Hi Acee, As a reminder, please take a look at https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ (this link was present in my ballot review) - "The bottom line is that a DISCUSS ballot is a request to have a discussion".
Please check for follow-ups and clarifications inline below with KT On Thu, Mar 5, 2026 at 1:00 AM Acee Lindem <[email protected]> wrote: > 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 KT> The question that I asked was if that specific alternate approach was considered because I didn't see that being discussed. > > 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. KT> I respect WG consensus. If any of the discussion points have been considered and discussed within the WG, I would not have brought them up in my IESG evaluation ballot. Please correct me, if I missed something. The point of IESG evaluation is to do a technical review and as part of that ADs can bring up points/questions for discussions that have not been considered by the authors/WG. Sometimes reviews go into things that are not in the document text - things not being considered or possibly have escaped the attention of the WG. None of this is disrespectful. This is all technical discussion. Furthermore, I note that there are no implementations of this specification (even code points not allocated) - that allows the WG the opportunity to be more flexible in considering feedback. When specifications come up for IESG evaluation that have implementations/deployments, I am more circumspect and if not then I am more liberal in the discussions. KT> I hope you are able to see the technical aspects behind the points that have been raised and I look forward to fruitful technical discussion on them. > > > > 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. KT> Right. Vertices (as in nodes) have the notion of reachability/unreachability. Destinations (as in prefixes) have the same. However, I have not come across the notion of a link (i.e. an edge) being reachable/unreachable. I hope that clarifies. Links/edges can be not considered or become unusable (i.e., excluded) in specific SPF computations. I raise this point as this spec is introducing new protocol constants in OSPF named as MaxReachableLinkMetric (that is being proliferated into widely implemented and deployed RFCs like 6987 and 5443) and discussions on link reachability. I wish to discuss so the spec is using the correct terminology. To quote from RFC5305: If a link is advertised with the maximum link metric (2^24 - 1), this link MUST NOT be considered during the normal SPF computation. > > > > > > <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. KT> Is your response that - you have considered the suggested approach and don't find it any better but don't wish to offer any technical reasons for it? > > > > > > > <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). KT> The spec is proposing to replace MaxLinkMetric constant in RFC6987 with MaxReachableLinkMetric. When an OSPF router supports the Unreachable Link capability defined in this document, the OSPF stub router MaxLinkMetric (0xffff) MUST be updated to MaxReachableLinkMetric (0xfffe). First, this constant does not change within an implementation by simply supporting this spec since it depends on the area-wide capability negotiation. So, the router would advertise metric as 0xffff for all the usage of max-metric scenarios if there is at least one router in the area that does not have the capability. That leads me to believe that the constant MaxLinkMetric always remains relevant with value becoming either 0xffff or 0xfffe depending on the area-wide capability of this feature. Then there is a new LSLinkInfinity (0xffff) constant that comes into play only when the area-wide capability negotiation indicates that all routers in the area support this feature. So, then aren't we left with just one new constant (LSLinkInfinity) and the change in the value of an existing one (MaxLinkMetric)? > > > > > > > > <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? KT> The reason is the same reason IS-IS via RFC5305 also covered TE metric. It is for TE computations. > > > > > > > <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. KT> Can you please point me to the metric TLV/sub-TLV you are referring to? Here is the list: https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#extended-link-opaque-lsa-tlvs > > > > > > > > 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. KT> Sure. Please see below. Scope of the RI LSA is not specified: *The RI LSA MUST be area-scoped.* By default the capability is proposed to be OFF (per YANG model but not specified in the text or is not clear enough). Following text gives the impression that default is TRUE? To provide backward compatibility, this document defines that routers supporting LSLinkInfinity for unreachable links MUST advertise a Router Information (RI) LSA with a Router Functional Capabilities TLV [RFC7770 <https://www.ietf.org/archive/id/draft-ietf-lsr-ospf-ls-link-infinity-23.html#RFC7770> ] including the following Router Functional Capability Bit The above are the most important parts. What is next is simply a suggestion. The following text in RFC8770 describes the scenarios with enablement of this feature or when a new router is introduced or existing non-compliant router restarts (we stop considering RI LSAs of unreachable nodes when they go down - causing flip/flops). Please consider - up to the authors/WG. In normal operation, it is possible that the RI LSA will fail to reach all routers in an area in a timely manner. For example, if a new router without H-bit support joins an area that previously had only H-bit-capable routers with the H-bit set, then it may take some time for the RI LSA to propagate to all routers. While it is propagating, the routers in the area will gradually detect the presence of a router that does not support the capability and will revert back to the normal SPF calculation. During the propagation time, the area as a whole is unsure of the status of the new router; this type of situation can cause temporary transient loops. > > > > > > > > 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. KT> Please see my follow-up on the previous point. The YANG model says default is OFF. So, a knob should be a MUST? If the spec is saying default in ON, then I can understand the SHOULD/RECOMMEND to allow it to be turned off. > > > > > 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. KT> Thanks. I hope you will also consider and respond to the comments outside of the DISCUSS portion. Thanks, Ketan > > > 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]
