We’ve changed names in the past when the initial name didn’t remote reflect the draft content. However, I don’t see that to be the case here. Also, given my preference, if we were to change it, I’d change it to ietf-lsr-ospf-ls-link-infinity-00.txt.
Thanks, Acee > On Mar 13, 2024, at 07:38, tom petch <[email protected]> wrote: > > From: Lsr <[email protected]> on behalf of Yingzhen Qu > <[email protected]> > Sent: 13 March 2024 05:36 > Les, thanks for the reminder. > > Liyan, you can post the WG version with a file name as Les suggested. Like > Chris mentioned, X can replace Y. If you run into issues, please let us know. > > <tp> > They will not run into issues. The rest of the world may at some future date > when trying to understand what changes were introduced when and why. > > I have seen ADs fail to understand that a name change has happened to an I-D > and so fail to understand how and why a document ended up as it is. > > The file name is temporary. It vanishes when the I-D is published.. > Changing it just introduces the scope for mistakes. > > Don't do it. Ever. > > Tom Petch > > p.s. I wonder if anyone has ever appealed to the IESG against a decision to > change th name of an I-D:-) > > Thanks, > Yingzhen > > On Tue, Mar 12, 2024 at 9:38 PM Christian Hopps > <[email protected]<mailto:[email protected]>> wrote: > I am not aware of any "inherited" requirement. We link documents (X replaces > Y) in the datatracker by choosing whatever document we want as "replaces". > You can post the document with whatever name changes you want and the chairs > can either accept it and it gets posted or not. > > Thanks, > Chris. > >> On Mar 12, 2024, at 23:26, Liyan Gong >> <[email protected]<mailto:[email protected]>> wrote: >> >> Hi Yingzhen,Les and WG, >> >> Thank you. The first version will be updated soon with the name >> draft-ietf-lsr-ospf-unreachable-link since the first version name needs to >> be inherited. >> The proposed name will be reflected in later versions. Thank you Les for >> your good suggestion. It is more apt. >> Any comments are always welcome. >> >> Best Regards, >> Liyan >> >> ----邮件原文---- >> 发件人："Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>> >> 收件人：Yingzhen Qu >> <[email protected]<mailto:[email protected]>>,Liyan Gong >> <[email protected]<mailto:[email protected]>> >> 抄 送: "[email protected]<mailto:[email protected]>" >> <[email protected]<mailto:[email protected]>>,Acee Lindem >> <[email protected]<mailto:[email protected]>>,Gyan Mishra >> <[email protected]<mailto:[email protected]>>,lsr >> <[email protected]<mailto:[email protected]>>,lsr-chairs >> <[email protected]<mailto:[email protected]>>,ketan Talaulikar >> <[email protected]<mailto:[email protected]>> >> 发送时间：2024-03-13 04:27:46 >> 主题：RE: [Lsr] WG AdoptionCall-draft-gong-lsr-ospf-unreachable-link(02/23/24 - >> 03/08/24) >> >> Or – if the authors want to consider my comments – replace “unreachable” >> in the name with something more apt – perhaps: >> >> “lsr-ospf-max-link-metric” >> >> 😊 >> >> Les >> >> >> From: Lsr <[email protected]<mailto:[email protected]>> On Behalf Of >> Yingzhen Qu >> Sent: Tuesday, March 12, 2024 1:11 PM >> To: Liyan Gong <[email protected]<mailto:[email protected]>> >> Cc: [email protected]<mailto:[email protected]>; Acee Lindem >> <[email protected]<mailto:[email protected]>>; Gyan Mishra >> <[email protected]<mailto:[email protected]>>; lsr >> <[email protected]<mailto:[email protected]>>; lsr-chairs >> <[email protected]<mailto:[email protected]>>; ketan Talaulikar >> <[email protected]<mailto:[email protected]>> >> Subject: Re: [Lsr] WG Adoption >> Call-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24) >> >> Hi all, >> >> The adoption call has ended. >> >> There is strong consensus, and all the authors and contributors have replied >> to the IPR call thread, so this draft is now adopted. >> >> Authors, please upload a WG version with name >> draft-ietf-lsr-ospf-unreachable-link when the datatracker is open. >> >> Please continue the discussion to further refine the draft. >> >> Thanks, >> Yingzhen >> >> On Mon, Mar 11, 2024 at 7:34PM Liyan Gong >> <[email protected]<mailto:[email protected]>> wrote: >> Hi Jie, >> >> Thank you for your replies. Please see inline with [Liyan]. >> >> Best Regards, >> Liyan >> >> >> ----邮件原文---- >> 发件人："Dongjie \\(Jimmy\\)" >> <[email protected]<mailto:[email protected]>> >> 收件人：Acee Lindem <[email protected]<mailto:[email protected]>>,Liyan >> Gong <[email protected]<mailto:[email protected]>> >> 抄 送: Gyan Mishra >> <[email protected]<mailto:[email protected]>>,Yingzhen Qu >> <[email protected]<mailto:[email protected]>>,lsr >> <[email protected]<mailto:[email protected]>>,lsr-chairs >> <[email protected]<mailto:[email protected]>>,ketan Talaulikar >> <[email protected]<mailto:[email protected]>> >> 发送时间：2024-03-11 23:11:49 >> 主题：Re: [Lsr] WG Adoption Call-draft-gong-lsr-ospf-unreachable-link(02/23/24 >> - 03/08/24) >> >> Hi Acee and Liyan, >> >> Please see some replies inline with [Jie] : >> >> From: Acee Lindem [mailto:[email protected]<mailto:[email protected]>] >> Sent: Sunday, March 10, 2024 5:37 AM >> To: Liyan Gong <[email protected]<mailto:[email protected]>> >> Cc: Gyan Mishra <[email protected]<mailto:[email protected]>>; >> Dongjie (Jimmy) <[email protected]<mailto:[email protected]>>; >> Yingzhen Qu <[email protected]<mailto:[email protected]>>; lsr >> <[email protected]<mailto:[email protected]>>; lsr-chairs >> <[email protected]<mailto:[email protected]>>; ketan Talaulikar >> <[email protected]<mailto:[email protected]>> >> Subject: Re: [Lsr] WG Adoption Call >> -draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24) >> >> All, >> >> With respect to the naming of the OSPF constants, I think we should go with: >> >> LSLinkInfinity - 0xffff >> MaxReachableLinkMetric - 0xfffe >> >> LSLinkInfinity is analogous to LSInfinity. >> >> [Jie] This is OK to me. >> >> >> >> See inline. >> >> >> >> On Mar 2, 2024, at 06:16, Liyan Gong >> <[email protected]<mailto:[email protected]>> wrote: >> >> Hi Gyan and Jie, >> I am not entirely sure if the suggestions from Ketan in previous email can >> address these two concerns. If not fully addressed, please feel free to let >> us know. >> Overall, this feature is applicable to all FAs, including FA0. The next >> version will further elaborate on the relationships between new features and >> FAs, as well as optimize the use-case descriptions and corresponding name to >> reflect "Unreachable" in a way that is easier to understand. >> Appreciate everyone's discussion. It is very helpful. >> >> >> [Jie] Thanks, this aligns with my understanding: it applies to all SPF >> computations (including Flexible Algorithms) which make use of IGP metric. >> And it would be good to replace unreachable with some more accurate >> description. >> [Liyan]Thanks.I am also considering this matter and hope to get your advice. >> Would it be better to use "Infinity Link" instead of " Unreachable Link" for >> both the content and the title of the draft? >> >> Best Regards, >> Liyan >> >> >> ----邮件原文---- >> 发件人：Gyan Mishra <[email protected]<mailto:[email protected]>> >> 收件人："Dongjie (Jimmy)" >> <[email protected]<mailto:[email protected]>> >> 抄 送: Yingzhen Qu >> <[email protected]<mailto:[email protected]>>,lsr >> <[email protected]<mailto:[email protected]>>,lsr-chairs >> <[email protected]<mailto:[email protected]>> >> 发送时间：2024-03-01 11:27:32 >> 主题：Re: [Lsr] WG Adoption Call - >> draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24) >> Hi Jie >> >> Some answers in-line >> >> On Thu, Feb 29, 2024 at 2:31 AM Dongjie (Jimmy) >> <[email protected]<mailto:[email protected]>> >> wrote: >> Hi Yingzhen, >> >> I’ve read the latest version of this document and support its adoption. It >> is a useful feature in general to exclude some of the links from SPF >> computation. >> >> I also have some comments for the authors to consider, they can be solved >> after the adoption. >> >> 1. I’m not sure the purpose is to advertise an unreachable link in >> OSPF, from the use cases in the draft, the link is still reachable and can >> be used for some services, just it needs be excluded from normal SPF >> calculation. If this is correct, it is better the title of the draft and the >> name of the new capability Flag need to be updated to reflect this. >> >> LSLinkInfinity would always indicate the link is unreachable. However, there >> is no real need to advertise it for other services since in these cases the >> advertisement is optional. >> >> [Jie] IMO once LSLinkInfinity is advertised for a link, it would impact all >> services which rely on SPF computation based on IGP metric. Regarding “for >> other services the advertisement is optional”, do you mean other services >> would rely on metric-types other than IGP metric? This is true for services >> which use TE paths, while there maybe issue with Flex Algorithm (as >> discussed below). >> >> Gyan> I agree with you and that is as well stated in the draft that >> MaxLinkMetric (0xFFFF) does not exclude the link from SPF and thus requires >> RI LSA with capability bit set for MaxLinkMetric (0xFFFF) for link to be >> excluded from SPF. Maybe “OSPF RI Capability LSA”. >> >> I think the capability should be LSLinkInfinity support. >> >> [Jie] This is OK. >> >> >> 2. In the Flex-Algo use case, if the metric of a link is set to >> MaxLinkMetric (0xFFFF) to exclude it from normal SPF computation, while a >> Flex-Algo is defined to use the same metric type for path calculation, >> will it cause the link also be excluded from the Flex-Algo path computation? >> If not, will metric value 0xFFFF be used in the Flex-Algo computation? In >> other word, the interaction between this new feature and Flex-Algo needs >> to be further elaborated. >> Gyan> I agree that the RI LSA capability flag for MaxLinkMetric (0xFFFF) >> is applicable to base Algo 0 and any Algo. However AFAIK you would have >> to explicitly set the RI flag the particular Algo. The use case described >> in this draft is when you are using flex algo for network slicing meaning >> you have both algo 0 and 128 on the same links and not a separate sub >> topology and in that case in order to avoid best effort traffic from going >> over the same link used for algo 128 you would need to use this RI >> capability flag. This concept we have talked about comes into play of >> degree of network slicing and isolation to meet SLO SLE requirements. >> >> LSLinkInfinity would exclude the link from a flex algorithm as well. >> However, the correct way to exclude it by omitting the advertisement. >> >> [Jie] Agree that if a Flex Algorithm uses IGP metric as its metric type, >> LSLinkInfinity would impact the Flex-Algo computation as well. While a >> Flex-Algo which uses other metric-types would not be impacted. Is that what >> you mean by “omitting the advertisement”? >> >> [Liyan]Yes, I think both of you have the same ideas which alligns with the >> draft. If misunderstanding, please Acee correct me. >> >> Best regards, >> Jie >> >> >> Thanks, >> Acee >> >> >> >> Best regards, >> Jie >> >> From: Lsr [mailto:[email protected]<mailto:[email protected]>] On >> Behalf Of Yingzhen Qu >> Sent: Friday, February 23, 2024 1:28 PM >> To: lsr <[email protected]<mailto:[email protected]>>; lsr-chairs >> <[email protected]<mailto:[email protected]>> >> Subject: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link >> (02/23/24 - 03/08/24) >> >> Hi, >> >> This email begins a 2 week WG adoption poll for the following draft: >> https://datatracker.ietf.org/doc/draft-gong-lsr-ospf-unreachable-link/ >> >> Please review the document and indicate your support or objections by March >> 8th, 2024. >> Authors and contributors, please respond to the list indicating whether you >> are aware of any IPR that applies to the draft. >> Thanks, >> Yingzhen >> _______________________________________________ >> Lsr mailing list >> [email protected]<mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/lsr >> --<image001.jpg> >> Gyan Mishra >> Network Solutions Architect >> Email [email protected]<mailto:[email protected]> >> M 301 502-1347 >> >> >> >> >> > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
