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:00 AM 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:58 AM 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 list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
