On Feb 4, 2010, at 20:18 MST, Christopher Morrow wrote:
> On Wed, Feb 3, 2010 at 11:18 PM, Dale W. Carder <> wrote:
>>> Joel, in (msg05925), you wrote:
>>>> The IPv4 Internet works. The routers, and the routing system, cope
>>>> with the current pressures. To my way of looking at things, the
>>>> question is how will the Internet routing system cope with growth.
>>>> But, definitionally, there really is not that much growth left in
>>>> IPv4.
>> As an operator, I would agree with this, but I fear it only to be
>> true until prefixes start having substantial resale value.  At that
>> point, slicing and dicing would really begin once the money starts
>> flowing.
> I think it's not just 'for sale' but 'gosh /24 really isn't the limit
> is it? lets start accepting and passing on /25../26../27...etc'

I have to disagree, at least with respect to anything longer than /24.  
Specifically, while you're immediate upstream (whom you're paying money to) may 
accept longer than /24, they can't (or, actually, won't) make any guarantees 
that any other provider will accept that prefix, effectively leaving you with 
only partial (barely any?) connectivity to the Internet.  OTOH, you're correct 
that it's possible that much shorter IPv4 prefixes (/8 - /23) may be 
de-aggregated, but I would add two things:
1)  In the short run, it's possible for SP's to use well-known techniques like 
FIB aggregation[1] and/or proxy aggregation in an attempt to constrain FIB and 
RIB growth.  However, TANSTAAFL and both are likely to further stress existing 
control planes on existing routers, which leads to my next point ... 
2)  We don't know when/where the control plane (RIB) will break with increased 
pressure of de-aggregation.  The traditional _assumption_ that we'll run out of 
FIB space long before the control plane falls over[2]; however, what could also 
happen is that with larger numbers of IPv4 *routes* in the global routing 
table, convergence may become intolerably slow for some (or, most?) 
applications, thus pushing people more quickly toward IPv6 with a not yet as 
big routing table and/or that doesn't have some of the "optimizations" that 
will be necessary to the IPv4 control plane protocols to slow down convergence 
to keep the system stable (cf: Sprint, iMCI, etc. in the mid- to late '90's) 

Note, neither of the above scenarios are by any means "pretty", but I did want 
to add there are 'tools' that may provide some [small] amount of runway and 
dampen some of the hysteria that the sky is falling and we need to have a fully 
deployed ID-Loc solution by tomorrow ...


[1] <-- already (was) 
being looked at in GROW!
[2] Let's not forget that it's not *just* routes in BGP, but just as 
importantly *paths* that has negative scaling implications, as well, on the 
control plane, (note slide 13):
    ... and, keep in mind, there are things on the horizon (i.e.: add-paths, 
SIDR?) that may add _more_ state to be pushed around in BGP (should they see 
widespread deployment), which is scary.  OTOH, on a more optimistic note, there 
are some additional enhancements that can make BGP more efficient, however it's 
unclear how much benefit several of the enhancements may provide as not all of 
them have been studied.

> Sure
> it's not going to get to Avagadro's number of prefixes in v4, but 3B
> is still way more than 2M (which is about where current vendors stop
> hedging today).
> In the end, ipv4 can get larger than current platforms can handle,
> quickly, and future planned platforms as well. It seems that the same
> problem exists regardless of protocol#.
>> The RIR's appear to me to be gearing up for this to some degree.
> yes.
> -chris
> _______________________________________________
> rrg mailing list

rrg mailing list

Reply via email to