Advertising Unreachable Links in OSPF

Advertising Unreachable Links in OSPF China Mobile

China gongliyan@chinamobile.com

China Mobile

China chengweiqiang@chinamobile.com

New H3C Technologies

China linchangwang.04414@h3c.com

Arrcus, Inc.

United States of America acee.ietf@gmail.com

ZTE Corporation

China chen.ran@zte.com.cn

RTG lsr OSPF ls OSPF Router Link State Advertisements (LSAs) use fixed-format encodings that always include advertised links in the default Shortest Path First (SPF) computation. For non-default SPF computations, e.g., Flexible Algorithms as described in RFC 9350, advertised OSPF links are used in the default SPF computation even if this is not intended. 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. If all OSPF routers in an OSPF area support this functionality and have advertised the capability via an area-scoped OSPF Router Information LSA, then links advertised with a metric of LSLinkInfinity are considered 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, RFC 8379, and RFC 8770 with respect to the advertisement of MaxReachableLinkMetric (0xfffe) rather than MaxLinkMetric (0xffff).

Introduction OSPF Router Link State Advertisements (LSAs) use fixed-format encodings that always include advertised links in the default Shortest Path First (SPF) computation. For example, a link may be required for Traffic Engineering (TE) paths but not intended for hop-by-hop routing. Another example is an OSPF link used exclusively by a Flexible Algorithm but excluded from the default algorithm. In order to advertise these links as unreachable, the metric LSLinkInfinity (0xffff) is used to specify that the link is unreachable and OSPF routers supporting this specification will exclude the link from SPF calculations (subject to backward-compatibility, refer to ). Stub Router Advertisement defines MaxLinkMetric (0xffff) to indicate a router-LSA link should only be used for transit IP traffic as a last resort. When an OSPF router supports the Unreachable Link capability defined in this document, OSPF stub router links are advertised as MaxReachableLinkMetric (0xfffe) rather than MaxLinkMetric (0xffff). This document updates and with respect to the advertisement of MaxReachableLinkMetric rather than MaxLinkMetric. Similarly, Label Distribution Protocol (LDP) IGP Synchronization specifies OSPF advertisement of MaxLinkMetric (0xffff) to indicate that while the OSPF adjacency is in FULL state, LDP has not been synchronized between the two neighbors and transit traffic is discouraged. This document updates with respect to the advertisement of MaxReachableLinkMetric rather than MaxLinkMetric. Finally, OSPF Graceful Link Shutdown specifies OSPF advertisement of MaxLinkMetric (0xffff) to indicate that the OSPF link will be taken out of service and transit traffic is discouraged. This document updates with respect to the advertisement of MaxReachableLinkMetric rather than MaxLinkMetric.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Use Cases

Case 1: Traffic Engineering A network topology is shown in . The OSPF link between Node A and E is only to be used for Traffic Engineering. Since the OSPF link is advertised by default, it will be included in the base SPF calculation for the default topology and may be used for hop-by-hop routing in the default topology.

Network Topology

Case 2: Flexible Algorithm A network topology is shown in . The links between Nodes A and B and between C and D are to be used exclusively for a Flex-Algorithm devoted to specific traffic. These links have an Extended Administrative Group (EAG) attribute specifying the "Red" color.

Network Topology Flex-Algorithm 128 is enabled on Nodes A, B, C, and D, with an EAG rule including "Red", and the Metric-Type is designated to be a type other than the OSPF metric. OSPF will compute routes for Flex-Algorithm 128 using these links. The topology associated with Flex-Algorithm 128 is shown in .

Topology of Flex-Algorithm 128 The "Red" links are used by Flex-Algorithm 128 calculation. However, these "Red" links are also included in the default algorithm calculation since they are reachable. Note that links used by the default algorithm are omitted from for clarity. 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 . This allows the "Red" links from A to B and C to D to be used exclusively by the Flex-Algorithm 128 calculation.

Base SPF Topology Excluding Unreachable Links

LSLinkInfinity-Based Solution

Unreachable Link Advertisement This document specifies that if the OSPF metric of a link is advertised as LSLinkInfinity (0xffff), it MUST NOT be considered during the associated SPF computation. This applies to both the Flex-Algorithm SPF and the base SPF as long as LSLinkInfinity is specified for the OSPF metric. While the interpretation of LSLinkInfinity is only required in the base topology as other topologies are optional , OSPF routers supporting this specification MUST consistently interpret LSLinkInfinity as unreachable during the associated SPF computation. Interpretation of LSLinkInfinity as unreachable is also applicable to Flex-Algorithm SPF computations that use the OSPF link metric. An OSPF metric with LSLinkInfinity indicating a link is unreachable is applicable to the following TLVs/LSAs:

The Router-LSA
The Router-Link TLV of OSPFv3 E-Router-LSA

Unreachable Link Backward Compatibility Prior to this specification, OSPF treated links with an advertised metric of LSLinkInfinity as reachable . Hence, partial deployment of this specification may result in routing loops due to inconsistent interpretation of LSLinkInfinity. For example, in the network shown in , link D-F is advertised with LSLinkInfinity (65535/0xffff). Router B supports LSLinkInfinity as unreachable, but router A doesn't. Router A considers link D-F as reachable, and the shortest path to F is A->B->D->F. Router B considers link D-F as unreachable, and the shortest path to F is B->A->C->E->F. As a result, A forwards the packets to B, but B returns them to A, which results in a routing loop.

Inconsistent LSLinkInfinity Interpretation Causing Loops F A------C------E A considers link D-F as reachable | | A's shortest path to F: A->B->D->F 5| |5 B considers link D-F as unreachable | | B's shortest path to F: B->A->C->E->F B------D------F 5 65535]]> To provide backward compatibility, this document specifies that routers supporting LSLinkInfinity for unreachable links support advertisement of an area-scoped Router Information LSA with a Router Functional Capabilities TLV that includes the following Router Functional Capability Bit. The value of the bit is controlled by configuration as specified in .

Bit	Capabilities
0	Unreachable Link

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 in an OSPFv2 Router Information Opaque LSA or an OSPFv3 Router Information LSA. If all OSPF routers in the area have advertised this capability, then links with an advertised metric of LSLinkInfinity MUST be treated as unreachable. When 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. In normal operation, it is possible that an area-scoped OSPF Router Information LSA will fail to reach all routers in an area in a timely manner. For example, if a new router not supporting the Unreachable Link capability joins an area that previously only had OSPF routers advertising support of the Unreachable Link capability, then it may take some time for the OSPF Router Information 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 to treating links with MaxLinkMetric as being reachable. During the propagation time, this inconsistency of MaxLinkMetric interpretation between OSPF routers can result in transient routing loops.

Stub Router Advertisement Backward Compatibility Stub Router Advertisement defines MaxLinkMetric (0xffff) to indicate a router-LSA link should not be used for transit traffic. 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). This document updates and with respect to the advertisement of MaxReachableLinkMetric rather than MaxLinkMetric. When an OSPF router supports OSPF Stub Router Advertisement and the Unreachable Link capability defined in this document, it MUST support advertisement of all its non-stub links with a link cost of MaxReachableLinkMetric (0xfffe). Since MaxLinkMetric will not be used to indicate that a link is unreachable unless all OSPF routers in the area support this specification as specified in , 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 ().

Label Distribution Protocol (LDP) IGP Synchronization Backward Compatibility LDP IGP Synchronization specifies OSPF advertisement of MaxLinkMetric (0xffff) to indicate that while the OSPF adjacency is in FULL state, LDP has not been synchronized between the two neighbors and transit IP traffic is discouraged. When an OSPF router supports the Unreachable Link capability defined in this document, the usage of OSPF MaxLinkMetric (0xffff) to discourage usage of the link until LDP is "fully operational" MUST be updated to MaxReachableLinkMetric (0xfffe). It is important to keep the link in the topology to allow IP traffic to use the link as a last resort in case of LDP packets between OSPF router loopbacks addresses or a network failure. This document updates with respect to the advertisement of MaxReachableLinkMetric rather than MaxLinkMetric.

OSPF Graceful Link Shutdown Backward Compatibility OSPF Graceful Link specifies OSPF advertisement of MaxLinkMetric (0xffff) to indicate that the link is going to be taken down and transit traffic is discouraged. When an OSPF router supports the Unreachable Link capability defined in this document, the usage of OSPF MaxLinkMetric (0xffff) to discourage usage of a link prior to it being taken out of service MUST be updated to MaxReachableLinkMetric (0xfffe). It is important to keep the link in the topology to allow IP traffic to use the link as a last resort prior to planned shutdown. This document updates with respect to the advertisement of MaxReachableLinkMetric rather than MaxLinkMetric.

Operational Considerations

Configuration Parameters Support of the Unreachable Link capability MUST be configurable. The default MUST be to not advertise the capability, i.e., the functional capability in the area-scoped OSPF Router Information LSA is false. In some networks, the operator may still want links with maximum metric (0xffff) to be treated as reachable. For example, when the cost of links is automatically computed based on the inverse of the link's bandwidth and there is a mix of low-speed and high-speed links, the computation may result in the maximum metric. Hence, implementations supporting this document and auto-costing MUST limit the maximum computed cost to MaxReachableLinkMetric (0xfffe). An example of auto-costing would be to automatically set the link metric to be inversely proportional to the link bandwidth (refer to the auto-cost feature in the "ietf-ospf" module ).

YANG Data Model This section defines three YANG modules. The "iana-ospf-functional-cap-bits" module defines the identities for OSPF Router Functional Capabilities as per the "OSPF Router Functional Capability Bits" IANA registry . The "ietf-ospf-functional-capability" and "ietf-ospf-unreachable-links" modules 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 and the YANG data model for Routing Management . This document uses the graphical representation of data models per .

Tree for OSPF Functional Capability The following shows the tree diagram of the module for OSPF Functional Capability:

Tree for OSPF Advertising Unreachable Links The following shows the tree diagram of the module for OSPF Advertising Unreachable Links:

IANA Module for OSPF Functional Capability Bits IANA has created the "OSPF Router Functional Capability Bits" registry within the "Open Shortest Path First (OSPF) Parameters" registry group to identify OSPF Router Functional Capabilities. This document defines the initial version of the IANA-maintained "iana-ospf-functional-cap-bits" module, which mirrors the IANA "OSPF Router Functional Capability Bits" registry . The module will be updated as the "OSPF Router Functional Capability Bits" registry changes. The latest version of this YANG module is available in the "YANG Module Names” registry <>.

YANG Module for OSPF Functional Capability The following is the YANG module for OSPF Functional Capability: WG List: Author: Yingzhen Qu Author: Acee Lindem Author: Liyan Gong Author: Weiqiang Cheng Author: Changwang Lin Author: Ran Chen "; description "This YANG module defines the operational state for Functional Capability in OSPF as defined in RFC 7770. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). All revisions of IETF and IANA published modules can be found at the 'YANG Parameters' registry group (https://www.iana.org/assignments/yang-parameters). This version of this YANG module is part of RFC 10041; see the RFC itself for full legal notices."; revision 2026-09-16 { description "Initial revision."; reference "RFC 10041: Advertising Unreachable Links in OSPF"; } grouping router-functional-capabilities { description "Grouping for OSPF router capabilities TLV types."; reference "RFC 7770: Extensions to OSPF for Advertising Optional Router Capabilities"; container router-functional-capabilities { leaf-list functional-capability { type identityref { base iana-ospf-fc-bits:functional-capability; } description "List of Router Functional Capabilities. This list contains the identities for functional capabilities supported by the router."; } description "OSPF Router Functional identity definitions."; } } augment "/rt:routing/" + "rt:control-plane-protocols/rt:control-plane-protocol/" + "ospf:ospf/ospf:areas/ospf:area/" + "ospf:interfaces/ospf:interface/ospf:database/" + "ospf:link-scope-lsa-type/ospf:link-scope-lsas/" + "ospf:link-scope-lsa/ospf:version/ospf:ospfv2/" + "ospf:ospfv2/ospf:body/ospf:opaque/ospf:ri-opaque/" + "ospf:router-capabilities-tlv" { when "derived-from-or-self(/rt:routing/" + "rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:type, 'ospf:ospfv2')" { description "This augmentation is only valid for OSPFv2."; } description "OSPFv2 Opaque Link-Scoped Router-Information LSA Router Functional Capabilities."; uses router-functional-capabilities; reference "RFC 7770: Extensions to OSPF for Advertising Optional Router Capabilities"; } augment "/rt:routing/" + "rt:control-plane-protocols/rt:control-plane-protocol/" + "ospf:ospf/ospf:areas/" + "ospf:area/ospf:database/" + "ospf:area-scope-lsa-type/ospf:area-scope-lsas/" + "ospf:area-scope-lsa/ospf:version/ospf:ospfv2/" + "ospf:ospfv2/ospf:body/ospf:opaque/" + "ospf:ri-opaque/ospf:router-capabilities-tlv" { when "derived-from-or-self(/rt:routing/" + "rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:type, 'ospf:ospfv2')" { description "This augmentation is only valid for OSPFv2."; } description "OSPFv2 Opaque Area-Scoped Router-Information LSA Router Functional Capabilities."; uses router-functional-capabilities; reference "RFC 7770: Extensions to OSPF for Advertising Optional Router Capabilities"; } augment "/rt:routing/" + "rt:control-plane-protocols/rt:control-plane-protocol/" + "ospf:ospf/ospf:database/" + "ospf:as-scope-lsa-type/ospf:as-scope-lsas/" + "ospf:as-scope-lsa/ospf:version/ospf:ospfv2/" + "ospf:ospfv2/ospf:body/ospf:opaque/" + "ospf:ri-opaque/ospf:router-capabilities-tlv" { when "derived-from-or-self(/rt:routing/" + "rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:type, 'ospf:ospfv2')" { description "This augmentation is only valid for OSPFv2."; } description "OSPFv2 Opaque AS-Scoped Router-Information LSA Router Functional Capabilities."; uses router-functional-capabilities; reference "RFC 7770: Extensions to OSPF for Advertising Optional Router Capabilities"; } augment "/rt:routing/" + "rt:control-plane-protocols/rt:control-plane-protocol/" + "ospf:ospf/ospf:areas/ospf:area/" + "ospf:interfaces/ospf:interface/ospf:database/" + "ospf:link-scope-lsa-type/ospf:link-scope-lsas/" + "ospf:link-scope-lsa/ospf:version/ospf:ospfv3/" + "ospf:ospfv3/ospf:body/ospf:router-information/" + "ospf:router-capabilities-tlv" { when "derived-from-or-self(/rt:routing/" + "rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:type, 'ospf:ospfv3')" { description "This augmentation is only valid for OSPFv3."; } description "OSPFv3 Link-Scoped Router-Information LSA Router Functional Capabilities."; uses router-functional-capabilities; reference "RFC 7770: Extensions to OSPF for Advertising Optional Router Capabilities"; } augment "/rt:routing/" + "rt:control-plane-protocols/rt:control-plane-protocol/" + "ospf:ospf/ospf:database/" + "ospf:as-scope-lsa-type/ospf:as-scope-lsas/" + "ospf:as-scope-lsa/ospf:version/ospf:ospfv3/" + "ospf:ospfv3/ospf:body/ospf:router-information/" + "ospf:router-capabilities-tlv" { when "derived-from-or-self(/rt:routing/" + "rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:type, 'ospf:ospfv3')" { description "This augmentation is only valid for OSPFv3."; } description "OSPFv3 AS-Scoped Router-Information LSA Router Functional Capabilities."; uses router-functional-capabilities; reference "RFC 7770: Extensions to OSPF for Advertising Optional Router Capabilities"; } augment "/rt:routing/" + "rt:control-plane-protocols/rt:control-plane-protocol/" + "ospf:ospf/ospf:areas/" + "ospf:area/ospf:database/" + "ospf:area-scope-lsa-type/ospf:area-scope-lsas/" + "ospf:area-scope-lsa/ospf:version/ospf:ospfv3/" + "ospf:ospfv3/ospf:body/ospf:router-information/" + "ospf:router-capabilities-tlv" { when "derived-from-or-self(/rt:routing/" + "rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:type, 'ospf:ospfv3')" { description "This augmentation is only valid for OSPFv3."; } description "OSPFv3 Area-Scoped Router-Information LSA Router Functional Capabilities."; uses router-functional-capabilities; reference "RFC 7770: Extensions to OSPF for Advertising Optional Router Capabilities"; } } ]]>

YANG Module for OSPF Advertising Unreachable Links The following is the YANG module for OSPF Advertising Unreachable Links: WG List: Author: Yingzhen Qu Author: Acee Lindem Author: Liyan Gong Author: Weiqiang Cheng Author: Changwang Lin Author: Ran Chen "; description "This YANG module defines the configuration and operational state for Advertising Unreachable Links in OSPF as defined in RFC 10041. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). All revisions of IETF and IANA published modules can be found at the 'YANG Parameters' registry group (https://www.iana.org/assignments/yang-parameters). This version of this YANG module is part of RFC 10041; see the RFC itself for full legal notices."; revision 2026-09-16 { description "Initial revision."; reference "RFC 10041: Advertising Unreachable Links in OSPF"; } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ospf:ospf/" + "ospf:areas/ospf:area" { when "derived-from-or-self(../../../rt:type, 'ospf:ospfv2') or " + "derived-from-or-self(../../../rt:type, 'ospf:ospfv3')" { description "This augments the OSPF routing protocol when used."; } description "This augments the OSPF protocol with Unreachable Link advertisement."; container unreachable-link-advertisement { leaf enabled { type boolean; default "false"; description "Controls the interpretation of MaxLinkMetric as unreachable and the advertisement of the Unreachable Link capability for the area. It is enabled when set to true and disabled when set to false."; } description "OSPF Unreachable Link advertisement parameters."; } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ospf:ospf/" + "ospf:areas/ospf:area/ospf:interfaces/ospf:interface" { when "derived-from(/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:type, 'ospf:ospfv2') or " + "derived-from(/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:type, 'ospf:ospfv3')" { description "This augments the OSPF interfaces."; } leaf advertise-unreachable-link { type boolean; must "not(../advertise-unreachable-link = 'true' and " + "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ospf:ospf/ospf:areas/" + "ospf:area/" + "ospf-unreach-link:unreachable-link-advertisement/" + "ospf-unreach-link:enabled = 'false')" { error-message "The interface cannot be advertised " + "as unreachable (true) unless the " + "unreachable-link-advertisement capability is " + "enabled (true)."; description "Ensures an interface isn't explicitly advertised as unreachable unless the OSPF area level capability is enabled."; } default "false"; description "Specifies that the link should be advertised with a metric of MaxLinkMetric (0xffff) in the default topology."; } description "Augment OSPF interfaces with an option to advertise the link as unreachable."; } } ]]>

Security Considerations A compromised OSPF router could advertise changes to its Unreachable Link capability rapidly resulting in repeated route recalculations on routers in the area supporting this specification (). Hence, it is RECOMMENDED that routers supporting this specification also support the SPF back-off delay algorithm described in . The security considerations for , , , and are also applicable to this protocol extension. The "ietf-ospf-unreachable-links" YANG module and the "ietf-ospf-functional-capability" YANG module each define a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF and RESTCONF . These YANG-based management protocols (1) have to use a secure transport layer (e.g., SSH , TLS , and QUIC ) and (2) have to use mutual authentication. The Network Configuration Access Control Model (NACM) provides the means to restrict access for particular NETCONF or RESTCONF users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in the "ietf-ospf-unreachable-links" YANG module that are writable/creatable/deletable (i.e., "config true", which is the default). All writable data nodes are likely to be sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. The modification of these data nodes without proper protection can prevent interpretation of the OSPF LSLinkInfinity metric as unreachable or result in a link being advertised as unreachable. /ospf:ospf/ospf:areas/ospf:area/ospf-unreach-link:unreachable-link-advertisement/ospf-unreach-link:enabled /ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/ospf-unreach-link:advertise-unreachable-link Some of the readable data nodes in the "ietf-ospf-unreachable-links" YANG module may be considered sensitive or vulnerable in some network environments. Exposure of the OSPF unreachable link configuration may be useful in mounting Denial-of-Service (DoS) attacks. These are the readable data nodes: /ospf:ospf/ospf:areas/ospf:area/ospf-unreach-link:unreachable-link-advertisement/ospf-unreach-link:enabled /ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/ospf-unreach-link:advertise-unreachable-link

IANA Considerations

Registering OSPF Router Functional Capability Bits This document defines a new bit in the "OSPF Router Functional Capability Bits" registry :

Bit Number	Capability Name	Reference
0	Unreachable Link	RFC 10041

Registering YANG Modules IANA has registered the following three new URIs in the "ns" registry within the "IETF XML Registry" :

URI:: urn:ietf:params:xml:ns:yang:iana-ospf-functional-cap-bits
Registrant Contact:: The IESG.
XML:: N/A; the requested URI is an XML namespace.

URI:: urn:ietf:params:xml:ns:yang:ietf-ospf-functional-capability
Registrant Contact:: The IESG.
XML:: N/A; the requested URI is an XML namespace.

URI:: urn:ietf:params:xml:ns:yang:ietf-ospf-unreachable-links
Registrant Contact:: The IESG.
XML:: N/A; the requested URI is an XML namespace.

IANA has registered the following three new YANG module names in the "YANG Module Names" registry within the "YANG Parameters" registry group:

Name:: iana-ospf-functional-cap-bits
Maintained by IANA?: Y
Namespace:: urn:ietf:params:xml:ns:yang:iana-ospf-functional-cap-bits
Prefix:: iana-ospf-fc-bits
Reference:: RFC 10041

Name:: ietf-ospf-functional-capability
Maintained by IANA?: N
Namespace:: urn:ietf:params:xml:ns:yang:ietf-ospf-functional-capability
Prefix:: ospf-fc
Reference:: RFC 10041

Name:: ietf-ospf-unreachable-links
Maintained by IANA?: N
Namespace:: urn:ietf:params:xml:ns:yang:ietf-ospf-unreachable-links
Prefix:: ospf-unreach-link
Reference:: RFC 10041

IANA Module for OSPF Functional Capability Bits This document defines the initial version of the IANA-maintained "iana-ospf-functional-cap-bits" YANG module (). The most recent version of the YANG module is available in the "YANG Parameters" registry . IANA has added the following note to the registry:

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 .

When a value is added to the "OSPF Router Functional Capability Bits" 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 lowercase name provided in the registry with all spaces replaced with "-". The "identity" statement should have the following sub-statements defined:

"base":: Contains 'functional-capability'.
"description":: Contains the non-abbreviated OSPF capability bit name from the registry.
"reference":: Replicates the reference(s) from the registry with the title of the document(s) added.

IANA has added this note to :

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

References Normative References OSPF Router Functional Capability Bits IANA YANG Module Names IANA Informative References

Acknowledgments Thanks to for providing the YANG data models. Thanks to for OPS Directorate review and comments. Thanks to for review and comments. Thanks to for review and comments. Thanks to , , and for review and comments.

Contributors The following individuals have contributed to this document: New H3C Technologies

China chen.mengxiao@h3c.com

Ruijie Networks Co., Ltd.

China liangyanrong@ruijie.com.cn