SRm6 (was:SRv6)

James Bensley jwbensley+nanog at
Thu Sep 17 16:30:45 UTC 2020

On 17 September 2020 11:05:24 CEST, Saku Ytti <saku at> wrote:
>On Thu, 17 Sep 2020 at 11:03, James Bensley <jwbensley+nanog at>
>> 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

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 ???


More information about the NANOG mailing list