I couldn't help but notice how much address space BBN has:
4 Bolt Beranek and Newman Inc. (SATNET) 8 Bolt Beranek and Newman Inc. (BBNCCNET), listed as "temp" since 1992 46 Bolt Beranek and Newman Inc. (NET-BBNNET)
It would be nice if they (BBN-Planet) would renumber into a much smaller block. As one of their customers who renumbered to get a larger block, I find it hypocritical that they are asking their customers to renumber when they have not done it themselves. Bob
I couldn't help but notice how much address space BBN has:
4 Bolt Beranek and Newman Inc. (SATNET) 8 Bolt Beranek and Newman Inc. (BBNCCNET), listed as "temp" since 1992 46 Bolt Beranek and Newman Inc. (NET-BBNNET)
It would be nice if they (BBN-Planet) would renumber into a much smaller block. As one of their customers who renumbered to get a larger block, I find it hypocritical that they are asking their customers to renumber when they have not done it themselves.
Bob
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. --bill
Bill:
So lets not pick on BBN while the real problem is chomping on our respective hindends.
I could not agree more. Aggregation is a Tool not a Rule. A argument can be easily constructed that points fingers at router vendors; and another argument can be constructed that points fingers at other organizations. Let's not pick on BBN (didn't Bill say this first?) Happy Trails, Tim
[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. jerry@fc.net PO BOX 80315 Austin, Tx 78708 | 1-800-968-8750 | 512-339-6094 http://www.fc.net
participants (4)
-
bmanning＠isi.edu -
hinden＠ipsilon.com -
Jeremy Porter -
Tim Bass