I have looked at the latest version and I think that from a technical perspective we can safely publish version 21
I do have two comments Firstly I am surprised at the prominence (it is the first reference in the draft) given to [I-D.bashandy-rtgwg-segment-routing-uloop] given that it is in individual draft that has hardly progressed in many years. Secondly the number of changes that the draft has undergone since leaving the WG seems extraordinary large and the IESG needs to take a view as to whether this is within limits of whether the WG should be involved in any way before they send it for publication. Best regards Stewart > On 12 Feb 2025, at 16:52, Ahmed Bashandy <abashandy.i...@gmail.com> wrote: > > 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 -- 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
