Robert, Absolutely nothing. In fact, that is very close to what we had in mind in RFC 4797. But couldn't the same argument be used with regard to SRv6 when the network operator wants traffic to take the least-cost path from PE to PE? Ron Juniper Business Use Only From: Robert Raszuk <robert@raszuk.net> Sent: Wednesday, September 16, 2020 5:51 PM To: Ron Bonica <rbonica@juniper.net> Cc: nanog@nanog.org Subject: Re: SRm6 (was:SRv6) [External Email. Be cautious of content] 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. On Wed, Sep 16, 2020 at 10:17 PM Ron Bonica via NANOG <nanog@nanog.org<mailto:nanog@nanog.org>> wrote: Folks, If you want an IPv6 underlay for a network offering VPN services, it makes sense to: * Retain RFC 4291 IPv6 address semantics * Decouple the TE mechanism from the service labeling mechanism 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. Ron Juniper Business Use Only