Hi Rob,
A bit late but +1 to Zafar's and Linda's comments on adding overlay/app interaction with underlay in the WG charter. I presented at last IETF in PANRG (ref: https://datatracker.ietf.org/meeting/101/materials/slides-101-panrg-service-aware-networking-using-segment-routing-00) on this topic and I do think there is potential for a lot of extensions with regards to inter-carrier SR policy awareness and how it interacts at the host/app level as well. Cheers, Daniel Bernier ________________________________ From: spring <[email protected]> on behalf of Zafar Ali (zali) <[email protected]> Sent: Wednesday, June 6, 2018 2:41 PM To: Rob Shakir; Linda Dunbar Cc: Jeff Tantsura; Zafar Ali (zali); SPRING WG List Subject: Re: [spring] Updating the SPRING WG Charter Hi Rob, Re: Linda comment on SR assisted SD-WAN. At IETF101, Bruno and you presented a slide based on the WG feedback on the mailing list (https://datatracker.ietf.org/meeting/101/materials/slides-101-spring-00-chairs-slides-01). During the Spring meeting, the WG agreed to add milestones against those items. In general, I see some milestones are not included in the proposed chartered text. In the context of Linda’s feedback, the slide has the following text (with support during the WG meeting): * Interactions between overlay/applications and optimized underlay * E.g. SR-assisted SD-WAN, path awareness We should add a milestone for specification of architecture, and the required protocol extensions for Segment Routing for interactions between overlay/ applications and optimized SR underlay MPLS and IPv6 data planes. I fully agree with you that the actual protocol extension work will be done at the WG that owns the protocol. Thanks Regards … Zafar From: spring <[email protected]> on behalf of Rob Shakir <[email protected]> Date: Sunday, June 3, 2018 at 5:32 PM To: Linda Dunbar <[email protected]> Cc: Jeff Tantsura <[email protected]>, SPRING WG List <[email protected]> Subject: Re: [spring] Updating the SPRING WG Charter Hi Linda, On Fri, Jun 1, 2018 at 12:35 PM Linda Dunbar <[email protected]<mailto:[email protected]>> wrote: The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6). [jeff] I’d add “dataplanes” SPRING WG serves as a forum to discuss SPRING networks operations, define new applications, and specify extensions of Segment Routing technologies. [Linda] Does the “new applications” in the sentence above refer to the “Use cases” for SPRING? Is the “Extensions” being discussed in SPRING also include the “extensions” to other protocols? robjs> The aim here is to define that SPRING is where we discuss new things that are done with SR. I don't think we want to constrain things to say that only use-case work is done in SPRING (actually, we've had little success with a number of the use case documents). The extensions referred to are extensions to SR technologies.. Per the later wording in the charter, the intention here is to clarify that functional specifications for those extensions can be done in SPRING, but the actual extension work is owned by the WG that owns that technology. robjs> You can imagine the SR-TE policy work breaks down this way: we discuss the "application" which is steering traffic onto sets of SR paths, and define a functional specification document for how that works. If that is realised in BGP (as it is being today), IDR owns the protocol specification, if it's in PCEP, then it's done in that WG. *snip* o Source-routed stateless service chaining using SR-MPLS and SRv6 dataplanes. [Linda] o Source-routed stateless SD-WAN paths traversing through SR domain (i.e. SR as part of SD-WAN’s underlay network) robjs> Our focus here is to provide a constrained set of areas where there is a need for work within SPRING. The discussions that we had in the working group in London were focused around capturing the set of technologies that have strong support and folks to work on. If we have new proposals around this work, then we can always consider working on them if they need extensions to the SR architecture. At the moment, the preference is to keep this list constrained such that we can focus the working group. *snip* o The inter-working between SRv6 and SR-MPLS. [Linda] o The inter-working between SR and legacy networks (which is far more likely than SRv6 & SR-MPLS interworking) robjs> The LDP interop draft is something that is going to the IESG at the moment. There is existing work in TEAS (in WGLC) that covers co-existence of RSVP-TE and SR. Are there specific areas that we have gaps? The reason that we call out SRv6/SR-MPLS interop is that there has been some discussion of this, and we have not got an answer for this yet. Thanks for the comments. Kind regards, r.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
