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." 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." 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." 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?? ------------------------------------------------------------------------------- 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./ 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/ _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
