Re: SRm6 (was:SRv6)

[Jeff Tantsura <jefftant.ietf () gmail com>]

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.