[j-nsp] Limit on interfaces in bundle

[Saku Ytti]

On 29 October 2015 at 20:03, Michael Hare <michael.hare at wisc.edu> wrote:

Hey Michael,

> re: EoMPLS pw balancing, do you have no-control-word configured?  My understanding [and experience] is that vc is sticky due to hashing based on presence of control word.  If control word is absent you can hash based on normal IP/ethernet headers.  As I recall negative of removing control word has to do with drop optimizations during fragmentation.  I am struggling with same sort of thing for 10G backbone university san replication.  In my case it's because the traffic isn't well hashable even if it were native IP [consistent flow tuple] and short of pressuring vendor to support multiflow transfer, 40G/100G appears to be the only reasonable solution at this point.

This is largely terrible idea. MPLS LSR does not know what is the
payload that it is carrying, they can only use heuristics to guess it.
Common way to guess is, if first nibble is 6, it's ipv6, if first
nibble is 4 it's ipv4, otherwise it's ethernet.
This strategy stopped working somewhere in 2009 or so, when IEEE
decided to make stealing MAC addresses more awkward by stopping
in-order allocation in favour of random allocation. Now you can have
MAC address starting with 4, which would be incorrectly balanced as if
it were IPv4, causing reordering. Reordering is almost same as packet
loss on pretty much all shipping TCP stacks (reordering could be
mostly harmless, if stack were tuned for that, but it would make them
less efficient dealing with packet loss, now they are aggressively
tuned to handle more typical case).

If there is chance of ECMP in core, you want control-word.

-- 
  ++ytti