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
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
