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  <[email protected]>收件人:"Dongjie (Jimmy)" 
<[email protected]>抄 送: Yingzhen Qu  
<[email protected]>,lsr  <[email protected]>,lsr-chairs  
<[email protected]>发送时间:2024-03-01 11:27:32主题:Re: [Lsr] WG Adoption Call - 
draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)Hi Jie 
Some answers in-line 


On Thu, Feb 29, 2024 at 2:31 AM Dongjie (Jimmy) 
<[email protected]> wrote:


Hi Yingzhen, 


 


I’ve read the latest version of this document and support its adoption.  It is 
a useful feature in general to exclude some of the links from SPF  computation. 


 


I also have some comments for the authors to consider, they can be solved after 
the adoption. 


 


1.       I’m not sure the purpose is to advertise an unreachable link in OSPF, 
from the use cases in the draft, the link is still reachable and  can be used 
for some services, just it needs be excluded from normal SPF calculation. If 
this is correct, it is better the title of the draft and the name of the new 
capability Flag need to be updated to reflect this. 



 Gyan> I agree with you and that is as well stated in the draft that 
MaxLinkMetric (0xFFFF) does not exclude the link from SPF and thus requires RI 
LSA with capability bit set for MaxLinkMetric (0xFFFF) for link to be excluded 
from SPF. Maybe “OSPF RI Capability LSA”.







2.       In the Flex-Algo use case, if the metric of a link is set to 
MaxLinkMetric (0xFFFF) to exclude it from normal SPF computation, while a  
Flex-Algo is defined to use the same metric type for path calculation, will it 
cause the link also be excluded from the Flex-Algo path computation? If not, 
will metric value 0xFFFF be used in the Flex-Algo computation? In other word, 
the interaction between  this new feature and Flex-Algo needs to be further 
elaborated. 


    Gyan>  I agree that the RI LSA capability flag for MaxLinkMetric (0xFFFF) 
is applicable to base Algo 0 and any Algo.  However AFAIK you would have to 
explicitly set the RI flag the particular Algo.  The use case described in this 
draft is when you are using flex algo for network slicing meaning you have both 
algo 0 and 128 on the same links and not a separate sub topology and in that 
case in order to avoid best effort traffic from going over the same link used 
for algo 128  you would need to use this RI capability flag.  This concept we 
have talked about comes into play of degree of network slicing and isolation to 
meet SLO SLE  requirements.


Best regards,


Jie


 




From: Lsr [mailto:[email protected]] On Behalf Of Yingzhen Qu Sent: Friday, 
February 23, 2024 1:28 PM To: lsr <[email protected]> lsr-chairs 
<[email protected]> Subject: [Lsr] WG Adoption Call - 
draft-gong-lsr-ospf-unreachable-link (02/23/24 - 03/08/24)




 

Hi,






  This email begins a 2 week WG adoption poll for the following draft: 
https://datatracker.ietf.org/doc/draft-gong-lsr-ospf-unreachable-link/   Please 
review the document and indicate your support or objections by March 8th, 2024. 
Authors and contributors, please respond to the list indicating whether you are 
aware of any IPR that applies to the draft. Thanks, Yingzhen 





_______________________________________________ Lsr mailing list [email protected] 
https://www.ietf.org/mailman/listinfo/lsr 


-- 




Gyan Mishra


Network Solutions Architect 


Email [email protected]


M 301 502-1347












_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to