Network Working Group                                           L. Gong
Internet Draft                                                 W. Cheng
Intended status: Standards Track                           China Mobile
Expires: April 20, 2023                                          C. Lin
                                                                M. Chen
                                                   New H3C Technologies
                                                                R. Chen
                                                        ZTE Corporation
                                                               Y. Liang
                                              Ruijie Networks Co., Ltd.
                                                       October 20, 2022


                   Advertising Unreachable Links in OSPF
                  draft-gong-lsr-ospf-unreachable-link-00


Abstract

   This document proposes the method to advertise unreachable links in
   OSPF.

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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on April 20, 2023.







Gong, et al.            Expire April 20, 2023                 [Page 1]


Internet-Draft           OSPF Unreachable Link             October 2022


Copyright Notice

   Copyright (c) 2022 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
   (http://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 Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Table of Contents


   1. Introduction...................................................2
      1.1. Requirements Language.....................................3
   2. Use Case.......................................................3
      2.1. Case 1: Traffic Engineering...............................3
      2.2. Case 2: Flexible Algorithm................................3
   3. Solution A: Maximum Link Metric................................4
   4. Solution B: Unreachable Link Flag..............................6
   5. Backward Compatibility.........................................7
   6. Security Considerations........................................7
   7. IANA Considerations............................................7
   8. References.....................................................7
      8.1. Normative References......................................7
      8.2. Informative References....................................8
   Authors' Addresses................................................9

1. Introduction

   In some scenarios, there are requirements to advertise unreachable
   links in OSPF for purposes other than building the normal Shortest
   Path Tree. One example is a link that is available for Traffic
   Engineering (TE), but not for hop-by-hop routing. Another example is
   that specific links with dedicated resources for network slicing are
   included in Flexible Algorithm (Flex-Algorithm), but should be
   excluded in the default topology.

   This document proposes the method to advertise unreachable links in
   OSPF.




Gong, et al.           Expires April 20, 2023                 [Page 2]


Internet-Draft           OSPF Unreachable Link             October 2022


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 Case

2.1. Case 1: Traffic Engineering

   A network topology is shown in Figure 1. There is a link only
   available for Traffic Engineering between Node A and E. If that link
   is reachable in SPF computation, unexpected flows of best-effort
   service may be steered into it, which is not desired.

       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. Node A, B, C and D have an
   extra link between each other. These links have EAG attribute of
   "red" color.

    ******
   A------C------E
   |*     |*     |
   |*     |*     |        ******: "red" link
   |*     |*     |
   B------D------F
    ******

   Figure 2: Network Topology

   Flex-Algorithm 128 are enabled on Node A, B, C and D, with EAG rule
   of including "red". Flex-Algorithm allows IGP to compute the paths


Gong, et al.           Expires April 20, 2023                 [Page 3]


Internet-Draft           OSPF Unreachable Link             October 2022


   along the constrained topology. The topology used by Flex-Algorithm
   128 is shown in Figure 3.

   A******C
   *      *
   *      *
   *      *
   B******D

   Figure 3: Topology of Flex-Algorithm 128

   Flex-Algorithm 128 are used to transmit particular flows, such as
   network slice. The "red" links used by Flex-Algorithm 128 are sub-
   interfaces with dedicated queues for bandwidth guarantee. So, it is
   expected that only the particular flows are transmitted on these
   links using Flex-Algorithm 128. However, these links are also
   contained in the default topology used by normal SPF calculation,
   and unexpected flows of best-effort service may be steered into
   these links. Therefore, it is a problem that the dedicated links for
   Flex-Algorithm are still reachable in normal SPF calculation.

   If all the "red" links are advertised as unreachable, the default
   topology used in normal SPF calculation will be as Figure 4. So that
   only the network slice traffics will be steered into the "red" links
   by Flex-Algorithm 128.

   A------C------E
   |      |      |
   |      |      |
   |      |      |
   B------D------F

   Figure 4: SPF Topology after Excluding Unreachable Links

3. Solution A: Maximum Link Metric

   In OSPF protocol, there are some inconsistencies when a link is
   advertised with the maximum link metric (0xffff). [RFC1247]
   specifies that, if the cost of the link is 0xffff, the link should
   not be used for data traffic. However, if a router performs an
   intra-area Dijkstra calculation as specified in [RFC1583] and
   higher, it do not treat links with maximum link metric as
   unreachable.

   [RFC6987] defines the MaxLinkMetric (0xffff) which indicates a
   router-LSA link to be unreachable, in order to support stub router
   advertisement.


Gong, et al.           Expires April 20, 2023                 [Page 4]


Internet-Draft           OSPF Unreachable Link             October 2022


   About the backward compatibility, [RFC6987] states that "Note that
   this inconsistency will not lead to routing loops, because if there
   are some alternate paths in the network, both types of routers will
   agree on using them rather than the path through the stub router. If
   the path through the stub router is the only one, the routers of the
   first type will not use the stub router for transit (which is the
   desired behavior), while the routers of the second type will still
   use this path".

   However, if the MaxLinkMetric is used for general purposes, such
   inconsistency may lead to routing loops. For example, in the network
   shown as Figure 5, link D-F is advertised with MaxLinkMetric
   (65535/0xffff). Router A supports MaxLinkMetric, but router B does
   not. Router A sees link D-F as reachable, and the shortest path to F
   is A->B->D->F. Router B sees 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 causes routing loops.

      40000  40000      Traffic: A->F
    A------C------E       A sees link D-F as reachable
    |             |         A's shortest path: A->B->D->F
   5|             |5      B sees link D-F as unreachable
    |             |         B's shortest path: B->A->C->E->F
    B------D------F
        5    65535

   Figure 5: Inconsistency of MaxLinkMetric Causing Loops

   To improve backward compatibility, this document defines that all
   routers supporting MaxLinkMetric must advertise a Router Information
   (RI) LSA with a Router Functional Capabilities TLV [RFC7770]
   including the following Router Functional Capability Bit:

   Bit       Capabilities
   TBD       MaxLinkMetric support

   Upon detecting the presence of a reachable Router-LSA without a
   companion RI LSA that has the bit set, all routers MUST recalculate
   routes without considering MaxLinkMetric.

   In addition, this document extends MaxLinkMetric to be applicable
   for the following TLVs/LSAs as well:

   o The OSPFv2 Extended Link TLV of OSPFv2 Extended Link Opaque LSA
      [RFC7684]

   o The Router-Link TLV of OSPFv3 E-Router-LSA [RFC8362]


Gong, et al.           Expires April 20, 2023                 [Page 5]


Internet-Draft           OSPF Unreachable Link             October 2022


4. Solution B: Unreachable Link Flag

   A new OSPF Link Flags sub-TLV is defined in OSPF. The format is as
   the following:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Flags                             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o Type: TBD.

   o Length: Variable, dependent on the size of the Flags field. MUST
      be a multiple of 4 octets.

   o Flags: Following flags are currently defined.

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |U|             ~
      +-+-+-+-+-+-+-+-+

        o U-Flag: Unreachable Link Flag. The associated link MUST be
          treated as unreachable during SPF calculation.

   The OSPF Link Flags sub-TLV is advertised in the TLVs/sub-TLVs
   below:

   o OSPFv2 Extended Link TLV of OSPFv2 Extended Link Opaque LSA
      [RFC7684]

   o Router-Link TLV of OSPFv3 E-Router-LSA [RFC8362]

   Due to the change of procedures in the SPF calculation, all routers
   in an area must support the changes specified in this section. To
   ensure that, if an area is provisioned to support Unreachable Link
   Flag, all routers supporting this capability must advertise a Router
   Information (RI) LSA with a Router Functional Capabilities TLV
   [RFC7770] that includes the following Router Functional Capability
   Bit:






Gong, et al.           Expires April 20, 2023                 [Page 6]


Internet-Draft           OSPF Unreachable Link             October 2022


   Bit       Capabilities
   TBD       Unreachable Link Flag support

   Upon detecting the presence of a reachable Router-LSA without a
   companion RI LSA that has the bit set, all routers MUST recalculate
   routes without considering any Unreachable Link Flag.

5. Backward Compatibility

   Whether using solution A or solution B, all nodes in the same area
   must support that feature. To avoid topology inconsistence and
   achieve backward compatibility, routers MUST advertise the
   corresponding capability as described in Section 3 and Section 4.
   Upon detecting the absence of that capability from any router in the
   same area, all routers MUST recalculate routes without considering
   any unreachable link advertisement.

6. Security Considerations

   TBD

7. IANA Considerations

   TBD

8. References

8.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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, <http://www.rfc-editor.org/info/rfc7770>.

   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
             2119 Key Words", BCP 14, RFC 8174, May 2017.





Gong, et al.           Expires April 20, 2023                 [Page 7]


Internet-Draft           OSPF Unreachable Link             October 2022


   [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
             F. Baker, "OSPFv3 Link State Advertisement (LSA)
             Extensibility", DOI 10.17487/RFC8362, RFC 8362, April
             2018, <https://www.rfc-editor.org/info/rfc8362>.

8.2. Informative References

   [RFC1247] Moy, J., "OSPF Version 2", RFC 1247, July 1991.

   [RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994.

   [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D.
             McPherson, "OSPF Stub Router Advertisement", RFC 6987, DOI
             10.17487/RFC6987, September 2013, <http://www.rfc-
             editor.org/info/rfc6987>.

































Gong, et al.           Expires April 20, 2023                 [Page 8]


Internet-Draft           OSPF Unreachable Link             October 2022


Authors' Addresses

   Liyan Gong
   China Mobile

   Email: gongliyan@chinamobile.com


   Weiqiang Cheng
   China Mobile

   Email: chengweiqiang@chinamobile.com


   Changwang Lin
   New H3C Technologies

   Email: linchangwang.04414@h3c.com


   Mengxiao Chen
   New H3C Technologies

   Email: chen.mengxiao@h3c.com


   Ran Chen
   ZTE Corporation

   Email: chen.ran@zte.com.cn


   Yanrong Liang
   Ruijie Networks Co., Ltd.

   Email: liangyanrong@ruijie.com.cn












Gong, et al.           Expires April 20, 2023                 [Page 9]