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) 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. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
