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.
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.
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.
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 <[email protected]>
Sent: Sunday, November 24, 2024 11:30 AM
To: RTGWG <[email protected]>; rtgwg-chairs <[email protected]>
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 -- [email protected]
To unsubscribe send an email to [email protected]
