Re: [Lsr] WG AdoptionCall-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)
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 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 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)" > > 收件人：Yingzhen Qu ,Liyan Gong < > gongli...@chinamobile.com> > > 抄 送: "jie.d...@huawei.com" ,Acee Lindem < > acee.i...@gmail.com>,Gyan Mishra ,lsr < > lsr@ietf.org>,lsr-chairs ,ketan Talaulikar < > 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 On Behalf Of Yingzhen Qu > > Sent: Tuesday, March 12, 2024 1:11 PM > > To: Liyan Gong > > Cc: jie.d...@huawei.com; Acee Lindem ; Gyan Mishra > ; lsr ; lsr-chairs < > lsr-cha...@ietf.org>; ketan Talaulikar > > 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 > wrote: > > Hi Jie, > > > > Thank you for your replies. Please see inline with [Liyan]. > > > > Best Regards, > > Liyan > > > > > > 邮件原文 > > 发件人："Dongjie \\(Jimmy\\)" > > 收件人：Acee Lindem ,Liyan Gong < > gongli...@chinamobile.com> > > 抄 送: Gyan Mishra ,Yingzhen Qu < > yingzhen.i...@gmail.com>,lsr ,lsr-chairs < > lsr-cha...@ietf.org>,ketan Talaulikar > > 发送时间：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] > > Sent: Sunday, March 10, 2024 5:37 AM > > To: Liyan Gong > > Cc: Gyan Mishra ; Dongjie (Jimmy) < > jie.d...@huawei.com>; Yingzhen Qu ; lsr < > lsr@ietf.org>; lsr-chairs ; ketan Talaulikar < > 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- 0x > > MaxReachableLinkMetric - 0xfffe > > > > LSLinkInfinity is analogous to LSInfinity. > > > > [Jie] This is OK to me. > > > > > > > > See inline. > > > > > > > > On Mar 2, 2024, at 06:16, Liyan Gong 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 > > 收件人："Dongjie (Jimmy)" > > 抄 送: Yingzhen Qu ,lsr ,lsr-chairs > > > 发送时间：2024-03-01 11:27:32 > > 主题：Re: [Lsr] WG Adoption Call - > draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24) > >
Re: [Lsr] WG AdoptionCall-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)
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 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)" > 收件人：Yingzhen Qu ,Liyan Gong > > 抄 送: "jie.d...@huawei.com" ,Acee Lindem > ,Gyan Mishra ,lsr > ,lsr-chairs ,ketan Talaulikar > > 发送时间：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 On Behalf Of Yingzhen Qu > Sent: Tuesday, March 12, 2024 1:11 PM > To: Liyan Gong > Cc: jie.d...@huawei.com; Acee Lindem ; Gyan Mishra > ; lsr ; lsr-chairs > ; ketan Talaulikar > 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 wrote: > Hi Jie, > > Thank you for your replies. Please see inline with [Liyan]. > > Best Regards, > Liyan > > > 邮件原文 > 发件人："Dongjie \\(Jimmy\\)" > 收件人：Acee Lindem ,Liyan Gong > 抄 送: Gyan Mishra ,Yingzhen Qu > ,lsr ,lsr-chairs > ,ketan Talaulikar > 发送时间：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] > Sent: Sunday, March 10, 2024 5:37 AM > To: Liyan Gong > Cc: Gyan Mishra ; Dongjie (Jimmy) > ; Yingzhen Qu ; lsr > ; lsr-chairs ; ketan Talaulikar > > 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- 0x > MaxReachableLinkMetric - 0xfffe > > LSLinkInfinity is analogous to LSInfinity. > > [Jie] This is OK to me. > > > > See inline. > > > > On Mar 2, 2024, at 06:16, Liyan Gong 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 > 收件人："Dongjie (Jimmy)" > 抄 送: Yingzhen Qu ,lsr ,lsr-chairs > > 发送时间：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) > 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
Re: [Lsr] WG AdoptionCall-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)
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)" 收件人：Yingzhen Qu ,Liyan Gong 抄 送: "jie.d...@huawei.com" ,Acee Lindem ,Gyan Mishra ,lsr ,lsr-chairs ,ketan Talaulikar 发送时间：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 On Behalf Of Yingzhen Qu Sent: Tuesday, March 12, 2024 1:11 PM To: Liyan Gong Cc: jie.d...@huawei.com Acee Lindem Gyan Mishra lsr lsr-chairs ketan Talaulikar 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 wrote: Hi Jie, Thank you for your replies. Please see inline with [Liyan]. Best Regards, Liyan 邮件原文 发件人："Dongjie \\(Jimmy\\)" 收件人：Acee Lindem ,Liyan Gong 抄 送: Gyan Mishra ,Yingzhen Qu ,lsr ,lsr-chairs ,ketan Talaulikar 发送时间：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] Sent: Sunday, March 10, 2024 5:37 AM To: Liyan Gong Cc: Gyan Mishra Dongjie (Jimmy)Yingzhen Qu lsr lsr-chairs ketan Talaulikar 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- 0x MaxReachableLinkMetric - 0xfffe LSLinkInfinity is analogous to LSInfinity. [Jie] This is OK to me. See inline. On Mar 2, 2024, at 06:16, Liyan Gong 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 everyone39s 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 收件人："Dongjie (Jimmy)" 抄 送: Yingzhen Qu ,lsr ,lsr-chairs 发送时间：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) 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
Re: [Lsr] WG Adoption Call-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 On Behalf Of Yingzhen Qu Sent: Tuesday, March 12, 2024 1:11 PM To: Liyan Gong Cc: jie.d...@huawei.com; Acee Lindem ; Gyan Mishra ; lsr ; lsr-chairs ; ketan Talaulikar 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:34 PM Liyan Gong mailto:gongli...@chinamobile.com>> wrote: Hi Jie, Thank you for your replies. Please see inline with [Liyan]. Best Regards, Liyan 邮件原文 发件人："Dongjie \\(Jimmy\\)" mailto:40huawei@dmarc.ietf.org>> 收件人：Acee Lindem mailto:acee.i...@gmail.com>>,Liyan Gong mailto:gongli...@chinamobile.com>> 抄 送: Gyan Mishra mailto:hayabusa...@gmail.com>>,Yingzhen Qu mailto:yingzhen.i...@gmail.com>>,lsr mailto:lsr@ietf.org>>,lsr-chairs mailto:lsr-cha...@ietf.org>>,ketan Talaulikar mailto: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] Sent: Sunday, March 10, 2024 5:37 AM To: Liyan Gong mailto:gongli...@chinamobile.com>> Cc: Gyan Mishra mailto:hayabusa...@gmail.com>>; Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; lsr mailto:lsr@ietf.org>>; lsr-chairs mailto:lsr-cha...@ietf.org>>; ketan Talaulikar mailto: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- 0x MaxReachableLinkMetric - 0xfffe LSLinkInfinity is analogous to LSInfinity. [Jie] This is OK to me. See inline. On Mar 2, 2024, at 06:16, Liyan Gong mailto: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 mailto:hayabusa...@gmail.com>> 收件人："Dongjie (Jimmy)" mailto:jie.dong=40huawei@dmarc.ietf.org>> 抄 送: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>,lsr mailto:lsr@ietf.org>>,lsr-chairs mailto: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) mailto: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
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:34 PM Liyan Gong wrote: > Hi Jie, > > > Thank you for your replies. Please see inline with [Liyan]. > > > Best Regards, > > Liyan > > > > 邮件原文 > *发件人：*"Dongjie \\(Jimmy\\)" > *收件人：*Acee Lindem ,Liyan Gong < > gongli...@chinamobile.com> > *抄 送: *Gyan Mishra ,Yingzhen Qu < > yingzhen.i...@gmail.com>,lsr ,lsr-chairs < > lsr-cha...@ietf.org>,ketan Talaulikar > *发送时间：*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 ] > *Sent:* Sunday, March 10, 2024 5:37 AM > *To:* Liyan Gong > *Cc:* Gyan Mishra ; Dongjie (Jimmy) < > jie.d...@huawei.com>; Yingzhen Qu ; lsr < > lsr@ietf.org>; lsr-chairs ; ketan Talaulikar < > 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- 0x > > MaxReachableLinkMetric - 0xfffe > > > > LSLinkInfinity is analogous to LSInfinity. > > > > [Jie] This is OK to me. > > > > > > > > See inline. > > > > > > > > On Mar 2, 2024, at 06:16, Liyan Gong 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 > *收件人：*"Dongjie (Jimmy)" > *抄 送: *Yingzhen Qu ,lsr >,lsr-chairs > *发送时间：*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) 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 (0x) does not exclude the link from SPF and thus > requires RI LSA with capability bit set for MaxLinkMetric (0x) 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 (0x) to exclude it from normal SPF computation, while a > Flex-Algo is defined to use the same metric type for
Re: [Lsr] IPR Poll for draft-gong-lsr-ospf-unreachable-link
No - I'm not aware of any undisclosed IPR. Thanks, Acee > On Mar 8, 2024, at 7:58 PM, Yingzhen Qu wrote: > > Hi all, > > There is an IPR disclosure filed for this draft on 3/8/2024: > IPR disclosures (ietf.org) > > Also not all authors have responded to the IPR poll in the adoption call > thread, so I'd like to ask all the authors and contributors to answer in this > thread. The draft won't progress without answers from all authors and > contributors. > > Please state either: > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author. > > > Thanks, > Yingzhen ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Yangdoctors last call review of draft-ietf-lsr-ospf-admin-tags-16
Reviewer: Qiufang Ma Review result: Almost Ready Hi, this is my YANG Doctor review of draft-ietf-lsr-ospf-admin-tags-16, I marked the review as “Almost Ready” with a couple of comments and questions below. (1) For the "ietf-ospf-admin-tags" YANG data model, what is the consideration for the “advertise-prefixes” data node to be defined as a list with only one child key inside it? Will this list node be populated with new parameters in the future? Otherwise I think a simpler definition might be the following: OLD: augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area /ospf:interfaces/ospf:interface: +--rw admin-tags +--rw tags* [tag] +--rw tag uint32 +--rw advertise-prefixes* [prefix] +--rw prefixinet:ip-prefix NEW: augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area /ospf:interfaces/ospf:interface: +--rw admin-tags +--rw tags* [tag] +--rw tag uint32 +--rw advertise-prefix* inet:ip-prefix There is nothing wrong to be defined in the current draft (e.g., PYANG won’t complain), but I think it can be hierarchically reduced this way, thoughts? (2) For the grouping "prefix-admin-tag-sub-tlvs", it is defined and used to augment the OSPF YANG data model and the OSPFv3 Extended LSA YANG data model. There is a list defined inside the grouping definition, with only one child declared as leaf-list. I am wondering why the type and length are not defined inside admin-tag-sub-tlv list? Aren’t they part of the admin tag TLV? (3) The reference info inside the “revision” statement for this draft is inconsistent with its real title. It is using “RFC : YANG Data Model for OSPF Prefix Administrative Tags.”, while it should be “RFC : Extensions to OSPF for Advertising Prefix Administrative Tags”. (4) There are some list/leaf-list data nodes defined in the YANG data model with their names defined as plural (e.g., tags, advertise-prefixes, admin-tags), but the naming convention is to have the list/leaf-list name singular form. See RFC8407bis (https://www.ietf.org/archive/id/draft-ietf-netmod-rfc8407bis-09.html#section-4.3.1) for the following: “List identifiers SHOULD be singular with the surrounding container name plural. Similarly, "leaf-list" identifiers SHOULD be singular.” (5) There is a YANG tree diagram included in the draft, an informative reference to RFC 8340 should be added in the draft. See RFC8407bis (https://www.ietf.org/archive/id/draft-ietf-netmod-rfc8407bis-09.html#section-3.4) for the following: “If YANG tree diagrams are used, then an informative reference to the YANG tree diagrams specification MUST be included in the document. Refer to Section 2.2 of [RFC8349] for an example of such a reference.” (6) It would be good if the tree structure of the YANG module could be defined in a separate section/subsection, so that readers are able to navigate to the overview (i.e., tree structure) of the model quickly if they want. Just a suggestion for the authors to consider. (7) Please include a note to the RFC editor requesting RFC and (or even better, use RFC for draft-ietf-lsr-ospfv3-extended-lsa-yang) is replaced with the RFC number that is assigned to the document. (8) I see a couple of “TBD” throughout the draft, did the authors leave them intentional? (9) I think it would be useful if some example instance snippets of this YANG data model can be added, either throughout the document or in an appendix. Is this something the authors would consider to help understand the use of YANG module? ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
