[c-nsp] Pseudowire and load-balancing - revisit

[James Jun]

Hi James

On Wed, Mar 13, 2019 at 09:29:13AM +0000, James Bensley wrote:

> The ingress PE probably only has the same source and destination MACs
> to hash on to generate the FAT label. This means that in the scenario
> that your customer is using MPLS the required level of entropy isn't
> available to the ingress PE to generate a range of FAT labels.

This would be the case yea.  The customer in this case is rolling MX on both ends
with a /31 used on both ends of the PW and using it as "backbone p2p" link, so src
and dst MACs visible to the PE will always be the same.

But the feature problem here is that anytime EtherType is not IP, entropy isn't 
generated for FAT-PW as it won't see the payload IP headers after ENET?  If the 
customer turns off MPLS or IGP shortcuts and switches to pure IP forwarding, problem
would go away.


> > Thanks! I figured as much.  It seems like ASR9K only creates entropy for
> > pure IP traffic as passenger traffic entering the PW.  MPLS run over PW by
> > client user seems to break load balancing completely.
> 
> That is not strictly true. ASR9K can pull entropy from Ethernet
> headers entering the pseudowire; I think the problem in your case is
> that it's always the same src/dst.

Yea, but ENET headers don't do any good for me.  I can't expect passenger traffic to be
load balanced between various MACs, it's like expecting a LAG interface to generate
decent balance on a two-router p2p link relying on src/dst MACs as entropy.

> 
> > In the meantime, we'll just have to replace the LAG with 100GE to make
> > this problem go away.
> 
> If that is easy for you to do then that will definately fix this
> problem (for now, untill you add a 2nd 100G link :) ).
> 

Alas, yea.. life is full of compromises lol.  I think it's a design compromise that when
we're providing 10GE PWs as atomic units, transport links just need to be higher than what
passenger atomic units are, to let even rudimentary (L2CKT label only hash) load balancing
to work.  Same logic we've had with ASR920 in the metro -- not providing bigger than 1GE PWs
on those devices being fed with 10GE uplinks.

If someone needs a 100G point-to-point, for now it'll have to be optical transport, or we'll
have to look at alternate packet transport designs.  Right now, business case wise, it makes
more sense (and cleaner) to provide optical transport for 100G waves than oversubscribe the
packet network -- but only works in the metro where we have fiber/optical footprint.

James