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.
Thanks, Yingzhen On Tue, Mar 12, 2024 at 9:38 PM Christian Hopps <[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]> 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]> > > 收件人：Yingzhen Qu <[email protected]>,Liyan Gong < > [email protected]> > > 抄 送: "[email protected]" <[email protected]>,Acee Lindem < > [email protected]>,Gyan Mishra <[email protected]>,lsr < > [email protected]>,lsr-chairs <[email protected]>,ketan Talaulikar < > [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]> On Behalf Of Yingzhen Qu > > Sent: Tuesday, March 12, 2024 1:11 PM > > To: Liyan Gong <[email protected]> > > Cc: [email protected]; Acee Lindem <[email protected]>; Gyan Mishra > <[email protected]>; lsr <[email protected]>; lsr-chairs < > [email protected]>; ketan Talaulikar <[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]> > wrote: > > Hi Jie, > > > > Thank you for your replies. Please see inline with [Liyan]. > > > > Best Regards, > > Liyan > > > > > > ----邮件原文---- > > 发件人："Dongjie \\(Jimmy\\)" <[email protected]> > > 收件人：Acee Lindem <[email protected]>,Liyan Gong < > [email protected]> > > 抄 送: Gyan Mishra <[email protected]>,Yingzhen Qu < > [email protected]>,lsr <[email protected]>,lsr-chairs < > [email protected]>,ketan Talaulikar <[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]] > > Sent: Sunday, March 10, 2024 5:37 AM > > To: Liyan Gong <[email protected]> > > Cc: Gyan Mishra <[email protected]>; Dongjie (Jimmy) < > [email protected]>; Yingzhen Qu <[email protected]>; lsr < > [email protected]>; lsr-chairs <[email protected]>; ketan Talaulikar < > [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]> 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]> > > 收件人："Dongjie (Jimmy)" <[email protected]> > > 抄 送: Yingzhen Qu <[email protected]>,lsr <[email protected]>,lsr-chairs > <[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) <jie.dong= > [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]] On Behalf Of Yingzhen Qu > > Sent: Friday, February 23, 2024 1:28 PM > > To: lsr <[email protected]>; lsr-chairs <[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] > > https://www.ietf.org/mailman/listinfo/lsr > > --<image001.jpg> > > Gyan Mishra > > Network Solutions Architect > > Email [email protected] > > M 301 502-1347 > > > > > > > > > > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
