[フレーム] Skip to main content
Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

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

Document Type Active Internet-Draft (lsr WG)
Authors Liyan Gong , Weiqiang Cheng , Changwang Lin , Acee Lindem , Ran Chen
Last updated 2025年12月04日
Replaces draft-gong-lsr-ospf-unreachable-link
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Yang Validation 0 errors, 0 warnings
Reviews
Additional resources Mailing list discussion
Stream WG state WG Consensus: Waiting for Write-Up
Document shepherd Yingzhen Qu
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to yingzhen.ietf@gmail.com
Email authors Email WG IPR 1 References Referenced by Nits Search email archive
draft-ietf-lsr-ospf-ls-link-infinity-13
LSR Working Group L. Gong
Internet-Draft W. Cheng
Updates: 5443, 6987, 8770 (if approved) China Mobile
Intended status: Standards Track C. Lin
Expires: 7 June 2026 New H3C Technologies
 A. Lindem
 Arrcus, Inc.
 R. Chen
 ZTE Corporation
 4 December 2025
 Advertising Unreachable Links in OSPF
 draft-ietf-lsr-ospf-ls-link-infinity-13
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.
 Stub Router Advertisement (RFC 6987) defines MaxLinkMetric (0xffff)
 to indicate a router-LSA link should not be used for transit IP
 traffic. When an OSPF router supports the Unreachable Link support
 capability defined in this document, OSPF 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.
 Similarily, Label Distribution Protocol (LDP) IGP Synchronization
 (RFC5443) 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 RFC 5433 with respect to the
 advertisement of MaxReachableLinkMetric rather than MaxLinkMetric.
Status of This Memo
 This Internet-Draft is submitted in full conformance with the
 provisions of BCP 78 and BCP 79.
Gong, et al. Expires 7 June 2026 [Page 1]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 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 7 June 2026.
Copyright Notice
 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.
Table of Contents
 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
 2.1. Case 1: Traffic Engineering . . . . . . . . . . . . . . . 3
 2.2. Case 2: Flexible Algorithm . . . . . . . . . . . . . . . 4
 3. LSLinkInfinity Based Solution . . . . . . . . . . . . . . . . 5
 3.1. Unreachable Link Advertisement . . . . . . . . . . . . . 5
 3.2. Unreachable Link Backward Compatibility . . . . . . . . . 5
 3.3. Stub Router Advertisement Backward Compatibility . . . . 6
 3.4. Label Distribution Protocol (LDP) IGP Synchronization
 Backward Compatibility . . . . . . . . . . . . . . . . . 7
 4. Operational Considerations . . . . . . . . . . . . . . . . . 7
 4.1. Configuration Parameters . . . . . . . . . . . . . . . . 7
 4.2. YANG Data Model . . . . . . . . . . . . . . . . . . . . . 8
 4.2.1. Tree for OSPF Functional Capability . . . . . . . . . 8
 4.2.2. Tree for OSPF Advertising Unreachable Links . . . . . 9
 4.2.3. IANA Module for OSPF Functional Capability Bits . . . 10
 4.2.4. YANG Module for OSPF Functional Capability . . . . . 11
 4.2.5. YANG Module for OSPF Advertising Unreachable Links . 16
 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
Gong, et al. Expires 7 June 2026 [Page 2]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
 6.1. Registering OSPF Router Functional Capability Bits . . . 19
 6.2. Registering YANG Modules . . . . . . . . . . . . . . . . 20
 6.3. IANA Module for OSPF Functional Capability Bits . . . . . 20
 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21
 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
 9.1. Normative References . . . . . . . . . . . . . . . . . . 22
 9.2. Informative References . . . . . . . . . . . . . . . . . 24
 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. 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 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).
1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
 capitals, as shown here.
2. Use Cases
2.1. 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 included in the base SPF
 calculation for the default topology and may be used for hop-by-hop
 routing in the default topology.
Gong, et al. Expires 7 June 2026 [Page 3]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 TE Link
 ---------
 / \
 / \
 A------C------E
 | | |
 | | |
 | | |
 B------D------F
 Figure 1: Network Topology
2.2. 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 [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 OSPF 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.
Gong, et al. Expires 7 June 2026 [Page 4]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 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.
 A------C------E
 |
 |
 |
 B------D------F
 Figure 4: Base SPF Topology Excluding Unreachable Links
3. LSLinkInfinity Based Solution
3.1. 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 [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 OSPF metric.
 An OSPF metric with LSLinkInfinity indicating a link is unreachable
 is applicable to the following TLVs/LSAs:
 * The Router-LSA [RFC2328] [RFC5340]
 * The OSPFv2 Extended Link TLV of OSPFv2 Extended Link Opaque LSA
 [RFC7684]
 * The Router-Link TLV of OSPFv3 E-Router-LSA [RFC8362]
3.2. Unreachable Link Backward Compatibility
 Prior to this specification, OSPF treated links with an advertised
 metric of 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
Gong, et al. Expires 7 June 2026 [Page 5]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 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 |
 +-----+--------------------------+
 Table 1
 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.
3.3. Stub Router Advertisement Backward Compatibility
 Stub Router Advertisement [RFC6987] defines MaxLinkMetric (0xffff) to
 indicate a router-LSA link should not be used for transit traffic.
 When an OSPF router supports the Unreachable Link support capability
 defined in this document, the OSPF 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.
Gong, et al. Expires 7 June 2026 [Page 6]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 When an OSPF 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 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.
 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.
3.4. Label Distribution Protocol (LDP) IGP Synchronization Backward
 Compatibility
 LDP IGP Synchronization [RFC5443] 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 support 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 [RFC5443] with respect to the
 advertisement of MaxReachableLinkMetric rather than MaxLinkMetric.
4. Operational Considerations
4.1. Configuration Parameters
 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.
Gong, et al. Expires 7 June 2026 [Page 7]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 It is also RECOMMENDED that implementations supporting this document
 and auto-costing limit the maximum computed cost to
 MaxReachableLinkMetric (0xfffe).
4.2. YANG Data Model
 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].
4.2.1. Tree for OSPF Functional Capability
 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: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:
 +--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: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
Gong, et al. Expires 7 June 2026 [Page 8]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 /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: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:
 +--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
4.2.2. Tree for OSPF Advertising Unreachable Links
 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
Gong, et al. Expires 7 June 2026 [Page 9]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
4.2.3. IANA Module for OSPF Functional Capability Bits
 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
Gong, et al. Expires 7 June 2026 [Page 10]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 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>
4.2.4. YANG Module for OSPF Functional Capability
 The following is the YANG module for OSPF Functional Capability:
Gong, et al. Expires 7 June 2026 [Page 11]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 <CODE BEGINS> file "ietf-ospf-functional-capability@2025年12月04日.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.
Gong, et al. Expires 7 June 2026 [Page 12]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 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年12月04日 {
 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:interfaces/ospf:interface/ospf:database/"
 + "ospf:link-scope-lsa-type/ospf:link-scope-lsas/"
 + "ospf:link-scope-lsa/ospf:version/ospf:ospfv2/"
Gong, et al. Expires 7 June 2026 [Page 13]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 + "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/"
Gong, et al. Expires 7 June 2026 [Page 14]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 + "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
Gong, et al. Expires 7 June 2026 [Page 15]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 "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>
4.2.5. YANG Module for OSPF Advertising Unreachable Links
 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;
Gong, et al. Expires 7 June 2026 [Page 16]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 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).
Gong, et al. Expires 7 June 2026 [Page 17]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 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>
5. Security Considerations
 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.
Gong, et al. Expires 7 June 2026 [Page 18]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 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.
 /ospf:ospf/ospf-unreach-link:unreachable-link-advertisement/ospf-
 unreach-link:enabled
 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:
 /ospf:ospf/ospf-unreach-link:unreachable-link-advertisement/ospf-
 unreach-link:enabled
6. IANA Considerations
6.1. Registering OSPF Router Functional Capability Bits
 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 |
 +------------+--------------------------+---------------+
 Table 2
Gong, et al. Expires 7 June 2026 [Page 19]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
6.2. Registering YANG Modules
 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
6.3. IANA Module for OSPF Functional Capability Bits
 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:
Gong, et al. Expires 7 June 2026 [Page 20]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 | 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.
7. Contributors
 The following individuals have contributed to this document:
Gong, et al. Expires 7 June 2026 [Page 21]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 Mengxiao Chen
 New H3C Technologies
 China
 Email: chen.mengxiao@h3c.com
 Yanrong Liang
 Ruijie Networks Co., Ltd.
 China
 Email: liangyanrong@ruijie.com.cn
8. Acknowledgments
 Thanks to Yingzhen Qu for providing the YANG model.
 Thanks to Dhruv Dhody for OPS Directorate review and comments.
9. References
9.1. Normative References
 [IANA-OSPF-FC-Bits]
 IANA, "OSPF Router Functional Capability Bits",
 <https://www.iana.org/assignments/ospf-parameters>.
 [IANA-YANG-Parameters]
 IANA, "YANG Module Names",
 <https://www.iana.org/assignments/yang-parameters>.
 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 Requirement Levels", BCP 14, RFC 2119,
 DOI 10.17487/RFC2119, March 1997,
 <https://www.rfc-editor.org/info/rfc2119>.
 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
 DOI 10.17487/RFC2328, April 1998,
 <https://www.rfc-editor.org/info/rfc2328>.
 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
 DOI 10.17487/RFC3688, January 2004,
 <https://www.rfc-editor.org/info/rfc3688>.
 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
 RFC 4915, DOI 10.17487/RFC4915, June 2007,
 <https://www.rfc-editor.org/info/rfc4915>.
Gong, et al. Expires 7 June 2026 [Page 22]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
 the Network Configuration Protocol (NETCONF)", RFC 6020,
 DOI 10.17487/RFC6020, October 2010,
 <https://www.rfc-editor.org/info/rfc6020>.
 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
 and A. Bierman, Ed., "Network Configuration Protocol
 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
 <https://www.rfc-editor.org/info/rfc6241>.
 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
 2015, <https://www.rfc-editor.org/info/rfc7684>.
 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
 S. Shaffer, "Extensions to OSPF for Advertising Optional
 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
 February 2016, <https://www.rfc-editor.org/info/rfc7770>.
 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
 RFC 7950, DOI 10.17487/RFC7950, August 2016,
 <https://www.rfc-editor.org/info/rfc7950>.
 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
 <https://www.rfc-editor.org/info/rfc8040>.
 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
 Access Control Model", STD 91, RFC 8341,
 DOI 10.17487/RFC8341, March 2018,
 <https://www.rfc-editor.org/info/rfc8341>.
 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
 Routing Management (NMDA Version)", RFC 8349,
 DOI 10.17487/RFC8349, March 2018,
 <https://www.rfc-editor.org/info/rfc8349>.
 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
 F. Baker, "OSPFv3 Link State Advertisement (LSA)
 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
 2018, <https://www.rfc-editor.org/info/rfc8362>.
Gong, et al. Expires 7 June 2026 [Page 23]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 [RFC9129] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
 "YANG Data Model for the OSPF Protocol", RFC 9129,
 DOI 10.17487/RFC9129, October 2022,
 <https://www.rfc-editor.org/info/rfc9129>.
9.2. Informative References
 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
 January 2006, <https://www.rfc-editor.org/info/rfc4252>.
 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
 <https://www.rfc-editor.org/info/rfc5340>.
 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP
 Synchronization", RFC 5443, DOI 10.17487/RFC5443, March
 2009, <https://www.rfc-editor.org/info/rfc5443>.
 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D.
 McPherson, "OSPF Stub Router Advertisement", RFC 6987,
 DOI 10.17487/RFC6987, September 2013,
 <https://www.rfc-editor.org/info/rfc6987>.
 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS
 Traffic Engineering (MPLS-TE)", RFC 7308,
 DOI 10.17487/RFC7308, July 2014,
 <https://www.rfc-editor.org/info/rfc7308>.
 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
 <https://www.rfc-editor.org/info/rfc8340>.
 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
 <https://www.rfc-editor.org/info/rfc8446>.
 [RFC8770] Patel, K., Pillay-Esnault, P., Bhardwaj, M., and S.
 Bayraktar, "Host Router Support for OSPFv2", RFC 8770,
 DOI 10.17487/RFC8770, April 2020,
 <https://www.rfc-editor.org/info/rfc8770>.
 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
 Multiplexed and Secure Transport", RFC 9000,
 DOI 10.17487/RFC9000, May 2021,
 <https://www.rfc-editor.org/info/rfc9000>.
Gong, et al. Expires 7 June 2026 [Page 24]
Internet-Draft Advertising Unreachable Links in OSPF December 2025
 [RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
 and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
 DOI 10.17487/RFC9350, February 2023,
 <https://www.rfc-editor.org/info/rfc9350>.
Authors' Addresses
 Liyan Gong
 China Mobile
 China
 Email: gongliyan@chinamobile.com
 Weiqiang Cheng
 China Mobile
 China
 Email: chengweiqiang@chinamobile.com
 Changwang Lin
 New H3C Technologies
 China
 Email: linchangwang.04414@h3c.com
 Acee Lindem
 Arrcus, Inc.
 United States of America
 Email: acee.ietf@gmail.com
 Ran Chen
 ZTE Corporation
 China
 Email: chen.ran@zte.com.cn
Gong, et al. Expires 7 June 2026 [Page 25]

AltStyle によって変換されたページ (->オリジナル) /