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

[Gyan Mishra <[e-mail]>]

Any of these options work for me.

I will be a remote  participant.

Thanks

Gyan


On Thu, Nov 2, 2023 at 1:10 PM Stewart Bryant <[e-mail]>
wrote:

> Any of these work for me.
>
> Stewart
>
> On 2 Nov 2023, at 16:47, Alexander Vainshtein <
> [e-mail]> wrote:
>
> Yingzhen,
>
> Any of these options would work for me. If we can start with a side
> meeting during the IETF-118, this would speed things up.
>
>
>
> Regards,
>
> Sasha
>
>
>
> *From:* Yingzhen Qu <[e-mail]>
> *Sent:* Thursday, November 2, 2023 6:35 PM
> *To:* Stewart Bryant <[e-mail]>
> *Cc:* Alexander Vainshtein <[e-mail]>; [e-mail];
> rtgwg-chairs <[e-mail]>;
> [e-mail]; Gyan Mishra <
> [e-mail]>
> *Subject:* Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-ti-lfa : A
> simple pathological network fragment
>
>
>
> Hi,
>
>
>
> The ti-lfa draft has not done WGLC yet, and we should definitely try to
> resolve this issue.
>
>
>
> I just checked the IETF 118 attendees list, and it seems not everyone will
> be onsite. I'd suggest continuing the discussion using this thread, and we
> can schedule either a side meeting during 118 or an Interim meeting on this
> topic after 118. Authors from both the ti-lfa and sr-uloop, Stewart, Sasha,
> and Gyan should be there.
>
>
>
> Please reply with your thoughts or email the chairs directly.
>
>
>
> Thanks,
>
> Yingzhen
>
>
>
> On Thu, Nov 2, 2023 at 8:45 AM Stewart Bryant <[e-mail]>
> 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 between Section 6.2 of RFC 5715
> <https://www.rfc-editor.org/rfc/rfc5715#section-6.2> and the SR
> Micro-Loop Avoidance
> <https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-uloop-15>  draft
> – or, rather, common expectations from this draft.
>
>
>
> RFC 5715 has been published in 2010. With the tunneling techniques
> available at that time in the industry I suspect that “tunnels whose path
> is not affected by the topology change”  in this section have been
> implicitly presumed to be RSVP-TE tunnels – simply because no other
> tunneling technology was available at that time (I do not think that source
> routing in IP has been seriously considered).
>
>
>
> Nearside tunnelling does not need RSVP. Any ingress that will use the PLR
> to deliver a packet via the failed link will always be able to reach the
> PLR since it is on the nearside of the failure, so all you need to do is to
> push a label that is associated with the PLR router and the packet will get
> to the PLR where it will be popped to reveal the label associated with an
> entity reachable via the failed link which them triggers a repair action on
> that packet. I cannot remember if we wrote that down, but as I remember we
> considered it obvious at the time. This needs no signalling beyond the
> normal normal IGP and MPLS LDP.
>
>
>
>
>
>
>
> The context of the SR Micro-Loop Avoidance draft is Segment Routing, and
> RSVP-TE is, most probably, out of scope. With SR, the tunnels that are not
> affected by topology changes are implemented as contiguous lists of
> unprotected Adj-SIDs – but forwarding HW is quite limited regarding the
> length of such lists. Therefore, the common expectation from the SR
> Micro-Loop avoidance  (as well from TI-:FA) is that that it uses tunnels
> whose paths are not affected by the topology change *and that are
> implementing using a reasonably short lists of Node SIDs and Adj-SIDs*.
>
>
>
> For link failure with loop free support you never need more that two
> labels: one to get you to the edge of P space, and if the P mode is not a
> PQ node, a second table to get you into Q space.
>
>
>
> A router already has the label t reach the P router, and pre the work on
> SR we proposed to use TLDP, but now you would use an SR label.
>
>
>
> So you only ever need one label at ingress and you already have that. You
> need at most two labels at the PLR, one normal label that you already have
> and one adjacency label that you could have got from T-LDP but which you
> more conveniently get from the SR system.
>
>
>
> This is much simpler than the TiLFA approach and just works.
>
>
>
>
>
> Section 6 of the TI-LFA draft describes how such paths can be computed in
> the case of a single link failure, and the constrain of post-convergence is
> one way to guarantee that they are not affected by topology changes.
>
>
>
> SR Micro-Loop Avoidance draft, for the last 7 years, repeats the promise
> to define approaches for computing such paths in Section 3 which remains
> unchanged from the -00 version and until this day.
>
> I admit that I am not aware of another way to guarantee that the path that
> is implemented as a sequence of SISD and includes Node SIDs would not be
> affected by the topology change.
>
>
>
> What do you think?
>
>
>
> I think we are making a simple problem much harder than it needs to be.
>
>
>
> Best regards
>
>
>
> Stewart
>
>
>
>
>
> Regards,
>
> Sasha
>
>
>
>
>
>
>
>
>
>
>
> Regards,
>
> Sasha
>
>
>
> *From:* Stewart Bryant <[e-mail]>
> *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 up RFC5715 Section 6.2
> <https://www.rfc-editor.org/rfc/rfc5715#section-6.2> and I agree that it
> is similar to the SR Micro-Loop Avoidance
> <https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-uloop-15>
>  draft.
>
>
>
> Specifically, explicitly mentions usage of  “tunnels whose path is not
> affected by the topology change” which is quite close IMHO to what the SR
> Micro-Loop avoidance draft is about and quite close to post-convergence
> paths used in TI-LFA.
>
> At the same time there are some differences. Specifically, RFC mentions “a
> new "loop-prevention" routing message” being issued by the router
> adjacent to failure. No such message is required in the SR Micro-Loop
> Avoidance draft.
>
>
>
> There are two ways of looking at this - new as in of a new type - and new
> as in a new message is issued.
>
>
>
> What ever you do you need a message to trigger loop prevention otherwise
> nodes remote from the failure will not know that it is needed. This could
> be done in one of two ways, either a bespoke fast flooded message, or you
> can trigger it from the routing LSP that will be issued by the PLR. It is
> not clear how fast the LSP flooding message will reach the all the nodes in
> P space.
>
>
>
> Either way you need a message to trigger loop prevention.
>
>
>
>
>
> I also think that the proposal, in the case of a link failure, to tunnel
> traffic to the nearest node adjacent to failure, is problematic. (Of
> course, the SR Micro-Loop Avoidance draft does not provide any approach for
> computing micro-loop avoiding paths with limited depth of added label
> stacks at all, it just repeats the promise to provide reference approaches
> starting from version -00 and until now).
>
>
>
> There are of course multiple ways of avoiding loops called up in RFC5715,
> but all of them require that all packets arriving at any ingress in the
> network that would originally go to the PLR either go direct to Q space or
> continue in P space to the PLR are repaired. If they are going to the PLR
> they need to be tunnelled where for the purposes of this discussion
> encapsulating in an SR packet is considered to be a tunnel.
>
>
>
> Anyway you did not comment on my point that if we need loop free anyway
> the congruence of the PLR path to the PQ node is no longer a hard
> requirement.
>
>
>
> Best regards
>
>
>
> Stewart
>
>
>
>
>
> My 2c,
>
> Sasha
>
>
>
> *From:* Stewart Bryant <[e-mail]>
> *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 the SR Micro-Loop
> Avoidance draft
> <https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-uloop-15> is
> about (no offence intended). *
>
>
>
> Of course an implementor could cheat and just used the simplified strategy
> I describe above and almost certainly very few operators would notice
> because:
>
>
>
> 1) In many cases the two paths would be congruent
>
>
>
> 2) The transient is short and quite difficult to instrument
>
>
>
> 3) Unless there was some security reason or traffic management reason for
> the path constraint few would care.
>
>
>
> I will look at the proposed differences later, but this sounds like it
> should be a topic for discussion in RTGWG before the text is finalised and
> sent the RFC editor.
>
> *[[Sasha]] The RTGWG agenda at IETF-118
> <https://datatracker.ietf.org/meeting/118/materials/agenda-118-rtgwg-02> seems
> tightly packed already. I wonder if a side meeting for such a discussion
> could be set in a way that allows online participation?*
>
>
>
> - Stewart
>
>
>
>
> On 2 Nov 2023, at 05:09, Gyan Mishra <[e-mail]> 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:
>
> o   Micro-loops that appear – or do not appear –on the paths to the
> destination that do not pass thru TI-LFA paths
>
>
>
> As an editorial comment, depending on where such text would be inserted, I
> would propose the following change:
>
> OLD: Micro-loops that appear – or do not appear –
>
> NEW: Micro-loops that appear – or do not appear – as part of the
> distributed IGP convergence [RFC5715]
>
>
>
> Motivation: some reader could wrongly understand that such micro-loops are
> caused by TI-LFA
>
>
>
> Thanks,
>
> Regards,
>
> --Bruno
>
>
>
> Orange Restricted
>
> *From:* Alexander Vainshtein <[e-mail]>
> *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
>
> o   Timing: from detection time , to start of the IGP convergence
>
> -     IGP Micro-loop avoidance (“b”)
>
> o   Timing: from start of IGP convergence to end of IGP convergence
>
>
>
> The scope of draft-ietf-rtgwg-segment-routing-ti-lfa is FRR / “a”. IGP
> micro-loop is out of scope. Other documents are proposing solutions for
> this. (and for those Micro-loop documents, FRR is similarly out of scope).
>
>
>
> Personally I agree with you that both mechanisms are needed. But I think
> that this is already highlighted in RFC 5714, and that this is no different
> than RFC 7490 (RLFA). Therefore, I don’t see why the outcome/text should be
> different. Hence my proposition to reuse the text from RFC 7490 (RLFA). I
> find it adequate. You wrote it so probably find it adequate.
>
>
>
> On a side note, RFC5715, that you also wrote, seems to already cover what you are asking for. Quoting the abstract, it
>
>       provides a summary of the causes and consequences of
>
>    micro-loops and enables the reader to form a judgement on whether
>
>    micro-looping is an issue that needs to be addressed in specific
>
>    networks.
>
>
>
> Note that this RFC5715 is already cited in the proposed text.
>
>
>
> PS: If you were ready to wrote a 5715bis, I would support this.
>
>
>
> Best regards,
>
> --Bruno
>
>
>
>
>
> Orange Restricted
>
> *From:* Stewart Bryant <[e-mail]>
> *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] wrote:
>
>
>
> Hi Stewart,
>
>
>
> Please see inline
>
>
>
>
>
> Orange Restricted
>
> *From:* Stewart Bryant <[e-mail]>
> *Sent:* Monday, October 16, 2023 2:08 PM
> *To:* [e-mail]; rtgwg-chairs <[e-mail]>;
> [e-mail]
> *Cc:* Stewart Bryant <[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/
>
>
>
> 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?
>
>