rfc9798v1.txt		rfc9798.txt
	Internet Engineering Task Force (IETF) V. Govindan		Internet Engineering Task Force (IETF) V. Govindan
	Request for Comments: 9798 S. Venaas		Request for Comments: 9798 Cisco
	Updates: 8059 Cisco		Updates: 8059 S. Venaas
	Category: Experimental May 2025		Category: Experimental Cisco Systems, Inc.
	ISSN: 2070-1721		ISSN: 2070-1721 June 2025
	PIM Join/Prune Attributes for Locator/ID Separation Protocol (LISP)		PIM Join/Prune Attributes for Locator/ID Separation Protocol (LISP)
	Environments Using Underlay Multicast		Environments Using Underlay Multicast
	Abstract		Abstract
	This document specifies an update to the PIM Receiver RLOC Join/Prune		This document specifies an update to the Receiver RLOC field (Routing
	attribute that supports the construction of multicast distribution		Locator) of the PIM Join/Prune attribute that supports the
	trees where the source and receivers are located in different		construction of multicast distribution trees where the source and
	Locator/ID Separation Protocol (LISP) sites and are connected using		receivers are located in different Locator/ID Separation Protocol
	underlay IP Multicast. This attribute allows the receiver site to		(LISP) sites and are connected using underlay IP multicast. This
	signal the underlay multicast group to the control plane of the root		attribute allows the receiver site to signal the underlay multicast
	Ingress Tunnel Router (ITR). This document updates RFC 8059.		group to the control plane of the root Ingress Tunnel Router (ITR).
			This document updates RFC 8059.
	Status of This Memo		Status of This Memo
	This document is not an Internet Standards Track specification; it is		This document is not an Internet Standards Track specification; it is
	published for examination, experimental implementation, and		published for examination, experimental implementation, and
	evaluation.		evaluation.
	This document defines an Experimental Protocol for the Internet		This document defines an Experimental Protocol for the Internet
	community. This document is a product of the Internet Engineering		community. This document is a product of the Internet Engineering
	Task Force (IETF). It represents the consensus of the IETF		Task Force (IETF). It represents the consensus of the IETF
	skipping to change at line 78 ¶		skipping to change at line 79 ¶
	6. Normative References		6. Normative References
	Acknowledgements		Acknowledgements
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	The construction of multicast distribution trees where the root and		The construction of multicast distribution trees where the root and
	receivers are located in different LISP sites [RFC9300] is defined in		receivers are located in different LISP sites [RFC9300] is defined in
	[RFC6831].		[RFC6831].
	[RFC6831] specifies that (root-EID, G) data packets are to be LISP-		[RFC6831] specifies that (EID, G) data packets are to be LISP-
	encapsulated into (root-RLOC, G) multicast packets. [RFC8059]		encapsulated into (RLOC, G) multicast packets. In this document, we
	defines PIM Join/Prune attribute extensions to construct multicast		use the term root-EID or root-RLOC to refer to the source of the
	distribution trees. Please refer to Section 3 of [RFC6831] for the		multicast tree rooted at the EID or RLOC. [RFC8059] defines PIM
	definition of the terms Endpoint ID (EID) and Routing Locator (RLOC).		Join/Prune attribute extensions to construct multicast distribution
	We use the term root-EID or root-RLOC to refer to the source of the		trees. Please refer to Section 3 of [RFC6831] for the definition of
	multicast tree rooted at the EID or RLOC. This document extends the		the terms Endpoint ID (EID) and Routing Locator (RLOC). This
	Receiver ETR RLOC PIM Join/Prune attribute [RFC8059] to facilitate		document extends the Receiver ETR RLOC PIM Join/Prune attribute
	the construction of underlay multicast trees for (root-RLOC, G).		[RFC8059] to facilitate the construction of underlay multicast trees
			for (root-RLOC, G).
	Specifically, the assignment of the underlay multicast group needs to		Specifically, the assignment of the underlay multicast group needs to
	be done in consonance with the downstream Tunnel Router (xTR) nodes		be done in consonance with the downstream Tunnel Router (xTR) nodes
	needed to avoid unnecessary replication or traffic hairpinning.		needed to avoid unnecessary replication or traffic hairpinning.
	Since the Receiver RLOC Attribute defined in [RFC8059] only addresses		Since the Receiver RLOC Attribute defined in [RFC8059] only addresses
	the Ingress Replication case, this document extends the scope of that		the Ingress Replication case, this document extends the scope of that
	PIM Join/Prune attribute to include scenarios where the underlay uses		PIM Join/Prune attribute to include scenarios where the underlay uses
	Multicast transport. The scope extension complies with the base		multicast transport. The scope extension complies with the base
	specification [RFC5384].		specification [RFC5384].
	This document uses terminology defined in [RFC9300], such as EID,		This document uses terminology defined in [RFC9300], such as EID,
	RLOC, ITR, and ETR.		RLOC, ITR, and ETR.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. The Case for Extending the Received ETR RLOC Attribute of RFC 8059		2. The Case for Extending the Received ETR RLOC Attribute of RFC 8059
	When LISP-based Multicast trees are constructed using IP Multicast in		When LISP-based multicast trees are constructed using IP multicast in
	the underlay, the mapping between the overlay group address and the		the underlay, the mapping between the overlay group address and the
	underlay group address becomes a crucial engineering decision.		underlay group address becomes a crucial engineering decision.
	2.1. Flexible Mapping of Overlay to Underlay Group Ranges		2.1. Flexible Mapping of Overlay to Underlay Group Ranges
	Three distinct types of overlay to underlay group mappings are		Three distinct types of overlay to underlay group mappings are
	possible:		possible:
	* Many-to-one mapping: Many (root-EID, G) flows originating from an		* Many-to-one mapping: Many (root-EID, G) flows originating from an
	RLOC can be mapped to a single underlay multicast (root-RLOC, G-u)		RLOC can be mapped to a single underlay multicast (root-RLOC, G-u)
	skipping to change at line 145 ¶		skipping to change at line 147 ¶
	the same overlay multicast stream may be constrained to use distinct		the same overlay multicast stream may be constrained to use distinct
	underlay multicast mapping ranges.		underlay multicast mapping ranges.
	This introduces a trade-off between replication overhead and the		This introduces a trade-off between replication overhead and the
	flexibility of address range assignment, which may be necessary in		flexibility of address range assignment, which may be necessary in
	specific use cases like Proxy Tunnel Routers or when using nodes with		specific use cases like Proxy Tunnel Routers or when using nodes with
	limited hardware resources as explained below.		limited hardware resources as explained below.
	Inter-site Proxy Tunnel Routers (PxTR):		Inter-site Proxy Tunnel Routers (PxTR):
	When multiple LISP sites are interconnected through a LISP-based		When multiple LISP sites are interconnected through a LISP-based
	transit, the site border node (PxTR) connects the site-facing		transit, the site border node (i.e., PxTR) connects the site-facing
	interfaces with the external LISP core. In such cases, different		interfaces with the external LISP core. In such cases, different
	ranges of multicast group addresses may be used for constructing		ranges of multicast group addresses may be used for constructing
	(S-RLOC, G) trees within the LISP site and in the external LISP		(S-RLOC, G) trees within the LISP site and in the external LISP
	core. This distinction is desirable for various operational		core. This distinction is desirable for various operational
	reasons.		reasons.
	Hardware resource restrictions:		Hardware resource restrictions:
	Platform limitations may necessitate engineering decisions to		Platform limitations may necessitate engineering decisions to
	restrict multicast address ranges in the underlay due to hardware		restrict multicast address ranges in the underlay due to hardware
	resource constraints.		resource constraints.
	3. Updates to RFC 8059		3. Updates to RFC 8059
	3.1. Scope		3.1. Scope
	No changes are proposed to the syntax or semantics of the Transport		No changes are proposed to the syntax or semantics of the Transport
	Attribute defined in [RFC8059].		Attribute defined in [RFC8059].
	The scope of the updates to [RFC8059] is limited to the case where		The scope of the updates to [RFC8059] is limited to the case where
	the "Transport" field of the Transport Attribute is set to zero		the "Transport" field of the Transport Attribute is set to zero
	(Multicast) only.		(multicast) only.
	3.2. Receiver ETR RLOC Attribute		3.2. Receiver ETR RLOC Attribute
	The definition of the "Receiver RLOC" field of the Receiver ETR RLOC		The definition of the "Receiver RLOC" field of the Receiver ETR RLOC
	attribute [RFC8059] is updated as follows:		attribute (see Section 5.1 of [RFC8059]) is updated as follows:
	| Receiver RLOC:		OLD:
	| The RLOC address on which the receiver ETR wishes to receive
	| the encapsulated flow. A unicast IP Receiver RLOC address is		| Receiver RLOC: The RLOC address on which the receiver ETR wishes
	| used for unicast-encapsulated flows. Alternately, a multicast		| to receive the unicast-encapsulated flow.
	| IP Receiver RLOC address is used for for multicast-encapsulated
	| flows. A multicast IP address MUST be used only when the		NEW:
	| underlay network of the LISP core supports IP Multicast
	| transport.		| Receiver RLOC: The RLOC address on which the receiver ETR wishes
			| to receive the encapsulated flow. A unicast IP Receiver RLOC
			| address is used for unicast-encapsulated flows. Alternately, a
			| multicast IP Receiver RLOC address is used for for multicast-
			| encapsulated flows. A multicast IP address MUST be used only
			| when the underlay network of the LISP core supports IP
			| multicast transport.
	The definitions of the other fields of the Receiver ETR RLOC		The definitions of the other fields of the Receiver ETR RLOC
	Attribute remain unchanged.		Attribute remain unchanged.
	When the ITR needs to track the list of ETRs from which the PIM joins		When the ITR needs to track the list of ETRs from which the PIM joins
	are received, the ITR MUST use the source IP address field of the		are received, the ITR MUST use the source IP address field of the
	incoming PIM Join/Prune message. The source IP address of the PIM		incoming PIM Join/Prune message. The source IP address of the PIM
	Join/Prune MUST be an ETR RLOC IP address.		Join/Prune MUST be an ETR RLOC IP address.
	3.3. Using the Receiver RLOC Attribute		3.3. Using the Receiver RLOC Attribute
	skipping to change at line 206 ¶		skipping to change at line 214 ¶
	document.		document.
	* It identifies the upstream LISP site where the underlay multicast		* It identifies the upstream LISP site where the underlay multicast
	tree needs to be rooted.		tree needs to be rooted.
	* It constructs the PIM Join/Prune message as specified in		* It constructs the PIM Join/Prune message as specified in
	[RFC8059]. Only the Receiver RLOC attribute is encoded as above.		[RFC8059]. Only the Receiver RLOC attribute is encoded as above.
	When the ITR receives a PIM Join/Prune message:		When the ITR receives a PIM Join/Prune message:
	* It allocates a new entry in the OutgoingInterfaceList [RFC6831]		* It allocates a new entry in the outgoing interface list [RFC6831]
	for every unique underlay multicast mapping.		for every unique underlay multicast mapping.
	* The ITR MAY apply local policy to perform any kind of rate-		* The ITR MAY apply local policy to perform any kind of rate-
	limiting on the number of copies it needs to make in the underlay.		limiting on the number of copies it needs to make in the underlay.
	Such actions are beyond the scope of this document.		Such actions are beyond the scope of this document.
	4. IANA Considerations		4. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	skipping to change at line 285 ¶		skipping to change at line 293 ¶
	their contributions to the document. The authors thank Gunter Van de		their contributions to the document. The authors thank Gunter Van de
	Velde for his valuable comments.		Velde for his valuable comments.
	Authors' Addresses		Authors' Addresses
	Vengada Prasad Govindan		Vengada Prasad Govindan
	Cisco		Cisco
	Email: venggovi@cisco.com		Email: venggovi@cisco.com
	Stig Venaas		Stig Venaas
	Cisco		Cisco Systems, Inc.
			Tasman Drive
			San Jose, CA 95134
			United States of America
	Email: svenaas@cisco.com		Email: svenaas@cisco.com
End of changes. 11 change blocks.
	35 lines changed or deleted		46 lines changed or added
This html diff was produced by rfcdiff 1.48.