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? > > > > > > > > > > 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). 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]
