Address allocation stats

[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 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 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

Hm... perhaps I need a better chart at Nanog, anyway, here the
Todays total announce prefixes:
Average aggregation on a prefix for currently unannounced space
(not including RFC- space reserved for private networks)
For a /20:


For a /19:


For a /18:


For a /17:


For a /16:

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

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.