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, . [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, . 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, . [RFC8706] Ginsberg, L., and P. Wells, "Restart Signaling for IS-IS", RFC 8706, DOI 10.17487/RFC8706, February 2020, . 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, . 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]