Re: [Lsr] WG Adoption Call -draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

[Acee Lindem]

Hi Ketan, 

> On Mar 15, 2024, at 05:26, Ketan Talaulikar  wrote:
> 
> Hi Acee,
> 
> Sorry for the late reply. Your naming proposal for the terminologies look 
> good to me.
> 
> Just one clarification - this draft will change the value of LinkMaxMetric 
> constant as defined in RFC6987/8770 from 0x to 0xfffe - is that correct?

Yes. I think there might be one more as well.

Thanks,
Acee



> 
> Please also see inline below for a minor comment/clarification.
> 
> 
> On Sun, Mar 10, 2024 at 3:07 AM Acee Lindem  <mailto:acee.i...@gmail.com>> wrote:
>> 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. 
>> 
>> 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.
>>> 
>>> Best Regards,
>>> Liyan
>>> 
>>> 
>>> 
>>> 邮件原文
>>> 发件人：Gyan Mishra  mailto:hayabusa...@gmail.com>>
>>> 收件人："Dongjie (Jimmy)" >> <mailto: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. 
> 
> KT> Since we are talking about the OSPF cost/metric here, it is not possible 
> to omit its advertisement. For OSPFv3 per RFC8363, the metric is present in 
> the fixed part of the Router Link TLV and thus cannot be omitted. For OSPFv2, 
> this omission was specified for the TE and delay metrics in 
> https://www.rfc-editor.org/rfc/rfc9350.html#section-15.3 but for the IGP 
> metric, it falls to the base specification. Now, it is debatable if we could 
> simply skip the "unreachable" link from the base OSPF Router LSA and only 
> advertise it in the OSPFv2 Extended Link LSA - this isn't something that is 
> explicitly specified as being handled as the "IGP metric" being omitted. 
> Since we anyway need LSLinkInfinity for OSPFv3, might as well bring in the 
> same for OSPFv2.
> 
> Thanks,
> Ketan
>  
>> 
>> 
>> 
>>> 
>>>  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”.
>>

Re: [Lsr] WG Adoption Call -draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

[Ketan Talaulikar]

Hi Acee,

Sorry for the late reply. Your naming proposal for the terminologies look
good to me.

Just one clarification - this draft will change the value of LinkMaxMetric
constant as defined in RFC6987/8770 from 0x to 0xfffe - is that correct?

Please also see inline below for a minor comment/clarification.


On Sun, Mar 10, 2024 at 3:07 AM Acee Lindem  wrote:

> 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.
>
> 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.
>
>
> 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.
>

KT> Since we are talking about the OSPF cost/metric here, it is not
possible to omit its advertisement. For OSPFv3 per RFC8363, the metric is
present in the fixed part of the Router Link TLV and thus cannot be
omitted. For OSPFv2, this omission was specified for the TE and delay
metrics in https://www.rfc-editor.org/rfc/rfc9350.html#section-15.3 but for
the IGP metric, it falls to the base specification. Now, it is debatable if
we could simply skip the "unreachable" link from the base OSPF Router LSA
and only advertise it in the OSPFv2 Extended Link LSA - this isn't
something that is explicitly specified as being handled as the "IGP metric"
being omitted. Since we anyway need LSLinkInfinity for OSPFv3, might as
well bring in the same for OSPFv2.

Thanks,
Ketan


>
>
>
>  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.
>
>
>
>
>> 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 path calculation,
>> will it cause the link also be excluded from the Flex-Algo path
>> computation? If not, will metric value 0x 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
>> (0x) 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 u

Re: [Lsr] WG Adoption Call-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

[Les Ginsberg (ginsberg)]

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

Re: [Lsr] WG Adoption Call-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

[Yingzhen Qu]

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 

Re: [Lsr] WG Adoption Call-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

[Liyan Gong]

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 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 path calculation, will it 
cause the link also be excluded from the Flex-Algo path computation? If not, 
will metric value 0x 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 (0x) 
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 tha

Re: [Lsr] WG Adoption Call -draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

[Dongjie (Jimmy)]

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.





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 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 path calculation, will it 
cause the link also be excluded from the Flex-Algo path computation? If not, 
will metric value 0x 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 (0x) 
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  requiremen

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[chen.ran]

Hi Yingzhen & WG，
I am not aware of any undisclosed IPR related to this document

Best Regards,
Ran











From: YingzhenQu 
To: lsr ;lsr-chairs ;
Date: 2024年02月23日 13:28
Subject: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link 
(02/23/24 - 03/08/24)

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr




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
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call -draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

[Gyan Mishra]

+1

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*



On Sat, Mar 9, 2024 at 4:37 PM Acee Lindem  wrote:

> 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.
>
> 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.
>
>
> 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.
>
>
>
>  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.
>
>
>
>
>> 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 path calculation,
>> will it cause the link also be excluded from the Flex-Algo path
>> computation? If not, will metric value 0x 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
>> (0x) 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.
>
> Thanks,
> Acee
>
>
>
> Best regards,
>>
>> Jie
>>
>>
>> *From:* Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Yingzhen Qu
>> *Sent:* Friday, February 23, 2024 1:28 PM
>> *To:* lsr ; lsr-chairs 
>> *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-lin

Re: [Lsr] WG Adoption Call -draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

[Acee Lindem]

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. 

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.
> 
> 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) 
> 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. 



>  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. 



>> 
>> 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 path calculation, will 
>> it cause the link also be excluded from the Flex-Algo path computation? If 
>> not, will metric value 0x 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 
>> (0x) 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. 

Thanks,
Acee



>> Best regards,
>> 
>> Jie
>> 
>>  
>> From: Lsr [mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>] On 
>> Behalf Of Yingzhen Qu
>> Sent: Friday, February 23, 2024 1:28 PM
>> To: lsr mailto:lsr@ietf.org>>; lsr-chairs 
>> mailto: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 awar

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

[Liyan Gong]

Hi Yingzhen and WG，



I support this adoption as a co-author and sincerely appreciate all your 
comments.  



The IPR has been disclosed in compliance with IETF IPR rules.



Best Regards,

Liyan





邮件原文发件人：Yingzhen Qu  收件人：lsr  
,lsr-chairs  抄　送: (无)发送时间：2024-02-23 
13:27:50主题：[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
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

[Liyan Gong]

Hi Les,




Thank you for your comments and providing RFC 5305 as a reference. 





We will review the entire document and update it to ensure a more accurate 
description. 





Best Regards,


Liyan







邮件原文发件人："Les Ginsberg \\(ginsberg\\)" 
收件人：Yingzhen Qu  
,lsr  ,lsr-chairs 抄　
送: (无)发送时间：2024-03-04 12:23:08主题：Re: [Lsr] WG Adoption Call - 
draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)


I support WG adoption of this draft.


Being able to advertise a link that is not used in the base SPF is a useful 
functionality to have.


 


I do think that the language currently used in the draft could be improved.


Currently the draft says:


 


“there are requirements to advertise unreachable


   links in OSPF for purposes other than building the normal Shortest


   Path Tree.”


 


The term “unreachable link” is a misnomer. If the link were truly unreachable 
it couldn’t be used for any purpose.


I would suggest the language be changed to more closely mimic RFC 5305:


 


“If a link is advertised with the maximum link metric (2^24 - 1), this


   link MUST NOT be considered during the normal SPF computation.  This


   will allow advertisement of a link for purposes other than building


   the normal Shortest Path Tree.”


 


“MUST NOT be considered” is a much more accurate description than “unreachable”.


 


I leave it to the authors to decide how best to revise the draft language.


 


   Les


 


 




From: Lsr  On Behalf Of Yingzhen Qu Sent: Thursday, 
February 22, 2024 9:28 PM To: lsr  lsr-chairs 
 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
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Les Ginsberg (ginsberg)]

I support WG adoption of this draft.
Being able to advertise a link that is not used in the base SPF is a useful 
functionality to have.

I do think that the language currently used in the draft could be improved.
Currently the draft says:

“there are requirements to advertise unreachable
   links in OSPF for purposes other than building the normal Shortest
   Path Tree.”

The term “unreachable link” is a misnomer. If the link were truly unreachable 
it couldn’t be used for any purpose.
I would suggest the language be changed to more closely mimic RFC 5305:

“If a link is advertised with the maximum link metric (2^24 - 1), this
   link MUST NOT be considered during the normal SPF computation.  This
   will allow advertisement of a link for purposes other than building
   the normal Shortest Path Tree.”

“MUST NOT be considered” is a much more accurate description than “unreachable”.

I leave it to the authors to decide how best to revise the draft language.

   Les


From: Lsr  On Behalf Of Yingzhen Qu
Sent: Thursday, February 22, 2024 9:28 PM
To: lsr ; lsr-chairs 
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
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[liu.yao71]

Hi, 

I support the adoption of this draft.

Regards,
Yao___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call -draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

[Liyan Gong]

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.





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. 



 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”.







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 path calculation, will it 
cause the link also be excluded from the Flex-Algo path computation? If not, 
will metric value 0x 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 (0x) 
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.


Best regards,


Jie


 




From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Yingzhen Qu Sent: Friday, 
February 23, 2024 1:28 PM To: lsr  lsr-chairs 
 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 
https://www.ietf.org/mailman/listinfo/lsr 


-- 




Gyan Mishra


Network Solutions Architect 


Email gyan.s.mis...@verizon.com


M 301 502-1347












___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

[Liyan Gong]

Hi Jie and Ketan，





Thank you both for the good discussion.


Yes, the intent of the document aligns completely with Ketan39s opinion.


Sorry for the confusion caused by the use-case description in the document 
sec2.2, and we will calrify this part in the next version.





Best Regards,


Liyan





邮件原文发件人：Ketan Talaulikar  收件人："Dongjie (Jimmy)" 
抄　送: Yingzhen Qu  
,lsr  ,lsr-chairs  
发送时间：2024-02-29 15:45:15主题：Re: [Lsr] WG Adoption Call - 
draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)Hi Jie,Regarding your 
point (2), my understanding is that this feature applies to OSPF cost (i.e., 
IGP metric) and as an extension is applicable to both the "base" SPF as well as 
any SPF computation (including FlexAlgo) that uses IGP metric. You are right, 
that the draft should clarify this. Moreover, the use-case description of 
flex-algo in section 2.2 is misleading - it can be achieved using this feature 
only if the flex-algo definition is using some metric type other than IGP 
metric.
The authors can correct my understanding.
Thanks,
Ketan



On Thu, Feb 29, 2024 at 1:01PM 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. 


 


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 path calculation, will it 
cause the link also be excluded from the Flex-Algo path computation? If not, 
will metric value 0x be used in the Flex-Algo computation? In other word, 
the interaction between  this new feature and Flex-Algo needs to be further 
elaborated. 


 


Best regards,


Jie


 




From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Yingzhen Qu Sent: Friday, 
February 23, 2024 1:28 PM To: lsr  lsr-chairs 
 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 
https://www.ietf.org/mailman/listinfo/lsr 



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

[Liyan Gong]

Hi Ketan,





Sorry for the the late reply.It took me some time to think about this issue. 


My previous description indeed only considered （b）and did not consider（a）， 
which was not comprehensive. Sorry for it. 


Including the consideration of the factor (a), I agree with your point that 
39UnreachableLinkMetric39 is easier to understand. 


We can update this in the next version using more accurate name to express 
0x and 0xfffe as well as the new flag. Thank you very much.





Best Regards,


Liyan






邮件原文发件人：Ketan Talaulikar  收件人：Liyan Gong  
抄　送: Acee Lindem  ,Yingzhen Qu  
,lsr  ,lsr-chairs  
发送时间：2024-02-29 12:16:44主题：Re: [Lsr] WG Adoption 
Call-draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)Hi Liyan,My email 
below brings out two aspects. You have responded to (b) but are silent on (a).
On (b), what the authors are proposing is a change in semantics of an existing 
term MaxLinkMetric (as proposed by 6987/8770) and introducing new term 
MaxUsableLinkMetric with the same meaning as what used to be MaxLinkMetric (per 
6987/8770). I am suggesting that we keep the semantics of the existing term 
MaxLinkMetric unchanged (only the value changes from 0x -> 0xfffe) while a 
new term UnreachableLinkMetric (or something like that) is used for the new 
"unreachable link metric" semantics being introduced by the document. 
My logic for this suggestion is to avoid the scenario when someone refers to 
"MaxLinkMetric" ... a question follows ... Well, are you referring to 
MaxLinkMetric in RFC6987/8770 or RFC?  This is entirely avoidable.
While it would be good to conclude this thread at this stage, if the authors 
feel very strongly against these changes ((a) and (b)), we can perhaps continue 
this debate post WG adoption and seek input from other WG members on this.
Thanks,
Ketan



On Wed, Feb 28, 2024 at 2:09PM Liyan Gong  wrote:
Hi Ketan,

Thank you very much for your comments. I39m trying to understand your point.

 

The core idea is to differentiate between these two values, 0x and 0xfffe. 

One represents unreachable, and the other signifies the maximum value (cannot 
transmit traffic).

 

Based on Acee39s explanation, where the new term MaxUsableLinkMetric represents 
0xfffe and also updates 8770, 

I think these two concepts can now be distinguished, and therefore, there is no 
need to introduce UnreachableLinkMetric.



If I have misunderstood, I would greatly appreciate your correction. Thanks 
again.

 

Best Regards,

Liyan





邮件原文发件人：Ketan Talaulikar  收件人：Acee Lindem  
抄　送: Yingzhen Qu  ,lsr  
,lsr-chairs  发送时间：2024-02-28 15:43:10主题：Re: 
[Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link(02/23/24 - 
03/08/24)Hi Acee,Thanks for your quick response. On the point (1), there are 
actually two aspects:
a) The name of the capability itself - "MaxLinkMetric support" seems odd to me 
since all implementations do support setting this metric value already. Perhaps 
"UnreachableLinkMetric support" (or something like that) seems more meaningful 
since it talks about the support for treating links with this metric value as 
unreachable. After all, the name of this "feature" and the "draft" says 
"unreachable link"?
b) The term MaxLinkMetric was defined in RFC6987/8770 to have a different 
meaning. This draft can "update" the value of that term (to 0xfffe) without 
changing its semantics. However, it would be better to define a new term 
UnreachableLinkMetric for this feature to avoid mixing of the semantics of the 
two terms. We do need both those terms/features, right?
Hope this clarifies.
Thanks,
Ketan



On Wed, Feb 28, 2024 at 12:00AM Acee Lindem  wrote:
Hi Ketan, On Feb 27, 2024, at 08:16, Ketan Talaulikar  
wrote:
Hello,I support the adoption of this document by the WG since it is a useful 
OSPF protocol extension.
I have the following comments for the authors to consider (post adoption):
1) Suggest to rename the capability bit to UnreachableLinkMetric to clearly 
distinguish it from all previous use of MaxMetric in OSPF. Also suggest to use 
this term through the document where the purpose is to mark the link as 
unreachable.


I’m not sure I understand why there would be any confusion between MaxMetric 
and MaxLinkMetric. In OSPF, we are using MaxMetric as unreachable so this 
change would just be for the corner case of OSPFv2 stub router. So, it seems to 
be consistent we should stick with MaxLinkMetric to be unreachable. 
2) This document should introduce a new MaxLinkMetric which is 0xfffe which can 
be then used as a "link of last resort" as specified in RFC6987.


The document requires use of RFC 8770 for OSPFv2 Stub Router support.  We could 
call this MaxUsableLinkMetric for this new constant. 
3) Section 3: There is no OSPF cost/metric in OSPFv2 Extended Link LSA. Also, 
not sure why the base OSPFv3 5340 has been excluded from this li

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[梁艳荣]

Hi Chair and WG,

I support the adoption of the draft as a WG document.
As a contributor, I'm not aware of any IPR that applies to this draft.

thanks,
Yanrong

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
Yingzhen Qu
Sent: Friday, February 23, 2024 1:28 PM
To: lsr <lsr@ietf.org>; lsr-chairs 
<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/<http://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
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Gyan Mishra]

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.

 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”.

> 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 path calculation, will
> it cause the link also be excluded from the Flex-Algo path computation? If
> not, will metric value 0x 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
> (0x) 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.
>
> Best regards,
>
> Jie
>
>
>
> *From:* Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Yingzhen Qu
> *Sent:* Friday, February 23, 2024 1:28 PM
> *To:* lsr ; lsr-chairs 
> *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
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Ketan Talaulikar]

Hi Jie,

Regarding your point (2), my understanding is that this feature applies to
OSPF cost (i.e., IGP metric) and as an extension is applicable to both the
"base" SPF as well as any SPF computation (including FlexAlgo) that uses
IGP metric. You are right, that the draft should clarify this. Moreover,
the use-case description of flex-algo in section 2.2 is misleading - it can
be achieved using this feature only if the flex-algo definition is using
some metric type other than IGP metric.

The authors can correct my understanding.

Thanks,
Ketan


On Thu, Feb 29, 2024 at 1:01 PM 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.
>
>
>
> 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 path calculation, will
> it cause the link also be excluded from the Flex-Algo path computation? If
> not, will metric value 0x be used in the Flex-Algo computation? In
> other word, the interaction between this new feature and Flex-Algo needs to
> be further elaborated.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Yingzhen Qu
> *Sent:* Friday, February 23, 2024 1:28 PM
> *To:* lsr ; lsr-chairs 
> *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
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Dongjie (Jimmy)]

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.



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 path calculation, will it 
cause the link also be excluded from the Flex-Algo path computation? If not, 
will metric value 0x be used in the Flex-Algo computation? In other word, 
the interaction between this new feature and Flex-Algo needs to be further 
elaborated.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Yingzhen Qu
Sent: Friday, February 23, 2024 1:28 PM
To: lsr ; lsr-chairs 
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
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[zhang.zheng]

Support the adoption of this draft. 
Thanks,
Sandy










Original


From: YingzhenQu 
To: lsr ;lsr-chairs ;
Date: 2024年02月23日 13:28
Subject: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link 
(02/23/24 - 03/08/24)


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr




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
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call -draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

[Ketan Talaulikar]

Hi Liyan,

My email below brings out two aspects. You have responded to (b) but are
silent on (a).

On (b), what the authors are proposing is a change in semantics of an
existing term MaxLinkMetric (as proposed by 6987/8770) and introducing new
term MaxUsableLinkMetric with the same meaning as what used to be
MaxLinkMetric (per 6987/8770). I am suggesting that we keep the semantics
of the existing term MaxLinkMetric unchanged (only the value changes from
0x -> 0xfffe) while a new term UnreachableLinkMetric (or something like
that) is used for the new "unreachable link metric" semantics being
introduced by the document.

My logic for this suggestion is to avoid the scenario when someone refers
to "MaxLinkMetric" ... a question follows ... Well, are you referring to
MaxLinkMetric in RFC6987/8770 or RFC?  This is entirely avoidable.

While it would be good to conclude this thread at this stage, if the
authors feel very strongly against these changes ((a) and (b)), we can
perhaps continue this debate post WG adoption and seek input from other WG
members on this.

Thanks,
Ketan

On Wed, Feb 28, 2024 at 2:09 PM Liyan Gong 
wrote:

> Hi Ketan,
>
> Thank you very much for your comments. I'm trying to understand your point.
>
>
>
> The core idea is to differentiate between these two values, 0x and
> 0xfffe.
>
> One represents unreachable, and the other signifies the maximum value
> (cannot transmit traffic).
>
>
>
> Based on Acee's explanation, where the new term MaxUsableLinkMetric
> represents 0xfffe and also updates 8770,
>
> I think these two concepts can now be distinguished, and therefore, there
> is no need to introduce UnreachableLinkMetric.
>
>
> If I have misunderstood, I would greatly appreciate your correction.
> Thanks again.
>
>
>
> Best Regards,
>
> Liyan
>
>
>
> 邮件原文
> *发件人：*Ketan Talaulikar  
> *收件人：*Acee Lindem  
> *抄 送: *Yingzhen Qu  ,lsr   >,lsr-chairs  
> *发送时间：*2024-02-28 15:43:10
> *主题：*
> Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link(02/23/24 - 
> 03/08/24)
>
> Hi Acee,
> Thanks for your quick response. On the point (1), there are actually two
> aspects:
>
> a) The name of the capability itself - "MaxLinkMetric support" seems odd
> to me since all implementations do support setting this metric value
> already. Perhaps "UnreachableLinkMetric support" (or something like that)
> seems more meaningful since it talks about the support for treating links
> with this metric value as unreachable. After all, the name of this
> "feature" and the "draft" says "unreachable link"?
>
> b) The term MaxLinkMetric was defined in RFC6987/8770 to have a different
> meaning. This draft can "update" the value of that term (to 0xfffe) without
> changing its semantics. However, it would be better to define a new term
> UnreachableLinkMetric for this feature to avoid mixing of the semantics of
> the two terms. We do need both those terms/features, right?
>
> Hope this clarifies.
>
> Thanks,
> Ketan
>
> On Wed, Feb 28, 2024 at 12:00AM Acee Lindem  wrote:
>
>> Hi Ketan,
>>
>> On Feb 27, 2024, at 08:16, Ketan Talaulikar 
>> wrote:
>>
>> Hello,
>> I support the adoption of this document by the WG since it is a useful
>> OSPF protocol extension.
>>
>> I have the following comments for the authors to consider (post adoption):
>>
>> 1) Suggest to rename the capability bit to UnreachableLinkMetric to
>> clearly distinguish it from all previous use of MaxMetric in OSPF. Also
>> suggest to use this term through the document where the purpose is to mark
>> the link as unreachable.
>>
>>
>> I’m not sure I understand why there would be any confusion between
>> MaxMetric and MaxLinkMetric. In OSPF, we are using MaxMetric as unreachable
>> so this change would just be for the corner case of OSPFv2 stub router. So,
>> it seems to be consistent we should stick with MaxLinkMetric to be
>> unreachable.
>>
>>
>>
>>
>>
>> 2) This document should introduce a new MaxLinkMetric which is 0xfffe
>> which can be then used as a "link of last resort" as specified in RFC6987.
>>
>>
>>
>> The document requires use of RFC 8770 for OSPFv2 Stub Router support.  We
>> could call this MaxUsableLinkMetric for this new constant.
>>
>>
>>
>>
>> 3) Section 3: There is no OSPF cost/metric in OSPFv2 Extended Link LSA.
>> Also, not sure why the base OSPFv3 5340 has been excluded from this list
>> where the Router LSA carries the link cost similar to OSPFv2.
>>
>>
>&g

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[chen.ran]

Hi WG,

I support the adoption of this draft as co-author.
In some scenarios(For details, see section 2), it is very necessary to 
advertise unreachable links in OSPF.

Best Regards,
Ran


Original


From: YingzhenQu 
To: lsr ;lsr-chairs ;
Date: 2024年02月23日 13:28
Subject: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link 
(02/23/24 - 03/08/24)

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr




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
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call -draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)

[Liyan Gong]

Hi Ketan,

Thank you very much for your comments. I39m trying to understand your point.

 

The core idea is to differentiate between these two values, 0x and 0xfffe. 

One represents unreachable, and the other signifies the maximum value (cannot 
transmit traffic).

 

Based on Acee39s explanation, where the new term MaxUsableLinkMetric represents 
0xfffe and also updates 8770, 

I think these two concepts can now be distinguished, and therefore, there is no 
need to introduce UnreachableLinkMetric.



If I have misunderstood, I would greatly appreciate your correction. Thanks 
again.

 

Best Regards,

Liyan





邮件原文发件人：Ketan Talaulikar  收件人：Acee Lindem  
抄　送: Yingzhen Qu  ,lsr  
,lsr-chairs  发送时间：2024-02-28 15:43:10主题：Re: 
[Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link(02/23/24 - 
03/08/24)Hi Acee,Thanks for your quick response. On the point (1), there are 
actually two aspects:
a) The name of the capability itself - "MaxLinkMetric support" seems odd to me 
since all implementations do support setting this metric value already. Perhaps 
"UnreachableLinkMetric support" (or something like that) seems more meaningful 
since it talks about the support for treating links with this metric value as 
unreachable. After all, the name of this "feature" and the "draft" says 
"unreachable link"?
b) The term MaxLinkMetric was defined in RFC6987/8770 to have a different 
meaning. This draft can "update" the value of that term (to 0xfffe) without 
changing its semantics. However, it would be better to define a new term 
UnreachableLinkMetric for this feature to avoid mixing of the semantics of the 
two terms. We do need both those terms/features, right?
Hope this clarifies.
Thanks,
Ketan



On Wed, Feb 28, 2024 at 12:00AM Acee Lindem  wrote:
Hi Ketan, On Feb 27, 2024, at 08:16, Ketan Talaulikar  
wrote:
Hello,I support the adoption of this document by the WG since it is a useful 
OSPF protocol extension.
I have the following comments for the authors to consider (post adoption):
1) Suggest to rename the capability bit to UnreachableLinkMetric to clearly 
distinguish it from all previous use of MaxMetric in OSPF. Also suggest to use 
this term through the document where the purpose is to mark the link as 
unreachable.


I’m not sure I understand why there would be any confusion between MaxMetric 
and MaxLinkMetric. In OSPF, we are using MaxMetric as unreachable so this 
change would just be for the corner case of OSPFv2 stub router. So, it seems to 
be consistent we should stick with MaxLinkMetric to be unreachable. 
2) This document should introduce a new MaxLinkMetric which is 0xfffe which can 
be then used as a "link of last resort" as specified in RFC6987.


The document requires use of RFC 8770 for OSPFv2 Stub Router support.  We could 
call this MaxUsableLinkMetric for this new constant. 
3) Section 3: There is no OSPF cost/metric in OSPFv2 Extended Link LSA. Also, 
not sure why the base OSPFv3 5340 has been excluded from this list where the 
Router LSA carries the link cost similar to OSPFv2.


Agreed. 
4) This document should formally update the base OSPFv2/v3 RFCs since it 
changes the SPF.


Agreed - It should also update RFC 8770. 
Thanks,
Acee
I hope this helps.
Thanks,
Ketan



On Fri, Feb 23, 2024 at 10:58AM Yingzhen Qu  wrote:
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 
https://www.ietf.org/mailman/listinfo/lsr 
___Lsr mailing 
listLsr@ietf.orghttps://www.ietf.org/mailman/listinfo/lsr






___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Ketan Talaulikar]

Hi Acee,

Thanks for your quick response. On the point (1), there are actually two
aspects:

a) The name of the capability itself - "MaxLinkMetric support" seems odd to
me since all implementations do support setting this metric value already.
Perhaps "UnreachableLinkMetric support" (or something like that) seems more
meaningful since it talks about the support for treating links with this
metric value as unreachable. After all, the name of this "feature" and the
"draft" says "unreachable link"?

b) The term MaxLinkMetric was defined in RFC6987/8770 to have a different
meaning. This draft can "update" the value of that term (to 0xfffe) without
changing its semantics. However, it would be better to define a new term
UnreachableLinkMetric for this feature to avoid mixing of the semantics of
the two terms. We do need both those terms/features, right?

Hope this clarifies.

Thanks,
Ketan

On Wed, Feb 28, 2024 at 12:00 AM Acee Lindem  wrote:

> Hi Ketan,
>
> On Feb 27, 2024, at 08:16, Ketan Talaulikar  wrote:
>
> Hello,
>
> I support the adoption of this document by the WG since it is a useful
> OSPF protocol extension.
>
> I have the following comments for the authors to consider (post adoption):
>
> 1) Suggest to rename the capability bit to UnreachableLinkMetric to
> clearly distinguish it from all previous use of MaxMetric in OSPF. Also
> suggest to use this term through the document where the purpose is to mark
> the link as unreachable.
>
>
> I’m not sure I understand why there would be any confusion between
> MaxMetric and MaxLinkMetric. In OSPF, we are using MaxMetric as unreachable
> so this change would just be for the corner case of OSPFv2 stub router. So,
> it seems to be consistent we should stick with MaxLinkMetric to be
> unreachable.
>
>
>
>
>
> 2) This document should introduce a new MaxLinkMetric which is 0xfffe
> which can be then used as a "link of last resort" as specified in RFC6987.
>
>
>
> The document requires use of RFC 8770 for OSPFv2 Stub Router support.  We
> could call this MaxUsableLinkMetric for this new constant.
>
>
>
>
> 3) Section 3: There is no OSPF cost/metric in OSPFv2 Extended Link LSA.
> Also, not sure why the base OSPFv3 5340 has been excluded from this list
> where the Router LSA carries the link cost similar to OSPFv2.
>
>
> Agreed.
>
>
>
> 4) This document should formally update the base OSPFv2/v3 RFCs since it
> changes the SPF.
>
>
> Agreed - It should also update RFC 8770.
>
> Thanks,
> Acee
>
>
>
>
> I hope this helps.
>
> Thanks,
> Ketan
>
>
> On Fri, Feb 23, 2024 at 10:58 AM Yingzhen Qu 
> wrote:
>
>> 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
>> https://www.ietf.org/mailman/listinfo/lsr
>>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Acee Lindem]

Hi Ketan, 

> On Feb 27, 2024, at 08:16, Ketan Talaulikar  wrote:
> 
> Hello,
> 
> I support the adoption of this document by the WG since it is a useful OSPF 
> protocol extension.
> 
> I have the following comments for the authors to consider (post adoption):
> 
> 1) Suggest to rename the capability bit to UnreachableLinkMetric to clearly 
> distinguish it from all previous use of MaxMetric in OSPF. Also suggest to 
> use this term through the document where the purpose is to mark the link as 
> unreachable.

I’m not sure I understand why there would be any confusion between MaxMetric 
and MaxLinkMetric. In OSPF, we are using MaxMetric as unreachable so this 
change would just be for the corner case of OSPFv2 stub router. So, it seems to 
be consistent we should stick with MaxLinkMetric to be unreachable. 




> 
> 2) This document should introduce a new MaxLinkMetric which is 0xfffe which 
> can be then used as a "link of last resort" as specified in RFC6987.


The document requires use of RFC 8770 for OSPFv2 Stub Router support.  We could 
call this MaxUsableLinkMetric for this new constant. 



> 
> 3) Section 3: There is no OSPF cost/metric in OSPFv2 Extended Link LSA. Also, 
> not sure why the base OSPFv3 5340 has been excluded from this list where the 
> Router LSA carries the link cost similar to OSPFv2.

Agreed. 


> 
> 4) This document should formally update the base OSPFv2/v3 RFCs since it 
> changes the SPF.

Agreed - It should also update RFC 8770. 

Thanks,
Acee



> 
> I hope this helps.
> 
> Thanks,
> Ketan
> 
> 
> On Fri, Feb 23, 2024 at 10:58 AM Yingzhen Qu  > wrote:
>> 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 
>> https://www.ietf.org/mailman/listinfo/lsr
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Ketan Talaulikar]

Hello,

I support the adoption of this document by the WG since it is a useful OSPF
protocol extension.

I have the following comments for the authors to consider (post adoption):

1) Suggest to rename the capability bit to UnreachableLinkMetric to clearly
distinguish it from all previous use of MaxMetric in OSPF. Also suggest to
use this term through the document where the purpose is to mark the link as
unreachable.

2) This document should introduce a new MaxLinkMetric which is 0xfffe which
can be then used as a "link of last resort" as specified in RFC6987.

3) Section 3: There is no OSPF cost/metric in OSPFv2 Extended Link LSA.
Also, not sure why the base OSPFv3 5340 has been excluded from this list
where the Router LSA carries the link cost similar to OSPFv2.

4) This document should formally update the base OSPFv2/v3 RFCs since it
changes the SPF.

I hope this helps.

Thanks,
Ketan


On Fri, Feb 23, 2024 at 10:58 AM Yingzhen Qu 
wrote:

> 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
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Lihao]

Hi WG & Chairs

I support the adoption of this draft.

Best Wishes.

发件人: Lsr mailto:lsr-boun...@ietf.org>> 代表 Yingzhen Qu
发送时间: 2024年2月23日 13:28
收件人: lsr mailto:lsr@ietf.org>>; lsr-chairs 
mailto:lsr-cha...@ietf.org>>
主题: [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

-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[hantingt...@chinamobile.com]

Hi all,

I have reviewed the draft and support the adoption of the draft. The 
document proposes a basic mechanism for identifying unreachable OSPF links. It 
is a good mechanism consistent with IS-IS and easy to deploy.

Thanks,
Tingting Han

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Mengxiao.Chen]

Hi Yingzhen,

I am not aware of any IPR related to this document.

Thanks,
Mengxiao

From: Lsr  On Behalf Of Yingzhen Qu
Sent: Friday, February 23, 2024 1:28 PM
To: lsr ; lsr-chairs 
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

-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[王亚蓉]

Hi, 
I support the adoption of the draft as a WG document. 


thanks, 
Yarong 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[chen.ran]

Hi Yingzhen & WG，

I am not aware of any IPRs that applies to the draft. .

Best Regards,
Ran


Original


From: YingzhenQu 
To: lsr ;lsr-chairs ;
Date: 2024年02月23日 13:28
Subject: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link 
(02/23/24 - 03/08/24)

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr




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
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[linchangwang]

Hi,

I support adoption.

As a co-author, I’m unaware of any IPR on the document.



Thanks,

Changwang


发件人: Lsr  代表 Yingzhen Qu
发送时间: 2024年2月23日 13:28
收件人: lsr ; lsr-chairs 
主题: [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

-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Gyan Mishra]

I support adoption.


Thanks



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*



On Fri, Feb 23, 2024 at 12:28 AM Yingzhen Qu 
wrote:

> 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
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Qiuyuanxiang]

Hi all,
I have reviewed the draft and support the adoption of the draft.

Thanks,
Yuanxiang

From: Lsr  On Behalf Of Yingzhen Qu
Sent: Friday, February 23, 2024 1:28 PM
To: lsr ; lsr-chairs 
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

-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Acee Lindem]

As one would expect from  a co-author, I also support adoption. The primary 
reasons to use an infinite link metric are:


   1. It is consistent with the infinite metric usage for prefixes. 
   2. Usage of an infinite metric in Router-LSAs, provides a solution which 
doesn’t require accessing
   the OSPF Opaque Extended Link Attribute TLV for the base topology SPF. 
3. Implementation simplicity (#2) will facilitate adoption.

Thanks,
Acee 

> On Feb 23, 2024, at 12:27 AM, Yingzhen Qu  wrote:
> 
> 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
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Acee Lindem]

As a co-author, I’m unaware of any IPR on the document.

Thanks,
Acee

> On Feb 23, 2024, at 12:27 AM, Yingzhen Qu  wrote:
> 
> 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
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Feng Yang]

Hi,

I support the adoption of this draft.

在 2024-02-23 13:27, Yingzhen Qu 写道:
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


--
BR,
Feng Yang （杨锋）
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Huzhibo]

I support the adoption of the draft as a WG document.

thanks,
Zhibo
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Yingzhen Qu
Sent: Friday, February 23, 2024 1:28 PM
To: lsr ; lsr-chairs 
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
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Peter Psenak]

I support the adoption of the draft as a WG document.

thanks,
Peter

On 23/02/2024 06:27, Yingzhen Qu wrote:
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
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)

[Yingzhen Qu]

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
https://www.ietf.org/mailman/listinfo/lsr