Spot on. 

And on the point of protection ... in all cases it is orthogonal to the service itself. If you want to use it you enable it regardless if your packet's transport is IPv4, IPv6, MPLS or any SR flavor. 

Sure if you need to traffic engineer your services some form of path control is required. It can be stack of SIDs, it can be pre-signalled paths or it can be pure encap-decap on selected anchor points. Your network - your choice. 

Thx,
R.


On Thu, Sep 17, 2020 at 11:07 AM Saku Ytti <saku@ytti.fi> wrote:
On Thu, 17 Sep 2020 at 11:03, James Bensley <jwbensley+nanog@gmail.com> wrote:

> MPLSoUDP lacks transport engineering features  like explicit paths, FRR LFA and FRR rLFA, assuming only a single IP header is used for the transport abstraction [1]. If you want stuff like TI-LFA (I assume this is supported in SRm6 and SRv6, but I'm not familiar with these, sorry if that is a false assumption) you need additional transport headers or a stack of MPLS labels encapped in the UDP header and then you're back to square one.

One of us has confusion about what MPLSoUDP is. I don't run it, so might be me.

SPORT == Entropy (so non-cooperating transit can balance)
DPORT == 6635 (NOT label)
Payload = MPLS label(s)

Whatever MPLS can do MPLSoUDP can, by definition, do. It is just
another MPLS point-to-point adjacency after the MPLSoUDP
abstraction/tunnel.

--
  ++ytti