Sasha, Stephane,
> On Sep 30, 2016, at 1:29 PM, stephane.litkow...@orange.com wrote: > > Hi, > > Expressed this way I agree that this is an interesting additional requirement > for the draft. I agree. I’ll update the draft. s. > > Best Regards, > > Stephane > > > -----Original Message----- > From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com] > Sent: Tuesday, September 27, 2016 14:41 > To: LITKOWSKI Stephane OBS/OINIS > Cc: spring@ietf.org; Shell Nakash; Michael Gorokhovsky; > draft-ietf-spring-resiliency-use-ca...@ietf.org; Marina Fizgeer; Rotem Cohen; > DECRAENE Bruno IMT/OLN; Stefano Previdi (sprevidi) > Subject: RE: [spring] Issue with path protection for SR-TE LSPs > > Stephane, > Lots of thanks for an important clarification. > > But don’t you think that in addition to your statement "SPRING architecture > MUST provide a way to compute paths that MUST NOT be protected by local > repair techniques" the draft should also say that " SPRING architecture MUST > provide a way to instantiate pairs of paths that will would remain disjoint > in spite of any topology changes in the network"? > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: alexander.vainsht...@ecitele.com > > > -----Original Message----- > From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com] > Sent: Tuesday, September 27, 2016 2:41 PM > To: Alexander Vainshtein <alexander.vainsht...@ecitele.com>; DECRAENE Bruno > IMT/OLN <bruno.decra...@orange.com>; Stefano Previdi (sprevidi) > <sprev...@cisco.com> > Cc: spring@ietf.org; Shell Nakash <shell.nak...@ecitele.com>; Michael > Gorokhovsky <michael.gorokhov...@ecitele.com>; > draft-ietf-spring-resiliency-use-ca...@ietf.org; Marina Fizgeer > <marina.fizg...@ecitele.com>; Rotem Cohen <rotem.co...@ecitele.com> > Subject: RE: [spring] Issue with path protection for SR-TE LSPs > > Hi, > > As Stefano mentioned, as it's a use case and requirement draft, we do not > have to talk about solutions, and about issues in using one or other > mechanism. > Such considerations about using or not some particular SIDs to fill the "path > must not be protected by any local repair" constraint are up to a solution > draft and not this document. Regarding this document, the requirement is > clear : " SPRING architecture MUST provide a way to compute paths that MUST > NOT be protected by local repair techniques", that's all we can expect > from this document. > > Best Regards, > > Stephane > > > -----Original Message----- > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander > Vainshtein > Sent: Tuesday, September 27, 2016 12:22 > To: DECRAENE Bruno IMT/OLN; Stefano Previdi (sprevidi) > Cc: spring@ietf.org; Shell Nakash; Michael Gorokhovsky; > draft-ietf-spring-resiliency-use-ca...@ietf.org; Marina Fizgeer; Rotem Cohen > Subject: Re: [spring] Issue with path protection for SR-TE LSPs > > Stefano, Bruno and all, > Lots of thanks for detailed responses that, frankly, now go much deeper than > my original question. > > My concern was about combining "regular" prefix SIDs advertised with the > default algorithm and path protection for SR LSPs. > To the best of my understanding, within his, admittedly limited, scope: > - there is no way to guarantee that Main and Protection paths will remain > disjoint following some topology changes in the network > - if some local protection for these SIDs is enabled in the network, there is > no way to guarantee that it will not affect some segments of such LSPs. > > To the best of my understanding, Stefano's answers says that you can use some > "special" prefix-SIDs (e.g., marking them as not protecting, advertising tem > with some non-default algorithm etc.). I have no problem with these answers - > but from my POV they are out of the narrow scope of my original questions. > I do not think that this draft should list any specific solutions. But maybe > it should say that "the default prefix-SIDs" (i.e. prefix-SIDs advertised > with the default algorithm etc.) should not be used in specification of > SR-LSPs employing the path protection scheme? > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: alexander.vainsht...@ecitele.com > > -----Original Message----- > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of > bruno.decra...@orange.com > Sent: Tuesday, September 27, 2016 12:08 PM > To: Stefano Previdi (sprevidi) <sprev...@cisco.com> > Cc: spring@ietf.org; Alexander Vainshtein <alexander.vainsht...@ecitele.com>; > Shell Nakash <shell.nak...@ecitele.com>; Michael Gorokhovsky > <michael.gorokhov...@ecitele.com>; > draft-ietf-spring-resiliency-use-ca...@ietf.org; Marina Fizgeer > <marina.fizg...@ecitele.com>; Rotem Cohen <rotem.co...@ecitele.com> > Subject: Re: [spring] Issue with path protection for SR-TE LSPs > > Hi Stefano, > >> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] > Sent: >> Tuesday, September 27, 2016 10:53 AM >> >>> On Sep 27, 2016, at 9:50 AM, bruno.decra...@orange.com wrote: >>> >>> Hi Stefano, >>> >>> As an individual contributor, please find a comment inline > > > >> From: >>> Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] > Sent: Monday, > >>> September 26, 2016 11:22 AM > >> > >> <see below> > >> > >> > >>> On >>> Sep 26, 2016, at 11:14 AM, Stefano Previdi (sprevidi) <sprev...@cisco.com> >>> wrote: >>>>> >>>>> Hi Sasha, >>>>> >>>>> sorry for being late. See below. >>>>> >>>>> >>>>>> On Jul 10, 2016, at 11:07 AM, Alexander Vainshtein > >> >>>>>> <alexander.vainsht...@ecitele.com> wrote: >>>>>> >>>>>> Hi all, >>>>>> I have read the SR Resiliency Use Cases draft and I have an issue with >>>>>> the path > >> protection use case. >>>>>> >>>>>> The draft defines this use case with the following constrains/qualifiers >>>>>> (quoting > from > >> Section 2): >>>>>> · The operator configures two SPRING paths T1 and T2 from A to Z >>>>>> · Initially, the customer traffic (e.g., PW traffic) is sent >>>>>> from A to Z via T1. When >>>> T1 fails, the traffic is sent via T2. >>>>>> · The two paths are made disjoint using the SPRING architecture >>>>>> · The two configured paths T1 and T2 MUST NOT benefit from local >>>>>> protection >>>>>> >>>>>> The draft does not go into any detail regarding the type of segments >>>>>> that the > operator > >> uses when specifying T1 and T2, and the >>>>>> example given in the draft can be interpreted > in > >> two ways: >>>>>> · T1 and T2 are specified using only adjacency SID >>>>>> · T1 and T2 are specified using node SIDs (or a mix of node SIDs >>>>>> and adjacency >>>> SIDs). >>>>> >>>>> >>>>> this is intentional. >>>>> >>>>> It’s a use case draft where we describe the various protection >>>>> requirements and > >> strategies for protection. >>>>> >>>>> It has never been intended to describe a specific solution. >>>>> >>>>> >>>>>> If T1 and T2 are specified using node SIDs, there is no guarantee that >>>>>> these paths, > even > >> if initially disjoint, will remain disjoint >>>>>> when the underlying network topology changes. >>>>> >>>>> >>>>> It all depends on various factors among which the topology and how these >>>>> paths have > >> been computed (i.e.: for which failure: link/node/srlg). >>>>> IOW, you _can_ compute > disjoint > >> paths taking into account a >>>>> given srlg failure. >>>>> >>>>> For sure, a path expressed through an exhaustive (list of adj-sid will >>>>> give you the best > >> guarantee on the path the packet will take in all >>>>> cases but it is not the point of the > draft. >>>>> >>>>> >>>>>> Further, if TI FRR is enabled in the network for protection of non-TE SR >>>>>> LSPs, the > >> fragments of T1 and T2 that are specified using node >>>>>> SIDs will not be excluded from > local > >> protection. >>>> >>>> >>>> sorry, I realized something is missing in my answer. >>>> >>>> In fact, even using node-sids and even for non TE SR traffic, you can >>>> still ensure the > path > >> you computed uses non protected sid’s. >>>> >>>> Think about the use of strict-spf sid’s where the rule is clear: just >>>> fowllow spt and do > not > >> diverge from it. >>> >>> IMO, it would be useful to indicate in draft-ietf-spring-segment-routing >>> that strict-spf > SID MUST NOT be protected by a local protection (aka >>> Fast ReRoute). >>> It may be obvious to you, but it was not for me. In particular in the case >>> of TI-LFA where > the protection _do_ follow the SPF (indeed in the new >>> topology, but just like strict-spf > after the IGP convergence) > > > >>> Well, I’m not recommending this. I just took an example on how you could >>> enforce a > specific forwarding rule through a given segment identifier. >>> There are multiple choices for > that: >> . add a flag to prefix-sid (i.e.: do not protect) >> . define new “unprotected” SIDs >> . define new algorithm >> . use strict-spf algorithm >> . probably more... >> >> Here, in the context of this draft, I don’t think we have to list the >> possible solutions, right ? > > Agreed. > > >> My answer was given to Sasha when he claimed that there are now ways to >> prevent > protection for a given traffic. That statement was wrong (IMO) >> and I illustrated one way > to achieve it. > > You said to use strict-spf since it is not protected by FRR. > For this rule to be enforced, it needs to be clear in the definition of the > strict-spf algo. > IMO, this rule, as currently written in draft-ietf-spring-segment-routing, is > not clear enough. Hence could you please clarify it, in > draft-ietf-spring-segment-routing, to specify whether or not SID using the > "Strict Shortest Path" may be protected by FRR or not? > > Thanks > --Bruno > >> Thanks. >> s. >> >> >>> >>> Thanks >>> --Bruno >>> >>> >>>> s. >>>> >>>> >>>>>> So it seems that path protection for SR LSPs as specified in the draft >>>>>> is only > applicable > >> to paths that are specified using only >>>>>> adjacency SIDs. >>>> >>>>> I don’t disagree while I believe it mostly depends on the topology. >>>>> >>>>> More important is the fact that the document should not focus on one >>>>> specific way of > >> computing protection paths. >>>>> >>>>> s. >>>>> >>>>> >>>>>> >>>>>> Did I miss something substantial? >>>>>> >>>>>> Regards, and lots fo thanks in advance, > >>>> Sasha > >>>> > >>>> >>>>>> Office: +972-39266302 >>>>>> Cell: +972-549266302 >>>>>> Email: alexander.vainsht...@ecitele.com >>>>>> >>>>>> _______________________________________________ >>>>>> spring mailing list >>>>>> spring@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/spring >>>>> >>> >>> >>> >> _________________________________________________________________________ >> ________________________________________________ >>> >>> 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. >>> > > > _________________________________________________________________________________________________________________________ > > 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 > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > _________________________________________________________________________________________________________________________ > > 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. > > > _________________________________________________________________________________________________________________________ > > 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 spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
