<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?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"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902" docName="draft-ietf-rtgwg-vrrp-p2mp-bfd-14" updates="" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.6.0 -->
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<front>
    <title abbrev="Applicability of BFD P2MP in VRRP">Applicability of Bidirectional Forwarding Detection (BFD) for Multi-point Networks in Virtual Router Redundancy Protocol (VRRP)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-rtgwg-vrrp-p2mp-bfd-14"/>
    <author initials="G." surname="Mirsky" fullname="Greg Mirsky">
      <organization>Ericsson</organization>
      <address>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>
    <author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
      <organization>NVIDIA</organization>
      <address>
        <email>jefftant.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Gyan Mishra" initials="G. " surname="Mishra">
      <organization>Verizon Inc.</organization>
      <address>
        <email>gyan.s.mishra@verizon.com</email>
      </address>
    </author>
    
    <area>Routing</area>
    <workgroup>RTGWG</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>VRRP</keyword>
    <keyword>BFD </keyword>
    <abstract>
      <t>
This document specifies the applicability of Bidirectional Forwarding Detection in multipoint networks
to support sub-second failure detection for Virtual Router Redundancy Protocol Router Role election.
The mechanism enables faster determination of the Active Router without requiring any modification to the protocol behavior or message formats defined in RFC 9568.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
 The <xref target="RFC9568"/> is the current Virtual Router Redundancy Protocol (VRRP) specification for IPv4 and IPv6 networks.
 VRRPv3 allows for a faster switchover to a Backup Router. A router may be part of several
 Virtual Router Redundancy groups, such as Active in some and Backup in others.
Supporting sub-second mode for VRRPv3 <xref target="RFC9568"/> for all these roles without specialized support
in the data plane may prove challenging because of the increased load on the control plane.
However, it may still be possible to deploy VRRP and provide sub-second detection of Active Router failure by Backup Routers.
      </t>
      <t>
 Bidirectional Forwarding Detection (BFD) <xref target="RFC5880"/> had been originally defined to detect
 failure of point-to-point paths: single-hop <xref target="RFC5881"/>, multihop <xref target="RFC5883"/>.
Single-hop BFD may enable a Backup router to detect a failure of the Active router within sub-seconds.
      </t>
      <t>
 <xref target="RFC8562" format="default"/> extends <xref target="RFC5880" format="default"/> for multipoint and multicast
 networks, which matches the deployment scenarios for VRRP over the LAN segment. This document
 demonstrates how point-to-multipoint (p2mp) BFD can enable faster detection of the Active Router failure and 
 thus minimize service disruption in a VRRP domain.
      </t>

      <section numbered="true" toc="default">
        <name>Conventions used in this document</name>
        <section numbered="true" toc="default">
          <name>Terminology</name>
          <t>BFD:          Bidirectional Forwarding Detection</t>
          <t>p2mp:         Pont-to-Multipoint</t>
          <t>VRRP:        Virtual Router Redundancy Protocol</t>
        </section>
        <section 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", and "OPTIONAL" in this document are to be interpreted as
   described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/>
   when, and only when, they appear in all capitals, as shown here.
          </t>
        </section>
      </section>
    </section>

    <section anchor="apply-p2mp-bfd" numbered="true" toc="default">
      <name>Applicability of p2mp BFD</name>
      <t>
 <xref target="RFC8562" format="default"/> may provide an efficient and scalable solution for a fast-converging
 environment that uses the default route rather than dynamic routing. Each redundancy group presents itself as a p2mp BFD
 session, with its Active Router being the head and Backup Routers being the tails of the p2mp BFD session.
      </t>

      <t>
 The Active Router, configured to use p2mp BFD to support faster convergence of VRRP,
 starts transmitting BFD control packets with IPvX address associated
 with the Virtual Router <xref target="RFC9568"/> as a source IP address
 and the value of the My Discriminator field (<xref target="RFC5880"/>) locally selected according to the following rules:
 </t>
 <ul empty="true" spacing="normal">
<li>For IPv4, the Active Router uses 32 bits of the IPv4 source address as described in Section 5.1.1.1 of <xref target="RFC9568"/>.</li>
<li>For IPv6, the Active Router uses the 32 least-significant bits of IPv6 source address, as described in Section 5.1.2.1 of <xref target="RFC9568"/>.</li>
</ul>
 <t>
A Backup Router demultiplexes
 p2mp BFD test sessions based on IPvX address associated with the Virtual Router that it has been configured with
 and the non-zero My Discriminator value, it deduces from the received VRRP Advertisement packet
 according to the rules listed above. When a Backup
 router detects the failure of the Active Router, according to Section 5.11 <xref target="RFC8562"/>,
 it re-evaluates its role in the Virtual Router. As a result, the Backup Router may become the Active
router of the given Virtual Router or continue as a Backup Router.
</t>
<ul empty="true" spacing="normal">
<li>
 If the former is the case, then the new Active
router will start transmitting p2mp BFD control packets using the Active Router IP address as the source IP address for p2mp BFD control packets
and thus bootstraps a new p2mp BFD session on a Backup Router.
</li>
<li>
 If the latter is the case, the
 Backup Router MUST close and remove the p2mp BFD session associated with the failed Active Router.
 The VRRP Advertisement packet from the new VRRP Active Router will bootstrap the new p2mp BFD session.
 </li>
</ul>
      
      <section anchor="p2mp-bfd-encap" numbered="true" toc="default">
        <name>Multipoint BFD Encapsulation</name>
        <t>
The MultipointHead of p2mp BFD session when transmitting BFD control packet:
</t>
        <ul empty="true" spacing="normal">
        <li>Set the source MAC address according to rules in Section 7.3 of <xref target="RFC9568"/>;</li>
          <li>MUST set TTL or Hop Limit value to 255 (Section 5 <xref target="RFC5881"/>).
      Similarly, all received BFD Control packets that are demultiplexed
      to the session MUST be discarded if the received TTL or Hop Limit
      is not equal to 255;</li>
          <li>SHOULD use group address VRRP ('224.0.0.18' for IPv4 and 'FF02:0:0:0:0:0:0:12' for IPv6) as destination IP address;</li>
          <li>MAY use network broadcast address for IPv4 or link-local all nodes multicast group for IPv6 as destination IP address;</li>
          <li>MUST set destination UDP port value to 3784 when transmitting BFD control packets, as defined in <xref target="RFC8562"/>;</li>
          <li>Source UDP port value selection follows the rules defined in Section 4 of <xref target="RFC5881"/>;</li>
          <li>MUST use the Active Router IP address as the source IP address.</li>
        </ul>
      </section>
    </section>
    <section anchor="iana-consider" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
This document makes no requests for IANA allocations. This section may be deleted by RFC Editor.
      </t>
    </section>
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
         This document defines an alternative way, to the one defined in <xref target="RFC9568"/>, to accelerate detecting a failure that
   affects VRRP functionality using p2mp BFD.  The operation of either protocol is not changed.
</t>
      <t>
 Security considerations discussed in <xref target="RFC9568"/>, <xref target="RFC5880"/>, <xref target="RFC5881"/>,
 and <xref target="RFC8562"/>, apply to this document. 
      </t>
    </section>
    <section numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>
      The authors appreciate comments and suggestions shared by Acee Lindem and Alexander "Sasha" Vainshtein that helped simplify the solution.
      </t>
    </section>
  </middle>
  <back>
    <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.5883.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9568.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8562.xml"/>
    </references>

 </back>
</rfc>
