Hi Ketan, Thank you very much for your comments. I39m trying to understand your point.
The core idea is to differentiate between these two values, 0xffff and 0xfffe. One represents unreachable, and the other signifies the maximum value (cannot transmit traffic). Based on Acee39s explanation, where the new term MaxUsableLinkMetric represents 0xfffe and also updates 8770, I think these two concepts can now be distinguished, and therefore, there is no need to introduce UnreachableLinkMetric. If I have misunderstood, I would greatly appreciate your correction. Thanks again. Best Regards, Liyan ----邮件原文----发件人：Ketan Talaulikar <[email protected]>收件人：Acee Lindem <[email protected]>抄 送: Yingzhen Qu <[email protected]>,lsr <[email protected]>,lsr-chairs <[email protected]>发送时间：2024-02-28 15:43:10主题：Re: [Lsr] WG Adoption Call - draft-gong-lsr-ospf-unreachable-link(02/23/24 - 03/08/24)Hi Acee,Thanks for your quick response. On the point (1), there are actually two aspects: a) The name of the capability itself - "MaxLinkMetric support" seems odd to me since all implementations do support setting this metric value already. Perhaps "UnreachableLinkMetric support" (or something like that) seems more meaningful since it talks about the support for treating links with this metric value as unreachable. After all, the name of this "feature" and the "draft" says "unreachable link"? b) The term MaxLinkMetric was defined in RFC6987/8770 to have a different meaning. This draft can "update" the value of that term (to 0xfffe) without changing its semantics. However, it would be better to define a new term UnreachableLinkMetric for this feature to avoid mixing of the semantics of the two terms. We do need both those terms/features, right? Hope this clarifies. Thanks, Ketan On Wed, Feb 28, 2024 at 12:00AM Acee Lindem <[email protected]> wrote: Hi Ketan, On Feb 27, 2024, at 08:16, Ketan Talaulikar <[email protected]> wrote: Hello,I support the adoption of this document by the WG since it is a useful OSPF protocol extension. I have the following comments for the authors to consider (post adoption): 1) Suggest to rename the capability bit to UnreachableLinkMetric to clearly distinguish it from all previous use of MaxMetric in OSPF. Also suggest to use this term through the document where the purpose is to mark the link as unreachable. I’m not sure I understand why there would be any confusion between MaxMetric and MaxLinkMetric. In OSPF, we are using MaxMetric as unreachable so this change would just be for the corner case of OSPFv2 stub router. So, it seems to be consistent we should stick with MaxLinkMetric to be unreachable. 2) This document should introduce a new MaxLinkMetric which is 0xfffe which can be then used as a "link of last resort" as specified in RFC6987. The document requires use of RFC 8770 for OSPFv2 Stub Router support. We could call this MaxUsableLinkMetric for this new constant. 3) Section 3: There is no OSPF cost/metric in OSPFv2 Extended Link LSA. Also, not sure why the base OSPFv3 5340 has been excluded from this list where the Router LSA carries the link cost similar to OSPFv2. Agreed. 4) This document should formally update the base OSPFv2/v3 RFCs since it changes the SPF. Agreed - It should also update RFC 8770. Thanks, Acee I hope this helps. Thanks, Ketan On Fri, Feb 23, 2024 at 10:58AM Yingzhen Qu <[email protected]> wrote: 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 _______________________________________________Lsr mailing [email protected]https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
