[rtgwg] Re: I-D Action: draft-ietf-rtgwg-segment-routing-ti-lfa-20.txt

[Ahmed Bashandy <[e-mail]>]

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/