rfc9961.original   rfc9961.txt 
Network Working Group H. Bidgoli, Ed. Internet Engineering Task Force (IETF) H. Bidgoli, Ed.
Internet-Draft Nokia Request for Comments: 9961 Nokia
Intended status: Standards Track Z. Ali Category: Standards Track Z. Ali
Expires: 12 April 2026 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
9 October 2025 April 2026
Segment Routing MPLS Point-to-Multipoint (P2MP) Policy Ping Segment Routing MPLS Point-to-Multipoint (P2MP) Policy Ping
draft-ietf-pim-p2mp-policy-ping-25
Abstract Abstract
SR Point-to-Multipoint (P2MP) Policies are used to define and manage Segment Routing (SR) Point-to-Multipoint (P2MP) Policies are used to
explicit P2MP paths within a network. These policies are typically define and manage explicit P2MP paths within a network. These
calculated via a controller-based mechanism and installed via, e.g., policies are typically calculated via a controller-based mechanism
a Path Computation Element (PCE). In other cases these policies can and installed via, e.g., a Path Computation Element (PCE). In other
be installed via using NETCONF/YANG or CLI. They are used to steer cases, these policies can be installed using the Network
multicast traffic along optimized paths from a Root to a set of Leaf Configuration Protocol (NETCONF) / YANG or a Command Line Interface
routers. (CLI). They are used to steer multicast traffic along optimized
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 SR P2MP Policy with MPLS encapsulation to provide OAM for an SR P2MP Policy with MPLS encapsulation to provide Operations,
(Operations, Administration, and Maintenance) capabilities. The Administration, and Maintenance (OAM) capabilities. The extensions
extensions enable operators to verify connectivity, diagnose failures enable operators to verify connectivity, diagnose failures, and
and troubleshoot forwarding issues within SR P2MP Policy multicast troubleshoot forwarding issues within SR P2MP Policy multicast trees.
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 Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 12 April 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9961.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation
3.1. MPLS P2MP Policy Ping and Traceroute . . . . . . . . . . 4 3.1. MPLS P2MP Policy Ping and Traceroute
3.1.1. Applicability of current RFC to SR P2MP Policies . . 4 3.1.1. Applicability of the Current RFC to SR P2MP Policies
3.1.2. Conformance to Existing Procedures and Additional 3.1.2. Conformance to Existing Procedures and Additional
Considerations . . . . . . . . . . . . . . . . . . . 6 Considerations
3.1.3. Considerations for Interworking with Unicast paths . 6 3.1.3. Considerations for Interworking with Unicast Paths
3.2. Packet format and new TLVs . . . . . . . . . . . . . . . 7 3.2. Packet Format and New TLVs
3.2.1. Identifying a P2MP Policy . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . 7 Sub-TLVs
3.3. Limiting the Scope of Response . . . . . . . . . . . . . 8 3.3. Limiting the Scope of Response
4. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations
4.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 9 5. Security Considerations
5. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 9 6. References
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
[draft-ietf-pim-sr-p2mp-policy] explains the concept of the SR P2MP [RFC9960] explains the concept of the SR P2MP Policy and its
Policy and its Candidate Paths (CPs). It also explains the concept candidate paths (CPs). It also explains the concept of how a CP is
of how a CP is selected to be the active CP. To enable seamless selected to be the active CP. To enable seamless global
global 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 (MBB) procedures between an (PTIs), allowing for Make-Before-Break procedures between an active
active PTI and a newly established, optimized PTI. A PTI is the PTI and a newly established, optimized PTI. A PTI is the actual P2MP
actual P2MP tunnel set up from the Root to a set of Leaves via tunnel set up from the Root to a set of Leaves via transit routers.
transit routers. A PTI is identified on the Root node by the PTI's A PTI is identified on the Root node by the PTI's instance ID.
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 a 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 Operations, Administration, and Maintenance (OAM). All
considerations and limitations described in section 6 of [RFC6425] considerations and limitations described in 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
implementation of the SR P2MP Policy regarding the implementation of the SR P2MP Policy.
[RFC9524] section 1.1 defines terms specific to 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 a Bud Node. including the Root node, Leaf node, and Bud node.
[draft-ietf-pim-sr-p2mp-policy] section 2, defines terms and concepts [RFC9960], Section 1.1 defines terms and concepts specific to the SR
specific to SR P2MP Policy including the CP and the PTI. P2MP Policy including the CP and the PTI.
2. Conventions used in this document 2. Conventions Used in This Document
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 BCP "OPTIONAL" in this document are to be interpreted as described in
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
A 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 [draft-ietf-pim-sr-p2mp-policy] and the multicast accordance with [RFC9960], and the multicast tree is computed from
tree is computed from the root to the leaves. However, there is no the Root to the Leaves. However, there is no underlay signaling
underlay signaling protocol to distribute the SR P2MP Policy from the protocol to distribute the SR P2MP Policy from the Root to the Leaf
root to the leaf routers. Consequently, when a P2MP tree fails to routers. Consequently, when a P2MP tree fails to deliver user
deliver user traffic, identifying the failure can be challenging traffic, identifying the failure can be challenging without ping and
without ping and traceroute mechanisms to isolate faults along the traceroute mechanisms to isolate faults along the tree.
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 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 current RFC to SR P2MP Policies 3.1.1. Applicability of the Current RFC to SR P2MP Policies
The procedures in [RFC6425] define fault detection and isolation The procedures in [RFC6425] define fault detection and isolation
mechanisms for P2MP MPLS LSPs and extend the LSP ping techniques mechanisms for P2MP MPLS Label Switched Paths (LSPs) and extend the
described in [RFC8029] such that they may be applied to P2MP MPLS LSP ping techniques described in [RFC8029] such that they may be
LSPs, ensuring alignment with existing fault management tools. applied to P2MP MPLS LSPs, ensuring alignment with existing fault
[RFC6425] emphasizes the reuse of existing LSP ping mechanisms management tools. [RFC6425] emphasizes the reuse of existing LSP
designed for Point-to-Point P2P LSPs, adapting them to P2MP MPLS LSPs ping mechanisms designed for Point-to-Point (P2P) LSPs, adapting them
to facilitate seamless implementation and network operation. to P2MP MPLS LSPs to facilitate seamless implementation and network
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 SR P2MP SR 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 LSRs lack Egress Address P2MP Responder sub-TLVs, as upstream Label
visibility into downstream leaf nodes. Similarly, SR P2MP Switching Routers (LSRs) lack visibility into downstream Leaf
Policies often rely on a Path Computation Element (PCE) for nodes. Similarly, SR P2MP Policies often rely on a Path
programming transit routers. This is why in SR P2MP domain, Computation Element (PCE) for programming transit routers. This
transit routers do not have knowledge of the leaf nodes. Only is why in the SR P2MP domain, transit routers do not have
the Root node, where the SR P2MP Policy is programmed, has knowledge of the Leaf nodes. Only the Root node, where the SR
visibility into the leaf nodes. Consequently, these Sub-TLVs P2MP Policy is programmed, has visibility into the Leaf nodes.
SHOULD NOT be used when an echo request carries a SR P2MP Policy Consequently, these sub-TLVs SHOULD NOT be used when an echo
MPLS Candidate Path FEC. If a node receives the Egress Address request carries an SR P2MP Policy MPLS Candidate Path Forwarding
P2MP Responder Sub-TLVs in an echo request, then it will not Equivalence Class (FEC). If a node receives the Egress Address
P2MP Responder sub-TLVs in an echo request, then it will not
respond since it is unaware of whether it lies on the path to the respond since it is unaware of whether it lies 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 for traceroute orations provide [RFC6425], it is RECOMMENDED that traceroute orations provide for
for a configurable upper limit on TTL values. This is because a configurable upper limit on TTL values. This is because, for
for some protocols like Multicast LDP, there may not be an easy some protocols like Multicast LDP, there may not be an easy way
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 a 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. How ever, configurable upper limit on TTL may not be necessary. However, a
a configurable upper limit on TTL value is an implementation configurable upper limit on the TTL value is an implementation
choice. choice.
3. Identification of the LSP under test: [RFC6425], in Section 3.1, 3. Identification of the LSP under test: Section 3.1 of [RFC6425]
defines distinct identifiers for P2MP RSVP-TE and Multicast LDP defines distinct identifiers for P2MP RSVP-TE and Multicast LDP
when identifying an LSP under test. As each protocol has its own when identifying an LSP under test. As each protocol has its own
identifier, this document introduces a new Target FEC Stack TLV identifier, this document introduces a new Target FEC Stack TLV
specific to SR P2MP Policies to uniquely identify their Candidate specific to SR P2MP Policies to uniquely identify their CPs and
Paths (CPs) and P2MP Tree Instances (PTIs). These modifications PTIs. These modifications ensure that SR P2MP Policy OAM
ensure that SR P2MP Policy OAM mechanisms are properly aligned mechanisms are properly aligned with existing MPLS ping and
with existing MPLS ping and traceroute tools while addressing the traceroute tools while addressing the specific operational
specific operational characteristics of SR P2MP Policies. characteristics of SR P2MP Policies.
3.1.2. Conformance to Existing Procedures and Additional Considerations 3.1.2. Conformance to Existing Procedures and Additional Considerations
In addition to major differences outlined in the previous section, SR In addition to major differences outlined in the previous section, SR
P2MP Policies SHOULD follow to the common procedures specified in P2MP Policies SHOULD follow the common procedures specified in
[RFC6425] for P2MP MPLS LSPs. Furthermore, this specification reuses [RFC6425] for P2MP MPLS LSPs. Furthermore, this specification reuses
the same destination UDP port as defined in [RFC8029] for consistency the same destination UDP port as defined in [RFC8029] for consistency
with existing MPLS OAM mechanism. with the existing MPLS OAM mechanism.
Implementations MUST account for the fact that a SR P2MP Policy may Implementations MUST account for the fact that an SR P2MP Policy may
contain multiple CPs, and each CP may consist of multiple PTIs. As contain multiple CPs, and each CP may consist of multiple PTIs. As
such, implementations SHOULD support the ability to individually test such, implementations SHOULD support the ability to individually test
each CP and its corresponding PTI using ping and traceroute each CP and its corresponding PTI using ping and traceroute
mechanisms. The ping and traceroute packets are forwarded along the mechanisms. The ping and traceroute packets are forwarded along the
specified CP and its PTI, traversing the associated Replication specified CP and its PTI, traversing the associated Replication
Segments. When a downstream node capable of understanding the segments. When a downstream node capable of understanding the
replication SID receives a ping or traceroute packet, it MUST process Replication-SID receives a ping or traceroute packet, it MUST process
the request and generate a response even if the CP and its PTI are the request and generate a response even if the CP and its PTI are
not currently the active path. not currently the active path.
3.1.3. Considerations for Interworking with Unicast paths 3.1.3. Considerations for Interworking with Unicast Paths
As per [draft-ietf-pim-sr-p2mp-policy] there are two ways to build a As per [RFC9960], there are two ways to build a P2MP tree:
P2MP Tree:
1. P2MP Tree with non-adjacent Replication Segments 1. P2MP tree with non-adjacent Replication segments
2. P2MP tree with adjacent Replication Segments 2. P2MP tree with adjacent Replication segments
For the case of adjacent Replication Segments, there are no special For the case of adjacent Replication segments, there are no special
considerations for the TTL or Hop Limit propagation and the TTL considerations for the TTL or Hop Limit propagation, and the TTL
should be decremented hop by hop as the OAM packet traverses the should be decremented hop by hop as the OAM packet traverses the
Replication Segments of a P2MP tree. Replication segments of a P2MP tree.
For the case of non-adjacent Replication Segments, as an example two For the case of non-adjacent Replication segments (for example, two
Replication Segments that are connected via a 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 Tree the non-adjacent Replication segments that are building the P2MP
while the unicast OAM tools should be used to verify the connectivity tree, while the unicast OAM tools should be used to verify the
of unicast path connecting the two non-adjacent Replication Segment. connectivity of the unicast path connecting the two non-adjacent
In these scenarios the Replication SID should not be exposed or Replication segments. In these scenarios, the Replication-SID should
examined in the unicast path. Proper TTL handling to copy the not be exposed or examined in the unicast path. Proper TTL handling
Replication Segment TTL to unicast path can be achieved via to copy the Replication segment TTL to the unicast path can be
hierarchical MPLS TTL mode being used (e.g., Pipe Mode vs. Uniform achieved via the hierarchical MPLS TTL mode being used (e.g., Pipe
Mode) as per [RFC3270]. For the P2MP Tree Traceroute the TTL mode Mode vs. Uniform Mode) as per [RFC3270]. For the P2MP Tree
MUST be set to PIPE mode on the router that the unicast path starts. Traceroute, the TTL mode MUST be set to Pipe Mode on the router that
This will ensure that the unicast path TTL is set to a large value the unicast path starts. This will ensure that the unicast path TTL
that allows the traceroute packet to be delivered to the downstream is set to a large value that allows the traceroute packet to be
Replication Segment. For Ping either the PIPE mode or Uniform mode delivered to the downstream Replication segment. For Ping, either
can be used depending on the implementation. The unicast path the Pipe Mode or the Uniform Mode can be used depending on the
failure detection is considered out of scope for this document. implementation. The unicast path failure detection is considered out
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 follow 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 Multiprotocol Label Switching (MPLS) Label Switched Paths failures in MPLS LSPs. To correctly identify the Replication segment
(LSPs). To correctly identify the Replication Segment associated associated with a given CP and PTI, the echo request message MUST
with a given Candidate Path (CP) and P2MP Tree Instance (PTI), the include a Target FEC Stack TLV that explicitly specifies the
Echo Request message MUST include a Target FEC Stack TLV that candidate path and P2MP tree instance under test.
explicitly specifies the Candidate Path and P2MP Tree Instance 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 |
+----------+----------+-----------------------------------+
Table 1
Further details regarding the structure and processing of this sub- Further details regarding the structure and processing of this sub-
TLV are provided in subsequent sections. TLV are provided in subsequent sections.
3.2.1.1. SR MPLS P2MP Policy Tree Instance FEC Stack Sub-TLVs 3.2.1.1. SR MPLS P2MP Policy Tree Instance FEC Stack Sub-TLVs
The SR MPLS P2MP Policy Tree Instance sub-TLV value field follows the The SR MPLS P2MP Policy Tree Instance sub-TLV value field follows the
format specified in Section 2.3 of [draft-ietf-pim-sr-p2mp-policy]. format specified in Section 2.3 of [RFC9960]. The structure of this
The structure of this sub-TLV is illustrated in the figure below. It sub-TLV is illustrated in the figure below. It should be noted that
should be noted that this sub-TLV is testing a specific PTI within a this sub-TLV is testing a specific PTI within a specific CP and it is
specific CP and it is not testing the CP. not testing the CP.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Address Length| Reserved | | Address Family | Address Length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Root ~ ~ Root ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-ID | | Tree-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance-ID | | Instance-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Address Family: (2 octets) IPv4/IPv6 ADDRESS FAMILY NUMBERS as Address Family: 2 octets. IPv4/IPv6 Address Family Numbers as
specified in [IANA-AF] , indicating the address family of the specified in [IANA-AF], indicating the Address Family of the Root.
Root. Any other Address Family but IPv4/IPv6 is not supported by Any other Address Family, except IPv4/IPv6, is not supported by
this draft. this document.
* Address Length: (1 octet) specifying the length of the Root Address Length: 1 octet. Specifies the length of the Root Address
Address in octets (4 octets for IPv4, 16 octets for IPv6). in octets (4 octets for IPv4, and 16 octets for IPv6).
* Reserved: MUST be set to zero by sender and it should be ignored Reserved: MUST be set to zero by the sender and should be ignored by
by the receiver. the receiver.
* Root: (variable length depending on the address family field) The Root: Variable length depending on the Address Family field. The
root node of the SR P2MP Policy, as defined in Root node of the SR P2MP Policy, as defined in [RFC9960].
[draft-ietf-pim-sr-p2mp-policy]
* Tree-ID: (4 octets) A unique identifier for the P2MP tree, as Tree-ID: 4 octets. A unique identifier for the P2MP tree, as
defined in [draft-ietf-pim-sr-p2mp-policy] defined in [RFC9960].
* Instance-ID: (2 octets) identifies the specific Path-Instance as Instance-ID: 2 octets. Identifies the specific Path-Instance, as
defined in[draft-ietf-pim-sr-p2mp-policy] defined in [RFC9960].
3.3. Limiting the Scope of Response 3.3. Limiting the Scope of Response
As specified in section 3.2 of [RFC6425], four sub-TLVs are used As specified in Section 3.2 of [RFC6425], four sub-TLVs are used
within the P2MP Responder Identifier TLV included in the echo request within the P2MP Responder Identifier TLV that is included in the echo
message. request message.
The Sub-TLVs for IPv4 and IPv6 egress addresses of P2MP responder are The sub-TLVs for IPv4 and IPv6 egress addresses of the P2MP responder
aligned with section 3.2.1 of [RFC6425]. are aligned with Section 3.2.1 of [RFC6425].
The sub-TLVs for IPv4 and IPv6 node addresses of the P2MP responder The sub-TLVs for IPv4 and IPv6 node addresses of the P2MP responder
are aligned with Section 3.2.2 of [RFC6425] are aligned with Section 3.2.2 of [RFC6425].
These mechanisms ensure that responses are appropriately scoped to These mechanisms ensure that responses are appropriately scoped to
limit unnecessary processing and improve the efficiency of P2MP OAM limit unnecessary processing and improve the efficiency of P2MP OAM
procedures. procedures.
4. Implementation Status 4. IANA Considerations
Note to the RFC Editor: please remove this section before
publication. This section records the status of known
implementations of the protocol defined by this specification at the
time of posting of this Internet-Draft, and is based on a proposal
described in RFC7942 . The description of implementations in this
section is intended to assist the IETF in its decision processes in
progressing drafts to RFCs. Please note that the listing of any
individual implementation here does not imply endorsement by the
IETF. Furthermore, no effort has been spent to verify the
information presented here that was supplied by IETF contributors.
This is not intended as, and must not be construed to be, a catalog
of available implementations or their features. Readers are advised
to note that other implementations may exist. According to RFC7942,
"this will allow reviewers and working groups to assign due
consideration to documents that have the benefit of running code,
which may serve as evidence of valuable experimentation and feedback
that have made the implemented protocols more mature. It is up to
the individual working groups to use this information as they see
fit".
4.1. Nokia Implementation
Nokia has implemented [draft-ietf-pim-sr-p2mp-policy] and [RFC9524].
In addition, Nokia has implemented P2MP policy ping as defined in
this draft to verify the end to end connectivity of a P2MP tree in
segment routing domain. The implementation supports SR-MPLS
encapsulation and has all the MUST and SHOULD clause in this draft.
The implementation is at general availability maturity and is
compliant with the latest version of the draft. The documentation
for implementation can be found at Nokia help and the point of
contact is hooman.bidgoli@nokia.com.
5. IANA Consideration
IANA has assigned the code point for the "SR MPLS P2MP Policy Tree
Instance" Sub-TLV Name. This Sub-TLV is assigned from TLV type 1
(Target FEC Stack) from the "Multi-Protocol Label Switching (MPLS)
Label Switched Paths (LSPs) Ping Parameters" registry group. The
Sub-TLVs for TLV type 1 are listed under "Sub-TLVs for TLV Types 1,
16, and 21" sub-registry. This sub-type value is assigned from the
standards Action range of 0-16383 from the "Sub-TLVs for TLV Types 1,
16, and 21" sub-registry.
Sub-Type Sub-TLV Name IANA has assigned a sub-type value for the SR MPLS P2MP Policy Tree
Instance sub-TLV in the "Sub-TLVs for TLV Types 1, 16, and 21"
registry under the "Multiprotocol Label Switching (MPLS) Label
Switched Paths (LSPs) Ping Parameters" registry group. The sub-type
value has been assigned from the Standards Action range of 0-16383 as
shown below. Note that the sub-TLV has been assigned from Type 1
(Target FEC Stack) of the "TLVs" registry.
41 SR MPLS P2MP Policy Tree Instance +==========+===================================+
| Sub-Type | Sub-TLV Name |
+==========+===================================+
| 41 | SR MPLS P2MP Policy Tree Instance |
+----------+-----------------------------------+
6. Security Considerations Table 2
Overall, the security needs for P2MP policy ping are the same as 5. Security Considerations
[draft-ietf-pim-sr-p2mp-policy], [RFC6425] and[RFC8029]. The P2MP
policy ping is susceptible to the same three attack vectors as
explained in [RFC8029] section 5. The same procedures and
recommendations explained in [RFC8029] section 5 should be taken and
implemented to mitigate these attack vectors for P2MP policy Ping as
well.
In addition security considerations of section 8 of [RFC6425] should Overall, the security needs for P2MP policy ping are the same as in
be followed, specifically the security recommendations from [RFC4379] [RFC9960], [RFC6425], and [RFC8029]. P2MP policy ping is susceptible
which recommends "To avoid potential Denial-of-Service attacks, it is to the same three attack vectors as explained in Section 5 of
RECOMMENDED that implementations regulate the LSP ping traffic going [RFC8029]. The same procedures and recommendations explained in
to the control plane. A rate limiter SHOULD be applied to the well- Section 5 of [RFC8029] should be taken and implemented to mitigate
known UDP port" allocated for this service." these attack vectors for P2MP policy ping as well.
7. Acknowledgments In addition, the security considerations in Section 8 of [RFC6425]
should be followed, specifically the security recommendation from
[RFC4379], which recommends "To avoid potential Denial-of-Service
attacks, it is RECOMMENDED 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.
8. References 6. References
8.1. Normative References 6.1. Normative References
[draft-ietf-pim-sr-p2mp-policy] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
"D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang, Requirement Levels", BCP 14, RFC 2119,
"draft-ietf-pim-sr-p2mp-policy"", July 2025. DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] "S. Brandner, "Key words for use in RFCs to Indicate [RFC3270] Le Faucheur, F., Ed., Wu, L., Davie, B., Davari, S.,
Requirement Levels"", March 1997. Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen,
"Multi-Protocol Label Switching (MPLS) Support of
Differentiated Services", RFC 3270, DOI 10.17487/RFC3270,
May 2002, <https://www.rfc-editor.org/info/rfc3270>.
[RFC3270] "F. Le Faucheur, L. Wu, B. Davie "MPLS Support of [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Differentiated Services"", May 2002. Label Switched (MPLS) Data Plane Failures", RFC 4379,
DOI 10.17487/RFC4379, February 2006,
<https://www.rfc-editor.org/info/rfc4379>.
[RFC4379] "K. Kompella, G. Swallow "Detecting MPLS Data Plane [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
Failures"", February 2006. Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
Failures in Point-to-Multipoint MPLS - Extensions to LSP
Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,
<https://www.rfc-editor.org/info/rfc6425>.
[RFC6425] "S. Saxena, G. Swallow, Z. Ali, A. Farrel, S. Yasukawa, [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
T.Nadeau "Detecting Data-Plane Failures in Point-to- Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Multipoint MPLS"", November 2011. Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[RFC8029] "K. Kompella, G. Swallow, C. Pgnataro, N. kumar, S. Aldrin [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
M. Chen, "Detecting Multiprotocol Label Switched (MPLS) 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
Data-Plane Failures.", February 2006. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] "B. Leiba, "ambiguity of Uppercase vs Lowercase in RFC [RFC9524] Voyer, D., Ed., Filsfils, C., Parekh, R., Bidgoli, H., and
2119 Key Words"", May 2017. Z. Zhang, "Segment Routing Replication for Multipoint
Service Delivery", RFC 9524, DOI 10.17487/RFC9524,
February 2024, <https://www.rfc-editor.org/info/rfc9524>.
[RFC9524] "D. Voyer, C. Filsfils, R. Parekh, H. Bidgoli, Z. Zhang, [RFC9960] Parekh, R., Ed., Voyer, D., Ed., Filsfils, C., Bidgoli,
"Segment Routing Replication for Multipoint Service H., and Z. Zhang, "Segment Routing Point-to-Multipoint
Delivery"", February 2024. Policy", RFC 9960, DOI 10.17487/RFC9960, April 2026,
<https://www.rfc-editor.org/info/rfc9960>.
8.2. Informative References 6.2. Informative References
[IANA-AF] "IANA Assigned Port Numbers, [IANA-AF] IANA, "Address Family Numbers",
"http://www.iana.org/assignments/address-family-numbers"". <http://www.iana.org/assignments/address-family-numbers>.
Authors' Addresses Authors' Addresses
Hooman Bidgoli (editor) Hooman Bidgoli (editor)
Nokia Nokia
Ottawa Ottawa
Canada Canada
Email: hooman.bidgoli@nokia.com Email: hooman.bidgoli@nokia.com
Zafar Zafar Ali
Cisco System Cisco System
San Jose, San Jose,
United States of America United States of America
Email: zali@cisco.com Email: zali@cisco.com
Zhaohui Zhang Zhaohui Zhang
Juniper Networks Juniper Networks
Boston, Boston,
United States of America United States of America
Email: zzhang@juniper.net Email: zzhang@juniper.net
 End of changes. 82 change blocks. 
288 lines changed or deleted 264 lines changed or added

This html diff was produced by rfcdiff 1.48.