rfc9739v1.txt		rfc9739.txt
	skipping to change at line 115 ¶		skipping to change at line 115 ¶
	3. PIM Light Interface		3. PIM Light Interface
	Section 4.3.1 of [RFC7761] describes PIM neighbor discovery via Hello		Section 4.3.1 of [RFC7761] describes PIM neighbor discovery via Hello
	messages. Section 4.5 of [RFC7761] notes that if a router receives a		messages. Section 4.5 of [RFC7761] notes that if a router receives a
	Join/Prune message from a particular IP source address and it has not		Join/Prune message from a particular IP source address and it has not
	seen a PIM Hello message from that source address, then the Join/		seen a PIM Hello message from that source address, then the Join/
	Prune message SHOULD be discarded without further processing.		Prune message SHOULD be discarded without further processing.
	In certain scenarios, it is desirable to establish multicast states		In certain scenarios, it is desirable to establish multicast states
	between two adjacent Layer 3 routers without forming a PIM		between two routers without forming a PIM neighborship. This can be
	neighborship. This can be necessary for various reasons, such as		necessary for various reasons, such as signaling multicast states
	signaling multicast states upstream between multiple PIM domains over		upstream between multiple PIM domains over a network that is not
	a network that is not optimized for PIM or that does not necessitate		optimized for PIM or that does not necessitate PIM neighbor
	PIM neighbor establishment. For example, in a Bit Index Explicit		establishment. An example is a Bit Index Explicit Replication (BIER)
	Replication (BIER) [RFC8279] network connecting multiple PIM domains,		[RFC8279] network connecting multiple PIM domains, where PIM Join/
	where PIM Join/Prune messages are tunneled via BIER as specified in		Prune messages are tunneled via BIER as specified in [BIER-PIM].
	[BIER-PIM].
	A PLI accepts Join/Prune messages from an unknown PIM router without		A PLI accepts Join/Prune messages from an unknown PIM router without
	requiring a PIM Hello message from the router. The absence of Hello		requiring a PIM Hello message from the router. The absence of Hello
	messages on a PLI means there is no mechanism to discover neighboring		messages on a PLI means there is no mechanism to discover neighboring
	PIM routers or their capabilities or to execute basic algorithms such		PIM routers or their capabilities or to execute basic algorithms such
	as Designated Router (DR) election [RFC7761]. Consequently, the PIM		as Designated Router (DR) election [RFC7761]. Consequently, the PIM
	Light router does not create any general-purpose state for		Light router does not create any general-purpose state for
	neighboring PIM routers and only processes Join/Prune messages from		neighboring PIM routers and only processes Join/Prune messages from
	downstream routers in its multicast routing table. Processing these		downstream routers in its multicast routing table. Processing these
	Join/Prune messages will introduce multicast states in a PIM Light		Join/Prune messages will introduce multicast states in a PIM Light
	router.		router.
	Due to these constraints, a PLI should be deployed in very specific		Due to these constraints, a PLI should be deployed in very specific
	scenarios where PIM-SM is not suitable. The applications or the		scenarios where PIM-SM is not suitable. The applications or the
	networks on which PLIs are deployed MUST ensure that there is no		networks on which PLIs are deployed MUST ensure that there is no
	multicast packet duplication, such as multiple upstream routers		multicast packet duplication, such as multiple upstream routers
	sending the same multicast stream to a single downstream router. For		sending the same multicast stream to a single downstream router. For
	example, an implementation should ensure that DR election is done on		example, an implementation should ensure that DR election is done on
	upstream redundant PIM routers that are at the edge of the PIM Light		upstream redundant PIM routers that are at the edge of the PIM Light
	domain to ensure a single DR to forward the PIM Join message from		domain to ensure that a single DR forwards the PIM Join message from
	reviver to the source.		the receiver to the source.
	3.1. Message Types Supported by PIM Light		3.1. Message Types Supported by PIM Light
	The "PIM Message Types" registry [IANA-PIM-Mess-Types] lists the		The "PIM Message Types" registry [IANA-PIM-Mess-Types] lists the
	message types supported by PIM. PIM Light only supports the		message types supported by PIM. PIM Light only supports the
	following message types in that registry:		following message types in that registry:
	* type 1 (Register)		* type 1 (Register)
	* type 2 (Register Stop)		* type 2 (Register Stop)
	* type 3 (Join/Prune) (Note that this type is from the ALL-PIM-		* type 3 (Join/Prune)
	ROUTERS message types listed in [RFC7761].)
	* type 8 (Candidate RP Advertisement)		* type 8 (Candidate RP Advertisement)
	* type 13 (PIM Packed Null-Register)		* type 13.0 (PIM Packed Null-Register)
	* type 13.1 (PIM Packed Register-Stop)		* type 13.1 (PIM Packed Register-Stop)
	* Any future PIM message types that use unicast destination IP		* Any future PIM message types where the destination is a unicast IP
			address
	No other message types are supported by PIM Light; other message		No other message types are supported by PIM Light; other message
	types MUST NOT be processed if received on a PLI.		types MUST NOT be processed if received on a PLI.
	3.2. Considerations for the Absence of Hello Message		3.2. Considerations for the Absence of Hello Message
	Because Hello messages are not processed in a PIM Light domain, the		Because Hello messages are not processed in a PIM Light domain, the
	considerations in the subsections below should be taken into account.		considerations in the subsections below should be taken into account.
	3.2.1. Join Attribute		3.2.1. Join Attribute
	Since a PLI does not process PIM Hello messages, it also does not		Since a PLI does not use PIM Hello messages, it also does not support
	support the join attribute option in PIM Hello as specified in		the Join Attribute option in PIM Hello as specified in [RFC5384]. As
	[RFC5384]. As such, PIM Light is unaware of its neighbor's		such, PIM Light is unaware of its neighbor's capability to process
	capability to process join attributes, and it SHOULD NOT process a		Join Attributes and SHOULD NOT send a Join message containing a Join
	Join message containing it.		Attribute.
	There are two cases in which a PLI can send and process a join		There are two cases in which a PLI can support a Join Attribute:
	attribute:
	* The join attribute must be configured with an appropriate join		* The neighbors on the PLI are known via configuration to be capable
	attribute type that the PLI is capable of processing as per the		of processing the attribute.
	"PIM Join Attribute Types" registry [IANA-PIM-Attr-Types].
	* Internet-Drafts and RFCs may dictate that certain join attributes		* Internet-Drafts and RFCs may dictate that certain Join Attributes
	are allowed to be used without explicit configuration of the PLI		are allowed to be used without explicit configuration of the PLI
	in certain scenarios. The details are left to those Internet-		in certain scenarios. The details are left to those Internet-
	Drafts and RFCs.		Drafts and RFCs.
	3.2.2. DR Election		3.2.2. DR Election
	Due to the absence of Hello messages, DR Election is not supported on		Due to the absence of Hello messages, DR election is not supported on
	a PIM Light router. The network design must ensure DR Election		a PIM Light router. The network design must ensure DR election
	occurs within the PIM domain, assuming the PIM Light domain		occurs within the PIM domain, assuming the PIM Light domain
	interconnects PIM domains.		interconnects PIM domains.
			For instance, in a BIER domain connecting two PIM domains as in the
			figure below, a PLI can be used between BIER edge routers solely for
			multicast state communication and transmit only PIM Join/Prune
			messages. 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. For example, DR election could be between router D
			and F in the figure below. When the Join or Prune message arrives
			from a PIM domain to the downstream BIER edge router, it can be
			forwarded over the BIER tunnel to the upstream BIER edge router only
			via the DR.
	Bier edge router Bier edge router		Bier edge router Bier edge router
	|--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)
	For instance, in a BIER domain connecting two PIM networks, a PLI can
	be used between BIER edge routers solely for multicast state
	communication and transmit only PIM Join/Prune messages. If there
	are redundant PIM routers at the edge of the BIER domain, to prevent
	multicast stream duplication, they MUST establish PIM adjacency as
	per [RFC7761] to ensure DR election at the edge of BIER domain. An
	example DR election could be DR election between router D and F in
	the figure above. When the Join or Prune message arrives from a PIM
	domain to the downstream BIER edge router, it can be forwarded over
	the BIER tunnel to the upstream BIER edge router only via the DR.
	3.2.3. PIM Assert		3.2.3. PIM Assert
	In scenarios where multiple PIM routers peer over a shared LAN or a		In scenarios where multiple PIM routers peer over a shared LAN or a
	point-to-multipoint medium, more than one upstream router may have		point-to-multipoint medium, more than one upstream router may have
	valid forwarding state for a packet, which can potentially cause		valid forwarding state for a packet, which can potentially cause
	packet duplication. PIM Assert is used to select a single		packet duplication. PIM Assert is used to select a single
	transmitter when such duplication is detected. According to		transmitter when such duplication is detected. According to
	Section 4.6 of [RFC7761], PIM Assert should only be accepted from a		Section 4.6 of [RFC7761], PIM Assert should only be accepted from a
	known PIM neighbor.		known PIM neighbor.
	skipping to change at line 248 ¶		skipping to change at line 246 ¶
	the downstream IBBR identifies two EBBRs, it can select one using a		the 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.		algorithm, which is beyond the scope of this document.
	3.3. PLI Configuration		3.3. PLI Configuration
	Since a PLI doesn't require PIM Hello Messages and PIM neighbor		Since a PLI doesn't require PIM Hello Messages and PIM neighbor
	adjacency is not checked for arriving Join/Prune messages, there		adjacency is not checked for arriving Join/Prune messages, there
	needs to be a mechanism to enable PLIs on interfaces. If a router		needs to be a mechanism to enable PLIs on interfaces. Join/Prune
	supports PIM Light, arriving Join/Prune messages MUST be processed		messages not received from a PIM neighbor MUST be dropped unless PLI
	only when a PLI is enabled on an interface; otherwise, they MUST be		is enabled on the interface. In some cases, a PLI may be enabled
	dropped. A PLI may be enabled automatically or via an underlying		automatically via an underlying mechanism on a logical interface.
	mechanism on some logical interfaces (for example, the logical		For example, in a BIER domain, a logical interface can connect two or
	interface connecting two or more BIER edge routers in a BIER		more BIER edge routers as per [BIER-PIM]).
	subdomain [BIER-PIM]).
	3.4. Failures in PLR Domain		3.4. Failures in PLR Domain
	Because Hello messages are not processed on the PLI, PLI failures may		Because Hello messages are not processed on the PLI, PLI failures may
	not be discovered in a PIM Light domain, and multicast routes will		not be discovered in a PIM Light domain, and multicast routes will
	not be pruned toward the source on the PIM Light domain. This		not be pruned toward the source on the PIM Light domain. This
	results in the upstream routers continuously sending multicast		results in the upstream routers continuously sending multicast
	streams until the outgoing interface (OIF) expires.		streams until the outgoing interface (OIF) expires.
	Other protocols can be used to detect these failures in the PIM Light		Other protocols can be used to detect these failures in the PIM Light
	domain, and they can be implementation specific. As an example, the		domain, and they can be implementation specific. As an example, the
	interface on which PIM Light is configured can be protected via		interface on which PIM Light is configured can be protected via
	Bidirectional Forwarding Detection (BFD) or similar technology. If		Bidirectional Forwarding Detection (BFD) or similar technology. If
	BFD to the far-end PLI goes down and the PIM Light router is upstream		BFD 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		and has an OIF for a multicast route (S,G), PIM must remove that PLI
	from its OIF list.		from its OIF list.
			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.
	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>		<--Prune (S,G) <failure on D>
	In another example, the PLI is configured automatically between the
	BIER Edge Routers (BERs). 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.
	3.5. Reliable Transport Mechanism for PIM Light		3.5. Reliable Transport Mechanism for PIM Light
	[RFC6559] defines a reliable transport mechanism for PIM transmission		[RFC6559] defines a reliable transport mechanism called PIM Over
	of Join/Prune messages, using either TCP or SCTP as the transport		Reliable Transport (PORT) for PIM transmission of Join/Prune
	protocol. For TCP, PIM Over Reliable Transport (PORT) uses port		messages, using either TCP or SCTP as the transport protocol. Both
	8471, which was assigned by IANA. SCTP is explained in [RFC9260] and		TCP and SCTP use destination port number 8471. SCTP is explained in
	is used as a second option for PORT. [RFC6559] mentions that when a		[RFC9260] and is used as a second option for PORT. [RFC6559]
	router is configured to use PIM over TCP on a given interface, it		mentions that when a router is configured to use PIM over TCP on a
	MUST include the PIM-over-TCP-Capable Hello Option in its Hello		given interface, it MUST include the PIM-over-TCP-Capable Hello
	messages for that interface. The same is true for SCTP; the router		Option in its Hello messages for that interface. The same is true
	must include the PIM-over-SCTP-Capable Hello Option in its Hello		for SCTP; the router MUST include the PIM-over-SCTP-Capable Hello
	message on that interface.		Option in its Hello messages on that interface.
	These Hello options contain a Connection ID, which is an IPv4 or IPv6		These Hello options contain a Connection ID, which is an IPv4 or IPv6
	address used to establish the SCTP or TCP connection. For PORT using		address used to establish the SCTP or TCP connection. For PORT using
	TCP, the Connection ID is used to determine which peer is doing an		TCP, the Connection ID is used to determine which peer is doing an
	active transport open to the neighbor and which peer is doing passive		active transport open to the neighbor and which peer is doing passive
	transport open, as per Section 4 of [RFC6559].		transport open, as per Section 4 of [RFC6559]. When the router is
			using SCTP, the Connection ID is not used to determine the active and
	When the router is using SCTP, the Connection ID IP address		passive peer since SCTP can handle call collision.
	comparison need not be done since SCTP can handle call collision.
	Because PIM Light lacks Hello messages, the PLI can be configured		Because PIM Light lacks Hello messages, the PLI can be configured
	with the Connection ID IPv4 or IPv6 addresses used to establish the		with the Connection ID (i.e., the IPv4 or IPv6 address used to
	SCTP or TCP connection. For PIM Light using the TCP PORT option,		establish the SCTP or TCP connection). For PIM Light using the TCP
	each end of the PLI must be explicitly and correctly configured as		PORT option, each end of the PLI must be explicitly and correctly
	being either active transport open or passive transport open to		configured as being either active transport open or passive transport
	ensure that call collision is avoided.		open to ensure that call collision is avoided.
	3.6. PIM Variants Not Supported		3.6. PIM Variants Not Supported
	The following PIM variants are not supported with PIM Light and not		The following PIM variants are not supported with PIM Light and not
	covered by this document:		covered by this document:
	* PIM - Dense Mode (PIM-DM) [RFC3973]		* PIM - Dense Mode (PIM-DM) [RFC3973]
	* Bidirectional PIM (BIDIR-PIM) [RFC5015]		* Bidirectional PIM (BIDIR-PIM) [RFC5015]
	skipping to change at line 339 ¶		skipping to change at line 335 ¶
	verify PIM neighbor adjacency for incoming Join/Prune messages, for		verify PIM neighbor adjacency for incoming Join/Prune messages, for
	security reasons, it is crucial that implementations ensure that only		security 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		Join/Prune messages received on an interface that is not configured
	as a PLI MUST be discarded and not processed. Additionally, as a		as a PLI MUST be discarded and not processed. Additionally, as a
	secondary line of defense, route policies SHOULD be implemented to		secondary line of defense, route policies SHOULD be implemented to
	process only the Join/Prune messages associated with the desired		process only the Join/Prune messages associated with the desired
	(S,G) pairs, while all other (S,G) pairs MUST be discarded and not		(S,G) pairs, while all other (S,G) pairs MUST be discarded and not
	processed.		processed.
	Furthermore, because PIM Light can be used for signaling Source-		Furthermore, because PIM Light can be used for signaling PIM-SM Join/
	Specific and Sparse Mode Join/Prune messages, the security		Prune messages, the security considerations outlined in [RFC7761] and
	considerations outlined in [RFC7761] and [RFC4607] SHOULD be		[RFC4607] SHOULD be considered where appropriate.
	considered where appropriate.
	Per Section 6.1.1 of [RFC7761], only forged Join/Prune messages		Per Section 6.1.1 of [RFC7761], only forged Join/Prune messages
	should be considered as a potential attack vector, as PIM Light does		should be considered as a potential attack vector, as PIM Light does
	not process Hello or Assert messages. In addition, as detailed in		not process Hello or Assert messages. In addition, as detailed in
	Section 6.3 of [RFC7761], the authentication mechanisms described in		Section 6.3 of [RFC7761], the authentication mechanisms described in
	[RFC5796] can be applied to PIM Light via IPsec Encapsulating		[RFC5796] can be applied to PIM Light via IPsec Encapsulating
	Security Payload (ESP) or, optionally, the Authentication Header		Security Payload (ESP) or, optionally, the Authentication Header
	(AH).		(AH).
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[IANA-PIM-Attr-Types]
	IANA, "PIM Join Attribute Types",
	<https://www.iana.org/assignments/pim-parameters>.
	[IANA-PIM-Mess-Types]		[IANA-PIM-Mess-Types]
	IANA, "PIM Message Types",		IANA, "PIM Message Types",
	<https://www.iana.org/assignments/pim-parameters>.		<https://www.iana.org/assignments/pim-parameters>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for		[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
	skipping to change at line 460 ¶		skipping to change at line 451 ¶
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Tasman Drive		Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	United States of America		United States of America
	Email: mankamis@cisco.com		Email: mankamis@cisco.com
	Zhaohui Zhang		Zhaohui Zhang
	Juniper Networks		Juniper Networks
	Boston, MA		Boston, MA
	United States of America		United States of America
	Email: zzhang@juniper.com		Email: zzhang@juniper.net
	Mike McBride		Mike McBride
	Futurewei Technologies Inc.		Futurewei Technologies Inc.
	Santa Clara, CA		Santa Clara, CA
	United States of America		United States of America
	Email: michael.mcbride@futurewei.com		Email: michael.mcbride@futurewei.com
End of changes. 22 change blocks.
	83 lines changed or deleted		74 lines changed or added
This html diff was produced by rfcdiff 1.48.