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

[Robert Raszuk]

All true.

But for me from the perspective of number of years passed by I think using
MPLS transport is just a one big mistake.

MPLS for service demux is great, but I really see no advantages in using
LDP or even concept of global labels for transport. IP transport be it IPv4
or IPv6 offers  much more advantages, native summarization UDP or flow
label adds a lot of entropy while MPLS service label can still sit happy
behind.

If you need TE - it seems pretty trivial to do that with either IPv6 or
IPv4 encapsulation too.

Originally when we started with tag switching and then mpls GSRs did not
support IP encap (except of CPU based Engine 0 LCs) and hence to offer any
SP services - to allow them to move from ATM and F/R to IP yet still
interconnect customers new transport was rolled out. RSVP-TE came along as
natural extension too, but as we all know it has its own set of problems.

Sev 1 bug free 2020,
R.

On Thu, Jan 2, 2020 at 3:46 PM Saku Ytti <saku at ytti.fi> wrote:

> On Thu, 2 Jan 2020 at 15:46, Robert Raszuk <robert at raszuk.net> wrote:
>
>
> >> Hence I'd always prefer transit nodes to use solely the MPLS stack for
> any clues on how to load-share.
> >
> > That may not be a good idea.
> >
> > Think about SR-MPLS and global labels with say 5 TE segment nodes
> (hops). As MPLS header would be identical all flows travelling via such TE
> path would get zero load balancing across ECMP paths even parallel L3 links.
> >
> > Even if you get fancy and stick there EL as described in
> draft-ietf-mpls-spring-entropy-label-12 the limited ERLD in most platforms
> will not even reach it in the middle of the network.
>
> Adam implied presence of entropy indeed, and of course this would then
> be design constraint in choosing the LSR. Most platforms seems
> ambiguous, Trio, FP4, Jericho, Pacific should be good to +dozen
> labels, which seems very much reasonable for SR+EL. No perfect answer,
> but certainly if you want to design network to never do payload
> heuristics, it's entirely possible and there is no significant CAPEX
> penalty to it.
>
> > Not to mention that P routes may be receiving both IP and MPLS traffic.
> But I guess your point was that ".. if packets is mpls packet".
>
> And if you only balance on labels and include EL, then it doesn't
> matter what it carries. There is absolutely no way to be sure that
> MPLS payload heuristics is interpreting bytes correctly, it cannot
> know what it is carrying. The more verification you do (like IP packet
> length match) the rarer and harder to troubleshoot the problems are,
> the problems quickly become so esoteric you'll never even hear of
> them, because even customer can't believe it would be caused by the
> service provider's pseudowire. Like 'all hosts work, then we added
> ipsec, and one host stopped working' could very well be transit
> heuristics problem, but going from customer => noc => ops => dev =>
> vendor would be unlikely.
> IMHO, if you MUST do payload heuristics, simple heuristic 4 == IPv4, 6
> == IPv6, anything else is unknown is the correct heuristics. And then
> you must design your network to honor that assumption.
>
> --
>   ++ytti
>