[arin-ppml] A challenge to the assumption that a big DFZ is a problem

Jon Lewis jlewis at lewis.org
Tue Dec 15 11:03:59 EST 2009

On Mon, 14 Dec 2009, Ted Mittelstaedt wrote:

> One of the fundamental assumptions that we all seem to accept many
> times is the "Ballooning BGP table/DFZ"  Much policy discussion
> seems to be centered around the idea that if the DFZ gets bigger
> it's going to cost bazillions of dollars for every ISP to upgrade
> equipment, yadda yadda yadda.
> I have to ask, however, is this assumption really technically
> accurate?
> I have to ask, if the PURCHASERS of new router hardware were to tell
> the router vendors that they aren't gonna bother buying a router
> that cannot handle a half-million table entries in the BGP table,
> that the router vendors might just possibly see a need for the
> faster silicon - and step up to the plate and supply it?  God
> knows they charge enough money for the OLD tech they are supplying
> now.  Anyone heard of Moore's Law?

This has at least to some degreee been addressed.  Cisco, for example, now 
makes a bunch of "CPE level" routers that can take large amounts of RAM.

The issue though, is the large installed base of routers and switches 
carrying traffic for all the service provider networks.  As the DFZ grows, 
routers that were doing just fine traffic capacitywise will require either 
processor board upgrades (NPE, Sup, etc.), forklift upgrades, or filters 
to get by.

That I can buy an inexpensive PC with quad core processors and several GB 
of RAM doesn't do me much good if my BGP is being done on large but aging 
cisco gear running out of whatever non-upgradable resources are used to 
hold the routing table.

That a good deal of the DFZ "growth" is actually just bloat caused by 
sloppiness or cluelessness is particularly annoying.

  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

More information about the ARIN-PPML mailing list