<?xml version='1.0'?>   
    <!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [ 
        <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> 
        <!ENTITY rfc4601 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4601.xml'> 
        <!ENTITY rfc7761 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7761.xml'> 
        ]>
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="yes" ?>
<rfc category="info" docName="draft-ietf-pim-bdr-02" updates="" ipr="trust200902">
  <!-- ***** FRONT MATTER ***** -->
  <front>
    <title abbrev="PIM Backup Designated Router">PIM Backup Designated Router Procedure </title>
    
    <author initials="M" surname="Mishra" 
        fullname="Mankamana Mishra"> 
    <organization>Cisco Systems</organization>
	  <address>
		   <postal>
			 <street>821 Alder Drive,</street>

			<region>MILPITAS, CALIFORNIA 95035</region>

			<country>UNITED STATES</country>
		   </postal>

		   <phone></phone>
		   <email>mankamis@cisco.com</email>
		  </address>
    </author>
    <author initials="A" surname="Budhiraja" 
        fullname="Anuj Budhiraja"> 
    <organization>Cisco Systems</organization>
	  <address>
		   <postal>
			 <street>821 Alder Drive,</street>

			<region>MILPITAS, CALIFORNIA 95035</region>

			<country>UNITED STATES</country>
		   </postal>

		   <phone></phone>
		   <email>abudhira@cisco.com</email>
		  </address>
    </author>
    <author initials="A" surname="Paramasivam" 
        fullname="Aravind Paramasivam"> 
    <organization>Cisco Systems</organization>
	  <address>
		   <postal>
			 <street>821 Alder Drive,</street>

			<region>MILPITAS, CALIFORNIA 95035</region>

			<country>UNITED STATES</country>
		   </postal>

		   <phone></phone>
		   <email>arparama@cisco.com</email>
		  </address>
    </author>
    <author initials="I" surname="Romdhani" 
        fullname="Dr Imed Romdhani"> 
    <organization>Edinburgh Napier University</organization>
	  <address>
		   <postal>
			 <street></street>

			<region></region>
			<country>UK</country>
		   </postal>

		   <phone></phone>
		   <email>I.Romdhani@napier.ac.uk</email>
		  </address>
    </author>
    <author initials="G" surname="Mishra" 
        fullname="Gyan S. Mishra"> 
    <organization>Verizon Communications Inc. (VZ)</organization>
	  <address>
		   <postal>
			 <street>13101 Columbia Pike FDC1 Rm 304-D</street>

			<region>Silver Spring MD 20904</region>

			<country>UNITED STATES</country>
		   </postal>

		   <phone></phone>
		   <email>gyan.s.mishra@verizon.com</email>
		  </address>
    </author>

    <date year="2024"/>    
    <area>Routing</area>
    <workgroup>Network Working Group</workgroup>
    <abstract>
        <t>On a multi-access network, one of the PIM routers is elected as a
            Designated Router (DR).  On the last hop LAN, the PIM DR is
            responsible for tracking local multicast listeners and forwarding
            traffic to these listeners if the group is operating in PIM-SM.  
            In this document, we propose a mechanism to elect backup DR on a shared 
            LAN. A backup DR on LAN would be useful for faster convergence. 
            This draft introduces the concept of a Backup Designated Router (BDR) and 
            the procedure to implement it. 
        </t>
    </abstract>
  </front>

  <!-- ***** MIDDLE MATTER ***** -->

  <middle>
      <section title="Introduction">
          <t>On a multi-access LAN such as an Ethernet, one of the PIM routers
              is elected as a DR.  The PIM DR has two roles in the PIM-SM protocol.
              On the first hop network, the PIM DR is responsible for registering
              an active source with the Rendezvous Point (RP) if the group is
              operating in PIM-SM.  On the last hop LAN, the PIM DR is
              responsible for tracking local multicast listeners and forwarding to
              these listeners if the group is operating in PIM-SM.
          </t> 

          <t>Consider the following last hop LAN in Figure 1: 
          </t>
          <figure  >
            <preamble/>
              <artwork ><![CDATA[            
                         ( core networks )
                           |     |     |
                           |     |     |
                          R1    R2     R3
                           |     |     |
                        --(last hop LAN)--
                                 |
                                 |
                         (many receivers)

                    Figure 1: Last Hop LAN
                  ]]></artwork>
              <postamble></postamble>
          </figure>     

          <t>   Assume R1 is elected as the Designated Router.  According to
              <xref target="RFC4601"/>, R1 will be responsible for forwarding traffic to that LAN
              on behalf of any local member. In addition to keeping track of IGMP
              and MLD membership reports, R1 is also responsible for initiating the
              creation of source and/or shared trees towards the senders or the
              RPs. 
          </t>
          <t>
              There are multiple reasons for why network could potentially trigger 
              DR re-election. Some of the reasons are 
              <list style="numbers">
                  <t> R1 going down </t>
                  <t> Access interface towards shared LAN going down </t>
                  <t> Config changed with lower DR priority </t>
              </list>
          </t>
          <t> When any of above network event occurs, PIM DR re-election would be 
              triggered. When a new DR is elected in shared LAN, new DR would be responsible 
              to build a multicast tree towards source / RP. There are some cases, where 
              traffic is crucial and the operator wants to have minimum traffic loss with DR 
              failure. 
              To address this requirement, this draft introduces a backup DR election procedure 
              which would minimize traffic loss during PIM DR failure. 
         </t>

      </section>     

      <section title="Terminology">
          <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
              "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
              document are to be interpreted as described in <xref target="RFC2119"/>  .
          </t>
          <t> BDR - PIM Backup DR 
          </t>
          <t>With respect to PIM, this document follows the terminology that has
              been defined in <xref target="RFC4601"/> .
          </t>
      </section>

      <section title="Applicability and deviation from draft PIM DR Improvement">
          <t> <xref target="I-D.ietf-pim-dr-improvement"/> defines procedure to solve 
              same problem which was stated in the introduction  section of this draft. 
              <xref target="I-D.ietf-pim-dr-improvement"/> introduces new PIM Hello 
              options for election of backup PIM DR. 
          </t>
          <t> This draft provides mechanism to elect BDR without using any new PIM Hello.
         </t>
      </section>

      <section title="Protocol Specification">
          <section title="PIM Backup DR (BDR) election procedure">
              <t> <xref target="RFC7761"/> defines procedure for PIM DR election. PIM 
                      DR is elected on interface "I"  among all PIM routers for which "I" has 
                      received PIM Hello. BDR election follows the exact same procedure and the 
                      second best PIM DR on shared LAN to be chosen as BDR on interface "I"
             </t>
             <t> BDR would perform each of the responsibility of PIM DR except it would not 
                 forward traffic on shared LAN. 
             </t>

          </section>
          <section title="Existing PIM DR failure">
              <t> When PIM DR fails, PIM DR re-election is triggered on shared LAN. Since BDR is 
                  second best DR in LAN, it MUST take over immediately and MUST start forwarding 
                  multicast traffic on shared LAN. 
              </t>
              <t> Again on a shared LAN, new BDR would be elected. and current BDR would be the new DR. 
              </t>
          </section>
          <section title="Existing PIM BDR failure">
              <t> When an existing PIM BDR fails, the shared LAN MUST have BDR re-election using the DR election 
                  procedure from <xref target="RFC7761"/>.
              </t>
          </section>
          <section title="New PIM Router addition in network">
              <t> When a new PIM router is added in shared LAN, It could be either one of the below defined 
                  roles.
              </t>
              <section title="New PIM router eligible to be PIM DR on shared LAN">
                  <t> When a new PIM router is added in a shared LAN and has the highest PIM DR priority 
                      configured, if a new router starts propagating its configured DR priority right 
                      away, the existing PIM DR would give up its role. Then there would be potential traffic 
                      loss till the new DR learns about membership states and builds a multicast tree to the source 
                      or RP.
                  </t>
                  <t> To avoid any such traffic loss situation, new PIM router SHOULD send a PIM Hello with 
                      priority 0. After 2 (default value, SHOULD have way to configure) PIM Hello interval or IGMP Query Interval (Which ever is higher) it 
                      SHOULD start propagating its original configured DR priority.
                  </t>
                  <t> Even though a new PIM router propagating its priority as 0, it MUST start building a multicast 
                      tree towards source / RP, This is So that traffic loss could be minimized once it starts sending 
                      Hello with configured DR priority.
                  </t>
                  <t> For a brief amount of time, there would be multiple copies of flows present in the multicast 
                      core, but a user SHOULD be able to configure whether to send hello with 0 priority or 
                      a configured priority. Depending on the application tolerance (Traffic loss Vs Extra traffic in 
                      core) the operator can choose option whichever is suitable for network.
                  </t>
                  <t> After a PIM Hello or IGMP Query interval, the network would get stable with only one DR and 
                      one BDR.
                  </t>
              </section>
              <section title="New PIM router eligible to be PIM BDR on shared LAN">
                  <t> It SHOULD follow the exact same procedure defined in the previous section. 
                 </t>
              </section>
              <section title="New PIM router is not eligible to be PIM DR or BDR on shared LAN">
                  <t> First a PIM Hello MUST be sent with priority 0. Once it has gotten Hello from other PIM 
                      neighbors, it knows that it is not eligible to be PIM DR or BDR. It MUST send configured 
                      PIM DR priority immediately. It MUST not wait for next hello interval.
                  </t>
              </section>
          </section>

          <section title="Initial case, All new PIM router coming up in shared LAN">
              <t> In this case, initially each of the PIM routers would send Hellos with priorities of 0. If a PIM 
                  router receives all Hellos with priorities 0, it MUST send out a Hello with a configured PIM 
                  DR priority. Since it is initial startup case, it would take up to one Hello interval 
                  to converge. 
              </t>
          </section>
          <section title="Benefit">
              <t>
              <list style="numbers">
                  <t> Easy to implement as it uses an existing PIM procedure to elect DR.</t>
                  <t> Does not introduce any new Hello option</t>
              </list>
             </t>
          </section>

      </section>

      <section title="Compatibility">
      </section>
      <section title="Manageability Considerations">
      </section>
      <section title="IANA Considerations">
          <t> 
          </t>
      </section>

      <section title="Security Considerations">
          <t> 
          </t>
      </section>

      <section title="Acknowledgement">
          <t> The author would like to thank Stig Venaas, Tharak Abraham, Anish Kachinthaya, 
              Anvitha Kachinthaya for helping with original idea.
          </t>
      </section>

    
    
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>

      <references title='Normative References'>
          <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pim-dr-improvement-04.xml"?>
          &rfc2119;
          &rfc4601;
          &rfc7761;
      </references>

  </back>
</rfc>
