| Internet-Draft | BGP Cease Notification Subcode for BFD | October 2022 |
| Haas | Expires 16 April 2023 | [Page] |
The Bidirectional Forwarding Detection (BFD) protocol 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 faster than the native protocol timers.¶
This document defines a Subcode for the BGP Cease NOTIFICATION message for when a BGP connection is being closed due to a BFD session going down.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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.¶
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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
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."¶
This Internet-Draft will expire on 16 April 2023.¶
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 (https://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 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.¶
The Bidirectional Forwarding Detection (BFD) protocol [RFC5880] 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 [RFC5882]. This is typically used by the clients to quickly trigger closure of their connections than the native protocol timers might allow.¶
The Border Gateway Protocol, Version 4 (BGP) [RFC4271] terminates its connections upon Hold Timer expiration when the speaker does not receive a BGP message within the negotiated Hold Time interval. As per Section 4.2 of [RFC4271], the minimum Hold Time interval supported by the protocol must be either zero, or at least three seconds.¶
If a BGP speaker desires to have its connections terminate faster than the negotiated BGP Hold Timer can accommodate upon loss of connectivity with a neighbor, the BGP speakers can rely upon BFD is used to supply that faster detection. When the BFD session state changes to Down, the BGP speaker terminates the connection with a NOTIFICATION message sent to the neighbor, if possible, and then close the TCP connection for the connection.¶
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".¶
A BFD session may go Down when there is only a partial loss of connectivity between two BGP speakers. Operators using BFD for their BGP connections make choices for 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 be 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 in the BGP MIB [RFC4273], and "last-error" in [I-D.ietf-idr-bgp-model].¶
When the procedures in [RFC8538] for sending a NOTIFICATION message with a Cease Code and Hard Reset Subcode, and the BGP connection is being terminated because BFD has gone Down, the BFD Down Subcode SHOULD be encapsulated in the Hard Reset's data portion of the NOTIFICATION message.¶
This document introduces no additional BGP security considerations.¶
NOTE TO IANA and the RFC Editor: IANA is requested to make the temporary allocation below permanent. The RFC Editor is requested to delete this note to IANA prior to publication.¶
IANA has assigned the value 10 from the BGP Cease NOTIFICATION message subcodes registry with the Name "BFD Down", and a Reference of this document.¶
Thanks to Jeff Tantsura, and Dale Carder for their comments on the draft.¶
Mohamed Boucadair provided feedback as part of Routing Directorate review of this document.¶
Bruno Rijsman had a substantively similar proposal to this document in 2006; draft-rijsman-bfd-down-subcode. That draft did not progress in IDR at that time. The author of this draft was unaware of Bruno's prior work when creating this proposal.¶