| Internet-Draft | Advertising Unreachable Links in OSPF | September 2025 |
| Gong, et al. | Expires 1 April 2026 | [Page] |
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.¶
Stub Router Advertisement (RFC 6987) defines MaxLinkMetric (0xffff) to indicate a router-LSA link should not be used for transit traffic. When an OSPFv2 router supports the Unreachable Link support capability defined in this document, OSPFv2 Stub Router links are advertised as MaxReachableLinkMetric (0xfffe) rather than MaxLinkMetric (0xffff). This document updates RFC 6987 and RFC 8770 with respect to the advertisement of MaxReachableLinkMetric rather than MaxLinkMetric.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 1 April 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
In certain scenarios, it is necessary to advertise OSPF links that are not applicable to the default SPF calculation for other purposes. For example, a link may be available for Traffic Engineering (TE) purposes but not suitable for hop-by-hop routing. Another example is an OSPF link used exclusively by a Flexible Algorithm [RFC9350] 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 constraints, refer to Section 3.2).¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
A network topology is shown in Figure 1. 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.¶
TE Link
---------
/ \
/ \
A------C------E
| | |
| | |
| | |
B------D------F
Figure 1: Network Topology
¶
A network topology is shown in Figure 2. The links between nodes A and B and between C and D are to be used exclusively for a flex-algorithm [RFC9350] devoted to specific traffic. These links have an Extended Administrative Group (EAG) [RFC7308] attribute specifying the "Red" color.¶
******
A------C------E
|* |* |
|* |* | ******: "Red" link
|* |* |
B------D------F
******
Figure 2: 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 IGP metric. OSPF will compute routes for Flex-Algorithm 128 using these links. The topology associated with Flex-Algorithm 128 is shown in Figure 3.¶
A******C
* *
* *
* *
B******D
Figure 3: Topology of Flex-Algorithm 128¶
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.¶
If the IGP 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.¶
A------C------E
| | |
| | |
| | |
B------D------F
Figure 4: Base SPF Topology Excluding Unreachable Links
¶
This document specifies that if the IGP 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 IGP metric.¶
While the interpretation of LSLinkInfinity is only required in the base topology as other topologies are optional [RFC4915], OSPF routers supporting this specification MUST consistently interpret LSLinkInfinity as unreachable 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 IGP metric.¶
An IGP metric with LSLinkInfinity indicating a link is unreachable is applicable to the following TLVs/LSAs:¶
Prior to this specification, OSPF treated links advertised as LSLinkInfinity as reachable [RFC2328]. Hence, partial deployment of this specification may result in routing loops due to inconsistent interpretation of LSLinkInfinity. For example, in the network shown in Figure 5, 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.¶
40000 40000 Traffic: A->F
A------C------E A considers link D-F as reachable
| | A's shortest path: A->B->D->F
5| |5 B considers link D-F as unreachable
| | B's shortest path: B->A->C->E->F
B------D------F
5 65535
Figure 5: Inconsistent LSLinkInfinity Interpretation Causing Loops
¶
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:¶
| Bit | Capabilities |
|---|---|
| TBA | Unreachable Link support |
OSPF Routers MUST NOT treat links with an advertised metric of LSLinkInfinity as unreachable unless all routers in the OSPF area 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 support capability changes to 0 or from 0 to greater than 0, all OSPF routers in the area MUST recalculate their routes.¶
Stub Router Advertisement [RFC6987] defines MaxLinkMetric (0xffff) to indicate a router-LSA link should not be used for transit traffic.¶
When an OSPFv2 router supports the Unreachable Link support capability defined in this document, the OSPFv2 stub router MaxLinkMetric (0xffff) MUST be updated to MaxReachableLinkMetric (0xfffe). This document updates [RFC6987] and [RFC8770] with respect to the advertisement of MaxReachableLinkMetric rather than MaxLinkMetric.¶
When an OSPFv2 router supports [RFC6987] and the Unreachable Link support 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 OSPFv2 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.¶
An OSPFv3 router can simply advertise R-bit in its router-LSA options [RFC5340] to prevent usage stub router links for transit traffic. Similarly, OSPFv2 routers supporting [RFC8770] can advertise the H-bit in the router-LSA options.¶
Support of the Unreachable Link support capability SHOULD be configurable.¶
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 and there is a mix of low-speed and high-speed links, the computation may result in the maximum metric. In this case, OSPF routers supporting this specification can disable the Unreachable Link support capability and still treat links with maximum metric as reachable.¶
It is also RECOMMENDED that implementations supporting this document and auto-costing limit the maximum computed cost to MaxReachableLinkMetric (0xfffe).¶
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].¶
This section defines three YANG 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].¶
This document uses the graphical representation of data model per [RFC8340].¶
The following shows the tree diagram of the module for OSPF Functional Capability:¶
module: ietf-ospf-functional-capability
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:
+--ro router-functional-capabilities
+--ro functional-capability* identityref
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:
+--ro router-functional-capabilities
+--ro functional-capability* identityref
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:
+--ro router-functional-capabilities
+--ro functional-capability* identityref
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:
+--ro router-functional-capabilities
+--ro functional-capability* identityref
¶
The following shows the tree diagram of the module for OSPF Advertising Unreachable Links:¶
module: ietf-ospf-unreachable-links
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/ospf:ospf:
+--rw unreachable-link-advertisement
+--rw enabled? boolean
¶
IANA has created a registry titled "OSPF Router Functional Capability Bits" under the "Open Shortest Path First (OSPF) Parameters" registry group to identify OSPF Router Functional Capabilities. Module iana-ospf-functional-cap-bits is an IANA-maintained module, which defines the identities for the OSPF Functional Capabilities as in the IANA "OSPF Router Functional Capability Bits" registry.¶
This module is maintained by IANA and will be updated if and when there is any change to the registry.¶
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].¶
<CODE BEGINS> file "iana-ospf-functional-cap-bits@2025-09-28.yang"
module iana-ospf-functional-cap-bits {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:"
+ "iana-ospf-functional-cap-bits";
prefix iana-ospf-fc-bits;
organization
"Internet Assigned Numbers Authority (IANA)";
contact
"Internet Assigned Numbers Authority
ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
United States of America
Tel: +1 310 301 5800
<mailto:iana@iana.org>";
description
"This YANG module defines the identities for OSPF Router
Functional Capabilities.
This YANG module is maintained by IANA and reflects the 'OSPF
Router Functional Capability Bits' registry.
Copyright (c) 2025 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 initial version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.
The latest version of this YANG module is available at
https://www.iana.org/assignments/yang-parameters.";
revision 2025-09-28 {
description
"Initial version";
reference
"RFC XXXX: Advertising Unreachable Links in OSPF";
}
identity functional-capability {
description
"Base identity for OSPF Router Functional Capabilities. The
functional capabilities are defined in IANA OSPF Router
Functional Capability Bits registry.";
}
identity unreachable-link {
base functional-capability;
description
"Indicates that the OSPF router is capable of advertising
unreachable links.";
reference
"RFC XXXX: Advertising Unreachable Links in OSPF";
}
}
<CODE ENDS>¶
The following is the YANG module for OSPF Functional Capability:¶
<CODE BEGINS> file "ietf-ospf-functional-capability@2025-09-28.yang"
module ietf-ospf-functional-capability {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:"
+ "ietf-ospf-functional-capability";
prefix ospf-fc;
import ietf-routing {
prefix rt;
reference
"RFC 8349: A YANG Data Model for Routing Management
(NMDA Version)";
}
import ietf-ospf {
prefix ospf;
reference
"RFC 9129: YANG Data Model for the OSPF Protocol";
}
import iana-ospf-functional-cap-bits {
prefix iana-ospf-fc-bits;
reference
"RFC XXXX: Advertising Unreachable Links in OSPF";
}
organization
"IETF Link State Routing (LSR) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/lsr/>
WG List: <mailto:lsr@ietf.org>
Author: Yingzhen Qu
<mailto:yqu@futurewei.com>
Author: Acee Lindem
<mailto:acee.ietf@gmail.com>
Author: Liyan Gong
<mailto:gongliyan@chinamobile.com>
Author: Weiqiang Cheng
<mailto:chengweiqiang@chinamobile.com>
Author: Changwang Lin
<mailto:linchangwang.04414@h3c.com>
Author: Ran Chen
<mailto:chen.ran@zte.com.cn>";
description
"This YANG module defines the operational state for
Functional Capability in OSPF as defined in RFC 7770.
Copyright (c) 2025 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 XXXX; see
the RFC itself for full legal notices.";
revision 2025-09-28 {
description
"Initial version";
reference
"RFC XXXX: 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 functional capabilities. This list
contains the identities for the 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: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: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 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: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 AS-Scoped Router-Information LSA Router
Functional capabilities.";
uses router-functional-capabilities;
reference
"RFC 7770: Extensions to OSPF for Advertising Optional
Router Capabilities";
}
}
<CODE ENDS>¶
The following is the YANG module for OSPF Advertising Unreachable Links:¶
<CODE BEGINS> file "ietf-ospf-unreachable-links@2025-09-28.yang"
module ietf-ospf-unreachable-links {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:"
+ "ietf-ospf-unreachable-links";
prefix ospf-unreach-link;
import ietf-routing {
prefix rt;
reference
"RFC 8349: A YANG Data Model for Routing Management
(NMDA Version)";
}
import ietf-ospf {
prefix ospf;
reference
"RFC 9129: YANG Data Model for the OSPF Protocol";
}
organization
"IETF Link State Routing (LSR) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/lsr/>
WG List: <mailto:lsr@ietf.org>
Author: Yingzhen Qu
<mailto:yqu@futurewei.com>
Author: Acee Lindem
<mailto:acee.ietf@gmail.com>
Author: Liyan Gong
<mailto:gongliyan@chinamobile.com>
Author: Weiqiang Cheng
<mailto:chengweiqiang@chinamobile.com>
Author: Changwang Lin
<mailto:linchangwang.04414@h3c.com>
Author: Ran Chen
<mailto:chen.ran@zte.com.cn>";
description
"This YANG module defines the configuration and operational
state for Advertising Unreachable Links in OSPF as defined
in RFC XXXX.
Copyright (c) 2025 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 XXXX; see
the RFC itself for full legal notices.";
revision 2025-09-28 {
description
"Initial version";
reference
"RFC XXXX: Advertising Unreachable Links in OSPF";
}
augment "/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol/ospf:ospf" {
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 OSPF protocol with unreachable link
advertisement.";
container unreachable-link-advertisement {
leaf enabled {
type boolean;
default "false";
description
"Controls advertisement of unreachable links.
It is enabled when set to true and desabled
when set to false.";
}
description
"OSPF unreachable link advertisement parameters.";
}
}
}
<CODE ENDS>¶
The document does not introduce any new security issues for the OSPF protocol. The security considerations for [RFC2328],[RFC5340], [RFC6987], and [RFC7770] are applicable to 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 [RFC6241] and RESTCONF [RFC8040]. These YANG-based management protocols (1) have to use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use mutual authentication.¶
The NETCONF Access Control Model (NACM) [RFC8341] 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.¶
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 modifications to these data nodes without proper protection can have prevent interpreting the OSPF LSLinkInfinity metric as unreachable.¶
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 link state database may be useful in mounting a Denial-of-Service (DoS) attacks. These are the readable data nodes:¶
This document defines a new bit in the registry "OSPF Router Functional Capability Bits":¶
| Bit Number | Capability Name | Reference |
|---|---|---|
| 0(TBD) | Unreachable Link support | This document |
The IANA is requested to assign three new URIs from the IETF XML registry ([RFC3688]). Authors are suggesting the following URIs:¶
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¶
This document also requests three new YANG module names in the YANG Module Names registry ([RFC6020]) with the following suggestion :¶
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 XXXX
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 XXXX
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 XXXX
¶
This document defines the initial version of the IANA-maintained "iana-ospf-functional-cap-bits" YANG module (Section 4.2). The most recent version of the YANG module is available from the "YANG Parameters" registry [IANA-YANG-Parameters].¶
IANA is requested to add this 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 [IANA-OSPF-FC-Bits].¶
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" MUST be the name as provided in the registry. The "identity" statement should have the following sub-statements defined:¶
"base": Contains 'functional-capability'.
"description": Replicates the description from the registry.
"reference": Replicates the reference(s) from the registry with
the title of the document(s) added.
¶
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.¶
IANA is requested to add this note to [IANA-OSPF-FC-Bits]:¶
When this registry is modified, the YANG module "iana-ospf-functional-cap-bits" must be updated as defined in RFC XXXX.¶
The following individuals have contributed to this document:¶
Thanks to Yingzhen Qu for providing the YANG model.¶
Thanks to Dhruv Dhody for OPS Directorate review and comments.¶