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

[Richard A Steenbergen]

On Thu, Mar 11, 2010 at 02:23:12PM -0500, Chris Woodfield wrote:
> Can you elaborate (or point me to docs) on how this dynamic allocation
> works? Is the TCAM populated on demand based on traffic? I imagine the
> old horror of the Sup1A's flow-based forwarding every time I hear
> this...

I believe he means that you no longer have to statically allocate your
TCAM at boot time into segments for IPv4/MPLS (72 bit TCAM entries) vs
IPv6/Multicast (144 bit TCAM entries). This is a good thing for
minimizing unnecessary reboots, especially with the uncertain growth
rates of v4 vs v6, and has nothing to do with flow based routing.

> And while we're on the subject, are there any reasons why Cisco (or
> any other vendor AFAIK) has seriously looked into methods of
> "optimizing" the TCAM? I'm thinking in terms of "If 10.0.0.0/16 and
> 10.0.1.0/24 both have the same next hop, why do you need two TCAM
> slots?"

The most compelling argument I've heard against this type of FIB
aggregation is that it would be completely non-deterministic. While it
might greatly improve your FIB utilization, the amount that it helps
would be entirely dependent on your configuration and topology, and you
would never be able to predict when a routing change might vastly
increase utilization. Imagine for instance that you change your
route-maps, and now 10.0.1.0/24 and a bunch of other /24s are pointing
to a different next-hop. Suddenly your FIB usage increases, exceeds the
capacity of the router, and bad things start to happen. Having customers
depending on such an unpredictable mechanism is... risky.

Of course we all know the real reason is they'd rather sell you a bigger
box with more TCAM, but the above scenerio is certainly not without its
risks. :)

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