[j-nsp] TCAM full on EX8200?

Pavel Lunin plunin at senetsy.ru
Fri Oct 21 07:21:54 EDT 2011



BTW, this is why I'm quite sceptically looking at the Juniper's 
marketing of Express Chip simplicity and corresponded benefits. Lower 
number of  transistors in the crystal, greater MTBF, blah-blah.

Because of the mentioned features, which I don't really believe Juniper 
could easily throw out, the LSR's PFE must be still quite smart. 
Otherwise we'll have much of fun, if the "revolutionary state-of-the-art 
PTX platform" can never do what Kompella and Drake proposed because of 
the hardware limitations :)

What they really could do (and looks like they did) is to reduce amount 
of SRAM for FIB and to assume that because of mostly label lookups, the 
ALU speed can be slower.

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


More information about the juniper-nsp mailing list