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? Please also see inline below for a minor comment/clarification. On Sun, Mar 10, 2024 at 3:07 AM Acee Lindem <[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]> 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) <jie.dong= > [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]] *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 >> > -- > > <http://www.verizon.com/> > *Gyan Mishra* > *Network Solutions A**rchitect * > *Email [email protected] <[email protected]>* > > > *M 301 502-1347* > > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
