Hi Mahesh, Thanks for your review.
> On Mar 3, 2026, at 8:45 PM, Mahesh Jethanandani via Datatracker > <[email protected]> wrote: > > Mahesh Jethanandani has entered the following ballot position for > draft-ietf-lsr-ospf-ls-link-infinity-23: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-ls-link-infinity/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 2.2, paragraph 7 >> The "Red" links that are used by Flex-Algorithm 128 calculation. >> However, these "Red" links are also included in the default algorithm >> calculation [RFC9350] since they are reachable. Note that links used >> by the default algorithm are omitted from Figure 3 for clarity. > > The first sentence seems to be a fragment. I think you meant to say: > > "The "Red" links are used by Flex-Algorithm 128 calculation." Fixed. > > Section 3.2, paragraph 6 >> OSPF Routers MUST NOT treat links with an advertised metric of >> LSLinkInfinity as unreachable unless all routers in the OSPF area, >> i.e., all routers with Router-LSAs in the area Link State Database >> (LSDB), have advertised this capability. If all OSPF Routers in the >> area have advertised this capability, then links with an advertised >> metric of LSLinkInfinity MUST be treated as unreachable. Upon >> detection of a change in the number of routers in the area not >> supporting the Unreachable Link capability changes to 0 or from 0 to >> greater than 0, all OSPF routers in the area MUST recalculate their >> routes. > > The last sentence in the paragraph is hard to parse. Could it be reworded to > say: > > "When the number of routers in the area that do not support the Unreachable > Link > capability changes to 0 or from 0 to a value greater than 0, all OSPF routers > in the area MUST recalculate their routes." Already changed via comment from Mike Bishop. > > Section 3.3, paragraph 3 >> When an OSPF router supports [RFC6987] and the Unreachable Link >> capability defined in this document, it MUST also support >> advertisement all its non-stub links with a link cost of >> MaxReachableLinkMetric (0xfffe). Since MaxLinkMetric will not be >> used to indicate a link is unreachable unless all OSPF routers in the >> area support this specification as specified in Section 3.2, all >> routers in the area will also support the usage of >> MaxReachableLinkMetric to discourage the usage of stub router links >> for transit traffic. If there are any OSPF routers in the area that >> do not support the Unreachable Link capability, then all OSPF routers >> in the area will treat links advertised with a cost MaxLinkMetric as >> reachable (Section 3.2). > > Similarly, the first sentence should be reworded to say: > > "... it MUST support the advertisement of all its non-stub links." I can remove "also" but I think it is fine as is. > > Section 4.2, paragraph 0 >> This section defines three YANG [RFC7950] modules. Module iana-ospf- >> functional-cap-bits defines the identities for OSPF Functional >> Capabilities as per the "OSPF Router Functional Capability Bits" IANA >> registry [IANA-OSPF-FC-Bits]. Module ietf-ospf-functional-capability >> and module ietf-ospf-unreachable-links can be used to configure and >> manage the usage of OSPF LSLinkInfinity for unreachable links as >> defined in this document, which augments the OSPF YANG data model >> [RFC9129] and the YANG Data Model for Routing Management [RFC8349]. > > The description above states that the module ietf-ospf-functional-capability > will be used to configure and manage the usage of OSPF LSLinkInfinity. > However, all the nodes are ro nodes. I assume that the actual configuration > of the capabilities is happening somewhere else, and this module is only > being used to query those capabilities?? There is a writable node in YANG module ietf-ospf-unreachable-links.yang. > > ------------------------------------------------------------------------------- > NIT > ------------------------------------------------------------------------------- > > All comments below are about very minor potential issues that you may choose > to > address in some way - or ignore - as you see fit. Some were flagged by > automated tools (via https://github.com/larseggert/ietf-reviewtool), so there > will likely be some false positives. There is no need to let me know what you > did with these suggestions. > > Section 2.2, paragraph 7 >> If the OSPF metrics for all the "Red" links are advertised as >> unreachable, they will be excluded from the default SPF calculation >> as shown in Figure 4, This allows the "Red" links from A to B and C >> to D to be used exclusively by the Flex-Algorithm 128 calculation. > > s/Figure 4,/Figure 4./ Fixed. > > Section 5, paragraph 5 >> The following data nodes defined in the ietf-ospf-unreachable-links >> YANG module that are writable/creatable/deletable (i.e., config true, >> which is the default). The modification of these data nodes without >> proper protection can prevent interpretation of the OSPF >> LSLinkInfinity metric as unreachable. > > s/that are/are/ I copied in the boiler plate from RFC 8407BIS which fixes this. Thanks, Acee > > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
