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.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp