Hi Ahmed & WG chairs, Thank you for the work in this latest version. However, as the responsible AD I am still uneasy with the consensus call on this document given the objections raised before and during the IETF 121 meeting, and the still open DISCUSSes after IESG evaluation. The main point of contention seems to be clearly summarized in John Scudder’s last email which was based upon Stewart Bryant’s (and others) comments at the mic during the 121 meeting. In summary:
“What the authors need to do is to be quite clear to the working group if it is no longer a mandatory requirement to follow the post-convergence path, and then there needs to be an explanation as to why this position has changed and then the text body needs to reflect the consensus position of the working group on whether it is important that it follows the "post-convergence path" or it's not important or there are times when it is and times when it is not, and in which case those circumstances should be documented in the text.” I believe that this discussion needs to happen, and I would ask the chairs to please start this conversation on the mailing list so that the WG has the chance to voice their concerns and come to a rough consensus on what needs to be addressed in the document (if anything) and whether relaxation of the mandatory requirement is acceptable. Thanks! Jim From: Ahmed Bashandy <abashandy.i...@gmail.com> Date: Thursday, November 21, 2024 at 2:46 PM To: Ketan Talaulikar <ketant.i...@gmail.com>, John Scudder <j...@juniper.net> Cc: RTGWG <rtgwg@ietf.org> Subject: [rtgwg] Re: New Version Notification for draft-ietf-rtgwg-segment-routing-ti-lfa-18.txt I forgot to include this latest change in my previous email The diffs attached to this reply contains all your previous suggestions plus this latest pne Thanks Ahmed On 11/15/24 7:23 AM, Ketan Talaulikar wrote: Hi John, Disclaimer: I am just catching up on the discussion on this draft. I also missed the WG session due to a conflict but have caught up with the recording. And I am not speaking for the authors. Below is an additional text proposal (over and above what I have shared previously) to cover, what I think, may be the essence of your discuss. It is possible though that I've still missed your point. f) Section 2 v18 Although not a TI-LFA requirement or constraint, TI-LFA also brings the benefit of the ability to provide a backup path that follows the expected post-convergence path considering a particular failure which reduces the need of locally configured policies that influence the backup path selection ([RFC7916<https://www.ietf.org/archive/id/draft-ietf-rtgwg-segment-routing-ti-lfa-18.html#RFC7916>]). The easiest way to express the expected post-convergence path in a loop-free manner is to encode it as a list of adjacency segments. However, this may create a long segment list that some hardware may not be able to program. One of the challenges of TI-LFA is to encode the expected post-convergence path by combining adjacency segments and node segments. Each implementation may independently develop its own algorithm for optimizing the ordered segment list. This document provides an outline of the fundamental concepts applicable to constructing the SR backup path, along with the related dataplane procedures. New v18 Although not a TI-LFA requirement or constraint, TI-LFA also brings the benefit of the ability to provide a backup path that follows the expected post-convergence path considering a particular failure which reduces the need of locally configured policies that influence the backup path selection ([RFC7916<https://www.ietf.org/archive/id/draft-ietf-rtgwg-segment-routing-ti-lfa-18.html#RFC7916>]). The easiest way to express the expected post-convergence path in a loop-free manner is to encode it as a list of adjacency segments. However, this may create a long segment list that some hardware may not be able to program. One of the challenges of TI-LFA is to encode the expected post-convergence path by combining adjacency segments and node segments. Each implementation may independently develop its own algorithm for optimizing the ordered segment list. This document provides an outline of the fundamental concepts applicable to constructing the SR backup path, along with the related dataplane procedures. Appendix A describes some of the post-convergence path related aspects of TI-LFA in more detail. The essence is that post-convergence is indeed an important differentiating aspect of TI-LFA. The text does already indicate the platform limitation aspect and leaves some of the optimization to implementations - I believe this is quite adequate already. Also, added the reference to the Appendix A per our discussion. Thanks, Ketan On Fri, Nov 15, 2024 at 8:22 PM John Scudder <j...@juniper.net<mailto:j...@juniper.net>> wrote: Hi Ketan, On Nov 15, 2024, at 9:48 AM, Ketan Talaulikar <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>> wrote: I believe my text proposals do not dilute the post-convergence aspect of TI-LFA. Please let me know if you see it otherwise. No argument. I was harking back to the debate I addressed at (probably too much) length in my message to this thread yesterday. I guess your proposed edits, while valuable, are tangential to the underlying question. Thanks, —John _______________________________________________ rtgwg mailing list -- rtgwg@ietf.org<mailto:rtgwg@ietf.org> To unsubscribe send an email to rtgwg-le...@ietf.org<mailto:rtgwg-le...@ietf.org>
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
