Martin, Thanks. I’d be glad if the discussion returns to charter contents and usual WG cooperation.
Work of TEAS should progress independently from Spring. My take of the TEAS WG is, that Traffic Engineering linked to RSVP TE is covered there. Spring policy routing isn’t linked to RSVP-TE signaling and I’m not aware of any requirement to add RSVP-TE signaling to Spring policy routing. To me, the following would make sense: * All aspects of Spring policy routing which are not linked to RSVP-TE signaling are pursued by an appropriately re-chartered Spring WG. * If terminology is an issue, SR “Traffic Engineering” to me can be replaced by “SR Policy Routing” or another suitable term. I’m interested in fast progress of the SR policy routing within Spring WG and I don’t want this progress to be blocked by words. * There’s a draft listed by Spring, but not by TEAS: https://www.ietf.org/id/draft-ietf-teas-sr-rsvp-coexistence-rec-02.txt . I think it describes how both approaches can coexist. * If there’s interest by the TEAS WG to work on solutions combining Spring and RSVP-TE signaling, then the TEAS Charter needs to be adapted. Spring or Segment Routing are not mentioned by it. I hope that Spring WG succeeds in re-chartering to cover all aspects of SR policy routing (excluding RSVP-TE signaling) and related OAM and TEAS can make progress on their chartered work items. I’d appreciate the usual IETF style cooperation of both WGs, if there’s an overlap on contents. Regards, Ruediger Von: spring [mailto:[email protected]] Im Auftrag von Martin Horneffer Gesendet: Mittwoch, 21. März 2018 07:21 An: [email protected] Cc: [email protected] Betreff: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion Having been told that my sentence about the TEAS charter was perceived as agressive I want to apologize for my exaggeration. That sentence should have better been something like: Reading the TEAS charter I felt personally insulted as it generally defines the term "traffic engineering", but in a way that doesn't allow for any other methodology but using RSVP. Apparently that feeling of insult made me choose aggressive words, which I shouldn't have used. It was not my intention to hurt anyone in return. Best regards, Martin Am 20.03.18 um 14:27 schrieb Martin Horneffer: +1 Or, to be more explicit, mentioning TEAS is - in my eyes - a major reason to insist in keeping the SPRING wg for a while, and for having the SRE-TE discussions here and not there!!! While it's always good to learn from each other, I strongly believe that moving any SR-TE discussion to TEAS would do nobody any good. As Dan pointed out, TEAS is about RSVP-TE. And it has a completely different way of approaching TE than what we want to do with SR. I really believe it's better to keep the different approaches to TE separate, rather than to coerce opposite minds to do their work in a joint forum, which most likely just leads to religious wars rather than anything productive. From my point of view, the TEAS charter even defines "traffic engineering" in a way which is completely ignorant and insulting. I don't feel like interfering with that, as long as everyone can still get their job done. But this tolerance wouldn't work any more if the SR-TE discussions would have to move there. Best regards, Martin P.S.: It's not like I was blindly ignorant towards RSVP-TE. In more than 15 years of experience with traffic engineering, I have used and accounted for RSVP more than once, in more than one or two independet IP/MPLS networks. Just recently I did recommend to use RSVP for specific use cases in a specific network. But I have the strong opinion that it's not the only solution for traffic engineering problems, and depending on the exact frame conditions it might not at all be the best overall solution. Am 19.03.18 um 11:42 schrieb Voyer, Daniel: [DV] see inlines From: spring <[email protected]><mailto:[email protected]> on behalf of "Shah, Himanshu" <[email protected]><mailto:[email protected]> Date: Sunday, March 18, 2018 at 9:23 PM To: Jeff Tantsura <[email protected]><mailto:[email protected]>, Daniel Bernier <[email protected]><mailto:[email protected]>, Bruno Decraene <[email protected]><mailto:[email protected]>, "[email protected]"<mailto:[email protected]> <[email protected]><mailto:[email protected]> Cc: "Alvaro Retana (aretana)" <[email protected]><mailto:[email protected]>, "[email protected]"<mailto:[email protected]> <[email protected]><mailto:[email protected]> Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion Agree with Jeff, without harping on all the good reasons already stated for SPRING WG charter extensions, I would think that it would be beneficial to leverage TE expertise from TEAS WG to progress SR-TE there for a cohesive, uniform solution for all tunneling schemes. [DV] 1- SRTE is NOT a tunnel. Labels are signals straight in the IGP, as known. This is why the word “policy” was introduce with SRTE – “SRTE Policy”. [DV] 2- According to TEAS WG charter - https://datatracker.ietf.org/wg/teas/about/: 1. Definition of additional abstract service, link, and path properties such as jitter, delay, and diversity. Extensions to IGPs to advertise these properties, and extensions to RSVP-TE to request and to accumulate these properties. [DV] 3- also notice in the SPRING Charter - https://datatracker.ietf.org/wg/spring/about/: o Some types of network virtualization, including multi- topology networks and the partitioning of network resources for VPNs o Network path and node protection such as fast re-route o Network programmability o New OAM techniques o Simplification and reduction of network signalling components o Load balancing and traffic engineering [DV] Hence I believe “SRTE policy” is a key component of the SR Architecture and should pursued as part as the Architecture definition milestone of the SPRING WG. Dan IMHO.. Thanks, Himanshu From: spring <[email protected]><mailto:[email protected]> on behalf of Jeff Tantsura <[email protected]><mailto:[email protected]> Date: Sunday, March 18, 2018 at 3:26 PM To: "Bernier, Daniel" <[email protected]><mailto:[email protected]>, "[email protected]"<mailto:[email protected]> <[email protected]><mailto:[email protected]>, "[email protected]"<mailto:[email protected]> <[email protected]><mailto:[email protected]> Cc: Alvaro Retana <[email protected]><mailto:[email protected]>, "[email protected]"<mailto:[email protected]> <[email protected]><mailto:[email protected]> Subject: [**EXTERNAL**] Re: [spring] SPRING - rechartering discussion Hi, I'm not going to repeat all the valid reasons to continue mentioned beforehand. There's definitely work to be done in architecture and O&M areas as well as co-ordination of various activities across IETF. Cheers, Jeff On 3/18/18, 13:23, "spring on behalf of Bernier, Daniel" <[email protected]<mailto:[email protected]> on behalf of [email protected]<mailto:[email protected]>> wrote: Hi, I echo the need to continue the SPRING work on service-chaining. There is a growing interest to have a mechanism that operates at the forwarding plane level using source routing as an alternative to a dedicated service overlay. This will surely generate other related work such as automated service discovery, inter-domain chaining policies, parallelism versus sequential chaining, various control-plane implementations, etc. Secondly, since there is a tight relation to SR chaining and TE policies, I believe there will is a lot of opportunities related to Path Awareness which is currently running in IRTF. Opportunities like, intent translation to SR policies, Policy requests or announcements between domains and host (probably app) level TE policy requests (e.g. how can an app receive a proper policy based on its requirements) ? My humble operator 0.02 cents. Daniel Bernier | Bell Canada ________________________________________ From: spring <[email protected]<mailto:[email protected]>> on behalf of [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Monday, March 5, 2018 11:59 AM To: [email protected]<mailto:[email protected]> Cc: Alvaro Retana (aretana); [email protected]<mailto:[email protected]> Subject: [spring] SPRING - rechartering discussion Hello WG, now that nearly all the core documents are in the hands of IESG or beyond, we think it is time to (re)discuss rechartering. We brought up that question few meetings ago and the feedback, at that time, was that the WG at least needs to be maintained to discuss the extensions following deployment feedback. But we need also identify technical directions. In order to initiate the discussion we are proposing some high level items but we'd like to make clear a few points before: * these are only proposals; what might end-up as the next steps for SPRING will be what the WG is willing to work on (which includes having cycles for that). * what the WG might be rechartered to do is not necessarily limited to that; so other proposals are welcome. So, we thought of the following: * general architectural work / extensions there are still few items on our plate and we expect that some might need to be progressed, and we should maybe allow for others to come. * service chaining last meeting there were proposals discussed in SPRING to realize some form of service chaining. any work in that space would require close coordination with SFC and maybe other WG. * yang we are a bit behind here and there is definitely work to do. So please comment on these and propose additional items. We'll likely have a dedicated slot in London but we'd like to progress before that. Thank you, --Martin, Rob, Bruno > -----Original Message----- > From: Martin Vigoureux [mailto:[email protected]] > Sent: Wednesday, March 29, 2017 4:25 PM > To: [email protected]<mailto:[email protected]> > Cc: [email protected]<mailto:[email protected]>; Alvaro Retana (aretana) > Subject: Next steps for SPRING? > > WG, > > in the session we have opened the discussion on the future of the WG, > putting all options on the table (recharter/close/sleep). > As a foreword, we still have few WG Documents that we need to -and will- > push towards IESG (and a greater number that need to reach RFC status), > but with those we'll have reached most if not all of our milestones, > thus the question on what's next. > > So, we think we have heard during the session that closing wasn't > desired and one reason for that is to have a home to share and discuss > deployment considerations as the technology gets deployed. > There are also a few individual documents knocking at the door, and some > of them were presented during the session. > > To reach out to everyone, we are thus asking the question on the list. > We would like to hear from you all what the working group should be > focussing on. > > Note, the expectation is that future items should not be use-cases but > rather be technology extensions/evolutions. > > Thank you > > Martin & Bruno _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ spring mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
