<?xml version="1.0" encoding="UTF-8"?>
<rfc category="std" ipr="trust200902" docName="draft-gopal-pim-pfm-forwarding-enhancements-01">
	<?rfc toc="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<?rfc symrefs="yes"?>
	<front>
		<title abbrev="PIM Flooding Mechanism Enhancements">PIM Flooding Mechanism Enhancements</title>
		<author initials="A." surname="Gopal" fullname="Ananya Gopal">
			<organization>Cisco Systems, Inc.</organization>
			<address>
				<postal>
					<street>Tasman Drive</street>
					<city>San Jose</city>
					<code>CA 95134</code>
					<country>USA</country>
				</postal>
				<email>ananygop@cisco.com</email>
			</address>
		</author>
		<author initials="S." surname="Venaas" fullname="Stig Venaas">
			<organization>Cisco Systems, Inc.</organization>
			<address>
				<postal>
					<street>Tasman Drive</street>
					<city>San Jose</city>
					<code>CA 95134</code>
					<country>USA</country>
				</postal>
				<email>svenaas@cisco.com</email>
			</address>
		</author>
		<date />
		<area>Routing</area>
		<keyword>Multicast</keyword>
		<abstract>
			<t>PIM Flooding Mechanism is a generic PIM message exchange mechanism that allows multicast information to be exchanged between PIM routers hop-by-hop. One example is PIM Flooding Mechanism and Source Discovery which allows Last Hop Routers to learn about new sources using PFM messages, without the need of initial data registers, RPs or shared trees.</t> 
			<t>This document defines a methodology that enhances forwarding efficiency in PFM deployments. This enhancement can avoid extra processing at PIM routers when PFM messages are forwarded.</t>
		</abstract>
	</front>
	<middle>
        
		<section title="Introduction">
            
        <t>
		PIM Flooding Mechanism <xref target="RFC8364"/> allows a PIM router in the network to originate a PFM message to distribute multicast information to its PIM neighbors <xref target="RFC7761"/> . All PIM neighbors then process this PFM message and flood it further on their PIM-enabled links.  To prevent loops, the originator address as defined in Section 3.1 <xref target="RFC8364"/> is used for RPF checking at each router. This RPF check is defined in Section 3.4.1 <xref target="RFC8364"/>. Periodic PFM messages are triggered, see Section 3.4.2 <xref target="RFC8364"/> and exchanged to keep the multicast information updated across the PIM domain.
            
        At present, a PIM router will flood a PFM message on all its PIM enabled links. It is the recipient's responsibility to perform RPF checks on all received PFM messages and then decide whether to accept or drop a particular message. This means that if two routers have PIM neighborships over more than one link, the same PFM messages are exchanged or dropped over more than one link between the same two routers. This leads to extra processing at each PIM router, periodically, or every time a new source is discovered (in case of a PFM-SD implementation). 
            
        This document defines a mechanism to exchange PFM messages only on one ONE link per router-pair, even though they may maintain PIM neighborships over multiple links. 
   
        In other words, when there are multiple links between two PIM routers, routers should not send the same message on all the links between them. This is achieved by identifying the PIM routers in the network using Router Identifier that are announced via PIM hellos, as per RFC 6395.
        </t>    
            
		 <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="Terminology">
				<t>
					<list style="hanging">
						<t hangText="RP:">Rendezvous Point</t>
						<t hangText="RPF:">Reverse Path Forwarding</t>
                        <t hangText="PFM:">PIM Flooding Mechanism</t>
					</list>
				</t>
			</section>
		</section>

        <section title="Methodology">
        <section title="RFC 6395 Compliance">
        <t>
            For the PFM enhancement specified in this document to be adopted, all PIM routers MUST be compliant with RFC <xref target="RFC6395"/>. This means that PIM routers announce a unique domain-wide router ID in their PIM Hellos. A PIM router announces the same 4-byte Router-ID in PIM Hellos that it sends to all neighbors on all links. It also caches of the Router-Ids of its neighbors, when it receives Hellos from RFC 6395 Compliant PIM neighbors.            
            
            This can be used to determine that different PIM neighbors are really the same router. In a VRF context, if the router has multiple interfaces with only one neighbor per interface, the router SHOULD check if those neighbors announce an RFC 6395 router ID. If the router can see the same router ID for multiple neighbors, PFM message exchange is optimized, as discussed in Section 2.
            
        </t>
        </section> 
            
            <section title="PFM optimization Hello option">
        <t>
            A PIM router indicates that it supports the mechanism specified in this document by including the new PFM optimization Hello option. When this optimization is included in the PIM hello, the router MUST also include the router-ID Hello Option defined in <xref target="RFC6395"/> with a non-zero router-ID.
        </t>
      
            <figure> <artwork>
            
                
       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 = 0        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 1: PFM optimization Hello option

                </artwork>
             </figure> 
                
            <list style='hanging'>
	               <t hangText='OptionType = TBD'>
                   </t>
                  <t hangText='OptionLength = 0'>
                   </t> 
            </list>    
        <t>
        Note that there is no option value included.  
        When a PIM hello with OptionType TBD is received from a PIM neighbor, the router MUST cache this information so that it can make forwarding and dropping decisions for PFM messages for that neighbor. When this option is included, the router MUST also cache the non-zero router-ID of this neighbor. 
            
        </t>
        </section>  
            
        <section title="PFM message sending">

            <t> Consider a topology where two PIM routers maintain PIM neighborships over more than one links in the same PIM domain.
                 From each router's point of view, there is a single neighbor on each link. Traditionally, each of the routers will send out PFM messages out over all the links to its neighbor. RPF checks are one of the commonly used ways to prevents loops, hence the recipient router performs an RPF check and accepts only on one link, thereby dropping packets from all the others. Since, the sender does not know which link will be chosen as the RPF-source on the neighbor, it cannot make the decision of choosing one of the links, without knowing its neighbor's decision.
                
            </t>
            <t>    
            If the optimization specified in this document is advertised by both routers, the sender should choose one of the links and send and forward PFM messages to its neighbor using only that link. It is imperative that the sender does this only when the receiver is capable of the optimization and is advertising the same. Otherwise, the messages may be dropped because of RPF failures. Mechanism to choose a link is left to the implementation. 
            </t>
            </section>
            
        <section title="PFM message receiving and RPF check relaxation">
                  <t> 
           Consider a router that is advertising its capability to optimize PFM exchanges in the network. Upon receiving a PFM message, this router MUST first check whether this message is sent by a PFM optimization enabled router. If the check returns true, the receiver should relax its RPF check and accept the message.  When a PFM message is received, the receiver SHOULD keep track of the router ID of the sender, so that the receiver does not forward the message back to the sender on any other link, as explained in the next section.
                      
            If it receives this message from a router that is not advertising the PFM optimization specified in this document, however the optimization is enabled on the receiver, the receiver SHOULD NOT relax its RPF check. This is because the sender will be still sending out messages on all the links between them.
        
            </t>
        
        </section>
        
         <section title="PFM message forwarding">
            
        <t> 
           Traditionally, a PIM router forwards a PFM message on all its PIM enabled links. However, this is now optimized. Consider a router that is advertising its capability to optimize PFM exchanges in the network. When this router receives a PFM message from a router that also has the PFM optimization enabled, the forwarding mechanism is as follows. The receiver MUST NOT send the PFM message on out on any links where there is only one neighbor and the neighbor has the same router ID as the sender.
            </t>
		</section>
            
        </section>
         <section title="Operational Considerations">
               <list style='hanging'>
             <t hangText='Existing neighbor on a new link:' > 
           When a new neighbor is detected announcing support for the optimization and announcing a non-zero router ID, and it is the only neighbor on the link, a PIM router needs to check if there is an existing neighbor on another link with the same router ID (it does not need to be the sole neighbor on the other link). A mechanism SHOULD be implemented to prevent 
                 PFM messages being sent on this link.  </t>
                
             <t hangText='New neighbor on a new link:' > 
                 Appropriate logic SHOULD be implemented to handle new neighbor additions so that extra messages are not forwarded to same neighbor, as well as ensuring that a new neighbor quickly gets the correct state. </t>
                
               <t hangText='Removal of a neighbor:' > 
             Appropriate logic SHOULD also be implemented to handle neighbor removals.
                
              </t>
              
             </list>
		</section>       
        
		<section title="Acknowledgments">
		</section>
	</middle>
    
	<back>
		<references title="Normative References">
 			<?rfc include='reference.RFC.2119' ?>
            <?rfc include='reference.RFC.8174' ?> 
             <?rfc include='reference.RFC.7761' ?>
            <?rfc include='reference.RFC.8364' ?>
            <?rfc include='reference.RFC.6395' ?>
		</references>
	</back>
</rfc>