[c-nsp] Dynamic TCAM allocation/optimization? (was Re: N7K tcam handling)

[Richard A Steenbergen]

On Mon, Mar 15, 2010 at 04:40:50PM +1000, David Hughes wrote:
> 
> So, as an example, in your RIB you have an entry for 10.0.0.0/16 and
> about 1,000 entries for more specific routes in net 10.  The supernet
> is withdrawn by a peer device and the router is left trying to work
> out which of the more specific FIB entries it yanked it needs to put
> back in (and if they'll even fit).  Sounds like a mine field.

This isn't really that difficult. Yes you'd have to keep tabs on which
routes have been aggregated away, which route caused the aggregation,
and be able to quickly find those routes when you go to pull an
aggregator, but this is the kind of stuff the router is already doing
within the BGP protocol anyways. The hardest part of the implementation
would probably be not slowing down fib updates (because everyone wants
rapid convergence), but I think you could probably make this pretty
quick by integrating it into the FIB build process (depending on the
exact details of your FIB, of course). Totally not an intractable
problem.

The real mess here is the non-deterministic nature of what you're doing.
Someone flaps that /16 and now you've added 1000 new more specifics,
which might push you over the edge in FIB usage, with no way to predict
when or where it will happen. And yes you can probably consume a fair 
bit of CPU by flapping a big aggregator over and over, but heck you used 
to be able to do similar by flapping 0.0.0.0/32. :) Once you start 
exposing these details to the end user though, things get problematic. 
It's much easier just to sell them a bigger fib.

-- 
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)