<?xml version='1.0'?>   
    <!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [ 
        <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> 
        <!ENTITY rfc6395 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6395.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="std" docName="draft-mankamana-pim-graceful-dr-shutdown-00"
     ipr="trust200902">
  <!-- ***** FRONT MATTER ***** -->
  <front>
    <title abbrev="PIM Designated Router graceful shutdown">PIM Designated Router graceful shutdown</title>
    
    <author initials="Mankamana" 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="Stig " surname="Venaas" 
    fullname="Stig Venaas">
      <organization>Cisco Systems</organization>
    
      <address>
       <postal>
         <street>821 Alder Drive,</street>
         
        <region>MILPITAS, CALIFORNIA 95035</region>
        
        <country>UNITED STATES</country>
       </postal>
       
       <phone></phone>
       <email>svenaas@cisco.com</email>
      </address>
    </author>

    <author initials="Mahesh" surname="Sivakumar" 
    fullname="Mahesh Sivakumar">
      <organization>juniper networks</organization>
    
      <address>
       <postal>
         <street>1133 Innovation Way</street>
         
        <region>Sunnyvale, CALIFORNIA 94089</region>
        
        <country>UNITED STATES</country>
       </postal>
       
       <phone></phone>
       <email>sivakumar.mahesh@gmail.com</email>
      </address>
    </author>

    <author initials="Zheng(Sandy)" surname="Zhang" 
    fullname="Zheng(Sandy) Zhang">
      <organization>ZTE Corporation</organization>
    
      <address>
       <postal>
         <street>No. 50 Software Ave, Yuhuatai Distinct</street>
         
        <region>Nanjing</region>
        
        <country>China</country>
       </postal>
       
       <phone></phone>
       <email>zhang.zheng@zte.com.cn</email>
      </address>
    </author>

    <author initials="Mikael" surname="Abrahamsson" 
    fullname="Mikael Abrahamsson">
      <organization></organization>
    
      <address>
       <postal>
         <street></street>
         
        <region></region>
        
        <country></country>
       </postal>
       
       <phone></phone>
       <email>swmike@swm.pp.se</email>
      </address>
    </author>

    <date year="2018"/>    
    <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 case of a network maintenance, where we want to bring down the current DR, 
            there is currently no way to gracefully handover the PIM DR role to a new DR on 
            the shared LAN. In this document, we propose a modification to the PIM-SM 
            protocol that allows PIM DR to gracefully shutdown or go down for maintenance. 
            We also provide a procedure for PIM DR to gracefully handover its 
            role to a new PIM DR in the network.
        </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 represents the LAN segment/broadcast domain 
              in the PIM topology tree and has two roles to play in the PIM-SM protocol. 
              For sources connected to the segment, the PIM DR is responsible for registering 
              one or more active sources with the Rendezvous Point (RP) if the group is 
              operating in PIM-SM.  In addition, on the last hop LAN, the PIM DR is responsible 
              for tracking local multicast listeners and forwarding data traffic 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 members.  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 sources or the
              RPs. 
          </t>
          <t>If R1 needs to go on planned maintenance, the current approach is to 
              lower the DR priority which would make sure that another PIM 
              router on the LAN gets elected as the new DR and starts forwarding multicast traffic.
          </t>
          <t>
              With this approach, R1 gives away DR role as soon as new priority is 
              configured and a new PIM DR (lets assume R3) starts building a 
              multicast tree and starts forwarding multicast traffic on the LAN.
              However, this could cause traffic disruption for the duration it 
              takes for R3 to build the upstream multicast tree.
          </t>
          <t>
              This draft defines a mechanism in the PIM protocol to handover 
              DR role gracefully and as a result minimize traffic disruption.
          </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>With respect to PIM, this document follows the terminology that has
              been defined in <xref target="RFC4601"/> and 
              <xref target="RFC7761"/> .
             Many places this draft would refer to PIM RFC <xref target="RFC4601"/> 
             but it MUST be considered <xref target="RFC7761"/> as well. 
          </t>
      </section>

      <section title="Protocol Specification">
          <t> In this draft, we define a new hello option to enable the graceful 
              handover of a DR during planned maintenance.In <xref target="proposed-mechanism"/>, 
              we describe the proposed mechanism. In <xref target="impact"/>, we evaluate 
              the impact of the mechanism on the network under different conditions. 
              <xref target="DR-Graceful-handoff"/> describes the proposed hello option.
          </t>
          <section anchor="proposed-mechanism" title="Proposed Mechanism">
              <t> 
                      <list style="numbers">
                          <t> In Figure-1, assume that R1 is current PIM DR 
                              that needs to go on planned maintenance. R1 MUST 
                              sends out a PIM Hello with option described in <xref target="DR-Graceful-handoff"/>. 
                              The DR Priority MUST be set to 0. R1 MUST also 
                              set its assert metric to (PIM_ASSERT_INFINITY - 1)
                          </t>
                          <t>The PIM assert metric modification would make 
                              sure that R1 does not become an assert winner 
                          </t>
                          <t> Sending DR priority as 0 would make sure to have default
                              transition in case new DR does not support the new specification
                          </t>
                          <t> The current PIM DR (R1 here) MUST not stop 
                              forwarding traffic to intended receivers 
                              unless it starts getting duplicate flows from 
                              newly elected PIM DR.
                          </t>
                          <t> A failsafe timer SHOULD be used to stop 
                              forwarding multicast traffic towards receiver. 
                              It SHOULD be set to at least two PIM Hello intervals. 
                              But it SHOULD also be a configurable value.</t>
                      </list>
              </t>
          </section>

          <section anchor="impact" title="Impact on the network">
              <t> This section covers impact of PIM hello with <xref target="DR-Graceful-handoff"/>  option </t>
              <section title="Every PIM router supports the new specification on the shared LAN">
                  <t>
                      <list style="numbers">
                          <t> In Figure-1, if each of the PIM routers on 
                              shared LAN supported this specification, 
                              new DR election would be done as per <xref target="RFC4601"/>
                          </t>
                          <t>The newly elected DR MUST start building the 
                              multicast tree towards the source/RP. 
                              It MUST start fail safe timer (default value 
                              2 PIMHello interval) and MUST not generate a 
                              data driven assert.  Once the timer expires, 
                              it can move back to the default assert mechanism. 
                              The reason to avoid an assert is to allow the 
                              old PIM DR on LAN to forward multicast traffic 
                              until such time the new DR is completely ready 
                              to forward  multicast traffic. 
                          </t>
                          <t> It MUST forward multicast flow to receivers as 
                              soon as it gets the multicast flow from the source/RP
                          </t>
                      </list>
                  </t>
              </section>
              <section title="Hybrid shared LAN, some of PIM router does not support specification">
                  <t>There are two cases to consider,</t>
                  <t>
                      <list style="numbers">
                          <t>If the new DR supports this specification, it would follow 
                              <xref target="proposed-mechanism"/> </t>
                          <t>If the new DR does not support this specification, 
                              there is no need for any special handling as the 
                              new DR would take over as it does today. 
                              It would assert as soon as it gets elected as 
                              DR and the old DR would become the assert loser 
                              as it had already adjusted its assert 
                              metric to PIM_ASSERT_INFINITY - 1 </t>
                      </list>
                  </t>
              </section>
          </section>
      </section>


          <section anchor="DR-Graceful-handoff" title="PIM Hello option">
             <figure  align="center">
                 <artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Type = TBD          |         Length                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     Figure 2: Graceful DR handoff  Hello Option

                      ]]></artwork>
                  <postamble></postamble>
              </figure>
           <t> where 
               <list style="empthy">
                   <t> Type  : DR Graceful handoff</t>
                   <t> Length: 2</t>
               </list>

           </t>
          </section>

      <section title="IANA Considerations">
          <t>A new PIM Hello option is TBD..
          </t>
      </section>

      <section title="Security Considerations">
          <t> Security of the new PIM Hello Options is only
              guaranteed by the security of PIM Hello message, so the security
              considerations for PIM Hello messages as described in PIM-SM
              <xref target="RFC4601"/> apply here.
          </t>
      </section>

      <section title="Acknowledgement">
          <t>
          </t>
      </section>
      <section title="Contributors">
          <t>
              In addition to the authors listed on the front page, the following
              co-authors have also contributed to original idea.
          </t>

          <t> Krishna Muddenahally Ananthamurthy</t>
          <t> Cisco Systems </t>

      <t> Sameer Gulrajani</t>
  <t>Cisco systems</t>

            <t>  Rishabh Parekh</t>
          <t>Cisco systems</t>
      </section>

    
    
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>

      <references title='Normative References'>
          &rfc2119;
          &rfc4601;
          &rfc6395;
          &rfc7761;
      </references>
      <references title="Informative References">
          <reference anchor="HELLO-OPT">
              <front>                                                                   
                  <title>PIM Hello Options</title>            
                  <author>                                                                  
                      <organization>                                                            
                          IANA                                                                      
                      </organization>                                                           
                  </author>                                                                 
                  <date month="March" year="2007" />                                     
              </front>                                                                  
              <seriesInfo name="IANA" value="PIM-HELLO-OPTIONS" />
          </reference>

      </references>

  </back>
</rfc>
