> On 9 Aug 2021, at 09:07, Alexander Vainshtein <[email protected]> > wrote: > > Stewart, > Lots of thanks for a prompt response. > Please see some comments inline below. > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: [email protected] <mailto:[email protected]> > > From: Stewart Bryant <[email protected] > <mailto:[email protected]>> > Sent: Monday, August 9, 2021 10:54 AM > To: Alexander Vainshtein <[email protected] > <mailto:[email protected]>> > Cc: Stewart Bryant <[email protected] > <mailto:[email protected]>>; [email protected] > <mailto:[email protected]>; Stephane Litkowski (slitkows) > <[email protected] <mailto:[email protected]>>; [email protected] > <mailto:[email protected]>; Voyer, Daniel <[email protected] > <mailto:[email protected]>>; Ahmed Bashandy <[email protected] > <mailto:[email protected]>>; [email protected] > <mailto:[email protected]>;[email protected] <mailto:[email protected]> > Subject: [EXTERNAL] Re: A problematic example with the TI-LFA draft > Importance: High > > Hi Sasha > > Thank you for your comments however I do not understand the point that you > are making at (5) in your analysis regarding the conflict between Section 5.2 > and Section 5.3. Please could you explain? > [[Sasha]] Quoting from Section 5.2: > > When a remote node R is in P(S,X) and Q(D,x) and on the post- > convergence path, the repair list MUST be made of a single node > segment to R and the outgoing interface SHOULD be set to the outgoing > interface used to reach R. > This text uses normative language (MUST) describing the repair list in a > specific situation. It also uses normative language (SHOULD)when it comes to > selection of t6he egress situation. This does not leave too much space for > the implementors’ consideration. > > In some ways the “rules” in section 5 overcomplicate the description of the > solution. > [[Sasha]] I see it differently: the rules in Section 5 make the TI-LFA > technique practical. > > The solution could be simply stated as > > 1) Compute the PC path from PLR to destination. > 2) Create an SR path from PLR to destination using adjacency segments > [[Sasha]] And what if your forwarding engine cannot impose the resulting > label stack because it is too deep? AFAIK, this is quite a real issue, and > the implementors have two choices: forget about protection, or try to > implement optimization using the rules in Section 5.
Sasha You are right, either you can impose the required label stack or you forget about TI-LFA. Indeed in your particular example the only think that TI-LFA is buying is the traffic planning certainly since there is an excluded LFA that would not micro-loop during re-convergence. However the traffic planning certainty is not as clear cut as it might appear. At the moment I do not see why the Section 5 rules need to be *rules* rather than methods to explore to minimise the number of segments. We know the plan is to use the path R1 -> R5 -> R4 -> R3 -> R2 So the obvious approach is to compute P space ar R1 and discover you can get to R4, you are down to three segments which may be good enough. If not, compute Q space at R2 and you see that R3 can reach R2 so you only need to reach R3 R3 is adjacent to R4 so an adjacency segment gets you there So the repair becomes model segment to R4 adjacency segment to R3 which is the best you can do. We know from the very early days of FRR in 2002 https://www.ietf.org/archive/id/draft-bryant-ipfrr-tunnels-03.txt <https://www.ietf.org/archive/id/draft-bryant-ipfrr-tunnels-03.txt> that in a symmetric metric network you doing link repair you will need at most one directed hop between P space and Q space. I would be interesting to know if there is a proof that for link repair the P space and the Q space always contain nodes that are on the post convergence path that are separated by at most one hop. If that is the case we can simply the whole TI-LFA link repair concept to: Compute P space Compute Q space Compute the post convergence path If there is a PQ node repair to it on the PC path repair to it If there is not there will be a P and Q node separated by one hop repair to P and direct to Q Now what is glossed over is the calculation of the post convergence path which does not fall out of the standard Dijkstra calculation since that only computes the next hop and not the path. There is lots of subtlety around the PCP assumption which does not effect the TI-LFA micro loop assumptions by could effect the TI-LFA traffic loading assumptions. Now since Sasha brings up the imposition limit, it is worth noting that the limit of 4 SIDs shown in table 4x is a study of a particular set of unnamed networks that were studied and not an absolute limit. A good mental reminder of the problem is the cartwheel scenario where the failed node is the centre of a cartwheel with the spokes having cost 1. Any node repair solution will require about n/2 SIDs where n is the number of spokes. - Stewart > > At this point the job is done and everything else is an optimisation: > > 3) If desired optimise the number of segments. > 4) How step (3) is done is entirely within the remit of the implementor but > the pre-SR techniques we evolved and which described in Section 5 may be of > some use. > > I other words we do not need to consider section 5 as rules, just helpful > hints since technically we have a solution at step (2) > > - Stewart > > > > On 8 Aug 2021, at 09:57, Alexander Vainshtein <[email protected] > <mailto:[email protected]>> wrote: > > Dear authors of the TI-LFA draft > <https://clicktime.symantec.com/3SLXvM3kRidYiaMAJh8cbt6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-rtgwg-segment-routing-ti-lfa-07>, > I would appreciate your comments regarding TI-LFA computation in the example > topology shown below (also in an attached PDF file): > > <image002.png> > > > I am trying to compute repair path from R1 (the PLR) to the destination R2 > when the link R1 → R2 fails using the definitions and rules as they appear in > the draft. > > My computations yield the following results: > The post-convergence path from R1 to R2 is, obviously, R1 → R5 → R4 → R3 → R2 > Q-space of R2 consists of R3 and R6 > R2 is in the P-space of R6 and therefore in the extended P-space of the PLR > with regard to link R1 → R2, but R6 is not on the post-convergence path. > Therefore the rules in Section 5.1 of the draft do not apply > R3 is in the P-space of R6 and therefore in the extended P-space of the PLR > with regard to link R1 → R2, so that R3 is a PQ node on post-convergence path > and the rules in Section 5.2 of the draft should be applied. However, the > repair path computed as defined in Section 5.2 of the draft is R1 → R6 → R2 > → R3 → R2, NOT on the post-convergence path > R4 is in the extended P-space as defined in Section 2 of the draft, of the > PLR with regard to link R1 → R2. In addition, it is adjacent to R3 that is > in the Q-space of R2. Therefore the rules defined in Section 5.3 of the draft > also apply and yield the repair path R1 → R5 → R4 → R3 → R2 (i.e., matches > the post-convergence path). But preferring in Section 5.3 to the rules in > section 5.2 seems to be in direct contradiction to the draft. > > Your feedback will be highly appreciated. > > Regards, and lots of thanks in advance, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: [email protected] <mailto:[email protected]> > > > Notice: This e-mail together with any attachments may contain information of > Ribbon Communications Inc. and its Affiliates that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without express > permission is strictly prohibited. If you are not the intended recipient, > please notify the sender immediately and then delete all copies, including > any attachments. > <oledata.mso><ti-lfa-example.pdf> > > > Notice: This e-mail together with any attachments may contain information of > Ribbon Communications Inc. and its Affiliates that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without express > permission is strictly prohibited. If you are not the intended recipient, > please notify the sender immediately and then delete all copies, including > any attachments.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
