<?xml version="1.0" encoding="UTF-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902" docName="draft-mankamana-pim-pim-sticky-dr-00">
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>

	<front>
		<title abbrev="Sticky PIM DR">Sticky PIM DR</title>

        <author initials="M." surname="Mishra" fullname="Mankamana Mishra">
			<organization>Cisco Systems</organization>
			<address>
				<postal>
					<street>Tasman Drive</street>
					<city>San Jose</city>
					<code>CA 95134</code>
					<country>USA</country>
				</postal>
				<email>mankamis@cisco.com</email>
			</address>
		</author>
        
		<author initials="A." surname="Budhiraja" fullname="Anuj Budhiraja">
			<organization>Cisco Systems</organization>
			<address>
				<postal>
					<street>Tasman Drive</street>
					<city>San Jose</city>
					<code>CA 95134</code>
					<country>USA</country>
				</postal>
				<email>abudhira@cisco.com</email>
			</address>
		</author>
		
		<author initials="H." surname="Bidgoli" fullname="Hooman Bidgoli">
			<organization>Nokia</organization>
			<address>
				<postal>
					<street>March Road</street>
					<city>Ottawa Ontario </city>
					<code>K2K 2T6</code>
					<country>Canada</country>
				</postal>
				<email>hooman.bidgoli@nokia.com</email>
			</address>
		</author>
        
		<date />
		<area>Routing</area>
		<keyword>Multicast</keyword>
		<abstract>
			<t>This draft proposes a mechanism to enhance the stability of Protocol Independent Multicast (PIM) Designated Router (DR) election by introducing the concept of a Sticky DR. In traditional PIM operations, the DR role on a LAN may change dynamically in response to router availability or priority changes, leading to potential multicast service disruptions or state reinitialization. The Sticky PIM DR approach aims to retain the previous DR role whenever feasible. By minimizing DR churn, this mechanism improves multicast session continuity, reduces unnecessary Join/Prune message propagation, and enhances operational stability in dense multicast deployments. The draft outlines the procedural extensions to existing PIM DR election, compatibility considerations, and configuration guidelines to support backward interoperability. </t>   
		</abstract>
	</front>
	<middle>
        
    <section title="Introduction">
	    
	    <t>
		    In Protocol Independent Multicast (PIM) <xref target="RFC7761"/> , the Designated Router (DR) on a multi-access network plays a critical role in initiating PIM Join/Prune messages for multicast group membership and acting as a liaison for local receivers. The DR is elected based on the highest IP address or configured priority among routers on the subnet. However, this election is inherently dynamic and can result in frequent DR changes due to config change or new higher priority router joining the shared LAN.
</t> <t>
Several operational deployments, including those in enterprise and service provider networks, have observed that frequent DR changes can lead to undesirable multicast behavior, including temporary multicast traffic loss, source registration issues (in PIM-SM), and unnecessary Join/Prune state transitions. These disruptions are particularly impactful in high-availability environments, such as IPTV, financial trading platforms, or real-time sensor networks.
</t> 
<t>

This document proposes a s procedure for Sticky PIM DR behavior to  introduces minimal extensions to the existing PIM DR election logic, is backward-compatible with existing routers, and preserves PIM’s core operational principles while improving robustness in the face of control-plane volatility.
</t>

    </section> <!--end of introduction-->
    
    
 		 <section numbered="true" toc="include" removeInRFC="false">
            <name>Conventions Used in This Document</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 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
                when, and only when, they appear in all capitals, as shown here.
            </t>
        </section>
        
        
        
     <section  title="Control plane operations">

           <section title="Initial PIM DR election">
                <t> Let us consider a scenario with three PIM routers operating on a shared LAN segment. The routers are identified as Router 1, Router 2, and Router 3, with the following IP addresses and configured PIM priorities:
	             <list style='hanging'>
		            <t hangText='Router 1: '>
			            IP address = 10.1.1.1, PIM Priority = 100
			            </t>  
		            <t hangText='Router 2: '>
			            IP address = 20.1.1.1, PIM Priority = 200
			            </t>  
		            <t hangText='Router 3: '>
			            IP address = 30.1.1.1, PIM Priority = 300
			            </t>  			             
			             </list> 
	                 </t>
                <t>
                  <figure>
                <artwork>

              +-----+      +-----+      +-----+   
              |     |      |     |      |     |   
              +  1  +      +  2  +      +  3  +
              |     |      |     |      |     |
              +--+--+      +--+--+      +--+--+
                 |            |            |
                 |            |            |
        ---------+------------+------------+---------

                </artwork>
                  </figure>
                </t>
                <t>
	                These routers participate in the standard PIM DR election process as defined in <xref target="RFC7761"/>, where the router with the highest PIM priority is elected as the Designated Router (DR). In the event of a tie in priority, the router with the highest IP address is selected. With the procedure defined in <xref target="RFC7761"/> Router 3 becomes PIM DR. 
	                </t>

        </section>
        
        <section title="Sticky PIM DR Procedures">
	                        <t>
	Once the initial PIM DR election has been completed and the network is provisioned to support Sticky PIM DR behavior, the elected DR is permitted to advertise an updated, elevated DR priority value to its neighbors in order to retain its role across reboots or transient link failures.
	
         </t>
                <t>
Specifically, the DR will begin advertising a priority value of (MAX_PIM_DR - 1), where MAX_PIM_DR is defined as 0xFFFFFFFF. This mechanism ensures that the current DR maintains its role, even in the presence of routers that may later join the LAN with a higher configured priority.
         </t>
                <t>

For example, assume Router 3 becomes the DR through the standard election process. Upon activation of Sticky PIM DR behavior, Router 3 MUST begin advertising its PIM DR priority as (0xFFFFFFFF - 1). As a result, even if a new router (e.g., with configured priority 400) subsequently joins the LAN, no DR re-election will be triggered, since Router 3 now advertises a higher effective priority.
         </t>
                <t>

This behavior allows the DR role to be "sticky" to the original elected router, providing stability and avoiding unnecessary multicast state churn during topology changes or restarts.

                </t>

	        
	     </section> 
	     
	     	    <section title="Overriding PIM DR with Sticky DR">
		     	    	                        <t>
In networks that support the concept of a Backup PIM Designated Router (Backup DR), this specification allows for enhanced coordination by assigning a specific priority value to the Backup DR role. In such cases, the router elected as the Backup DR MUST advertise a PIM DR Priority of MAX_PIM_DR - 2 (i.e., one value lower than the Sticky DR Priority of MAX_PIM_DR - 1).
</t>
     	    	                        <t>
The election of the Backup DR follows the standard PIM DR election rules as defined in [RFC7761], and all other operational procedures remain unchanged. The use of this distinct priority value allows other routers on the LAN to recognize the Backup DR without affecting the active DR selection process.
</t>
     	    	                        <t>
This approach ensures a predictable and deterministic Backup DR assignment, while maintaining compatibility with both traditional PIM routers and the sticky DR mechanism introduced in this document.	     	    	                        

</t>

	     </section> 

	     
	    <section title="Overriding PIM DR with Sticky DR">
	                        <t>
		                       There may be operational scenarios where the network operator requires the ability to override the Sticky PIM DR behavior and trigger a DR re-election. This need can arise due to a variety of reasons, such as the existing DR becoming non-operational, requiring a planned maintenance window, or necessitating network upgrades that involve role reassignment.
                </t>
                <t>
	                To support such scenarios, this document defines a configurable mechanism that allows the operator to force a DR change even when Sticky PIM DR is enabled. A new router can be configured with a user-defined PIM DR priority, along with an optional setting to trigger DR re-election. When this option is enabled, the router will temporarily advertise a PIM DR priority equal to MAX_PIM_DR (0xFFFFFFFF) to initiate the re-election process. Upon receiving this advertisement, the currently active Sticky DR MUST relinquish its DR role and release its acquired Sticky DR priority of (MAX_PIM_DR - 1).
	                    </t>
                <t>

Once the existing DR steps down, the initiating router will revert to advertising its originally configured PIM DR priority. The standard PIM DR election procedure is then executed among all routers on the LAN. After election completion, the newly elected DR regardless of which router wins will resume the Sticky DR behavior by advertising a priority of (MAX_PIM_DR - 1).
	                </t>
	        
	     </section> 
	     
	       
    </section>  <!--end of enhancement 1 -->    
    
    <section title="Interoperability with Legacy PIM Routers">
	    <t>
		    This specification has been designed to ensure backward compatibility with existing PIM implementations that do not support Sticky DR behavior. In scenarios where some routers on the LAN are traditional PIM routers compliant with [RFC7761] and do not implement the extensions defined in this document, the behavior of the network remains consistent and predictable.
		    </t>
 <t>
	 If a new router that supports this specification and is eligible to become the DR (based on configured priority) joins the LAN, it will begin advertising the elevated DR priority value as defined by this draft (i.e., MAX_PIM_DR - 1), following the Sticky DR procedure. Traditional routers, which honor DR priority per [RFC7761], will accept the advertised value and defer DR election accordingly. Thus, no disruption occurs in the election process, and interoperability is preserved.
	 
	 </t>
	 
 <t>
	 Conversely, if a traditional PIM router that does not support this specification becomes the DR, it will operate based on standard [RFC7761] behavior and will not advertise any Sticky DR priority. In this case, the sticky mechanism is effectively bypassed, but the DR election and forwarding functionality continue to work as expected, without violating protocol behavior.
	 
	 </t>
	 
	  <t>
Additionally, if a legacy router is manually configured with a reserved DR priority value (e.g., MAX_PIM_DR or (MAX_PIM_DR - 1)), the election process will naturally fall back to the default PIM DR election rules, using priority and IP address as defined in [RFC7761]. The Sticky DR behavior will not take effect unless explicitly supported by the router.
	 
	 </t>
	  <t>
To assist with operational visibility, routers that implement this specification SHOULD log a warning if a reserved DR priority value is detected in the network from a device which never originated any other DR priority. This provides the operator with the opportunity to detect and correct any misconfiguration or unsupported behavior proactively.  
	 
	 </t>
            
     </section>
   
        
    <section title="Security Considerations">
            <t>
              When it comes to general PIM message security, see
              <xref target='RFC7761'/>.
            </t>
            <t>This document does not introduce any new security consideration on top of what has been already covered by <xref target='RFC7761'/>.
            </t>
    </section> <!--end of security-cons --> 
        

    <section title="IANA Considerations">
    <t>
      This document requires the assignment of a  DR priority value as below. 
             <list style='hanging'>
		            <t hangText='MAX_PIM_DR: '>
			            0xFFFFFFFF
			            </t>  
		            <t hangText='Sticky PIM DR Priority: '>
			            0xFFFFFFFF - 1
			            </t>  
		            <t hangText='Sticky PIM Backup DR Priority: '>
			            0xFFFFFFFF - 2
			            </t>  			             
			             </list> 
      

        </t>
        

  </section> <!--end of IANA-cons --> 
        
        
     <section title="Acknowledgments">
	     <t> The authors would like to thank Joya Neema for her valuable discussions and insightful comments that contributed to the development of this document.
		     </t>
		</section>
	</middle>
    
	<back>
        <references>
		<name>Normative References</name>
                <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
		</references>
	</back>
</rfc>