Ketan, > On Mar 5, 2026, at 9:17 AM, Ketan Talaulikar <[email protected]> wrote: > > 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.
There is nothing technically wrong with this solution and it is inappropriate for you to use your AD position to propose a totally different draft with different terminology right when the draft should be going on the RFC Editor queue. If you wanted a different solution, you should have proposed it years ago rather waiting for the draft to go through all the reviews and even the YANG models to be done. Acee > > > > 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] > 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]
