Skip to main content

BGP Cease Notification Subcode For BFD
draft-ietf-idr-bfd-subcode-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 9384.
Author Jeffrey Haas
Last updated 2022-10-06 (Latest revision 2022-08-21)
Replaces draft-haas-idr-bfd-subcode
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Consensus: Waiting for Write-Up
Document shepherd Keyur Patel
Shepherd write-up Show Last changed 2022-09-29
IESG IESG state Became RFC 9384 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to keyur@arrcus.com
draft-ietf-idr-bfd-subcode-03
Inter-Domain Routing                                             J. Haas
Internet-Draft                                          Juniper Networks
Intended status: Standards Track                          21 August 2022
Expires: 22 February 2023

                 BGP Cease Notification Subcode For BFD
                     draft-ietf-idr-bfd-subcode-03

Abstract

   The Bidirectional Forwarding Detection protocol (BFD) 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 use that detection of loss of
   connectivity to bring down the 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.

Requirements Language

   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.

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).  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 22 February 2023.

Haas                    Expires 22 February 2023                [Page 1]
Internet-Draft   BGP Cease Notification Subcode For BFD      August 2022

Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  BFD Cease NOTIFICATION Subcode  . . . . . . . . . . . . . . .   3
   3.  Operational Considerations  . . . . . . . . . . . . . . . . .   3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   The Bidirectional Forwarding Detection protocol (BFD) [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 action when a BFD session goes
   down [RFC5882].  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) [RFC4271] 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

Haas                    Expires 22 February 2023                [Page 2]
Internet-Draft   BGP Cease Notification Subcode For BFD      August 2022

   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.

2.  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".

3.  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.
   [RFC4273].

   When the procedures in [RFC8538] 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.

4.  Security Considerations

   This document introduces no additional BGP security considerations.

Haas                    Expires 22 February 2023                [Page 3]
Internet-Draft   BGP Cease Notification Subcode For BFD      August 2022

5.  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.

6.  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.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <https://www.rfc-editor.org/info/rfc5880>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2.  Informative References

   [RFC4273]  Haas, J., Ed. and S. Hares, Ed., "Definitions of Managed
              Objects for BGP-4", RFC 4273, DOI 10.17487/RFC4273,
              January 2006, <https://www.rfc-editor.org/info/rfc4273>.

   [RFC4486]  Chen, E. and V. Gillet, "Subcodes for BGP Cease
              Notification Message", RFC 4486, DOI 10.17487/RFC4486,
              April 2006, <https://www.rfc-editor.org/info/rfc4486>.

Haas                    Expires 22 February 2023                [Page 4]
Internet-Draft   BGP Cease Notification Subcode For BFD      August 2022

   [RFC5882]  Katz, D. and D. Ward, "Generic Application of
              Bidirectional Forwarding Detection (BFD)", RFC 5882,
              DOI 10.17487/RFC5882, June 2010,
              <https://www.rfc-editor.org/info/rfc5882>.

   [RFC8538]  Patel, K., Fernando, R., Scudder, J., and J. Haas,
              "Notification Message Support for BGP Graceful Restart",
              RFC 8538, DOI 10.17487/RFC8538, March 2019,
              <https://www.rfc-editor.org/info/rfc8538>.

Author's Address

   Jeffrey Haas
   Juniper Networks
   Email: jhaas@juniper.net

Haas                    Expires 22 February 2023                [Page 5]