All,
With respect to the naming of the OSPF constants, I think we should go with:
LSLinkInfinity - 0xffff
MaxReachableLinkMetric - 0xfffe
LSLinkInfinity is analogous to LSInfinity.
See inline.
> On Mar 2, 2024, at 06:16, Liyan Gong <[email protected]> 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 <[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] <mailto:[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.
>
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 (0xFFFF) does not exclude the link from SPF and thus requires
> RI LSA with capability bit set for MaxLinkMetric (0xFFFF) for link to be
> excluded from SPF. Maybe “OSPF RI Capability LSA”.
>
I think the capability should be LSLinkInfinity support.
>>
>> 2. In the Flex-Algo use case, if the metric of a link is set to
>> MaxLinkMetric (0xFFFF) to exclude it from normal SPF computation, while a
>> Flex-Algo is defined to use the same metric type for path calculation, will
>> it cause the link also be excluded from the Flex-Algo path computation? If
>> not, will metric value 0xFFFF be used in the Flex-Algo computation? In other
>> word, the interaction between this new feature and Flex-Algo needs to be
>> further elaborated.
>>
>> Gyan> I agree that the RI LSA capability flag for MaxLinkMetric
>> (0xFFFF) is applicable to base Algo 0 and any Algo. However AFAIK you would
>> have to explicitly set the RI flag the particular Algo. The use case
>> described in this draft is when you are using flex algo for network slicing
>> meaning you have both algo 0 and 128 on the same links and not a separate
>> sub topology and in that case in order to avoid best effort traffic from
>> going over the same link used for algo 128 you would need to use this RI
>> capability flag. This concept we have talked about comes into play of
>> degree of network slicing and isolation to meet SLO SLE requirements.
>>
LSLinkInfinity would exclude the link from a flex algorithm as well. However,
the correct way to exclude it by omitting the advertisement.
Thanks,
Acee
>> Best regards,
>>
>> Jie
>>
>>
>> From: Lsr [mailto:[email protected] <mailto:[email protected]>] On
>> Behalf Of Yingzhen Qu
>> Sent: Friday, February 23, 2024 1:28 PM
>> To: lsr <[email protected] <mailto:[email protected]>>; lsr-chairs
>> <[email protected] <mailto:[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] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/lsr
> --
> <http://www.verizon.com/>
> Gyan Mishra
> Network Solutions Architect
> Email [email protected] <mailto:[email protected]>
> M 301 502-1347
>
>
>
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
