+1 take a look at draft-ietf-mpls-sr-over-ip
Cheers, Jeff On Jul 8, 2019, 11:45 PM -0700, 徐小虎(义先) <[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 > > Best regards, > Xiaohu > > > ------------------------------------------------------------------ > > From:Linda Dunbar <[email protected]> > > Send Time:2019年7月9日(星期二) 06:26 > > To:Linda Dunbar <[email protected]>; SPRING WG <[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]> On Behalf Of Linda Dunbar > > Sent: Monday, July 08, 2019 5:11 PM > > To: SPRING WG <[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/ > > 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] > https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
