Hi John, I believe my text proposals do not dilute the post-convergence aspect of TI-LFA. Please let me know if you see it otherwise.
Thanks, Ketan On Fri, Nov 15, 2024 at 8:07 PM John Scudder <j...@juniper.net> wrote: > Hi Ketan, > > Thanks. It seems to me, though, that there is a qualitative difference > between computing a path that’s intended to be post-convergence, but having > that intent foiled because of known limitations in the design, and not even > trying to compute a post-convergence path. Let’s suppose the "not a TI-LFA > requirement or constraint” language, and similar, is only trying to capture > the limitation you’ve highlighted. In that case, I don’t think it would be > too hard to propose edits to cover the former (“intended to be… foiled”) > without also opening the door to the latter (“not even trying”), as the > present language does. > > —John > > On Nov 15, 2024, at 9:27 AM, Ketan Talaulikar <ketant.i...@gmail.com> > wrote: > > Hi John, > > This comment was towards the discussion on whether TI-LFA computed repair > path is always a post-convergence path or not. I meant to convey that it > practically may not be so for all types of protection schemes and failures. > This is nothing new. > > Thanks, > Ketan > > > On Fri, Nov 15, 2024 at 7:51 PM John Scudder <j...@juniper.net> wrote: > >> [trimmed cc; presumably copying the WG is sufficient] >> >> Hi Ketan, >> >> Can you help me understand what you’re driving toward with this comment? >> >> On Nov 15, 2024, at 5:44 AM, Ketan Talaulikar <ketant.i...@gmail.com> >> wrote: >> >> In addition to the above text change suggestions, I would remind that >> strict following of post-convergence is not guaranteed by TI-LFA as it >> depends on the protection scheme selected. There is the following text that >> explains this scenario in Appendix A. >> >> Readers should be aware that FRR protection is pre-computing a backup >> path to protect against a particular type of failure (link, node, SRLG). >> When using the post-convergence path as FRR backup path, the computed >> post-convergence path is the one considering the failure we are protecting >> against. This means that FRR is using an expected post-convergence path, >> and this expected post-convergence path may be actually different from the >> post-convergence path used if the failure that happened is different from >> the failure FRR was protecting against. As an example, if the operator has >> implemented a protection against a node failure, the expected >> post-convergence path used during FRR will be the one considering that the >> node has failed. However, even if a single link is failing or a set of >> links is failing (instead of the full node), the node-protecting >> post-convergence path will be used. The consequence is that the path used >> during FRR is not optimal with respect to the failure that has actually >> occurred. >> >> >> I agree with your statement; however, I’m a little baffled as to how it >> connects with the rest of the conversation. >> >> Thanks, >> >> —John >> > >
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
