Re: SRm6 (was:SRv6)

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

On 16 September 2020 23:51:03 CEST, Robert Raszuk <robert () 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?