[ppml] Revising Centrally Assigned ULA draft

[Leo Bicknell]

In a message written on Tue, Jun 19, 2007 at 09:04:34AM -0700, David Conrad wrote:
> So, between 60K and 250K additional routes, which (according to the  
> router vendors) is still 1/4th what today's routers can handle.  That  
> would appear to double the size of the routing table over a 2 to 3  
> year period, not be a "jump by at least one order of magnitude  
> overnight, perhaps closer to two orders of magnitude."

Under current policies.  In the scenario you put forth PI was much
easier to get, which will also mean an increase in the number of
ASN's being allocated.

Let me put it to you this way.  Verizon Business (I pick on Jason
as he's the only one I've seen stand up recently and give a metric,
if someone has better numbers) has 200,000 internal routes IIRC.
They have what, perhaps 2,000 RIR allocations (I bet it's less) so
the average RIR block turns into 100 routes.  Humm, that sounds low for
a company getting /12's and such.  Still, it's a factor of 100.

If all of those turned into PI in the DFZ, you'd have a factor of
100 more routes.  So if there's 200,000 routes today, it would be
20,000,000 routes in the time period it took people to get the
space.  Now, let's me optimistic and say 25% take advantage.  That's
still 5 million routes in perhaps 5 years time.

Going from 200,000 to 5 million in 5 years pretty much is a step
function, at least to me.  And I think 25% buy in and an "average
block" turning into 100 routes is both way low.

> Clearly there is a disconnect.  From my perspective, operators who  
> are concerned have been completely drowned out by those who (for  
> whatever reason) are not concerned. If major operators actually  
> believe what the router vendors is saying is BS, then they should  
> probably stop preaching to the choir in the RIR community and make  
> their feelings known more forcefully in places like NANOG (I wasn't  
> there, did anyone shoot down Scudder's presentation?) and the IETF.

Part of the issue is that the "box" being able to do, say, 1 million
routes does not mean the DFZ can be 1 million routes.  If an ISP
is going to deploy a 1 million route router with a 5 year lifespan,
that's effectively maybe 500,000 routes today, to allow for growth
over that lifespan.  In a large provider that  500,000 routes is
then probably divided to 200,000 in the DFZ, another 200,000 of
internal routes to suport the Internet business, and 100,000 to
support Layer 3 VPN's on the edge devices.

So a 1M router box, buyable today is "full", in the sense of
everything that will go on it with a 5 year life span, and 200,000
routes.  Those numbers are just IPv4 too, that's left zero headroom
for IPv6.  Perhaps Jason can give a nod to my swag, but I think
that's the jist of why he stands up at the meetings and is so
concerned.

> Aside from the fact that the IPv6 DFZ surpassing the IPv4 DFZ is a  
> mere doubling and there is (supposedly) sufficient headroom in  
> routers today, much less 2 to 3 years from now, what would drive the  
> rush for IPv6 space?  I am skeptical that simply it's availability  
> (particularly if the $100/year fee was recurrent).  IPv6 would need  
> to provide something that IPv4+NAT doesn't.

IPv4 exhaustion will drive the rush.  The first person who is
effectively forced to use IPv6 will start pressuring the people
they want to talk to use IPv6.  As more people are forced to use
IPv6, that groundswell will happen rather quickly.  I think you'll
find within a 18-24 month period 80% or more of the current IPv4
internet trying to migrate to at least dual-stack.

So they will get IPv6 space.  If PI is "easier" they will ask for
it, because in IPv4 PI was better, reserved for the eletes, and
makes your life a lot easier.  I think that's still true, but even
if it's not the change will happen so quick we have no chance of
educating the masses of network admins around the globe.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070619/9c8524c5/attachment.sig>