North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Address allocation stats

  • From: Jeremy Porter
  • Date: Wed Jun 12 16:18:21 1996 
[initial stuff deleted]
>They are much improved.  When address reclaimation was started over this space,
>BBN had eight (8) blocks.  And there are efforts in progress to recover
>more of this space. You will note that none of these blocks are for BBN-Planet
>but for BBN internal and BBN contracts for US Military nets. However, this
>is not the real problem.
>
>The largest concern is the so-called toxic-waste-dump of the 192.0.0.0/8 range.
>This is due to the fact that the critical path component is not address space
>but routing table entries.   Efforts to get people to reduce the number of
>192.0.0.0/8 entries in the global routing space will provide the most "bang
>for the buck" until (with a nod to Noels excellent arguments) better routers
>are on the market.  
>
>So lets not pick on BBN while the real problem is chomping on our respective
>hindends.


Hm...  perhaps I need a better chart at Nanog, anyway,  here the
summary:
Todays total announce prefixes: 
~36,000
Average aggregation on a prefix for currently unannounced space
(not including RFC- space reserved for private networks)
For a /20:
>650,000
For a /19:
>325,000
For a /18:
>150,000
For a /17:
>75,000
For a /16:
<50,000

Now from my other chart " Your favority router vendor BGP memory usage"
At /16 level of AVERAGE aggregation, plus legacy prefixs, we will
be eating about 18megs of memory for Cisco BGP data
with 4 full views (4 NAP/MAEs)
At /17 (4.0 views): 30M of memory
At /18 (4.0 views): 50M of memory
At /19 (4.0 views): 100M of memory
At /20, my chart won't fit on my screen.

For those companies that are creating multiple private interconnections we can 
look at data for 8.0 views:  (fractional View number are common in real
world data since, there are legacy private interconnects and
multi-home customers count differently, thew "view" number is the
ratio of prefixes to path, since cisco's use about 135 bytes
per prefix, plus 35 bytes per path, this is fairly constant).

/17 (8.0): ~45M
/18 (8.0): ~55M
/19 (8.0): ~125M
/20 (8.0): >225M

At 16 paths per prefix (16 major exchanges)
/17 (16.0): ~60M
/18 (16.0): ~115M
/19 (16.0): ~240M
/20 (16.0): >370M


Of course this is "end state" after all possible addresses have been
assigned.

Now if you just look at it on a total prefixes basis, you can
see with 8 peering points and 75,000 prefixes, a Cisco 7000
is just going to die.

And most of us know that route flap will kill is first, if we
don't dampen.   If any has any clear ways to gather data
of route flap cpu utilization, I'd like to tal to them.  Some people
have done this, it just isn't very easy to gather data and
do best fit function like the memory data was.


-- 
Jeremy Porter, Freeside Communications, Inc.      [email protected]
PO BOX 80315 Austin, Tx 78708  |  1-800-968-8750  |  512-339-6094
http://www.fc.net

- - - - - - - - - - - - - - - - -