+1 <http://www.verizon.com/>
*Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347* On Sat, Mar 9, 2024 at 4:37 PM 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. > > > > 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
