BGP Cease Notification Subcode For BFD

Introduction The Bidirectional Forwarding Detection protocol (BFD) 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 action when a BFD session goes down . This is typically used by the clients to take faster action in terminating their connections than the native protocol timers might allow. The Border Gateway Protocol, Version 4 (BGP) terminates its sessions upon Hold Timer expiration when the speaker does not receive a BGP message within the negotiated Hold Time interval. The minimum Hold Time interval supported by the protocol is three seconds. The Hold Timer may be optionally negotiated to being disabled with a Hold Time interval of zero. If a BGP speaker desires to have its sessions terminate faster than the supported BGP Hold Timer can accommodate upon loss of connectivity, BFD is used to supply that faster detection. When the BFD session state changes to Down, the BGP speaker terminates the session. BGP will send a NOTIFICATION message, if possible, and then close the TCP connection for the session.

BFD Cease NOTIFICATION Subcode The value 10 has been allocated by IANA for the "BFD Down" Cease NOTIFICATION message Subcode. When a BGP session 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 Down when there is only a partial loss of connectivity between two BGP Speakers. Operators using BFD for their BGP sessions make choices for what BFD timers are used based on a variety of inputs for stability vs. fast failure depending on the role BGP is playing for the deployment. In the event of a BGP session 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 the BGP NOTIFICATION message with the BFD Down Subcode. The receiving BGP Speaker will then have an understanding that the session 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 NOTIFICATION message to have been sent. Even so, BGP speakers SHOULD provide this reason as part of their operational state; e.g. bgpPeerLastError in the BGP MIB. . When the procedures in for sending a NOTIFICATION message with a Cease Code and Hard Reset Subcode, and the session 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.

Security Considerations This document introduces no additional BGP security considerations.

IANA Considerations 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.

Acknowledgments Thanks to Jeff Tantsura, and Dale Carder for their comments on the draft. 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.