Re: [rrg] IPv4 & IPv6 routing scaling problems

[Christopher Morrow <[e-mail]>]

On Fri, Feb 5, 2010 at 1:29 AM, Shane Amante <[e-mail]> wrote:
> Chris,
>
> On Feb 4, 2010, at 20:18 MST, Christopher Morrow wrote:
>> On Wed, Feb 3, 2010 at 11:18 PM, Dale W. Carder <[e-mail]> 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:

I should have been more clear with a few things :( (first that I would
hate to see this sort of thing happen) I was suppposing a world where
at least the following things have come to pass:
1) ipv4 freepool is empty
2) some number of providers have no more PA space to dole out to
new/existing customers
3) IP address space is available for 'purchase' (lease? whatever)
through 'not RIR' methods
4) there exist businesses with more than one 'site', which connect to
different upstream networks

In these cases it is a possible future where the enterprise in
question pays both upstreams to exchange these routes. There's the
possiblity that this becomes commonplace enough such that more global
leaking of ip prefixes longer than /24 is 'the norm'.

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

this is independent of my example future. (unless by FIB Aggregation
you mean: "Default to the left" aka Schiller's paradigm)

> 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 ...
>
> -shane
>
> [1] http://tools.ietf.org/html/draft-zhang-fibaggregation-02 <-- 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):
> http://www.ietf.org/proceedings/74/slides/grow-6.pdf

i agree that it's not just routes, it's not just paths, it's not just
speed of change (of either of the two previous items)...

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

also agree with this, adding more state or more memory/cpu
requirements to existing systems is full of unknown consequences.

-chris

>
>
>> 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
>> [e-mail]
>> http://www.irtf.org/mailman/listinfo/rrg
>
>