Hi Dhruv, Thanks for the view.
> On Sep 11, 2025, at 8:56 AM, Dhruv Dhody via Datatracker <[email protected]> > wrote: > > Document: draft-ietf-lsr-ospf-ls-link-infinity > Title: Advertising Unreachable Links in OSPF > Reviewer: Dhruv Dhody > Review result: Has Issues > > # Early OPSDIR Review of draft-ietf-lsr-ospf-ls-link-infinity > > I have reviewed this document as part of the Operational directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving the operational aspects of > the IETF drafts. > > The document is well-written. The motivation is clear. Thank you for including > the use cases with clear examples. > > The document does not include a dedicated Operational Considerations section. > There is a Management consideration, though. Consider changing that to > Operational and adding other operational details — some useful information in > draft-opsarea-rfc5706bis. > > ## Major > > - Don't use BCP14 MUST in the abstract. I'd already removed this in -08. > > - It is unclear what exactly the update to existing RFCs is. The draft states > "OSPFv2 stub router MaxLinkMetric(0xffff) MUST be updated to > MaxReachableLinkMetric(0xfffe)", RFC 6987 defines this as a value - > "MaxLinkMetric: The metric value indicating that a router-LSA link (see > Section > 2) should not be used for transit traffic. It is defined to be the 16-bit > binary value of all ones: 0xffff. How to interpret the update? Do you mean to > say that every instance of MaxLinkMetric in RFC 6987 and RFC 8770 needs to be > updated to MaxReachableLinkMetric? It means that MaxReachableLinkMetric is advertised rather than MaxLinkMetric as the text says. I've added "with respect to the advertisement of MaxReachableLinkMetric rather than MaxLinkMetric" in two places. > > - For "Support of the Unreachable Link support capability SHOULD be > configurable", because the draft itself highlights loop risks with > inconsistent > behaviour, shouldn't configurability be a MUST? No - the backward compatibility mechanism assures that links with a metric of MaxLinkMetric are not interpreted as unreachable unless every OSPF router in the area supports this. > > ## Minor > > - The introduction does not set enough context. Here is a suggestion that you > can wordsmith further: "OSPF advertise all active links in the network as part > of the link-state database. Each advertised link is assigned a cost that is > used by the Shortest Path First (SPF) algorithm to compute forwarding paths. > Existing mechanisms allow operators to influence this computation. For > example, > [RFC6987] describes the use of maximum link metrics to discourage the use of a > router or its links, and [RFC8770] specifies host-router support that prevents > a router from being used for transit traffic. In both cases, however, the > links > are still considered reachable and may still be used under certain > circumstances." > > - Can we have a clear definition of an Unreachable Link up front? I strongly disagree that this is needed. What part of "unreachable" is unclear??? In certain scenarios, it is necessary to advertise OSPF links that are not applicable to the default SPF (Shortest Path First) calculation for other purposes. In order to advertise these links and not use them in the base SPF calculation, the metric LSLinkInfinity (0xffff) is used to specify that the link is unreachable. > > - Add references for Flex Algo This was done in -08. > > - I had a hard time parsing the 2nd paragraph of 3.1. Let me know if this > interpretation is correct - In the base topology, LSLinkInfinity (0xFFFF) MUST > always mean unreachable (mandatory). Flex-Algo feature is optional, but if > implemented, LSLinkInfinity MUST also mean unreachable there. I suggest > rephrasing! I've re-written much of this. I agree it was confusing. > > - Is there a reference for the term 'auto-costing'? If not, consider > rephrasing > and explaining it. Ok - at the risk of confusion, I explained this. > > - Update security consideration as per draft-ietf-netmod-rfc8407bis Fixed. > > ## YANG > > - Remove reference RFC XXXX statement after description. > > - Should functional-capability be a separate IANA-maintained module? > > ## Nits > > - Expand on first use: SPF, Fixed. > > -s/his document specifies using LSLinkInfinity(oxffff)/This document specifies > using LSLinkInfinity(0xffff)/ This was changed before. > > -s/links between nodes A, and B/links between nodes A and B/ Fixed. > > -s/IGP metic/IGP metric/ Fixed. > > -s/it MUST also support advertise all its non-stub links/it MUST also support > advertisement of all its non-stub links/ Fixed. > > Thanks! > Dhruv > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
