<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-pim-p2mp-policy-ping-25"
     ipr="trust200902"> number="9961" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <front>

<!--[rfced] Since the running text uses "SR P2MP Policy ping and
traceroute" and "P2MP policy ping" (both without "MPLS"), should
the document title be updated as shown below for consistency?

Since "traceroute" is mentioned in the Abstract and with ping in
the running text, should it be included in the title as well?
(Note that if "traceroute" is included, we will update the short
title that spans the header of the PDF file to include it as well.)

Also, would you like to add the abbreviation for "Segment Routing"
since "(P2MP)" is included for "Point-to-Multipoint"?

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

Perhaps:
   MPLS Segment Routing (SR) Point-to-Multipoint (P2MP) Policy
   Ping and Traceroute
-->

    <title abbrev="P2MP Policy Ping">Segment Routing MPLS Point-to-Multipoint
    (P2MP) Policy Ping</title>
    <seriesInfo name="RFC" value="9961"/>
    <author fullname="Hooman Bidgoli" initials="H" role="editor" surname="Bidgoli">
      <organization>Nokia</organization>
      <address>
        <postal>
          <street/>
          <city>Ottawa</city>

          <region/>

          <code/>
          <country>Canada</country>
        </postal>

        <phone/>
        <email>hooman.bidgoli@nokia.com</email>
      </address>
    </author>
    <author fullname="Zafar" fullname="Zafar Ali" initials="Z." surname="Ali">
      <organization>Cisco System</organization>
      <address>
        <postal>
          <street/>
          <city>San Jose</city>

          <region/>

          <code/>

          <country>USA</country>
          <country>United States of America</country>
        </postal>

        <phone/>

        <facsimile/>
        <email>zali@cisco.com</email>

        <uri/>
      </address>
    </author>
    <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street/>
          <city>Boston</city>

          <region/>

          <code/>

          <country>USA</country>
          <country>United States of America</country>
        </postal>

        <phone/>

        <facsimile/>
        <email>zzhang@juniper.net</email>

        <uri/>
      </address>
    </author>
    <author fullname="Anuj Budhiraja" initials="A." surname="BudhirajaC">
      <organization>Cisco System</organization>
      <address>
        <postal>
          <street/>
          <city>San Jose</city>

          <region/>

          <code/>

          <country>USA</country>
          <country>United States of America</country>
        </postal>

        <phone/>

        <facsimile/>
        <email>abudhira@cisco.com</email>

        <uri/>
      </address>
    </author>
    <author fullname="Daniel Voyer" initials="D" surname="Voyer">
      <organization>Cisco System</organization>
      <address>
        <postal>
          <street/>
          <city>Montreal</city>

          <region/>

          <code/>
          <country>Canada</country>
        </postal>

        <phone/>

        <facsimile/>
        <email>davoyer@cisco.com</email>

        <uri/>
      </address>
    </author>
    <date day="09" month="October" year="2025"/> month="April" year="2026"/>
    <area>RTG</area>
    <workgroup>pim</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <t>SR
      <t>Segment Routing (SR) Point-to-Multipoint (P2MP) Policies are used to define and manage
      explicit P2MP paths within a network. These policies are typically
      calculated via a controller-based mechanism and installed via, e.g., a
      Path Computation Element (PCE). In other cases cases, these policies can be
      installed via using NETCONF/YANG the Network Configuration Protocol (NETCONF) / YANG or CLI. a Command Line Interface (CLI).
      They are used to steer
      multicast traffic along optimized paths from a Root to a set of Leaf
      routers.</t>
      <t>This document defines extensions to Ping and Traceroute mechanisms
      for an SR P2MP Policy with MPLS encapsulation to provide OAM (Operations, Operations,
      Administration, and Maintenance) Maintenance (OAM) capabilities. The extensions enable
      operators to verify connectivity, diagnose failures failures, and troubleshoot
      forwarding issues within SR P2MP Policy multicast trees.</t>
      <t>By introducing new mechanisms for detecting failures and validating
      path integrity, this document enhances the operational robustness of
      P2MP multicast deployments. Additionally, it ensures that existing MPLS
      and SR-based OAM tools can be effectively applied to networks utilizing
      SR P2MP Policies.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
      <!-- 1 --> numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="draft-ietf-pim-sr-p2mp-policy"/> target="RFC9960" format="default"/> explains the concept
      of the SR P2MP Policy and its Candidate Paths candidate paths (CPs). It also explains
      the concept of how a CP is selected to be the active CP. To enable
      seamless global optimization optimization, a CP may consist of multiple P2MP Tree
      Instances tree
      instances (PTIs), allowing for Make-Before-Break (MBB) procedures
      between an active 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. A PTI is identified on the Root node by the PTI's
      instance ID.</t>
      <t>To ensure reliable network operation, it is essential to verify
      end-to-end connectivity for both active and backup CPs, as well as all
      associated PTIs. This document specifies a mechanism for detecting data
      plane failures within a an SR P2MP Policy CP and its associated PTIs,
      enabling operators to monitor and troubleshoot multicast path
      integrity.</t>

      <t>This

<!--[rfced] Should "Replication Segments (Replication SIDs)" be
updated as "Replication segment identifiers (Replication-SIDs)"
(option A) or "Replication segments (i.e., Replication segment
identifiers (Replication-SIDs)) (option B) for clarity?

Original:
   This specification applies exclusively to Replication Segments
   (Replication SIDs) that use MPLS encapsulation for forwarding and does
   not cover Segment Routing over IPv6 (SRv6).

Perhaps A:
   This specification applies exclusively to Replication segment identifiers
   (Replication-SIDs) that use MPLS encapsulation for forwarding and does
   not cover Segment Routing over IPv6 (SRv6).

or
Perhaps B:
   This specification applies exclusively to Replication segments
   (i.e., Replication segment identifiers (Replication-SIDs)) that
   use MPLS encapsulation for forwarding and does not cover Segment
   Routing over IPv6 (SRv6).
-->

      <t>This specification applies exclusively to Replication Segments
      (Replication-SIDs) that use MPLS encapsulation for forwarding and does
      not cover Segment Routing over IPv6 (SRv6). The mechanisms described
      herein build upon the concepts established in <xref target="RFC6425"/> target="RFC6425" format="default"/>
      for P2MP MPLS Operations, Administration, and Maintenance (OAM). All
      considerations and limitations described in section 6 of <xref
      target="RFC6425"/> target="RFC6425" section="6"/> apply to this document as well.</t>
      <section title="Terminology "> numbered="true" toc="default">
        <name>Terminology</name>
        <t>The readers of this document should familiarize themselves with the
        following documents and sections for terminology and details regarding the
        implementation of the SR P2MP Policy</t> Policy.</t>
        <t><xref target="RFC9524"/> section 1.1 target="RFC9524" section="1.1" sectionFormat="comma"/> defines terms specific to an SR
        Replication Segment segment and also explains the Node node terminology in a
        Multicast domain, including the Root Node, node, Leaf Node node, and a Bud
        Node.</t>

        <t><xref target="draft-ietf-pim-sr-p2mp-policy"> </xref>
        node.</t>

<!-- [rfced] FYI - We have updated this citation to point to Section 1.1
of RFC-to-be 9960 (the Terminology section.) Please review and
let us know of any objections.

Original:
   [draft-ietf-pim-sr-p2mp-policy] section 2, defines terms and concepts
   specific to SR P2MP Policy including the CP and the PTI.

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

        <t><xref target="RFC9960" section="1.1" sectionFormat="comma"/>
        defines terms and concepts specific to the SR P2MP Policy including the CP
        and the PTI.</t>
      </section>
    </section>
    <section title="Conventions used numbered="true" toc="default">
      <name>Conventions Used in this document">
      <!-- 2 -->

      <t>The This Document</name>
      <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
      "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.</t> here.
</t>
    </section>
    <section title="Motivation">
      <!-- 3-->

      <t>A numbered="true" toc="default">
      <name>Motivation</name>

      <t>An SR P2MP Policy and its corresponding Replication Segments segments are
      typically provisioned via a centralized controller or configured using
      NETCONF/YANG or CLI. The root Root and the leaves Leaves are discovered in
      accordance with <xref target="draft-ietf-pim-sr-p2mp-policy"/> target="RFC9960" format="default"/>, and the
      multicast tree is computed from the root Root to the leaves. Leaves. However, there
      is no underlay signaling protocol to distribute the SR P2MP Policy from
      the root Root to the leaf Leaf routers. Consequently, when a P2MP tree fails to
      deliver user traffic, identifying the failure can be challenging without
      ping and traceroute mechanisms to isolate faults along the tree.</t>
      <t>To address this challenge, SR P2MP Policy ping and traceroute can be
      utilized to detect and localize faults within the P2MP tree and its
      associated Replication Segments, segments, as defined in <xref target="RFC9524"/>. target="RFC9524" format="default"/>.
      These OAM tools enable periodic ping operations to verify connectivity
      between the root Root and the leaves. Leaves. In cases where a ping fails, a
      traceroute can be initiated to determine the point of failure along the
      tree. This diagnostic process can be initiated from the node responsible
      for establishing the SR P2MP Policy, ensuring proactive monitoring and
      fault detection.</t>
      <section title="MPLS numbered="true" toc="default">

<!--[rfced] Should "SR" be added to the title of Section 3.1 for
consistency with the running text?

Original:
   3.1.  MPLS P2MP Policy Ping and Traceroute">
        <!-- 3.1 Traceroute

Perhaps:
   3.1.  MPLS SR P2MP Policy Ping and Traceroute
-->

        <name>MPLS P2MP Policy Ping and Traceroute</name>
        <t>Ping/Traceroute packets are forwarded based upon the SR P2MP
        Policy,
        Policy on a specific CP and its PTI toward the designated leaf Leaf
        routers. These packets are replicated at the replication point based
        on the Replication Segment segment forwarding information on the corresponding
        router.</t>
        <t>MPLS Packets packets are processed based on the standard behavior when
        their Time-to-Live Time to Live (TTL) expires or when they reach the egress (leaf) (Leaf)
        router. The appropriate response is sent back to the root Root node
        following the procedures outlined in <xref target="RFC6425"/>.</t> target="RFC6425" format="default"/>.</t>
        <section title="Applicability numbered="true" toc="default">

<!--[rfced] Please clarify what "Current RFC" refers to in the title
of current Section 3.1.1.

Original:
   3.1.1.  Applicability of the Current RFC to SR P2MP Policies">
          <!-- 3.1.1 Policies
-->

          <name>Applicability of the Current RFC to SR P2MP Policies</name>
          <t>The procedures in <xref target="RFC6425"/> target="RFC6425" format="default"/> define fault detection
          and isolation mechanisms for P2MP MPLS LSPs Label Switched Paths (LSPs) and extend the LSP ping
          techniques described in <xref target="RFC8029"/> target="RFC8029" format="default"/> such that they may
          be applied to P2MP MPLS LSPs, ensuring alignment with existing fault
          management tools. <xref target="RFC6425"/> target="RFC6425" format="default"/> emphasizes the reuse of
          existing LSP ping mechanisms designed for Point-to-Point P2P (P2P) LSPs,
          adapting them to P2MP MPLS LSPs to facilitate seamless
          implementation and network operation.</t>
          <t>The fault detection procedures specified in <xref
          target="RFC6425"/> target="RFC6425" format="default"/> are applicable to all P2MP MPLS protocols,
          including P2MP RSVP-TE and Multicast LDP and now the SR P2MP SR Policy.
          While <xref target="RFC6425"/> target="RFC6425" format="default"/> highlights specific differences for
          P2MP RSVP-TE and Multicast LDP, this document introduces
          considerations unique to SR P2MP Policies, including:</t>

          <t><list style="numbers">
          <ol spacing="normal" type="1"><li>
              <t>Egress Address P2MP Responder Sub-TLVs: sub-TLVs: Multicast LDP, as per
              section 3.2.1 of
              <xref target="RFC6425"/>, target="RFC6425" section="3.2.1" sectionFormat="of"/>, does not allow for
              the inclusion of Egress Address P2MP Responder Sub-TLVs, sub-TLVs, as
              upstream LSRs Label Switching Routers (LSRs) lack visibility into downstream leaf Leaf nodes.
              Similarly, SR P2MP Policies often rely on a Path Computation
              Element (PCE) for programming transit routers. This is why in the SR
              P2MP domain, transit routers do not have knowledge of the leaf Leaf
              nodes. Only the Root node, where the SR P2MP Policy is
              programmed, has visibility into the leaf Leaf nodes. Consequently,
              these Sub-TLVs SHOULD NOT sub-TLVs <bcp14>SHOULD NOT</bcp14> be used when an echo request carries a an
              SR P2MP Policy MPLS Candidate Path FEC. Forwarding Equivalence Class (FEC). If a node receives the
              Egress Address P2MP Responder Sub-TLVs sub-TLVs in an echo request, then
              it will not respond since it is unaware of whether it lies on
              the path to the address in the sub-TLV.</t>
            </li>
            <li>
              <t>End of Processing for Traceroutes: As per section 4.3.1 of
              <xref target="RFC6425"/>, target="RFC6425" section="4.3.1" sectionFormat="of"/>, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that for traceroute
              orations provide for a configurable upper limit on TTL values.
              This is because because, for some protocols like Multicast LDP, there may
              not be an easy way to figure out the end of the traceroute
              processing
              processing, as the initiating LSR might not always know about all
              of the leaf Leaf routers. In the case of a an SR P2MP Policy Policy, the Root
              node has visibility of the leaf nodes, Leaf nodes; as such such, there is a
              definitive way to estimate the end of processing for a
              traceroute
              traceroute, and a configurable upper limit on TTL may not be
              necessary. How ever, However, a configurable upper limit on the TTL value is
              an implementation choice.</t>
            </li>
            <li>
              <t>Identification of the LSP under test: <xref
              target="RFC6425"/>, in Section 3.1, target="RFC6425"
              section="3.1" sectionFormat="of"/> defines distinct identifiers for P2MP RSVP-TE
              and Multicast LDP when identifying an LSP under test. As each
              protocol has its own identifier, this document introduces a new
              Target FEC Stack TLV specific to SR P2MP Policies to uniquely
              identify their Candidate Paths (CPs) CPs and
              P2MP Tree Instances (PTIs). PTIs. These modifications ensure that
	      SR P2MP Policy OAM
              mechanisms are properly aligned with existing MPLS ping and
              traceroute tools while addressing the specific operational
              characteristics of SR P2MP Policies.</t>
            </list></t>
            </li>
          </ol>
        </section>
        <section title="Conformance numbered="true" toc="default">
          <name>Conformance to Existing Procedures and Additional Considerations">
          <!-- 3.1.2 --> Considerations</name>

          <t>In addition to major differences outlined in the previous
          section, SR P2MP Policies SHOULD <bcp14>SHOULD</bcp14> follow to the common procedures
          specified in <xref target="RFC6425"/> target="RFC6425" format="default"/> for P2MP MPLS LSPs.
          Furthermore, this specification reuses the same destination UDP port
          as defined in <xref target="RFC8029"> target="RFC8029" format="default"> </xref> for consistency with
          the existing MPLS OAM mechanism.</t>
          <t>Implementations MUST <bcp14>MUST</bcp14> account for the fact that a an SR P2MP Policy
          may contain multiple CPs, and each CP may consist of multiple PTIs.
          As such, implementations SHOULD <bcp14>SHOULD</bcp14> support the ability to individually
          test each CP and its corresponding PTI using ping and traceroute
          mechanisms. The ping and traceroute packets are forwarded along the
          specified CP and its PTI, traversing the associated Replication
          Segments.
          segments. When a downstream node capable of understanding the
          replication SID
          Replication-SID receives a ping or traceroute packet, it MUST <bcp14>MUST</bcp14>
          process the request and generate a response even if the CP and its
          PTI are not currently the active path.</t>
        </section>
        <section title="Considerations numbered="true" toc="default">
          <name>Considerations for Interworking with Unicast paths"> Paths</name>
          <t>As per <xref target="draft-ietf-pim-sr-p2mp-policy"/> target="RFC9960" format="default"/>, there are
          two ways to build a P2MP Tree:</t>

          <t><list style="numbers"> tree:</t>
          <ol spacing="normal" type="1"><li>
              <t>P2MP Tree tree with non-adjacent Replication Segments</t> segments</t>
            </li>
            <li>
              <t>P2MP tree with adjacent Replication Segments</t>
            </list></t> segments</t>
            </li>
          </ol>
          <t>For the case of adjacent Replication Segments, segments, there are no
          special considerations for the TTL or Hop Limit propagation propagation, and the
          TTL should be decremented hop by hop as the OAM packet traverses the
          Replication Segments segments of a P2MP tree.</t>
          <t>For the case of non-adjacent Replication Segments, as an example segments (for example,
          two Replication Segments segments that are connected via a an SR Policy or
          similar technology, technology), there are special considerations. In such
          scenarios, SR P2MP Policy OAM tools should be used to verify the
          connectivity of the non-adjacent Replication Segments segments that are
          building the P2MP Tree tree, while the unicast OAM tools should be used to
          verify the connectivity of the unicast path connecting the two
          non-adjacent Replication Segment. segments. In these scenarios scenarios, the Replication
          SID Replication-SID
          should not be exposed or examined in the unicast path. Proper
          TTL handling to copy the Replication Segment segment TTL to the unicast path can
          be achieved via the hierarchical MPLS TTL mode being used (e.g., Pipe
          Mode vs. Uniform Mode) as per <xref target="RFC3270"/>. target="RFC3270" format="default"/>. For the P2MP
          Tree Traceroute Traceroute, the TTL mode MUST <bcp14>MUST</bcp14> be set to PIPE mode Pipe Mode on the router
          that 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
          delivered to the downstream Replication Segment. segment. For Ping Ping, either the
          PIPE mode
          Pipe Mode or the Uniform mode Mode can be used depending on the
          implementation. The unicast path failure detection is considered out
          of scope for this document.</t>
        </section>
      </section>
      <section title="Packet format numbered="true" toc="default">
        <name>Packet Format and new TLVs"> New TLVs</name>
        <t>The packet format used in this specification follow section 3 of follows
        <xref target="RFC8029"/>. target="RFC8029" section="3" sectionFormat="of"/>. However, additional TLVs and sub-TLVs are
        required to support the new functionality introduced for SR P2MP
        Policies. These extensions are described in the following
        sections.</t>
        <section title="Identifying numbered="true" toc="default">
          <name>Identifying a P2MP Policy">
          <!-- 3.1 --> Policy</name>

          <t><xref target="RFC8029"/> target="RFC8029" format="default"/> defines a standardized mechanism for
          detecting data-plane data plane failures in Multiprotocol Label Switching
          (MPLS) Label Switched Paths (LSPs). MPLS LSPs. To correctly identify the
          Replication Segment segment associated with a given Candidate Path (CP) CP and
          P2MP Tree Instance (PTI),
          PTI, the Echo Request echo request message MUST <bcp14>MUST</bcp14> include a
          Target FEC Stack TLV that explicitly specifies the Candidate Path candidate path
          and P2MP Tree Instance tree instance under test.</t>
          <t>This document introduces a new sub-TLV, referred to as the SR
          MPLS P2MP Policy Tree Instance sub-TLV, which is defined as
          follows:</t>

          <figure>
            <artwork><![CDATA[Sub-Type       Length            Value Field
--------       ------            -----------
    41        Variable          SR
<table>
  <thead>
    <tr>
      <th>Sub-Type</th>
      <th>Length</th>
      <th>Value Field</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>41</td>
      <td>Variable</td>
      <td>SR MPLS P2MP Policy Tree Instance
]]></artwork>
          </figure> Instance</td>
    </tr>
  </tbody>
</table>
          <t>Further details regarding the structure and processing of this
          sub-TLV are provided in subsequent sections.</t>
          <section title="SR numbered="true" toc="default">
            <name>SR MPLS P2MP Policy Tree Instance FEC Stack Sub-TLVs"> Sub-TLVs</name>
            <t>The SR MPLS P2MP Policy Tree Instance sub-TLV value field
            follows the format specified in Section 2.3 of <xref
            target="draft-ietf-pim-sr-p2mp-policy"/>. section="2.3" target="RFC9960" format="default" sectionFormat="of"/>. The structure of this
            sub-TLV is illustrated in the figure below. It should be noted
            that this sub-TLV is testing a specific PTI within a specific CP
            and it is not testing the CP.</t>

            <t><figure>
                <artwork><![CDATA[
            <artwork name="" type="" align="left" alt=""><![CDATA[    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               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
              </figure></t>

            <t><list style="symbols">
                <t>Address Family: (2 octets)
            <dl spacing="normal" newline="false">
              <dt>Address Family:</dt><dd>2 octets. IPv4/IPv6 ADDRESS FAMILY NUMBERS Address Family
              Numbers as specified in <xref target="IANA-AF"/> , target="IANA-AF"
              format="default"/>, indicating the
                address family Address Family of the
              Root. Any other Address Family but
                IPv4/IPv6 Family, except IPv4/IPv6, is not supported by
              this draft.</t>

                <t>Address Length: (1 octet) specifying document.</dd>
              <dt>Address Length:</dt><dd>1 octet. Specifies the length of
              the Root Address in octets (4 octets for IPv4, and 16 octets for IPv6).</t>

                <t>Reserved: MUST
              IPv6).</dd>
              <dt>Reserved:</dt><dd><bcp14>MUST</bcp14> be set to zero by the
              sender and it should be ignored by the receiver.</t>

                <t>Root: (variable receiver.</dd>
              <dt>Root:</dt><dd>Variable length depending on the address family
                field) Address
              Family field. The root Root node of the SR P2MP Policy, as defined in
              <xref target="draft-ietf-pim-sr-p2mp-policy"/></t>

                <t>Tree-ID: (4 octets) target="RFC9960"
              format="default"/>.</dd>
              <dt>Tree-ID:</dt><dd>4 octets. A unique identifier for the P2MP
              tree, as defined in <xref
                target="draft-ietf-pim-sr-p2mp-policy"/></t>

                <t>Instance-ID: (2 octets) identifies target="RFC9960"
              format="default"/>.</dd>
              <dt>Instance-ID:</dt><dd>2 octets. Identifies the specific
                Path-Instance
              Path-Instance, as defined in<xref
                target="draft-ietf-pim-sr-p2mp-policy"/></t>
              </list></t> in <xref
              target="RFC9960" format="default"/>.</dd>
            </dl>
          </section>
        </section>
      </section>
      <section title="Limiting numbered="true" toc="default">
        <name>Limiting the Scope of Response">
        <!-- 3.2 --> Response</name>

        <t>As specified in section 3.2 of <xref target="RFC6425"/>, target="RFC6425" section="3.2" sectionFormat="of"/>, four
        sub-TLVs are used within the P2MP Responder Identifier TLV that is included in
        the echo request message.</t>
        <t>The Sub-TLVs sub-TLVs for IPv4 and IPv6 egress addresses of the P2MP responder
        are aligned with section 3.2.1 of <xref target="RFC6425"/>.</t> target="RFC6425" section="3.2.1" sectionFormat="of"/>.</t>
        <t>The sub-TLVs for IPv4 and IPv6 node addresses of the P2MP responder
        are aligned with Section 3.2.2 of <xref target="RFC6425"/></t> target="RFC6425" section="3.2.2" sectionFormat="of"/>.</t>
        <t>These mechanisms ensure that responses are appropriately scoped to
        limit unnecessary processing and improve the efficiency of P2MP OAM
        procedures.</t>
      </section>
    </section>

    <section title="Implementation Status">
      <t>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".</t>

      <section title="Nokia Implementation">
        <t>Nokia has implemented <xref
        target="draft-ietf-pim-sr-p2mp-policy"/> and <xref target="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.</t>
      </section>
    </section>

    <section title="IANA Consideration">
      <!-- 6 -->

      <t>IANA numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
      IANA has assigned the code point a sub-type value for the "SR SR MPLS P2MP Policy
      Tree
      Instance" Sub-TLV Name. This Sub-TLV is assigned from Instance sub-TLV in
      the "Sub-TLVs for TLV type 1 (Target
      FEC Stack) from Types 1, 16, and 21" registry under the "Multi-Protocol "Multiprotocol
      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 has been assigned from the standards 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 "Sub-TLVs for TLV Types 1, 16, and 21"
      sub-registry.</t>

      <t>Sub-Type Sub-TLV Name</t>

      <t>41 SR "TLVs" registry.

      </t>
<table>
  <thead>
    <tr><th>Sub-Type</th><th>Sub-TLV Name</th></tr>
  </thead>
  <tbody>
    <tr><td>41</td><td>SR MPLS P2MP Policy Tree Instance</t> Instance</td></tr>
  </tbody>
</table>
    </section>
    <section title="Security Considerations">
      <!-- 8 --> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Overall, the security needs for P2MP policy ping are the same as in
      <xref target="draft-ietf-pim-sr-p2mp-policy"/>, target="RFC9960" format="default"/>, <xref target="RFC6425"/>
      and<xref target="RFC8029"> target="RFC6425" format="default"/>,
      and <xref target="RFC8029" format="default"> </xref>. The P2MP policy ping is susceptible
      to the same three attack vectors as explained in <xref
      target="RFC8029"/> section 5. target="RFC8029" section="5" sectionFormat="of"/>. The same procedures and recommendations
      explained in <xref target="RFC8029"/> section 5 target="RFC8029" section="5" sectionFormat="of"/> should be taken and
      implemented to mitigate these attack vectors for P2MP policy Ping ping as
      well.</t>

      <t>In

<!--[rfced] To improve the readability of this quotation, may we format
it within a <blockquote>?

Original:
   In addition security considerations of section 8 of <xref
      target="RFC6425"/> [RFC6425] should
   be followed, specifically the security recommendations from <xref target="RFC4379"/> [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 well-
   known UDP port" allocated for this service."</t>
    </section>

    <section title="Acknowledgments">
      <!-- 9 service."

Perhaps:
   In addition, security considerations in Section 8 of [RFC6425] should
   be followed, specifically the security recommendations from [RFC4379],
   which recommend the following:

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

      <t/>

      <t>In addition, the security considerations in <xref target="RFC6425"
      section="8" sectionFormat="of"/> should be followed, specifically the security
      recommendation from <xref target="RFC4379" format="default"/>, which
      recommends "To avoid potential Denial-of-Service attacks, it is
      <bcp14>RECOMMENDED</bcp14> that implementations regulate the LSP ping
      traffic going to the control plane. A rate limiter
      <bcp14>SHOULD</bcp14> be applied to the well-known UDP port" allocated
      for this service.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <reference anchor="RFC2119">
        <front>
          <title>S. Brandner, "Key words for use in RFCs to Indicate
          Requirement Levels"</title>

          <author>
            <organization/>
          </author>

          <date month="March" year="1997"/>
        </front>
      </reference>

      <reference anchor="RFC8174">
        <front>
          <title>B. Leiba, "ambiguity of Uppercase vs Lowercase in
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9524.xml"/>
<!-- [RFC9960]
draft-ietf-pim-sr-p2mp-policy-22
companion doc RFC 2119
          Key Words"</title>

          <author>
            <organization/>
          </author>

          <date month="May" year="2017"/>
        </front>
      </reference>

      <reference anchor="RFC8029">
        <front>
          <title>K. Kompella, G. Swallow, C. Pgnataro, N. kumar, S. Aldrin M.
          Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane
          Failures.</title>

          <author>
            <organization/>
          </author>

          <date month="February" year="2006"/>
        </front>
      </reference> 9960
in RFC-EDITOR as of 04/14/26
-->
<reference anchor="RFC9524"> anchor="RFC9960" target="https://www.rfc-editor.org/info/rfc9960">
<front>
          <title>D. Voyer, C. Filsfils, R. Parekh, H. Bidgoli, Z. Zhang,
          "Segment
      <title>Segment Routing Replication for Multipoint Service
          Delivery"</title>

          <author>
            <organization/> Point-to-Multipoint Policy</title>
      <author initials="R." surname="Parekh" fullname="Rishabh Parekh" role="editor">
         <organization>Arrcus</organization>
      </author>

          <date month="February" year="2024"/>
        </front>
      </reference>

      <reference anchor="draft-ietf-pim-sr-p2mp-policy">
        <front>
          <title>D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang,
          "draft-ietf-pim-sr-p2mp-policy"</title>

          <author>
            <organization/>
      <author initials="D." surname="Voyer" fullname="Daniel Voyer" role="editor">
         <organization>Cisco Systems, Inc.</organization>
      </author>

          <date month="July" year="2025"/>
        </front>
      </reference>

      <reference anchor="RFC6425">
        <front>
          <title>S. Saxena, G. Swallow, Z. Ali, A. Farrel, S. Yasukawa,
          T.Nadeau "Detecting Data-Plane Failures in Point-to-Multipoint
          MPLS"</title>

          <author>
            <organization/>
      <author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
         <organization>Cisco Systems, Inc.</organization>
      </author>

          <date month="November" year="2011"/>
        </front>
      </reference>

      <reference anchor="RFC3270">
        <front>
          <title>F. Le Faucheur, L. Wu, B. Davie "MPLS Support of
          Differentiated Services"</title>

          <author>
            <organization/>
      <author initials="H." surname="Bidgoli" fullname="Hooman Bidgoli">
         <organization>Nokia</organization>
      </author>

          <date month="May" year="2002"/>
        </front>
      </reference>

      <reference anchor="RFC4379">
        <front>
          <title>K. Kompella, G. Swallow "Detecting MPLS Data Plane
          Failures"</title>

          <author>
            <organization/>
      <author initials="Z." surname="Zhang" fullname="Zhaohui (Jeffrey) Zhang">
         <organization>Juniper Networks</organization>
      </author>
<date month="February" year="2006"/> month='April' year='2026'/>
</front>
<seriesInfo name="RFC" value="9960"/>
<seriesInfo name="DOI" value="10.17487/RFC9960"/>
</reference>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6425.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3270.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4379.xml"/>

      </references>

    <references title="Informative References">
      <!-- 10.2 -->
      <references>
        <name>Informative References</name>
      <reference anchor="IANA-AF"> anchor="IANA-AF" target="http://www.iana.org/assignments/address-family-numbers">
          <front>
          <title>IANA Assigned Port Numbers,
          "http://www.iana.org/assignments/address-family-numbers"</title>
            <title>Address Family Numbers</title>
            <author>
            <organization/>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
      </references>
  </back>
</rfc>
    </references>

<!--[rfced] Terminology

a) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.

 Multicast vs. multicast
 Ping vs. ping
 Traceroute vs. traceroute

b) FYI - We have updated the following terms to reflect the forms on the right
per usage in RFC-to-be 9960. Please review and let us know of any objections.

 Candidate Path -> candidate path

 P2MP Tree -> P2MP tree
   [Note: If any instances of "P2MP tree" should be "P2MP tree instance",
   please let us know.

 P2MP Tree Instance -> P2MP tree instance

 Replication Segment -> Replication segment

c) Please let us know if/how we may make these terms consistent.

 SR P2MP Policy ping vs. P2MP policy ping
-->

<!-- generated [rfced] Abbreviations

a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

 Command Line Interface (CLI)
 Forwarding Equivalence Class (FEC)
 Label Switching Router (LSR)
 Segment Routing (SR)

b) As recommended in the Web Portion of the Style Guide
<https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>, once an
abbreviation is introduced, the abbreviated form should be used
thereafter. Please consider if you would like to apply this style for
the following terms:

 candidate path (CP)
 Operations, Administration, and Maintenance (OAM)
 P2MP tree instance (PTI)
 Path Computation Element (PCE)

c) FYI - In the Introduction, note that we removed the abbreviation "MBB"
from file C:\Users\hbidgoli\Downloads\draft-ietf-bier-pim-signaling-08.nroff with nroff2xml 0.1.0 by Tomek Mrugalski "Make-Before-Break (MBB)" as this term was only mentioned once.
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

  </back>
</rfc>