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>
<phone/>
<facsimile/>
<email>zzhang@juniper.com</email> <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>
<country>United States of America</country>
</postal>
<email>michael.mcbride@futurewei.com</email>
</address>
</author>
<date month="February" year="2025"/>
<region/> <area>RTG</area>
<workgroup>pim</workgroup>
<code/> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<country>USA</country> <keyword>example</keyword>
</postal>
<phone/> <!-- [rfced] Abstract
<facsimile/> a) We updated the text starting with "which does not..." as follows to improve
readability; please review and let us know any concerns.
<email>michael.mcbride@futurewei.com</email> 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.
<uri/> Perhaps:
</address> This document specifies Protocol Independent Multicast Light (PIM Light)
</author> 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 connec
t two or
more PIM domains.
<date day="05" month="December" year="2024"/> 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> <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 <!-- [rfced] This is a sentence fragment. How may we update to make a complete
between two layer-3 adjacent routers without forming a PIM neighborship. 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 adjacent Layer 3 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 For example, in a Bit Index Explicit Replication (BIER) <xref target="RFC8
target="RFC8279"/> networks connecting multiple PIM domains, where PIM 279" 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>
<!-- [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 <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 mul ticast packet
duplication, such as multiple upstream routers sending the same duplication, such as multiple upstream routers sending the same
multicast stream to a single downstream router. As an example the multicast stream to a single downstream router. For example, an
implementation should ensure that DR election is done on upstream 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 a single DR to forward the PIM Join message from
reviver to the Source.</t> reviver to the source.</t>
<section numbered="true" toc="default">
<section title="PLI supported Messages"> <!-- [rfced] FYI - We reordered the list in Section 3.1 by type number as only
<t>IANA <xref target="iana pim-parameters message-types"/>, lists the one was out of order.
PIM supported message types. PIM Light only supports the following -->
message types from the table "PIM Message Types"</t>
<t><list style="numbers"> <!-- [rfced] Is the text starting with "from the..." needed here? Other
<t>type 3 (Join/Prune) from the ALL-PIM-ROUTERS message types entries in the list do not have such notes, and in the IANA registry
listed in <xref target="RFC7761"/>.</t> (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/.
<t>type 1 (Register)</t> Original:
1. type 3 (Join/Prune) from the ALL-PIM-ROUTERS message types listed
in [RFC7761].
<t>type 2 (Register Stop)</t> Current:
* type 3 (Join/Prune) (Note that this type is from the ALL-PIM-
ROUTERS message types listed in [RFC7761].)
<t>type 8 (Candidate RP Advertisement)</t> Perhaps:
* type 3 (Join/Prune)
-->
<t>type 13 (PIM Packed Null-Register)</t> <!-- [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-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>
</li>
<li>
<t>type 2 (Register Stop)</t>
</li>
<li>
<t>type 3 (Join/Prune) (Note that this type is from the ALL-PIM-ROUT
ERS message types
listed in <xref 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> <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 <t>Any future PIM message types that use unicast destination
IP.</t> IP</t>
</list> No other message types are supported for PIM Light and MUST </li>
NOT be process if received on a PLI.</t> </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">
<name>Join Attribute</name>
<section title="Join Attribute"> <!-- [rfced] Will readers know what both instances of "it" refer to in the
<t>Since a PLI does not process PIM Hello messages, it also does not text "it SHOULD NOT process a join message containing it"?
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 Original:
cases: <list style="numbers"> As such, PIM Light is unaware of its neighbor's
<t>It must be configured with appropriate join attribute type capability to process join attributes and it SHOULD NOT process a
that the PLI is capable of processing as per <xref join message containing it.
target="iana pim-parameters join-attribute-types"/> table.</t>
<t>Separate IETF drafts or RFCs may dictate that certain join 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 attribute option in PIM Hello as specified in
<xref target="RFC5384" format="default"/>. As such, PIM Light is unawa
re of its
neighbor's capability to process join attributes, and it <bcp14>SHOULD
NOT</bcp14>
process a Join message containing it.</t>
<t>There are two cases in which a PLI can send and process a join attri
bute:
</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 Attribu
te Types" registry <xref 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 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>
<!-- [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.
-->
<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><figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ Bier edge router Bier Bier edge router Bier edge router
edge router (BER) |--PIM domain--|--BIER domain (PLI)--|--PIM domain--|
|--PIM Domain--|--BIER domain (PLI)--|--PIM domain--| Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--Host
Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--host | PIM Adj| | | |PIM Adj |
| PIM Adj| | | |PIM Adj | |------------( E )-------| |-------( F )------------|
|------------( E )-------| |-------( F )------------| (DR Election)
(DR Election)]]></artwork> ]]></artwork>
</figure></t>
<t>For instance, in a BIER domain connecting two PIM networks, a PLI <t>For instance, in a BIER domain connecting two PIM networks, a PLI
can be used between BIER edge routers solely for multicast state can be used between BIER edge routers solely for multicast state
communication and transmit only PIM Join/Prune messages. If there communication and transmit only PIM Join/Prune messages. If there
are redundant PIM routers at the edge of the BIER domain, to prevent are redundant PIM routers at the edge of the BIER domain, to prevent
multicast stream duplication, they MUST establish PIM adjacency as multicast stream duplication, they <bcp14>MUST</bcp14> establish PIM a
per <xref target="RFC7761"/> to ensure DR election at the edge of djacency as
per <xref target="RFC7761" format="default"/> to ensure DR election at
the edge of
BIER domain. An example DR election could be DR election between BIER domain. An example DR election could be DR election between
router D and F in above figure. When the Join or Prune message router D and F in the figure above. When the Join or Prune message
arrives from a PIM domain to the down stream BIER edge router, it arrives from a PIM domain to the downstream BIER edge router, it
can be forwarded over the BIER tunnel to the upstream BIER edge can be forwarded over the BIER tunnel to the upstream BIER edge
router only via the designated router.</t> router only via the DR.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="PIM Assert"> <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">
<name>PLI Configuration</name>
<section title="PLI Configuration"> <!-- [rfced] We updated this sentence as follows; please review and let us
<!-- 3.1 --> 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]).
-->
-&gt;
<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. If a router supports
PIM Light, only when PLI is enabled on an interface, arriving PIM Light, arriving Join/Prune messages <bcp14>MUST</bcp14> be
Join/Prune messages MUST be processed, otherwise they MUST be dropped. processed only when a PLI is enabled on an interface; otherwise, they
While on some logical interfaces PLI maybe enabled automatically or <bcp14>MUST</bcp14> be dropped. A PLI may be enabled automatically or
via an underlying mechanism, as an example the logical interface via an underlying mechanism on some logical interfaces (for example,
connecting two or more BIER edge routers in a BIER subdomain <xref the logical interface connecting two or more BIER edge routers in a
target="draft-ietf-bier-pim-signaling"/>.</t> BIER subdomain <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 &lt;S,G&gt;, PIM must remove that PLI
from its OIF list.</t> from its OIF list.</t>
<t><figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ UBER DBER UBER DBER
|--PIM Domain--|--BIER domain (PLI)--|--PIM domain--| |--PIM domain--|--BIER domain (PLI)--|--PIM domain--|
Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--host Source--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--Host
<--Prune <S,G> <failure on D>]]></artwork> <--Prune <S,G> <failure on D>
</figure></t> ]]></artwork>
<t>In another example, the PLI is configured automatically
<t>In another example, where the PLI is configured automatically between the BIER Edge Routers (BERs). When the Downstream BIER Edge
between the BIER Edge Routers (BER), when the downstream BIER Edge Router (DBER) is no longer reachable on the Upstream BIER Edge Router
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
(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 &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>
</section> </section>
<section numbered="true" toc="default">
<name>Reliable Transport Mechanism for PIM Light</name>
<section title="Reliable Transport Mechanism for PIM LIGHT"> <!-- [rfced] We confirmed that port 8471 is correct in this sentence per the
<t><xref target="RFC6559"/> defines a reliable transport mechanism for registry at https://www.iana.org/assignments/service-names-port-numbers. In the
PIM transmission of Join/Prune messages, using either TCP or SCTP as registry, we see that port 8471 is also for PORT with SCTP as the transport
transport protocol. For TCP, PIM over reliable transport (PORT) uses protocol. This sentence just mentions TCP, though SCTP is mentioned in
port 8471 which is assigned by IANA. SCTP is explained in <xref the next sentence. Are any updates needed?
target="RFC9260"/>, and it is used as a second option for PORT. <xref
target="RFC6559"/> mentions that when a router is configured to use Original:
PIM over TCP on a given interface, it MUST include the 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" format="default"/> defines a reliable transpor
t mechanism for
PIM transmission of Join/Prune messages, using either TCP or SCTP as the
transport protocol. For TCP, PIM Over Reliable Transport (PORT) uses
port 8471, which was assigned by IANA. SCTP is explained in <xref target
="RFC9260" format="default"/> and is used as a second option for PORT. <xref tar
get="RFC6559" format="default"/> mentions that when a router is configured to us
e
PIM over TCP on a given interface, it <bcp14>MUST</bcp14> include the
PIM-over-TCP-Capable Hello Option in its Hello messages for that PIM-over-TCP-Capable Hello Option in its Hello messages for that
interface. The same is true for SCTP and the router must include interface. The same is true for SCTP; the router must include the
PIM-over-SCTP-Capable Hello Option in its Hello messsage on that PIM-over-SCTP-Capable Hello Option in its Hello message on that
interface.</t> interface.</t>
<t>These Hello options contain a Connection ID which is an IPv4 or <!-- [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, 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" targ
target="RFC6559"/></t> et="RFC6559" format="default"/>.</t>
<t>When the router is using SCTP, the Connection ID IP address <t>When the router is using SCTP, the Connection ID IP address
comparison need not be done since the SCTP protocol can handle call comparison need not be done since SCTP can handle call
collision.</t> collision.</t>
<t>PIM Light lacks Hello messages, the PLI can be configured with the <!-- [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 ID IPv4 or IPv6 addresses used to establish the SCTP or TCP
connection. For PIM Light using TCP PORT option each end of the PLI connection. For PIM Light using the TCP PORT option, each end of the PLI
must be explicitly and correct configured as being active transport must be explicitly and correctly configured as being either active trans
open or passive transport open to ensure handle call collision is 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">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section numbered="true" toc="default">
<name>Security Considerations</name>
<section title="IANA Considerations"> <!-- [rfced] Should "Source-Specific and Sparse Mode Join/Prune messages" here
<!-- 7 --> be updated to "PIM-SSM and PIM-SM Join/Prune messages"?
<t>There are no new IANA considerations for this document.</t> Original:
</section> 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.
<section title="Security Considerations"> Perhaps:
<!-- 8 --> 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.
-->
-&gt;
<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 Source-Specific and Sparse Mode Join/Prune messages, the security
considerations outlined in <xref target="RFC7761"/> and <xref considerations outlined in <xref target="RFC7761" format="default"/> and <
target="RFC4607"/> SHOULD be considered where appropriate.</t> xref target="RFC4607" format="default"/> <bcp14>SHOULD</bcp14> be considered whe
re 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"> <displayreference target="I-D.ietf-bier-pim-signaling" to="BIER-PIM"/>
<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/> <references>
</front> <name>References</name>
</reference> <references>
<name>Normative References</name>
<reference anchor="RFC4607"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<front> 19.xml"/>
<title>H. Holbrook, B. Cain "Source-Specific Multicast for <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
IP"</title> 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"/>
<author> <reference anchor="IANA-PIM-Mess-Types" target="https://www.iana.org/ass
<organization/> ignments/pim-parameters">
</author> <front>
<title>PIM Message Types</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<date/> <reference anchor="IANA-PIM-Attr-Types" target="https://www.iana.org/ass
</front> ignments/pim-parameters">
</reference> <front>
<title>PIM Join Attribute Types</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<reference anchor="RFC5796"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.65
<front> 59.xml"/>
<title>W. Atwood, S. Islam, M. Siami "Authentication and <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.46
Confidentiality in PIM-SM"</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/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.39
</front> 73.xml"/>
</reference>
<reference anchor="RFC5015"> <!-- I-D.ietf-bier-pim-signaling.xml - used long way because missing "Ed" -->
<front>
<title>M. Handley, I. Kouvelas, T. Speakman, L. Vicisano
"Bidirectional Protocol Independent Multicast"</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/> </references>
</front> </references>
</reference>
<reference anchor="RFC8279"> <section numbered="false" toc="default">
<front> <name>Acknowledgments</name>
<title>Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T. and S. <t>The authors would like to thank <contact fullname="Zheng (Sandy) Zhang"
Aldrin, "Multicast using Bit Index Explicit Replication"</title> />
and <contact fullname="Tanmoy Kundu"/> for their suggestions and
contributions to this document.</t>
</section>
<author> <!-- [rfced] Terminology
<organization/>
</author>
<date month="October" year="2016"/> a) These terms are used inconsistently throughout the text. Should these be
</front> uniform? If so, please let us know which form is preferred.
</reference>
<reference anchor="RFC9260"> DR Election vs. DR election
<front> <S,G> vs. (S,G)
<title>R. Stewart, M. Tuxen, K. Nielsen, "Stream Control
Transmission Protocol"</title>
<author> b) We also note inconsistencies in the terms listed below. We chose the form
<organization/> on the right. Please let us know any objections.
</author>
<date month="June" year="2022"/> PIM Light Router vs. PIM Light router
</front> PIM Light Domain vs. PIM Light domain
</reference> connection ID vs Connection ID
</references> Source vs. source
join message vs. Join message
join/prune message vs. Join/Prune message
<references title="Informative References"> c) Should "join attribute" be capitalized per usage in RFC 5384?
<reference anchor="RFC3973">
<front>
<title>A. Adams, J. Nicholas, W. Siadak, "Protocol Independent
Multicast - Dense Mode"</title>
<author> d) Article usage (e.g., "a" and "the") with "PIM Light Interface" and "PLI"
<organization/> was mixed. We added articles in some instances. Please review for
</author> correctness.
<date/> -->
</front>
</reference>
<reference anchor="draft-ietf-bier-pim-signaling"> <!-- [rfced] Please review the "Inclusive Language" portion of the online
<front> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
<title>H.Bidgoli, F.XU, J. Kotalwar, I. Wijnands, M.Mishra, Z. and let us know if any changes are needed. Updates of this nature typically
Zhang, "PIM Signaling Through BIER Core"</title> result in more precise language, which is helpful for readers.
<author> Note that our script did not flag any words in particular, but this should
<organization/> still be reviewed as a best practice.
</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. 147 change blocks. 
451 lines changed or deleted 700 lines changed or added

This html diff was produced by rfcdiff 1.48.