Thanks a lot for the comments
I adopted all the suggestions in version 21 at
https://www.ietf.org/archive/id/draft-ietf-rtgwg-segment-routing-ti-lfa-21.txt
Please take a look at it in case I missed something
Ahmed
On 2/6/25 1:29 PM, John Scudder wrote:
Hi All,
Thanks for all your work on the document. I've been re-reviewing it and trying
to come up-to-date with the mailing list traffic. I hit one significant snag
with the new version, which is detailed below. It shouldn't be too
controversial, it's just a case of well-intentioned edits having made the
section hard to understand. There are also a few nits at the bottom.
--John
(Provided in ballot format just out of habit.)
## COMMENT
### Section 7.2
These two paragraphs are new/substantially revised since my last review:
```
This method which merges back the traffic at the remote end of the
adjacency segment has the advantage of keeping as much as possible
the traffic on the pre-failure path. When SR policies are involved
and a strict compliance of the policy is required, an end-to-end
protection should be preferred over a local repair mechanism.
The case where this active segment is followed by another adjacency
segment is distinguished from the case where it is followed by a node
segment. Note that any method is incapable of providing the post-
convergence TE path that will be recomputed by the SR source node.
Another method requires to look to the next segment in the segment
list.
```
I find them hard to follow. Taking them one by one, would it be correct to
rewrite the first paragraph this way?
NEW:
This method, which merges back the traffic at the remote end of the
adjacency segment, has the advantage of keeping as much as possible
the traffic on the pre-failure path. When SR policies are involved
and strict compliance with the policy is required, an end-to-end
protection (beyond the scope of this document) should be preferred
over the local repair mechanism described above.
I presume the e2e protection being referred to is genuine e2e, i.e., it doesn't involve
the PLR at all; it relies on the headend computing a backup path. You're saying, "if
you have to have strict compliance with your SR policy, this is not the solution for
you."
I went back and reviewed the list traffic to figure out how the next paragraph
came into existence. While well-intentioned, I think it suffers from a couple
of problems -- one is the suggestions were pasted in an order that makes the
flow illogical for anyone who doesn't know the previous version. I'm going to
propose some reflow and rewording.
The second part of the second paragraph:
Note that any method is incapable of providing the post-
convergence TE path that will be recomputed by the SR source node.
used to be the end of the first paragraph, and that's where it should stay to
keep the logical flow. But also, the plain language of that sentence is, it's
flat-out impossible to ever get on the post-convergence path. Not even if
you're lucky! I think what's intended is that when TE is being done, then
without access to the TE constraints, you don't know what the headend is going
to prioritize doing when it lays out the new path. If so, a clearer way to say
that might be something like,
NEW:
Note, however, that when the SR source node is using traffic
engineering (TE), it will generally not be possible for the PLR to
know what post-convergence path will be selected by the source node
once it detects the failure, since computation of the TE path is a
local matter that depends on constraints that may not be known at the
PLR. Therefore, no method applied at the PLR can guarantee protection
will follow the post-convergence path.
If you use that, it probably should be its own paragraph, inserted immediately
following the first one, because I made it more verbose. I don't insist you use
my wording, and if you come up with something more concise as you had before,
it could be the last sentence of the first paragraph, again as it was before.
The residual parts of the second paragraph (after we cut out the middle,
covered above) are,
The case where this active segment is followed by another adjacency
segment is distinguished from the case where it is followed by a node
segment.
That is mostly unchanged from version 16 and sets up the following two subsections. It should be the last thing in Section 7.2 because of that. Since I was looking at it anyway, I came up with this if you'd like to use it:
NEW:
The case where the active segment is followed by another adjacency
segment is distinguished from the case where it is followed by a node
segment. Repair techniques for the respective cases are provided
in the following subsections.
And finally,
Another method requires to look to the next segment in the segment
list.
That was in the first paragraph in version 16. Looking at it now, I can't
figure out what it means, so I can't propose a disposition. Would it harm the
document to delete it? (Answering that question might help me understand what
it's trying to say.)
## NITS:
s/directred/directed/
s/establised/established/
_______________________________________________
rtgwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
