OK
I'll make the change in the next few days and reply to this email with
version 13
Ahmed
On 1/15/24 8:12 PM, Gyan Mishra wrote:
Yes that is correct.
Thank you
<http://www.verizon.com/>
*Gyan Mishra*
/Network Solutions A//rchitect /
/Email [email protected]//
/
/M 301 502-1347
/
On Mon, Jan 15, 2024 at 10:33 PM Ahmed Bashandy
<[email protected]> wrote:
Question regarding removal of references to
draft-bashandy-rtgwg-segment-routing-uloop.
My understanding is that you are suggesting I remove the following
bullet from Section 2
* - Segment Routing may be used for prevention of such micro-loops
as described in [I-D.bashandy-rtgwg-segment-routing-uloop].*
Is my understanding correct?
Ahmed
On 12/17/23 11:05 PM, Gyan Mishra wrote:
Hi Yingzhen & Jeff
I completed the updated OPSDIR Review of TO-LFA draft and changed
status from “serious issues” to “Ready”.
Thank you
<http://www.verizon.com/>
*Gyan Mishra*
/Network Solutions A//rchitect /
/Email [email protected]//
/
/M 301 502-1347
/
---------- Forwarded message ---------
From: *Gyan Mishra via Datatracker* <[email protected]>
Date: Mon, Dec 18, 2023 at 2:00 AM
Subject: [OPS-DIR] Opsdir early review of
draft-ietf-rtgwg-segment-routing-ti-lfa-12
To: <[email protected]>
CC: <[email protected]>,
<[email protected]>
Reviewer: Gyan Mishra
Review result: Ready
I have reviewed version 12 and am updating my initial review of
TI-LFA in
August which this review.
Summary:
Based on revision 12 review, the draft is ready for publication.
Review details:
IETF 118 side meeting discussion summary:
We had a very productive discussion during the side meeting, and
the review
comments and open issues have been addressed.
Outcome of the discussion:
It’s important for the draft to clarify that with ti-lfa, when
IGP starts to
reconverge, there is still a possibility for micro-loops. So
customers should
be advised to deploy some micro-loop protection mechanisms to
prevent traffic
loss.
Action items for authors of the ti-lfa draft:
• To include text from RFC7490 second paragraph of section 10 - done
• To include the text summary in the email thread - done
• Change the text in section 6.1 from node to link - done
Next steps:
After the draft is updated to address the open issues which was
completed with
version 12, Gyan Mishra will update the OPS Directorate review,
and the RTGWG
WG Chairs will start the WGLC of this draft.
Draft updates from v11 to v12 below:
When the network reconverges, micro-loops [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], [RFC6976],
[RFC8333], or [I-D.bashandy-rtgwg-segment-routing-uloop] should be
implemented.
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:
* Micro-loops that appear - or do not appear – as part of the
distributed IGP convergence [RFC5715] on the paths to the
destination that do not pass thru TI-LFA paths:
- As explained in [RFC5714], such micro-loops may result
in the
traffic not reaching the PLR and therefore not following
TI-LFA
paths.
- Segment Routing may be used for prevention of such
micro-loops
as described in [I-D.bashandy-rtgwg-segment-routing-uloop].
* Micro-loops that appear – or do not appear - when the
failed link
is repaired.
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.
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 Section 6.2, Section 6.3, or
Section 6.4
of the draft. One of the possible ways to prevent such
micro-loops
is local convergence delay ([RFC8333]).
TI-LFA procedures are complementary to application of any
micro-loop
avoidance procedures in the case of link or node failure:
* 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
* The paths used in the micro-loop avoidance procedures typically
cannot be pre-computed.
6.1. FRR path using a direct neighbor
When a direct neighbor is in P(S,X) and Q(D,x) and the link to
that
direct neighbor is on the post-convergence path, the outgoing
interface is set to that neighbor and the repair segment list
SHOULD
be empty.
This is comparable to a post-convergence LFA FRR repair.
Major issues:
None
Minor issues:
Stewart Bryant pick up something that was agreed but was not
included in this
summary: we agreed to remove the reference to draft-bashandy in
order to make
the discussion on uloop prevention technology neutral.
So the TI-LFA draft even though it has loop preventing
mechanisms that can
possibly work independently of a separate uLoop avoidance
mechanism, that there
are cases as we both pointed out that uLoops can form, in those
cases for
further convergence time optimization a separate uLoop prevention
mechanism
maybe necessary.
So in that case the current reference to the uLoop avoidance
draft could apply.
However, I do think the uLoop draft needs a lot of work
particularly section 3
and is an I-D.
So I agree we need to remove any references to the uLoop draft
and stating that
a separate from TI-LFAs uLoop prevention technology is
necessary. The uLoop
draft as it exists would be the appropriate draft to be
referenced but
unfortunately it’s not ready so I don’t think we should reference it.
Nits:
None
_______________________________________________
OPS-DIR mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ops-dir
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
