North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: A call for the future. Was: Re: Verio Decides what parts of the internet to drop

  • From: Andrew Bender
  • Date: Thu Dec 09 13:22:46 1999

In the design of contemporary core routers, table maintenance and packet
processing are discrete functions. 

The maintenance of comprehensive routing information that includes a superset of
best paths is common practice, with proven benefits. However, it is neither
necessary nor desirable to consult this database for a forwarding decision.
Instead, the fastpath need only have knowledge of the best next hop matching a
DA prefix. 

Whatever changes we believe to be in store for the table population, this is
unlikely to affect the typical number of adjacencies for a core router. Assuming
also that  we continue to use IPv4 for a while, the "input length" of composite
information for the FIB could be less than 7 bytes for unicast routes. For the
2.5E5 best paths discussed, this equates to approximately 1.4MB. 

Also, since the matching (ideally) yields a singular, exclusive result, this
matching operation is easily "parallelized" , in hardware or otherwise; observed
work need not even be linear with FIB size.

In short, the technical obstacles presented by high table / route population are
no greater for forwarding logic than for the control plane.

Regards,
Andrew Bender
Total Network Solutions, Inc.

> Date: Mon, 06 Dec 1999 18:27:07 -0800
> From: George Herbert <[email protected]>
> 
> The issue isn't in storing hundreds of thousands, millions,
> or tens of millions of routes.  This is, all things considered,
> a piece of cake.
> 
> The issue is getting the route out of storage, for each packet coming
> through the router, at a rate of millions of packets per second for
> each core router.  Each IP core router is doing about the same
> lookup work as the whole combined PSTN network is for all of its
> freely routed numbers.  It is, or should be, quite viable... but not
> easy, as we've all found.
> 
> - -george william herbert
> [email protected]
>