Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment

[Stewart Bryant <[e-mail]>]

> On 8 Nov 2023, at 05:18, Gyan Mishra <[e-mail]> wrote:
> 
> 
> 
> In the below RLFA RFC 7490 style  loop topology R1, R4, R5 are in the extended P space and  and Q space being R5, R6, R3 and TO-LFA algorithm post convergence path calculated RLFA PQ node being R5.
> 
> Using section 6.4 to build the post convergence repair path using RFC 5715 near side tunneling the repair path is NodeSid(R5), AdjSid(R6). So a near side tunnel is now built from R1 to R6.  
> 
> Looping is not an issue with R4 or R5 in looping packets back to R1 as the repair path is built from R1 to R6, tunneling over any nodes with un-converged FIBs.
> 
> Micro loop problem solved!
> 
> 
> CE1 –R1- R2-/-R3-CE2
>      |         |
>      R4 – R5 -R6

I think that it is important to note that if R1 reconverges first it will send packets to R4 using normal forwarding. However R4 is ECMP to CE2 via R1 which will micro loop back to R4.

At this point the repair is starved and no longer works.

Hence the point that I have been making and I think the point that Gyan originally made.

Without FRR the network converges in its own time and we accept micro loops and traffic discontinuity for an unknown time plus collateral damage to traffic that never used the failed link.

However once we deploy FRR we make a contract with the user that after a short while - of the order of 50ms - productive forwarding will continue uninterrupted. However this is not the case in some topologies (see above) and thus uloop prevention is required.

The thread has become somewhat difficult to follow with time, so I am now not sure what Bono’s text is. It would be helpful if it were repeated. However I think the draft has to say  that in order to warrant that FRR continues to provide traffic continuity until the network is reconverged a uloop strategy is required.

I would note as it is easily forgotten that a uloop strategy is also required when R2-R3 goes back into service. This is because if R4 converges first it will ECMP back to R1 which will send the packet back to R1.

Now we need to be clear that the micro looking is not the fault of the TiLFA design per se, but given that networks will deploy TiLFA with certain traffic continuity expectations we must clearly note to the reader that those expectations may not be met without addressing the uloop problem.

By way of referencing earlier work, RFC5714 does point to RFC5715 stating that a uloop technology is needed. In Section 10 of RFC 7490 the issue of loops is drawn to the attention of the network manager although perhaps with hindsight the text should be stronger.

- Stewart