Hello Nick,<br><br>I see that we still disagree on many points.<br><br><div class="gmail_quote">On Mon, Dec 12, 2011 at 12:55 AM, Nick Hilliard <span dir="ltr"><<a href="mailto:nick@inex.ie">nick@inex.ie</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 11/12/2011 20:50, Turchanyi Geza wrote:<br>
> 1, It would be better not to forget the limits of the equipments installed<br>
> in the current network (not negligabe percentage of the installed<br>
> equipments with 500k IPv4 prefix capability only.).<br>
<br>
</div>Routers with RE space for only 500k prefixes will soon be defunct if they<br>
aren't already. �It's been pretty easy to project ipv4 RIB growth over the<br>
last several years. �Take a look at:<br>
<br>
<a href="http://bgp.potaroo.net/bgprpts/bgp-active.png" target="_blank">http://bgp.potaroo.net/bgprpts/bgp-active.png</a><br>
<br>
If you draw a straight line on the basis of any period after 2004, you'll<br>
see that we'll hit 500k prefixes some time in 2013. �If you're using ipv6<br>
or mpls or have a large IGP or have a l3vpn network, you're probably<br>
outside the bounds of 500k prefix routers.<br></blockquote><div><br>The same trends coud not apply after the IPv4 address space run-out. <br>An earlier (IPv4->IPv6) transition, or cleaning the announcements would stop the growth and even reduce the table.<br>
And not only the 500K limit could be reached soon if the size of the routing table is not considered important while deciding about policy, however, the 1000K limit as well. What affects a much larger chunk of the installed equipments. <br>

</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="im"><br>
> 2, As far as I know network convergence still needs several 10s of seconds<br>
> in real life, even with faster CPU in the installed equipments.<br>
<br>
</div>More importantly, Moore's law has ensured that CPU speeds have increased<br>
faster than the DFZ BGP table has grown over the last number of years. �BGP<br>
and routing churn are not the problem here.<br></blockquote><div><br>I have still quastion marks: if a severe earthquake cuts an optical cable under the ocean how much time needed for the global routing to converge? <br>
<br>Increasing the BGP table is easy.... changing the CPUs is theorically possible, but who should pay for it?<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div class="im"><br>
> Do we agree that a clear, understandable limitation of the bad effects of<br>
> the PI address space would be helpfull, and reduce the conflict between<br>
> PI-funs and "clean-forwarding-table" networkers?<br>
<br>
</div>We're all adults and we all understand the implications of DFZ table growth.<br>
<div class="im"><br>
> I suggested a mesure: OK. let's allow PI allocations in exceptional cases<br>
> until the number of PI allocations is below of the number of the LIR in the<br>
> RIPE regions. (Other regions might accept the same, therefore it is easy to<br>
> extend this policy limitaton at global level, and keeping the "pollution"<br>
> low, globally).<br>
<br>
</div>I'm not in favour of the idea of pulling a figure out of thin air and<br>
saying that we shouldn't allow any more ipv6 PI assignments than this. �The<br>
number of LIRs in the RIPE region is no more relevant to a good quality PI<br>
assignment policy than any other randomly chosen number.<br></blockquote><div><br>I agree that using the "number of LIRs in the region" as a unit might sound strange. BUT there are arguments in favour it: even politician might understand this mesure. Anyhow, the RIPE NCC should be financed and controlled by the LIRs, and not by the PI address space holders.<br>
<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> OR, do you want PI allocation for every village in certain continents?<br>
<br>
</div>Let's not create a straw man argument. �IPv4 didn't cause the sky to fall,<br>
and IPv6 won't cause it to fall either. �If IPv6 PI starts showing signs of<br>
causing problems over the next couple of years, then we can change the policy.<br>
<font color="#888888"><br></font></blockquote><div>�</div><div>PI allocation MUST be stopped earlier then it cause more problems. <br><br>There is no way to foresee the exact behaviour of address requestors: if PI requests became a fashion you might expect several tens of thousands of PI address block allocated within a year... and you wont be able to stop this within the framework of the current proposal.<br>
<br>�</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font color="#888888">
Nick<br>
<br></font></blockquote><div>G�za <br></div></div><br>