Re: SRm6 (was:SRv6)
MPLSoUDP is not the technology you should be looking at, SRoUDP (RFC8663) is. draft-bookham-rtgwg-nfix-arch describes an architecture that makes use of it to provide an end2end SR path. Cheers, Jeff On Sep 17, 2020, 9:32 AM -0700, James Bensley , wrote: > > > On 17 September 2020 11:05:24 CEST, Saku Ytti wrote: > > On Thu, 17 Sep 2020 at 11:03, James Bensley > > wrote: > > > > > 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 > > abstraction/tunnel. > > 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 ??? > > > Cheers, > James.
Re: SRm6 (was:SRv6)
On 17 September 2020 11:05:24 CEST, Saku Ytti wrote: >On Thu, 17 Sep 2020 at 11:03, James Bensley >wrote: > >> 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 >abstraction/tunnel. 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 ??? Cheers, James.
Re: SRm6 (was:SRv6)
Spot on. And on the point of protection ... in all cases it is orthogonal to the service itself. If you want to use it you enable it regardless if your packet's transport is IPv4, IPv6, MPLS or any SR flavor. Sure if you need to traffic engineer your services some form of path control is required. It can be stack of SIDs, it can be pre-signalled paths or it can be pure encap-decap on selected anchor points. Your network - your choice. Thx, R. On Thu, Sep 17, 2020 at 11:07 AM Saku Ytti wrote: > On Thu, 17 Sep 2020 at 11:03, James Bensley > wrote: > > > 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 > abstraction/tunnel. > > -- > ++ytti >
Re: SRm6 (was:SRv6)
On Thu, 17 Sep 2020 at 11:03, James Bensley wrote: > 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 abstraction/tunnel. -- ++ytti
Re: SRm6 (was:SRv6)
On 16 September 2020 23:51:03 CEST, Robert Raszuk 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?
RE: SRm6 (was:SRv6)
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 Sent: Wednesday, September 16, 2020 5:51 PM To: Ron Bonica 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 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
Re: SRm6 (was:SRv6)
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 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 >
SRm6 (was:SRv6)
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
