Ketan Talaulikar has entered the following ballot position for draft-ietf-lsr-ospf-ls-link-infinity-23: Discuss
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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to the authors and the WG for their work on this document. This document attempts to bring in a feature to the OSPF protocol that has been there in IS-IS and I believe this to be useful. However, I have some points that I would like to discuss about the proposal in the document. <discuss-1> I am trying to understand if there is such a thing as an unreachable link. Isn't reachability evaluated for nodes and prefixes advertised by those nodes? I was trying to find RFCs in either IGPs that cover unreachability for links. What we do have is for a link to be not used/considered in the SPF computation. That makes the link unusable for SPF, but not unreachable, right? This is important since the document talks about reachability/unreachability of links throughout the text, while that notion applies to nodes & prefixes. <discuss-2> I would like to discuss if the authors/WG considered using an approach similar to RFC8379 to signal un-usability of links in SPF rather than disturbing all the link metric constants and calculations that are widely implemented. This feature requires a new capability anyway, and so using a TLV for this indication would have been just fine? One argument in favor of this approach that I would like the WG to consider is that it does not change the semantics of existing MaxLinkMetric and its treatment. This means that in a partial deployment where this feature is being introduced gradually, the nodes don't link to update their Router LSAs in response to change in the area-wide capability. I understand that the current approach is taken from IS-IS, however, that was a day 1 feature in that protocol while in OSPF one needs to factor in existing implementations that perhaps warrant a different approach? <discuss-3> Doesn't the MaxLinkMetric value remain 0xffff if not all routers in an area support this new capability? The value changes to 0xfffe only when all routers in an area support this new capability. This means the values change based on area-wide capability and hence are no longer constant.So, why is there a need to introduce two new "constants" (keeping aside for now the 'reachability' in their names), when this document could have simply changed the value of MaxLinkMetric to 0xfffe when this capability is turned on across the area. This way, the document only needs to update RFC6987. <discuss-4> When IS-IS introduced this concept via RFC5305 it covered both the IGP as well as TE metric. Should OSPF also not consider covering both? 230 * The OSPFv2 Extended Link TLV of OSPFv2 Extended Link Opaque LSA 231 [RFC7684] <discuss-5> I don't see how it applies to OSPFv2 Extended Link Opaque LSA. Which specific TLV/sub-TLV is going to carry this metric? 235 3.2. Unreachable Link Backward Compatibility <discuss-6> Can the authors/WG please consider if this section should be updated along the lines of https://www.rfc-editor.org/rfc/rfc8770#section-5 as that is quite good and thorough. The current text is missing some important aspects such as LSA scope. 330 4.1. Configuration Parameters 332 Support of the Unreachable Link capability SHOULD be configurable. <discuss-7> Why not MUST? Isn't this a very operator driven thing and therefore there MUST be a config option? Also, I don't seem to find the knob in the YANG module to mark the link usable/unusable. Am I missing something? These knobs (default OFF) are needed for both the router level capability and the per-link setting. ---------------------------------------------------------------------- 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? 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 ? 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. 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 ? 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? 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 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. 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? 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? 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. 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? <EoRv23> _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
