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