Hi Ketan, The window has opened and I've posted -25. See inline.
> On Mar 14, 2026, at 2:46 AM, Ketan Talaulikar <[email protected]> wrote: > > Hi Acee, > > Thanks for your response. Please see inline below a couple of follow-ups. > > > On Fri, Mar 13, 2026 at 10:59 PM Acee Lindem <[email protected]> wrote: > Ketan, > > I've gone through these comments as well. > > > > > > > > > > ---------------------------------------------------------------------- > > > > COMMENT: > > > > ---------------------------------------------------------------------- > > > > > > > > Please also find below some comments provided inline in the idnits o/p > > > > of v23 > > > > of this document. Look for the tag <EoRv23> at the end to ensure that > > > > you have > > > > received the full review. > > > > > > > > 16 Abstract > > > > > > > > > > > > <minor> Could the abstract convey that all these changes are contingent > > > > on > > > > the presence of a new capability? > > > The abstract is not meant to include every detail of the draft. I have > reluctantly added > an additional sentence covering this. > > > > > > > > > > 107 In order to advertise these links as unreachable, the metric > > > > 108 LSLinkInfinity (0xffff) is used to specify that the link is > > > > 109 unreachable and OSPF routers supporting this specification > > > > will > > > > 110 exclude the link from SPF calculations (subject to backward- > > > > 111 compatibility constraints, refer to Section 3.2). > > > > > > > > <minor> perhaps s/backward-compatibility constraints/capability > > > > negotiation ? > > No - the reference describes the details of the backward compatibility. It > would be redundant > to cover it here. > > > > > > > > > > > 113 Stub Router Advertisement [RFC6987] defines MaxLinkMetric > > > > (0xffff) to > > > > 114 indicate a router-LSA link should not be used for transit IP > > > > traffic. > > > > > > > > <major> Isn't this is a wrong characterization of RFC6987? RFC6987 is > > > > setting > > > > this highest level of metric in the hope that the link gets used only > > > > as a last > > > > resort. The "should not be used" is incorrect. > > OK. This is effectively the behavior. > > > > > > > > > 121 Similarly, Label Distribution Protocol (LDP) IGP > > > > Synchronization > > > > 122 [RFC5443] specifies OSPF advertisement of MaxLinkMetric > > > > (0xffff) to > > > > 123 indicate that while the OSPF adjacency is in FULL state, LDP > > > > has not > > > > 124 been synchronized between the two neighbors and transit > > > > traffic is > > > > 125 discouraged. This document updates [RFC5443] with respect > > > > to the > > > > 126 advertisement of MaxReachableLinkMetric rather than > > > > MaxLinkMetric. > > > > > > > > <major> You are missing implications on RFC8379? > > OK. > > KT> I assume that means you will add RFC8379 and cover the changes for it > similar to the other ones such as LDP/IGP sync? Yes - now in -25. > > > > > > > > > > 218 While the interpretation of LSLinkInfinity is only required > > > > in the > > > > 219 base topology as other topologies are optional [RFC4915], > > > > OSPF > > > > > > > > <major> I am not sure that I understand why MT is being brought in > > > > here. Can you > > > > please elaborate the implications on MT? > > Because it uses the additional TOS encodings in the OSPFv2 Router-LSA. It > should be > obvious that this is for link metric consistency. > > > > > > > > > > 222 This applies to both the Flex-Algorithm SPF [RFC9350] and > > > > the base > > > > 223 SPF as long as LSLinkInfinity is specified for the OSPF > > > > metric. > > > > > > > > <major> Perhaps what you mean to say is that it applies to Flex-Algo > > > > where the > > > > metric type used for computation is IGP Metric. Please clarify. I > > > > believe it > > > > also applies to Algo 1 - > > > > https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types > > OK - I'll add the detail even though it would seem to be obvious that it > would only > apply to algorithms which actually use the link metric. There could be future > algorithms other > than Algorithm 1 that use it. > > KT> My point was that the current text covers only Flex-Algorithm and base > SPF. If it were expanded to > cover all computations that use OSPF metric then we are good as well (i.e., > no need to call out just algo 1 explicitly). This is the conclusion I came to as well. See -25. Thanks, Acee > > Thanks, > Ketan > > > > > > > > > > > > > 307 An OSPFv3 router can simply advertise R-bit in its > > > > router-LSA options > > > > 308 [RFC5340] to prevent usage stub router links for transit > > > > traffic. > > > > 309 Similarly, OSPFv2 routers supporting [RFC8770] can advertise > > > > the > > > > 310 H-bit in the router-LSA options. > > > > > > > > <major> Please consider removing the above paragraph. It is not > > > > relevant to this > > > > feature and may only cause readers to ponder if they are missing any > > > > relation > > > > between these two separate procedures. > > I can remove this as I agree it isn't absolutely necessary. > > > > > > > > > > > 334 In some networks, the operator may still want links with > > > > maximum > > > > 335 metric (0xffff) to be treated as reachable. For example, > > > > when the > > > > 336 cost of links is automatically computed based on the inverse > > > > of the > > > > 337 link's bandwidth and there is a mix of low-speed and > > > > high-speed > > > > 338 links, the computation may result in the maximum metric. In > > > > this > > > > 339 case, OSPF routers supporting this specification can disable > > > > the > > > > 340 Unreachable Link capability and still treat links with > > > > maximum metric > > > > 341 as reachable. > > > > > > > > 343 It is also RECOMMENDED that implementations supporting this > > > > document > > > > 344 and auto-costing limit the maximum computed cost to > > > > 345 MaxReachableLinkMetric (0xfffe). An example of auto-costing > > > > would be > > > > 346 to automatically set the link metric to be inversely > > > > proportional to > > > > 347 the link bandwidth (refer to the auto-cost feature in the > > > > ietf- > > > > 348 ospf.yang [RFC9129]). > > > > > > > > <major> What is meant by "OSPF routers supporting ... can disable"? > > > > Would this > > > > not cause churn and instability as capability is turned on/off based on > > > > link > > > > bandwidth changes (e.g., in the case of a bundle?). Why not change > > > > RECOMMENDED > > > > to MUST to fix this issue in a proper way? > > Normally, you would only disable it when necessary so it wouldn't result in > churn. However, > I'll update it to MUST. > > > > > > > > > > 862 5. Security Considerations > > > > > > > > 864 A compromised OSPF router could advertise changes to its > > > > Unreachable > > > > 865 Link capability rapidly resulting in repeated route > > > > recalculations on > > > > 866 routers in the area supporting this specification (Section > > > > 3.2). > > > > 867 Hence, it is RECOMMENDED that routers supporting this > > > > specification > > > > 868 also support the SPF back-off delay algorithm described in > > > > [RFC8405]. > > > > > > > > <major> It is not just about a compromised router. It could be an older > > > > router > > > > or one that does not support this feature becoming > > > > connected/disconnected to > > > > the rest of the routers in the area. This is enough to cause the area > > > > wide > > > > capability to flip back/forth. This isn't for the security > > > > considerations but > > > > perhaps should be there in the operational considerations - i.e., > > > > recommend > > > > that care be taken when this capability is enabled and some router(s) > > > > in the > > > > network does not support it? > > Note the inclusion of the adverb "rapidly" with respect to the change. > This covers the case of an attack where the capability is toggled on and off > - NOT the > normal enablement or disablement. > > With respect to operational considerations, I don't think we need to document > every > configuration change that causes an additional SPF. > > > > > > > > > > > > 1018 9.1. Normative References > > > > > > > > 1020 [IANA-OSPF-FC-Bits] > > > > 1021 IANA, "OSPF Router Functional Capability Bits", > > > > 1022 > > > > <https://www.iana.org/assignments/ospf-parameters>. > > > > > > > > 1024 [IANA-YANG-Parameters] > > > > 1025 IANA, "YANG Module Names", > > > > 1026 > > > > <https://www.iana.org/assignments/yang-parameters>. > > > > > > > > <major> The above two references seem informative to me. > > I'm going to leave them as normative as these registries are updated by this > document. > > > > > > > > > > 1127 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, > > > > "OSPF > > > > 1128 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July > > > > 2008, > > > > 1129 <https://www.rfc-editor.org/info/rfc5340>. > > > > > > > > <major> Should RFC5340 not be normative? > > Yes - I think it should. > > Thanks, > Acee > > > > > > > > > > <EoRv23> > > > > > > > > > > > > > > > > > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
