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 that 
case in order to avoid best effort traffic from going 

Re: [Lsr] Tsvart early review of draft-ietf-lsr-isis-fast-flooding-06

[Mirja Kuehlewind (IETF)]

Hi Bruno,

Sorry for my late reply. These weeks are busy...

See below.

> On 4. Mar 2024, at 16:59, bruno.decra...@orange.com wrote:
> 
> Hi Mirja,
> 
> Thanks for your follow up on this and your time
> Please see inline [Bruno3]
> 
>> -Original Message-
>> From: Mirja Kuehlewind (IETF)  
>> Sent: Thursday, February 29, 2024 3:30 PM
>> To: DECRAENE Bruno INNOV/NET 
>> Cc: Les Ginsberg (ginsberg) ; 
>> gsoli...@protonmail.com; draft-ietf-lsr-isis-fast-flooding@ietf.org; 
>> lsr@ietf.org; tsv-...@ietf.org
>> Subject: Re: [Lsr] Tsvart early review of 
>> draft-ietf-lsr-isis-fast-flooding-06
>> 
>> Hi Bruno,
>> 
>> Sorry for my late reply.
>> 
>> Please see some more comments below.
>> 
>>> On 9. Feb 2024, at 21:50, bruno.decra...@orange.com wrote:
>>> 
>>> Hi Mirja,
>>> 
>>> Thanks for your replies. Please see inline [Bruno2]
>>> 
>>> On a side note, we have presented some tests results at IETF 111. If you 
>>> want to have a look at them, please find below the slides. If you have some 
>>> comments on the tests results, I would be obviously interested in your 
>>> comments. Either on the list or of the list.
>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
>>> tracker.ietf.org%2Fmeeting%2F111%2Fmaterials%2Fslides-111-lsr-22-flow-
>>> congestion-control-00.pdf=05%7C02%7Cbruno.decraene%40orange.com%7
>>> C2a11513881214cd239fd08dc3932fc06%7C90c7a20af34b40bfbc48b9253b6f5d20%7
>>> C0%7C0%7C638448138656092668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
>>> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=A2
>>> cRtfmaAgWVdE3S0KeNnlfyQfEgNsxIxHSNowwOQe0%3D=0
>>> 
>>> 
>>> 
 From: Lsr mailto:lsr-boun...@ietf.org>> On 
 Behalf Of Mirja Kuehlewind (IETF)
 Sent: Thursday, February 8, 2024 2:06 PM
 
 Hi Bruno,
 
 Thanks for your replies.
 
 On the high-level I think that some or most of the explanation you provide 
 me below about parameter values, should actually go into the draft. I 
 understand that there is not a one fits all but that's why min/max values 
 are often more important than recommended values. Yes, these might also 
 not hold forever but maybe that just mean there is a point in future where 
 it makes sense to update this RFC. Also you say it depends on the 
 performance/capability of the router, however, I think you can say 
 something like: with an average router today with these performance 
 parameters, these are our tested values that showed good performance and 
 also this and that value can e.g. scale with e.g. more CPU power. 
 Something like this.
 
 See further below.
>>> 
>>> [Bruno2] OK. See further below.
>>> 
> On 5. Feb 2024, at 19:17, bruno.decra...@orange.com 
>  wrote:
> 
> [+Les, Guillaume as we go quite deep in the discussion]
> 
> Hi Mirja,
> 
> Thank you for your review and comments. Very useful.
> 
> Please see inline [Bruno]
> 
>> From: Mirja Kühlewind via Datatracker > >
>> Sent: Friday, February 2, 2024 3:57 PM
>> 
>> Reviewer: Mirja Kühlewind
>> Review result: Not Ready
>> 
>> First of all I have a clarification question: The use the of flags TLV 
>> with the O flag is not clear to me. Is that also meant as a 
>> configuration parameter or is that supposed to be a subTLV that has to 
>> be sent together with the PSNP? If it is a configuration, doesn't the 
>> receiver need to confirm that the configuration is used and how does 
>> that work in the LAN scenario where multiple configurations are used? If 
>> it has to be sent together with the PSNP, this needs to be clarified and 
>> it seem a bit strange to me that it is part of the same TLV. Or maybe 
>> I'm missing something completely about the flag?
> 
> [Bruno] The O-flag is advertised by the receiver in the Flags sub-TLV, 
> which may be sent either in PSNP or IIH.
> That's not a configuration but a capability of the receiver which is 
> signaled to the sender.
> That's only applicable to the point-to-point scenario, not the LAN 
> scenario. ( as on a LAN there is no explicit acknowledgment of the 
> receipt of LSPs between a given LSP transmitter and a given LSP receiver).
> 
>> it seem a bit strange to me that it is part of the same TLV
> 
> [Bruno]
> All those sub-TLVs, at least the one currently defined, carries
> (relatively) static parameters and are not required to be sent in all IIH 
> or PSNP. The way IS-IS acknowledges the reception of LSP is not changed 
> They are all grouped in a single TLV called " Flooding Parameters TLV" 
> for grouping purpose and also because IS-IS has a limited TLV space.
> If the above does not clarify, could you please elaborate on what you 
> feel "strange" about?
 
 Okay, it a capability. Does that mean 

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

LSLinkInfinity would exclude the link from a flex algorithm as well. However, 
the correct way to exclude it by 

Re: [Lsr] IPR Poll for draft-gong-lsr-ospf-unreachable-link

[linchangwang]

Hi Yingzhen & WG，

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

Best Regards,
Changwang


发件人: Lsr  代表 Yingzhen Qu
发送时间: 2024年3月9日 8:58
收件人: draft-gong-lsr-ospf-unreachable-l...@ietf.org; lsr ; 
lsr-chairs 
主题: [Lsr] IPR Poll for draft-gong-lsr-ospf-unreachable-link

Hi all,

There is an IPR disclosure filed for this draft on 3/8/2024:
IPR disclosures 
(ietf.org)

Also not all authors have responded to the IPR poll in the adoption call 
thread, so I'd like to ask all the authors and contributors to answer in this 
thread. The draft won't progress without answers from all authors and 
contributors.


Please state either:

"No, I'm not aware of any IPR that applies to this draft"

or

"Yes, I'm aware of IPR that applies to this draft"



If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3669, 5378 and 8179 for more details)?



If yes to the above, please state either:



"Yes, the IPR has been disclosed in compliance with IETF IPR rules"

or

"No, the IPR has not been disclosed"



If you answer no, please provide any additional details you think

appropriate.



If you are listed as a document author or contributor please answer the

above by responding to this email regardless of whether or not you are

aware of any relevant IPR. This document will not advance to the next

stage until a response has been received from each author.



Thanks,

Yingzhen

-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
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] IPR Poll for draft-gong-lsr-ospf-unreachable-link

[Mengxiao.Chen]

Hi Yingzhen,

No, I'm not aware of any IPR that applies to this draft.

Thanks,
Mengxiao

From: Lsr  On Behalf Of Yingzhen Qu
Sent: Saturday, March 9, 2024 8:58 AM
To: draft-gong-lsr-ospf-unreachable-l...@ietf.org; lsr ; 
lsr-chairs 
Subject: [Lsr] IPR Poll for draft-gong-lsr-ospf-unreachable-link

Hi all,

There is an IPR disclosure filed for this draft on 3/8/2024:
IPR disclosures 
(ietf.org)

Also not all authors have responded to the IPR poll in the adoption call 
thread, so I'd like to ask all the authors and contributors to answer in this 
thread. The draft won't progress without answers from all authors and 
contributors.


Please state either:

"No, I'm not aware of any IPR that applies to this draft"

or

"Yes, I'm aware of IPR that applies to this draft"



If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3669, 5378 and 8179 for more details)?



If yes to the above, please state either:



"Yes, the IPR has been disclosed in compliance with IETF IPR rules"

or

"No, the IPR has not been disclosed"



If you answer no, please provide any additional details you think

appropriate.



If you are listed as a document author or contributor please answer the

above by responding to this email regardless of whether or not you are

aware of any relevant IPR. This document will not advance to the next

stage until a response has been received from each author.



Thanks,

Yingzhen

-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
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] IPR Poll for draft-gong-lsr-ospf-unreachable-link

[chen.ran]

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

Best Regards,
Ran







---
发件人：Yingzhen Qu  
收件人：draft-gong-lsr-ospf-unreachable-link 
,lsr  ,lsr-chairs  

抄　送: (无)
发送时间：2024-03-09 08:58:25
主题：[Lsr] IPR Poll for draft-gong-lsr-ospf-unreachable-link

Hi all,
There is an IPR disclosure filed for this draft on 3/8/2024: 
IPR disclosures (ietf.org)


Also not all authors have responded to the IPR poll in the adoption call 
thread, so I'd like to ask all the authors and contributors to answer in this 
thread. The draft won't progress without answers from all authors and 
contributors.

Please state either: "No, I'm not aware of any IPR that applies to this draft" 
or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been 
disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for 
more details)? If yes to the above, please state either: "Yes, the IPR has been 
disclosed in compliance with IETF IPR rules" or "No, the IPR has not been 
disclosed" If you answer no, please provide any additional details you think 
appropriate. If you are listed as a document author or contributor please 
answer the above by responding to this email regardless of whether or not you 
are aware of any relevant IPR. This document will not advance to the next stage 
until a response has been received from each author.
Thanks,Yingzhen___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Lsr] Re： IPR Poll for draft-gong-lsr-ospf-unreachable-link

[梁艳荣]

Hi Yingzhen,

As a co-contributor, my answer is:
No, I'm not aware of any IPR that applies to this draft.

Best Regards,
Yanrong

邮件原文
发件人：Yingzhen Qu  
收件人：draft-gong-lsr-ospf-unreachable-link 
,lsr  ,lsr-chairs  

抄　送: (无)
发送时间：2024-03-09 08:58:25
主题：[Lsr] IPR Poll for draft-gong-lsr-ospf-unreachable-link

Hi all,

There is an IPR disclosure filed for this draft on 3/8/2024: 
IPR disclosures 
(ietf.org)

Also not all authors have responded to the IPR poll in the adoption call 
thread, so I'd like to ask all the authors and contributors to answer in this 
thread. The draft won't progress without answers from all authors and 
contributors.

Please state either:
"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

Thanks,
Yingzhen___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IPR Poll for draft-gong-lsr-ospf-unreachable-link

[Liyan Gong]

Hi Yingzhen,



As a co-author, my answer is:


Yes, the IPR has been disclosed in compliance with IETF IPR rules.


Best Regards,

Liyan







邮件原文发件人：Yingzhen Qu  
收件人：draft-gong-lsr-ospf-unreachable-link 
,lsr  ,lsr-chairs  
抄　送: (无)发送时间：2024-03-09 08:58:25主题：[Lsr] IPR Poll for 
draft-gong-lsr-ospf-unreachable-linkHi all,There is an IPR disclosure filed for 
this draft on 3/8/2024: 
IPR disclosures (ietf.org)
Also not all authors have responded to the IPR poll in the adoption call 
thread, so I39d like to ask all the authors and contributors to answer in this 
thread. The draft won39t progress without answers from all authors and 
contributors.
Please state either:
"No, I39m not aware of any IPR that applies to this draft"
or
"Yes, I39m aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.Thanks,Yingzhen






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