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

[Lincoln Dale]

On 12/03/2010, at 6:23 AM, 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...

no very very different.  C6K Sup1A was flow switching (MLS) demand populated.  i.e. first packet in a flow processed in software, software installs a hardware (MLS) shortcut entry, rest of flow is processed in hardware.

N7K always forwards based on a FIB.  i.e. not demand populated.  a forwarding entry either exists in the forwarding TCAM or does not.  if it does not, packet is dropped.

the context of "demand populated FIB TCAM" means that the FIB TCAM isn't statically carved out for IPv4 unicast, IPv6 unicast, IPv4 multicast, IPv6 multicast.
rather, banks of the FIB TCAM are carved out into the above as needed.
"as needed" is determined by RIB populating the FIB, i.e. routing protocols populating the entries.

> 
> 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?"
> 
> Oh wait, that might mean your customers might not need to upgrade as often. Never mind.

we have looked at this. many times.  it gets nondeterministic very very quickly and does not scale from a control plane perspective.
http://www.ops.ietf.org/lists/rrg/2008/msg01880.html covers some of the idea and pros/cons.


cheers,

lincoln.