<?xml version="1.0" encoding="US-ASCII"?> encoding="utf-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-pim-light-11" ipr="trust200902"> number="9739" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="PIM Light">Protocol Independent Multicast Light (PIM
    Light)</title> Light)
    </title>
    <seriesInfo name="RFC" value="9739"/>
    <author fullname="Hooman Bidgoli" initials="H" role="editor" surname="Bidgoli">
      <organization>Nokia</organization>
      <address>
        <postal>
          <street>March Road</street>
          <city>Ottawa</city>
          <region>Ontario</region>
          <code>K2K 2T6</code>
          <country>Canada</country>
        </postal>

        <phone/>
        <email>hooman.bidgoli@nokia.com</email>
      </address>
    </author>
    <author fullname="Stig Venaas" initials="S." surname="Venaas">
      <organization>Cisco System, Systems, Inc.</organization>
      <address>
        <postal>
          <street>Tasman Drive</street>
          <city>San Jose</city>

          <region>California</region>
          <region>CA</region>
          <code>95134</code>
          <country>United States of America</country>
        </postal>
        <phone/>
        <email>stig@cisco.com</email>

        <uri/>
      </address>
    </author>
    <author fullname="Mankamana Mishra" initials="M." surname="Mishra">
      <organization>Cisco System</organization> Systems, Inc.</organization>
      <address>
        <postal>
          <street>Tasman Drive</street>
          <city>San Jose</city>

          <region>California</region>
          <region>CA</region>
          <code>95134</code>
          <country>United States of America</country>
        </postal>

        <phone/>

        <facsimile/>
        <email>mankamis@cisco.com</email>

        <uri/>
      </address>
    </author>
    <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street/>
          <city>Boston</city>

          <region/>

          <code/>

          <country>USA</country>
          <region>MA</region>
          <country>United States of America</country>
        </postal>

        <phone/>

        <facsimile/>
        <email>zzhang@juniper.com</email>

        <uri/>
      </address>
    </author>
    <author fullname="Mike McBride" initials="M." surname="McBride">
      <organization>Futurewei Technologies Inc.</organization>
      <address>
        <postal>
          <street/>
          <city>Santa Clara</city>

          <region/>

          <code/>

          <country>USA</country>
          <region>CA</region>
          <country>United States of America</country>
        </postal>

        <phone/>

        <facsimile/>
        <email>michael.mcbride@futurewei.com</email>

        <uri/>
      </address>
    </author>
    <date day="05" month="December" year="2024"/> month="February" year="2025"/>

    <area>RTG</area>
    <workgroup>pim</workgroup>

    <abstract>
      <t>This document specifies Protocol Independent Multicast Light (PIM
      Light) and the PIM Light Interface (PLI) which (PLI). A PLI does not need a PIM
      Hello message to accept PIM Join/Prune messages. PLI messages, and it can signal
      multicast states over networks that can not cannot support full PIM neighbor
      discovery, such as an example BIER Bit Index Explicit Replication (BIER) networks that are connecting
      connect two or more PIM domains.  This document outlines the PIM Light
      protocol and procedures to ensure loop-free multicast traffic between
      two or more PIM Light routers.</t>
    </abstract>
  </front>
  <middle>

    <section title="Introduction">
      <!-- 1 --> numbered="true" toc="default">
      <name>Introduction</name>

      <t>This document specifies the procedures for Protocol Independent Multicast Light (PIM
      Light) and the PIM Light Interface (PLI) procedures. (PLI). The PLI is a new type of
      PIM interface that allows signaling of PIM Join/Prune packets without
      full PIM neighbor discovery. A PLI is useful in scenarios where multicast
      states needs need to be signalled signaled over networks or media that cannot support
      full PIM neighborship between routers or alternatively or, alternatively,  where full PIM
      neighborship is not desired. These type types of networks or medias and media are
      addressed as a PIM
      called "PIM Light Domain domains" within this document. Lack of full PIM
      neighborship will remove some PIM functionality as explained in section
      3.2 <xref target="absence-hello"/> of this document. PIM Light only supports Protocol Independent
      Multicast the PIM - Sparse Mode (PIM-SM) protocol protocol, including PIM Source-Specific
      Multicast (PIM-SSM) (PIM-SSM), as per <xref target="RFC7761"/>. The target="RFC7761" format="default"/>. This document
      details procedures and considerations needed for PIM Light and the PLI to
      ensure efficient routing of multicast groups for specific deployment
      environments.</t>
    </section>
    <section title="Conventions used in this document">
      <!-- 2 -->

      <t>The numbered="true" toc="default">
      <name>Terminology</name>

        <t>

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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
      "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t>

      <section title="Definitions">
        <!-- 2.1 --> here.

        </t>
        <t>This document uses definitions used in Protocol terminology from "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)" <xref
        target="RFC7761"/></t>
      </section> target="RFC7761" format="default"/>.</t>

    </section>
    <section title="PIM numbered="true" toc="default">
      <name>PIM Light Interface">
      <!--  3 -->

      <t>RFC <xref target="RFC7761"/> section 4.3.1 Interface</name>
      <t><xref section="4.3.1" sectionFormat="of" target="RFC7761" format="default"/> describes the PIM neighbor
      discovery via Hello messages. In section 4.5 it describes <xref section="4.5" sectionFormat="of" target="RFC7761"/> notes that if a
      router receives a Join/Prune message from a particular IP source address
      and it has not seen a PIM Hello message from that source address, then
      the Join/Prune message SHOULD <bcp14>SHOULD</bcp14> be discarded without further
      processing.</t>

<t>In certain scenarios, it is desirable to establish multicast states
      between two layer-3 adjacent Layer 3 routers without forming a PIM neighborship.
      This can be necessary for various reasons, such as signaling multicast
      states upstream between multiple PIM domains over a network that is not
      optimized for PIM or that does not necessitate PIM Neighbor neighbor establishment.
      For example, in
      An example is a Bit Index Explicit Replication (BIER) <xref
      target="RFC8279"/> networks target="RFC8279" format="default"/> network connecting multiple PIM domains, where PIM
      Join/Prune messages are tunneled via BIER as specified in <xref
      target="draft-ietf-bier-pim-signaling"/>.</t> target="I-D.ietf-bier-pim-signaling" format="default"/>.</t>
      <t>A PIM Light Interface (PLI) PLI accepts Join/Prune messages from an
      unknown PIM router without requiring a PIM Hello message from the
      router. The absence of Hello messages on a PLI means there is no
      mechanism to discover neighboring PIM routers or their capabilities, nor capabilities or
      to execute basic algorithms such as Designated Router (DR) election
      <xref target="RFC7761"/>. target="RFC7761" format="default"/>. Consequently, the PIM Light router does not
      create any general-purpose state for neighboring PIM routers and only
      processes Join/Prune messages from downstream routers in its multicast
      routing table. Processing these Join/Prune messages will introduce
      multicast states in a PIM Light router.</t>

      <t>Due to these constraints, a PLI should be deployed in very specific
      scenarios where PIM-SM is not suitable. The applications or the networks
      that
      on which PLIs are deployed on MUST <bcp14>MUST</bcp14> ensure that there is no
      multicast packet duplication, such as multiple upstream routers sending
      the same multicast stream to a single downstream router. As For example,
      an example the implementation should ensure that DR election is done on upstream
      Redundant
      redundant PIM routers that are at the edge of the PIM Light Domain domain to
      ensure that a single Designated Router to forward DR forwards the PIM Join message from
      reviver the receiver
      to the Source.</t> source.
      </t>
      <section title="PLI supported Messages">
        <t>IANA numbered="true" toc="default">

        <name>Message Types Supported by PIM Light</name>
        <t>The "PIM Message Types" registry <xref target="iana pim-parameters message-types"/>, target="IANA-PIM-Mess-Types" format="default"/> lists the
        PIM supported
        message types. types supported by PIM. PIM Light only supports the following
        message types from the table "PIM Message Types"</t>

        <t><list style="numbers">
            <t>type 3 (Join/Prune) from the ALL-PIM-ROUTERS message types
            listed in <xref target="RFC7761"/>.</t> that registry:</t>
        <ul>
          <li>
            <t>type 1 (Register)</t>
          </li>
          <li>
            <t>type 2 (Register Stop)</t>
          </li>
	  <li>
            <t>type 3 (Join/Prune)
	    </t>
          </li>
          <li>
            <t>type 8 (Candidate RP Advertisement)</t>
          </li>
          <li>
            <t>type 13 13.0 (PIM Packed Null-Register)</t>
          </li>
          <li>
            <t>type 13.1 (PIM Packed Register-Stop)</t>
          </li>
          <li>

            <t>Any future PIM message types that use unicast where the destination
            IP.</t>
          </list> No is a unicast IP address
            </t>
          </li>
        </ul>
        <t>No other message types are supported for by PIM Light and MUST
        NOT Light; other message types <bcp14>MUST
        NOT</bcp14> be process processed if received on a PLI.</t>
      </section>
      <section title="Absence numbered="true" toc="default" anchor="absence-hello">
        <name>Considerations for the Absence of Hello Message consideration">
        <t>In Message</name>

<t>Because Hello messages are not processed in a PIM Light domain, the following
considerations in the subsections below should be taken into account due to the lack of processing Hello messages.</t> account.
</t>
        <section title="Join Attribute"> numbered="true" toc="default">
          <name>Join Attribute</name>

          <t>Since a PLI does not process PIM Hello messages, it also does not
          support the join attributes Join Attribute option in PIM Hello as specified in
          <xref target="RFC5384"/>. target="RFC5384" format="default"/>. As such, PIM Light is unaware of its
          neighbor's capability to process join attributes Join Attributes and it SHOULD NOT <bcp14>SHOULD NOT</bcp14>
          process a join Join message containing it.</t>

          <t>For a Join Attribute.</t>

	  <t>There are two cases in which a PLI to can send and process a join attributes there can be two
          cases: <list style="numbers">
              <t>It Join Attribute:
          </t>
          <ul spacing="normal"><li>
              <t>The Join Attribute must be configured with an appropriate join attribute Join Attribute type
              that the PLI is capable of processing as per the "PIM Join Attribute Types" registry <xref
              target="iana pim-parameters join-attribute-types"/> table.</t>

              <t>Separate IETF drafts or target="IANA-PIM-Attr-Types" format="default"/>.</t>
            </li>
            <li>
              <t>Internet-Drafts and RFCs may dictate that certain join
              attributes are allowed to be used without explicit configuration
              of the PLI in certain scenarios. The details are left to those
              drafts or
              Internet-Drafts and RFCs.</t>
            </list></t>
            </li>
          </ul>
        </section>
        <section title="DR Election"> numbered="true" toc="default">
          <name>DR Election</name>

          <t>Due to the absence of Hello messages, DR Election election is not
          supported on a PIM Light router. The network design must ensure DR
          Election
          election occurs within the PIM domain, assuming the PIM Light domain
          interconnects PIM domains.</t>

          <t><figure>
              <artwork><![CDATA[                    Bier edge router       Bier edge router (BER)
           |--PIM Domain--|--BIER domain (PLI)--|--PIM domain--|
 Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--host
           |       PIM Adj|         | |         |PIM Adj       |
           |------------( E )-------| |-------( F )------------|
                                          (DR Election)]]></artwork>
            </figure></t>
          <t>For instance, in a BIER domain connecting two PIM networks, domains as in the figure below, a PLI
          can be used between BIER edge routers solely for multicast state
          communication and transmit only PIM Join/Prune messages.

  If there are redundant PIM routers at the edge of the BIER domain, to prevent
          multicast stream duplication, they MUST
  <bcp14>MUST</bcp14> establish PIM adjacency as per <xref target="RFC7761"/> target="RFC7761"
  format="default"/> to prevent multicast stream duplication and to ensure DR
  election at the edge of the BIER domain. An example

	  For example, DR election
          could be DR election between router D and F in above figure. the figure below.  When the Join
          or Prune message arrives from a PIM domain to the down stream downstream BIER
          edge router, it can be forwarded over the BIER tunnel to the
          upstream BIER edge router only via the designated router.</t> DR.</t>

          <artwork name="" type="" align="left" alt=""><![CDATA[
                   Bier edge router       Bier edge router
          |--PIM domain--|--BIER domain (PLI)--|--PIM domain--|
Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--Host
          |       PIM Adj|         | |         |PIM Adj       |
          |------------( E )-------| |-------( F )------------|
                                         (DR election)
]]></artwork>

        </section>
        <section title="PIM Assert"> numbered="true" toc="default">
          <name>PIM Assert</name>
          <t>In scenarios where multiple PIM routers peer over a shared LAN or
          a Point-to-Multipoint point-to-multipoint medium, more than one upstream router may have
          valid forwarding state for a packet, which can potentially causing cause packet
          duplication. PIM Assert is used to select a single transmitter when
          such duplication is detected. According to <xref target="RFC7761"/>
          section 4.6, section="4.6" sectionFormat="of" target="RFC7761" format="default"/>, PIM Assert should only be accepted from a known PIM
          neighbor.</t>
          <t>In PIM Light implementations, care must be taken to avoid
          duplicate streams arriving from multiple upstream PIM Light routers
          to a single downstream PIM Light router. If network design
          constraints prevent this, the implemented network architecture must
          take measures to avoid traffic duplication. For example, in a scenario with PIM
          Light over a BIER domain scenario, domain, a downstream IBBR (Ingress BIER
          Border Router) in a BIER domain can identify the nearest EBBRs
          (Egress BIER Border Routers) to the source using the Shortest Path
          First (SPF) algorithm with a post-processing as described in <xref
          target="draft-ietf-bier-pim-signaling"/> Appendix A.1. A.1 of <xref target="I-D.ietf-bier-pim-signaling" format="default"/>. If the
          downstream IBBR identifies two EBBRs, it can select one using a
          unique IP selection algorithm, such as choosing the EBBR with the
          lowest or highest IP address. If the selected EBBR goes offline, the
          downstream router can use the next EBBR based on the IP selection
          algorithm, which is beyond the scope of this document.</t>
        </section>
      </section>
      <section title="PLI Configuration">
        <!-- 3.1 --> numbered="true" toc="default">
        <name>PLI Configuration</name>

        <t>Since a PLI doesn't require PIM Hello Messages and PIM neighbor
        adjacency is not checked for arriving Join/Prune messages, there needs
        to be a mechanism to enable PLI PLIs on interfaces. If a router supports
        PIM Light, arriving Join/Prune messages <bcp14>MUST</bcp14> be
        processed only when a PLI is enabled on an interface, arriving
        Join/Prune messages MUST be processed, otherwise interface; otherwise, they MUST
        <bcp14>MUST</bcp14> be dropped.
        While on  In some logical interfaces cases, a PLI maybe may be enabled
        automatically or via an underlying mechanism, as an example the mechanism on a logical interface. For
        example, in a BIER domain, a logical interface
        connecting can connect two or more
        BIER edge routers in a BIER subdomain as per <xref
        target="draft-ietf-bier-pim-signaling"/>.</t> target="I-D.ietf-bier-pim-signaling"
        format="default"/>).</t>
      </section>
      <section title="Failures numbered="true" toc="default">
        <name>Failures in PLR domain"> Domain</name>

	<t>Because the Hello messages are not processed on the PLI, PIM Light
        Interface PLI
        failures may not be discovered in a PIM Light domain domain, and
        multicast routes will not be pruned toward the source on the PIM Light
        domain, leaving
        domain. This results in the upstream routers continuously sending multicast
        streams until the outgoing interface (OIF) expires.</t>
        <t>Other protocols can be used to detect these failures in the PIM
        Light domain domain, and they can be implementation specific. As an example,
        the interface that on which PIM Light is configured on can be protected via
        Bidirectional Forwarding Detection (BFD) or similar technology. If BFD
        to the far-end PLI goes down, down and the PIM Light Router router is upstream and
        has an OIF for a multicast route &lt;S,G&gt;, (S,G), PIM must remove that PLI
        from its OIF list.</t>

        <t><figure>
            <artwork><![CDATA[                         UBER                 DBER
           |--PIM Domain--|--BIER domain (PLI)--|--PIM domain--|
 Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--host
                  <--Prune <S,G>          <failure on D>]]></artwork>
          </figure></t>

        <t>In another example, where the PLI is configured automatically
        between the BIER Edge Routers (BER), when (BERs) as in the downstream figure below. When the Downstream BIER Edge
        Router (DBER) is no longer reachable on the upstream Upstream BIER Edge Router
        (UBER), the UBER which (which is also a PIM Light Router router) can prune the
        &lt;S,G&gt;
        (S,G) advertised toward the source on the PIM domain to stop the
        transmission of the multicast stream.</t>

        <artwork name="" type="" align="left" alt=""><![CDATA[
                        UBER                 DBER
          |--PIM domain--|--BIER domain (PLI)--|--PIM domain--|
Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--Host
                 <--Prune (S,G)          <failure on D>
]]></artwork>
      </section>
      <section title="Reliable numbered="true" toc="default">
        <name>Reliable Transport Mechanism for PIM LIGHT"> Light</name>

	<t><xref target="RFC6559"/> target="RFC6559" format="default"/> defines a reliable transport mechanism called
	PIM Over Reliable Transport (PORT) for PIM transmission of Join/Prune messages,
	using either TCP or SCTP as the transport protocol. For TCP, PIM over reliable transport (PORT) uses Both TCP and SCTP use
	destination port 8471 which is assigned by IANA. number 8471. SCTP is explained in <xref
        target="RFC9260"/>, target="RFC9260" format="default"/> and it
	is used as a second option for PORT. <xref
        target="RFC6559"/> target="RFC6559" format="default"/> mentions that when
	a router is configured to use PIM over TCP on a given interface, it MUST
	<bcp14>MUST</bcp14> include the PIM-over-TCP-Capable Hello Option in its Hello
	messages for that interface.  The same is true for SCTP and SCTP; the router must
	<bcp14>MUST</bcp14> include the PIM-over-SCTP-Capable Hello Option in its Hello messsage messages
	on that
        interface.</t> interface.
	</t>

        <t>These Hello options contain a Connection ID ID, which is an IPv4 or
        IPv6 address used to establish the SCTP or TCP connection.  For PORT
        using TCP, the connection Connection ID is used for determining to determine which peer is
        doing an active transport open to the neighbor and which peer is doing
        passive transport open, as per section 4 of <xref
        target="RFC6559"/></t>

        <t>When section="4" sectionFormat="of"
        target="RFC6559" format="default"/>.

	When the router is using SCTP, the Connection ID IP address
        comparison need is not be done since used to
	determine the active and passive peer since SCTP protocol can handle call
        collision.</t>

        <t>PIM
	collision.
        </t>

	<t>Because PIM Light lacks Hello messages, the PLI can be configured with the
        Connection ID (i.e., the IPv4 or IPv6 addresses address used to establish the SCTP or TCP
        connection.
        connection). For PIM Light using the TCP PORT option option, each end of the PLI
        must be explicitly and correct correctly configured as being either active transport
        open or passive transport open to ensure handle that call collision is
        avoided.</t>
      </section>
      <section title="PIM numbered="true" toc="default">
        <name>PIM Variants not supported"> Not Supported</name>
        <t>The following PIM variants are not supported with PIM Light and not
        covered by this document:</t>

        <t><list style="numbers">
            <t>Protocol Independent Multicast
        <ul spacing="normal">
	  <li>
            <t>PIM - Dense Mode (PIM-DM)<xref
            target="RFC3973"> </xref></t> (PIM-DM) <xref target="RFC3973" format="default"/></t>
          </li>
          <li>
            <t>Bidirectional Protocol Independent Multicast PIM (BIDIR-PIM) <xref
            target="RFC5015"/></t>
          </list></t> target="RFC5015" format="default"/></t>
          </li>
        </ul>
      </section>
    </section>
    <section title="IANA Considerations">
      <!-- 7 -->

      <t>There are numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no new IANA considerations for this document.</t> actions.</t>
    </section>
    <section title="Security Considerations">
      <!-- 8 --> numbered="true" toc="default">
      <name>Security Considerations</name>

      <t>Since PIM Light does not require PIM Hello messages and does not
      verify PIM neighbor adjacency for incoming Join/Prune messages, it is
      crucial for security reasons, it is
      crucial that implementations ensure that the implementation ensures only
      Join/Prune messages arriving at a configured PLI are processed. Any
      Join/Prune messages received on an interface that is not configured as a
      PLI MUST <bcp14>MUST</bcp14> be discarded and not processed. Additionally, as a secondary
      line of defense, route policies SHOULD <bcp14>SHOULD</bcp14> be implemented to process only
      the Join/Prune messages associated with the desired (S,G) pairs, while
      all other (S,G) pairs MUST <bcp14>MUST</bcp14> be discarded and not processed.</t>

      <t>Furthermore, because PIM Light can be used for signaling
      Source-Specific and Sparse Mode
      PIM-SM Join/Prune messages, the security considerations outlined in
      <xref target="RFC7761"/> target="RFC7761" format="default"/> and <xref
      target="RFC4607"/> SHOULD target="RFC4607"
      format="default"/> <bcp14>SHOULD</bcp14> be considered where
      appropriate.</t>

      <t>In section 6.1.1 of

      <t>Per <xref section="6.1.1" sectionFormat="of" target="RFC7761"/>, only forged join/prune
      message Join/Prune
      messages should be considered as a potential attack vector, as PIM Light
      does not process Hello or Assert messages. In addition, as detailed in
      Section 6.3, <xref section="6.3" sectionFormat="of" target="RFC7761"/>, the authentication mechanisms described in <xref
      target="RFC5796"/> target="RFC5796" format="default"/> can be applied to PIM Light via IPsec Encapsulating
      Security Payload (ESP) or, optionally, the Authentication Header
      (AH).</t>
    </section>

    <section title="Acknowledgments">
      <!-- 9 -->

      <t>Would like to thank Sandy &lt;Zhang Zheng&gt; and Tanmoy Kundu for
      their suggestions and contribution to this document.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <!-- 10.1 -->

      <reference anchor="RFC2119">
        <front>
          <title>S. Brandner, "Key words for use in RFCs to Indicate
          Requirement Levels"</title>

          <author>
            <organization/>
          </author>

          <date month="March" year="1997"/>
        </front>
      </reference>

    <displayreference target="I-D.ietf-bier-pim-signaling" to="BIER-PIM"/>

    <references>
      <name>References</name>
      <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.8174.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.5384.xml"/>

        <reference anchor="RFC8174"> anchor="IANA-PIM-Mess-Types" target="https://www.iana.org/assignments/pim-parameters">
          <front>
          <title>B. Leiba, "ambiguity of Uppercase vs Lowercase in RFC 2119
          Key Words"</title>

          <author>
            <organization/>
          </author>

          <date month="May" year="2017"/>
        </front>
      </reference>

      <reference anchor="RFC7761">
        <front>
          <title>B.Fenner, M.Handley, H. Holbrook, I. Kouvelas, R. Parekh,
          Z.Zhang "PIM Sparse Mode"</title>
            <title>PIM Message Types</title>
            <author>
            <organization/>
              <organization>IANA</organization>
            </author>

          <date month="March" year="2016"/>
          </front>
        </reference>

        <reference anchor="RFC5384"> anchor="IANA-PIM-Attr-Types" target="https://www.iana.org/assignments/pim-parameters">
          <front>
          <title>A. Boers, I. Wijnands, E. Rosen "PIM
            <title>PIM Join Attribute
          Format"</title>

          <author>
            <organization/>
          </author>

          <date month="March" year="2016"/>
        </front>
      </reference>

      <reference anchor="iana pim-parameters message-types"
                 target="https://www.iana.org/assignments/pim-parameters/pim-parameters.xhtml#message-types">
        <front>
          <title/>

          <author>
            <organization/>
          </author>

          <date month="01" year="2022"/>
        </front>
      </reference>

      <reference anchor="iana pim-parameters join-attribute-types"
                 target="https://www.iana.org/assignments/pim-parameters/pim-parameters.xhtml#pim-parameters-2">
        <front>
          <title/>

          <author>
            <organization/>
          </author>

          <date month="01" year="2022"/>
        </front>
      </reference>

      <reference anchor="RFC6559">
        <front>
          <title>D. Farinacci, I. Wijnands, S. Venaas, M. Napierala "A
          reliable Transport Mechanism for PIM"</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC4607">
        <front>
          <title>H. Holbrook, B. Cain "Source-Specific Multicast for
          IP"</title> Types</title>
            <author>
            <organization/>
              <organization>IANA</organization>
            </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC5796">
        <front>
          <title>W. Atwood, S. Islam, M. Siami "Authentication and
          Confidentiality in PIM-SM"</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC5015">
        <front>
          <title>M. Handley, I. Kouvelas, T. Speakman, L. Vicisano
          "Bidirectional Protocol Independent Multicast"</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="RFC8279">
        <front>
          <title>Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T. and S.
          Aldrin, "Multicast using Bit Index Explicit Replication"</title>

          <author>
            <organization/>
          </author>

          <date month="October" year="2016"/>
        </front>
      </reference>

      <reference anchor="RFC9260">
        <front>
          <title>R. Stewart, M. Tuxen, K. Nielsen, "Stream Control
          Transmission Protocol"</title>

          <author>
            <organization/>
          </author>

          <date month="June" year="2022"/>
          </front>
        </reference>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6559.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4607.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5796.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5015.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9260.xml"/>

      </references>

    <references title="Informative References">
      <reference anchor="RFC3973">
        <front>
          <title>A. Adams, J. Nicholas, W. Siadak, "Protocol Independent
          Multicast
      <references>
        <name>Informative References</name>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3973.xml"/>

<!-- I-D.ietf-bier-pim-signaling.xml - Dense Mode"</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference> used long way because missing "Ed" -->

<reference anchor="draft-ietf-bier-pim-signaling"> anchor="I-D.ietf-bier-pim-signaling" target="https://datatracker.ietf.org/doc/html/draft-ietf-bier-pim-signaling-12">
<front>
          <title>H.Bidgoli, F.XU, J. Kotalwar, I. Wijnands, M.Mishra, Z.
          Zhang, "PIM
<title>PIM Signaling Through BIER Core"</title>

          <author>
            <organization/> Core</title>
<author fullname="Hooman Bidgoli" initials="H." surname="Bidgoli" role="editor">
<organization>Nokia</organization>
</author>
<author fullname="Fengman Xu" initials="F." surname="Xu">
<organization>Verizon</organization>
</author>
<author fullname="Jayant Kotalwar" initials="J." surname="Kotalwar">
<organization>Nokia</organization>
</author>
<author fullname="IJsbrand Wijnands" initials="I." surname="Wijnands">
<organization>Cisco System</organization>
</author>
<author fullname="Mankamana Prasad Mishra" initials="M." surname="Mishra">
<organization>Cisco System</organization>
</author>
<author fullname="Zhaohui (Jeffrey) Zhang" initials="Z." surname="Zhang">
<organization>Juniper Networks</organization>
</author>
<date day="25" month="July" year="2021"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-bier-pim-signaling-12"/>
</reference>

      </references>
    </references>

        <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank <contact fullname="Zheng (Sandy) Zhang"/>
      and <contact fullname="Tanmoy Kundu"/> for their suggestions and
      contributions to this document.</t>
    </section>

  </back>
</rfc>
<!-- generated from file C:\Users\hbidgoli\Downloads\draft-ietf-bier-pim-signaling-08.nroff with nroff2xml 0.1.0 by Tomek Mrugalski -->