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

[Ahmed Bashandy <[e-mail]>]

great

I'll change the wording accordingly

Ahmed

On 11/1/23 10:09 PM, Gyan Mishra 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)