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
