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

[Ahmed Bashandy <[e-mail]>]

I looked through the various replies and I was not able to find the time 
slot or the webex link

But I am assuming it will be shortly after Session I on Wednesday. This 
way we do not miss Session II, or at least only miss the first few minutes


Ahmed


On 11/7/23 12:42 AM, Yingzhen Qu wrote:
> Hi Ahmed,
>
> We'll have webex link, so it's about your availability.
>
> Thanks,
> Yingzhen
>
> On Tue, Nov 7, 2023 at 12:33 AM Ahmed Bashandy 
> <[e-mail]> wrote:
>
>     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
>