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<mailto: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<mailto: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
