I meant to send this to the WG as well Stewart
Begin forwarded message: > From: Stewart Bryant <stewart.bry...@gmail.com> > Date: 12 February 2025 at 17:12:04 GMT > To: Ahmed Bashandy <abashandy.i...@gmail.com> > Cc: Stewart Bryant <stewart.bry...@gmail.com>, John Scudder > <j...@juniper.net>, draft-ietf-rtgwg-segment-routing-ti-...@ietf.org, Routing > WG <rtgwg@ietf.org> > Subject: Re: [rtgwg] I-D Action: > draft-ietf-rtgwg-segment-routing-ti-lfa-20.txt > > 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
