<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 10, 2014 at 1:58 PM, David Farmer <span dir="ltr"><<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 1/10/14, 09:23 , Michael Richardson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Martin Hannigan <<a href="mailto:hannigan@gmail.com" target="_blank">hannigan@gmail.com</a>> wrote:<br>
     > Someone pointed me at 4.4 and noted that it says that an IXP can<br>
     > receive an allocation if two parties are present. The common<br>
     > understanding in the industry is that two parties connected are private<br>
     > peering and three on a common switch "could" be an IXP.<br>
<br>
     > Is there a reason not to bump this number up to three in light of<br>
     > prevailing circumstances and conservation of the infrastructure pool?<br>
<br>
If two parties decide to start an IXP, and get a switch, rather than just<br>
do private peering, it's really hard to get to three if two don't count.<br>
Still, one party or the other *ought* to have a /28 around, and renumbering<br>
for two parties isn't that hard.<br>
<br>
I propose a compromise: three parties (a route server would count) for IPv4<br>
micro-allocation,<br>
</blockquote>
<br></div>
I think I like this idea.<br></blockquote><br><br></div><div class="gmail_quote">It's interesting, but you're introducing a new barrier. Capital. Some are already encumbered by bad advice and capital constraints. By upping the number a digit you actually increase their likelihood and getting an ROI on their capital. <br>

<br>Adding a route server is a good idea, but without the third, it's a waste of capital IMHO and a new barrier.<br><br>Best,<br><br></div><div class="gmail_quote">-M<<br><br><br></div><div class="gmail_quote"><br>

<br></div></div></div>