# 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. 
 
- 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?

- 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? 

## 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?

- Add references for Flex Algo

- 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! 

- Is there a reference for the term 'auto-costing'? If not, consider rephrasing and explaining it.  

- Update security consideration as per draft-ietf-netmod-rfc8407bis 

## YANG

- Remove reference RFC XXXX statement after description. 

- Should functional-capability be a separate IANA-maintained module? 

## Nits

- Expand on first use: SPF, 

-s/his document specifies using LSLinkInfinity(oxffff)/This document specifies using LSLinkInfinity(0xffff)/

-s/links between nodes A, and B/links between nodes A and B/

-s/IGP metic/IGP metric/

-s/it MUST also support advertise all its non-stub links/it MUST also support advertisement of all its non-stub links/


Thanks! 
Dhruv