[j-nsp] TCAM full on EX8200?

[Pavel Lunin]

>> I meant that in order to do LB on labels alone (to have
>> enough of hash-keys for micro-flows), you need a large
>> enough set of labels in the core and more or less
>> uniformly distributed traffic over these labels. If you
>> have, say, 10 PoPs and 90 core tunnels, it's very
>> probable that 20% of them carry 80% of traffic. But
>> label-based hash will share labels 50:50. This is why
>> label alone is not sufficient for limited set of LSPs
>> and you need to construct hashes with more parameters
>> from payload.
> Seems like a problem that can be solved with the so-called
> Entropy Label:
>
> http://tools.ietf.org/html/draft-ietf-mpls-entropy-label-00

Thanks, I didn't see it. Cool idea, which allows to signal sharing 
proportion from the ingress to LSRs down the path.
But, I am afraid, it's still not for the cheap PFEs. At least it seems 
like that from the first glance.

>     Entropy labels are generated by an ingress LSR, based entirely on
>     load balancing information.  However, they MUST NOT have values in
>     the reserved label space (0-15).  Entropy labels MUST be at the
>     bottom of the label stack, and thus the 'Bottom of Stack' (S) bit
>     ([RFC3032  <http://tools.ietf.org/html/rfc3032>]) in the label should be set.  To ensure that they are not
>     used inadvertently for forwarding, entropy labels SHOULD have a TTL
>     of 0.

So, the LSR must be clever enough to inspect the label stack down to the 
bottom, find the entropy label, extract it, push it to the network 
processor, construct a hash on it, etc.

Keeping in mind what we discussed in the next thread, it's way too 
complicated for the cheap ASICs, used in ethernet switches. Most of 
them, as far as I understand, are just hardcoded to extract bits with 
given offsets and that's all. In addition, looks like they have a 
limited-size memory cells (registers or whatever), on which they can do 
xor/mod/cmp/etc for the hash-key calculations and hash-key->next-hop 
mapping.