rfc9961v1.txt		rfc9961.txt
	skipping to change at line 13 ¶		skipping to change at line 13 ¶
	Request for Comments: 9961 Nokia		Request for Comments: 9961 Nokia
	Category: Standards Track Z. Ali		Category: Standards Track Z. Ali
	ISSN: 2070-1721 Cisco System		ISSN: 2070-1721 Cisco System
	Z. Zhang		Z. Zhang
	Juniper Networks		Juniper Networks
	A. BudhirajaC		A. BudhirajaC
	D. Voyer		D. Voyer
	Cisco System		Cisco System
	April 2026		April 2026
	Segment Routing MPLS Point-to-Multipoint (P2MP) Policy Ping		MPLS Segment Routing Point-to-Multipoint (P2MP) Policy Ping
	Abstract		Abstract
	Segment Routing (SR) Point-to-Multipoint (P2MP) Policies are used to		Segment Routing (SR) Point-to-Multipoint (P2MP) Policies are used to
	define and manage explicit P2MP paths within a network. These		define and manage explicit P2MP paths within a network. These
	policies are typically calculated via a controller-based mechanism		policies are typically calculated via a controller-based mechanism
	and installed via, e.g., a Path Computation Element (PCE). In other		and installed via, e.g., a Path Computation Element (PCE). In other
	cases, these policies can be installed using the Network		cases, these policies can be installed using the Network
	Configuration Protocol (NETCONF) / YANG or a Command Line Interface		Configuration Protocol (NETCONF) / YANG or a Command Line Interface
	(CLI). They are used to steer multicast traffic along optimized		(CLI). They are used to steer Multicast traffic along optimized
	paths from a Root to a set of Leaf routers.		paths from a Root to a set of Leaf routers.
	This document defines extensions to Ping and Traceroute mechanisms		This document defines extensions to ping and traceroute mechanisms
	for an SR P2MP Policy with MPLS encapsulation to provide Operations,		for an SR P2MP Policy with MPLS encapsulation to provide Operations,
	Administration, and Maintenance (OAM) capabilities. The extensions		Administration, and Maintenance (OAM) capabilities. The extensions
	enable operators to verify connectivity, diagnose failures, and		enable operators to verify connectivity, diagnose failures, and
	troubleshoot forwarding issues within SR P2MP Policy multicast trees.		troubleshoot forwarding issues within SR P2MP Policy Multicast trees.
	By introducing new mechanisms for detecting failures and validating		By introducing new mechanisms for detecting failures and validating
	path integrity, this document enhances the operational robustness of		path integrity, this document enhances the operational robustness of
	P2MP multicast deployments. Additionally, it ensures that existing		P2MP Multicast deployments. Additionally, it ensures that existing
	MPLS and SR-based OAM tools can be effectively applied to networks		MPLS and SR-based OAM tools can be effectively applied to networks
	utilizing SR P2MP Policies.		utilizing SR P2MP Policies.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	skipping to change at line 73 ¶		skipping to change at line 73 ¶
	include Revised BSD License text as described in Section 4.e of the		include Revised BSD License text as described in Section 4.e of the
	Trust Legal Provisions and are provided without warranty as described		Trust Legal Provisions and are provided without warranty as described
	in the Revised BSD License.		in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	1.1. Terminology		1.1. Terminology
	2. Conventions Used in This Document		2. Conventions Used in This Document
	3. Motivation		3. Motivation
	3.1. MPLS P2MP Policy Ping and Traceroute		3.1. MPLS SR P2MP Policy Ping and Traceroute
	3.1.1. Applicability of the Current RFC to SR P2MP Policies		3.1.1. Applicability of RFC 6425 to MPLS SR P2MP Policy
	3.1.2. Conformance to Existing Procedures and Additional		3.1.2. Conformance to Existing Procedures and Additional
	Considerations		Considerations
	3.1.3. Considerations for Interworking with Unicast Paths		3.1.3. Considerations for Interworking with Unicast Paths
	3.2. Packet Format and New TLVs		3.2. Packet Format and New TLVs
	3.2.1. Identifying a P2MP Policy		3.2.1. Identifying a P2MP Policy
	3.2.1.1. SR MPLS P2MP Policy Tree Instance FEC Stack		3.2.1.1. SR MPLS P2MP Policy Tree Instance FEC Stack
	Sub-TLVs		Sub-TLVs
	3.3. Limiting the Scope of Response		3.3. Limiting the Scope of Response
	4. IANA Considerations		4. IANA Considerations
	5. Security Considerations		5. Security Considerations
	skipping to change at line 105 ¶		skipping to change at line 105 ¶
	optimization, a CP may consist of multiple P2MP tree instances		optimization, a CP may consist of multiple P2MP tree instances
	(PTIs), allowing for Make-Before-Break procedures between an active		(PTIs), allowing for Make-Before-Break procedures between an active
	PTI and a newly established, optimized PTI. A PTI is the actual P2MP		PTI and a newly established, optimized PTI. A PTI is the actual P2MP
	tunnel set up from the Root to a set of Leaves via transit routers.		tunnel set up from the Root to a set of Leaves via transit routers.
	A PTI is identified on the Root node by the PTI's instance ID.		A PTI is identified on the Root node by the PTI's instance ID.
	To ensure reliable network operation, it is essential to verify end-		To ensure reliable network operation, it is essential to verify end-
	to-end connectivity for both active and backup CPs, as well as all		to-end connectivity for both active and backup CPs, as well as all
	associated PTIs. This document specifies a mechanism for detecting		associated PTIs. This document specifies a mechanism for detecting
	data plane failures within an SR P2MP Policy CP and its associated		data plane failures within an SR P2MP Policy CP and its associated
	PTIs, enabling operators to monitor and troubleshoot multicast path		PTIs, enabling operators to monitor and troubleshoot Multicast path
	integrity.		integrity.
	This specification applies exclusively to Replication Segments		This specification applies exclusively to Replication Segments
	(Replication-SIDs) that use MPLS encapsulation for forwarding and		(Replication-SIDs) that use MPLS encapsulation for forwarding and
	does not cover Segment Routing over IPv6 (SRv6). The mechanisms		does not cover Segment Routing over IPv6 (SRv6). The mechanisms
	described herein build upon the concepts established in [RFC6425] for		described herein build upon the concepts established in [RFC6425] for
	P2MP MPLS Operations, Administration, and Maintenance (OAM). All		P2MP MPLS OAM. All considerations and limitations described in
	considerations and limitations described in Section 6 of [RFC6425]		Section 6 of [RFC6425] apply to this document as well.
	apply to this document as well.
	1.1. Terminology		1.1. Terminology
	The readers of this document should familiarize themselves with the		The readers of this document should familiarize themselves with the
	following documents and sections for terminology and details		following documents and sections for terminology and details
	regarding the implementation of the SR P2MP Policy.		regarding the implementation of the SR P2MP Policy.
	[RFC9524], Section 1.1 defines terms specific to an SR Replication		[RFC9524], Section 1.1 defines terms specific to an SR Replication
	segment and also explains the node terminology in a Multicast domain,		segment and also explains the node terminology in a Multicast domain,
	including the Root node, Leaf node, and Bud node.		including the Root node, Leaf node, and Bud node.
	skipping to change at line 142 ¶		skipping to change at line 141 ¶
	"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.
	3. Motivation		3. Motivation
	An SR P2MP Policy and its corresponding Replication segments are		An SR P2MP Policy and its corresponding Replication segments are
	typically provisioned via a centralized controller or configured		typically provisioned via a centralized controller or configured
	using NETCONF/YANG or CLI. The Root and the Leaves are discovered in		using NETCONF/YANG or CLI. The Root and the Leaves are discovered in
	accordance with [RFC9960], and the multicast tree is computed from		accordance with [RFC9960], and the Multicast tree is computed from
	the Root to the Leaves. However, there is no underlay signaling		the Root to the Leaves. However, there is no underlay signaling
	protocol to distribute the SR P2MP Policy from the Root to the Leaf		protocol to distribute the SR P2MP Policy from the Root to the Leaf
	routers. Consequently, when a P2MP tree fails to deliver user		routers. Consequently, when a P2MP tree fails to deliver user
	traffic, identifying the failure can be challenging without ping and		traffic, identifying the failure can be challenging without ping and
	traceroute mechanisms to isolate faults along the tree.		traceroute mechanisms to isolate faults along the tree.
	To address this challenge, SR P2MP Policy ping and traceroute can be		To address this challenge, SR P2MP Policy ping and traceroute can be
	utilized to detect and localize faults within the P2MP tree and its		utilized to detect and localize faults within the P2MP tree and its
	associated Replication segments, as defined in [RFC9524]. These OAM		associated Replication segments, as defined in [RFC9524]. These OAM
	tools enable periodic ping operations to verify connectivity between		tools enable periodic ping operations to verify connectivity between
	the Root and the Leaves. In cases where a ping fails, a traceroute		the Root and the Leaves. In cases where a ping fails, a traceroute
	can be initiated to determine the point of failure along the tree.		can be initiated to determine the point of failure along the tree.
	This diagnostic process can be initiated from the node responsible		This diagnostic process can be initiated from the node responsible
	for establishing the SR P2MP Policy, ensuring proactive monitoring		for establishing the SR P2MP Policy, ensuring proactive monitoring
	and fault detection.		and fault detection.
	3.1. MPLS P2MP Policy Ping and Traceroute		3.1. MPLS SR P2MP Policy Ping and Traceroute
	Ping/Traceroute packets are forwarded based upon the SR P2MP Policy		Ping/traceroute packets are forwarded based upon the SR P2MP Policy
	on a specific CP and its PTI toward the designated Leaf routers.		on a specific CP and its PTI toward the designated Leaf routers.
	These packets are replicated at the replication point based on the		These packets are replicated at the replication point based on the
	Replication segment forwarding information on the corresponding		Replication segment forwarding information on the corresponding
	router.		router.
	MPLS packets are processed based on the standard behavior when their		MPLS packets are processed based on the standard behavior when their
	Time to Live (TTL) expires or when they reach the egress (Leaf)		Time to Live (TTL) expires or when they reach the egress (Leaf)
	router. The appropriate response is sent back to the Root node		router. The appropriate response is sent back to the Root node
	following the procedures outlined in [RFC6425].		following the procedures outlined in [RFC6425].
	3.1.1. Applicability of the Current RFC to SR P2MP Policies		3.1.1. Applicability of RFC 6425 to MPLS SR P2MP Policy
	The procedures in [RFC6425] define fault detection and isolation		The procedures in [RFC6425] define fault detection and isolation
	mechanisms for P2MP MPLS Label Switched Paths (LSPs) and extend the		mechanisms for P2MP MPLS Label Switched Paths (LSPs) and extend the
	LSP ping techniques described in [RFC8029] such that they may be		LSP ping techniques described in [RFC8029] such that they may be
	applied to P2MP MPLS LSPs, ensuring alignment with existing fault		applied to P2MP MPLS LSPs, ensuring alignment with existing fault
	management tools. [RFC6425] emphasizes the reuse of existing LSP		management tools. [RFC6425] emphasizes the reuse of existing LSP
	ping mechanisms designed for Point-to-Point (P2P) LSPs, adapting them		ping mechanisms designed for Point-to-Point (P2P) LSPs, adapting them
	to P2MP MPLS LSPs to facilitate seamless implementation and network		to P2MP MPLS LSPs to facilitate seamless implementation and network
	operation.		operation.
	The fault detection procedures specified in [RFC6425] are applicable		The fault detection procedures specified in [RFC6425] are applicable
	to all P2MP MPLS protocols, including P2MP RSVP-TE and Multicast LDP		to all P2MP MPLS protocols, including P2MP RSVP-TE and Multicast LDP
	and now the SR P2MP Policy. While [RFC6425] highlights specific		and now the SR P2MP Policy. While [RFC6425] highlights specific
	differences for P2MP RSVP-TE and Multicast LDP, this document		differences for P2MP RSVP-TE and Multicast LDP, this document
	introduces considerations unique to SR P2MP Policies, including:		introduces considerations unique to SR P2MP Policies, including:
	1. Egress Address P2MP Responder sub-TLVs: Multicast LDP, as per		1. Egress Address P2MP Responder sub-TLVs: Multicast LDP, as per
	Section 3.2.1 of [RFC6425], does not allow for the inclusion of		Section 3.2.1 of [RFC6425], does not allow for the inclusion of
	Egress Address P2MP Responder sub-TLVs, as upstream Label		Egress Address P2MP Responder sub-TLVs, as upstream Label
	Switching Routers (LSRs) lack visibility into downstream Leaf		Switching Routers (LSRs) lack visibility into downstream Leaf
	nodes. Similarly, SR P2MP Policies often rely on a Path		nodes. Similarly, SR P2MP Policies often rely on a PCE for
	Computation Element (PCE) for programming transit routers. This		programming transit routers. This is why in the SR P2MP domain,
	is why in the SR P2MP domain, transit routers do not have		transit routers do not have knowledge of the Leaf nodes. Only
	knowledge of the Leaf nodes. Only the Root node, where the SR		the Root node, where the SR P2MP Policy is programmed, has
	P2MP Policy is programmed, has visibility into the Leaf nodes.		visibility into the Leaf nodes. Consequently, these sub-TLVs
	Consequently, these sub-TLVs SHOULD NOT be used when an echo		SHOULD NOT be used when an echo request carries an SR P2MP Policy
	request carries an SR P2MP Policy MPLS Candidate Path Forwarding		MPLS CP Forwarding Equivalence Class (FEC). If a node receives
	Equivalence Class (FEC). If a node receives the Egress Address		the Egress Address P2MP Responder sub-TLVs in an echo request,
	P2MP Responder sub-TLVs in an echo request, then it will not		then it will not respond since it is unaware of whether it lies
	respond since it is unaware of whether it lies on the path to the		on the path to the address in the sub-TLV.
	address in the sub-TLV.
	2. End of Processing for Traceroutes: As per Section 4.3.1 of		2. End of processing for traceroutes: As per Section 4.3.1 of
	[RFC6425], it is RECOMMENDED that traceroute orations provide for		[RFC6425], it is RECOMMENDED that traceroute orations provide for
	a configurable upper limit on TTL values. This is because, for		a configurable upper limit on TTL values. This is because, for
	some protocols like Multicast LDP, there may not be an easy way		some protocols like Multicast LDP, there may not be an easy way
	to figure out the end of the traceroute processing, as the		to figure out the end of the traceroute processing, as the
	initiating LSR might not always know about all of the Leaf		initiating LSR might not always know about all of the Leaf
	routers. In the case of an SR P2MP Policy, the Root node has		routers. In the case of an SR P2MP Policy, the Root node has
	visibility of the Leaf nodes; as such, there is a definitive way		visibility of the Leaf nodes; as such, there is a definitive way
	to estimate the end of processing for a traceroute, and a		to estimate the end of processing for a traceroute, and a
	configurable upper limit on TTL may not be necessary. However, a		configurable upper limit on TTL may not be necessary. However, a
	configurable upper limit on the TTL value is an implementation		configurable upper limit on the TTL value is an implementation
	skipping to change at line 271 ¶		skipping to change at line 269 ¶
	Replication segments that are connected via an SR Policy or similar		Replication segments that are connected via an SR Policy or similar
	technology), there are special considerations. In such scenarios, SR		technology), there are special considerations. In such scenarios, SR
	P2MP Policy OAM tools should be used to verify the connectivity of		P2MP Policy OAM tools should be used to verify the connectivity of
	the non-adjacent Replication segments that are building the P2MP		the non-adjacent Replication segments that are building the P2MP
	tree, while the unicast OAM tools should be used to verify the		tree, while the unicast OAM tools should be used to verify the
	connectivity of the unicast path connecting the two non-adjacent		connectivity of the unicast path connecting the two non-adjacent
	Replication segments. In these scenarios, the Replication-SID should		Replication segments. In these scenarios, the Replication-SID should
	not be exposed or examined in the unicast path. Proper TTL handling		not be exposed or examined in the unicast path. Proper TTL handling
	to copy the Replication segment TTL to the unicast path can be		to copy the Replication segment TTL to the unicast path can be
	achieved via the hierarchical MPLS TTL mode being used (e.g., Pipe		achieved via the hierarchical MPLS TTL mode being used (e.g., Pipe
	Mode vs. Uniform Mode) as per [RFC3270]. For the P2MP Tree		Mode vs. Uniform Mode) as per [RFC3270]. For the P2MP tree
	Traceroute, the TTL mode MUST be set to Pipe Mode on the router that		traceroute, the TTL mode MUST be set to Pipe Mode on the router that
	the unicast path starts. This will ensure that the unicast path TTL		the unicast path starts. This will ensure that the unicast path TTL
	is set to a large value that allows the traceroute packet to be		is set to a large value that allows the traceroute packet to be
	delivered to the downstream Replication segment. For Ping, either		delivered to the downstream Replication segment. For ping, either
	the Pipe Mode or the Uniform Mode can be used depending on the		the Pipe Mode or the Uniform Mode can be used depending on the
	implementation. The unicast path failure detection is considered out		implementation. The unicast path failure detection is considered out
	of scope for this document.		of scope for this document.
	3.2. Packet Format and New TLVs		3.2. Packet Format and New TLVs
	The packet format used in this specification follows Section 3 of		The packet format used in this specification follows Section 3 of
	[RFC8029]. However, additional TLVs and sub-TLVs are required to		[RFC8029]. However, additional TLVs and sub-TLVs are required to
	support the new functionality introduced for SR P2MP Policies. These		support the new functionality introduced for SR P2MP Policies. These
	extensions are described in the following sections.		extensions are described in the following sections.
	3.2.1. Identifying a P2MP Policy		3.2.1. Identifying a P2MP Policy
	[RFC8029] defines a standardized mechanism for detecting data plane		[RFC8029] defines a standardized mechanism for detecting data plane
	failures in MPLS LSPs. To correctly identify the Replication segment		failures in MPLS LSPs. To correctly identify the Replication segment
	associated with a given CP and PTI, the echo request message MUST		associated with a given CP and PTI, the echo request message MUST
	include a Target FEC Stack TLV that explicitly specifies the		include a Target FEC Stack TLV that explicitly specifies the CP and
	candidate path and P2MP tree instance under test.		PTI under test.
	This document introduces a new sub-TLV, referred to as the SR MPLS		This document introduces a new sub-TLV, referred to as the SR MPLS
	P2MP Policy Tree Instance sub-TLV, which is defined as follows:		P2MP Policy Tree Instance sub-TLV, which is defined as follows:
	+==========+==========+===================================+		+==========+==========+===================================+
	| Sub-Type | Length | Value Field |		| Sub-Type | Length | Value Field |
	+==========+==========+===================================+		+==========+==========+===================================+
	| 41 | Variable | SR MPLS P2MP Policy Tree Instance |		| 41 | Variable | SR MPLS P2MP Policy Tree Instance |
	+----------+----------+-----------------------------------+		+----------+----------+-----------------------------------+
	skipping to change at line 387 ¶		skipping to change at line 385 ¶
	+==========+===================================+		+==========+===================================+
	| Sub-Type | Sub-TLV Name |		| Sub-Type | Sub-TLV Name |
	+==========+===================================+		+==========+===================================+
	| 41 | SR MPLS P2MP Policy Tree Instance |		| 41 | SR MPLS P2MP Policy Tree Instance |
	+----------+-----------------------------------+		+----------+-----------------------------------+
	Table 2		Table 2
	5. Security Considerations		5. Security Considerations
	Overall, the security needs for P2MP policy ping are the same as in		Overall, the security needs for SR P2MP Policy ping are the same as
	[RFC9960], [RFC6425], and [RFC8029]. P2MP policy ping is susceptible		in [RFC9960], [RFC6425], and [RFC8029]. SR P2MP Policy ping is
	to the same three attack vectors as explained in Section 5 of		susceptible to the same three attack vectors as explained in
	[RFC8029]. The same procedures and recommendations explained in		Section 5 of [RFC8029]. The same procedures and recommendations
	Section 5 of [RFC8029] should be taken and implemented to mitigate		explained in Section 5 of [RFC8029] should be taken and implemented
	these attack vectors for P2MP policy ping as well.		to mitigate these attack vectors for SR P2MP Policy ping as well.
	In addition, the security considerations in Section 8 of [RFC6425]		In addition, the security considerations in Section 8 of [RFC6425]
	should be followed, specifically the security recommendation from		should be followed, specifically the security recommendations from
	[RFC4379], which recommends "To avoid potential Denial-of-Service		[RFC4379], which recommend the following:
	attacks, it is RECOMMENDED that implementations regulate the LSP ping
	traffic going to the control plane. A rate limiter SHOULD be applied		| To avoid potential Denial-of-Service attacks, it is RECOMMENDED
	to the well-known UDP port" allocated for this service.		| that implementations regulate the LSP ping traffic going to the
			| control plane. A rate limiter SHOULD be applied to the well-known
			| UDP port [allocated for this service].
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[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>.
End of changes. 19 change blocks.
	43 lines changed or deleted		43 lines changed or added
This html diff was produced by rfcdiff 1.48.