SRm6 (was:SRv6)

James Bensley jwbensley+nanog at
Thu Sep 17 08:00:16 UTC 2020

On 16 September 2020 23:51:03 CEST, Robert Raszuk <robert at> wrote:
>Hi Ron,
>>  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
>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
>and software ... Why do we need to go via decks of SRm6 slides and new
>of protocols extensions ???

>> Please consider the TE mechanism described in
>> draft-bonica-6man-comp-rtg-hdr and the service labeling mechanism
>> in draft-bonica-6man-vpn-dest-opt. These can be deployed on a mix and
>> basis. For example can deploy:
>>    - Draft-bonica-6man-vpn-dest-opt only, allowing traffic to follow
>>    least-cost path from PE to PE.
>>    - Deploy draft-bonica-6man-vpn-dest-opt only, using a legacy
>>    (VXLAN, RFC 4797) to label services.
>> In all cases, the semantic of the IPv6 address is unchanged. There is
>> need to encode anything new in the IPv6 address.

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.


[1] I'm interested to hear if anyone has done any large scale MPLSoUDP work. Did you hack in this functionality with static egress interface entries/static routes pushed from a central controller for specific IPs reserve as "path" IPs?

More information about the NANOG mailing list