Rob, You said: 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.
Just want to make sure that I understand the term “define new applications” used in the SPRING charter wording: We have a draft describing using SR to steer a SD-WAN path over desired network segments ( https://www.ietf.org/internet-drafts/draft-dunbar-sr-sdwan-over-hybrid-networks-01.txt ). Will our draft be considered as the “new applications” in SPRING charter? Thanks, Linda Dunbar. From: Rob Shakir [mailto:ro...@google.com] Sent: Sunday, June 03, 2018 4:32 PM To: Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> Cc: Jeff Tantsura <jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>; SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>> Subject: Re: [spring] Updating the SPRING WG Charter Hi Linda, On Fri, Jun 1, 2018 at 12:35 PM Linda Dunbar <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> 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 spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
