Advertising Unreachable Links in OSPF
draft-ietf-lsr-ospf-ls-link-infinity-25

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

While discussion on some of the points was unfortunately rejected (see original ballot), my thanks to the authors for addressing the other discussion points and comments.

[Ballot comment]
Section 2.2, paragraph 7
>    The "Red" links that are used by Flex-Algorithm 128 calculation.
>    However, these "Red" links are also included in the default algorithm
>    calculation [RFC9350] since they are reachable.  Note that links used
>    by the default algorithm are omitted from Figure 3 for clarity.

The first sentence seems to be a fragment. I think you meant to say:

"The "Red" links are used by Flex-Algorithm 128 calculation."

Section 3.2, paragraph 6
>    OSPF 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.

The last sentence in the paragraph is hard to parse. Could it be reworded to say:

"When the number of routers in the area that do not support the Unreachable Link
capability changes to 0 or from 0 to a value greater than 0, all OSPF routers
in the area MUST recalculate their routes."

Section 3.3, paragraph 3
>    When an OSPF router supports [RFC6987] and the Unreachable Link
>    capability defined in this document, it MUST also support
>    advertisement all its non-stub links with a link cost of
>    MaxReachableLinkMetric (0xfffe).  Since MaxLinkMetric will not be
>    used to indicate a link is unreachable unless all OSPF routers in the
>    area support this specification as specified in Section 3.2, all
>    routers in the area will also support the usage of
>    MaxReachableLinkMetric to discourage the usage of stub router links
>    for transit traffic.  If there are any OSPF routers in the area that
>    do not support the Unreachable Link capability, then all OSPF routers
>    in the area will treat links advertised with a cost MaxLinkMetric as
>    reachable (Section 3.2).

Similarly, the first sentence should be reworded to say:

"... it MUST support the advertisement of all its non-stub links."

Section 4.2, paragraph 0
>    This section defines three YANG [RFC7950] modules.  Module iana-ospf-
>    functional-cap-bits defines the identities for OSPF Functional
>    Capabilities as per the "OSPF Router Functional Capability Bits" IANA
>    registry [IANA-OSPF-FC-Bits].  Module ietf-ospf-functional-capability
>    and module ietf-ospf-unreachable-links can be used to configure and
>    manage the usage of OSPF LSLinkInfinity for unreachable links as
>    defined in this document, which augments the OSPF YANG data model
>    [RFC9129] and the YANG Data Model for Routing Management [RFC8349].

The description above states that the module ietf-ospf-functional-capability
will be used to configure and manage the usage of OSPF LSLinkInfinity.
However, all the nodes are ro nodes. I assume that the actual configuration
of the capabilities is happening somewhere else, and this module is only
being used to query those capabilities??

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2.2, paragraph 7
>    If the OSPF metrics for all the "Red" links are advertised as
>    unreachable, they will be excluded from the default SPF calculation
>    as shown in Figure 4, This allows the "Red" links from A to B and C
>    to D to be used exclusively by the Flex-Algorithm 128 calculation.

s/Figure 4,/Figure 4./

Section 5, paragraph 5
>    The following data nodes defined in the ietf-ospf-unreachable-links
>    YANG module that are writable/creatable/deletable (i.e., config true,
>    which is the default).  The modification of these data nodes without
>    proper protection can prevent interpretation of the OSPF
>    LSLinkInfinity metric as unreachable.

s/that are/are/

[Ballot comment]
# IESG review of draft-ietf-lsr-ospf-ls-link-infinity-23

CC @MikeBishop

## Comments

### Section 6, paragraph 0

Please add links to the relevant registries.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 2.2, paragraph 11
```
- 3.  LSLinkInfinity Based Solution
-                  ^
+ 3.  LSLinkInfinity-Based Solution
+                  ^
```

#### Section 3.2, paragraph 7
```
-    metric of LSLinkInfinity MUST be treated as unreachable.  Upon
-                                                              ^^
-    detection of a change in the number of routers in the area not
+    metric of LSLinkInfinity MUST be treated as unreachable.  When the number of routers in the area not
+                                                              ^^^^^^^^^^^^^^^^ +++++++++++ +++++++++++++
```

#### Section 3.3, paragraph 4
```
-    [RFC5340] to prevent usage stub router links for transit traffic.
+    [RFC5340] to prevent the usage of stub router links for transit traffic.
+                        ++++    +++
```

#### Section 5, paragraph 2
```
-    The security considerations for [RFC2328],[RFC5340], [RFC6987], and
+    The security considerations for [RFC2328], [RFC5340], [RFC6987], and
+                                              +
```

#### Section 5, paragraph 3
```
-    SSH [RFC4252], TLS [I-D.ietf-tls-rfc8446bis], and QUIC [RFC9000]) and
-                                                  ^^^
+    SSH [RFC4252], TLS [I-D.ietf-tls-rfc8446bis], or QUIC [RFC9000]) and
+                                                  ^^
```

### URLs

These URLs in the document did not return content:

* https://www.iana.org/assignments/iana-ospf-functional-cap-bits/iana-ospf-functional-cap-bits.xhtml

### Grammar/style

#### Section 4.2.5, paragraph 8
```
egistry with all spaces replaced with “-“. The "identity" statement should ha
                                      ^ ^
```
Please do not use "smart-quotes".

[Ballot 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.

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.

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?

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.

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]

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

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.

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.

[Ballot comment]
Please also find below some comments provided inline in the idnits o/p of v23 of this document. Look for the tag  at the end to ensure that you have received the full review.

16 Abstract

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).

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.

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.

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

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.

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.

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]).

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].

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               .

1024   [IANA-YANG-Parameters]
1025               IANA, "YANG Module Names",
1026               .

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               .

Should RFC5340 not be normative?

[Ballot comment]
Thanks to Carl Wallace for their secdir review.

Section 5, para 3:  Consider changing the reference from RFC 8446 to draft-ietf-tls-8446bis which is currently in Auth48 (so it should be completed before this draft).

[Ballot comment]
Hi Liyan, Weiqiang, Changwang, Acee, and Ran,

Thank you for the discussion and the changes. The changes made in [1] address ALL my points. Much appreciated.

Special thanks to Acee for closing the LC issue [3].

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-lsr-ospf-ls-link-infinity-19&url2=draft-ietf-lsr-ospf-ls-link-infinity-21&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/lsr/DZ-I9cz0aWiNQ5BoNxydZscaONY/

[3] https://mailarchive.ietf.org/arch/msg/lsr/txbL9tHOr5SkxFFHNQlGXs2V8l0/

[Ballot discuss]
Hi Liyan, Weiqiang, Changwang, Acee, and Ran,

Thank you for the effort put into this specification. Special thanks for the detailed Operational Considerations section. The approach in this draft is consistent with draft-iab-nemops-workshop-report, especially this part:

  *  Consider having YANG as part of the protocol specification/change
      where possible, or have the YANG document progress in parallel.

Thanks also to Dhruv Dhody for the great OPSDIR review and to authors for positively engaging and making relevant changes.

I have already reviewed a previous version of this specification. Thanks to the authors for having addressed that review: https://mailarchive.ietf.org/arch/msg/ops-dir/uS3e3-HJVS1_PmDyySa9Im5-y3E/.

Please find below some comments based on the latest version. Let me know if any help is needed.

# IETF Last Call comments

Unless I’m mistaken, there was no follow up to this review: https://mailarchive.ietf.org/arch/msg/last-call/kKh1DX7mc3l40GX_6lDB8Ab6ty0/ Was that missed or that the points raised there are not issues?

# Flex-Algorithm SPF

CURRENT:
  This applies to both the
  Flex-Algorithm SPF and the base SPF as long as LSLinkInfinity is
  specified for the OSPF metric.

and

  This applies to both the Flex-Algorithm SPF and the base SPF as long
  as LSLinkInfinity is specified for the OSPF metric.

We don’t have any normative reference for Flex-Algorithm SPF in the doc. Can we please add one? Thanks.

# IANA-maintained module

Thanks for adopting this design. However, we need to make sure the module is not kept in the final RFC per the following in RFC8704bis:

  The authors MUST include a note to the RFC
  Editor requesting that the appendix with the initial version of the
  module be removed before publication as RFC and that RFC IIII is
  replaced with the RFC number that is assigned to the document.

I suggest we make this change:

OLD:
  This document defines the initial version of the IANA-maintained YANG
  module for OSPF Router Functional Capabilities that mirrors the IANA
  "OSPF Router Functional Capability Bits" registry
  [IANA-OSPF-FC-Bits].

NEW:

  This document defines the initial version of the IANA-maintained YANG
  module for OSPF Router Functional Capabilities that mirrors the IANA
  "OSPF Router Functional Capability Bits" registry
  [IANA-OSPF-FC-Bits]. The latest version of this YANG module is available at IANA_URL.

  Note to the RFC Editor: Please remove this module in the version to be published as RFC.

# IANA Module for OSPF Functional Capability Bits

## Mismatch between the registry name and the identifier

I suggest you fix this as follows:

OLD:
  registry, a new "identity" statement needs to be added to the "iana-
  ospf-functional-cap-bits" YANG module.  The name of the "identity"
  MUST be the name as provided in the registry. 

NEW:
  registry, a new "identity" statement needs to be added to the "iana-
  ospf-functional-cap-bits" YANG module.  The name of the "identity"
  is the lower-case name provided in the registry with all spaces replaced with “-“. 

## Description

CURRENT:
    "description":  Replicates the description from the registry.

There is no such field in the registry. I think this should be capability name.

## Default

I suggest to delete this text as these actions correspond to the normal IANA operations

CURRENT:
  When the "iana-ospf-functional-cap-bits" YANG module is updated, a
  new "revision" statement with a unique revision date must be added in
  front of the existing revision statements.  The "revision" statement
  MUST contain both "description" and "reference" substatements as
  follows.

  The "description" substatement captures what changed in the revised
  version.  Typically, the description enumerates the changes such as
  udpates to existing entries (e.g., update a description or a
  reference) or notes which identities were added or had their status
  changed (e.g., deprecated, discouraged, or obsoleted).

  The "reference" substatement points specifically to the published
  module (i.e., IANA_FOO_URL_With_REV).  It may also point to an
  authoritative event triggering the update to the YANG module.  In all
  cases, this event is cited from the underlying IANA registry.  If the
  update is triggered by an RFC, that RFC must also be included in the
  "reference" substatement.

# Normative references

CURRENT:
  Updates: 5443, 6987, 8770 (if approved)                    China Mobile


However, these are listed as informative. Please move RFC5443, RFC6987, and RFC8770 to be listed as normative.

[Ballot comment]
# No need to motivate YANG

I would delete this text in Section 4.2:

  YANG [RFC7950] is a data definition language used to define the
  contents of a conceptual data store that allows networked devices to
  be managed using NETCONF [RFC6241] or RESTCONF [RFC8040].

Also, this is restrictive as other non-IETF protocols are available out there.

# Two modules

I’m really neutral on this but I’m curious whether there is any reason modules in 4.2.4. and 4.2.5. are not covered in the same module?

If you decide to keep them separate, consider adding a note to motivate the design.

# References

Please move RFC6241 and RFC8040 from Normative to Informative.

Cheers,
Med

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-lsr-ospf-ls-link-infinity-17. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are five actions which we must complete.

First, in the OSPF Router Functional Capability Bits registry in the Open Shortest Path First (OSPF) Parameters registry group located at:

https://www.iana.org/assignments/ospf-parameters/

a single new registration will be made as follows:

Bit Number: [ TBD-at-Registration ]
Capability Name: Unreachable Link support
Reference: [ RFC-to-be ]

Second, in the ns registry in the IETF XML Registry group located at:



three new namespaces will be registered as follows:

ID: yang:iana-ospf-functional-cap-bits
URI: urn:ietf:params:xml:ns:yang:iana-ospf-functional-cap-bits
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-ospf-functional-capability
URI: urn:ietf:params:xml:ns:yang:ietf-ospf-functional-capability
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-ospf-unreachable-links
URI: urn:ietf:params:xml:ns:yang:ietf-ospf-unreachable-links
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request.††Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the YANG Module Names registry in the YANG Parameters registry group located at:



three new YANG modules will be registered as follows:

Name: iana-ospf-functional-cap-bits
File: [ TBD-at-Registration ]
Maintained by IANA? Y
Namespace: urn:ietf:params:xml:ns:yang:iana-ospf-functional-cap-bits
Prefix: iana-ospf-fc-bits
Module:
Reference: [ RFC-to-be ]

Name: ietf-ospf-functional-capability
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-ospf-functional-capability
Prefix: ospf-fc
Module:
Reference: [ RFC-to-be ]

Name: ietf-ospf-unreachable-links
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-ospf-unreachable-links
Prefix: ospf-unreach-link
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

Fourth, in the YANG Module Names registry in the YANG Parameters registry group located at:

https://www.iana.org/assignments/yang-parameters/

new text will be added to the note for the registry as follows:

New values must not be directly added to the "iana-ospf-functional-cap-bits" YANG module. They must instead be added to the OSPF Router Functional Capability Bits registry in the Open Shortest Path First (OSPF) Parameters registry group [ https://www.iana.org/assignments/ospf-parameters ].

Fifth, in the OSPF Router Functional Capability Bits registry in the Open Shortest Path First (OSPF) Parameters registry group located at: https://www.iana.org/assignments/ospf-parameters

new text will be added to the note for the registry as follows:

When this registry is modified, the YANG module "iana-ospf-functional-cap-bits" must be updated as defined in [ RFC-to-be ].

IANA Question --> Should [ RFC-to-be ] be added to the references for the OSPF Router Functional Capability Bits registry?

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2026-02-12):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lsr-ospf-ls-link-infinity@ietf.org, gunter@vandevelde.cc, lsr-chairs@ietf.org, lsr@ietf.org, yingzhen.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Advertising Unreachable Links in OSPF) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'Advertising Unreachable Links in OSPF'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-02-12. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  In certain scenarios, it is necessary to advertise OSPF links that
  are not applicable to the default SPF (Shortest Path First)
  calculation for other purposes.  In order to advertise these links
  and not use them in the base SPF calculation, the metric
  LSLinkInfinity (0xffff) is used to specify that the link is
  unreachable.

  MaxReachableLinkMetric (0xfffe) is defined to provide backward
  compatible reachability in specifications that previously specified
  advertisement of MaxLinkMetric (0xffff).  This document updates RFC
  5443, RFC 6987, and RFC 8770 with respect to the advertisement of
  MaxReachableLinkMetric (0xfffe) rather than MaxLinkMetric (0xffff).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-ls-link-infinity/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/6313/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  There is broad agreement in the WG to progress this document.
  WGLC: https://mailarchive.ietf.org/arch/msg/lsr/n9l7_1ggJHeuWxs8r7fQubenpU4/

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  No implementation of this document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  This is an OSPF protocol extension, so no reviews from other WGs are required.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  The document includes a YANG data model, which has been reviewed by a YANG
  doctor. The review comments have been addressed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  All YANG modules included in this document have been verified using pyang and
  YANG Validator, and there is no issue found. All modules comply with NMDA.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  There is no idnits found.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  The extension defined in this document is straightforward and includes example
  use cases. Both backward compatibility and operational considerations are
  included as well.

  The document is clearly written and ready to be published.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    Both security and operational considerations are included in the document,
    as well as a YANG model.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    It's standards track. The document defines a new OSPF Router Functional
    Capability Bit and the corresponding YANG data model. All datatracker state
    attributes have been correctly set.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    There is one IPR disclosure for this document:
    https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lsr-ospf-ls-link-infinity

    All authors have answerend the IPR call:
    https://mailarchive.ietf.org/arch/msg/lsr/KsTfNJ19Vqe7BwDHiBsb5pPH6Vc/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    Yes. There are five authors for this document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    No idnits found.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    If approved, the document will update RFC 5443, RFC 6987 and RFC 8770. The
    datatracker metadata has been correctly set, and it's included in both the
    abstract and the introduction.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    The document defines a new bit in the registry "OSPF Router FUnctional
    Capability Bits", which is included in the IANA consideration.

    The document also defines three YANG modules, including an IANA
    maintained YANG module. The IANA Consideration section has correctly
    included the corresponding information.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    The IANA registry requires the IETF review, not designated expert review.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  There is broad agreement in the WG to progress this document.
  WGLC: https://mailarchive.ietf.org/arch/msg/lsr/n9l7_1ggJHeuWxs8r7fQubenpU4/

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  No implementation of this document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  This is an OSPF protocol extension, so no reviews from other WGs are required.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  The document includes a YANG data model, which has been reviewed by a YANG
  doctor. The review comments have been addressed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  All YANG modules included in this document have been verified using pyang and
  YANG Validator, and there is no issue found. All modules comply with NMDA.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  There is no idnits found.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  The extension defined in this document is straightforward and includes example
  use cases. Both backward compatibility and operational considerations are
  included as well.

  The document is clearly written and ready to be published.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    Both security and operational considerations are included in the document,
    as well as a YANG model.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    It's standards track. The document defines a new OSPF Router Functional
    Capability Bit and the corresponding YANG data model. All datatracker state
    attributes have been correctly set.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    There is one IPR disclosure for this document:
    https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lsr-ospf-ls-link-infinity

    All authors have answerend the IPR call:
    https://mailarchive.ietf.org/arch/msg/lsr/KsTfNJ19Vqe7BwDHiBsb5pPH6Vc/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    Yes. There are five authors for this document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    No idnits found.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    If approved, the document will update RFC 5443, RFC 6987 and RFC 8770. The
    datatracker metadata has been correctly set, and it's included in both the
    abstract and the introduction.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    The document defines a new bit in the registry "OSPF Router FUnctional
    Capability Bits", which is included in the IANA consideration.

    The document also defines three YANG modules, including an IANA
    maintained YANG module. The IANA Consideration section has correctly
    included the corresponding information.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    The IANA registry requires the IETF review, not designated expert review.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/