



LSR Working Group                                                L. Gong
Internet-Draft                                                  W. Cheng
Updates: 6987, 8770 (if approved)                           China Mobile
Intended status: Standards Track                                  C. Lin
Expires: 22 March 2026                              New H3C Technologies
                                                               A. Lindem
                                                            Arrcus, Inc.
                                                                 R. Chen
                                                         ZTE Corporation
                                                       18 September 2025


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

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

Status of This Memo

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




Gong, et al.              Expires 22 March 2026                 [Page 1]

Internet-Draft    Advertising Unreachable Links in OSPF   September 2025


   This Internet-Draft will expire on 22 March 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Case 1: Traffic Engineering . . . . . . . . . . . . . . .   3
     2.2.  Case 2: Flexible Algorithm  . . . . . . . . . . . . . . .   3
   3.  LSLinkInfinity-Based Solution . . . . . . . . . . . . . . . .   4
     3.1.  Unreachable Link Advertisement  . . . . . . . . . . . . .   5
     3.2.  Unreachable Link Backward Compatibility . . . . . . . . .   5
     3.3.  Stub Router Advertisement Backward Compatibility  . . . .   6
   4.  Management Considerations . . . . . . . . . . . . . . . . . .   7
   5.  YANG Data Model . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Tree for the YANG Data Model  . . . . . . . . . . . . . .   7
     5.2.  YANG Data Model for OSPF Advertising Unreachable Links  .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  14
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  14
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     10.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

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.



Gong, et al.              Expires 22 March 2026                 [Page 2]

Internet-Draft    Advertising Unreachable Links in OSPF   September 2025


   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.

                               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.








Gong, et al.              Expires 22 March 2026                 [Page 3]

Internet-Draft    Advertising Unreachable Links in OSPF   September 2025


                      ******
                   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

3.  LSLinkInfinity-Based Solution








Gong, et al.              Expires 22 March 2026                 [Page 4]

Internet-Draft    Advertising Unreachable Links in OSPF   September 2025


3.1.  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 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:

   *  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 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



Gong, et al.              Expires 22 March 2026                 [Page 5]

Internet-Draft    Advertising Unreachable Links in OSPF   September 2025


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



Gong, et al.              Expires 22 March 2026                 [Page 6]

Internet-Draft    Advertising Unreachable Links in OSPF   September 2025


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

5.  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 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
   [RFC9129] and the YANG Data Model for Routing Management [RFC8349].

5.1.  Tree for the YANG Data Model

   This document uses the graphical representation of data models per
   [RFC8340].

   The following show the tree diagram of the module:
















Gong, et al.              Expires 22 March 2026                 [Page 7]

Internet-Draft    Advertising Unreachable Links in OSPF   September 2025


   augment /rt:routing/rt:control-plane-protocols
             /rt:control-plane-protocol/ospf:ospf:
     +--rw unreachable-link-advertisement
        +--rw enabled?   boolean
   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-capabilities*   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-capabilities*   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-capabilities*   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-capabilities*   identityref


5.2.  YANG Data Model for OSPF Advertising Unreachable Links

   The following is the YANG module:

   <CODE BEGINS> file "ietf-ospf-unreachable-links@2025-08-20.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 22 March 2026                 [Page 8]

Internet-Draft    Advertising Unreachable Links in OSPF   September 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 LSR - Link State Routing 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>";
     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";
     }



Gong, et al.              Expires 22 March 2026                 [Page 9]

Internet-Draft    Advertising Unreachable Links in OSPF   September 2025


     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



Gong, et al.              Expires 22 March 2026                [Page 10]

Internet-Draft    Advertising Unreachable Links in OSPF   September 2025


             "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/"



Gong, et al.              Expires 22 March 2026                [Page 11]

Internet-Draft    Advertising Unreachable Links in OSPF   September 2025


           + "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;
     }
   }
   <CODE ENDS>

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

   The ietf-ospf-unreachable-links YANG module defines 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.




Gong, et al.              Expires 22 March 2026                [Page 12]

Internet-Draft    Advertising Unreachable Links in OSPF   September 2025


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

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

                                  Table 2

   The IANA is requested to assign one new URI from the IETF XML
   registry ([RFC3688]).  Authors are suggesting the following URI:

   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 one new YANG module name in the YANG
   Module Names registry ([RFC6020]) with the following suggestion :







Gong, et al.              Expires 22 March 2026                [Page 13]

Internet-Draft    Advertising Unreachable Links in OSPF   September 2025


   name: ietf-ospf-unreachable-links
   namespace: urn:ietf:params:xml:ns:yang:ietf-ospf-unreachable-links
   prefix: ospf-unreach-link
   reference: RFC XXXX

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

9.  Acknowledgments

   Thanks to Yingzhen Qu for providing the YANG model.

   Thanks to Dhruv Dhody for OPS Directorate review and comments.

10.  References

10.1.  Normative References

   [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 22 March 2026                [Page 14]

Internet-Draft    Advertising Unreachable Links in OSPF   September 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 22 March 2026                [Page 15]

Internet-Draft    Advertising Unreachable Links in OSPF   September 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>.

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

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

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




Gong, et al.              Expires 22 March 2026                [Page 16]

Internet-Draft    Advertising Unreachable Links in OSPF   September 2025


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 22 March 2026                [Page 17]
