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