SRm6 (was:SRv6)

Thu Sep 17 08:00:16 UTC 2020

On 16 September 2020 23:51:03 CEST, Robert Raszuk <robert at raszuk.net> 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
>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 ???
>
>Best,
>Robert.
>
>

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

Cheers,
James.

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