MPLSoUDP is not the technology you should be looking at, SRoUDP (RFC8663) is. draft-bookham-rtgwg-nfix-arch describes an architecture that makes use of it to provide an end2end SR path. Cheers, Jeff On Sep 17, 2020, 9:32 AM -0700, James Bensley <jwbensley+nanog@gmail.com>, wrote:
On 17 September 2020 11:05:24 CEST, 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.
Nope, we have the same understanding. But the email I was responding to was talking about using MPLSoUDP for service label encapsulation *only*, not transport & services labels:
If you want an IPv6 underlay for a network offering VPN services
And what's wrong again with MPLS over UDP to accomplish the very same with simplicity ?
MPLS - just a demux label to a VRF/CE UDP with IPv6 header plain and simple
+ minor benefit: you get all of this with zero change to shipping hardware and software ... Why do we need to go via decks of SRm6 slides and new wave of protocols extensions ???
Cheers, James.