rfc9739xml2.original.xml   rfc9739.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" 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" ?>
<rfc category="std" docName="draft-ietf-pim-light-11" ipr="trust200902">
<front>
<title abbrev="PIM Light">Protocol Independent Multicast Light (PIM
Light)</title>
<author fullname="Hooman Bidgoli" initials="H" role="editor" <!DOCTYPE rfc [
surname="Bidgoli"> <!ENTITY nbsp "&#160;">
<organization>Nokia</organization> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-pim-light-11" number="9739" consensus="true" ipr="trust200902" obsoletes="" u
pdates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" sym
Refs="true" sortRefs="true" version="3">
<front>
<title abbrev="PIM Light">Protocol Independent Multicast Light (PIM Light)
</title>
<seriesInfo name="RFC" value="9739"/>
<author fullname="Hooman Bidgoli" initials="H" role="editor" surname="Bidgol
i">
<organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street>March Road</street> <street>March Road</street>
<city>Ottawa</city> <city>Ottawa</city>
<region>Ontario</region> <region>Ontario</region>
<code>K2K 2T6</code> <code>K2K 2T6</code>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<phone/>
<email>hooman.bidgoli@nokia.com</email> <email>hooman.bidgoli@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Stig Venaas" initials="S." surname="Venaas"> <author fullname="Stig Venaas" initials="S." surname="Venaas">
<organization>Cisco System, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Tasman Drive</street> <street>Tasman Drive</street>
<city>San Jose</city> <city>San Jose</city>
<region>CA</region>
<region>California</region>
<code>95134</code> <code>95134</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<phone/> <phone/>
<email>stig@cisco.com</email> <email>stig@cisco.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Mankamana Mishra" initials="M." surname="Mishra"> <author fullname="Mankamana Mishra" initials="M." surname="Mishra">
<organization>Cisco System</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Tasman Drive</street> <street>Tasman Drive</street>
<city>San Jose</city> <city>San Jose</city>
<region>CA</region>
<region>California</region>
<code>95134</code> <code>95134</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>mankamis@cisco.com</email> <email>mankamis@cisco.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Zhaohui Zhang" initials="Z." surname="Zhang"> <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Boston</city> <city>Boston</city>
<region>MA</region>
<region/> <country>United States of America</country>
<code/>
<country>USA</country>
</postal> </postal>
<email>zzhang@juniper.net</email>
<phone/>
<facsimile/>
<email>zzhang@juniper.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Mike McBride" initials="M." surname="McBride"> <author fullname="Mike McBride" initials="M." surname="McBride">
<organization>Futurewei Technologies Inc.</organization> <organization>Futurewei Technologies Inc.</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Santa Clara</city> <city>Santa Clara</city>
<region>CA</region>
<region/> <country>United States of America</country>
<code/>
<country>USA</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>michael.mcbride@futurewei.com</email> <email>michael.mcbride@futurewei.com</email>
<uri/>
</address> </address>
</author> </author>
<date month="February" year="2025"/>
<date day="05" month="December" year="2024"/> <area>RTG</area>
<workgroup>pim</workgroup>
<abstract> <abstract>
<t>This document specifies Protocol Independent Multicast Light (PIM <t>This document specifies Protocol Independent Multicast Light (PIM
Light) and PIM Light Interface (PLI) which does not need PIM Hello Light) and the PIM Light Interface (PLI). A PLI does not need a PIM
message to accept PIM Join/Prune messages. PLI can signal multicast Hello message to accept PIM Join/Prune messages, and it can signal
states over networks that can not support full PIM neighbor discovery, multicast states over networks that cannot support full PIM neighbor
as an example BIER networks that are connecting two or more PIM domains. discovery, such as Bit Index Explicit Replication (BIER) networks that
This document outlines the PIM Light protocol and procedures to ensure connect two or more PIM domains. This document outlines the PIM Light
loop-free multicast traffic between two or more PIM Light routers.</t> protocol and procedures to ensure loop-free multicast traffic between
two or more PIM Light routers.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction">
<!-- 1 -->
<t>This document specifies the Protocol Independent Multicast Light (PIM <section numbered="true" toc="default">
Light) and PIM Light Interface (PLI) procedures. PLI is a new type of <name>Introduction</name>
<t>This document specifies procedures for Protocol Independent Multicast L
ight (PIM
Light) and the PIM Light Interface (PLI). The PLI is a new type of
PIM interface that allows signaling of PIM Join/Prune packets without PIM interface that allows signaling of PIM Join/Prune packets without
full PIM neighbor discovery. PLI is useful in scenarios where multicast full PIM neighbor discovery. A PLI is useful in scenarios where multicast
states needs to be signalled over networks or media that cannot support states need to be signaled over networks or media that cannot support
full PIM neighborship between routers or alternatively full PIM full PIM neighborship between routers or, alternatively, where full PIM
neighborship is not desired. These type of networks or medias are neighborship is not desired. These types of networks and media are
addressed as a PIM Light Domain within this document. Lack of full PIM called "PIM Light domains" within this document. Lack of full PIM
neighborship will remove some PIM functionality as explained in section neighborship will remove some PIM functionality as explained in <xref targ
3.2 of this document. PIM Light only supports Protocol Independent et="absence-hello"/> of this document. PIM Light only supports the PIM - Sparse
Multicast Sparse Mode (PIM-SM) protocol including PIM Source-Specific Mode (PIM-SM) protocol, including PIM Source-Specific
Multicast (PIM-SSM) as per <xref target="RFC7761"/>. The document Multicast (PIM-SSM), as per <xref target="RFC7761" format="default"/>. Thi
details procedures and considerations needed for PIM Light and PLI to s document
details procedures and considerations needed for PIM Light and the PLI to
ensure efficient routing of multicast groups for specific deployment ensure efficient routing of multicast groups for specific deployment
environments.</t> environments.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Terminology</name>
<section title="Conventions used in this document"> <t>
<!-- 2 -->
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
"OPTIONAL" in this document are to be interpreted as described in BCP 14 ",
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
they appear in all capitals, as shown here.</t> "<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&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
<section title="Definitions"> </t>
<!-- 2.1 --> <t>This document uses terminology from "Protocol Independent Multicast -
Sparse Mode (PIM-SM): Protocol Specification (Revised)" <xref target="RFC7761"
format="default"/>.</t>
<t>This document uses definitions used in Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification <xref
target="RFC7761"/></t>
</section>
</section> </section>
<section numbered="true" toc="default">
<section title="PIM Light Interface"> <name>PIM Light Interface</name>
<!-- 3 --> <t><xref section="4.3.1" sectionFormat="of" target="RFC7761" format="defau
lt"/> describes PIM neighbor
<t>RFC <xref target="RFC7761"/> section 4.3.1 describes the PIM neighbor discovery via Hello messages. <xref section="4.5" sectionFormat="of" targe
discovery via Hello messages. In section 4.5 it describes that if a t="RFC7761"/> notes that if a
router receives a Join/Prune message from a particular IP source address 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 and it has not seen a PIM Hello message from that source address, then
the Join/Prune message SHOULD be discarded without further the Join/Prune message <bcp14>SHOULD</bcp14> be discarded without further
processing.</t> processing.</t>
<t>In certain scenarios, it is desirable to establish multicast states <t>In certain scenarios, it is desirable to establish multicast states
between two layer-3 adjacent routers without forming a PIM neighborship. between two routers without forming a PIM neighborship.
This can be necessary for various reasons, such as signaling multicast This can be necessary for various reasons, such as signaling multicast
states upstream between multiple PIM domains over a network that is not states upstream between multiple PIM domains over a network that is not
optimized for PIM or does not necessitate PIM Neighbor establishment. optimized for PIM or that does not necessitate PIM neighbor establishment.
For example, in a Bit Index Explicit Replication (BIER) <xref An example is a Bit Index Explicit Replication (BIER) <xref target="RFC827
target="RFC8279"/> networks connecting multiple PIM domains, where PIM 9" format="default"/> network connecting multiple PIM domains, where PIM
Join/Prune messages are tunneled via BIER as specified in <xref Join/Prune messages are tunneled via BIER as specified in <xref target="I-
target="draft-ietf-bier-pim-signaling"/>.</t> D.ietf-bier-pim-signaling" format="default"/>.</t>
<t>A PLI accepts Join/Prune messages from an
<t>A PIM Light Interface (PLI) accepts Join/Prune messages from an
unknown PIM router without requiring a PIM Hello message from the unknown PIM router without requiring a PIM Hello message from the
router. The absence of Hello messages on a PLI means there is no router. The absence of Hello messages on a PLI means there is no
mechanism to discover neighboring PIM routers or their capabilities, nor mechanism to discover neighboring PIM routers or their capabilities or
to execute basic algorithms such as Designated Router (DR) election to execute basic algorithms such as Designated Router (DR) election
<xref target="RFC7761"/>. Consequently, the PIM Light router does not <xref target="RFC7761" format="default"/>. Consequently, the PIM Light rou ter does not
create any general-purpose state for neighboring PIM routers and only create any general-purpose state for neighboring PIM routers and only
processes Join/Prune messages from downstream routers in its multicast processes Join/Prune messages from downstream routers in its multicast
routing table. Processing these Join/Prune messages will introduce routing table. Processing these Join/Prune messages will introduce
multicast states in a PIM Light router.</t> multicast states in a PIM Light router.</t>
<t>Due to these constraints, a PLI should be deployed in very specific <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 scenarios where PIM-SM is not suitable. The applications or the networks
that PLIs are deployed on MUST ensure there is no multicast packet on which PLIs are deployed <bcp14>MUST</bcp14> ensure that there is no
duplication, such as multiple upstream routers sending the same multicast packet duplication, such as multiple upstream routers sending
multicast stream to a single downstream router. As an example the the same multicast stream to a single downstream router. For example,
implementation should ensure that DR election is done on upstream an implementation should ensure that DR election is done on upstream
Redundant PIM routers that are at the edge of the PIM Light Domain to 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 ensure that a single DR forwards the PIM Join message from the receiver
reviver to the Source.</t> to the source.
</t>
<section title="PLI supported Messages"> <section numbered="true" toc="default">
<t>IANA <xref target="iana pim-parameters message-types"/>, lists the
PIM supported message types. 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>
<name>Message Types Supported by PIM Light</name>
<t>The "PIM Message Types" registry <xref target="IANA-PIM-Mess-Types" f
ormat="default"/> lists the
message types supported by PIM. PIM Light only supports the following
message types in that registry:</t>
<ul>
<li>
<t>type 1 (Register)</t> <t>type 1 (Register)</t>
</li>
<li>
<t>type 2 (Register Stop)</t> <t>type 2 (Register Stop)</t>
</li>
<li>
<t>type 3 (Join/Prune)
</t>
</li>
<li>
<t>type 8 (Candidate RP Advertisement)</t> <t>type 8 (Candidate RP Advertisement)</t>
</li>
<t>type 13 (PIM Packed Null-Register)</t> <li>
<t>type 13.0 (PIM Packed Null-Register)</t>
</li>
<li>
<t>type 13.1 (PIM Packed Register-Stop)</t> <t>type 13.1 (PIM Packed Register-Stop)</t>
</li>
<li>
<t>Any future PIM message types that use unicast destination <t>Any future PIM message types where the destination is a unicast I
IP.</t> P address
</list> No other message types are supported for PIM Light and MUST </t>
NOT be process if received on a PLI.</t> </li>
</ul>
<t>No other message types are supported by PIM Light; other message type
s <bcp14>MUST
NOT</bcp14> be processed if received on a PLI.</t>
</section> </section>
<section numbered="true" toc="default" anchor="absence-hello">
<name>Considerations for the Absence of Hello Message</name>
<section title="Absence of Hello Message consideration"> <t>Because Hello messages are not processed in a PIM Light domain, the
<t>In a PIM Light domain, the following considerations should be taken considerations in the subsections below should be taken into account.
into account due to the lack of processing Hello messages.</t> </t>
<section numbered="true" toc="default">
<section title="Join Attribute"> <name>Join Attribute</name>
<t>Since a PLI does not process PIM Hello messages, it also does not
support the join attributes option in PIM Hello as specified in
<xref target="RFC5384"/>. As such, PIM Light is unaware of its
neighbor's capability to process join attributes and it SHOULD NOT
process a join message containing it.</t>
<t>For a PLI to send and process a join attributes there can be two <t>Since a PLI does not use PIM Hello messages, it also does not
cases: <list style="numbers"> support the Join Attribute option in PIM Hello as specified in
<t>It must be configured with appropriate join attribute type <xref target="RFC5384" format="default"/>. As such, PIM Light is unawa
that the PLI is capable of processing as per <xref re of its
target="iana pim-parameters join-attribute-types"/> table.</t> neighbor's capability to process Join Attributes and <bcp14>SHOULD NOT
</bcp14>
send a Join message containing a Join Attribute.</t>
<t>Separate IETF drafts or RFCs may dictate that certain join <t>There are two cases in which a PLI can support a Join Attribute:
attributes are allowed to be used without explicit configuration </t>
<ul spacing="normal"><li><t>The neighbors on the PLI are known via
configuration to be capable of processing the attribute.</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 of the PLI in certain scenarios. The details are left to those
drafts or RFCs.</t> Internet-Drafts and RFCs.</t>
</list></t> </li>
</ul>
</section> </section>
<section numbered="true" toc="default">
<name>DR Election</name>
<section title="DR Election"> <t>Due to the absence of Hello messages, DR election is not
<t>Due to the absence of Hello messages, DR Election is not
supported on a PIM Light router. The network design must ensure DR supported on a PIM Light router. The network design must ensure DR
Election occurs within the PIM domain, assuming the PIM Light domain election occurs within the PIM domain, assuming the PIM Light domain
interconnects PIM domains.</t> interconnects PIM domains.</t>
<t>For instance, in a BIER domain connecting two PIM 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.
<t><figure> If there are redundant PIM routers at the edge of the BIER domain, they
<artwork><![CDATA[ Bier edge router Bier <bcp14>MUST</bcp14> establish PIM adjacency as per <xref target="RFC7761"
edge router (BER) format="default"/> to prevent multicast stream duplication and to ensure DR
|--PIM Domain--|--BIER domain (PLI)--|--PIM domain--| election at the edge of the BIER 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, a PLI For example, DR election
can be used between BIER edge routers solely for multicast state could be between router D and F in the figure below. When the Join
communication and transmit only PIM Join/Prune messages. If there or Prune message arrives from a PIM domain to the downstream BIER
are redundant PIM routers at the edge of the BIER domain, to prevent edge router, it can be forwarded over the BIER tunnel to the
multicast stream duplication, they MUST establish PIM adjacency as upstream BIER edge router only via the DR.</t>
per <xref target="RFC7761"/> 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. When the Join or Prune message
arrives from a PIM domain to the down stream BIER edge router, it
can be forwarded over the BIER tunnel to the upstream BIER edge
router only via the designated router.</t>
</section>
<section title="PIM Assert"> <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 numbered="true" toc="default">
<name>PIM Assert</name>
<t>In scenarios where multiple PIM routers peer over a shared LAN or <t>In scenarios where multiple PIM routers peer over a shared LAN or
a Point-to-Multipoint medium, more than one upstream router may have a point-to-multipoint medium, more than one upstream router may have
valid forwarding state for a packet, potentially causing packet valid forwarding state for a packet, which can potentially cause packe
t
duplication. PIM Assert is used to select a single transmitter when duplication. PIM Assert is used to select a single transmitter when
such duplication is detected. According to <xref target="RFC7761"/> such duplication is detected. According to <xref section="4.6" section
section 4.6, PIM Assert should only be accepted from a known PIM Format="of" target="RFC7761" format="default"/>, PIM Assert should only be accep
ted from a known PIM
neighbor.</t> neighbor.</t>
<t>In PIM Light implementations, care must be taken to avoid <t>In PIM Light implementations, care must be taken to avoid
duplicate streams arriving from multiple upstream PIM Light routers duplicate streams arriving from multiple upstream PIM Light routers
to a single downstream PIM Light router. If network design to a single downstream PIM Light router. If network design
constraints prevent this, the implemented network architecture must constraints prevent this, the implemented network architecture must
take measures to avoid traffic duplication. For example, in a PIM take measures to avoid traffic duplication. For example, in a scenario
Light over a BIER domain scenario, downstream IBBR (Ingress BIER with PIM
Light over a BIER domain, a downstream IBBR (Ingress BIER
Border Router) in a BIER domain can identify the nearest EBBRs Border Router) in a BIER domain can identify the nearest EBBRs
(Egress BIER Border Routers) to the source using the Shortest Path (Egress BIER Border Routers) to the source using the Shortest Path
First (SPF) algorithm with a post-processing as described in <xref First (SPF) algorithm with post-processing as described in Appendix A.
target="draft-ietf-bier-pim-signaling"/> Appendix A.1. If the 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 downstream IBBR identifies two EBBRs, it can select one using a
unique IP selection algorithm, such as choosing the EBBR with the unique IP selection algorithm, such as choosing the EBBR with the
lowest or highest IP address. If the selected EBBR goes offline, 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 downstream router can use the next EBBR based on the IP selection
algorithm, which is beyond the scope of this document.</t> algorithm, which is beyond the scope of this document.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="PLI Configuration"> <name>PLI Configuration</name>
<!-- 3.1 -->
<t>Since a PLI doesn't require PIM Hello Messages and PIM neighbor <t>Since a PLI doesn't require PIM Hello Messages and PIM neighbor
adjacency is not checked for arriving Join/Prune messages, there needs adjacency is not checked for arriving Join/Prune messages, there needs
to be a mechanism to enable PLI on interfaces. If a router supports to be a mechanism to enable PLIs on interfaces.
PIM Light, only when PLI is enabled on an interface, arriving Join/Prune messages not received from a PIM neighbor
Join/Prune messages MUST be processed, otherwise they MUST be dropped. <bcp14>MUST</bcp14> be dropped unless PLI is enabled on the interface.
While on some logical interfaces PLI maybe enabled automatically or In some cases, a PLI may be enabled
via an underlying mechanism, as an example the logical interface automatically via an underlying mechanism on a logical interface. For
connecting two or more BIER edge routers in a BIER subdomain <xref example, in a BIER domain, a logical interface can connect two or more
target="draft-ietf-bier-pim-signaling"/>.</t> BIER edge routers as per <xref target="I-D.ietf-bier-pim-signaling"
format="default"/>).</t>
</section> </section>
<section numbered="true" toc="default">
<name>Failures in PLR Domain</name>
<section title="Failures in PLR domain"> <t>Because Hello messages are not processed on the PLI, PLI
<t>Because the Hello messages are not processed on the PLI, PIM Light failures may not be discovered in a PIM Light domain, and
Interface failures may not be discovered in a PIM Light domain and
multicast routes will not be pruned toward the source on the PIM Light multicast routes will not be pruned toward the source on the PIM Light
domain, leaving the upstream routers continuously sending multicast domain. This results in the upstream routers continuously sending multic ast
streams until the outgoing interface (OIF) expires.</t> streams until the outgoing interface (OIF) expires.</t>
<t>Other protocols can be used to detect these failures in the PIM <t>Other protocols can be used to detect these failures in the PIM
Light domain and they can be implementation specific. As an example, Light domain, and they can be implementation specific. As an example,
the interface that PIM Light is configured on can be protected via the interface on which PIM Light is configured can be protected via
Bidirectional Forwarding Detection (BFD) or similar technology. If BFD Bidirectional Forwarding Detection (BFD) or similar technology. If BFD
to the far-end PLI goes down, and the PIM Light Router is upstream and to the far-end PLI goes down and the PIM Light router is upstream and
has an OIF for a multicast route &lt;S,G&gt;, PIM must remove that PLI has an OIF for a multicast route (S,G), PIM must remove that PLI
from its OIF list.</t> from its OIF list.</t>
<t><figure> <t>In another example, the PLI is configured automatically
<artwork><![CDATA[ UBER DBER between the BIER Edge Routers (BERs) as in the figure below. When the Do
|--PIM Domain--|--BIER domain (PLI)--|--PIM domain--| wnstream BIER Edge
Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--host Router (DBER) is no longer reachable on the Upstream BIER Edge Router
<--Prune <S,G> <failure on D>]]></artwork> (UBER), the UBER (which is also a PIM Light router) can prune the
</figure></t> (S,G) advertised toward the source on the PIM domain to stop the
<t>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
&lt;S,G&gt; advertised toward the source on the PIM domain to stop the
transmission of the multicast stream.</t> 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>
<section numbered="true" toc="default">
<name>Reliable Transport Mechanism for PIM Light</name>
<section title="Reliable Transport Mechanism for PIM LIGHT"> <t><xref target="RFC6559" format="default"/> defines a reliable transport
<t><xref target="RFC6559"/> defines a reliable transport mechanism for mechanism called
PIM transmission of Join/Prune messages, using either TCP or SCTP as PIM Over Reliable Transport (PORT) for PIM transmission of Join/Prune mes
transport protocol. For TCP, PIM over reliable transport (PORT) uses sages,
port 8471 which is assigned by IANA. SCTP is explained in <xref using either TCP or SCTP as the transport protocol. Both TCP and SCTP use
target="RFC9260"/>, and it is used as a second option for PORT. <xref destination port number 8471. SCTP is explained in <xref target="RFC9260"
target="RFC6559"/> mentions that when a router is configured to use format="default"/> and
PIM over TCP on a given interface, it MUST include the is used as a second option for PORT. <xref target="RFC6559" format="defau
PIM-over-TCP-Capable Hello Option in its Hello messages for that lt"/> mentions that when
interface. The same is true for SCTP and the router must include a router is configured to use PIM over TCP on a given interface, it
PIM-over-SCTP-Capable Hello Option in its Hello messsage on that <bcp14>MUST</bcp14> include the PIM-over-TCP-Capable Hello Option in its
interface.</t> Hello
messages for that interface. The same is true for SCTP; the router
<bcp14>MUST</bcp14> include the PIM-over-SCTP-Capable Hello Option in its
Hello messages
on that interface.
</t>
<t>These Hello options contain a Connection ID which is an IPv4 or <t>These Hello options contain a Connection ID, which is an IPv4 or
IPv6 address used to establish the SCTP or TCP connection. For PORT IPv6 address used to establish the SCTP or TCP connection. For PORT
using TCP, the connection ID is used for determining which peer is using TCP, the Connection ID is used to determine which peer is
doing an active transport open to the neighbor and which peer is doing doing an active transport open to the neighbor and which peer is doing
passive transport open, as per section 4 of <xref passive transport open, as per <xref section="4" sectionFormat="of"
target="RFC6559"/></t> target="RFC6559" format="default"/>.
<t>When the router is using SCTP, the Connection ID IP address When the router is using SCTP, the Connection ID is not used to
comparison need not be done since the SCTP protocol can handle call determine the active and passive peer since SCTP can handle call
collision.</t> collision.
</t>
<t>PIM Light lacks Hello messages, the PLI can be configured with the <t>Because PIM Light lacks Hello messages, the PLI can be configured with
Connection ID IPv4 or IPv6 addresses used to establish the SCTP or TCP the
connection. For PIM Light using TCP PORT option each end of the PLI Connection ID (i.e., the IPv4 or IPv6 address used to establish the SCTP
must be explicitly and correct configured as being active transport or TCP
open or passive transport open to ensure handle call collision is connection). For PIM Light using the TCP PORT option, each end of the PL
I
must be explicitly and correctly configured as being either active trans
port
open or passive transport open to ensure that call collision is
avoided.</t> avoided.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="PIM Variants not supported"> <name>PIM Variants Not Supported</name>
<t>The following PIM variants are not supported with PIM Light and not <t>The following PIM variants are not supported with PIM Light and not
covered by this document:</t> covered by this document:</t>
<ul spacing="normal">
<t><list style="numbers"> <li>
<t>Protocol Independent Multicast - Dense Mode (PIM-DM)<xref <t>PIM - Dense Mode (PIM-DM) <xref target="RFC3973" format="default"
target="RFC3973"> </xref></t> /></t>
</li>
<t>Bidirectional Protocol Independent Multicast (BIDIR-PIM) <xref <li>
target="RFC5015"/></t> <t>Bidirectional PIM (BIDIR-PIM) <xref target="RFC5015" format="defa
</list></t> ult"/></t>
</li>
</ul>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="IANA Considerations"> <name>IANA Considerations</name>
<!-- 7 --> <t>This document has no IANA actions.</t>
<t>There are no new IANA considerations for this document.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<!-- 8 -->
<t>Since PIM Light does not require PIM Hello messages and does not <t>Since PIM Light does not require PIM Hello messages and does not
verify PIM neighbor adjacency for incoming Join/Prune messages, it is verify PIM neighbor adjacency for incoming Join/Prune messages, for securi
crucial for security reasons, that the implementation ensures only ty reasons, it is
crucial that implementations ensure that only
Join/Prune messages arriving at a configured PLI are processed. Any Join/Prune messages arriving at a configured PLI are processed. Any
Join/Prune messages received on an interface that is not configured as a Join/Prune messages received on an interface that is not configured as a
PLI MUST be discarded and not processed. Additionally, as a secondary PLI <bcp14>MUST</bcp14> be discarded and not processed. Additionally, as a
line of defense, route policies SHOULD be implemented to process only secondary
line of defense, route policies <bcp14>SHOULD</bcp14> be implemented to pr
ocess only
the Join/Prune messages associated with the desired (S,G) pairs, while the Join/Prune messages associated with the desired (S,G) pairs, while
all other (S,G) pairs MUST be discarded and not processed.</t> all other (S,G) pairs <bcp14>MUST</bcp14> be discarded and not processed.< /t>
<t>Furthermore, because PIM Light can be used for signaling <t>Furthermore, because PIM Light can be used for signaling
Source-Specific and Sparse Mode Join/Prune messages, the security PIM-SM Join/Prune messages, the security considerations outlined in
considerations outlined in <xref target="RFC7761"/> and <xref <xref target="RFC7761" format="default"/> and <xref target="RFC4607"
target="RFC4607"/> SHOULD be considered where appropriate.</t> format="default"/> <bcp14>SHOULD</bcp14> be considered where
appropriate.</t>
<t>In section 6.1.1 of <xref target="RFC7761"/>, only forged join/prune <t>Per <xref section="6.1.1" sectionFormat="of" target="RFC7761"/>, only f
message should be considered as a potential attack vector, as PIM Light orged Join/Prune
does not process Hello or Assert messages. In addition, as detailed in messages should be considered as a potential attack vector, as PIM Light
Section 6.3, the authentication mechanisms described in <xref does not process Hello or Assert messages. In addition, as detailed in <xr
target="RFC5796"/> can be applied to PIM Light via IPsec Encapsulating ef section="6.3" sectionFormat="of" target="RFC7761"/>, the authentication mecha
nisms described in <xref target="RFC5796" format="default"/> can be applied to P
IM Light via IPsec Encapsulating
Security Payload (ESP) or, optionally, the Authentication Header Security Payload (ESP) or, optionally, the Authentication Header
(AH).</t> (AH).</t>
</section> </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> </middle>
<back> <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>
<reference anchor="RFC7761">
<front>
<title>B.Fenner, M.Handley, H. Holbrook, I. Kouvelas, R. Parekh,
Z.Zhang "PIM Sparse Mode"</title>
<author>
<organization/>
</author>
<date month="March" year="2016"/>
</front>
</reference>
<reference anchor="RFC5384">
<front>
<title>A. Boers, I. Wijnands, E. Rosen "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-par
ameters.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-par
ameters.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> <displayreference target="I-D.ietf-bier-pim-signaling" to="BIER-PIM"/>
<organization/>
</author>
<date/>
</front>
</reference>
<reference anchor="RFC5015"> <references>
<front> <name>References</name>
<title>M. Handley, I. Kouvelas, T. Speakman, L. Vicisano <references>
"Bidirectional Protocol Independent Multicast"</title> <name>Normative References</name>
<author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<organization/> 19.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
74.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.77
61.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.53
84.xml"/>
<date/> <reference anchor="IANA-PIM-Mess-Types" target="https://www.iana.org/ass
</front> ignments/pim-parameters">
</reference> <front>
<title>PIM Message Types</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<reference anchor="RFC8279"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.65
<front> 59.xml"/>
<title>Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T. and S. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.46
Aldrin, "Multicast using Bit Index Explicit Replication"</title> 07.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.57
96.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.50
15.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
79.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
60.xml"/>
<author> </references>
<organization/> <references>
</author> <name>Informative References</name>
<date month="October" year="2016"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.39
</front> 73.xml"/>
</reference>
<reference anchor="RFC9260"> <!-- I-D.ietf-bier-pim-signaling.xml - used long way because missing "Ed" -->
<front>
<title>R. Stewart, M. Tuxen, K. Nielsen, "Stream Control
Transmission Protocol"</title>
<author> <reference anchor="I-D.ietf-bier-pim-signaling" target="https://datatracker.ietf
<organization/> .org/doc/html/draft-ietf-bier-pim-signaling-12">
</author> <front>
<title>PIM Signaling Through BIER 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>
<date month="June" year="2022"/> </references>
</front>
</reference>
</references> </references>
<references title="Informative References"> <section numbered="false" toc="default">
<reference anchor="RFC3973"> <name>Acknowledgments</name>
<front> <t>The authors would like to thank <contact fullname="Zheng (Sandy) Zhang"
<title>A. Adams, J. Nicholas, W. Siadak, "Protocol Independent />
Multicast - Dense Mode"</title> and <contact fullname="Tanmoy Kundu"/> for their suggestions and
contributions to this document.</t>
<author> </section>
<organization/>
</author>
<date/>
</front>
</reference>
<reference anchor="draft-ietf-bier-pim-signaling">
<front>
<title>H.Bidgoli, F.XU, J. Kotalwar, I. Wijnands, M.Mishra, Z.
Zhang, "PIM Signaling Through BIER Core"</title>
<author>
<organization/>
</author>
<date month="July" year="2021"/>
</front>
</reference>
</references>
</back> </back>
</rfc> </rfc>
<!-- generated from file C:\Users\hbidgoli\Downloads\draft-ietf-bier-pim-signali ng-08.nroff with nroff2xml 0.1.0 by Tomek Mrugalski -->
 End of changes. 117 change blocks. 
488 lines changed or deleted 371 lines changed or added

This html diff was produced by rfcdiff 1.48.