North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: multi-homing fixes
in line > -----Original Message----- > From: [email protected] [mailto:[email protected]]On Behalf Of > Marshall Eubanks > Sent: Saturday, August 25, 2001 2:31 PM > To: Leo Bicknell; Randy Bush; Daniel Golding; Leo Bicknell; > [email protected] > Subject: Re: multi-homing fixes > > > > > > >On Fri, Aug 24, 2001 at 03:11:39PM -0700, Randy Bush wrote: > >> please look at slides 11 and 15 of > >> > >> <http://psg.com/~randy/010809.ptomaine.pdf> > >> > >> the /24s of small multihomers is half the routing table > (see geoff's data) > > >> and is growing radially (if you are silly enough not to > filter that stuff). > > > > >Does anyone have a graph of the number of allocated AS numbers? I > >ask because in a perfect world each AS would originate 1 prefix > >only, as they got enough address space in their first alloaction > >to service them forever. In that case growth of the AS table would > >be the growth of the routing table. > > There are a number of such plots - we have one at > http://www.multicasttech.com/status/asn.plot.gif - > see http://www.multicasttech.com/status/ for explanation - > and there are ones at Telstra -see > http://www.telstra.net/gih/papers/ipj/4-1-bgp.pdf and > http://www.telstra.net/ops/bgp/pc3/bgp-as-count.html > > By all indications, the growth in both active AS and BGP > prefixes has slowed since the market collapse. > > There are currently ~ 11,000 active AS and ~ 104,000 prefixes, so > each ASN has on average about 9 and 1/2 prefix blocks. > So by this indication multi-homing and exposing the prefix to the DFZ is not the problem. The real problem is the inability to defragment the prefix allocations. As Leo noted, if we could get to a single prefix per AS we would stop having these discussions about table growth. > Regards > Marshall Eubanks > > > > >The real world would never work like that of course, but it is an > >absolute lower bound on the table size, I think. I do believe we > >can get much closer to this world with address space sizes like > >those available in IPv6, however it's not clear to me that people > >are really trying to think that way. > > Historically this has been true, because there has been a disconnect between the operational goal of minimizing the table size through enforced aggregation, and the business goal of giving the customer the provider independence they want. I welcome all comments on: http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-00.txt http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-00.txt and their applicability here. I am planning on modifying the discussion on aggregation to account for the business reality that all multi-homed prefixes will show up in the DFZ, because there is no motivation to aggregate. Given the AS table is ~ 1/10 the IPv4 prefix table, I believe there will be no problem with routers keeping up for the foreseeable future because the number of prefixes per AS will approach 1. > >-- > >Leo Bicknell - [email protected] > >Systems Engineer - Internetworking Engineer - CCIE 3440 > >Read TMBG List - [email protected], www.tmbg.org > > > > > > Marshall Eubanks > > [email protected] Tony
|