Hi Jim, Ack. I've been following the discussion in this thread and I agree with your suggestion. The chairs will send an email to the mailing list about this major change in the draft and poll the WG's opinion, especially whether there are any objections.
Thanks, Yingzhen On Thu, Nov 21, 2024 at 12:08 PM James Guichard < james.n.guich...@futurewei.com> wrote: > 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> wrote: > > Hi Ketan, > > > > On Nov 15, 2024, at 9:48 AM, Ketan Talaulikar <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 > > To unsubscribe send an email to rtgwg-le...@ietf.org > >
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
