Ketan, I will respond to each of your DISCUSS points below. First, I'd like to express my extreme annoyance with your review. You are proposing a completely different solution to the problem during the IETF telechat. This is nothing short of an egregious abuse of the AD DISCUSS process. It shows a complete lack of respect for the draft authors and the LSR working group as a whole. Your behavior will certainly be remembered during the next NOMCOM cycle.
> On Mar 3, 2026, at 11:24 AM, Ketan Talaulikar via Datatracker > <[email protected]> wrote: > > 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. What is your point here? We've had this terminology for the 3 1/2 years that the draft has been active. Additionally, RFC 2328 Section 16 does refer to unreachable vertices. > > <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? If you wanted to propose a different solution, you should have done it at WG adoption time. Additionally, I don't see it as any better. > > <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. I think it is clearer to have separate values since these are different fixed architectural values (as they are referred to in RFC 6987). > > <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] What is the use case for a TE Link being advertised as unreachable? > > <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? Flex algo metrics are advertised in the OSPFv2 Extended Link Opaque LSA. > > 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. How is the above qualify as a DISCUSS comment? Here is what is there - what is missing below? SPF 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. Please suggest text. > > 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? The intent is for implementations to support the Unreachable Link capability and interpret MaxLinkMetric as unreachable when all routers in the area support it. In RFC 8770, the normative term "RECOMMENDED" is used. > 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. We can add these augmentations. Acee > > > ---------------------------------------------------------------------- > 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]
