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:* bruno.decra...@orange.com <bruno.decra...@orange.com>
*Sent:* Monday, October 23, 2023 3:27 PM
*To:* Alexander Vainshtein <alexander.vainsht...@rbbn.com>
*Cc:* rtgwg@ietf.org; rtgwg-chairs <rtgwg-cha...@ietf.org>;
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org; Stewart Bryant <
stewart.bry...@gmail.com>
*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 <alexander.vainsht...@rbbn.com>
*Sent:* Sunday, October 22, 2023 4:21 PM
*To:* DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com>; Stewart
Bryant <stewart.bry...@gmail.com>
*Cc:* rtgwg@ietf.org; rtgwg-chairs <rtgwg-cha...@ietf.org>;
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org
*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 <rtgwg-boun...@ietf.org> *On Behalf Of *
bruno.decra...@orange.com
*Sent:* Thursday, October 19, 2023 7:34 PM
*To:* Stewart Bryant <stewart.bry...@gmail.com>
*Cc:* rtgwg@ietf.org; rtgwg-chairs <rtgwg-cha...@ietf.org>;
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org
*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)
