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

[Stewart Bryant <[e-mail]>]

Any of these work for me.

Stewart

> On 2 Nov 2023, at 16:47, Alexander Vainshtein <[e-mail]> wrote:
> 
> Yingzhen,
> Any of these options would work for me. If we can start with a side meeting during the IETF-118, this would speed things up.
>  
> Regards,
> Sasha
>  
> From: Yingzhen Qu <[e-mail]> 
> Sent: Thursday, November 2, 2023 6:35 PM
> To: Stewart Bryant <[e-mail]>
> Cc: Alexander Vainshtein <[e-mail]>; [e-mail]; rtgwg-chairs <[e-mail]>; [e-mail]; Gyan Mishra <[e-mail]>
> Subject: Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment
>  
> Hi,
>  
> The ti-lfa draft has not done WGLC yet, and we should definitely try to resolve this issue.
>  
> I just checked the IETF 118 attendees list, and it seems not everyone will be onsite. I'd suggest continuing the discussion using this thread, and we can schedule either a side meeting during 118 or an Interim meeting on this topic after 118. Authors from both the ti-lfa and sr-uloop, Stewart, Sasha, and Gyan should be there. 
>  
> Please reply with your thoughts or email the chairs directly.
>  
> Thanks,
> Yingzhen
>  
> On Thu, Nov 2, 2023 at 8:45 AM Stewart Bryant <[e-mail] <mailto:[e-mail]>> wrote:
> Sasha, please see inline
> 
> 
> On 2 Nov 2023, at 14:12, Alexander Vainshtein <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Stewart and all,
> I think I understand now the difference between Section 6.2 of RFC 5715 <https://www.rfc-editor.org/rfc/rfc5715#section-6.2> and the SR Micro-Loop Avoidance <https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-uloop-15>  draft – or, rather, common expectations from this draft.
>  
> RFC 5715 has been published in 2010. With the tunneling techniques available at that time in the industry I suspect that “tunnels whose path is not affected by the topology change”  in this section have been implicitly presumed to be RSVP-TE tunnels – simply because no other tunneling technology was available at that time (I do not think that source routing in IP has been seriously considered).
>  
> Nearside tunnelling does not need RSVP. Any ingress that will use the PLR to deliver a packet via the failed link will always be able to reach the PLR since it is on the nearside of the failure, so all you need to do is to push a label that is associated with the PLR router and the packet will get to the PLR where it will be popped to reveal the label associated with an entity reachable via the failed link which them triggers a repair action on that packet. I cannot remember if we wrote that down, but as I remember we considered it obvious at the time. This needs no signalling beyond the normal normal IGP and MPLS LDP.
>  
> 
> 
>  
> The context of the SR Micro-Loop Avoidance draft is Segment Routing, and RSVP-TE is, most probably, out of scope. With SR, the tunnels that are not affected by topology changes are implemented as contiguous lists of unprotected Adj-SIDs – but forwarding HW is quite limited regarding the length of such lists. Therefore, the common expectation from the SR Micro-Loop avoidance  (as well from TI-:FA) is that that it uses tunnels whose paths are not affected by the topology change and that are implementing using a reasonably short lists of Node SIDs and Adj-SIDs.
>  
> For link failure with loop free support you never need more that two labels: one to get you to the edge of P space, and if the P mode is not a PQ node, a second table to get you into Q space.
>  
> A router already has the label t reach the P router, and pre the work on SR we proposed to use TLDP, but now you would use an SR label.
>  
> So you only ever need one label at ingress and you already have that. You need at most two labels at the PLR, one normal label that you already have and one adjacency label that you could have got from T-LDP but which you more conveniently get from the SR system.
>  
> This is much simpler than the TiLFA approach and just works.
> 
> 
>  
> Section 6 of the TI-LFA draft describes how such paths can be computed in the case of a single link failure, and the constrain of post-convergence is one way to guarantee that they are not affected by topology changes.
>  
> SR Micro-Loop Avoidance draft, for the last 7 years, repeats the promise to define approaches for computing such paths in Section 3 which remains unchanged from the -00 version and until this day.
> 
> I admit that I am not aware of another way to guarantee that the path that is implemented as a sequence of SISD and includes Node SIDs would not be affected by the topology change.
>  
> What do you think?
>  
> I think we are making a simple problem much harder than it needs to be.
>  
> Best regards
>  
> Stewart
> 
> 
>  
> Regards,
> Sasha
>  
>  
>  
>  
>  
> Regards,
> Sasha
>  
> From: Stewart Bryant <[e-mail] <mailto:[e-mail]>>
> Sent: Thursday, November 2, 2023 1:29 PM
> To: Alexander Vainshtein <[e-mail] <mailto:[e-mail]>>
> Cc: Stewart Bryant <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; rtgwg-chairs <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; Gyan Mishra <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment
>  
> I just want to correct something
>  
> You do not of course need to tunnel if the packets only go though nodes that are shielded from the knowledge that the link has failed and thus ego not reconverge. A method such as RFC5715 section 6.7 - Ordered FIB update - does not require a tunnel because it causes the Q space to gradually expand and P space to gradually contract until the PLR is subsumed into Q space.
>  
> - Stewart
>  
>  
>  
> 
> On 2 Nov 2023, at 11:20, Stewart Bryant <[e-mail] <mailto:[e-mail]>> wrote:
>  
>  
>  
> 
> On 2 Nov 2023, at 08:56, Alexander Vainshtein <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Stewart and all,
> I have looked up RFC5715 Section 6.2 <https://www.rfc-editor.org/rfc/rfc5715#section-6.2> and I agree that it is similar to the SR Micro-Loop Avoidance <https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-uloop-15> draft.
>  
> Specifically, explicitly mentions usage of  “tunnels whose path is not affected by the topology change” which is quite close IMHO to what the SR Micro-Loop avoidance draft is about and quite close to post-convergence paths used in TI-LFA.
> At the same time there are some differences. Specifically, RFC mentions “a new "loop-prevention" routing message” being issued by the router adjacent to failure. No such message is required in the SR Micro-Loop Avoidance draft.
>  
> There are two ways of looking at this - new as in of a new type - and new as in a new message is issued.
>  
> What ever you do you need a message to trigger loop prevention otherwise nodes remote from the failure will not know that it is needed. This could be done in one of two ways, either a bespoke fast flooded message, or you can trigger it from the routing LSP that will be issued by the PLR. It is not clear how fast the LSP flooding message will reach the all the nodes in P space.
>  
> Either way you need a message to trigger loop prevention.
>  
>  
> I also think that the proposal, in the case of a link failure, to tunnel traffic to the nearest node adjacent to failure, is problematic. (Of course, the SR Micro-Loop Avoidance draft does not provide any approach for computing micro-loop avoiding paths with limited depth of added label stacks at all, it just repeats the promise to provide reference approaches starting from version -00 and until now).
>  
> There are of course multiple ways of avoiding loops called up in RFC5715, but all of them require that all packets arriving at any ingress in the network that would originally go to the PLR either go direct to Q space or continue in P space to the PLR are repaired. If they are going to the PLR they need to be tunnelled where for the purposes of this discussion encapsulating in an SR packet is considered to be a tunnel.
>  
> Anyway you did not comment on my point that if we need loop free anyway the congruence of the PLR path to the PQ node is no longer a hard requirement.
>  
> Best regards
>  
> Stewart
>  
> 
>  
> My 2c,
> Sasha
>  
> From: Stewart Bryant <[e-mail] <mailto:[e-mail]>>
> Sent: Thursday, November 2, 2023 10:15 AM
> To: Alexander Vainshtein <[e-mail] <mailto:[e-mail]>>
> Cc: Stewart Bryant <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; rtgwg-chairs <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; Gyan Mishra <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment
>  
> As far as I can see SR Microloop avoidance is RFC5715 Section 6.2 nearside tunnelling.
>  
> That works unconditionally regardless of the Ti-LFA constraints.
>  
> My point is that as soon as you recognise the need to introduce one of the RFC5715 micro loop avoidance methods you admit that TiLFA does not unconditionally address micro loops and thus the TiLFA repair topology constraint is no longer REQUIRED. An implementor may chose to do it, but it becomes OPTIONAL.
>  
> I think that this needs a discussion chaired by the RTGWG chairs either during IETF 118 or at a side meeting or at an online interim.
>  
> Stewart
> 
> 
> 
> On 2 Nov 2023, at 07:55, Alexander Vainshtein <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Stewart and all,
> Please see some comments inline below.
>  
> Regards,
> Sasha
>  
> From: Stewart Bryant <[e-mail] <mailto:[e-mail]>>
> Sent: Thursday, November 2, 2023 9:30 AM
> To: Gyan Mishra <[e-mail] <mailto:[e-mail]>>
> Cc: Stewart Bryant <[e-mail] <mailto:[e-mail]>>; Alexander Vainshtein <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; rtgwg-chairs <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Subject: [EXTERNAL] Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment
>  
> Let me ask a fundamental question.
>  
> The whole point of Ti-LFA as sold to the community was that repairing along the post convergence path as opposed to repairing along a convenient temporary path avoided micro loops.
> [[Sasha]] To the best of my understanding, repairing along the post-convergence path prevents micro-loops on these paths due to distributed IGP convergence – as long as traffic follows these paths.  It does not – and, obviously, cannot, have any impact on micro-loops happening elsewhere due to distributed IGP convergence – neither prevents micro-loops that would form without TI-LFA, nor introduces any new ones.
> The repair path constraint and subsequent segment optimisations add complexity to the calculation of the path.
>  
> Are we are now saying that micro loops can form elsewhere and as a consequence we need a micro loop avoidance strategy?
> [[Sasha]] TI-LFA, same as any other form of LFA that I am aware of, handles just link/node failures.  Micro-loops can happen – and, from my experience, frequently DO happen – during repair of a failed link/node.  IMHO and FWIW this alone justifies the need for the micro-loop avoiding strategy/solution. 
>  
> If so the fundamental premise behind TiLFA is broken and the repair can simply become: use SR to expeditiously route the packets into Q space and run a micro loop avoidance strategy. This approach removes the complexity of constraining the repair to the post convergence path. [[Sasha]] Please see my previous comment about TI-LFA paths being micro-loop avoidant because they are post-convergence paths.  In other words, one possible micro-loop avoidance strategy is usage of post-convergence paths in the transient period – and this, in a nutshell, is what the SR Micro-Loop Avoidance draft <https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-uloop-15> is about (no offence intended). 
>  
> Of course an implementor could cheat and just used the simplified strategy I describe above and almost certainly very few operators would notice because:
>  
> 1) In many cases the two paths would be congruent
>  
> 2) The transient is short and quite difficult to instrument
>  
> 3) Unless there was some security reason or traffic management reason for the path constraint few would care.
>  
> I will look at the proposed differences later, but this sounds like it should be a topic for discussion in RTGWG before the text is finalised and sent the RFC editor.
> [[Sasha]] The RTGWG agenda at IETF-118 <https://datatracker.ietf.org/meeting/118/materials/agenda-118-rtgwg-02> seems tightly packed already. I wonder if a side meeting for such a discussion could be set in a way that allows online participation?
>  
> - Stewart
> 
> 
> 
> 
> On 2 Nov 2023, at 05:09, Gyan Mishra <[e-mail] <mailto:[e-mail]>> wrote:
>  
>  
> Hi Sasha, Bruno & Stewart 
>  
> Thank you for going over my OPSDIR review in detail.
>  
> I am good with the latest updated verbiage that Bruno had given.
>  
> Comments in-line 
>  
> On Mon, Oct 23, 2023 at 8:41 AM Alexander Vainshtein <[e-mail] <mailto:[e-mail]>> wrote:
> Bruno,
> Lots of thanks for a prompt and very encouraging response!
>  
> Your version of the text is definitely better than mine, I am all for using it.
>  
> As for where the clarifying text could be inserted, I see two options:
> ·       A common “Applicability Statement” section (there is no such section in the draft)
> 
>        
> ·        
> 
> ·       A dedicated section on relationship between TI-LFA and micro-loops.
> 
>     Gyan> I think this option would  be best.  This would fix the existing gap on uLoop.  I did mention but not sure if possible- as TI-LFA and uLoop are tightly coupled as a overall post convergence solution is it possible to combine the drafts and issue another WGLC.  (Question for authors)
> In any case, I defer to you and the rest of the authors to decide what, if anything should be done for clarifying the relationship between TI-LFA and micro-loops.
>  
>  
> Regards,
> Sasha
>  
> From: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> Sent: Monday, October 23, 2023 3:27 PM
> To: Alexander Vainshtein <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>; rtgwg-chairs <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; Stewart Bryant <[e-mail] <mailto:[e-mail]>>
> Subject: [EXTERNAL] RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment
>  
> Sasha,
>  
> Thanks for the summary and the constructive proposal.
> Speaking for myself, this makes sense and I agree.
>  
> Ø  TI-LFA is a local operation applied by the PLR when it detects failure of one of its local links. As such,  it does not affect:
> 
> o   Micro-loops that appear – or do not appear –on the paths to the destination that do not pass thru TI-LFA paths
> 
>  
> As an editorial comment, depending on where such text would be inserted, I would propose the following change:
> OLD: Micro-loops that appear – or do not appear –
> NEW: Micro-loops that appear – or do not appear – as part of the distributed IGP convergence [RFC5715]
>  
> Motivation: some reader could wrongly understand that such micro-loops are caused by TI-LFA
>  
> Thanks,
> Regards,
> --Bruno
>  
> Orange Restricted
> From: Alexander Vainshtein <[e-mail] <mailto:[e-mail]>>
> Sent: Sunday, October 22, 2023 4:21 PM
> To: DECRAENE Bruno INNOV/NET <[e-mail] <mailto:[e-mail]>>; Stewart Bryant <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>; rtgwg-chairs <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Subject: RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment
> Importance: High
>  
> Bruno, Stewart and all,
> I think that most of the things about TI-LFA and micro-loops have been said already (if in a slightly different context)  and are mainly self-evident.
> However, I share the feeling that somehow the relationship between TI-LFA and micro-loop avoidance has become somewhat muddled.
>  
> Therefore, I would like to suggest adding some text to the TI-LFA draft that clarifies this relationship, e.g., along the following lines:
> 1.       TI-LFA is a local operation applied by the PLR when it detects failure of one of its local links. As such,  it does not affect:
> 
> a.       Micro-loops that appear – or do not appear –on the paths to the destination that do not pass thru TI-LFA paths
> 
>                                                                                                               i.      As explained in RFC 5714, such micro-loops may result in the traffic not reaching the PLR and therefore not following TI-LFA paths
> 
>                                                                                                              ii.      Segment Routing may be used for prevention of such micro-loops as described in the micro-loop avoidance draft
> 
> b.       Micro-loops that appear – or do not appear - when the failed link is repaired (aside: the need for this line is based on personal experience☹)
> 
> 2.       TI-LFA paths are loop-free. What’s more, they follow the post-convergence paths, and, therefore, not subject to micro-loops due to difference in the IGP convergence times of the nodes thru which they pass
> 
> 3.       TI-LFA paths are applied from the moment the PLR detects failure of a local link and until IGP convergence at the PLR is completed. Therefore, early (relative to the other nodes) IGP convergence at the PLR and the consecutive ”early” release of TI-LFA paths may cause micro-loops, especially if these paths have been computed using the methods described in Section 6.2, 6.3 or 6.4 of the draft. One of the possible ways to prevent such micro-loops is local convergence delay (RFC 8333).
> 
> 4.       TI-LFA procedures are complementary to application of any micro-loop avoidance procedures in the case of link or node failure:
> 
> a.       Link or node failure requires some urgent action to restore the traffic that passed thru the failed resource. TI-LFA paths are pre-computed and pre-installed and therefore suitable for urgent recovery
> 
> b.       The paths used in the micro-loop avoidance procedures typically cannot be pre-computed.
> 
>  
> Hopefully these notes would be useful.
>  
> Regards,
> Sasha
>  
> From: rtgwg <[e-mail] <mailto:[e-mail]>> On Behalf Of [e-mail] <mailto:[e-mail]>
> Sent: Thursday, October 19, 2023 7:34 PM
> To: Stewart Bryant <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>; rtgwg-chairs <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Subject: [EXTERNAL] RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment
>  
> Hi Stewart,
>  
> I agree with you on the technical points, so the first part of your email up to “So I think”.
>  
> But I don’t quite follow why you want to mix IGP Convergence issues with this Fast ReRoute Solution.
> To quote RFC 5714 « IP Fast Reroute Framework”
>  
> In order to reduce packet disruption times to a duration commensurate
>    with the failure detection times, two mechanisms may be required:
>  
>    a.  A mechanism for the router(s) adjacent to the failure to rapidly
>        invoke a repair path, which is unaffected by any subsequent re-
>        convergence.
>  
>    b.  In topologies that are susceptible to micro-loops, a micro-loop
>        control mechanism may be required [RFC5715 <https://datatracker.ietf.org/doc/html/rfc5715>].
>  
>    Performing the first task without the second may result in the repair
>    path being starved of traffic and hence being redundant.
>  
> https://datatracker.ietf.org/doc/html/rfc5714#section-4
>  
> I would assume that you agree with the above (as you are an author of this RFC and my guess would be that you wrote that text)
>  
> My point is that there are two different mechanisms involved, in two different time periods:
> -     Fast ReRoute (“a”): this is the scope of draft-ietf-rtgwg-segment-routing-ti-lfa
> o   Timing: from detection time , to start of the IGP convergence
> -     IGP Micro-loop avoidance (“b”)
> o   Timing: from start of IGP convergence to end of IGP convergence
>  
> The scope of draft-ietf-rtgwg-segment-routing-ti-lfa is FRR / “a”. IGP micro-loop is out of scope. Other documents are proposing solutions for this. (and for those Micro-loop documents, FRR is similarly out of scope).
>  
> Personally I agree with you that both mechanisms are needed. But I think that this is already highlighted in RFC 5714, and that this is no different than RFC 7490 (RLFA). Therefore, I don’t see why the outcome/text should be different. Hence my proposition to reuse the text from RFC 7490 (RLFA). I find it adequate. You wrote it so probably find it adequate.
>  
> On a side note, RFC5715, that you also wrote, seems to already cover what you are asking for. Quoting the abstract, it
>       provides a summary of the causes and consequences of
>    micro-loops and enables the reader to form a judgement on whether
>    micro-looping is an issue that needs to be addressed in specific
>    networks. 
>  
> Note that this RFC5715 is already cited in the proposed text.
>  
> PS: If you were ready to wrote a 5715bis, I would support this.
>  
> Best regards,
> --Bruno
>  
>  
> Orange Restricted
> From: Stewart Bryant <[e-mail] <mailto:[e-mail]>>
> Sent: Tuesday, October 17, 2023 1:48 PM
> To: DECRAENE Bruno INNOV/NET <[e-mail] <mailto:[e-mail]>>
> Cc: Stewart Bryant <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; rtgwg-chairs <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Subject: Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment
>  
> Hi Bruno
>  
> I was thinking about this some more. It is something that was recognised in the early days, but somewhat swept aside.
>  
> The case that Gyan bought up was an ECMP case, but I fear that the case is more common and I think we should characterise it as part of the text rather that giving the impression it is unusual.
>  
> I think the problem occurs whenever there are two or more nodes between the point of packet entry and the failure.
>  
> CE1 - R1 - R2 - R3 - R4 -/- R5 - CE2
>       |                     |
>       R6 - R7 - R8 - R9 — R10
>  
> The normal path CE1-CE2 is via R2
>  
> When R4-R5 fails it is trivial to see how the repair works with R7 as the entry into Q space.
>  
> However unless R1, R2,  R3 converge in that order there will be microloops for traffic entering via any of those three nodes.
>  
> So I think we can say that unless the PLR is only receiving traffic to be protected directly or from its immediate neighbour it is not guaranteed that there  will not be micro loops that are not addressable by the propose strategy of aligning the repair path with the post convergence path.
>  
> Now thinking about the text you have below, I think we need to write in in terms of - Unless the operator is certain that no micro loops will form over any path the protected traffic will traverse between entry to the network and arrival at the PLR a micro loop avoidance method MUST be deployed. Of course I think that it would be helpful to the operator community for the text to provide some guidance on how to ascertain whether there is a danger of the formation of micro loops.
>  
> I would note that the long chains of nodes show in the example above were probably not present in the test topologies which as I remember were all national scale provider networks, but unless we provide guidance otherwise Ti-LFA could reasonably be deployed in edge networks and in the case of cell systems these are often ring topologies.
>  
> So I think we need to agree (as a WG) on the constrains that we are prepared to specify in the text and the degree of warning we need to provide to the operator community and then we can polish the text below.
>  
> Best regards
>  
> Stewart
>  
>  
>  
>  
> 
> On 16 Oct 2023, at 17:25, [e-mail] <mailto:[e-mail]> wrote:
>  
> Hi Stewart,
>  
> Please see inline
>  
>  
> Orange Restricted
> From: Stewart Bryant <[e-mail] <mailto:[e-mail]>>
> Sent: Monday, October 16, 2023 2:08 PM
> To: [e-mail] <mailto:[e-mail]>; rtgwg-chairs <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Cc: Stewart Bryant <[e-mail] <mailto:[e-mail]>>
> Subject: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment
>  
> During the operations directorate early review of draft-ietf-rtgwg-segment-routing-ti-lfa 
> Gyan Mishra points to a simple pathological network fragment that I think deserves wider discussion.
>  
> https://datatracker.ietf.org/doc/review-ietf-rtgwg-segment-routing-ti-lfa-11-opsdir-early-mishra-2023-08-25/ <https://datatracker.ietf.org/doc/review-ietf-rtgwg-segment-routing-ti-lfa-11-opsdir-early-mishra-2023-08-25>
>  
> I am not aware of any response to the RTGWG by the draft authors concerning the review comment and I cannot see obvious new text addressing this concern.
> 
> The fragment is as follows
> 
> CE1 –R1- R2-/-R3-CE2
>      |         |
>      R4 – R5 -R6
> 
> In the pre converged network R4 is ECMP CE2 via R5 (cost 4) and via R1 (cost also 4).
> 
> We can easily build a TI-LFA repair path from R2 under link failure to CE2 (so long as we remember that R4 is an ECMP path to CE2), but the problem occurs during convergence. If R1 converges before R4, R4 may ECMP packets addressed to CE2 back to R1 in a micro loop. Meanwhile since no packets for R3 are reaching R2 the Ti-LFA repair is not doing anything useful. 
> 
> The Ti-LFA text leads the reader to conclude that it is a loop-free solution, but gives no guidance on how to determine when this assumption breaks down. There is an informational reference to 
> draft-bashandy-rtgwg-segment-routing-uloop, but this short individual draft does little in the way of helping the reader determine when  loop avoidance strategy needs to be deployed and the loop-free approach it describes does not seem to be fully developed.
>  
> I am worried that proceeding with the Ti-LFA draft without noting that there is a real risk that simple network fragments can micoloop, and providing a fully formed mitigation strategy is a disservice to the operator community given the industry interest in Ti-LDA and the insidious nature of unexpected micro loop network transients, I am wondering what the view of the working group is on how to proceed.
>  
> One approach would be for the Ti-LFA draft to incorporate detailed guidance on how to determine the risk of a micro loop in a specific operator network, and to provide specific mitigation advice. Another approach would be to  reference a developed loop avoidance strategy and recommending its preemptive deployment. Another approach would be to make draft-bashandy-rtgwg-segment-routing-uloop a normative reference and tie the fate of the two drafts. Another approach would be to elaborate on the risks and their manifestations but declare it a currently unsolved problem. I am sure there are other options that the WG may formulate.
>  
> What is the opinion of the working group on how we should proceed with draft-ietf-rtgwg-segment-routing-ti-lfa when considering the possible formation of micro loops?
>  
> FRR takes place between the failure (detection) and the IGP reconvergence. Those are two consecutive steps that the WG has so far addressed with different solutions and documents.
> That’s not new and that’s not specific to TI-LFA. E.g., that’s applicable to RLFA.
>  
> Would the below text, taken verbatim from RFC 7490 (RLFA), work for you? Or would you say that the text is not good enough?
> “When the network reconverges, micro-loops [RFC5715 <https://datatracker.ietf.org/doc/html/rfc5715>] can form due to
>    transient inconsistencies in the forwarding tables of different
>    routers.  If it is determined that micro-loops are a significant
>    issue in the deployment, then a suitable loop-free convergence
>    method, such as one of those described in [RFC5715 <https://datatracker.ietf.org/doc/html/rfc5715>], [RFC6976 <https://datatracker.ietf.org/doc/html/rfc6976>], or
>    [ULOOP-DELAY <https://datatracker.ietf.org/doc/html/rfc7490#ref-ULOOP-DELAY>], should be implemented.”
>  
> https://datatracker.ietf.org/doc/html/rfc7490#section-10
>  
> Of course, we could update the list of informative references.
> E.g., by adding another informative reference to draft-bashandy-rtgwg-segment-routing-uloop and by removing informative references to [RFC6976] and [ULOOP-DELAY] which are probably outdated.
>  
> --Bruno
>  
>  
> - Stewart
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>  
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>  
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>  
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>  
> 
> Disclaimer
> 
> 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. 
> 
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>  
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> _______________________________________________
> rtgwg mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rtgwg
> _______________________________________________
> rtgwg mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rtgwg
>