Linda, In context of draft-ietf-mpls-sr-over-ip it would be IP->SRinUDP->SR-native-> SRinUDP->IP
Cheers, Jeff On Jul 18, 2019, 9:16 AM -0700, Linda Dunbar <[email protected]>, wrote: > 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 protected]> > Sent: Monday, July 15, 2019 5:48 PM > To: spring <[email protected]>; SPRING WG <[email protected]>; 徐小虎(义先) > <[email protected]>; Linda Dunbar <[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? > > 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
