RFC 9961

MPLS Segment Routing Point-to-Multipoint (P2MP) Policy Ping

📅 published April 2026, from ietf

RFC 9961: MPLS Segment Routing Point-to-Multipoint (P2MP) Policy Ping 💖

Okay bestie, let's start with the basics 🎀 This is RFC 9961, and it's an Internet Standards Track document, so the category is Standards Track. It's an IETF (Internet Engineering Task Force) document dated April 2026, with ISSN 2070-1721 🦋

The authors are H. Bidgoli (editor, Ed.) from Nokia, Z. Ali from Cisco System, Z. Zhang from Juniper Networks, A. Budhiraja from Cisco System, and D. Voyer from Cisco System 🫶 The header doesn't mark it as obsoleting or updating any other RFC.

Abstract ✨

Segment Routing (SR) Point-to-Multipoint (P2MP) Policies are used to define and manage explicit P2MP paths within a network 🛤️ These policies are usually worked out by a controller and installed through a Path Computation Element (PCE) 🧠 In other cases they get installed using the Network Configuration Protocol (NETCONF) / YANG or a Command Line Interface (CLI). Either way, they're the thing that steers Multicast traffic along optimized paths from a Root to a set of Leaf routers 🌸

This document defines extensions to ping and traceroute mechanisms for an SR P2MP Policy with MPLS encapsulation, so it gets Operations, Administration, and Maintenance (OAM) capabilities 💅 The extensions let operators verify connectivity, diagnose failures, and troubleshoot forwarding issues inside SR P2MP Policy Multicast trees 🔍

By introducing new ways to detect failures and validate path integrity, this document makes P2MP Multicast deployments way more operationally robust 👑 It also makes sure that existing MPLS and SR-based OAM tools can actually be used on networks running SR P2MP Policies. Iconic ✨

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF) 🌈 It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841.

For the current status, any errata, and a place to send feedback, go to https://www.rfc-editor.org/info/rfc9961 🦋

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Revised BSD License ⚖️💜

Table of Contents 🧚

   1.  Introduction
     1.1.  Terminology
   2.  Conventions Used in This Document
   3.  Motivation
     3.1.  MPLS SR P2MP Policy Ping and Traceroute
       3.1.1.  Applicability of RFC 6425 to MPLS SR P2MP Policy
       3.1.2.  Conformance to Existing Procedures and Additional
               Considerations
       3.1.3.  Considerations for Interworking with Unicast Paths
     3.2.  Packet Format and New TLVs
       3.2.1.  Identifying a P2MP Policy
         3.2.1.1.  SR MPLS P2MP Policy Tree Instance FEC Stack
                 Sub-TLVs
     3.3.  Limiting the Scope of Response
   4.  IANA Considerations
   5.  Security Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Authors' Addresses

1. Introduction ✨

Okay so [RFC9960] explains the whole concept of the SR P2MP Policy and its candidate paths (CPs) 🧁 It also explains how a CP gets selected to be the active CP. For seamless global optimization, a CP can be made up of multiple P2MP tree instances (PTIs), which lets you do Make-Before-Break procedures between an active PTI and a newly set up, optimized PTI. A PTI is the actual P2MP tunnel that's built from the Root to a set of Leaves through transit routers 🌳 On the Root node, a PTI is identified by its instance ID.

To keep the network reliable, you really need to verify end-to-end connectivity for both active and backup CPs, plus all the PTIs attached to them 💖 This document specifies a mechanism for detecting data plane failures inside an SR P2MP Policy CP and its PTIs, so operators can monitor and troubleshoot Multicast path integrity 🔍

This specification applies only to Replication Segments (Replication-SIDs) that use MPLS encapsulation for forwarding. It does not cover Segment Routing over IPv6 (SRv6) 🙅‍♀️ The mechanisms here build on the concepts from [RFC6425] for P2MP MPLS OAM. All the considerations and limitations in Section 6 of [RFC6425] apply to this document too.

1.1. Terminology

Readers should get familiar with the following documents and sections for terminology and details about how the SR P2MP Policy is implemented 📚

[RFC9524], Section 1.1 defines terms specific to an SR Replication segment. It also explains the node terminology in a Multicast domain, including the Root node, Leaf node, and Bud node.

[RFC9960], Section 1.1 defines terms and concepts specific to the SR P2MP Policy, including the CP and the PTI.

2. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀

3. Motivation 🌸

An SR P2MP Policy and its matching Replication segments are usually provisioned through a centralized controller, or configured using NETCONF/YANG or CLI. The Root and the Leaves are discovered according to [RFC9960], and the Multicast tree is computed from the Root to the Leaves. But here's the tea: there's no underlay signaling protocol to distribute the SR P2MP Policy from the Root to the Leaf routers 😭 So when a P2MP tree fails to deliver user traffic, figuring out what broke is honestly hard without ping and traceroute to isolate faults along the tree.

That's where SR P2MP Policy ping and traceroute come in 🦋 As defined in [RFC9524], they can detect and localize faults within the P2MP tree and its associated Replication segments. These OAM tools run periodic ping operations to verify connectivity between the Root and the Leaves. If a ping fails, you can start a traceroute to find the point of failure along the tree. This diagnostic process can be started from the node that's responsible for establishing the SR P2MP Policy, which gives you proactive monitoring and fault detection ✨

3.1. MPLS SR P2MP Policy Ping and Traceroute

Ping and traceroute packets get forwarded based on the SR P2MP Policy, on a specific CP and its PTI, toward the designated Leaf routers 🧚 At the replication point, these packets are replicated based on the Replication segment forwarding information on the corresponding router.

MPLS packets are handled with standard behavior when their Time to Live (TTL) expires, or when they reach the egress (Leaf) router 💅 The right response then gets sent back to the Root node, following the procedures in [RFC6425].

3.1.1. Applicability of RFC 6425 to MPLS SR P2MP Policy

The procedures in [RFC6425] define fault detection and isolation mechanisms for P2MP MPLS Label Switched Paths (LSPs). They extend the LSP ping techniques described in [RFC8029] so they can be applied to P2MP MPLS LSPs, which keeps everything lined up with existing fault management tools 🫶 [RFC6425] really leans into reusing existing LSP ping mechanisms that were designed for Point-to-Point (P2P) LSPs, and adapting them to P2MP MPLS LSPs so implementation and network operation stay seamless 🌈

The fault detection procedures in [RFC6425] apply to all P2MP MPLS protocols, including P2MP RSVP-TE and Multicast LDP, and now the SR P2MP Policy too. [RFC6425] calls out specific differences for P2MP RSVP-TE and Multicast LDP, but this document adds considerations that are unique to SR P2MP Policies. Here they are 👑

  1. Egress Address P2MP Responder sub-TLVs: Multicast LDP, as per Section 3.2.1 of [RFC6425], does not allow Egress Address P2MP Responder sub-TLVs to be included, because upstream Label Switching Routers (LSRs) have no visibility into downstream Leaf nodes. SR P2MP Policies also often rely on a PCE for programming transit routers, so in the SR P2MP domain, transit routers don't know about the Leaf nodes. Only the Root node, where the SR P2MP Policy is programmed, can see the Leaf nodes. That means these sub-TLVs SHOULD NOT be used when an echo request carries an SR P2MP Policy MPLS CP Forwarding Equivalence Class (FEC). If a node receives the Egress Address P2MP Responder sub-TLVs in an echo request, it won't respond, because it has no idea whether it sits on the path to the address in the sub-TLV 🙈
  2. End of processing for traceroutes: As per Section 4.3.1 of [RFC6425], it is RECOMMENDED that traceroute operations provide a configurable upper limit on TTL values. The reason is that for some protocols like Multicast LDP, there may not be an easy way to figure out where traceroute processing ends, since the initiating LSR might not always know about all of the Leaf routers. With an SR P2MP Policy, the Root node has visibility of the Leaf nodes, so there's a definitive way to estimate the end of traceroute processing, and a configurable upper limit on TTL may not be necessary. That said, a configurable upper limit on the TTL value is an implementation choice 🧠
  3. Identification of the LSP under test: Section 3.1 of [RFC6425] defines distinct identifiers for P2MP RSVP-TE and Multicast LDP when identifying an LSP under test. Since each protocol has its own identifier, this document introduces a new Target FEC Stack TLV specific to SR P2MP Policies, so their CPs and PTIs can be uniquely identified 💖 These changes keep SR P2MP Policy OAM properly aligned with existing MPLS ping and traceroute tools, while still addressing the specific operational characteristics of SR P2MP Policies 🎀
Part 1 ends here, more to come 🫶

3.1.2. Conformance to Existing Procedures and Additional Considerations

Okay so, besides the big differences we just covered 💅, SR P2MP Policies SHOULD follow the common procedures in [RFC6425] for P2MP MPLS LSPs ✨. This spec also reuses the same destination UDP port from [RFC8029], so it stays consistent with the existing MPLS OAM mechanism 🫶.

Implementations MUST account for the fact that an SR P2MP Policy can have multiple CPs, and each CP can have multiple PTIs 🌸. That means implementations SHOULD support testing each CP and its PTI individually with ping and traceroute 🔍. The ping and traceroute packets get forwarded along the specified CP and its PTI, going through the associated Replication segments 🦋. When a downstream node that understands the Replication-SID gets a ping or traceroute packet, it MUST process the request and generate a response, even if that CP and PTI aren't the active path 👑. Yes, even the backup. Periodt 💀.

3.1.3. Considerations for Interworking with Unicast Paths

Bestie, [RFC9960] says there are two ways to build a P2MP tree 🧚:

  1. P2MP tree with non-adjacent Replication segments
  2. P2MP tree with adjacent Replication segments

For adjacent Replication segments, there are no special considerations for TTL or Hop Limit propagation 🍓. The TTL should be decremented hop by hop as the OAM packet travels across the Replication segments of a P2MP tree.

For non-adjacent Replication segments, it gets a little more dramatic 😭. Think two Replication segments connected via an SR Policy or a similar technology. In that case SR P2MP Policy OAM tools should be used to verify the connectivity of the non-adjacent Replication segments that build the P2MP tree, while the unicast OAM tools should be used to verify the connectivity of the unicast path between those two segments. The Replication-SID should not be exposed or examined in the unicast path 🙈.

Proper TTL handling, where the Replication segment TTL gets copied to the unicast path, can be done with the hierarchical MPLS TTL mode you're using (like Pipe Mode vs. Uniform Mode) per [RFC3270] ✨. For the P2MP tree traceroute, the TTL mode MUST be set to Pipe Mode on the router where the unicast path starts. This makes sure the unicast path TTL is set to a large value, so the traceroute packet can actually reach the downstream Replication segment 🚀. For ping, either Pipe Mode or Uniform Mode can be used, depending on the implementation. And the unicast path failure detection is considered out of scope for this document, so that's a different story, iykyk 🌈.

3.2. Packet Format and New TLVs

The packet format in this specification follows Section 3 of [RFC8029]. However, extra TLVs and sub-TLVs are required to support the new functionality for SR P2MP Policies 💖. These extensions are described in the following sections.

3.2.1. Identifying a P2MP Policy

[RFC8029] defines a standardized way to detect data plane failures in MPLS LSPs 🔎. To correctly identify the Replication segment associated with a given CP and PTI, the echo request message MUST include a Target FEC Stack TLV that explicitly specifies the CP and PTI under test 🎯.

This document introduces a new sub-TLV called the SR MPLS P2MP Policy Tree Instance sub-TLV, defined like this 🎀:

        +==========+==========+===================================+
        | Sub-Type | Length   | Value Field                       |
        +==========+==========+===================================+
        | 41       | Variable | SR MPLS P2MP Policy Tree Instance |
        +----------+----------+-----------------------------------+

                                  Table 1

More details about how this sub-TLV is structured and processed come in the next sections 🧁.

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 format in Section 2.3 of [RFC9960] 💅. Here's the layout 👇. Important note: this sub-TLV is testing a specific PTI within a specific CP, and it is not testing the CP itself 🙈.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Address Family         | Address Length|   Reserved    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                            Root                               ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Tree-ID                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Instance-ID               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Now the field breakdown 📋:

  • Address Family: 2 octets 🌷. This is an IPv4/IPv6 Address Family Number from [IANA-AF], telling you the Address Family of the Root. Any other Address Family, except IPv4/IPv6, is not supported by this document 🚫.
  • Address Length: 1 octet 📏. It's the length of the Root Address in octets, so 4 octets for IPv4 and 16 octets for IPv6.
  • Reserved: MUST be set to zero by the sender, and should be ignored by the receiver 🫧.
  • Root: variable length, depending on the Address Family field 🌳. This is the Root node of the SR P2MP Policy, as defined in [RFC9960].
  • Tree-ID: 4 octets 🆔. A unique identifier for the P2MP tree, as defined in [RFC9960].
  • Instance-ID: 2 octets 🦋. It identifies the specific Path-Instance, as defined in [RFC9960].

3.3. Limiting the Scope of Response

As specified in Section 3.2 of [RFC6425], four sub-TLVs are used within the P2MP Responder Identifier TLV that gets included in the echo request message 🍰.

The sub-TLVs for IPv4 and IPv6 egress addresses of the P2MP responder line up with Section 3.2.1 of [RFC6425] ✨. The sub-TLVs for IPv4 and IPv6 node addresses of the P2MP responder line up with Section 3.2.2 of [RFC6425] 💜.

These mechanisms make sure responses are scoped properly, so there's less unnecessary processing and P2MP OAM procedures run more efficiently 🚀.

4. IANA Considerations ✨

IANA has assigned a sub-type value for the SR MPLS P2MP Policy Tree Instance sub-TLV 🏷️. It lives 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 came from the Standards Action range of 0-16383, as shown below 👑. Also, the sub-TLV was assigned from Type 1 (Target FEC Stack) of the "TLVs" registry.

             +==========+===================================+
             | Sub-Type | Sub-TLV Name                      |
             +==========+===================================+
             | 41       | SR MPLS P2MP Policy Tree Instance |
             +----------+-----------------------------------+

                                 Table 2

5. Security Considerations 🔐

Okay, security time, and I'm not playing 😤. Overall, the security needs for SR P2MP Policy ping are the same as in [RFC9960], [RFC6425], and [RFC8029] 🛡️. SR P2MP Policy ping is susceptible to the same three attack vectors explained in Section 5 of [RFC8029]. The same procedures and recommendations from Section 5 of [RFC8029] should be taken and implemented to mitigate these attack vectors for SR P2MP Policy ping as well.

On top of that, the security considerations in Section 8 of [RFC6425] should be followed. Specifically, you should take the security recommendations from [RFC4379] seriously, and they say this 💀:

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].

6. References 📚

6.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3270]  Le Faucheur, F., Ed., Wu, L., Davie, B., Davari, S.,
           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>.

[RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
           Label Switched (MPLS) Data Plane Failures", RFC 4379,
           DOI 10.17487/RFC4379, February 2006,
           <https://www.rfc-editor.org/info/rfc4379>.

[RFC6425]  Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
           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>.

[RFC8029]  Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
           Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
           Switched (MPLS) Data-Plane Failures", RFC 8029,
           DOI 10.17487/RFC8029, March 2017,
           <https://www.rfc-editor.org/info/rfc8029>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9524]  Voyer, D., Ed., Filsfils, C., Parekh, R., Bidgoli, H., and
           Z. Zhang, "Segment Routing Replication for Multipoint
           Service Delivery", RFC 9524, DOI 10.17487/RFC9524,
           February 2024, <https://www.rfc-editor.org/info/rfc9524>.

[RFC9960]  Parekh, R., Ed., Voyer, D., Ed., Filsfils, C., Bidgoli,
           H., and Z. Zhang, "Segment Routing Point-to-Multipoint
           Policy", RFC 9960, DOI 10.17487/RFC9960, April 2026,
           <https://www.rfc-editor.org/info/rfc9960>.

6.2. Informative References

[IANA-AF]  IANA, "Address Family Numbers",
           <http://www.iana.org/assignments/address-family-numbers>.

Authors' Addresses 💌

Hooman Bidgoli (editor)
Nokia
Ottawa
Canada
Email: hooman.bidgoli@nokia.com


Zafar Ali
Cisco System
San Jose,
United States of America
Email: zali@cisco.com


Zhaohui Zhang
Juniper Networks
Boston,
United States of America
Email: zzhang@juniper.net


Anuj Budhiraja
Cisco System
San Jose,
United States of America
Email: abudhira@cisco.com


Daniel Voyer
Cisco System
Montreal
Canada
Email: davoyer@cisco.com
📦 where this page comes from