[c-nsp] BGP memory on a 6500

[Richard A Steenbergen]

On Tue, Oct 03, 2006 at 10:55:55PM -0700, Tony Li wrote:
> 
> Richard,
> 
> The version that I'm thinking of was in fact deterministic.  For a given
> router and topology, for a given routing table, the results were 100%
> pre-computable.  Also, you should know that it is not wholly trivial to

Ok, I mean, the effectiveness of such aggregation varies depending upon 
topology and routes, and the operator may not (probably will not) be able 
to predict the results beforehand.

If an operator makes a policy change which moves a bunch of more-specifics 
to a new nexthop which is no longer covered by an aggregate route to the 
same nexthop, the FIB usage will shoot up accordingly. Thus you are no 
longer guaranteed that you will be able to fix X number of routes into Y 
sized FIB, and the effectiveness of such aggregation changes potentially 
with every BGP update.

Folks who depended on such aggregation to keep their network running, and 
who run it too close to the edge, might be in for a rude shock when they 
change a policy and their router blows up.

> implement.  There are a few interesting issues, such as remembering to
> reinstall the more specifics if the less specific is withdrawn;
> installing an aggregate plus holes if there was a full subtree of more
> specifics; and numerous other similar games each of which helped further
> reduce the forwarding load.

Well right, I guess I consider checking the RIB for more-specifics when 
you pull a route and rebuilding FIB accordingly simple enough. You can 
definitely go nuts with more complex optimizations like you mentioned, 
creating aggregate routes in the FIB which don't exist in the RIB in order 
to reduce routes, but I'd call that extra credit work. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)