rfc9384.original   rfc9384.txt 
Inter-Domain Routing J. Haas Internet Engineering Task Force (IETF) J. Haas
Internet-Draft Juniper Networks Request for Comments: 9384 Juniper Networks
Intended status: Standards Track 27 December 2022 Category: Standards Track March 2023
Expires: 30 June 2023 ISSN: 2070-1721
A BGP Cease Notification Subcode For Bidirectional Forwarding Detection A BGP Cease NOTIFICATION Subcode for Bidirectional Forwarding Detection
(BFD) (BFD)
draft-ietf-idr-bfd-subcode-05
Abstract Abstract
The Bidirectional Forwarding Detection (BFD) protocol [RFC 5880] is The Bidirectional Forwarding Detection (BFD) protocol (RFC 5880) is
used to detect loss of connectivity between two forwarding engines, used to detect loss of connectivity between two forwarding engines,
typically with low latency. BFD is leveraged by routing protocols, typically with low latency. BFD is leveraged by routing protocols,
including the Border Gateway Protocol (BGP), to bring down routing including the Border Gateway Protocol (BGP), to bring down routing
protocol connections faster than the native protocol timers. protocol connections more quickly than the original protocol timers.
This document defines a Subcode for the BGP Cease NOTIFICATION
message [RFC4271], Section 6.7, 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", This document defines a subcode for the BGP Cease NOTIFICATION
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and message (Section 6.7 of RFC 4271) for use when a BGP connection is
"OPTIONAL" in this document are to be interpreted as described in BCP being closed due to a BFD session going down.
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 30 June 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9384.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. BFD Cease NOTIFICATION Subcode . . . . . . . . . . . . . . . 3 2. Requirements Language
3. Operational Considerations . . . . . . . . . . . . . . . . . 3 3. BFD Cease NOTIFICATION Subcode
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4. Operational Considerations
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. References
7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.1. Normative References
7.2. Informative References . . . . . . . . . . . . . . . . . 5 7.2. Informative References
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 Acknowledgments
Author's Address
1. Introduction 1. Introduction
The Bidirectional Forwarding Detection (BFD) protocol [RFC5880] is The Bidirectional Forwarding Detection (BFD) protocol [RFC5880] is
used to detect loss of connectivity between two forwarding engines, used to detect loss of connectivity between two forwarding engines,
typically with low latency. BFD is utilized as a service for various typically with low latency. BFD is utilized as a service for various
clients, including routing protocols, to provide an advisory clients, including routing protocols, to provide an advisory
mechanism for those clients to take appropriate actions when a BFD mechanism for those clients to take appropriate actions when a BFD
session goes down [RFC5882]. This is typically used by the clients session goes down [RFC5882]. This is typically used by the clients
to trigger closure of their connections more quickly than the native to trigger closure of their connections more quickly than the
protocol timers might allow. original protocol timers might allow.
The Border Gateway Protocol, Version 4 (BGP) [RFC4271] terminates its Border Gateway Protocol version 4 (BGP-4) [RFC4271] terminates its
connections upon Hold Timer expiration when the speaker does not connections upon Hold Timer expiration when the speaker does not
receive a BGP message within the negotiated Hold Time interval. As receive a BGP message within the negotiated Hold Time interval. As
per Section 4.2 and Section 4.4 of [RFC4271], the minimum Hold Time per Sections 4.2 and 4.4 of [RFC4271], the minimum Hold Time interval
interval is at least three seconds, unless KEEPALIVE processing has is at least three seconds, unless KEEPALIVE processing has been
been disabled by negotiating the distinguished Hold Time of zero. disabled by negotiating the distinguished Hold Time of zero.
If a BGP speaker desires to have its connections terminate more If a BGP speaker desires to have its connections terminate more
quickly than the negotiated BGP Hold Timer can accommodate upon loss quickly than the negotiated BGP Hold Timer can accommodate upon loss
of connectivity with a neighbor, the BFD protocol can be relied upon of connectivity with a neighbor, the BFD protocol can be relied upon
by BGP speakers to supply that faster detection. When the BFD by BGP speakers to supply that faster detection. When the BFD
session state changes to Down, the BGP speaker terminates the session state changes to Down, the BGP speaker terminates the
connection with a Cease NOTIFICATION message sent to the neighbor, if connection with a Cease NOTIFICATION message sent to the neighbor, if
possible, and then closes the TCP connection for the session. possible, and then closes the TCP connection for the session.
This document defines a subcode, "BFD Down", to be sent with the This document defines a subcode, "BFD Down", to be sent with the
Cease NOTIFICATION message that indicates the reason for this type of Cease NOTIFICATION message that indicates the reason for this type of
connection termination. connection termination.
2. BFD Cease NOTIFICATION Subcode 2. 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.
3. BFD Cease NOTIFICATION Subcode
The value 10 has been allocated by IANA for the "BFD Down" Cease The value 10 has been allocated by IANA for the "BFD Down" Cease
NOTIFICATION message Subcode. NOTIFICATION message subcode.
When a BGP connection is terminated due to a BFD session going into When a BGP connection is terminated due to a BFD session going into
the Down state, the BGP speaker SHOULD send a NOTIFICATION message the Down state, the BGP speaker SHOULD send a NOTIFICATION message
with the Error Code Cease and the Error Subcode "BFD Down". with the error code "Cease" and the error subcode "BFD Down".
3. Operational Considerations 4. Operational Considerations
A BFD session may go Down when there is only a partial loss of A BFD session may go into the Down state when there is only a partial
connectivity between two BGP speakers. Operators using BFD for their loss of connectivity between two BGP speakers. Operators using BFD
BGP connections make choices for what BFD timers are used based upon for their BGP connections make choices regarding what BFD timers are
a variety of criteria; for example, stability vs. fast failure. 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 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 event from partial loss of connectivity as detected by BFD, the
remote BGP speaker might be able to receive a BGP Cease NOTIFICATION remote BGP speaker might be able to receive a BGP Cease NOTIFICATION
message with the BFD Down Subcode. The receiving BGP speaker will message with the "BFD Down" subcode. The receiving BGP speaker will
then have an understanding that the connection is being terminated then have an understanding that the connection is being terminated
because of a BFD-detected issue and not an issue with the BGP because of a BFD-detected issue and not an issue with the BGP
speaker. speaker.
When there is a total loss of connectivity between two BGP speakers, When there is a total loss of connectivity between two BGP speakers,
it may not have been possible for the Cease NOTIFICATION message to it may not have been possible for the Cease NOTIFICATION message to
have been sent. Even so, BGP speakers SHOULD provide this reason as have been sent. Even so, BGP speakers SHOULD provide this reason as
part of their operational state. Examples include bgpPeerLastError part of their operational state. Examples include bgpPeerLastError
in the BGP MIB [RFC4273], and "last-error" in per the BGP MIB [RFC4273] and "last-error" per [BGP-YANG].
[I-D.ietf-idr-bgp-model].
When the procedures in [RFC8538] for sending a NOTIFICATION message When the procedures in [RFC8538] for sending a NOTIFICATION message
with a Cease Code and Hard Reset Subcode are required, and the BGP with a "Cease" code and "Hard Reset" subcode are required, and the
connection is being terminated because BFD has gone Down, the BFD BGP connection is being terminated because BFD has gone into the Down
Down Subcode SHOULD be encapsulated in the Hard Reset's data portion state, the "BFD Down" subcode SHOULD be encapsulated in the Hard
of the NOTIFICATION message. Reset's data portion of the NOTIFICATION message.
4. Security Considerations 5. Security Considerations
Similar to [RFC4486], this document defines a subcode for the BGP Similar to [RFC4486], this document defines a subcode for the BGP
Cease NOTIFICATION message that provides information to aid network Cease NOTIFICATION message that provides information to aid network
operators in correlating network events and diagnosing BGP peering operators in correlating network events and diagnosing BGP peering
issues. This subcode is purely informational and has no impact on issues. This subcode is purely informational and has no impact on
the BGP Finite State Machine beyond that already documented by the BGP Finite State Machine beyond that already documented by
[RFC4271], Section 6.7. [RFC4271], Sections 6.6 and 6.7.
5. IANA 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 (https://www.iana.org/assignments/bgp-
parameters/bgp-parameters.xhtml#bgp-parameters-8) with the Name "BFD
Down", and a Reference to this document.
6. Acknowledgments
Thanks to Jeff Tantsura, and Dale Carder for their comments on the
draft.
Mohamed Boucadair provided feedback as part of Routing Directorate 6. IANA Considerations
review of this document.
Bruno Rijsman had a substantively similar proposal to this document IANA has assigned the value 10 from the "BGP Cease NOTIFICATION
in 2006; draft-rijsman-bfd-down-subcode. That draft did not progress message subcodes" registry (https://www.iana.org/assignments/bgp-
in IDR at that time. The author of this draft was unaware of Bruno's parameters/), with the name "BFD Down" and a reference to this
prior work when creating this proposal. document.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S. and RFC Publisher, "Key words for use in RFCs [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
to Indicate Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., Hares, S., Ed., and RFC [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Publisher, "A Border Gateway Protocol 4 (BGP-4)", Border Gateway Protocol 4 (BGP-4)", RFC 4271,
RFC 4271, DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[RFC5880] Katz, D., Ward, D., and RFC Publisher, "Bidirectional [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
Forwarding Detection (BFD)", RFC 5880, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
[RFC5882] Katz, D., Ward, D., and RFC Publisher, "Generic [RFC5882] Katz, D. and D. Ward, "Generic Application of
Application of Bidirectional Forwarding Detection (BFD)", Bidirectional Forwarding Detection (BFD)", RFC 5882,
RFC 5882, DOI 10.17487/RFC5882, June 2010, DOI 10.17487/RFC5882, June 2010,
<https://www.rfc-editor.org/info/rfc5882>. <https://www.rfc-editor.org/info/rfc5882>.
[RFC8174] Leiba, B. and RFC Publisher, "Ambiguity of Uppercase vs [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
DOI 10.17487/RFC8174, May 2017, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
<https://www.rfc-editor.org/info/rfc8174>.
[RFC8538] Patel, K., Fernando, R., Scudder, J., Haas, J., and RFC [RFC8538] Patel, K., Fernando, R., Scudder, J., and J. Haas,
Publisher, "Notification Message Support for BGP Graceful "Notification Message Support for BGP Graceful Restart",
Restart", RFC 8538, DOI 10.17487/RFC8538, March 2019, RFC 8538, DOI 10.17487/RFC8538, March 2019,
<https://www.rfc-editor.org/info/rfc8538>. <https://www.rfc-editor.org/info/rfc8538>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-idr-bgp-model] [BGP-YANG] Jethanandani, M., Patel, K., Hares, S., and J. Haas, "YANG
Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP Model for Border Gateway Protocol (BGP-4)", Work in
YANG Model for Service Provider Networks", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-model-16, 1
Progress, Internet-Draft, draft-ietf-idr-bgp-model-15, 13 March 2023, <https://datatracker.ietf.org/doc/html/draft-
October 2022, <https://www.ietf.org/archive/id/draft-ietf- ietf-idr-bgp-model-16>.
idr-bgp-model-15.txt>.
[RFC4273] Haas, J., Ed., Hares, S., Ed., and RFC Publisher, [RFC4273] Haas, J., Ed. and S. Hares, Ed., "Definitions of Managed
"Definitions of Managed Objects for BGP-4", RFC 4273, Objects for BGP-4", RFC 4273, DOI 10.17487/RFC4273,
DOI 10.17487/RFC4273, January 2006, January 2006, <https://www.rfc-editor.org/info/rfc4273>.
<https://www.rfc-editor.org/info/rfc4273>.
[RFC4486] Chen, E., Gillet, V., and RFC Publisher, "Subcodes for BGP [RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease
Cease Notification Message", RFC 4486, Notification Message", RFC 4486, DOI 10.17487/RFC4486,
DOI 10.17487/RFC4486, April 2006, April 2006, <https://www.rfc-editor.org/info/rfc4486>.
<https://www.rfc-editor.org/info/rfc4486>.
Acknowledgments
Thanks to Jeff Tantsura and Dale Carder for their comments on this
document.
Mohamed Boucadair provided feedback as part of the Routing
Directorate review of this document.
In 2006, Bruno Rijsman 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 Bruno's prior
work when creating this proposal.
Author's Address Author's Address
Jeffrey Haas Jeffrey Haas
Juniper Networks Juniper Networks
Email: jhaas@juniper.net Email: jhaas@juniper.net
 End of changes. 37 change blocks. 
127 lines changed or deleted 117 lines changed or added

This html diff was produced by rfcdiff 1.48.