[c-nsp] Rant: ASR1000 MPLS (not) load-balancing

[adamv0025 at netconsultings.com]

Hey Saku, happy new year!

> From: Saku Ytti <saku at ytti.fi>
> Sent: Tuesday, December 31, 2019 2:12 PM
> 
> On Tue, 31 Dec 2019 at 15:59, <adamv0025 at netconsultings.com> wrote:
> 
> > I was going to object that this can't possibly be by design cause what if I
> have 100 labels on the packet, then I realized that ASR1k's QFP gets the
> whole packets not just the first N bytes, so I guess I can see the thought
> process like "since we are getting the whole packet we might as well look
> into IP header and balance based on what we'll find there".
> 
> Based on context I believe 'this' here means ability to look past labels into IP
> headers. This is the norm, not exception. And it is typically followed by
> restriction such as 'up tp 5 labels'.
> 
I thought that what you wrote is obvious from the one liner comment quoted. 
Nevertheless yes correct that's what I meant, that on majority of the NPUs used in routers there are limits as to how many labels a platform can skip in order to inspect IP header contents and I was going to use this against ASR1k and the hard and fast rule to always look for IP header wondering how could this rule work if there's a limit of say 5 labels and my packet has more -what will the platform do then in terms of load-sharing if it can do such decision based solely on contents of the IP header but can't get those during parsing operation (due to up to 5 labels limit for instance) possibly leading to some kind of exception, however then I realized that QFP used in ASR9k is different in this regard and always has access to all the contents of a packet (very much like a FW NPUs for instance), therefore the "usual" router limits (e.g. lookup up to 5 labels deep) do not apply in case of asr1k so I was playing devil's advocate arguing how I could see ASR1k eng. Falling for this trap.
So I guess this is the long version of my thought process summed in that one liner there.    

> There is absolutely no way to know for sure what is carried by MPLS, 
Exactly 

> so fast
> and simple rule of 4/6 is fine, 
Yes fine as to usually does the right thing, but completely oblivious to any guidance on load-sharing carried by the label stack

> as it's the common case to follow MPLS label by
> IP header, with implied promise that any other protocol you send does not
> start with 4 or 6, i.e. code-word is non-optional if you plan to do any transit
> heuristics, no matter how smart the heuristics is, it is heuristics, not
> guarantee.
> 
Hence I'd always prefer transit nodes to use solely the MPLS stack for any clues on how to load-share. 
As the PE has much better chance of having an un-skewed view on what is or is not part of the same flow therefore my preference is for PEs to record the flow information in the flow stack and having P nodes blindly follow that (i.e. the use of entropy labels).
For what it's worth nowadays it could be an application or a controller with true knowledge of what constitutes a flow programming the label stack a PE should impose on a set of packets.  
And it seems this ASR1k acting as MPLS transit node and using port-channel interfaces, will happily ignore any clues carried by the label stack.   

> I agree with Lukas that not including labels in balancing hash calculation is
> broken behaviour.
So do I.
I'd have Cisco to update ASR1k documentation also on use of Entropy and Flow labels to put a note there that these features are not supported in combination with port-channels.
 

adam