Subject: A problematic example with the TI-LFA draft

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 8 Aug 2021 08:57:17 +0000

Dear authors of the TI-LFA draft<https://datatracker.ietf.org/doc/html/draft-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):

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-masked]

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.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 9 Aug 2021 08:53:35 +0100

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?

In some ways the “rules” in section 5 overcomplicate the description of the solution.

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

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-masked]> wrote:
> 
> Dear authors of the TI-LFA draft <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-07>,
> 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.
>  
> Email:   [email-masked] <mailto:[email-masked]>
>  
> 
> <oledata.mso><ti-lfa-example.pdf>

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 9 Aug 2021 08:07:53 +0000

Stewart,
Lots of thanks for a prompt response.
Please see some comments inline below.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Stewart Bryant <[email-masked]>
Sent: Monday, August 9, 2021 10:54 AM
To: Alexander Vainshtein <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; [email-masked]; Stephane Litkowski (slitkows) <[email-masked]>; [email-masked]; Voyer, Daniel <[email-masked]>; Ahmed Bashandy <[email-masked]>; [email-masked]; [email-masked]
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.

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.

- Stewart

On 8 Aug 2021, at 09:57, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> 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):

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 9 Aug 2021 10:39:03 +0100

> On 9 Aug 2021, at 09:07, Alexander Vainshtein <[email-masked]> wrote:
> 
> Stewart,
> From: Stewart Bryant <[email-masked] <mailto:[email-masked]>> 
> To: Alexander Vainshtein <[email-masked] <mailto:[email-masked]>>
> Cc: Stewart Bryant <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Stephane Litkowski (slitkows) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Voyer, Daniel <[email-masked] <mailto:[email-masked]>>; Ahmed Bashandy <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>;[email-masked] <mailto:[email-masked]>
> 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.
>  

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

> On 8 Aug 2021, at 09:57, Alexander Vainshtein <[email-masked] <mailto:[email-masked]>> 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>,