thanks a lot for the comments
One important clarification. Using the post convergence path is not a
constraint. In other words, using Ti-LFA does not require a repair path
to be post-convergence
Other than this clarification, I tend to agree with what you mentioned.
A couple of small comments under #Ahmed
On 11/7/23 1:45 AM, Alexander Vainshtein wrote:
Hi all,
Please see below the comments I planned to present during the
discussion at the RTGWG session today:
1. TI-LFA draft is about */local/* handling of */failures/*, while
the micro-loop avoidance one */is not limited to local reaction/*
and deals with any kind of topology changes, including (but not
limited to) */recovery/* of failed links/nodes. Therefore, I do
not think that merging these two drafts is a good idea.
#Ahmed: TOTALLY agree :)
1.
2. At the same time, I fully agree that relationship between TI-LFA
and micro-loop avoidance should be clarified, preferably in the
updated TI-LFA draft.
#Ahmed: There is really no relation. ti-lfa and uloop avoidance solve
different problems as mentioned in this draft and as Stewart himself
said that they are handled separately in his two RFCs although they may
be using the same algorithms to solve both problems.
1. The current (-11) revision:
1. The term micro-loop (sometimes spelled as “microloop”) does
not appear at all in the text
2. There is what I looks to me as a vague hint to micro-loop
avoidance in Section 6 of the TI-LFA draft that says (the
relevant text is highlighted): “The repair list encodes the
explicit post-convergence path to the destination, which
avoids the protected resource X and, at the same time, is
guaranteed to be loop-free irrespective of the state of FIBs
along the nodes belonging to the explicit path”. This statement:
i.Is obviously correct
ii.May be perceived as referring to TI-LFA paths represented by
explicit lists of Adj-SIDs
iii.Seems to ignore the fact that TI-LFA paths computed in accordance
with the definitions in Section 6.1, 6.2, 6.3 and, presumably, 6.4 of
the draft would not be affected the state of the FIBs long the nodes
they cross */regardless of matching the post-convergence path
constraint/*. This fact is not mentioned anywhere in the TI-LFA draft
#Ahmed: EXCELLENT comment. I agree that the phrase "regardless of
matching the post-convergence path" needs to be added. I can also add
some wording to refer to the sections that you referred to
3. I have proposed (on the list) tentative text clarifying this
relationship, and suggested placing it in a dedicated section
of the draft.
#Ahmed: Text is OK
3.
2. Section 2 of the TI-LFA draft states that the benefit of the
repair paths following post-convergence paths from the PLR (but
not from the ingress node) to the destination is reduction of the
“need for locally configured policies that drive the backup path
selection”. However, it does not update RFC 7916
<https://www.rfc-editor.org/rfc/rfc7916.html> that defines the
ways to specify such policies.
1. To me this suggests that congruence of the repair and
post-convergence path is not mandatory
#Ahmed: That is EXACTLY the intention. There is no place in the draft
where it says that following the post-convergence path is a constraint
or an intention. I do not understand why Stewart is saying that
post-convergence is a "constraint". Is there some wording that I missed
that might indicate that?
1.
2. In any case it would be nice to clarify all the benefits
associated with usage of the post-convergence paths, possibly
in a dedicated section of the draft.
#Ahmed: Well, although I would love to do that more extensively, but
some people may perceive this as excessive unnecessary content.
Hopefully, these comments will be useful.
#Ahmed: very :)
Regards,
Sasha
*Disclaimer*
This e-mail together with any attachments may contain information of
Ribbon Communications Inc. and its Affiliates that is confidential
and/or proprietary for the sole use of the intended recipient. Any
review, disclosure, reliance or distribution by others or forwarding
without express permission is strictly prohibited. If you are not the
intended recipient, please notify the sender immediately and then
delete all copies, including any attachments.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
