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

[Ahmed Bashandy <[e-mail]>]

I had to convert my attendance to remote due to family issues late last 
week. So I am not onsite


Ahmed


On 11/2/23 9:34 AM, Yingzhen Qu wrote:
> 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]> wrote:
>
>     Sasha, please see inline
>
>>     On 2 Nov 2023, at 14:12, Alexander Vainshtein
>>     <[e-mail]> wrote:
>>
>>     Stewart and all,
>>     I think I understand now the difference betweenSection 6.2 of RFC
>>     5715 <https://www.rfc-editor.org/rfc/rfc5715#section-6.2>and
>>     theSR 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]>
>>     *Sent:*Thursday, November 2, 2023 1:29 PM
>>     *To:*Alexander Vainshtein <[e-mail]>
>>     *Cc:*Stewart Bryant <[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
>>     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]> wrote:
>>
>>
>>             On 2 Nov 2023, at 08:56, Alexander Vainshtein
>>             <[e-mail]> wrote:
>>             Stewart and all,
>>             I have looked upRFC5715 Section 6.2
>>             <https://www.rfc-editor.org/rfc/rfc5715#section-6.2>and I
>>             agree that it is similar to theSR 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]>
>>             *Sent:*Thursday, November 2, 2023 10:15 AM
>>             *To:*Alexander Vainshtein <[e-mail]>
>>             *Cc:*Stewart Bryant
>>             <[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
>>             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]> wrote:
>>                 Stewart and all,
>>                 Please see some comments*/inline below/*.
>>                 Regards,
>>                 Sasha
>>                 *From:*Stewart Bryant <[e-mail]>
>>                 *Sent:*Thursday, November 2, 2023 9:30 AM
>>                 *To:*Gyan Mishra <[e-mail]>
>>                 *Cc:*Stewart Bryant <[e-mail]>;
>>                 Alexander Vainshtein
>>                 <[e-mail]>;[e-mail];
>>                 rtgwg-chairs
>>                 <[e-mail]>;[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
>>                 theSR 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]] TheRTGWG 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]> 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]> 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]<[e-mail]>
>>                         *Sent:*Monday, October 23, 2023 3:27 PM
>>                         *To:*Alexander Vainshtein
>>                         <[e-mail]>
>>                         *Cc:*[e-mail]; rtgwg-chairs
>>                         <[e-mail]>;[e-mail];
>>                         Stewart Bryant <[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:
>>
>>                         oMicro-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]>
>>                         *Sent:*Sunday, October 22, 2023 4:21 PM
>>                         *To:*DECRAENE Bruno INNOV/NET
>>                         <[e-mail]>; Stewart Bryant
>>                         <[e-mail]>
>>                         *Cc:*[e-mail]; rtgwg-chairs
>>                         <[e-mail]>;[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]>*On
>>                         Behalf Of*[e-mail]
>>                         *Sent:*Thursday, October 19, 2023 7:34 PM
>>                         *To:*Stewart Bryant <[e-mail]>
>>                         *Cc:*[e-mail]; rtgwg-chairs
>>                         <[e-mail]>;[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
>>
>>                         oTiming: from detection time , to start of the
>>                         IGP convergence
>>
>>                         -IGP Micro-loop avoidance (“b”)
>>
>>                         oTiming: 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]>
>>                         *Sent:*Tuesday, October 17, 2023 1:48 PM
>>                         *To:*DECRAENE Bruno INNOV/NET
>>                         <[e-mail]>
>>                         *Cc:*Stewart Bryant
>>                         <[e-mail]>;[e-mail];
>>                         rtgwg-chairs
>>                         <[e-mail]>;[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]:
>>                             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
>>                             <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]
>>                         https://www.ietf.org/mailman/listinfo/rtgwg
>>
>>                     _______________________________________________
>>                     rtgwg mailing list
>>                     [e-mail]
>>                     https://www.ietf.org/mailman/listinfo/rtgwg
>>
>
>
> _______________________________________________
> rtgwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtgwg