Diff: rfc9384.original.xml

	rfc9384.original.xml	rfc9384.xml

	<?xml version='1.0' encoding='utf-8'?>	<?xml version="1.0" encoding="UTF-8"?>

		<!-- [CS] updated by Chris 02/02/23 -->

		<!-- draft submitted in xml v3 -->

	<!DOCTYPE rfc [	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>

	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- used by XSLT processors -->	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-idr-bfd-subc
	<!-- OPTIONS, known as processing instructions (PIs) go here. -->	ode-05" number="9384" submissionType="IETF" category="std" consensus="true" ipr=
	<!-- For a complete list and description of PIs,	"trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="
	please see http://xml.resource.org/authoring/README.html. -->	3" symRefs="true" sortRefs="true" version="3">
	<!-- Below are generally applicable PIs that most I-Ds might want to use. -->
	<?rfc strict="yes" ?>
	<!-- give errors regarding ID-nits and DTD validation -->
	<!-- control the table of contents (ToC): -->
	<?rfc toc="yes"?>
	<!-- generate a ToC -->
	<?rfc tocdepth="3"?>
	<!-- the number of levels of subsections in ToC. default: 3 -->
	<!-- control references: -->
	<?rfc symrefs="yes"?>
	<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
	<?rfc sortrefs="yes" ?>
	<!-- sort the reference entries alphabetically -->
	<!-- control vertical white space:
	(using these PIs as follows is recommended by the RFC Editor) -->
	<?rfc compact="yes" ?>
	<!-- do not start each main section on a new page -->
	<?rfc subcompact="no" ?>
	<!-- keep one blank line between list items -->
	<!-- end of popular PIs -->
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
	tf-idr-bfd-subcode-05" ipr="trust200902" obsoletes="" updates="" submissionType=
	"IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="tru
	e" version="3">
	<!-- xml2rfc v2v3 conversion 3.12.0 -->	<!-- xml2rfc v2v3 conversion 3.12.0 -->
	<front>	<front>

	<title abbrev="BGP Cease Notification Subcode for BFD">A BGP Cease Notificat	<title abbrev="BGP Cease NOTIFICATION Subcode for BFD">A BGP Cease NOTIFICAT
	ion Subcode For Bidirectional Forwarding Detection (BFD)</title>	ION Subcode for Bidirectional Forwarding Detection (BFD)</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-idr-bfd-subcode-05"/>
		<seriesInfo name="RFC" value="9384"/>
	<author fullname="Jeffrey Haas" initials="J" surname="Haas">	<author fullname="Jeffrey Haas" initials="J" surname="Haas">
	<organization>Juniper Networks</organization>	<organization>Juniper Networks</organization>
	<address>	<address>
	<email>jhaas@juniper.net</email>	<email>jhaas@juniper.net</email>
	</address>	</address>
	</author>	</author>

	<date year="2022"/>	<date year="2023" month="March" />
	<area/>	<area>rtg</area>
	<workgroup>Inter-Domain Routing</workgroup>	<workgroup>idr</workgroup>
	<!-- <keyword/> -->
	<abstract>	<abstract>
	<t>	<t>

	The Bidirectional Forwarding Detection (BFD) protocol [RFC 5880] is used to detect	The Bidirectional Forwarding Detection (BFD) protocol (RFC 5880) is used to detect
	loss of connectivity between two forwarding engines, typically with	loss of connectivity between two forwarding engines, typically with
	low latency. BFD is leveraged by routing protocols, including the	low latency. BFD is leveraged by routing protocols, including the
	Border Gateway Protocol (BGP), to bring down routing protocol	Border Gateway Protocol (BGP), to bring down routing protocol

	connections faster than the native protocol timers.	connections more quickly than the original protocol timers.
	</t>	</t>
	<t>	<t>

	This document defines a Subcode for the BGP Cease NOTIFICATION message	This document defines a subcode for the BGP Cease NOTIFICATION message
	<xref target="RFC4271" format="default" sectionFormat="comma" section="6.	(Section 6.7 of RFC 4271) for use when a BGP connection is being closed d
	7"/>,	ue to a BFD session going
	for when a BGP connection is being closed due to a BFD session going
	down.	down.
	</t>	</t>
	</abstract>	</abstract>

	<note>
	<name>Requirements Language</name>
	<t>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
	<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
	they appear in all capitals, as shown here.</t>
	</note>
	</front>	</front>
	<middle>	<middle>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Introduction</name>	<name>Introduction</name>
	<t>	<t>
	The Bidirectional Forwarding Detection (BFD) protocol <xref target="RFC5 880" format="default"/> is used to detect loss of connectivity between two	The Bidirectional Forwarding Detection (BFD) protocol <xref target="RFC5 880" format="default"/> is used to detect loss of connectivity between two
	forwarding engines, typically with low latency. BFD is utilized as a	forwarding engines, typically with low latency. BFD is utilized as a
	service for various clients, including routing protocols, to provide an	service for various clients, including routing protocols, to provide an
	advisory mechanism for those clients to take appropriate actions when a BFD session	advisory mechanism for those clients to take appropriate actions when a BFD session
	goes down <xref target="RFC5882" format="default"/>. This is typically used by the	goes down <xref target="RFC5882" format="default"/>. This is typically used by the
	clients to trigger closure of their connections more quickly than the	clients to trigger closure of their connections more quickly than the

	native protocol timers might allow.	original protocol timers might allow.
	</t>	</t>
	<t>	<t>

	The Border Gateway Protocol, Version 4 (BGP) <xref target="RFC4271" form at="default"/>	Border Gateway Protocol version 4 (BGP-4) <xref target="RFC4271" format= "default"/>
	terminates its connections upon Hold Timer expiration when the speaker d oes	terminates its connections upon Hold Timer expiration when the speaker d oes
	not receive a BGP message within the negotiated Hold Time interval.	not receive a BGP message within the negotiated Hold Time interval.

	As per Section 4.2 and Section 4.4 of <xref target="RFC4271"/>, the mini	As per Sections <xref target="RFC4271" section="4.2"
	mum Hold Time	sectionFormat="bare"/> and <xref target="RFC4271" section="4.4"
		sectionFormat="bare"/> of <xref target="RFC4271"/>, the minimum Hold Time
	interval is at least three seconds, unless KEEPALIVE processing has	interval is at least three seconds, unless KEEPALIVE processing has
	been disabled by negotiating the distinguished Hold Time of zero.	been disabled by negotiating the distinguished Hold Time of zero.
	</t>	</t>
	<t>	<t>
	If a BGP speaker desires to have its connections terminate more quickly	If a BGP speaker desires to have its connections terminate more quickly
	than the negotiated BGP Hold Timer can accommodate upon loss of	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	connectivity with a neighbor, the BFD protocol can be relied upon by BGP speakers
	to supply that faster detection. When the BFD session state	to supply that faster detection. When the BFD session state
	changes to Down, the BGP speaker terminates the connection with a	changes to Down, the BGP speaker terminates the connection with a
	Cease NOTIFICATION message sent to the neighbor, if possible, and then c loses	Cease NOTIFICATION message sent to the neighbor, if possible, and then c loses
	the TCP connection for the session.	the TCP connection for the session.
	</t>	</t>
	<t>	<t>
	This document defines a subcode, "BFD Down", to be sent with the Cease	This document defines a subcode, "BFD Down", to be sent with the Cease
	NOTIFICATION message that indicates the reason for this type of	NOTIFICATION message that indicates the reason for this type of
	connection termination.	connection termination.
	</t>	</t>
	</section>	</section>

		<section>
		<name>Requirements Language</name>
		<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
		"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
		"<bcp14>SHOULD NOT</bcp14>",
		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
		are to be interpreted as described in BCP 14
		<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
		when, they appear in all capitals, as shown here.</t>
		</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>BFD Cease NOTIFICATION Subcode</name>	<name>BFD Cease NOTIFICATION Subcode</name>


	<t>	<t>
	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.
	</t>	</t>
	<t>	<t>
	When a BGP connection is terminated due to a BFD session going into the	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	Down state, the BGP speaker <bcp14>SHOULD</bcp14> send a NOTIFICATION me
	Error Code Cease and the Error Subcode "BFD Down".	ssage with the
		error code "Cease" and the error subcode "BFD Down".
	</t>	</t>
	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Operational Considerations</name>	<name>Operational Considerations</name>
	<t>	<t>

	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 lo ss of
	connectivity between two BGP speakers. Operators using BFD for their	connectivity between two BGP speakers. Operators using BFD for their

	BGP connections make choices for what BFD timers are used based upon a	BGP connections make choices regarding what BFD timers are used based up
	variety of criteria; for example, stability vs. fast failure.	on a
		variety of criteria -- for example, stability vs. fast failure.
	</t>	</t>
	<t>	<t>

	In the event of a BGP connection being terminated due to a BFD Down even t	In the event of a BGP connection being terminated due to a "BFD Down" ev ent
	from partial loss of connectivity as detected by BFD, the remote BGP	from partial loss of connectivity as detected by BFD, the remote BGP
	speaker might be able to receive a BGP Cease NOTIFICATION message with t he	speaker might be able to receive a BGP Cease NOTIFICATION message with t he

	BFD Down Subcode. The receiving BGP speaker will then have an	"BFD Down" subcode. The receiving BGP speaker will then have an
	understanding that the connection is being terminated because of a	understanding that the connection is being terminated because of a
	BFD-detected issue and not an issue with the BGP speaker.	BFD-detected issue and not an issue with the BGP speaker.
	</t>	</t>
	<t>	<t>
	When there is a total loss of connectivity between two BGP speakers, it	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 be en sent.	may not have been possible for the Cease NOTIFICATION message to have be en sent.

	Even so, BGP speakers SHOULD provide this reason as part of their	Even so, BGP speakers <bcp14>SHOULD</bcp14> provide this reason as part
	operational state. Examples include bgpPeerLastError in the BGP MIB	of their
	<xref target="RFC4273" format="default"/>, and "last-error" in	operational state. Examples include bgpPeerLastError per the BGP MIB
		<xref target="RFC4273" format="default"/> and "last-error" per
	<xref target="I-D.ietf-idr-bgp-model"/>.	<xref target="I-D.ietf-idr-bgp-model"/>.
	</t>	</t>
	<t>	<t>
	When the procedures in <xref target="RFC8538" format="default"/> for sen ding a	When the procedures in <xref target="RFC8538" format="default"/> for sen ding a

	NOTIFICATION message with a Cease Code and Hard Reset Subcode are requir	NOTIFICATION message with a "Cease" code and "Hard Reset" subcode are re
	ed, and the	quired, and the
	BGP connection is being terminated because BFD has gone Down, the BFD Do	BGP connection is being terminated because BFD has gone into the Down st
	wn	ate, the "BFD Down"
	Subcode SHOULD be encapsulated in the Hard Reset's data portion of the	subcode <bcp14>SHOULD</bcp14> be encapsulated in the Hard Reset's data p
		ortion of the
	NOTIFICATION message.	NOTIFICATION message.
	</t>	</t>
	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Security Considerations</name>	<name>Security Considerations</name>
	<t>	<t>
	Similar to <xref target="RFC4486"/>, this document defines a subcode	Similar to <xref target="RFC4486"/>, this document defines a subcode
	for the BGP Cease NOTIFICATION message that provides information to aid	for the BGP Cease NOTIFICATION message that provides information to aid
	network operators in correlating network events and diagnosing BGP	network operators in correlating network events and diagnosing BGP
	peering issues. This subcode is purely informational and has no impact	peering issues. This subcode is purely informational and has no impact
	on the BGP Finite State Machine beyond that already documented by	on the BGP Finite State Machine beyond that already documented by

	<xref target="RFC4271" format="default" sectionFormat="comma" section="6.	<xref target="RFC4271"/>, Sections <xref target="RFC4271" section="
	7"/>.	6.6" sectionFormat="bare"/> and <xref target="RFC4271" section="6.7"
		sectionFormat="bare"/>.
	</t>	</t>
	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>

	<t>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.
	</t>
	<t>	<t>
	IANA has assigned the value 10 from the	IANA has assigned the value 10 from the

	<eref target="https://www.iana.org/assignments/bgp-parameters/bgp-paramet	<eref target="https://www.iana.org/assignments/bgp-parameters/" brackets=
	ers.xhtml#bgp-parameters-8">	"none">
	BGP Cease NOTIFICATION message subcodes registry	"BGP Cease NOTIFICATION message subcodes" registry
	</eref>	</eref>,
	with the Name "BFD Down", and a Reference to this document.	with the name "BFD Down" and a reference to this document.
	</t>	</t>
	</section>	</section>

	<section numbered="true" toc="default">
	<name>Acknowledgments</name>
	<t>Thanks to Jeff Tantsura, and Dale Carder for their comments on the draf
	t.</t>
	<t>Mohamed Boucadair provided feedback as part of Routing Directorate
	review of this document.</t>
	<t>Bruno Rijsman had a substantively similar proposal to this document in
	2006; draft-rijsman-bfd-down-subcode. That draft did not progress in I
	DR
	at that time. The author of this draft was unaware of Bruno's prior wo
	rk
	when creating this proposal.
	</t>
	</section>
	</middle>	</middle>
	<back>	<back>


		<displayreference target="I-D.ietf-idr-bgp-model" to="BGP-YANG"/>

	<references>	<references>
	<name>References</name>	<name>References</name>
	<references>	<references>
	<name>Normative References</name>	<name>Normative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.2119.xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.2119.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.4271.xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.4271.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.5880.xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.5880.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.5882.xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.5882.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8174.xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8174.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8538.xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8538.xml"/>
	</references>	</references>
	<references>	<references>
	<name>Informative References</name>	<name>Informative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.4273.xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.4273.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.4486.xml"/>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.4486.xml"/>


		<!-- draft-ietf-idr-bgp-model (I-D Exists) -->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D. ietf-idr-bgp-model.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D. ietf-idr-bgp-model.xml"/>
	</references>	</references>
	</references>	</references>

		<section numbered="false" toc="default">
		<name>Acknowledgments</name>
		<t>Thanks to <contact fullname="Jeff Tantsura"/> and <contact fullname="Da
		le Carder"/> for their comments on this document.</t>
		<t><contact fullname="Mohamed Boucadair"/> provided feedback as part of th
		e Routing Directorate
		review of this document.</t>
		<t>In 2006, <contact fullname="Bruno Rijsman"/> had written a proposal tha
		t
		was substantively similar to this document: draft-rijsman-bfd-down-subcode. Tha
		t draft did not progress in the Inter-Domain Routing (IDR) Working Group
		at that time. The author of this document was unaware of <contact full
		name="Bruno"/>'s prior work
		when creating this proposal.
		</t>
		</section>
	</back>	</back>
	</rfc>	</rfc>

End of changes. 28 change blocks.
	96 lines changed or deleted	92 lines changed or added
This html diff was produced by rfcdiff 1.48.