Advertising Unreachable Links in OSPF

Introduction 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 with dedicated resources for a network slice included in a Flexible Algorithm 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 ).

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 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 include in the base SPF calculation for the default topology and may be used for hop-by-hop routing in the default topology.

Case 2: Flexible Algorithm 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 devoted to specific traffic. These links have an Extended Administrative Group (EAG) attribute specifying the "Red" color. 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. The "Red" links that 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 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.

LSInfinity-Based Solution

Unreachable Link Advertisement This document specifies that if the IGP metric of a link is advertised as LSLinkInfinity (0xffff), it MUST NOT be considered during the related 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 interpretaion 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. This applies to both the Flex- Algorithm SPF and the base SPF as long as LSLinkInfinity is specified for the IGP metric. An IGP metic with LSLinkInfinity indicating a link is unreachable is applicable to the following TLVs/LSAs:

The Router-LSA
The OSPFv2 Extended Link TLV of OSPFv2 Extended Link Opaque LSA
The Router-Link TLV of OSPFv3 E-Router-LSA

Unreachable Link Backward Compatibility Prior to this specification, OSPF treated links advertised as 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 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. 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 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 Backward Compatibility Stub Router Advertisement defines MaxLinkMetric (0xffff) to indicate a router-LSA link should not be used for transit traffic. This document updates and . 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). When an OSPFv2 router supports and the Unreachable Link support capability defined in this document, it MUST also support advertise 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 , 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 to prevent usage stub router links for transit traffic. Similarily, OSPFv2 routers supporting can advertise the H-bit in the router-LSA options.

Management Considerations 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 auto- costing of links is used and there is a mix of low-speed and high- speed links. In such cases, the updated routers 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 is a data definition language used to define the contents of a conceptual data store that allows networked devices to be managed using NETCONF or RESTCONF . This section defines a YANG data model that 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 . The following show the tree diagram of the module:

The following is the YANG module: WG List: Author: Yingzhen Qu Author: Acee Lindem "; 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). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; reference "RFC XXXX"; revision 2025-08-20 { description "Initial version"; reference "RFC XXXX: Advertising Unreachable Links in OSPF"; } identity functional-capability { description "Base identity for router informational capabilities."; } identity unreachable-link { base ospf-unreach-link:functional-capability; description "When set, the router is capable of advertising unreachable links."; } 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-capabilities { type identityref { base functional-capability; } description "List of functional capabilities. This list will contain 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" { when "../rt:type = 'ospf:ospfv2' or " + "../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 "Enable advertisement of unreachable links."; } description "OSPF unreachable link advertisement configuration."; } } 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(/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 (RFC 7770)."; uses router-functional-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(/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 (RFC 7770)."; uses router-functional-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(/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 (RFC 7770)."; uses router-functional-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(/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 (RFC 7770)."; uses router-functional-capabilities; } } ]]>

Security Considerations The document does not introduce any new security issues for the OSPF protocol. The security considerations for ,, , and are applicable to protocol extension. The ietf-ospf-link-unreach YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF and RESTCONF . These protocols have to use a secure transport layer (e.g., SSH , TLS , and QUIC ) and have to use mutual authentication. The NETCONF 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. The following data nodes defined in the 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.

/ospf:ospf/ospf-unreach-link:unreachable-link-advertisement/ospf-unreach-link:enabled

Some of the readable data nodes in this 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:

/ospf:ospf/ospf-unreach-link:unreachable-link-advertisement/ospf-unreach-link:enabled

IANA Considerations 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 one new URI from the IETF XML registry (). Authors are suggesting the following URI: This document also requests one new YANG module name in the YANG Module Names registry () with the following suggestion :

Contributors The following individuals have contributed to this document:

Mengxiao Chen
New H3C Technologies
China
Email: chen.mengxiao@h3c.com
Yanrong Liang
Ruijie Networks Co., Ltd.
China
Email: liangyanrong@ruijie.com.cn