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]