Hi Bruno, Thanks for this elaboration. I hope it helps us progress this document.
Please check inline below for some responses. On Thu, Dec 19, 2024 at 8:35 PM <bruno.decra...@orange.com> wrote: > Hi Yingzhen, all > > > > Speaking for myself, TI-LFA is about computing the protection over the > shortest path from the PLR to the destination (given failure of the > protected resource) and using Segment Routing to enforce that path. > > > > It seems that there is general agreement that using shortest path (aka > best path) is good, so I’m not detailing the arguments further. It seems > relatively straightforward to me that if this is a good property and we can > achieve it, we would want it. > > > > Regarding status at WG adoption time, without rereading the whole -00 WG > version [1], there are 25 occurrences of the term “post-convergence”. Also, > by only looking at the table of content, it seems like this > ”post-convergence” is the way it is computed and specified. > > > > 3. Intersecting P-Space and Q-Space with post-convergence paths > > 3.1. P-Space property computation for a resource X > > 3.2. Q-Space property computation for a link S-F, over > post-convergence paths > > 3.3. Q-Space property computation for a set of links adjacent to S, > over post-convergence paths > > 3.4. Q-Space property computation for a node F, over > post-convergence paths > > > > So to me, TI-LFA computation path is specified to use the SPF algo. > (section 3 of -00) > > > > Even in -19 the use of the post-convergence path seems part of the > specification to me: “§4. Base principle. The basic algorithm to compute > the repair path is to pre-compute SPT_new(R,X) and for each destination, > encode the repair path as a loop-free segment list.”. SPT_new(R,X) the > expected post-convergence path assuming the failure of X. > KT> Fully agree. > > > > > Now there is the question of enforcing this TI-LFA computed path. > > This is detailed in section 4 of -00. Ordered from the easiest case (4.1 > The repair node is a direct neighbor) to hardest case (4.4. Connecting > distant P and Q nodes along post-convergence paths). > > This hardest case is delegated to Segment Routing. So we gets SR benefits > and costs/limitations. Limitations seems well known to me, to the point we > even took the extra work of signaling them (MSD in RFC 8491 [2]). In the > general/academic case, the SID list is not bounded. So it should probably > not be a surprise that some implementation have limitations. However, in > the typical real cases, link protection is easy to achieve with any > implementation and node protection is typically not a problem although > corner cases may exist. > > > KT> This was clear to me from the document, but now that I read your email, I am wondering if it was not clear enough to some readers. > > > > > Regarding -19, I think that text and spec is mostly clear that the repair > path is following the expected post convergence path. > > Some possible changes could be: > > > > §2 > > OLD: 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.rfc-editor.org/info/rfc7916>]). > > NEW: TI-LFA also brings the benefit of providing 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.rfc-editor.org/info/rfc7916> > ]). > > > > §6 > > OLD: The repair list encodes the explicit, and possibly post-convergence, > path to the destination, > > NEW: The repair list encodes the explicit post-convergence path to the > destination > > > > If this help vendors to handle limitations of their implementation, I > think it would be fine to have a sentence stating those limitations and > possibly hints option e.g. > > NEW: For the case where the P and Q node are distant (§6.4), if an > implementation is not capable of computing or installing all the (ECMP) > protections for a destination, it MAY install a subset of the path, or a > different path or no path. > > > > Also, if one implementation wants to allow the use of a non > post-convergence path, I think it would be fine to have a sentence allowing > for so. E.g. > > NEW: Implementations MAY provide the ability to enforce a repair path > which is not following the post-convergence path, in particular to enforce > additional constraints. > KT> I agree with your proposed text updates, they help clarify for sure. Thanks, Ketan > > > > > I take this opportunity to thank John for his careful review and > dedication to improve the document. > > > > Thanks, > > --Bruno > > > > [1] > https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-00 > > [2] https://datatracker.ietf.org/doc/html/rfc8491 > > > > > > > > *From:* Yingzhen Qu <yingzhen.i...@gmail.com> > *Sent:* Sunday, November 24, 2024 11:30 AM > *To:* RTGWG <rtgwg@ietf.org>; rtgwg-chairs <rtgwg-cha...@ietf.org> > *Subject:* [rtgwg] Please review and comment > draft-ietf-rtgwg-segment-routing-ti-lfa > > > > Hi all, > > > > Since the draft-ietf-rtgwg-segment-routing-ti-lfa version 13 was submitted > to the IESG for publication in Feb this year, it has gone through several > iterations to address review comments. > > > > We'd like to bring the WG's attention that it is no longer a mandatory > requirement to follow the post-convergence path. The section 11 in version > 13 (Advantages of using the expected post-convergence path during FRR) is > now in Appendix A. Ahmed mentioned during his presentation at IETF121 that > this change was due to hardware limitations (recording: > https://www.youtube.com/watch?v=6qVpJsG9nO4), but this is not included in > the draft. Whether it is important to follow the post-convergence path is > not clearly stated in the draft, or under what circumstances the > post-convergence path is recommended and should be followed. > > > > We'd like to get the WG's opinion about the change. Please note that > currently the draft is Standards Track. Whether it should be kept as > Standards Track or moved to Informational should also be considered. > > > > Please review the latest version of the document and send your comments to > the list before December 14th, especially if you're not in agreement with > this change or you think it should be moved to Informational. > > > > Thanks, > > Jeff and Yingzhen (RTGWG co-chairs) > > > > > > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > 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
