Hi Stewart, I am curious about your reference to the v18 of this draft as opposed to the latest v19 that was posted a week ago.
Regarding the topic of post-convergence path, can you please point to the specific text in v19 that you find contrary to or even non-supportive of your position on this technology? Thanks, Ketan On Thu, Nov 28, 2024 at 10:55 PM Stewart Bryant <stewart.bry...@gmail.com> 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
