Chris, On Feb 4, 2010, at 20:18 MST, Christopher Morrow wrote: > On Wed, Feb 3, 2010 at 11:18 PM, Dale W. Carder <dwcar...@wisc.edu> 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 ... -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 ... 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@irtf.org > http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
