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 " "> | |||
<organization>Nokia</organization> | <!ENTITY zwsp "​"> | |||
<!ENTITY nbhy "‑"> | ||||
<!ENTITY wj "⁠"> | ||||
]> | ||||
<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 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]). | ||||
--> | ||||
-> | ||||
<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 <S,G>, 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> | <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 | ||||
<S,G> advertised toward the source on the PIM domain to stop the | <S,G> 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. | ||||
--> | ||||
-> | ||||
<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 <Zhang Zheng> 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. |