Hi Stefano, > From: Stefano Previdi (sprevidi) [mailto:[email protected]] > Sent: > Tuesday, September 27, 2016 10:53 AM > > > On Sep 27, 2016, at 9:50 AM, [email protected] wrote: > > > > Hi Stefano, > > > > As an individual contributor, please find a comment inline > > > >> From: Stefano Previdi (sprevidi) [mailto:[email protected]] > Sent: > >> Monday, > September 26, 2016 11:22 AM > >> > >> <see below> > >> > >> > >>> On Sep 26, 2016, at 11:14 AM, Stefano Previdi (sprevidi) > >>> <[email protected]> wrote: > >>> > >>> Hi Sasha, > >>> > >>> sorry for being late. See below. > >>> > >>> > >>>> On Jul 10, 2016, at 11:07 AM, Alexander Vainshtein > >> <[email protected]> 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: [email protected] > >>>> > >>>> _______________________________________________ > >>>> spring mailing list > >>>> [email protected] > >>>> 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 [email protected] https://www.ietf.org/mailman/listinfo/spring
