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 <gherbert@crl.com>

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 gherbert@crl.com