Internet DRAFT - draft-cheng-ospf-adjacency-suppress

draft-cheng-ospf-adjacency-suppress



Network Working Group                                          W. Cheng
Internet Draft                                                  L. Gong
Intended status: Standards Track                           China Mobile
Expires: September 6, 2023                                       C. Lin
                                                                M. Chen
                                                   New H3C Technologies
                                                          March 6, 2023


                        OSPF Adjacency Suppression
                  draft-cheng-ospf-adjacency-suppress-00


Abstract

   This document describes a mechanism for a router to signal its
   neighbors to suppress advertising the adjacency to it until link-
   state database synchronization is complete. This minimizes transient
   routing disruption when a router restarts from unplanned outages.

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 September 6, 2023.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors. All rights reserved.




Cheng, et al.         Expire September 6, 2023                [Page 1]

Internet-Draft        OSPF Adjacency Suppression            March 2023


   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.....................................4
   2. LLS SA-Bit Flag................................................4
      2.1. Option A: Extended Options and Flags TLV..................4
      2.2. Option B: Reverse Metric TLV..............................4
   3. Sending Hello Packets with the SA-Bit Set......................5
   4. Receiving Hello Packets with the SA-Bit Set....................5
   5. Backward Compatibility.........................................5
   6. Security Considerations........................................6
   7. IANA Considerations............................................6
   8. References.....................................................6
      8.1. Normative References......................................6
      8.2. Informative References....................................6
   Authors' Addresses................................................8

1. Introduction

   A router that is restarting from unplanned outages may not have
   maintained forwarding function state. Since this is not the first
   time the router has started, copies of LSAs generated by this router
   in its previous incarnation may exist in the link-state databases of
   other routers in the network. These copies are likely to appear
   "newer" than LSAs initially generated by the starting router due to
   the reinitialization of LSA sequence numbers by the starting router.
   So, without requesting the starting router to update its LSAs, the
   neighbors of the starting router may transition to "Full" state and
   route the traffic through the starting router. This may cause
   temporary blackholes to occur until the normal operation of the
   update process causes the starting router to regenerate and flood
   copies of its own LSAs with higher sequence numbers.

   The stub/host router mechanism [RFC6987] [RFC8770] does not work
   well in this case, since the starting router may fail to propagate
   newer router-LSA with R-bit for OSPFv3 or H-bit for OSPFv2 before
   the temporary blackholes occurs.

Cheng, et al.         Expires September 6, 2023               [Page 2]

Internet-Draft        OSPF Adjacency Suppression            March 2023


   [RFC9339] specifies the mechanism using OSPF LLS [RFC5613] to signal
   reverse metric. Because the Reverse Metric TLV is advertised in the
   LLS block of Hello packets, the starting router is able to signal
   its neighbor to advertise maximum metric for the link towards itself
   before transitioning to the FULL state. However, the maximum metric
   in OSPF cannot ensure the associated link is unreachable in SPF
   computation. In some scenarios, the temporary blackholes may still
   occur even using the maximum reverse metric.

   For example, in the following network the hosts are multihomed to
   router B and router C. Both B and C advertise an aggregated prefix
   1.0.0.0/8 for the host network. Most of the traffics to the host
   network will be load balanced between B and C. Meanwhile, B and C
   also advertise two specific prefixes, 1.1.1.0/24 and 1.2.2.0/24
   respectively, in order to optimize the forwarding path for the
   traffics to those prefixes. Assume that an unplanned outage happens
   on B. After that, A forward all the traffics towards the host
   network to C. When B restarts, it signals A to advertise maximum
   metric for the link A-B by using Reverse Metric TLV carried in the
   LLS block of Hello packets. For the route to 1.0.0.0/8, A still
   chooses C as the next-hop, because the cost of link A-C is smaller.
   But for the route to 1.1.1.0/24, A chooses B as the next-hop,
   because that prefix is only available on B and B is reachable. So,
   the traffics to 1.1.1.0/24 is forwarded to B. However, B is not
   ready to perform the forwarding service for the host network at that
   moment, and B has not yet propagated newer versions of LSA to
   withdraw that prefix. As a result, a temporary blackhole occurs.

           1.0.0.0/8
           1.1.1.0/24
      ----B
     /     \**************
    A       *Host Network*
     \     /**************
      ----C
           1.0.0.0/8
           1.2.2.0/24

   This document describes extensions to OSPF LLS [RFC5613] to signal
   adjacency suppression. This OSPF protocol extension provides
   functionality similar to the SA bit of Restart TLV in IS-IS
   [RFC8706]. With the proposed mechanism, the starting router's
   neighbors will suppress advertising an adjacency to the starting
   router until the starting router has been able to propagate newer
   versions of LSAs, so that the temporary blackholes can be avoided.




Cheng, et al.         Expires September 6, 2023               [Page 3]

Internet-Draft        OSPF Adjacency Suppression            March 2023


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. LLS SA-Bit Flag

   This Section defines the extension for OSPF protocol to signal SA-
   bit Flag, which provides functionality similar to the SA bit of
   Restart TLV in IS-IS [RFC8706]. There are two possible positions in
   the OSPF LLS [RFC5613] to carry the SA-bit Flag.

2.1. Option A: Extended Options and Flags TLV

   The SA-Bit can be carried in the Type 1 Extended Options and Flags
   TLV [RFC5613]. This bit is defined for the LLS block included in
   Hello packets and indicates the receiver to suppress advertising an
   adjacency to the sender.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             1                 |            4                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Extended Options and Flags                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Extended Options Bit:
     0x00000001: LR-bit
     0x00000002: RS-bit
     0x00000004: I-bit
     0x00000008: F-bit
     0x00000010: B-bit
     0x00000020: FR-bit
     TBD       : SA-bit

         Figure 1: Format of the Extended Options and Flags TLV

2.2. Option B: Reverse Metric TLV

   The SA-Bit can be carried in the Type 19 Reverse Metric TLV
   [RFC9339]. This bit is defined for the LLS block included in Hello
   packets and indicates the receiver to suppress advertising an
   adjacency to the sender.


Cheng, et al.         Expires September 6, 2023               [Page 4]

Internet-Draft        OSPF Adjacency Suppression            March 2023


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              19               |               4               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     MTID      |     Flags     |        Reverse Metric         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags:
     0x00000001: H-bit
     0x00000002: O-bit
     TBD       : SA-bit

                Figure 2: Format of the Reverse Metric TLV

3. Sending Hello Packets with the SA-Bit Set

   When a router is starting, it starts a timer T-SA and sends Hello
   Packets containing the LLS block that has the SA-bit set to
   neighbors. After the synchronization of link-state database is
   complete, the timer T-SA is canceled.

   When the timer T-SA has expired or been canceled, the starting
   router MUST send Hello Packets with the SA-bit clear.

4. Receiving Hello Packets with the SA-Bit Set

   When a router receives a Hello packet containing the LLS block that
   has the SA-bit set, if there exists on this interface an adjacency
   in the FULL state with the same Router ID, then the router MUST
   suppress advertisement of the adjacency to the neighbor in its own
   LSAs. In the case of broadcast and NBMA links, the Designated
   Routers are responsible for the suppressing of adjacency
   advertisement.

   Until a Hello packet with the SA-bit clear has been received, the
   neighbor advertisement MUST continue to be suppressed. If the
   neighbor transitions to the FULL state, the new adjacency MUST NOT
   be advertised until a Hello packet with the SA-bit clear has been
   received.

   Besides, a router that suppresses advertisement of an adjacency MUST
   NOT use this adjacency when performing its SPF calculation.

5. Backward Compatibility

   The described technique requires cooperation from neighboring
   routers. If a router does not support this technique, it will ignore

Cheng, et al.         Expires September 6, 2023               [Page 5]

Internet-Draft        OSPF Adjacency Suppression            March 2023


   the SA-bit in the LLS and advertise the adjacency when the neighbor
   transitions to the FULL state. As a result, the behavior would be
   the same as without this specification.

6. Security Considerations

   TBD.

7. IANA Considerations

   This document makes the following updates under the "Open Shortest
   Path First (OSPF) Link Local Signaling (LLS) - Type/Length/ Value
   Identifiers (TLV)" parameters.

   o SA-bit, 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.

   [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
             Yeung, "OSPF Link-Local Signaling", RFC 5613, DOI
             10.17487/RFC5613, August 2009, <https://www.rfc-
             editor.org/info/rfc5613>.

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

   [RFC9339] Talaulikar, K., Psenak, P., and H. Johnston, " OSPF
             Reverse Metric", RFC 9339, DOI 10.17487/RFC9339, December
             2022, <https://www.rfc-editor.org/info/rfc9339>.

8.2. Informative References

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

   [RFC8706] Ginsberg, L., and P. Wells, "Restart Signaling for IS-IS",
             RFC 8706, DOI 10.17487/RFC8706, February 2020,
             <https://www.rfc-editor.org/info/rfc8706>.




Cheng, et al.         Expires September 6, 2023               [Page 6]

Internet-Draft        OSPF Adjacency Suppression            March 2023


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












































Cheng, et al.         Expires September 6, 2023               [Page 7]

Internet-Draft        OSPF Adjacency Suppression            March 2023


Authors' Addresses

   Weiqiang Cheng
   China Mobile
   China
   Email: chengweiqiang@chinamobile.com


   Liyan Gong
   China Mobile
   China
   Email: gongliyan@chinamobile.com


   Changwang Lin
   New H3C Technologies
   China
   Email: linchangwang.04414@h3c.com


   Mengxiao Chen
   New H3C Technologies
   China
   Email: chen.mengxiao@h3c.com
























Cheng, et al.         Expires September 6, 2023               [Page 8]