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+na...@gmail.com>, wrote: > > > On 17 September 2020 11:05:24 CEST, Saku Ytti <s...@ytti.fi> wrote: > > On Thu, 17 Sep 2020 at 11:03, James Bensley <jwbensley+na...@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.
