Scalability issues in the Internet routing system

Thu Oct 20 03:11:29 UTC 2005

>>

Daniel,

>> I think it is safe, even with projected AS and IP uptake, to assume
>> Moore's law can cope with this.
>
> Moore will keep up reasonably with both the CPU needed to keep BGP  
> perking, and with memory requirements for the RIB, as well as other  
> non-data-path functions of routers.

That's only true if the rate of prefix addition can be constrained to  
be below the rate dictated by Moore's law, which is the entire point  
of the discussion.  There is nothing today that acts as a pressure  
against bloat except portions of the net periodically blowing up as  
their hardware capacity is exceeded.

> Several items regarding FIB lookup:
>
> 1) The design of the FIB need not be the same as the RIB. There is  
> plenty of room for creativity in router design in this space.  
> Specifically, the FIB could be dramatically reduced in size via  
> aggregation. The number of egress points (real or virtual) and/or  
> policies within a router is likely FAR smaller than the total  
> number of routes. It's unclear if any significant effort has been  
> put into this.

In fact, there has been.  In a previous life, we actually had some  
FIB pre-processing that did a great deal of aggregation prior to  
pushing the FIB down into hardware.  We found that it was workable,  
but consumed extensive CPU resources to keep up with the churn.   
Thus, this turns out to be a tool to push the problem from the FIB  
back up to the CPU.  Previous comments still apply, and this just  
increases the CPU burn rate.

> 2) Nothing says the design of the FIB lookup hardware has to be  
> longest match. Other designs are quite possible.

Longest match is fundamental in the workings of all of the classless  
protocols today.  Changing this means changing almost every protocol.

> 3) Don't discount novel uses of commodity components. There are  
> fast CPU chips available today that may be appropriate to embed on  
> line cards with a bit of firmware, and may be a lot more cost  
> effective and sufficiently fast compared to custom ASICs of a few  
> years ago. The definition of what's hardware and what's software on  
> line cards need not be entirely defined by whether the design is  
> executed entirely by a hardware engineer or a software engineer.

This has been tried as well.

Tony