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] From: Stewart Bryant <[email protected]> Sent: Monday, August 9, 2021 10:54 AM To: Alexander Vainshtein <[email protected]> Cc: Stewart Bryant <[email protected]>; [email protected]; Stephane Litkowski (slitkows) <[email protected]>; [email protected]; Voyer, Daniel <[email protected]>; Ahmed Bashandy <[email protected]>; [email protected]; [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. 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: 1. The post-convergence path from R1 to R2 is, obviously, R1 → R5 → R4 → R3 → R2 2. Q-space of R2 consists of R3 and R6 3. 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 4. 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 5. 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
