+1. SR-Policy is part of SPRING Charter. Sent from my iPhone
> On Mar 21, 2018, at 1:45 AM, Kamran Raza (skraza) <[email protected]> wrote: > > +1 > > I also believe that SR-policy falls under the charter of SPRING WG and not > TEAS. > Thx > -- > Kamran > > From: spring <[email protected]> on behalf of Robert Raszuk > <[email protected]> > Date: Tuesday, March 20, 2018 at 11:59 PM > To: "Darren Dukes (ddukes)" <[email protected]> > Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> > Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion > > All, > > I am not even sure why do we need to discuss applicability of SR-TE to TEAS > WG ... Who started that idea ? > > TEAS WG charter states: > > " The Traffic Engineering Architecture and Signaling (TEAS) Working > Group is responsible for defining MPLS and GMPLS traffic > engineering architecture ... " > > > SR TE or for that matter BGP TE (by adjusting BGP policies via BGP > attributes) or OSPF/ISIS TE (by adjusting IGP metrics) have nothing to do > with MPLS or GMPLS. So it should be pretty obvious for those even not very > much skilled with that art that this entire discussion is a classic red > herring and it should be stopped and archived ASAP. > > > Kind regards, > Robert. > > > > On Wed, Mar 21, 2018 at 12:45 AM, Darren Dukes (ddukes) <[email protected]> > wrote: > +1 for Paul, Martin, Dan on SR TE. I tried to type up something beyond what > you’ve said, but deleted it… > > I think you’ve hit the nail on the head. > > As an coder of SR TE Policy, I can confirm that it is as far away from > RSVP-TE as possible. > > Darren > > > On Mar 20, 2018, at 2:45 PM, Paul Mattes <[email protected]> wrote: > > I do not know a great deal about the inner workings of the TEAS WG. I have no > doubt that the TE activities inside the SPRING WG could benefit from close > collaboration with TEAS. On the other hand, SR-TE has evolved as a quite > different approach from the distributed RSVP-TE architecture -- something > that makes it very attractive as a replacement for RSVP-TE in our application. > > Could the TEAS charter be generalized to include this approach (as it would > apparently need to be)? Sure. Would separating SR-TE from a WG completing a > coherent SR architecture help or hinder it? It would hinder it, I fear, > because it might go from being one of the things that really fulfills the > promise of SR to being an uncomfortable step-child of a broader traffic > engineering effort. > > (I would love to hear the opposite argument – that many in the TEAS WG would > like to build on SR-TE policy and its approach as a way to move TE forward. > Might that be true?) > > pdm > > From: spring <[email protected]> On Behalf Of Voyer, Daniel > Sent: Monday, March 19, 2018 6:42 AM > To: Shah, Himanshu <[email protected]>; Jeff Tantsura > <[email protected]>; Bernier, Daniel <[email protected]>; > [email protected]; [email protected] > Cc: Alvaro Retana (aretana) <[email protected]>; [email protected] > > Subject: Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion > > [DV] see inlines > > From: spring <[email protected]> on behalf of "Shah, Himanshu" > <[email protected]> > Date: Sunday, March 18, 2018 at 9:23 PM > To: Jeff Tantsura <[email protected]>, Daniel Bernier > <[email protected]>, Bruno Decraene <[email protected]>, > "[email protected]" <[email protected]> > Cc: "Alvaro Retana (aretana)" <[email protected]>, "[email protected]" > <[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]> on behalf of Jeff Tantsura > <[email protected]> > Date: Sunday, March 18, 2018 at 3:26 PM > To: "Bernier, Daniel" <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" <[email protected]> > Cc: Alvaro Retana <[email protected]>, "[email protected]" > <[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] on behalf of [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]> on behalf of > [email protected] <[email protected]> > Sent: Monday, March 5, 2018 11:59 AM > To: [email protected] > Cc: Alvaro Retana (aretana); [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] > > Cc: [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] > https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring > > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring > > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
