From what I can see, and I haven't spent much time yet looking at what is
causing the return to exponential growth, there is a large amount of
deaggregation going on.
My thoughts about those are, in order of significance:
a: lack of BGP clue in the newer ISPs
b: multihoming by spraying out /24s in all directions in the hope that
something works
c: general carelessness by those who should know better
If you plot the growth rate of /24s, you will see that they are increasing
at a rate not far short of that of the overall routing table size. Today we
have 52000 /24s in a table of 90000 prefixes. Check out the daily stats I
produce at http://www.apnic.net/stats/bgp.
Ofcourse, I'd venture the question as to whether any of this is a problem.
Router vendors make bigger routers with more memory. Some ISPs have claimed
when I've presented on this over the last year or so, that the size does
not matter and convergence rate of the core isn't affected. Most of the
ones I work with in my theatre of operations (AsiaPac) are worried as they
have now to plan on upgrading routers from the 64M which was sufficient for
the last several years, to 128M or 256M to try and keep up with the
exponential growth rate.
Item a: above could be solvable with education. Many people are trying, but
I'd venture to say that it is not having much affect. Tony's posting
doesn't have the stigma it once had. In fact, I'd say most of the culprits
don't know about it, or couldn't care less as it doesn't affect them. Maybe
a bigger stick is required? (Like the one Sprint wielded a few years back? ;-)
Item b: could also be improved by education, with top providers
collaborating to document the best practices when it comes to multihoming.
And asking the vendors for features which would make it easier, if appropriate.
Item c: Loops back to Item a:, I think. Same cause, same solution.
I think we need to figure out whether any of this is really a problem at
the moment, and if it is, how we are going to solve it in a way which is
acceptable to all. Maybe BGP is simply out of date and we need to move on
to something else (??) which is better for the Internet...
My $0.02
philip
--At 00:57 23/09/00 -0600, mccreary@colorado.edu wrote: >Perhaps some of you have been following the thread on the NANOG mailing list >concerning the current growth rate of the core BGP routing table. This >reminded me of some questions that came up after Geoff Huston's presentation >at the last IETF regarding the possible origins of this growth. Geoff's >presentation included a heuristic `piecewise fit' of the historical BGP >routing table size data going back to the pre-CIDR period at the beginning >of 1994 (see http://www.telstra.net/ops/bgptable.html, or Tony Bates' similar >plot at http://www.employees.org/~tbates/cidr.hist.plot.html). Geoff >hypothesized that while the pre-CIDR period showed exponential growth in the >number of prefixes stored by core routers, the period after the introduction >of CIDR shows sub-exponential growth. However, both his and Tony's data (as >well as my own at http://xoanon.colorado.edu/routing/BGP_table_size.html) >clearly show that the current growth rate is once again exponential. > >If Geoff's hypothesis about the qualitative difference in the growth rate >during the mid-1994 to 1997 period is correct, then something must have >changed in the way core ISPs are using BGP in recent years. This raises the >following questions: > > 1. What engineering practices are producing the increased growth > rate? Possibilities here include advertising aggregateable > address space as several pieces to balance traffic across > multiple links, as well as lack of BGP expertise among new > providers' engineers. > > 2. Can BGP be easily extended to accomodate the technical and > economic requrements that motivate these practices while > reducing their impact on core router resources? Given a > thorough understanding of the problems ISPs are trying to > solve, it seems likely that a better solution can be found > through careful modification of the routing protocol rather > than operational hacks that achieve the desired goal as a > side-effect. > > 3. If no scheme can reduce the amount of resources required to > accomodate these requirements, can a feedback mechanism > be designed that prevents their frivolous use? This could > be economic or technical in nature, but a simple policy > mechanism that could be enforced unilaterally would best > match the current business model of most ISPs. >-- >Sean McCreary mccreary@colorado.edu
-------------------------------------------------------- Philip Smith ph: +61 7 3238 8200 Consulting Engineering, Office of the CTO, Cisco Systems --------------------------------------------------------
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT