On 11/12/2011 20:50, Turchanyi Geza wrote:
1, It would be better not to forget the limits of the equipments installed in the current network (not negligabe percentage of the installed equipments with 500k IPv4 prefix capability only.).
Routers with RE space for only 500k prefixes will soon be defunct if they aren't already. It's been pretty easy to project ipv4 RIB growth over the last several years. Take a look at: http://bgp.potaroo.net/bgprpts/bgp-active.png If you draw a straight line on the basis of any period after 2004, you'll see that we'll hit 500k prefixes some time in 2013. If you're using ipv6 or mpls or have a large IGP or have a l3vpn network, you're probably outside the bounds of 500k prefix routers. So I'm not really feeling very sympathetic to someone who's attempting to run a full DFZ on a 500k prefix box: either they haven't done their projections properly (in which case they need to consider a different career), or else they bought the box years ago, and it's been depreciated off their books. If you're using equipment that you many years ago, you shouldn't expect it to last forever, particularly if it has hard resource limits - e.g. forwarding table size. This is simply how hardware forwarding engines work. We're no longer able to run anything more than tiny networks on 7200s and J series boxes. It just doesn't work that way any more, and hasn't worked like that for years.
2, As far as I know network convergence still needs several 10s of seconds in real life, even with faster CPU in the installed equipments.
More importantly, Moore's law has ensured that CPU speeds have increased faster than the DFZ BGP table has grown over the last number of years. BGP and routing churn are not the problem here.
Do we agree that a clear, understandable limitation of the bad effects of the PI address space would be helpfull, and reduce the conflict between PI-funs and "clean-forwarding-table" networkers?
We're all adults and we all understand the implications of DFZ table growth.
I suggested a mesure: OK. let's allow PI allocations in exceptional cases until the number of PI allocations is below of the number of the LIR in the RIPE regions. (Other regions might accept the same, therefore it is easy to extend this policy limitaton at global level, and keeping the "pollution" low, globally).
I'm not in favour of the idea of pulling a figure out of thin air and saying that we shouldn't allow any more ipv6 PI assignments than this. The number of LIRs in the RIPE region is no more relevant to a good quality PI assignment policy than any other randomly chosen number.
OR, do you want PI allocation for every village in certain continents?
Let's not create a straw man argument. IPv4 didn't cause the sky to fall, and IPv6 won't cause it to fall either. If IPv6 PI starts showing signs of causing problems over the next couple of years, then we can change the policy. Nick