Re: SRm6 (was:SRv6)

[James Bensley <jwbensley+nanog () gmail com>]

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.