Hi Ketan, > On Mar 15, 2024, at 05:26, Ketan Talaulikar <[email protected]> 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 0xffff 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 <[email protected] > <mailto:[email protected]>> wrote: >> 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] >>> <mailto:[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] <mailto:[email protected]>> >>> 收件人："Dongjie (Jimmy)" <[email protected] >>> <mailto:[email protected]>> >>> 抄 送: Yingzhen Qu <[email protected] >>> <mailto:[email protected]>>,lsr <[email protected] >>> <mailto:[email protected]>>,lsr-chairs <[email protected] >>> <mailto:[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. > > 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 (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
