<?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"/>

    <abstract>
      <t>This month="February" year="2025"/>

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

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

<!-- [rfced] Abstract

a) We updated the text starting with "which does not..." as follows to improve
readability; please review and let us know any concerns.

Original:
   This document specifies Protocol Independent Multicast Light (PIM
   Light) and PIM Light Interface (PLI) which does not need PIM Hello
   message to accept PIM Join/Prune messages.  PLI can signal multicast
   states over networks that can not support full PIM neighbor
   discovery, as an example BIER networks that are connecting two or
   more PIM domains.

Perhaps:
   This document specifies Protocol Independent Multicast Light (PIM Light)
   and the PIM Light Interface (PLI). A PLI does not need a PIM Hello
   message to accept PIM Join/Prune messages, and it can signal multicast
   states over networks that cannot support full PIM neighbor
   discovery, such as Bit Index Explicit Replication (BIER) networks that connect two or
   more PIM domains.

b) Should "protocol and procedures" be updated to just "procedures" as in the
Introduction?

Original:
   This document outlines the PIM
   Light protocol and procedures to ensure loop-free multicast traffic
   between two or more PIM Light routers.

Perhaps:
   This document outlines PIM
   Light procedures to ensure loop-free multicast traffic
   between two or more PIM Light routers.
-->
    <abstract>
      <t>This document specifies Protocol Independent Multicast Light (PIM
      Light) and the PIM Light Interface (PLI). A PLI does not need a PIM
      Hello message to accept PIM Join/Prune messages, and it can signal
      multicast states over networks that cannot support full PIM neighbor
      discovery, such as Bit Index Explicit Replication (BIER) networks that
      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>

<!-- [rfced] This is a sentence fragment. How may we update to make a complete
sentence? Also, please confirm that "network" is intended here; elsewhere
in the document, we see "BIER domain" rather than "BIER network".

Original:
   For example, in a Bit Index Explicit
   Replication (BIER) [RFC8279] networks connecting multiple PIM
   domains, where PIM Join/Prune messages are tunneled via BIER as
   specified in [draft-ietf-bier-pim-signaling].

Perhaps:
   An example is a Bit Index Explicit
   Replication (BIER) [RFC8279] network connecting multiple PIM
   domains, where PIM Join/Prune messages are tunneled via BIER as
   specified in [BIER-PIM].

Or:
   For example, in a Bit Index Explicit
   Replication (BIER) [RFC8279] network connecting multiple PIM
   domains, PIM Join/Prune messages are tunneled via BIER as
   specified in [draft-ietf-bier-pim-signaling].
-->

<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 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>

<!-- [rfced] Please clarify the text starting with "to ensure...". Also, is
"reviver" correct? Or is "receiver" or something else intended?

Original:
   As an example
   the implementation should ensure that DR election is done on upstream
   Redundant PIM routers that are at the edge of the PIM Light Domain to
   ensure a single Designated Router to forward the PIM Join message
   from reviver to the Source.

Perhaps:
   As an example,
   the implementation should ensure that DR election is done on upstream
   redundant PIM routers that are at the edge of the PIM Light domain to
   ensure that a single DR forwards the PIM Join message
   from the receiver to the source.
-->

      <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 a single Designated Router DR to forward the PIM Join message from
      reviver to the Source.</t> source.</t>
      <section title="PLI supported Messages">
        <t>IANA numbered="true" toc="default">

<!-- [rfced] FYI - We reordered the list in Section 3.1 by type number as only
one was out of order.
-->

<!-- [rfced] Is the text starting with "from the..." needed here? Other
entries in the list do not have such notes, and in the IANA registry
(linked to in the text introducing this list), RFC 7761 is listed as a
reference for type 3. See https://www.iana.org/assignments/pim-parameters/.

Original:
   1.  type 3 (Join/Prune) from the ALL-PIM-ROUTERS message types listed
   in [RFC7761].

Current:
   *  type 3 (Join/Prune) (Note that this type is from the ALL-PIM-
   ROUTERS message types listed in [RFC7761].)

Perhaps:
   *  type 3 (Join/Prune)
-->

<!-- [rfced] FYI - We updated "13" to "13.0" to match the registry at
https://www.iana.org/assignments/pim-parameters/.

Original:
   type 13 (PIM Packed Null-Register)

Updated:
   type 13.0 (PIM Packed Null-Register)
-->

        <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"> in 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) (Note that this type is from the ALL-PIM-ROUTERS message types
            listed in <xref target="RFC7761"/>.</t>

            <t>type 1 (Register)</t>

            <t>type 2 (Register Stop)</t> target="RFC7761" format="default"/>.)</t>
          </li>
          <li>
            <t>type 8 (Candidate RP Advertisement)</t>
          </li>
          <li>
            <t>type 13 (PIM Packed Null-Register)</t>
          </li>
          <li>
            <t>type 13.1 (PIM Packed Register-Stop)</t>
          </li>
          <li>
<!-- [rfced] Is "unicast destination IP" correct here, or should it be "unicast
destination IP addresses" (with "addresses")?

Original:
   7.  Any future PIM message types that use unicast destination IP.

Perhaps:
   *  Any future PIM message types that use unicast destination IP addresses.
-->

            <t>Any future PIM message types that use unicast destination
            IP.</t>
          </list> No
            IP</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 account.
</t>
        <section numbered="true" toc="default">
          <name>Join Attribute</name>

<!-- [rfced] Will readers know what both instances of "it" refer to in the lack
text "it SHOULD NOT process a join message containing it"?

Original:
   As such, PIM Light is unaware of processing Hello messages.</t>

        <section title="Join Attribute"> its neighbor's
   capability to process join attributes and it SHOULD NOT process a
   join message containing it.

Perhaps:
   As such, PIM Light is unaware of its neighbor's
   capability to process join attributes and SHOULD NOT process a
   Join message containing a join attribute.
-->

          <t>Since a PLI does not process PIM Hello messages, it also does not
          support the join attributes 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 attributes, and it SHOULD NOT <bcp14>SHOULD NOT</bcp14>
          process a join Join message containing it.</t>

          <t>For

	  <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 attribute:
          </t>
          <ul spacing="normal"><li>
              <t>The join attribute must be configured with an appropriate 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>

<!-- [rfced] We note that the sentence below in Section 3.2.2 uses "PIM
networks" but the figure uses "PIM domain". Are any updates needed?

Original:
   For instance, in a BIER domain connecting two PIM networks, a PLI can
   be used between BIER edge routers solely for multicast state
   communication and transmit only PIM Join/Prune messages.

Perhaps:
   For instance, in a BIER domain connecting two PIM domains, a PLI can
   be used between BIER edge routers solely for multicast state
   communication and transmit only PIM Join/Prune messages.
-->

<!-- [rfced] Please clarify "An example DR election could be DR election".

Original:
   An example DR election could be DR election between router D and F in
   above figure.

Perhaps:
   For example, DR election could be between router D and F in
   above figure.
-->

<!-- [rfced] In Sections 3.2.2 and 3.4, we recommend including text to
introduce figure.

In Section 3.2.2, perhaps the second paragraph can be moved before the figure
and first sentence of that paragraph updated in one of the following ways.

Original:
   For instance, in a BIER domain connecting two PIM networks, a PLI can
   be used between BIER edge routers solely for multicast state
   communication and transmit only PIM Join/Prune messages.

Perhaps (add "as in the figure below"):
   For instance, in a BIER domain connecting two PIM networks 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.

Or (use two sentences):
   For instance, the figure below depicts a BIER domain connecting
   two PIM networks. A PLI can
   be used between BIER edge routers solely for multicast state
   communication and transmit only PIM Join/Prune messages.

In Section 3.4, perhaps the last paragraph can be moved before the figure and
updated as follows (add "as in the figure below").

Original:
   In another example, where the PLI is configured automatically between
   the BIER Edge Routers (BER), when the downstream BIER Edge Router
   (DBER) is no longer reachable on the upstream BIER Edge Router
   (UBER), the UBER which is also a PIM Light Router can prune the <S,G>
   advertised toward the source on the PIM domain to stop the
   transmission of the multicast stream.

Perhaps:
   In another example, the PLI is configured automatically between
   the BIER Edge Routers (BERs) as in the figure below. When the downstream BIER Edge Router
   (DBER) is no longer reachable on the upstream BIER Edge Router
   (UBER), the UBER (which is also a PIM Light router) can prune the <S,G>
   advertised toward the source on the PIM domain to stop the
   transmission of the multicast stream.
-->

<!-- [rfced] May we move the text "to prevent multicast stream duplication" as
follows to improve readability?

Original:
   If there
   are redundant PIM routers at the edge of the BIER domain, to prevent
   multicast stream duplication, they MUST establish PIM adjacency as
   per [RFC7761] to ensure DR election at the edge of BIER domain.

Perhaps:
   If there
   are redundant PIM routers at the edge of the BIER domain, they MUST
   establish PIM adjacency as per [RFC7761] to prevent multicast stream
   duplication and to ensure DR election at the edge of the BIER domain.
-->

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

          <t><figure>
              <artwork><![CDATA[

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

          <t>For instance, in a BIER domain connecting two PIM networks, 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 ensure DR election at the edge of
          BIER domain. An example DR election could be DR election between
          router D and F in above figure. the figure above. 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>
        </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"> numbered="true" toc="default">
        <name>PLI Configuration</name>

<!-- 3.1 [rfced] We updated this sentence as follows; please review and let us
know any concerns.

Original:
   If a router
   supports PIM Light, only when PLI is enabled on an interface,
   arriving Join/Prune messages MUST be processed, otherwise they MUST
   be dropped.

Updated:
   If a router supports PIM Light, arriving Join/Prune messages MUST be
   processed only when a PLI is enabled on an interface; otherwise, they MUST
   be dropped.
-->

<!-- [rfced] This sentence does not parse. We updated as follows. Let us know
any concerns.

Original:
   While on some logical interfaces PLI maybe enabled
   automatically or via an underlying mechanism, as an example the
   logical interface connecting two or more BIER edge routers in a BIER
   subdomain [draft-ietf-bier-pim-signaling].

Updated:
   PLI may be enabled automatically or via an underlying mechanism on some
   logical interfaces (for example, the logical interface connecting two or
   more BIER edge routers in a BIER subdomain [BIER-PIM]).
-->

        <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 some logical interfaces  A PLI maybe may be enabled automatically or
        via an underlying mechanism, as an example mechanism on some logical interfaces (for example,
        the logical interface connecting two or more BIER edge routers in a
        BIER subdomain <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;, PIM must remove that PLI
        from its OIF list.</t>

        <t><figure>
            <artwork><![CDATA[

        <artwork name="" type="" align="left" alt=""><![CDATA[
                        UBER                 DBER
          |--PIM Domain--|--BIER domain--|--BIER domain (PLI)--|--PIM domain--|
Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--host )--Host
                 <--Prune <S,G>          <failure on D>]]></artwork>
          </figure></t> D>
]]></artwork>
        <t>In another example, where the PLI is configured automatically
        between the BIER Edge Routers (BER), when (BERs). When the downstream 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; advertised toward the source on the PIM domain to stop the
        transmission of the multicast stream.</t>
      </section>
      <section title="Reliable numbered="true" toc="default">
        <name>Reliable Transport Mechanism for PIM LIGHT"> Light</name>

<!-- [rfced] We confirmed that port 8471 is correct in this sentence per the
registry at https://www.iana.org/assignments/service-names-port-numbers. In the
registry, we see that port 8471 is also for PORT with SCTP as the transport
protocol. This sentence just mentions TCP, though SCTP is mentioned in
the next sentence. Are any updates needed?

Original:
   For TCP, PIM over reliable transport (PORT) uses port 8471
   which is assigned by IANA.
-->

<!-- [rfced] The first sentence below uses "MUST", but the second uses "must"
(although it says "the same is true"). Please review and let us know if
any updates are needed.

Original:
   [RFC6559] mentions that when a
   router is configured to use PIM over TCP on a given interface, it
   MUST include the PIM-over-TCP-Capable Hello Option in its Hello
   messages for that interface.  The same is true for SCTP and the
   router must include PIM-over-SCTP-Capable Hello Option in its Hello
   message on that interface.

Perhaps:
   [RFC6559] mentions that when a
   router is configured to use PIM over TCP on a given interface, it
   MUST include the PIM-over-TCP-Capable Hello Option in its Hello
   messages for that interface.  The same is true for SCTP; the
   router MUST include the PIM-over-SCTP-Capable Hello Option in its Hello
   message on that interface.
-->

        <t><xref target="RFC6559"/> target="RFC6559" format="default"/> defines a reliable transport mechanism for
        PIM transmission of Join/Prune messages, using either TCP or SCTP as the
        transport protocol. For TCP, PIM over reliable transport Over Reliable Transport (PORT) uses
        port 8471 8471, which is was assigned by IANA. 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 include the
        PIM-over-SCTP-Capable Hello Option in its Hello messsage message on that
        interface.</t>

<!-- [rfced] Will readers understand "Connection ID IP address comparison"?
What is being compared?

Original:
   When the router is using SCTP, the Connection ID IP address
   comparison need not be done since the SCTP can handle call
   collision.
-->

        <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> section="4" sectionFormat="of" target="RFC6559" format="default"/>.</t>
        <t>When the router is using SCTP, the Connection ID IP address
        comparison need not be done since the SCTP protocol can handle call
        collision.</t>

        <t>PIM

<!-- [rfced] This sentence in Section 3.5 explains that a Connection ID is an
IPv4 or IPv6 address used to establish the SCTP or TCP connection:

Original
   These Hello options contain a Connection ID which is an IPv4 or IPv6
   address used to establish the SCTP or TCP connection.

The sentence below appears in the next paragraph. Should the text starting
with "Connection ID IPv4 or IPv6 addresses..." be updated for consistency with
the previous text?

Original:
   PIM Light lacks Hello messages, the PLI can be configured with the
   Connection ID IPv4 or IPv6 addresses used to establish the SCTP or
   TCP connection.

Perhaps:
   Because PIM Light lacks Hello messages, the PLI can be configured with the
   Connection ID (i.e., the IPv4 or IPv6 address used to establish the SCTP or
   TCP connection).

Or:
   Because PIM Light lacks Hello messages, the PLI can be configured with the
   Connection ID.
-->

	<t>Because PIM Light lacks Hello messages, the PLI can be configured with the
        Connection ID IPv4 or IPv6 addresses used to establish the SCTP or TCP
        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"> numbered="true" toc="default">
      <name>Security Considerations</name>

<!-- 8 [rfced] Should "Source-Specific and Sparse Mode Join/Prune messages" here
be updated to "PIM-SSM and PIM-SM Join/Prune messages"?

Original:
   Furthermore, because PIM Light can be used for signaling Source-
   Specific and Sparse Mode Join/Prune messages, the security
   considerations outlined in [RFC7761] and [RFC4607] SHOULD be
   considered where appropriate.

Perhaps:
   Furthermore, because PIM Light can be used for signaling PIM-SSM
   and PIM-SM Join/Prune messages, the security
   considerations outlined in [RFC7761] and [RFC4607] SHOULD be
   considered where appropriate.
-->

      <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 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>

      <reference anchor="RFC8174">
        <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>

    <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="RFC7761"> anchor="IANA-PIM-Mess-Types" target="https://www.iana.org/assignments/pim-parameters">
          <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> Types</title>
            <author>
            <organization/>
              <organization>IANA</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>

          <author>
            <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>
  </back>
</rfc>
    </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>

<!-- generated from file C:\Users\hbidgoli\Downloads\draft-ietf-bier-pim-signaling-08.nroff [rfced] Terminology

a) These terms are used inconsistently throughout the text. Should these be
uniform? If so, please let us know which form is preferred.

DR Election vs. DR election
<S,G> vs. (S,G)

b) We also note inconsistencies in the terms listed below. We chose the form
on the right. Please let us know any objections.

PIM Light Router vs. PIM Light router
PIM Light Domain vs. PIM Light domain
connection ID vs Connection ID
Source vs. source
join message vs. Join message
join/prune message vs. Join/Prune message

c) Should "join attribute" be capitalized per usage in RFC 5384?

d) Article usage (e.g., "a" and "the") with nroff2xml 0.1.0 by Tomek Mrugalski "PIM Light Interface" and "PLI"
was mixed. We added articles in some instances. Please review for
correctness.

-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

  </back>
</rfc>