On Mon, Dec 12, 2011 at 12:55 AM, Nick Hilliard <nick@inex.ie> wrote:

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.

The same trends coud not apply after the IPv4 address space run-out.
An earlier (IPv4->IPv6) transition, or cleaning the announcements would stop the growth and even reduce the table.
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.

> 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.

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?

Increasing the BGP table is easy.... changing the CPUs is theorically possible, but who should pay for it?

> 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.

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.

> 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.

PI allocation MUST be stopped earlier then it cause more problems.

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.

Nick

Géza