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
