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 v18Although 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 v18Although 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 tortgwg-le...@ietf.org
<<< text/html; charset=UTF-8; name="draft-ietf-rtgwg-segment-routing-ti-lfa-19.diff.html": Unrecognized >>>
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
