I hesitate to prolong a discussion which is less important than many other things before the WG – but I do think there are better choices than sticking with a name which is not apt – names are of some importance.
Inline… From: Liyan Gong <gongli...@chinamobile.com> Sent: Thursday, March 14, 2024 7:14 PM To: tom petch <ie...@btconnect.com>; Yingzhen Qu <yingzhen.i...@gmail.com>; Christian Hopps <cho...@chopps.org> Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; jie.d...@huawei.com; AceeLindem <acee.i...@gmail.com>; Gyan Mishra <hayabusa...@gmail.com>; lsr <lsr@ietf.org>; lsr-chairs <lsr-cha...@ietf.org>; ketan Talaulikar <ketant.i...@gmail.com> Subject: Re:Re: [Lsr] WGAdoptionCall-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24) Hi All, Sincerely appreciate all your remainder and suggestion. About whether to change the draft name, here are the feedbacks we have received. 1) Do not change LES: For those who have concerns about confusion caused by a document name change, I have to say I think this is a misplaced concern and pedantic. (Apologies Tom…) If one looks at the content of Datatracker for any draft/RFC, you will see there is a very clear history of all versions of the draft under all of the names that may have been used along the way – and the Datatracker page is easily found by searching under any of the draft names. 2) Change to: ietf-lsr-ospf-max-link-metric-00 3) Change to: ietf-lsr-ospf-ls-link-infinity-00 [LES:] I would be happy with either alternate choice. But the current “unreachable” is completely inaccurate in terms of the functionality being defined. (Apologies to Acee…) I personally think that option 1) might be better, not changing, as it helps for better tracking of the document's history. In comparison to the name, the title abbreviation may be more helpful and permanent for understanding the document. Therefore, I would like to update the abbreviation in subsequent versions. e.g.,from “Advertising Unreachable Links in OSPF”to “Advertising Infinity Links in OSPF”. [LES:] I suppose something is better than nothing, but I really don’t see the justification for halfway measures. That’s it for me on this topic. Les Please feel free to let us know your thoughts. Any ideas are welcome. Thanks again. Best Regards, Liyan ----邮件原文---- 发件人：tom petch <ie...@btconnect.com<mailto:ie...@btconnect.com>> 收件人：Yingzhen Qu <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com>>,Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>> 抄 送: Liyan Gong <gongli...@chinamobile.com<mailto:gongli...@chinamobile.com>>,"Les Ginsberg (ginsbe" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>,"jie.d...@huawei.com<mailto:jie.d...@huawei.com>" <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>,AceeLindem <acee.i...@gmail.com<mailto:acee.i...@gmail.com>>,Gyan Mishra <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>>,lsr <lsr@ietf.org<mailto:lsr@ietf.org>>,lsr-chairs <lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>>,ketan Talaulikar <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>> 发送时间：2024-03-13 19:38:30 主题：Re: [Lsr] WGAdoptionCall-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24) From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> on behalf of Yingzhen Qu <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com>> 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:38PM Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org<mailto:cho...@chopps.org%3cmailto:cho...@chopps.org>>> 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 > <gongli...@chinamobile.com<mailto:gongli...@chinamobile.com<mailto:gongli...@chinamobile.com%3cmailto:gongli...@chinamobile.com>>> > 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)" > <ginsb...@cisco.com<mailto:ginsb...@cisco.com<mailto:ginsb...@cisco.com%3cmailto:ginsb...@cisco.com>>> > 收件人：Yingzhen Qu > <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com%3cmailto:yingzhen.i...@gmail.com>>>,Liyan > Gong > <gongli...@chinamobile.com<mailto:gongli...@chinamobile.com<mailto:gongli...@chinamobile.com%3cmailto:gongli...@chinamobile.com>>> > 抄 送: > "jie.d...@huawei.com<mailto:jie.d...@huawei.com><mailto:jie.d...@huawei.com%3cmailto:jie.d...@huawei.com%3e>" > > <jie.d...@huawei.com<mailto:jie.d...@huawei.com<mailto:jie.d...@huawei.com%3cmailto:jie.d...@huawei.com>>>,Acee > Lindem > <acee.i...@gmail.com<mailto:acee.i...@gmail.com<mailto:acee.i...@gmail.com%3cmailto:acee.i...@gmail.com>>>,Gyan > Mishra > <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com<mailto:hayabusa...@gmail.com%3cmailto:hayabusa...@gmail.com>>>,lsr > > <lsr@ietf.org<mailto:lsr@ietf.org<mailto:lsr@ietf.org%3cmailto:lsr@ietf.org>>>,lsr-chairs > > <lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org%3cmailto:lsr-cha...@ietf.org>>>,ketan > Talaulikar > <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com<mailto:ketant.i...@gmail.com%3cmailto:ketant.i...@gmail.com>>> > 发送时间：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 > <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org%3cmailto:lsr-boun...@ietf.org>>> > On Behalf Of Yingzhen Qu > Sent: Tuesday, March 12, 2024 1:11 PM > To: Liyan Gong > <gongli...@chinamobile.com<mailto:gongli...@chinamobile.com<mailto:gongli...@chinamobile.com%3cmailto:gongli...@chinamobile.com>>> > Cc: > jie.d...@huawei.com<mailto:jie.d...@huawei.com<mailto:jie.d...@huawei.com%3cmailto:jie.d...@huawei.com>>; > Acee Lindem > <acee.i...@gmail.com<mailto:acee.i...@gmail.com<mailto:acee.i...@gmail.com%3cmailto:acee.i...@gmail.com>>>; > Gyan Mishra > <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com<mailto:hayabusa...@gmail.com%3cmailto:hayabusa...@gmail.com>>>; > lsr > <lsr@ietf.org<mailto:lsr@ietf.org<mailto:lsr@ietf.org%3cmailto:lsr@ietf.org>>>; > lsr-chairs > <lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org%3cmailto:lsr-cha...@ietf.org>>>; > ketan Talaulikar > <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com<mailto:ketant.i...@gmail.com%3cmailto:ketant.i...@gmail.com>>> > 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 > <gongli...@chinamobile.com<mailto:gongli...@chinamobile.com<mailto:gongli...@chinamobile.com%3cmailto:gongli...@chinamobile.com>>> > wrote: > Hi Jie, > > Thank you for your replies. Please see inline with [Liyan]. > > Best Regards, > Liyan > > > ----邮件原文---- > 发件人："Dongjie \\(Jimmy\\)<file://(Jimmy/)>" > <jie.dong=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org<mailto:jie.dong=40huawei....@dmarc.ietf.org%3cmailto:40huawei....@dmarc.ietf.org>>> > 收件人：Acee Lindem > <acee.i...@gmail.com<mailto:acee.i...@gmail.com<mailto:acee.i...@gmail.com%3cmailto:acee.i...@gmail.com>>>,Liyan > Gong > <gongli...@chinamobile.com<mailto:gongli...@chinamobile.com<mailto:gongli...@chinamobile.com%3cmailto:gongli...@chinamobile.com>>> > 抄 送: Gyan Mishra > <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com<mailto:hayabusa...@gmail.com%3cmailto:hayabusa...@gmail.com>>>,Yingzhen > Qu > <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com%3cmailto:yingzhen.i...@gmail.com>>>,lsr > > <lsr@ietf.org<mailto:lsr@ietf.org<mailto:lsr@ietf.org%3cmailto:lsr@ietf.org>>>,lsr-chairs > > <lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org%3cmailto:lsr-cha...@ietf.org>>>,ketan > Talaulikar > <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com<mailto:ketant.i...@gmail.com%3cmailto:ketant.i...@gmail.com>>> > 发送时间：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:acee.i...@gmail.com<mailto:acee.i...@gmail.com><mailto:acee.i...@gmail.com%3cmailto:acee.i...@gmail.com%3e>] > Sent: Sunday, March 10, 2024 5:37 AM > To: Liyan Gong > <gongli...@chinamobile.com<mailto:gongli...@chinamobile.com<mailto:gongli...@chinamobile.com%3cmailto:gongli...@chinamobile.com>>> > Cc: Gyan Mishra > <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com<mailto:hayabusa...@gmail.com%3cmailto:hayabusa...@gmail.com>>>; > Dongjie (Jimmy) > <jie.d...@huawei.com<mailto:jie.d...@huawei.com<mailto:jie.d...@huawei.com%3cmailto:jie.d...@huawei.com>>>; > Yingzhen Qu > <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com%3cmailto:yingzhen.i...@gmail.com>>>; > lsr > <lsr@ietf.org<mailto:lsr@ietf.org<mailto:lsr@ietf.org%3cmailto:lsr@ietf.org>>>; > lsr-chairs > <lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org%3cmailto:lsr-cha...@ietf.org>>>; > ketan Talaulikar > <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com<mailto:ketant.i...@gmail.com%3cmailto:ketant.i...@gmail.com>>> > 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 > <gongli...@chinamobile.com<mailto:gongli...@chinamobile.com<mailto:gongli...@chinamobile.com%3cmailto:gongli...@chinamobile.com>>> > 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 > <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com<mailto:hayabusa...@gmail.com%3cmailto:hayabusa...@gmail.com>>> > 收件人："Dongjie (Jimmy)" > <jie.dong=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org<mailto:jie.dong=40huawei....@dmarc.ietf.org%3cmailto:40huawei....@dmarc.ietf.org>>> > 抄 送: Yingzhen Qu > <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com%3cmailto:yingzhen.i...@gmail.com>>>,lsr > > <lsr@ietf.org<mailto:lsr@ietf.org<mailto:lsr@ietf.org%3cmailto:lsr@ietf.org>>>,lsr-chairs > > <lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org%3cmailto:lsr-cha...@ietf.org>>> > 发送时间：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=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org<mailto:jie.dong=40huawei....@dmarc.ietf.org%3cmailto:40huawei....@dmarc.ietf.org>>> > 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:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org><mailto:lsr-boun...@ietf.org%3cmailto:lsr-boun...@ietf.org%3e>] > On Behalf Of Yingzhen Qu > Sent: Friday, February 23, 2024 1:28 PM > To: lsr > <lsr@ietf.org<mailto:lsr@ietf.org<mailto:lsr@ietf.org%3cmailto:lsr@ietf.org>>>; > lsr-chairs > <lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org%3cmailto:lsr-cha...@ietf.org>>> > 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 > Lsr@ietf.org<mailto:Lsr@ietf.org<mailto:Lsr@ietf.org%3cmailto:Lsr@ietf.org>> > https://www.ietf.org/mailman/listinfo/lsr > --<image001.jpg> > Gyan Mishra > Network Solutions Architect > Email > gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com%3cmailto:gyan.s.mis...@verizon.com>> > M 301 502-1347 > > > > > Subject：Re: [Lsr] WGAdoptionCall-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24) From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> on behalf of Yingzhen Qu <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com>> 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:38PM Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org<mailto:cho...@chopps.org%3cmailto:cho...@chopps.org>>> 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 > <gongli...@chinamobile.com<mailto:gongli...@chinamobile.com<mailto:gongli...@chinamobile.com%3cmailto:gongli...@chinamobile.com>>> > 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)" > <ginsb...@cisco.com<mailto:ginsb...@cisco.com<mailto:ginsb...@cisco.com%3cmailto:ginsb...@cisco.com>>> > 收件人：Yingzhen Qu > <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com%3cmailto:yingzhen.i...@gmail.com>>>,Liyan > Gong > <gongli...@chinamobile.com<mailto:gongli...@chinamobile.com<mailto:gongli...@chinamobile.com%3cmailto:gongli...@chinamobile.com>>> > 抄 送: > "jie.d...@huawei.com<mailto:jie.d...@huawei.com><mailto:jie.d...@huawei.com%3cmailto:jie.d...@huawei.com%3e>" > > <jie.d...@huawei.com<mailto:jie.d...@huawei.com<mailto:jie.d...@huawei.com%3cmailto:jie.d...@huawei.com>>>,Acee > Lindem > <acee.i...@gmail.com<mailto:acee.i...@gmail.com<mailto:acee.i...@gmail.com%3cmailto:acee.i...@gmail.com>>>,Gyan > Mishra > <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com<mailto:hayabusa...@gmail.com%3cmailto:hayabusa...@gmail.com>>>,lsr > > <lsr@ietf.org<mailto:lsr@ietf.org<mailto:lsr@ietf.org%3cmailto:lsr@ietf.org>>>,lsr-chairs > > <lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org%3cmailto:lsr-cha...@ietf.org>>>,ketan > Talaulikar > <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com<mailto:ketant.i...@gmail.com%3cmailto:ketant.i...@gmail.com>>> > 发送时间：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 > <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org%3cmailto:lsr-boun...@ietf.org>>> > On Behalf Of Yingzhen Qu > Sent: Tuesday, March 12, 2024 1:11 PM > To: Liyan Gong > <gongli...@chinamobile.com<mailto:gongli...@chinamobile.com<mailto:gongli...@chinamobile.com%3cmailto:gongli...@chinamobile.com>>> > Cc: > jie.d...@huawei.com<mailto:jie.d...@huawei.com<mailto:jie.d...@huawei.com%3cmailto:jie.d...@huawei.com>>; > Acee Lindem > <acee.i...@gmail.com<mailto:acee.i...@gmail.com<mailto:acee.i...@gmail.com%3cmailto:acee.i...@gmail.com>>>; > Gyan Mishra > <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com<mailto:hayabusa...@gmail.com%3cmailto:hayabusa...@gmail.com>>>; > lsr > <lsr@ietf.org<mailto:lsr@ietf.org<mailto:lsr@ietf.org%3cmailto:lsr@ietf.org>>>; > lsr-chairs > <lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org%3cmailto:lsr-cha...@ietf.org>>>; > ketan Talaulikar > <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com<mailto:ketant.i...@gmail.com%3cmailto:ketant.i...@gmail.com>>> > 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 > <gongli...@chinamobile.com<mailto:gongli...@chinamobile.com<mailto:gongli...@chinamobile.com%3cmailto:gongli...@chinamobile.com>>> > wrote: > Hi Jie, > > Thank you for your replies. Please see inline with [Liyan]. > > Best Regards, > Liyan > > > ----邮件原文---- > 发件人："Dongjie \\(Jimmy\\)<file://(Jimmy/)>" > <jie.dong=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org<mailto:jie.dong=40huawei....@dmarc.ietf.org%3cmailto:40huawei....@dmarc.ietf.org>>> > 收件人：Acee Lindem > <acee.i...@gmail.com<mailto:acee.i...@gmail.com<mailto:acee.i...@gmail.com%3cmailto:acee.i...@gmail.com>>>,Liyan > Gong > <gongli...@chinamobile.com<mailto:gongli...@chinamobile.com<mailto:gongli...@chinamobile.com%3cmailto:gongli...@chinamobile.com>>> > 抄 送: Gyan Mishra > <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com<mailto:hayabusa...@gmail.com%3cmailto:hayabusa...@gmail.com>>>,Yingzhen > Qu > <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com%3cmailto:yingzhen.i...@gmail.com>>>,lsr > > <lsr@ietf.org<mailto:lsr@ietf.org<mailto:lsr@ietf.org%3cmailto:lsr@ietf.org>>>,lsr-chairs > > <lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org%3cmailto:lsr-cha...@ietf.org>>>,ketan > Talaulikar > <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com<mailto:ketant.i...@gmail.com%3cmailto:ketant.i...@gmail.com>>> > 发送时间：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:acee.i...@gmail.com<mailto:acee.i...@gmail.com><mailto:acee.i...@gmail.com%3cmailto:acee.i...@gmail.com%3e>] > Sent: Sunday, March 10, 2024 5:37 AM > To: Liyan Gong > <gongli...@chinamobile.com<mailto:gongli...@chinamobile.com<mailto:gongli...@chinamobile.com%3cmailto:gongli...@chinamobile.com>>> > Cc: Gyan Mishra > <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com<mailto:hayabusa...@gmail.com%3cmailto:hayabusa...@gmail.com>>>; > Dongjie (Jimmy) > <jie.d...@huawei.com<mailto:jie.d...@huawei.com<mailto:jie.d...@huawei.com%3cmailto:jie.d...@huawei.com>>>; > Yingzhen Qu > <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com%3cmailto:yingzhen.i...@gmail.com>>>; > lsr > <lsr@ietf.org<mailto:lsr@ietf.org<mailto:lsr@ietf.org%3cmailto:lsr@ietf.org>>>; > lsr-chairs > <lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org%3cmailto:lsr-cha...@ietf.org>>>; > ketan Talaulikar > <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com<mailto:ketant.i...@gmail.com%3cmailto:ketant.i...@gmail.com>>> > 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 > <gongli...@chinamobile.com<mailto:gongli...@chinamobile.com<mailto:gongli...@chinamobile.com%3cmailto:gongli...@chinamobile.com>>> > 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 > <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com<mailto:hayabusa...@gmail.com%3cmailto:hayabusa...@gmail.com>>> > 收件人："Dongjie (Jimmy)" > <jie.dong=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org<mailto:jie.dong=40huawei....@dmarc.ietf.org%3cmailto:40huawei....@dmarc.ietf.org>>> > 抄 送: Yingzhen Qu > <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com%3cmailto:yingzhen.i...@gmail.com>>>,lsr > > <lsr@ietf.org<mailto:lsr@ietf.org<mailto:lsr@ietf.org%3cmailto:lsr@ietf.org>>>,lsr-chairs > > <lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org%3cmailto:lsr-cha...@ietf.org>>> > 发送时间：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=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org<mailto:jie.dong=40huawei....@dmarc.ietf.org%3cmailto:40huawei....@dmarc.ietf.org>>> > 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:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org><mailto:lsr-boun...@ietf.org%3cmailto:lsr-boun...@ietf.org%3e>] > On Behalf Of Yingzhen Qu > Sent: Friday, February 23, 2024 1:28 PM > To: lsr > <lsr@ietf.org<mailto:lsr@ietf.org<mailto:lsr@ietf.org%3cmailto:lsr@ietf.org>>>; > lsr-chairs > <lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org%3cmailto:lsr-cha...@ietf.org>>> > 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 > Lsr@ietf.org<mailto:Lsr@ietf.org<mailto:Lsr@ietf.org%3cmailto:Lsr@ietf.org>> > https://www.ietf.org/mailman/listinfo/lsr > --<image001.jpg> > Gyan Mishra > Network Solutions Architect > Email > gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com%3cmailto:gyan.s.mis...@verizon.com>> > M 301 502-1347 > > > > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
