Subject: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

From: Linda Dunbar <[email-masked]>
Date: Mon, 8 Jul 2019 22:11:11 +0000

SD-WAN, as described by ONUG (Open Network User Group), is about pooling WAN bandwidth from multiple service providers to get better WAN bandwidth management, visibility & control.
Because of the ephemeral property of the selected Cloud DCs, an enterprise or its network service provider may not have the direct links to the Cloud DCs that are optimal for hosting the enterprise's specific workloads/Apps. Under those circumstances, SD-WAN is a very flexible choice to interconnect the enterprise on-premises data centers & branch offices to its desired Cloud DCs.
However, SD-WAN paths over public internet can have unpredictable performance, especially over long distances and cross state/country boundaries. Therefore, it is highly desirable to place as much as possible the portion of SD-WAN paths over service provider VPN (e.g. enterprise's existing VPN) that have guaranteed SLA and to minimize the distance/segments over public internet.

https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/ describes a method to enforce a SD-WAN path's head-end selected route traversing through a list of specific nodes of multiple network segments without requiring the nodes in each network segments to have the intelligence (or maintaining states) of selecting next hop or next segments.

When a SR domain has multiple PEs with ports facing the external networks (such as the public internet or LTE termination), SD-WAN paths can traverse the SR domain via different ingress/egress PEs resulting in different E2E performance.

Even with the same ingress/egress, some flows may need different segments across the SR Domain. It is not practical, or even possible, for PEs to determine which Apps' flows should egress.
Segment Routing can be used to steer packets (or path) to traverse the explicit egress node, or explicit segments through the SR Domain based on the SLA requested by the SD-WAN head-end nodes.

When the SDWAN edge nodes are directly connected to the PEs of SR domain, is it appropriate for SDWAN edge nodes to use GRE/VxLAN header bits to indicate the desired SR Path?

We are looking for feedback, criticisms, or suggestion on the the proposed approach.

Thank you,
Linda

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 8 Jul 2019 22:21:36 +0000

Sorry, I meant to ask:

When the SDWAN edge nodes are NOT directly connected to the PEs of SR domain, is it appropriate for SDWAN edge nodes to use GRE/VxLAN header bits to indicate the desired SR Path?

Linda

From: spring <[email-masked]> On Behalf Of Linda Dunbar
Sent: Monday, July 08, 2019 5:11 PM
To: SPRING WG <[email-masked]>
Subject: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

SD-WAN, as described by ONUG (Open Network User Group), is about pooling WAN bandwidth from multiple service providers to get better WAN bandwidth management, visibility & control.
Because of the ephemeral property of the selected Cloud DCs, an enterprise or its network service provider may not have the direct links to the Cloud DCs that are optimal for hosting the enterprise's specific workloads/Apps. Under those circumstances, SD-WAN is a very flexible choice to interconnect the enterprise on-premises data centers & branch offices to its desired Cloud DCs..
However, SD-WAN paths over public internet can have unpredictable performance, especially over long distances and cross state/country boundaries. Therefore, it is highly desirable to place as much as possible the portion of SD-WAN paths over service provider VPN (e.g. enterprise's existing VPN) that have guaranteed SLA and to minimize the distance/segments over public internet.

https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-sr-sdwan-over-hybrid-networks%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C1538194078e5452339f108d703f1c90c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636982209309189471&sdata=xnGEOr4OENlRDmgfwT4sWiDIHALPOuKFke%2FELyXsmG4%3D&reserved=0> describes a method to enforce a SD-WAN path's head-end selected route traversing through a list of specific nodes of multiple network segments without requiring the nodes in each network segments to have the intelligence (or maintaining states) of selecting next hop or next segments.

Thank you,
Linda

---

From: "徐小虎(义先)" <[email-masked]>
Date: Tue, 09 Jul 2019 14:45:19 +0800

Hi Linda,

Why not directly use the MPLSoUDP encapsulation to carry the B-SID label so as to indicate the preferred path? For more details, please read https://tools.ietf.org/html/draft-dukes-spring-sr-for-sdwan-02#section-7.3

Best regards,
Xiaohu

------------------------------------------------------------------
From:Linda Dunbar <[email-masked]>
Send Time:2019年7月9日(星期二) 06:26
To:Linda Dunbar <[email-masked]>; SPRING WG <[email-masked]>
Subject:Re: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

Sorry, I meant to ask:
 
Linda
From: spring <[email-masked]> On Behalf Of Linda Dunbar
Sent: Monday, July 08, 2019 5:11 PM
To: SPRING WG <[email-masked]>
Subject: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?  
SD-WAN, as described by ONUG (Open Network User Group), is about pooling WAN bandwidth from multiple service providers to get better WAN bandwidth management, visibility & control. 
Because of the ephemeral property of the selected Cloud DCs, an enterprise or its network service provider may not have the direct links to the Cloud DCs that are optimal for hosting the enterprise’s specific workloads/Apps. Under those circumstances, SD-WAN is a very flexible choice to interconnect the enterprise on-premises data centers & branch offices to its desired Cloud DCs...
However, SD-WAN paths over public internet can have unpredictable performance, especially over long distances and cross state/country boundaries. Therefore, it is highly desirable to place as much as possible the portion of SD-WAN paths over service provider VPN (e.g. enterprise’s existing VPN) that have guaranteed SLA and to minimize the distance/segments over public internet.
https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/ describes a method to enforce a SD-WAN path’s head-end selected route traversing through a list of specific nodes of multiple network segments without requiring the nodes in each network segments to have the intelligence (or maintaining states) of selecting next hop or next segments.
When a SR domain has multiple PEs with ports facing the external networks (such as the public internet or LTE termination), SD-WAN paths can traverse the SR domain via different ingress/egress PEs resulting in different E2E performance. 
 
Even with the same ingress/egress, some flows may need different segments across the SR Domain. It is not practical, or even possible, for PEs to determine which Apps’ flows should egress. 
Segment Routing can be used to steer packets (or path) to traverse the explicit egress node, or explicit segments through the SR Domain based on the SLA requested by the SD-WAN head-end nodes.

 
Thank you, 
Linda

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 9 Jul 2019 15:01:52 +0000

Xiao Hu,

Thank you very much for the suggestion. If the SDWAN edge node supports MPLS, MPLSoUDP is definitely a good choice. I will add it to the document.
When an SDWAN edge nodes doesn’t support MPLS,  any other suggestions in addition to GRE or VxLAN?

Linda

From: 徐小虎(义先) <[email-masked]>
Sent: Tuesday, July 09, 2019 1:45 AM
To: spring <[email-masked]>; Linda Dunbar <[email-masked]>; SPRING WG <[email-masked]>
Subject: Re: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

Hi Linda,

Why not directly use the MPLSoUDP encapsulation to carry the B-SID label so as to indicate the preferred path? For more details, please read https://tools.ietf.org/html/draft-dukes-spring-sr-for-sdwan-02#section-7.3<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dukes-spring-sr-for-sdwan-02%23section-7.3&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C2d347a69022c4c1b9bbc08d70439049d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C636982515250840448&sdata=g%2F1eMkVoC9OtHP71TdtalD0qGJ2L0z6yTg8Wg634CDI%3D&reserved=0>

Best regards,
Xiaohu

------------------------------------------------------------------
From:Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Send Time:2019年7月9日(星期二) 06:26
To:Linda Dunbar <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject:Re: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

Sorry, I meant to ask:

Linda

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Linda Dunbar
Sent: Monday, July 08, 2019 5:11 PM
To: SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-sr-sdwan-over-hybrid-networks%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C2d347a69022c4c1b9bbc08d70439049d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C636982515250840448&sdata=cPBlLhmj81J9T7d6k1khbnP33gQZwEOPCy0FYwn5U7s%3D&reserved=0> describes a method to enforce a SD-WAN path’s head-end selected route traversing through a list of specific nodes of multiple network segments without requiring the nodes in each network segments to have the intelligence (or maintaining states) of selecting next hop or next segments.

Thank you,
Linda

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 9 Jul 2019 14:02:53 -0700

+1

take a look at draft-ietf-mpls-sr-over-ip

Cheers,
Jeff
On Jul 8, 2019, 11:45 PM -0700, 徐小虎(义先) <[email-masked]>, wrote:
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 15 Jul 2019 22:24:13 +0000

Jeff,

The draft-ietf-mpls-sr-over-ip only has MPLS packets being tunneled by IP, but not reversed (IP packets tunneled over MPLS).

Do you think it worthwhile to add some similar sections (of course with different content), such as Forwarding entry Construction, forwarding procedures as in draft-ietf-mpls-sr-over-ip?

Linda

From: Jeff Tantsura <[email-masked]>
Sent: Tuesday, July 09, 2019 4:03 PM
To: spring <[email-masked]>; Linda Dunbar <[email-masked]>; SPRING WG <[email-masked]>; 徐小虎(义先) <[email-masked]>
Subject: Re: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

+1

Cheers,
Jeff
On Jul 8, 2019, 11:45 PM -0700, 徐小虎(义先) <[email-masked]<mailto:[email-masked]>>, wrote:

Hi Linda,

Why not directly use the MPLSoUDP encapsulation to carry the B-SID label so as to indicate the preferred path? For more details, please read https://tools.ietf.org/html/draft-dukes-spring-sr-for-sdwan-02#section-7.3<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dukes-spring-sr-for-sdwan-02%23section-7.3&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cf52fb4f3cd9849504fca08d704b0d42f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C636983029839380080&sdata=rORtMbo%2FgwAi1PypRoiiRcKkw%2ByLqhvgLKKqnetp5jA%3D&reserved=0>

Best regards,
Xiaohu

Sorry, I meant to ask:

Linda

https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-sr-sdwan-over-hybrid-networks%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cf52fb4f3cd9849504fca08d704b0d42f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C636983029839390078&sdata=aiQ6DE4Cq9Y1J%2B%2FsfbHNwlRblnBYB%2BDDaqGXs1CZBIw%3D&reserved=0> describes a method to enforce a SD-WAN path’s head-end selected route traversing through a list of specific nodes of multiple network segments without requiring the nodes in each network segments to have the intelligence (or maintaining states) of selecting next hop or next segments.

Thank you,
Linda
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 15 Jul 2019 15:48:08 -0700

Linda,

What you want is to use native MPLS when available and encapsulate MPLS packets in IP/UDP when you need to travers IP, you destination in the imposed IP header would be that of the next SR capable device as described in draft-ietf-mpls-sr-over-ip.

Cheers,
Jeff

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 18 Jul 2019 16:16:02 +0000

Jeff,

For SDWAN case, the Source node and Destination nodes (a.k.a. SDWAN edge nodes) are IP based.

So it should be reversed, IP segments -> SR segments which include both SRv6 & MPLS-SR -> IP segments

Linda

From: Jeff Tantsura <[email-masked]>
Sent: Monday, July 15, 2019 5:48 PM
To: spring <[email-masked]>; SPRING WG <[email-masked]>; 徐小虎(义先) <[email-masked]>; Linda Dunbar <[email-masked]>
Subject: RE: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

Linda,

Cheers,
Jeff
On Jul 15, 2019, 3:24 PM -0700, Linda Dunbar <[email-masked]<mailto:[email-masked]>>, wrote:

Jeff,

Linda

From: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, July 09, 2019 4:03 PM
To: spring <[email-masked]<mailto:[email-masked]>>; Linda Dunbar <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>; 徐小虎(义先) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

+1

Cheers,
Jeff

Why not directly use the MPLSoUDP encapsulation to carry the B-SID label so as to indicate the preferred path? For more details, please read https://tools.ietf.org/html/draft-dukes-spring-sr-for-sdwan-02#section-7.3<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dukes-spring-sr-for-sdwan-02%23section-7.3&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Ce2ef92e9de2143db0be208d709768846%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636988277015484955&sdata=hasaujqJuyv%2FvF2rnj8Gv%2FM%2BUVAUN5q2A6djQQBvl5g%3D&reserved=0>

Best regards,
Xiaohu

Sorry, I meant to ask:

Linda

https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-sr-sdwan-over-hybrid-networks%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Ce2ef92e9de2143db0be208d709768846%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636988277015484955&sdata=oPw5CZJK%2BtRB68%2FbGa9m%2BIhS8WgweEIb1Ne2yIRGnkY%3D&reserved=0> describes a method to enforce a SD-WAN path’s head-end selected route traversing through a list of specific nodes of multiple network segments without requiring the nodes in each network segments to have the intelligence (or maintaining states) of selecting next hop or next segments.

Thank you,
Linda
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Ce2ef92e9de2143db0be208d709768846%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636988277015494945&sdata=Fd1INBJQ4sjPR43b425zROXFlvrw%2BYQ3f%2FeCHh31Q6o%3D&reserved=0>

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 18 Jul 2019 12:25:21 -0700

Linda,

In context of draft-ietf-mpls-sr-over-ip it would be IP->SRinUDP->SR-native-> SRinUDP->IP

Cheers,
Jeff

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 19 Jul 2019 00:09:23 +0000

Jeff,

There are several scenarios (which have been documented in the draft):
One scenario has SDWAN edge node not directly attached to SR edge. The draft is suggesting VxLAN or GRE to connect the SDWAN edge and the SR edge.

Linda

From: Jeff Tantsura <[email-masked]>
Sent: Thursday, July 18, 2019 2:25 PM
To: spring <[email-masked]>; SPRING WG <[email-masked]>; 徐小虎(义先) <[email-masked]>; Linda Dunbar <[email-masked]>
Subject: RE: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

Linda,

Cheers,
Jeff
On Jul 18, 2019, 9:16 AM -0700, Linda Dunbar <[email-masked]<mailto:[email-masked]>>, wrote:

Jeff,

Linda

From: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Sent: Monday, July 15, 2019 5:48 PM
To: spring <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>; 徐小虎(义先) <[email-masked]<mailto:[email-masked]>>; Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

Linda,

Cheers,
Jeff

Jeff,

Linda

+1

Cheers,
Jeff

Why not directly use the MPLSoUDP encapsulation to carry the B-SID label so as to indicate the preferred path? For more details, please read https://tools.ietf.org/html/draft-dukes-spring-sr-for-sdwan-02#section-7.3<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dukes-spring-sr-for-sdwan-02%23section-7.3&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C35aa8f8c9b52469f571d08d70bb5b13f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636990747306731132&sdata=UtxB8Z%2B02FON9fBh%2BmVuqo5P3xGCHUb0Bf%2BfSKFFr2M%3D&reserved=0>

Best regards,
Xiaohu

Sorry, I meant to ask:

Linda

https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-sr-sdwan-over-hybrid-networks%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C35aa8f8c9b52469f571d08d70bb5b13f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636990747306731132&sdata=8CVcqS8etMqWdTox%2Bb06vqdz50CWaGrSReYvhEgaKlo%3D&reserved=0> describes a method to enforce a SD-WAN path’s head-end selected route traversing through a list of specific nodes of multiple network segments without requiring the nodes in each network segments to have the intelligence (or maintaining states) of selecting next hop or next segments.

Thank you,
Linda
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C35aa8f8c9b52469f571d08d70bb5b13f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636990747306741126&sdata=A%2BzLqLHwneKW95DdSu7XwnEKlCNhsARJ4TYLDGR042Y%3D&reserved=0>

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 19 Jul 2019 12:13:07 -0700

Linda,

We are not converging, please read the draft.

Note - SRinUDP doesn’t require device that imposes the SIDs to the device that encapsulates it in IP/UDP, neither should it be directly connected.
SR allows you to encode the desired  path in data plane, either directly, by imposing 1 or more SID’s, where the bottom one if the destination, or by encoding meta-data in a Binding SID, when BSID gets lookup up by the anchor node (device that own the BSID) - SR Edge in your case, it would expand BSID into a full path or a combination of BSID’s and NSIDs  (AKA segmented path).
In your case specifically and in a most simple way - SDWAN edge would be programmed to impose a SID stack that is: dest->BSID (desired SR path - could have another level(s) of indirections)->SR edge. As per draft-ietf-mpls-sr-over-ip - IP/UDP header would be imposed with DIP of SR edge (that is also the anchor for BSID) and DPORT set to 6635 (RFC7510), there are also other ways to resolve desired SR path on demand (BGP, PCEP, etc). Note you need co-operation between WAN (SR) controller and SDWAN controller.

There’s absolutely no need to (ab)using GRE/VxLAN header bits.

Please let me know if anything is still unclear, we could also meet in Montreal.

Cheers,
Jeff