Ketan,
Version -24 includes the following changes to address your comments:
1. Removal of the reference to "OSPFv2 Extended Link TLV of OSPFv2
Extended Link Opaque LSA "[RFC7684].
2. Change "SHOULD" to "MUST" support for the configuration of unreachable
link support.
3. Clarifications in the "Backward Compatibility" section and addition of a
paragraph on
propagation of the Unreachable Link Capability.
4. Addition of the YANG leaf to configure an OSPF interface as unreachable
and advertised with a link metric of MaxLinkMetric in the OSPF base
topology.
The following comments are rejected:
1. Your alternate proposal to use a new TLV to omit the link rather than
MaxLinkMetric is rejected. This was covered in my first email. The WG
reached consensus on this solution and the authors don't feel your
approach
is superior and even worth debating at this point (3 1/2 years after the
initial
draft).
2. Change the" Unreachable Link" terminology - In the context of OSPF and
the document, a link with a metric of MaxLinkMetric is, in fact,
considered
unreachable in the base SPF topology. I believe this comment to be
associated with your alternate solution (#1 above).
3. Change the value of MaxLinkMetric when the Unreachable Link functionality
is
active rather than using a separate constant (MaxReachableLinkMetric).
RFC 2328 defines several architectural constants in Appendix B, e.g.,
LSInfinity.
We consider MaxLinkMetric to be in the same category and, as such, should
remain a constant (similar to LSInfinity). Specifying it otherwise would
be very
confusing.
4. Define MaxLinkMetric as unreachable for the OSPF TE Link Metric as well.
OSPF TE and link metrics are very different and the authors had
previously
decided against doing this. The OSPF Link metric is part of the fixed
Router-LSA Link encoding while the OSPF TE metric is totally optional.
The
OSPF Link metric is a 16-bit value while the OSPF TE metric is a 32-bit
value
(clearly MaxLinkMetric is not applicable). Finally, usage of the OSPF TE
Metric isn't specified by the OSPF protocol or even the document
specifying
it (RFC 3630).
Thanks,
Acee
> 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.
>
>
> > 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]
