<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-pim-bfd-p2mp-use-case-10">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> docName="draft-ietf-pim-bfd-p2mp-use-case-10" number="9186" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

<front>
    <title abbrev="BFD P2MP Use in PIM-SM">Fast Failover in Protocol Independent Multicast - Sparse Mode (PIM-SM) Using Bidirectional Forwarding Detection (BFD) for Multipoint Networks</title>
    <seriesInfo name="RFC" value="9186"/>
    <author initials="G." surname="Mirsky" fullname="Greg Mirsky">
      <organization>Ericsson</organization>
      <address>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>
    <author initials="J" surname="Xiaoli" fullname="Ji Xiaoli"> initials="X." surname="Ji" fullname="Xiaoli Ji">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
        <street>No.50
	  <extaddr>Yuhuatai District</extaddr>
	  <street>No. 50 Software Avenue, Yuhuatai District</street>
      <region>Nanjing</region> Avenue</street>
          <city>Nanjing</city>
          <country>China</country>
        </postal>
        <email>ji.xiaoli@zte.com.cn</email>
      </address>
    </author>
    <date year="2021"/> year="2022" month="January" />
    <area>Routing</area>
    <workgroup>PIM Working Group</workgroup>

    <keyword>Internet-Draft</keyword>
    <keyword>PIM-SM</keyword>

   <keyword>BFD </keyword>
    <keyword>BFD</keyword>
    <abstract>
      <t>
	This document specifies how Bidirectional Forwarding Detection (BFD) for multipoint networks
	can provide sub-second failover for routers that participate in Protocol Independent Multicast - Sparse Mode (PIM-SM).
	<!--
	over shared-media segment with the sub-second convergence of the Designated Router  	and defines the extension to bootstrap point-to-multipoint BFD session.
	-->
 An extension to the PIM Hello message used to
bootstrap a point-to-multipoint BFD session is also defined in this
document.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
Faster convergence in the control plane minimizes the periods of
traffic blackholing, loss due to the use of stale routing information, transient routing loops, and other situations
that may negatively affect service data flow.  Faster convergence
in the control plane is beneficial to unicast and multicast routing
protocols.
</t>
      <t>
 <xref target="RFC7761"/> target="RFC7761" format="default"/> is the current specification of the Protocol Independent
   Multicast - Sparse Mode (PIM-SM) for IPv4 and IPv6 networks. A conforming implementation of PIM-SM elects a Designated Router (DR)
 on each PIM-SM interface. When a group of PIM-SM nodes is connected to a shared media segment, e.g., Ethernet,
 the node elected as the DR acts on behalf of directly connected hosts in the context of the PIM-SM protocol.
Failure of the DR impacts the quality of the multicast services it
provides to directly connected hosts because the default failure detection interval
for PIM-SM routers is 105 seconds.
      </t>
      <t>
 Bidirectional Forwarding Detection (BFD) <xref target="RFC5880"/> target="RFC5880" format="default"/> was originally defined to detect
 a failure of a point-to-point (p2p) (P2P) path, single-hop single hop <xref target="RFC5881"/> target="RFC5881" format="default"/>, or multihop <xref target="RFC5883"/>. target="RFC5883" format="default"/>.
 In some PIM-SM deployments, a p2p P2P BFD can be used to detect a failure and enable faster failover.

 <xref target="RFC8562"/> target="RFC8562" format="default"/> extends the BFD base specification <xref target="RFC5880"/> target="RFC5880" format="default"/> for multipoint and multicast
 networks, which matches the deployment scenarios for PIM-SM over a LAN segment.
 <!-- Among specific characteristics of p2mp BFD that particularly benefit PIM-SM over a LAN segment is
 a faster transition to the Up state of the p2mp BFD session due to avoidance of the three-way handshake required in p2p BFD <xref target="RFC5880"/>. -->
 A BFD system in p2mp a point-to-multipoint (P2MP) environment that transmits BFD Control messages using the BFD Demand mode <xref target="RFC5880"/> target="RFC5880" format="default"/> creates less BFD state
 than the Asynchronous mode. Point-to-multipoint (p2mp) P2MP BFD can enable
 faster detection of PIM-SM router failure compared to PIM-SM without BFD and
 thus minimize minimizes multicast service disruption. The monitored PIM-SM router acts as the head and other routers act as tails of a p2mp P2MP BFD
session. This document defines the monitoring of a PIM-SM router using p2mp P2MP BFD.
This document also defines the extension to PIM-SM <xref target="RFC7761"/> target="RFC7761" format="default"/>
 to bootstrap a PIM-SM router to join in p2mp the P2MP BFD session over a shared media segment.
      </t>
      <section title="Conventions used numbered="true" toc="default">
        <name>Conventions Used in this document"> This Document</name>
        <section title="Terminology"> numbered="true" toc="default">
          <name>Terminology</name>
          <t>
This document uses terminology defined in <xref target="RFC5880"/>, target="RFC5880" format="default"/>, <xref target="RFC8562"/>, target="RFC8562" format="default"/>,
and <xref target="RFC7761"/>. target="RFC7761" format="default"/>. Familiarity with these specifications and the terminology used
is expected.
</t>
        </section>
        <section title="Requirements Language"> numbered="true" toc="default">
          <name>Requirements Language</name>
	          <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
   "MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
        </section>
      </section>
    </section>

<!--
<section anchor="problem-statement" title="Problem Statement">
<t>
<xref target="RFC7761"/> does not provide a method for fast, e.g., sub-second, failure detection of a neighbor PIM-SM router.
BFD already has many implementations based on HW that are capable
of supporting multiple sub-second sessions concurrently.
</t>
</section>
-->
<section anchor="bfd-discriminatorpim-hello-sec" title="BFD numbered="true" toc="default">
      <name>BFD Discriminator PIM Hello Option"> Option</name>
      <t>
 <xref target="tlv-p2mp-bfd-boot-fig"/> target="tlv-p2mp-bfd-boot-fig" format="default"/> displays the new optional
 BFD Discriminator PIM Hello option Option
to bootstrap a tail of the p2mp P2MP BFD session. session:
      </t>

<t>
      <figure align="left" anchor="tlv-p2mp-bfd-boot-fig" title="BFD anchor="tlv-p2mp-bfd-boot-fig">
        <name>BFD Discriminator PIM Hello Option">
          <artwork><![CDATA[ Option</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          OptionType           |         OptionLength          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       HeadDiscriminator                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ]]></artwork>
      </figure>

</t>
      <t>
where new fields are interpreted as:
<list>
<t>OptionType: TBA.</t>
<t>OptionLength: MUST
</t>
      <dl>
        <dt>OptionType:</dt><dd>39</dd>
        <dt>OptionLength:</dt><dd><bcp14>MUST</bcp14> be set to 4.</t>
<t>HeadDiscriminator: 4.</dd>
        <dt>HeadDiscriminator:</dt><dd> the four-octet 4-octet field MUST <bcp14>MUST</bcp14> be included in the BFD Discriminator PIM-SM Hello option. Option.
The value MUST NOT <bcp14>MUST NOT</bcp14> be zero. It equals the value of My Discriminator
(<xref target="RFC5880"/>)
<xref target="RFC5880" format="default"/> allocated by the head. </t>
</list> </dd>
      </dl>
      <t>
If the value of the OptionLength field is not equal to 4, the BFD Discriminator PIM Hello option Option
is considered malformed, and the receiver MUST <bcp14>MUST</bcp14> stop processing PIM Hello options. Options.
If the value of the HeadDiscriminator field equals zero, then the BFD Discriminator PIM Hello option
MUST Option
<bcp14>MUST</bcp14> be considered invalid, and the receiver MUST <bcp14>MUST</bcp14> ignore it.
The receiver SHOULD <bcp14>SHOULD</bcp14> log a notification regarding the malformed or invalid BFD Discriminator Hello option Option
under the control of a throttling logging mechanism.
</t>
      <section anchor="pim-dr-p2mp-bfd-sec" title="Using numbered="true" toc="default">
        <name>Using P2MP BFD in PIM Router Monitoring"> Monitoring</name>
        <t>
If the head is no longer serving the function that prompted it
to be monitored, then it MUST <bcp14>MUST</bcp14> cease including the BFD Discriminator
PIM Hello option Option in its PIM-Hello PIM Hello message, and it SHOULD <bcp14>SHOULD</bcp14> shut down
the BFD session following the procedures described in Section 5.9 <xref target="RFC8562"/>. target="RFC8562" sectionFormat="comma" section="5.9"/>.
</t>
        <t>
 The head MUST <bcp14>MUST</bcp14> create a BFD session of type MultipointHead <xref target="RFC8562"/>. target="RFC8562" format="default"/>.
 Note that any PIM-SM router, regardless of its role, MAY <bcp14>MAY</bcp14> become a head of a p2mp P2MP BFD session.
 To control the volume of BFD control Control traffic on a shared media segment, an operator should carefully
 select PIM-SM routers configured as a head of a p2mp P2MP BFD session.
The head MUST <bcp14>MUST</bcp14> include the BFD Discriminator PIM Hello option Option in its
PIM Hello messages.
</t>
        <t>
 A PIM-SM router that is configured to monitor the head by
using p2mp P2MP BFD is referred to throughout this document as a "tail". When such a
tail receives a PIM-Hello PIM Hello packet with the BFD Discriminator PIM Hello option, Option, the tail
MAY
<bcp14>MAY</bcp14> create a p2mp P2MP BFD session of type MultipointTail, as defined in <xref target="RFC8562"/>. target="RFC8562" format="default"/>.
        </t>
        <t>
The node that includes the BFD Discriminator PIM Hello option Option
transmits BFD Control packets periodically. For the tail to correctly
demultiplex BFD <xref target="RFC8562"/>, target="RFC8562" format="default"/>, the source
address and My Discriminator of the BFD packets MUST <bcp14>MUST</bcp14> be the same
as the source address and the HeadDiscriminator, respectively, of the PIM Hello
message. If that is not the case,
the tail BFD node would not be able to monitor the state of the PIM-SM node, node --
that is, the head of the p2mp P2MP BFD session, session -- though the regular PIM-SM mechanisms remain fully operational.
        </t>
        <t>
If the tail detects a MultipointHead failure <xref target="RFC8562"/>, target="RFC8562" format="default"/>,
 it MUST <bcp14>MUST</bcp14> delete the corresponding neighbor state and follow procedures defined in <xref target="RFC7761"/> target="RFC7761" format="default"/>
 for the DR and additional neighbor state deletion after the neighbor timeout expires.
        </t>
        <t>
 If the head ceases to include the BFD Discriminator PIM Hello option Option in its PIM-Hello PIM Hello message,
 tails SHOULD
 the tail <bcp14>SHOULD</bcp14> close the corresponding MultipointTail BFD session without affecting the PIM state in any way.
Thus, the tail stops using BFD to monitor
 the head and reverts to the procedures defined in <xref target="RFC7761"/>. target="RFC7761" format="default"/>.
        </t>
      </section>
      <section anchor="p2mp-bfd-pim-drlb-sec" title="P2MP numbered="true" toc="default">
        <name>P2MP BFD in PIM DR Load Balancing"> Balancing</name>
        <t>
<xref target="RFC8775"/> target="RFC8775" format="default"/> specifies the PIM Designated Router Load Balancing Load-Balancing (DRLB) functionality.
Any PIM router that advertises the DRLB-Cap DR Load-Balancing Capability (DRLB-Cap) Hello Option can become the head of a p2mp P2MP BFD session,
as specified in <xref target="pim-dr-p2mp-bfd-sec"/>. target="pim-dr-p2mp-bfd-sec" format="default"/>.
The head router administratively sets the bfd.SessionState to Up in
the MultipointHead session <xref target="RFC8562"/> target="RFC8562" format="default"/> only if it is a Group Designated
Router (GDR) Candidate, as specified in Sections 5.5 <xref target="RFC8775" section="5.5" sectionFormat="bare" /> and 5.6
<xref target="RFC8775" section="5.6" sectionFormat="bare" /> of
<xref target="RFC8775"/>. If the router is no longer the GDR, then it MUST <bcp14>MUST</bcp14> shut down
following the procedures described in Section 5.9 <xref target="RFC8562"/>. target="RFC8562" sectionFormat="comma" section="5.9"/>.
 For each GDR Candidate that includes the
 BFD Discriminator option Option in its PIM Hello, the PIM DR MUST <bcp14>MUST</bcp14> create a MultipointTail session <xref target="RFC8562"/>. target="RFC8562" format="default"/>. PIM DR
 demultiplexes BFD sessions based on the value of the My Discriminator field and the source IP address.
 If PIM DR detects a failure of one of the sessions, it MUST <bcp14>MUST</bcp14> remove that router from
 the GDR Candidate list and immediately transmit a new DRLB-List option.
        </t>
      </section>
      <section anchor="p2mp-bfd-encap" title="Multipoint numbered="true" toc="default">
        <name>Multipoint BFD Encapsulation"> Encapsulation</name>
        <t>
The MultipointHead of a p2mp P2MP BFD session when transmitting BFD Control packets:
<list>
<t>MUST
</t>
        <ul empty="false" spacing="normal">
          <li><bcp14>MUST</bcp14> set the TTL or Hop Limit value to 255 (Section 5 <xref target="RFC5881"/>). (<xref target="RFC5881" sectionFormat="comma" section="5"/>). Similarly, all received BFD Control packets that are
   demultiplexed to the session MUST <bcp14>MUST</bcp14> be discarded if the received TTL or
   Hop Limit is not equal to 255;</t>
<t>MUST 255, and</li>
          <li><bcp14>MUST</bcp14> use the group address ALL-PIM-ROUTERS ('224.0.0.13' ("224.0.0.13" for IPv4 and 'ff02::d' "ff02::d" for IPv6) as the destination IP address</t>
</list>
</t> address.</li>
        </ul>
      </section>
    </section>
    <section anchor="iana-consider" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
IANA is requested to allocate has allocated a new OptionType value from PIM-Hello Options in the "PIM-Hello Options" registry according to: to <xref target="bfd-disc-pim-alloc"/>:
      </t>
      <texttable
      <table anchor="bfd-disc-pim-alloc" title="BFD align="center">
        <name>BFD Discriminator option type">
    <ttcol align="left">Value</ttcol>
    <ttcol align="left">Length</ttcol>
    <ttcol align="left">Name</ttcol>
    <ttcol align="left">Reference</ttcol>
    <c>TBA</c>
    <c>4</c>
    <c>BFD Option Type</name>
        <thead>
          <tr>
            <th align="left">Value</th>
            <th align="left">Length</th>
            <th align="left">Name</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">39</td>
            <td align="left">4</td>
            <td align="left">BFD Discriminator Option</c>
    <c>This&nbsp;document</c>
    </texttable> Option</td>
            <td align="left">RFC 9186</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
  This document defines a way to accelerate detecting detection of a failure that affects PIM functionality by using BFD. The operation of either protocol is not changed.
      </t>
      <t>
 The security considerations discussed in <xref target="RFC7761"/>, target="RFC5880" format="default"/>, <xref target="RFC5880"/>, target="RFC5881" format="default"/>, <xref target="RFC5881"/>, target="RFC7761" format="default"/>, <xref target="RFC8562"/>, target="RFC8562" format="default"/>, and <xref target="RFC8775"/> target="RFC8775" format="default"/> apply to this document.
      </t>
     <!--
     <t>
     PIM-SM link-local messages can be authenticated using various mechanisms, as described in Section 6.3 <xref target="RFC7761"/>.
     Authentication of BFD Control messages defined in Section 6.7 <xref target="RFC5880"/>. Each protocol may use authentication of its messages
     independently of the mode used by the other protocol.
     </t>
     -->
     <!--
     <t>
     An implementation that supports this specification  SHOULD use a mechanism to
   control the maximum number of BFD sessions that can be active at the
   same time.
     </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.8174.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.5881.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8562.xml"/>
   <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8775.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5883.xml"/>
    </references>
    </references>
    <section title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
         The authors cannot say enough to express their appreciation of the comments and suggestions we that were received from Stig Venaas. <contact fullname="Stig Venaas"/>.
         The authors also greatly appreciate the comments and suggestions by Alvaro Retana <contact fullname="Alvaro Retana"/> that improved the clarity of this document.
      </t>
    </section>

  </middle>

    <back>

    <references title="Normative References">

      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.8174"?>
      <?rfc include="reference.RFC.5880"?>
      <?rfc include="reference.RFC.5881"?>
      <?rfc include="reference.RFC.7761"?>

   <?rfc include="reference.RFC.8562"?>
  <!--
   <?rfc include="reference.I-D.ietf-pim-dr-improvement"?>
-->
   <?rfc include="reference.RFC.8775"?>

    </references>

    <references title="Informative References">

      <?rfc include="reference.RFC.5883"?>
    <!--
   <?rfc include="reference.I-D.mankamana-pim-bdr"?>
   -->

    </references>
  </back>
</rfc>