> On May 16, 2017, at 4:24 PM, Alexander Vainshtein > <alexander.vainsht...@ecitele.com> wrote: > > Stefano, > Lots of thanks for a prompt response. > > > I will borrow the quantum mechanics terminology that differentiates between > pure and mixed (a.k.a. superposition) states of a quantum system.
I have nothing against quantum mechanics. Even more, I’d really encourage anyone to study this wonderful aspects of our universe. Having said that, I’d remind you that ietf is about engineering, not science and we’re not here to list any possible combination of components that we describe in a drafts. We’re here to address REAL problems and REAL requirements expressed by the industry that, at the end of the day, deploy and operate what we define and implement. According to all the comments I’ve seen on this read, it looks to me the WG is inline with this and it doesn’t appear to me (please correct if I’m wrong) that there’s any consensus in extending the list of requirements of the resiliency use-cases draft. Thanks. s. PS: nothing prevents you to cook a pizza with ham and chocolate... but that’s not a valid reason to do it... > > As long as "mixed" use cases are not strictly prohibited in the draft (and > this was at least one possible interpretation of the text), I do not have any > issues with restricting it to just two "pure" use cases: > - End-to-end path protection with disabled local protection > - Local protection (of some kind) without end-to-end path protection. > > This would leave the question about operational value and complexity of > "superposition" use cases open for further discussion. > > Does this correctly reflect your intentions? > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: alexander.vainsht...@ecitele.com > > > -----Original Message----- > From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] > Sent: Tuesday, May 16, 2017 5:01 PM > To: Stephane Litkowski <stephane.litkow...@orange.com> > Cc: Alexander Vainshtein <alexander.vainsht...@ecitele.com>; spring@ietf.org; > Shell Nakash <shell.nak...@ecitele.com>; Michael Gorokhovsky > <michael.gorokhov...@ecitele.com>; > draft-ietf-spring-resiliency-use-ca...@ietf.org; Sidd Aanand > <sidd.aan...@ecitele.com>; Ron Sdayoor <ron.sday...@ecitele.com>; Rotem Cohen > <rotem.co...@ecitele.com> > Subject: Re: [spring] A belated comment on end-to-end path protection in > draft-ietf-spring-resiliency-use-cases > > Hi Stephane, > > >> On May 16, 2017, at 11:29 AM, stephane.litkow...@orange.com wrote: >> >> Hi, >> >> I think there is a misunderstanding on what the text says: >> “ A first protection strategy consists in excluding any local repair >> >> but instead use end-to-end path protection where each SPRING path >> is >> >> protected by a second disjoint SPRING path. In this case local >> >> protection MUST NOT be used. >> >> “ >> >> The text presents a design option which is to use end-to-end path protection >> and prevent any local-repair. In this option (the text mention: “In this >> case”), for sure, we need to prohibit local protection as this is the >> requirement of this design option. > > > I agree. > > >> Now if you want to combine end-to-end protection + local protection, that’s >> up to you and that’s another design option. IMO, I would not push for this >> combined design as it brings more complexity rather than solving problems, >> but it’s a personal design opinion. > > > I agree. > > I would add the precision that such option is NOT what the authors of the > draft had in mind so I’d suggest to anyone promoting such option to come with > some realistic operational requirements. > > Thanks. > s. > > >> >> Brgds, >> >> >> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander >> Vainshtein >> Sent: Tuesday, May 16, 2017 10:29 >> To: Stefano Previdi (sprevidi) >> Cc: spring@ietf.org; Shell Nakash; Michael Gorokhovsky; >> draft-ietf-spring-resiliency-use-ca...@ietf.org; Sidd Aanand; Ron >> Sdayoor; Rotem Cohen >> Subject: Re: [spring] A belated comment on end-to-end path protection >> in draft-ietf-spring-resiliency-use-cases >> >> >> >> Regards, >> Sasha >> >> Office: +972-39266302 >> Cell: +972-549266302 >> Email: alexander.vainsht...@ecitele.com >> >> From: Alexander Vainshtein >> Sent: Tuesday, May 16, 2017 11:28 AM >> To: 'Stefano Previdi (sprevidi)' <sprev...@cisco.com> >> Cc: draft-ietf-spring-resliency-use-ca...@ietf.org; spring@ietf.org; >> Shell Nakash <shell.nak...@ecitele.com>; Michael Gorokhovsky >> <michael.gorokhov...@ecitele.com>; Sidd Aanand >> <sidd.aan...@ecitele.com>; Ron Sdayoor <ron.sday...@ecitele.com>; >> Rotem Cohen <rotem.co...@ecitele.com> >> Subject: RE: [spring] A belated comment on end-to-end path protection >> in draft-ietf-spring-resiliency-use-cases >> >> Stefano, >> Lots of thanks for a prompt response. >> >> A couple of short comments if you do not mind: >> >> Using 2119 language in a "use cases" document: >> 1. Going back to the source I see that “MUST NOT… mean that the >> definition is an absolute prohibition of the specification” >> 2. I agree that the use case document defines which scenarios should >> be addressed, but I do not see how it can impose an absolute prohibition on >> a certain scenario. >> >> Little sense link protection has in the case of path protection: >> 1. This was definitely correct for traditional traffic engineering >> because the “shortest traffic paths” (e.g., LDL PSPs) could be easily >> differentiated from the “engineered traffic paths”. >> 2. In addition, traditional local protection (e.g., MPLS FRR using >> RSVP-TE) could deal with link and node failures regardless of whether the >> failed link or node appeared in the ERO of the protected path. >> 3. IMHO and FWIW, with SR the situation is quite different: >> o The shortest traffic paths not only coexist with engineered traffic >> paths: the latter are in many cases “tunneled” within the former. >> o Path protection cannot be applied to shortest traffic paths so they must >> rely on local protection >> o Local protection in the case of failure of a node or link that appears >> in the ERO of an engineered SR path is highly non-trivial at best, so path >> protection for the engineered LSPs looks like a preferred solution to me. >> I fully agree with you that the operators deploying SR should provide >> feedback on this point based on actual operational experience. >> Meanwhile I doubt that a priori declaring some use cases as absolutely >> prohibited is the right thing to do. >> >> My 2c, >> Sasha >> >> Office: +972-39266302 >> Cell: +972-549266302 >> Email: alexander.vainsht...@ecitele.com >> >> >> -----Original Message----- >> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] >> Sent: Monday, May 15, 2017 11:12 AM >> To: Alexander Vainshtein <alexander.vainsht...@ecitele.com> >> Cc: draft-ietf-spring-resliency-use-ca...@ietf.org; spring@ietf.org; >> Shell Nakash <shell.nak...@ecitele.com>; Michael Gorokhovsky >> <michael.gorokhov...@ecitele.com>; Sidd Aanand >> <sidd.aan...@ecitele.com>; Ron Sdayoor <ron.sday...@ecitele.com>; >> Rotem Cohen <rotem.co...@ecitele.com> >> Subject: Re: [spring] A belated comment on end-to-end path protection >> in draft-ietf-spring-resiliency-use-cases >> >> >>> On May 11, 2017, at 12:04 PM, Alexander Vainshtein >>> <alexander.vainsht...@ecitele.com> wrote: >>> >>> Hi all, >>> I have a belated (but hopefully late is still better than never) comment on >>> path protection as defined in Section 2 of the draft. >>> >>> This second para in this section says: >>> A first protection strategy consists in excluding any local >>> repair >>> >>> but instead use end-to-end path protection where each SPRING path >>> is >>> >>> protected by a second disjoint SPRING path. In this case local >>> >>> protection MUST NOT be used. >>> >>> First of all, I do not think that RFC 2119 language should be used in >>> Informational documents, especially in the documents that describe use >>> cases. >> >> >> this document is also a requirements document for the resiliency use-case. >> RFC2119 terminology is perfectly usable and even more, it adds clarity on >> what the solution is expected to provide. >> >> >>> In addition, I specifically disagree with the quoted statement above, >>> because, from my POV: >>> · Local repair and end-to-end path protection can be combined for >>> the same path >>> · Such a combination may be beneficial for the operators. >> >> >> are you talking by experience or is it just something that came into your >> mind ? I’d like to hear from operators using a combination of path and link >> protection. >> >> This document has been deeply reviewed also by operators and it has been >> always obvious the little sense link protection has in case of path >> protection. >> >> >>> One possible way to combine the two is described below: >>> >>> 1. A pair of SR paths is set up between the given two nodes – later >>> referred to as source and destination - in the network. These paths are >>> “SR-disjoint” in the sense that their “explicit routes” do not have any >>> common elements, be they nodes or adjacencies, with exclusion of the final >>> destination >>> 2. Local repair for these paths is enabled in the network. It is >>> triggered by locally observed events (link failures etc.), applied by the >>> nodes adjacent to the failure and guarantees that, in the case of a link or >>> node failure that is not specified in the explicit route, traffic along the >>> affected path would be restored within <X> milliseconds >>> 3. End-to-end liveness monitoring is enabled for the two SR paths, >>> and detects end-to-end failures of these paths within <Y> milliseconds >>> where Y >> X. In other words, end-to-end liveness monitoring for these >>> paths will ignore any failures that local repair can fix, but will detect >>> failures that cannot be locally repaired (e.g., failures of nodes or links >>> that have been specified in the explicit route of one of the paths >>> 4. End-to-end liveness monitoring triggers end-to-end path protection >>> to be applied by the source node in the following way: >>> a. If it recognizes both paths as alive, one of them will carry the >>> customer traffic, while the other one will be idle. The rules for selecting >>> the active path in this scenario may vary >>> b. If end-to-end failure of one of these paths is detected while the >>> other one remains alive, traffic will be carried across the live path >>> c. If end-to-end failure of both paths is detected (e.g., if the >>> final destination node fails, or if the network is partitioned), this is >>> recognized as an unrecoverable failure. >>> >>> From my POV the combination of local repair and end-to-end protection for >>> SR paths is one of a few possibilities to protect such paths against >>> failures of nodes and/or links that have been specified in their explicit >>> routes. (Another option has been described in Node Protection for SR-TE >>> Paths, but this draft has expired). >>> >>> Do I miss something substantial? >> >> >> to my view you created a use-case that doesn’t bring much to the picture but >> I’d let operators to comment. >> >> s. >> >> >>> >>> Regards, >>> Sasha >>> >>> Office: +972-39266302 >>> Cell: +972-549266302 >>> Email: alexander.vainsht...@ecitele.com >>> >>> >>> ____________________________________________________________________ >>> __ >>> _____ >>> >>> This e-mail message is intended for the recipient only and contains >>> information which is CONFIDENTIAL and which may be proprietary to >>> ECI Telecom. If you have received this transmission in error, please >>> inform us by e-mail, phone or fax, and then delete the original and all >>> copies thereof. >>> ____________________________________________________________________ >>> __ _____ _______________________________________________ >>> spring mailing list >>> spring@ietf.org >>> https://www.ietf.org/mailman/listinfo/spring >> >> >> ______________________________________________________________________ >> _____ >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please >> inform us by e-mail, phone or fax, and then delete the original and all >> copies thereof. >> ______________________________________________________________________ >> _____ >> ______________________________________________________________________ >> ___________________________________________________ >> >> 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. >> > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > ___________________________________________________________________________ > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
