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

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

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

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<!-- For a complete list and description of PIs,
     please see http://xml.resource.org/authoring/README.html. -->
<!-- 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-ietf-idr-bfd-subcode-05" number="9384" submissionType="IETF" category="std" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.12.0 -->
  <front>
    <title abbrev="BGP Cease Notification NOTIFICATION Subcode for BFD">A BGP Cease Notification NOTIFICATION Subcode For for Bidirectional Forwarding Detection (BFD)</title>

    <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bfd-subcode-05"/> name="RFC" value="9384"/>
    <author fullname="Jeffrey Haas" initials="J" surname="Haas">
      <organization>Juniper Networks</organization>
      <address>
        <email>jhaas@juniper.net</email>
      </address>
    </author>
    <date year="2022"/>
    <area/>
    <workgroup>Inter-Domain Routing</workgroup>
    <!-- <keyword/> --> year="2023" month="March" />
    <area>rtg</area>
    <workgroup>idr</workgroup>

    <abstract>
      <t>
        The Bidirectional Forwarding Detection (BFD) protocol [RFC 5880] (RFC 5880) 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 more quickly than the native original protocol timers.
      </t>
      <t>
        This document defines a Subcode subcode for the BGP Cease NOTIFICATION message
	<xref target="RFC4271" format="default" sectionFormat="comma" section="6.7"/>,
	(Section 6.7 of RFC 4271) for use when a BGP connection is being closed due to a BFD session going
        down.
      </t>
    </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>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        The Bidirectional Forwarding Detection (BFD) protocol <xref target="RFC5880" format="default"/> 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 <xref target="RFC5882" format="default"/>.  This is typically used by the
        clients to trigger closure of their connections more quickly than the
        native
        original protocol timers might allow.
      </t>
      <t>
        The
        Border Gateway Protocol, Version Protocol version 4 (BGP) (BGP-4) <xref target="RFC4271" format="default"/>
        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 Sections&nbsp;<xref target="RFC4271" section="4.2"
 sectionFormat="bare"/> and Section 4.4 <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
	been disabled by negotiating the distinguished Hold Time of zero.
      </t>
      <t>
        If a BGP speaker desires to have its connections terminate more quickly
        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
        to supply that faster detection.  When the BFD session state
        changes to Down, the BGP speaker terminates the connection with a
        Cease NOTIFICATION message sent to the neighbor, if possible, and then closes
        the TCP connection for the session.
      </t>
      <t>
	This document defines a subcode, "BFD Down", to be sent with the Cease
	NOTIFICATION message that indicates the reason for this type of
	connection termination.
      </t>
    </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&nbsp;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">
      <name>BFD Cease NOTIFICATION Subcode</name>

      <t>
        The value 10 has been allocated by IANA for the "BFD Down" Cease
        NOTIFICATION message Subcode. subcode.
      </t>
      <t>
        When a BGP connection is terminated due to a BFD session going into the
        Down state, the BGP speaker SHOULD <bcp14>SHOULD</bcp14> send a NOTIFICATION message with the
        Error Code Cease
        error code "Cease" and the Error Subcode error subcode "BFD Down".
      </t>
    </section>
    <section numbered="true" toc="default">
      <name>Operational Considerations</name>
      <t>
        A BFD session may go into the Down state when there is only a partial loss of
        connectivity between two BGP speakers.  Operators using BFD for their
        BGP connections make choices for regarding what BFD timers are used based upon a
        variety of criteria; criteria -- for example, stability vs. fast failure.
      </t>
      <t>
        In the event of a BGP connection being terminated due to a BFD Down "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.
        "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.
      </t>
      <t>
        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 been sent.
        Even so, BGP speakers SHOULD <bcp14>SHOULD</bcp14> provide this reason as part of their
        operational state.  Examples include bgpPeerLastError in per the BGP MIB
        <xref target="RFC4273" format="default"/>, format="default"/> and "last-error" in per
        <xref target="I-D.ietf-idr-bgp-model"/>.
      </t>
      <t>
        When the procedures in <xref target="RFC8538" format="default"/> for sending a
        NOTIFICATION message with a Cease Code "Cease" code and Hard Reset Subcode "Hard Reset" subcode are required, and the
        BGP connection is being terminated because BFD has gone Down, into the BFD Down
        Subcode SHOULD state, the "BFD Down"
        subcode <bcp14>SHOULD</bcp14> be encapsulated in the Hard Reset's data portion of the
        NOTIFICATION message.
      </t>
    </section>
    <section numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
	Similar to <xref target="RFC4486"/>, this document defines a subcode
	for the BGP Cease NOTIFICATION message that provides information to aid
	network operators in correlating network events and diagnosing BGP
	peering issues.  This subcode is purely informational and has no impact
	on the BGP Finite State Machine beyond that already documented by
        <xref target="RFC4271"/>, Sections&nbsp;<xref target="RFC4271" section="6.6" sectionFormat="bare"/> and <xref target="RFC4271" format="default" sectionFormat="comma" section="6.7"/>. section="6.7"
 sectionFormat="bare"/>.
      </t>
    </section>
    <section numbered="true" toc="default">
      <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>
        IANA has assigned the value 10 from the
	<eref target="https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-8">
	BGP target="https://www.iana.org/assignments/bgp-parameters/" brackets="none">
	"BGP Cease NOTIFICATION message subcodes subcodes" registry
	</eref>
	</eref>,
	with the Name name "BFD Down", Down" and a Reference reference to this document.
      </t>
    </section>
  </middle>
  <back>

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

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5882.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8538.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4273.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.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"/>
      </references>
    </references>
    <section numbered="true" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>Thanks to Jeff Tantsura, <contact fullname="Jeff Tantsura"/> and Dale Carder <contact fullname="Dale Carder"/> for their comments on the draft.</t>
      <t>Mohamed Boucadair this document.</t>
      <t><contact fullname="Mohamed Boucadair"/> provided feedback as part of the Routing Directorate
         review of this document.</t>
      <t>Bruno Rijsman
      <t>In 2006, <contact fullname="Bruno Rijsman"/> had written a proposal that
was substantively similar proposal to this document in
         2006; document: draft-rijsman-bfd-down-subcode.  That draft did not progress in IDR the Inter-Domain Routing (IDR) Working Group
         at that time.  The author of this draft document was unaware of Bruno's <contact fullname="Bruno"/>'s prior work
         when creating this proposal.
       </t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5882.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8538.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4273.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4486.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-bgp-model.xml"/>
      </references>
    </references>
  </back>
</rfc>