A BGP Cease NOTIFICATION Subcode for Bidirectional Forwarding Detection (BFD)Juniper Networksjhaas@juniper.net
rtg
idr
The Bidirectional Forwarding Detection (BFD) protocol (RFC 5880) is used to detect
loss of connectivity between two forwarding engines, typically with
low latency. BFD is leveraged by routing protocols, including the
Border Gateway Protocol (BGP), to bring down routing protocol
connections more quickly than the original protocol timers.
This document defines a subcode for the BGP Cease NOTIFICATION message
(Section 6.7 of RFC 4271) for use when a BGP connection is being closed due to a BFD session going
down.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2023 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
() 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
. Introduction
. Requirements Language
. BFD Cease NOTIFICATION Subcode
. Operational Considerations
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgments
Author's Address
Introduction
The Bidirectional Forwarding Detection (BFD) protocol is used to detect loss of connectivity between two
forwarding engines, typically with low latency. BFD is utilized as a
service for various clients, including routing protocols, to provide an
advisory mechanism for those clients to take appropriate actions when a BFD session
goes down . This is typically used by the
clients to trigger closure of their connections more quickly than the
original protocol timers might allow.
Border Gateway Protocol version 4 (BGP-4)
terminates its connections upon Hold Timer expiration when the speaker does
not receive a BGP message within the negotiated Hold Time interval.
As per Sections and of , the minimum Hold Time
interval is at least three seconds, unless KEEPALIVE processing has
been disabled by negotiating the distinguished Hold Time of zero.
If a BGP speaker desires to have its connections terminate more quickly
than the negotiated BGP Hold Timer can accommodate upon loss of
connectivity with a neighbor, the BFD protocol can be relied upon by BGP speakers
to supply that faster detection. When the BFD session state
changes to Down, the BGP speaker terminates the connection with a
Cease NOTIFICATION message sent to the neighbor, if possible, and then closes
the TCP connection for the session.
This document defines a subcode, "BFD Down", to be sent with the Cease
NOTIFICATION message that indicates the reason for this type of
connection termination.
Requirements LanguageThe 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
when, and only
when, they appear in all capitals, as shown here.BFD Cease NOTIFICATION Subcode
The value 10 has been allocated by IANA for the "BFD Down" Cease
NOTIFICATION message subcode.
When a BGP connection is terminated due to a BFD session going into the
Down state, the BGP speaker SHOULD send a NOTIFICATION message with the
error code "Cease" and the error subcode "BFD Down".
Operational Considerations
A BFD session may go into the Down state when there is only a partial loss of
connectivity between two BGP speakers. Operators using BFD for their
BGP connections make choices regarding what BFD timers are used based upon a
variety of criteria -- for example, stability vs. fast failure.
In the event of a BGP connection being terminated due to a "BFD Down" event
from partial loss of connectivity as detected by BFD, the remote BGP
speaker might be able to receive a BGP Cease NOTIFICATION message with the
"BFD Down" subcode. The receiving BGP speaker will then have an
understanding that the connection is being terminated because of a
BFD-detected issue and not an issue with the BGP speaker.
When there is a total loss of connectivity between two BGP speakers, it
may not have been possible for the Cease NOTIFICATION message to have been sent.
Even so, BGP speakers SHOULD provide this reason as part of their
operational state. Examples include bgpPeerLastError per the BGP MIB
and "last-error" per
.
When the procedures in for sending a
NOTIFICATION message with a "Cease" code and "Hard Reset" subcode are required, and the
BGP connection is being terminated because BFD has gone into the Down state, the "BFD Down"
subcode SHOULD be encapsulated in the Hard Reset's data portion of the
NOTIFICATION message.
Security Considerations
Similar to , this document defines a subcode
for the BGP Cease NOTIFICATION message that provides information to aid
network operators in correlating network events and diagnosing BGP
peering issues. This subcode is purely informational and has no impact
on the BGP Finite State Machine beyond that already documented by
, Sections and .
IANA Considerations
IANA has assigned the value 10 from the
"BGP Cease NOTIFICATION message subcodes" registry
,
with the name "BFD Down" and a reference to this document.
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.A Border Gateway Protocol 4 (BGP-4)This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.This document obsoletes RFC 1771. [STANDARDS-TRACK]Bidirectional Forwarding Detection (BFD)This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]Generic Application of Bidirectional Forwarding Detection (BFD)This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. [STANDARDS-TRACK]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Notification Message Support for BGP Graceful RestartThe BGP Graceful Restart mechanism defined in RFC 4724 limits the usage of BGP Graceful Restart to BGP messages other than BGP NOTIFICATION messages. This document updates RFC 4724 by defining an extension that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION message or the Hold Time expires. This document also defines a new subcode for BGP Cease NOTIFICATION messages; this new subcode requests a full session restart instead of a Graceful Restart.Informative ReferencesYANG Model for Border Gateway Protocol (BGP-4)Kloud ServicesArrcusHuaweiJuniper NetworksThis document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects, such as RIB, based on data center, carrier, and content provider operational requirements.Work in ProgressDefinitions of Managed Objects for BGP-4This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower.The origin of this memo is from RFC 1269 "Definitions of Managed Objects for the Border Gateway Protocol (Version 3)", which was updated to support BGP-4 in RFC 1657. This memo fixes errors introduced when the MIB module was converted to use the SMIv2 language. This memo also updates references to the current SNMP framework documents.This memo is intended to document deployed implementations of this MIB module in a historical context, to provide clarifications of some items, and to note errors where the MIB module fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB module with a new one representing the current state of the BGP protocol and its extensions.This document obsoletes RFC 1269 and RFC 1657. [STANDARDS-TRACK]Subcodes for BGP Cease Notification MessageThis document defines several subcodes for the BGP Cease NOTIFICATION message that would provide more information to aid network operators in correlating network events and diagnosing BGP peering issues. [STANDARDS-TRACK]AcknowledgmentsThanks to and for their comments on this document. provided feedback as part of the Routing Directorate
review of this document.In 2006, had written a proposal that
was substantively similar to this document: draft-rijsman-bfd-down-subcode. That draft did not progress in the Inter-Domain Routing (IDR) Working Group
at that time. The author of this document was unaware of 's prior work
when creating this proposal.
Author's AddressJuniper Networksjhaas@juniper.net