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 On Jul 15, 2019, 3:24 PM -0700, Linda Dunbar <[email protected]>, wrote: > > 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]>, 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
