Hi Ahmed, I don't believe Stewart has reviewed the text changes in v19 of the draft. Let us please give him the chance to go over the same once he is back so we can progress towards consensus.
We all agree that post convergence has always been an important aspect of TI-LFA and I believe the text in v19 has sorted out some text that came across as conflicting this. Thanks, Ketan On Mon, Dec 2, 2024 at 10:31 AM Ahmed Bashandy <abashandy.i...@gmail.com> wrote: > Stewart, > > I looked back till version -00 of the draft and I was NOT able to find a > version that says post-conversion is a MUST-have or MANDATORY. > > But I may have overlooked such version. > > Because you are the shepherd of this document and I am sure you have > reviewed it tens (if not hundreds) of times, I would expect it would be > easy for you to point out the version of the draft that says > post-convergence is a MUST or MANDATORY. > > If you can't, I think you're quite little bit late for these kinds of > comments. > > > Thanks > > > Ahmed > > > > On 11/28/24 9:24 AM, Stewart Bryant wrote: > > When this technology was originally introduced to the IETF in 2015 the > key selling point, and the key point of innovation, was that in order to > prevent the formation of micro-loops it was necessary for the repair path > to exactly follow the post convergence path. > > > > All the simulations in Appendix B were, as I recall made on that > assumption. > > > > As work progressed, segment routing was usefully introduced to avoid the > need for directed LDP sessions or preconfigured tunnels. > > > > It now seems that the author have quietly backtracked on the need for > the congruence between the repair path and the post convergence path. > > > > If there is no need for this path congruence then the draft can > succinctly be described as “repair according to RFC7490, but take advantage > of segment routing to build stateless repair paths”. That would be a very > simple and short draft to write. > > > > If partial path congruence is deployed then there needs to be some > detailed discussion about the consequences and mitigations of this, because > any micro loops that form will have an impact on both the traffic micro > looping and any traffic that is innocently using those paths. > > > > I am forming the view that the draft needs to be returned to the working > group for further consideration with a number of possible approaches. > > > > One approach is to split the draft into a draft that explains how to use > SR to support RFC7490 operation, and another draft that explains the > application of path selection that follows the path convergence path, > including text on operation in a network that only partially includes these > constraints. That way the two aspects of the problem are independently > approached and the costs and constraints of (partial) path congruence are > bought clearly to the fore. > > > > Another approach is to make it much clearer that congruence between the > post convergence path and the repair path is an optional extension to a > segment routing repair based on the methods described in RFC7490. There > then needs to be further text as indicated above making it clear to the > user what the consequences of partial congruence is so that they can make > an informed choice of the consequence of accepting this limitation. > > > > The draft is with the IESG and it is their decision, but having > reflected at length on this, I have the view that moving from an absolute > requirement to follow the post convergence path to making this an optional > requirement is a game changer compared to the original proposition, and as > such it needs considered joint work by the authors and the other experts in > RTGWG in the context the RTGWG. > > > > Best Regards > > > > Stewart > > > > > > > > _______________________________________________ > > 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 >
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
