RE: multi-homing fixes

["Tony Hain" <alh-ietf () tndh net>]

in line

> -----Original Message-----
> From: owner-nanog () merit edu [mailto:owner-nanog () merit edu]On Behalf Of
> Marshall Eubanks
> Sent: Saturday, August 25, 2001 2:31 PM
> To: Leo Bicknell; Randy Bush; Daniel Golding; Leo Bicknell;
> nanog () merit edu
> 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 - bicknell () ufp org
> > Systems Engineer - Internetworking Engineer - CCIE 3440
> > Read TMBG List - tmbg-list-request () tmbg org, www.tmbg.org
>
> Marshall Eubanks
>
> tme () 21rst-century com

Tony