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 protected]>
Sent: Tuesday, July 09, 2019 4:03 PM
To: spring <[email protected]>; Linda Dunbar 
<[email protected]>; SPRING WG <[email protected]>; 徐小虎(义先) 
<[email protected]>
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

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

Cheers,
Jeff
On Jul 8, 2019, 11:45 PM -0700, 徐小虎(义先) 
<[email protected]<mailto:[email protected]>>, 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

------------------------------------------------------------------
From:Linda Dunbar 
<[email protected]<mailto:[email protected]>>
Send Time:2019年7月9日(星期二) 06:26
To:Linda Dunbar 
<[email protected]<mailto:[email protected]>>; SPRING WG 
<[email protected]<mailto:[email protected]>>
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:

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 protected]<mailto:[email protected]>> On 
Behalf Of Linda Dunbar
Sent: Monday, July 08, 2019 5:11 PM
To: SPRING WG <[email protected]<mailto:[email protected]>>
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%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.

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
_______________________________________________
spring mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to