rfc9961xml2.original.xml   rfc9961.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!DOCTYPE rfc [
<?rfc strict="yes" ?> <!ENTITY nbsp "&#160;">
<?rfc toc="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc tocdepth="4"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes" ?> ]>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<rfc category="std" docName="draft-ietf-pim-p2mp-policy-ping-25" tf-pim-p2mp-policy-ping-25" number="9961" consensus="true" ipr="trust200902" obs
ipr="trust200902"> oletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDe
pth="4" symRefs="true" sortRefs="true" version="3">
<front> <front>
<title abbrev="P2MP Policy Ping">Segment Routing MPLS Point-to-Multipoint
(P2MP) Policy Ping</title>
<author fullname="Hooman Bidgoli" initials="H" role="editor" <!--[rfced] Since the running text uses "SR P2MP Policy ping and
surname="Bidgoli"> traceroute" and "P2MP policy ping" (both without "MPLS"), should
<organization>Nokia</organization> the document title be updated as shown below for consistency?
<address> Since "traceroute" is mentioned in the Abstract and with ping in
<postal> the running text, should it be included in the title as well?
<street/> (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.)
<city>Ottawa</city> Also, would you like to add the abbreviation for "Segment Routing"
since "(P2MP)" is included for "Point-to-Multipoint"?
<region/> Original:
Segment Routing MPLS Point-to-Multipoint (P2MP) Policy Ping
<code/> 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="Bidgol
i">
<organization>Nokia</organization>
<address>
<postal>
<city>Ottawa</city>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<phone/>
<email>hooman.bidgoli@nokia.com</email> <email>hooman.bidgoli@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Zafar Ali" initials="Z." surname="Ali">
<author fullname="Zafar" initials="Z." surname="Ali">
<organization>Cisco System</organization> <organization>Cisco System</organization>
<address> <address>
<postal> <postal>
<street/>
<city>San Jose</city> <city>San Jose</city>
<country>United States of America</country>
<region/>
<code/>
<country>USA</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>zali@cisco.com</email> <email>zali@cisco.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Zhaohui Zhang" initials="Z." surname="Zhang"> <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Boston</city> <city>Boston</city>
<country>United States of America</country>
<region/>
<code/>
<country>USA</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>zzhang@juniper.net</email> <email>zzhang@juniper.net</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Anuj Budhiraja" initials="A." surname="BudhirajaC"> <author fullname="Anuj Budhiraja" initials="A." surname="BudhirajaC">
<organization>Cisco System</organization> <organization>Cisco System</organization>
<address> <address>
<postal> <postal>
<street/>
<city>San Jose</city> <city>San Jose</city>
<country>United States of America</country>
<region/>
<code/>
<country>USA</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>abudhira@cisco.com</email> <email>abudhira@cisco.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Daniel Voyer" initials="D" surname="Voyer"> <author fullname="Daniel Voyer" initials="D" surname="Voyer">
<organization>Cisco System</organization> <organization>Cisco System</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Montreal</city> <city>Montreal</city>
<region/>
<code/>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>davoyer@cisco.com</email> <email>davoyer@cisco.com</email>
<uri/>
</address> </address>
</author> </author>
<date month="April" year="2026"/>
<area>RTG</area>
<workgroup>pim</workgroup>
<date day="09" month="October" year="2025"/> <!-- [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> <abstract>
<t>SR Point-to-Multipoint (P2MP) Policies are used to define and manage <t>Segment Routing (SR) Point-to-Multipoint (P2MP) Policies are used to de fine and manage
explicit P2MP paths within a network. These policies are typically explicit P2MP paths within a network. These policies are typically
calculated via a controller-based mechanism and installed via, e.g., a calculated via a controller-based mechanism and installed via, e.g., a
Path Computation Element (PCE). In other cases these policies can be Path Computation Element (PCE). In other cases, these policies can be
installed via using NETCONF/YANG or CLI. They are used to steer installed using the Network Configuration Protocol (NETCONF) / YANG or a C
ommand Line Interface (CLI).
They are used to steer
multicast traffic along optimized paths from a Root to a set of Leaf multicast traffic along optimized paths from a Root to a set of Leaf
routers.</t> routers.</t>
<t>This document defines extensions to Ping and Traceroute mechanisms <t>This document defines extensions to Ping and Traceroute mechanisms
for SR P2MP Policy with MPLS encapsulation to provide OAM (Operations, for an SR P2MP Policy with MPLS encapsulation to provide Operations,
Administration, and Maintenance) capabilities. The extensions enable Administration, and Maintenance (OAM) capabilities. The extensions enable
operators to verify connectivity, diagnose failures and troubleshoot operators to verify connectivity, diagnose failures, and troubleshoot
forwarding issues within SR P2MP Policy multicast trees.</t> forwarding issues within SR P2MP Policy multicast trees.</t>
<t>By introducing new mechanisms for detecting failures and validating <t>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 MPLS P2MP multicast deployments. Additionally, it ensures that existing MPLS
and SR-based OAM tools can be effectively applied to networks utilizing and SR-based OAM tools can be effectively applied to networks utilizing
SR P2MP Policies.</t> SR P2MP Policies.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<!-- 1 --> <name>Introduction</name>
<t><xref target="RFC9960" format="default"/> explains the concept
<t><xref target="draft-ietf-pim-sr-p2mp-policy"/> explains the concept of the SR P2MP Policy and its candidate paths (CPs). It also explains
of the SR P2MP Policy and its Candidate Paths (CPs). It also explains
the concept of how a CP is selected to be the active CP. To enable the concept of how a CP is selected to be the active CP. To enable
seamless global optimization a CP may consist of multiple P2MP Tree seamless global optimization, a CP may consist of multiple P2MP tree
Instances (PTIs), allowing for Make-Before-Break (MBB) procedures instances (PTIs), allowing for Make-Before-Break procedures
between an active PTI and a newly established, optimized PTI. A PTI is 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 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 transit routers. A PTI is identified on the Root node by the PTI's
instance ID.</t> instance ID.</t>
<t>To ensure reliable network operation, it is essential to verify <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 end-to-end connectivity for both active and backup CPs, as well as all
associated PTIs. This document specifies a mechanism for detecting data associated PTIs. This document specifies a mechanism for detecting data
plane failures within a SR P2MP Policy CP and its associated PTIs, plane failures within an SR P2MP Policy CP and its associated PTIs,
enabling operators to monitor and troubleshoot multicast path enabling operators to monitor and troubleshoot multicast path
integrity.</t> integrity.</t>
<!--[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 <t>This specification applies exclusively to Replication Segments
(Replication SIDs) that use MPLS encapsulation for forwarding and does (Replication-SIDs) that use MPLS encapsulation for forwarding and does
not cover Segment Routing over IPv6 (SRv6). The mechanisms described not cover Segment Routing over IPv6 (SRv6). The mechanisms described
herein build upon the concepts established in <xref target="RFC6425"/> herein build upon the concepts established in <xref target="RFC6425" forma t="default"/>
for P2MP MPLS Operations, Administration, and Maintenance (OAM). All for P2MP MPLS Operations, Administration, and Maintenance (OAM). All
considerations and limitations described in section 6 of <xref considerations and limitations described in <xref target="RFC6425" section
target="RFC6425"/> apply to this document as well.</t> ="6"/> apply to this document as well.</t>
<section numbered="true" toc="default">
<section title="Terminology "> <name>Terminology</name>
<t>The readers of this document should familiarize themselves with the <t>The readers of this document should familiarize themselves with the
following documents and sections for terminology and details following documents and sections for terminology and details regarding t
implementation of the SR P2MP Policy</t> he
implementation of the SR P2MP Policy.</t>
<t><xref target="RFC9524" section="1.1" sectionFormat="comma"/> defines
terms specific to an SR
Replication segment and also explains the node terminology in a
Multicast domain, including the Root node, Leaf node, and Bud
node.</t>
<t><xref target="RFC9524"/> section 1.1 defines terms specific to SR <!-- [rfced] FYI - We have updated this citation to point to Section 1.1
Replication Segment and also explains the Node terminology in a of RFC-to-be 9960 (the Terminology section.) Please review and
Multicast domain, including the Root Node, Leaf Node and a Bud let us know of any objections.
Node.</t>
<t><xref target="draft-ietf-pim-sr-p2mp-policy"> </xref> section 2, Original:
defines terms and concepts specific to SR P2MP Policy including the CP [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> and the PTI.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Conventions used in this document"> <name>Conventions Used in This Document</name>
<!-- 2 --> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP 14 "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
they appear in all capitals, as shown here.</t> to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
</section> </section>
<section numbered="true" toc="default">
<name>Motivation</name>
<section title="Motivation"> <t>An SR P2MP Policy and its corresponding Replication segments are
<!-- 3-->
<t>A SR P2MP Policy and its corresponding Replication Segments are
typically provisioned via a centralized controller or configured using typically provisioned via a centralized controller or configured using
NETCONF/YANG or CLI. The root and the leaves are discovered in NETCONF/YANG or CLI. The Root and the Leaves are discovered in
accordance with <xref target="draft-ietf-pim-sr-p2mp-policy"/> and the accordance with <xref target="RFC9960" format="default"/>, and the
multicast tree is computed from the root to the leaves. However, there multicast tree is computed from the Root to the Leaves. However, there
is no underlay signaling protocol to distribute the SR P2MP Policy from is no underlay signaling protocol to distribute the SR P2MP Policy from
the root to the leaf routers. Consequently, when a P2MP tree fails to the Root to the Leaf routers. Consequently, when a P2MP tree fails to
deliver user traffic, identifying the failure can be challenging without deliver user traffic, identifying the failure can be challenging without
ping and traceroute mechanisms to isolate faults along the tree.</t> ping and traceroute mechanisms to isolate faults along the tree.</t>
<t>To address this challenge, SR P2MP Policy ping and traceroute can be <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 utilized to detect and localize faults within the P2MP tree and its
associated Replication Segments, as defined in <xref target="RFC9524"/>. associated Replication segments, as defined in <xref target="RFC9524" form at="default"/>.
These OAM tools enable periodic ping operations to verify connectivity These OAM tools enable periodic ping operations to verify connectivity
between the root and the leaves. In cases where a ping fails, a between the Root and the Leaves. In cases where a ping fails, a
traceroute can be initiated to determine the point of failure along the traceroute can be initiated to determine the point of failure along the
tree. This diagnostic process can be initiated from the node responsible tree. This diagnostic process can be initiated from the node responsible
for establishing the SR P2MP Policy, ensuring proactive monitoring and for establishing the SR P2MP Policy, ensuring proactive monitoring and
fault detection.</t> fault detection.</t>
<section numbered="true" toc="default">
<section title="MPLS P2MP Policy Ping and Traceroute"> <!--[rfced] Should "SR" be added to the title of Section 3.1 for
<!-- 3.1 --> consistency with the running text?
Original:
3.1. MPLS P2MP Policy Ping and 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 <t>Ping/Traceroute packets are forwarded based upon the SR P2MP
Policy, on a specific CP and its PTI toward the designated leaf Policy on a specific CP and its PTI toward the designated Leaf
routers. These packets are replicated at the replication point based routers. These packets are replicated at the replication point based
on the Replication Segment forwarding information on the corresponding on the Replication segment forwarding information on the corresponding
router.</t> router.</t>
<t>MPLS packets are processed based on the standard behavior when
their Time to Live (TTL) expires or when they reach the egress (Leaf)
router. The appropriate response is sent back to the Root node
following the procedures outlined in <xref target="RFC6425" format="defa
ult"/>.</t>
<section numbered="true" toc="default">
<t>MPLS Packets are processed based on the standard behavior when <!--[rfced] Please clarify what "Current RFC" refers to in the title
their Time-to-Live (TTL) expires or when they reach the egress (leaf) of Section 3.1.1.
router. The appropriate response is sent back to the root node
following the procedures outlined in <xref target="RFC6425"/>.</t>
<section title="Applicability of current RFC to SR P2MP Policies"> Original:
<!-- 3.1.1 --> 3.1.1. Applicability of the Current RFC to SR P2MP Policies
-->
-&gt; <name>Applicability of the Current RFC to SR P2MP Policies</name>
<t>The procedures in <xref target="RFC6425"/> define fault detection <t>The procedures in <xref target="RFC6425" format="default"/> define
and isolation mechanisms for P2MP MPLS LSPs and extend the LSP ping fault detection
techniques described in <xref target="RFC8029"/> such that they may and isolation mechanisms for P2MP MPLS Label Switched Paths (LSPs) and
extend the LSP ping
techniques described in <xref target="RFC8029" format="default"/> such
that they may
be applied to P2MP MPLS LSPs, ensuring alignment with existing fault be applied to P2MP MPLS LSPs, ensuring alignment with existing fault
management tools. <xref target="RFC6425"/> emphasizes the reuse of management tools. <xref target="RFC6425" format="default"/> emphasizes
existing LSP ping mechanisms designed for Point-to-Point P2P LSPs, the reuse of
existing LSP ping mechanisms designed for Point-to-Point (P2P) LSPs,
adapting them to P2MP MPLS LSPs to facilitate seamless adapting them to P2MP MPLS LSPs to facilitate seamless
implementation and network operation.</t> implementation and network operation.</t>
<t>The fault detection procedures specified in <xref target="RFC6425"
<t>The fault detection procedures specified in <xref format="default"/> are applicable to all P2MP MPLS protocols,
target="RFC6425"/> are applicable to all P2MP MPLS protocols, including P2MP RSVP-TE and Multicast LDP and now the SR P2MP Policy.
including P2MP RSVP-TE and Multicast LDP and now SR P2MP SR Policy. While <xref target="RFC6425" format="default"/> highlights specific di
While <xref target="RFC6425"/> highlights specific differences for fferences for
P2MP RSVP-TE and Multicast LDP, this document introduces P2MP RSVP-TE and Multicast LDP, this document introduces
considerations unique to SR P2MP Policies, including:</t> considerations unique to SR P2MP Policies, including:</t>
<ol spacing="normal" type="1"><li>
<t><list style="numbers"> <t>Egress Address P2MP Responder sub-TLVs: Multicast LDP, as per
<t>Egress Address P2MP Responder Sub-TLVs: Multicast LDP, as per <xref target="RFC6425" section="3.2.1" sectionFormat="of"/>, does
section 3.2.1 of <xref target="RFC6425"/>, does not allow for not allow for
the inclusion of Egress Address P2MP Responder Sub-TLVs, as the inclusion of Egress Address P2MP Responder sub-TLVs, as
upstream LSRs lack visibility into downstream leaf nodes. upstream Label Switching Routers (LSRs) lack visibility into downs
tream Leaf nodes.
Similarly, SR P2MP Policies often rely on a Path Computation Similarly, SR P2MP Policies often rely on a Path Computation
Element (PCE) for programming transit routers. This is why in SR Element (PCE) for programming transit routers. This is why in the
P2MP domain, transit routers do not have knowledge of the leaf SR
P2MP domain, transit routers do not have knowledge of the Leaf
nodes. Only the Root node, where the SR P2MP Policy is nodes. Only the Root node, where the SR P2MP Policy is
programmed, has visibility into the leaf nodes. Consequently, programmed, has visibility into the Leaf nodes. Consequently,
these Sub-TLVs SHOULD NOT be used when an echo request carries a these sub-TLVs <bcp14>SHOULD NOT</bcp14> be used when an echo requ
SR P2MP Policy MPLS Candidate Path FEC. If a node receives the est carries an
Egress Address P2MP Responder Sub-TLVs in an echo request, then SR P2MP Policy MPLS Candidate Path Forwarding Equivalence Class (F
EC). 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 it will not respond since it is unaware of whether it lies on
the path to the address in the sub-TLV.</t> the path to the address in the sub-TLV.</t>
</li>
<t>End of Processing for Traceroutes: As per section 4.3.1 of <li>
<xref target="RFC6425"/>, it is RECOMMENDED that for traceroute <t>End of Processing for Traceroutes: As per
<xref target="RFC6425" section="4.3.1" sectionFormat="of"/>, it is
<bcp14>RECOMMENDED</bcp14> that traceroute
orations provide for a configurable upper limit on TTL values. orations provide for a configurable upper limit on TTL values.
This is because for some protocols like Multicast LDP, there may This is because, for some protocols like Multicast LDP, there may
not be an easy way to figure out the end of the traceroute not be an easy way to figure out the end of the traceroute
processing as the initiating LSR might not always know about all processing, as the initiating LSR might not always know about all
of the leaf routers. In the case of a SR P2MP Policy the Root of the Leaf routers. In the case of an SR P2MP Policy, the Root
node has visibility of the leaf nodes, as such there is a node has visibility of the Leaf nodes; as such, there is a
definitive way to estimate the end of processing for a definitive way to estimate the end of processing for a
traceroute and a configurable upper limit on TTL may not be traceroute, and a configurable upper limit on TTL may not be
necessary. How ever, a configurable upper limit on TTL value is necessary. However, a configurable upper limit on the TTL value is
an implementation choice.</t> an implementation choice.</t>
</li>
<t>Identification of the LSP under test: <xref <li>
target="RFC6425"/>, in Section 3.1, defines distinct identifiers <t>Identification of the LSP under test: <xref target="RFC6425"
for P2MP RSVP-TE and Multicast LDP when identifying an LSP under section="3.1" sectionFormat="of"/> defines distinct identifiers fo
test. As each protocol has its own identifier, this document r P2MP RSVP-TE
introduces a new Target FEC Stack TLV specific to SR P2MP and Multicast LDP when identifying an LSP under test. As each
Policies to uniquely identify their Candidate Paths (CPs) and protocol has its own identifier, this document introduces a new
P2MP Tree Instances (PTIs). These modifications ensure that SR Target FEC Stack TLV specific to SR P2MP Policies to uniquely
P2MP Policy OAM mechanisms are properly aligned with existing identify their CPs and PTIs. These modifications ensure that
MPLS ping and traceroute tools while addressing the specific SR P2MP Policy OAM
operational characteristics of SR P2MP Policies.</t> mechanisms are properly aligned with existing MPLS ping and
</list></t> traceroute tools while addressing the specific operational
characteristics of SR P2MP Policies.</t>
</li>
</ol>
</section> </section>
<section numbered="true" toc="default">
<section title="Conformance to Existing Procedures and Additional Consid <name>Conformance to Existing Procedures and Additional Considerations
erations"> </name>
<!-- 3.1.2 -->
<t>In addition to major differences outlined in the previous <t>In addition to major differences outlined in the previous
section, SR P2MP Policies SHOULD follow to the common procedures section, SR P2MP Policies <bcp14>SHOULD</bcp14> follow the common proc
specified in <xref target="RFC6425"/> for P2MP MPLS LSPs. edures
specified in <xref target="RFC6425" format="default"/> for P2MP MPLS L
SPs.
Furthermore, this specification reuses the same destination UDP port Furthermore, this specification reuses the same destination UDP port
as defined in <xref target="RFC8029"> </xref> for consistency with as defined in <xref target="RFC8029" format="default"> </xref> for con
existing MPLS OAM mechanism.</t> sistency with
the existing MPLS OAM mechanism.</t>
<t>Implementations MUST account for the fact that a SR P2MP Policy <t>Implementations <bcp14>MUST</bcp14> account for the fact that an SR
P2MP Policy
may contain multiple CPs, and each CP may consist of multiple PTIs. may contain multiple CPs, and each CP may consist of multiple PTIs.
As such, implementations SHOULD support the ability to individually As such, implementations <bcp14>SHOULD</bcp14> support the ability to individually
test each CP and its corresponding PTI using ping and traceroute test 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 Replication-SID receives a ping or traceroute packet, it <bcp14>MUST</
bcp14>
process the request and generate a response even if the CP and its process the request and generate a response even if the CP and its
PTI are not currently the active path.</t> PTI are not currently the active path.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Considerations for Interworking with Unicast paths"> <name>Considerations for Interworking with Unicast Paths</name>
<t>As per <xref target="draft-ietf-pim-sr-p2mp-policy"/> there are <t>As per <xref target="RFC9960" format="default"/>, there are
two ways to build a P2MP Tree:</t> two ways to build a P2MP tree:</t>
<ol spacing="normal" type="1"><li>
<t><list style="numbers"> <t>P2MP tree with non-adjacent Replication segments</t>
<t>P2MP Tree with non-adjacent Replication Segments</t> </li>
<li>
<t>P2MP tree with adjacent Replication Segments</t> <t>P2MP tree with adjacent Replication segments</t>
</list></t> </li>
</ol>
<t>For the case of adjacent Replication Segments, there are no <t>For the case of adjacent Replication segments, there are no
special considerations for the TTL or Hop Limit propagation and the special considerations for the TTL or Hop Limit propagation, and the
TTL should be decremented hop by hop as the OAM packet traverses the TTL should be decremented hop by hop as the OAM packet traverses the
Replication Segments of a P2MP tree.</t> Replication segments of a P2MP tree.</t>
<t>For the case of non-adjacent Replication segments (for example,
<t>For the case of non-adjacent Replication Segments, as an example two Replication segments that are connected via an SR Policy or
two Replication Segments that are connected via a SR Policy or similar technology), there are special considerations. In such
similar technology, there are special considerations. In such
scenarios, SR P2MP Policy OAM tools should be used to verify the scenarios, SR P2MP Policy OAM tools should be used to verify the
connectivity of the non-adjacent Replication Segments that are connectivity of the non-adjacent Replication segments that are
building the P2MP Tree while the unicast OAM tools should be used to building the P2MP tree, while the unicast OAM tools should be used to
verify the connectivity of unicast path connecting the two verify the connectivity of the unicast path connecting the two
non-adjacent Replication Segment. In these scenarios the Replication non-adjacent Replication segments. In these scenarios, the Replication
SID should not be exposed or examined in the unicast path. Proper -SID
TTL handling to copy the Replication Segment TTL to unicast path can should not be exposed or examined in the unicast path. Proper
be achieved via hierarchical MPLS TTL mode being used (e.g., Pipe TTL handling to copy the Replication segment TTL to the unicast path c
Mode vs. Uniform Mode) as per <xref target="RFC3270"/>. For the P2MP an
Tree Traceroute the TTL mode MUST be set to PIPE mode on the router be achieved via the hierarchical MPLS TTL mode being used (e.g., Pipe
Mode vs. Uniform Mode) as per <xref target="RFC3270" format="default"/
>. For the P2MP
Tree Traceroute, the TTL mode <bcp14>MUST</bcp14> be set to Pipe Mode
on the router
that the unicast path starts. This will ensure that the unicast path 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 TTL is set to a large value that allows the traceroute packet to be
delivered to the downstream Replication Segment. For Ping either the delivered to the downstream Replication segment. For Ping, either the
PIPE mode or Uniform mode can be used depending on the Pipe Mode or the Uniform Mode can be used depending on the
implementation. The unicast path failure detection is considered out implementation. The unicast path failure detection is considered out
of scope for this document.</t> of scope for this document.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Packet format and new TLVs"> <name>Packet Format and New TLVs</name>
<t>The packet format used in this specification follow section 3 of <t>The packet format used in this specification follows
<xref target="RFC8029"/>. However, additional TLVs and sub-TLVs are <xref target="RFC8029" section="3" sectionFormat="of"/>. However, additi
onal TLVs and sub-TLVs are
required to support the new functionality introduced for SR P2MP required to support the new functionality introduced for SR P2MP
Policies. These extensions are described in the following Policies. These extensions are described in the following
sections.</t> sections.</t>
<section numbered="true" toc="default">
<name>Identifying a P2MP Policy</name>
<section title="Identifying a P2MP Policy"> <t><xref target="RFC8029" format="default"/> defines a standardized me
<!-- 3.1 --> chanism for
detecting data plane failures in MPLS LSPs. To correctly identify the
<t><xref target="RFC8029"/> defines a standardized mechanism for Replication segment associated with a given CP and
detecting data-plane failures in Multiprotocol Label Switching PTI, the echo request message <bcp14>MUST</bcp14> include a
(MPLS) Label Switched Paths (LSPs). To correctly identify the Target FEC Stack TLV that explicitly specifies the candidate path
Replication Segment associated with a given Candidate Path (CP) and and P2MP tree instance under test.</t>
P2MP Tree Instance (PTI), the Echo Request message MUST include a
Target FEC Stack TLV that explicitly specifies the Candidate Path
and P2MP Tree Instance under test.</t>
<t>This document introduces a new sub-TLV, referred to as the SR <t>This document introduces a new sub-TLV, referred to as the SR
MPLS P2MP Policy Tree Instance sub-TLV, which is defined as MPLS P2MP Policy Tree Instance sub-TLV, which is defined as
follows:</t> follows:</t>
<table>
<figure> <thead>
<artwork><![CDATA[Sub-Type Length Value Field <tr>
41 Variable SR MPLS P2MP Policy Tree Instance <th>Sub-Type</th>
]]></artwork> <th>Length</th>
</figure> <th>Value Field</th>
</tr>
</thead>
<tbody>
<tr>
<td>41</td>
<td>Variable</td>
<td>SR MPLS P2MP Policy Tree Instance</td>
</tr>
</tbody>
</table>
<t>Further details regarding the structure and processing of this <t>Further details regarding the structure and processing of this
sub-TLV are provided in subsequent sections.</t> sub-TLV are provided in subsequent sections.</t>
<section numbered="true" toc="default">
<section title="SR MPLS P2MP Policy Tree Instance FEC Stack Sub-TLVs"> <name>SR MPLS P2MP Policy Tree Instance FEC Stack Sub-TLVs</name>
<t>The SR MPLS P2MP Policy Tree Instance sub-TLV value field <t>The SR MPLS P2MP Policy Tree Instance sub-TLV value field
follows the format specified in Section 2.3 of <xref follows the format specified in <xref section="2.3" target="RFC9960"
target="draft-ietf-pim-sr-p2mp-policy"/>. The structure of this format="default" sectionFormat="of"/>. The structure of this
sub-TLV is illustrated in the figure below. It should be noted 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 that this sub-TLV is testing a specific PTI within a specific CP
and it is not testing the CP.</t> and it is not testing the CP.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ 0
<t><figure> 1 2 3
<artwork><![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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> <dl spacing="normal" newline="false">
<dt>Address Family:</dt><dd>2 octets. IPv4/IPv6 Address Family
<t><list style="symbols"> Numbers as specified in <xref target="IANA-AF"
<t>Address Family: (2 octets) IPv4/IPv6 ADDRESS FAMILY NUMBERS format="default"/>, indicating the Address Family of the
as specified in <xref target="IANA-AF"/> , indicating the Root. Any other Address Family, except IPv4/IPv6, is not supported
address family of the Root. Any other Address Family but by
IPv4/IPv6 is not supported by this draft.</t> this document.</dd>
<dt>Address Length:</dt><dd>1 octet. Specifies the length of
<t>Address Length: (1 octet) specifying the length of the Root the Root Address in octets (4 octets for IPv4, and 16 octets for
Address in octets (4 octets for IPv4, 16 octets for IPv6).</t> IPv6).</dd>
<dt>Reserved:</dt><dd><bcp14>MUST</bcp14> be set to zero by the
<t>Reserved: MUST be set to zero by sender and it should be sender and should be ignored by the receiver.</dd>
ignored by the receiver.</t> <dt>Root:</dt><dd>Variable length depending on the Address
Family field. The Root node of the SR P2MP Policy, as defined in
<t>Root: (variable length depending on the address family <xref target="RFC9960"
field) The root node of the SR P2MP Policy, as defined in format="default"/>.</dd>
<xref target="draft-ietf-pim-sr-p2mp-policy"/></t> <dt>Tree-ID:</dt><dd>4 octets. A unique identifier for the P2MP
tree, as defined in <xref target="RFC9960"
<t>Tree-ID: (4 octets) A unique identifier for the P2MP tree, format="default"/>.</dd>
as defined in <xref <dt>Instance-ID:</dt><dd>2 octets. Identifies the specific
target="draft-ietf-pim-sr-p2mp-policy"/></t> Path-Instance, as defined in <xref
target="RFC9960" format="default"/>.</dd>
<t>Instance-ID: (2 octets) identifies the specific </dl>
Path-Instance as defined in<xref
target="draft-ietf-pim-sr-p2mp-policy"/></t>
</list></t>
</section> </section>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<name>Limiting the Scope of Response</name>
<section title="Limiting the Scope of Response"> <t>As specified in <xref target="RFC6425" section="3.2" sectionFormat="o
<!-- 3.2 --> f"/>, four
sub-TLVs are used within the P2MP Responder Identifier TLV that is inclu
<t>As specified in section 3.2 of <xref target="RFC6425"/>, four ded in
sub-TLVs are used within the P2MP Responder Identifier TLV included in
the echo request message.</t> the echo request message.</t>
<t>The sub-TLVs for IPv4 and IPv6 egress addresses of the P2MP responder
<t>The Sub-TLVs for IPv4 and IPv6 egress addresses of P2MP responder are aligned with <xref target="RFC6425" section="3.2.1" sectionFormat="o
are aligned with section 3.2.1 of <xref target="RFC6425"/>.</t> f"/>.</t>
<t>The sub-TLVs for IPv4 and IPv6 node addresses of the P2MP responder <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> are aligned with <xref target="RFC6425" section="3.2.2" sectionFormat="o
f"/>.</t>
<t>These mechanisms ensure that responses are appropriately scoped to <t>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.</t> procedures.</t>
</section> </section>
</section> </section>
<section title="Implementation Status"> <section numbered="true" toc="default">
<t>Note to the RFC Editor: please remove this section before <name>IANA Considerations</name>
publication. This section records the status of known implementations of <t>
the protocol defined by this specification at the time of posting of IANA has assigned a sub-type value for the SR MPLS P2MP Policy
this Internet-Draft, and is based on a proposal described in RFC7942 . Tree Instance sub-TLV in
The description of implementations in this section is intended to assist the "Sub-TLVs for TLV Types 1, 16, and 21" registry under the "Multiprotoc
the IETF in its decision processes in progressing drafts to RFCs. Please ol
note that the listing of any individual implementation here does not Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" regist
imply endorsement by the IETF. Furthermore, no effort has been spent to ry group.
verify the information presented here that was supplied by IETF The sub-type value has been assigned from the Standards Action range of 0-
contributors. This is not intended as, and must not be construed to be, 16383 as shown below. Note that the sub-TLV has been assigned from Type 1 (Targe
a catalog of available implementations or their features. Readers are t FEC Stack) of the "TLVs" registry.
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 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.</t>
<t>Sub-Type Sub-TLV Name</t>
<t>41 SR MPLS P2MP Policy Tree Instance</t> </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</td></tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default">
<name>Security Considerations</name>
<t>Overall, the security needs for P2MP policy ping are the same as in
<xref target="RFC9960" format="default"/>, <xref target="RFC6425" format="
default"/>,
and <xref target="RFC8029" format="default"> </xref>. P2MP policy ping is
susceptible
to the same three attack vectors as explained in <xref target="RFC8029" se
ction="5" sectionFormat="of"/>. The same procedures and recommendations
explained in <xref target="RFC8029" section="5" sectionFormat="of"/> shoul
d be taken and
implemented to mitigate these attack vectors for P2MP policy ping as
well.</t>
<section title="Security Considerations"> <!--[rfced] To improve the readability of this quotation, may we format
<!-- 8 --> it within a <blockquote>?
<t>Overall, the security needs for P2MP policy ping are the same as Original:
<xref target="draft-ietf-pim-sr-p2mp-policy"/>, <xref target="RFC6425"/> In addition security considerations of section 8 of [RFC6425] should
and<xref target="RFC8029"> </xref>. The P2MP policy ping is susceptible be followed, specifically the security recommendations from [RFC4379]
to the same three attack vectors as explained in <xref which recommends "To avoid potential Denial-of-Service attacks, it is
target="RFC8029"/> section 5. The same procedures and recommendations RECOMMENDED that implementations regulate the LSP ping traffic going
explained in <xref target="RFC8029"/> section 5 should be taken and to the control plane. A rate limiter SHOULD be applied to the well-
implemented to mitigate these attack vectors for P2MP policy Ping as known UDP port" allocated for this service."
well.</t>
<t>In addition security considerations of section 8 of <xref Perhaps:
target="RFC6425"/> should be followed, specifically the security In addition, security considerations in Section 8 of [RFC6425] should
recommendations from <xref target="RFC4379"/> which recommends "To avoid be followed, specifically the security recommendations from [RFC4379],
potential Denial-of-Service attacks, it is RECOMMENDED that which recommend the following:
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>
</section>
<section title="Acknowledgments"> | To avoid potential Denial-of-Service attacks, it is
<!-- 9 --> | 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.
-->
-&gt; <t>In addition, the security considerations in <xref target="RFC6425"
<t/> section="8" sectionFormat="of"/> should be followed, specifically the secu
rity
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> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<reference anchor="RFC2119"> <name>References</name>
<front> <references>
<title>S. Brandner, "Key words for use in RFCs to Indicate <name>Normative References</name>
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 RFC 2119
Key Words"</title>
<author>
<organization/>
</author>
<date month="May" year="2017"/>
</front>
</reference>
<reference anchor="RFC8029"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<front> 19.xml"/>
<title>K. Kompella, G. Swallow, C. Pgnataro, N. kumar, S. Aldrin M. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane 74.xml"/>
Failures.</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
29.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.95
24.xml"/>
<!-- [RFC9960]
draft-ietf-pim-sr-p2mp-policy-22
companion doc RFC 9960
in RFC-EDITOR as of 04/14/26
-->
<reference anchor="RFC9960" target="https://www.rfc-editor.org/info/rfc9960">
<front>
<title>Segment Routing Point-to-Multipoint Policy</title>
<author initials="R." surname="Parekh" fullname="Rishabh Parekh" role="edi
tor">
<organization>Arrcus</organization>
</author>
<author initials="D." surname="Voyer" fullname="Daniel Voyer" role="editor
">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="H." surname="Bidgoli" fullname="Hooman Bidgoli">
<organization>Nokia</organization>
</author>
<author initials="Z." surname="Zhang" fullname="Zhaohui (Jeffrey) Zhang">
<organization>Juniper Networks</organization>
</author>
<date month='April' year='2026'/>
</front>
<seriesInfo name="RFC" value="9960"/>
<seriesInfo name="DOI" value="10.17487/RFC9960"/>
</reference>
<author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.64
<organization/> 25.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.32
70.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.43
79.xml"/>
<date month="February" year="2006"/> </references>
</front> <references>
</reference> <name>Informative References</name>
<reference anchor="IANA-AF" target="http://www.iana.org/assignments/addres
s-family-numbers">
<front>
<title>Address Family Numbers</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
</references>
</references>
<reference anchor="RFC9524"> <!--[rfced] Terminology
<front>
<title>D. Voyer, C. Filsfils, R. Parekh, H. Bidgoli, Z. Zhang,
"Segment Routing Replication for Multipoint Service
Delivery"</title>
<author> a) Throughout the text, the following terminology appears to be used
<organization/> inconsistently. Please review these occurrences and let us know if/how they
</author> may be made consistent.
<date month="February" year="2024"/> Multicast vs. multicast
</front> Ping vs. ping
</reference> Traceroute vs. traceroute
<reference anchor="draft-ietf-pim-sr-p2mp-policy"> b) FYI - We have updated the following terms to reflect the forms on the right
<front> per usage in RFC-to-be 9960. Please review and let us know of any objections.
<title>D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang,
"draft-ietf-pim-sr-p2mp-policy"</title>
<author> Candidate Path -> candidate path
<organization/>
</author>
<date month="July" year="2025"/> P2MP Tree -> P2MP tree
</front> [Note: If any instances of "P2MP tree" should be "P2MP tree instance",
</reference> please let us know.
<reference anchor="RFC6425"> P2MP Tree Instance -> P2MP tree instance
<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> Replication Segment -> Replication segment
<organization/>
</author>
<date month="November" year="2011"/> c) Please let us know if/how we may make these terms consistent.
</front>
</reference>
<reference anchor="RFC3270"> SR P2MP Policy ping vs. P2MP policy ping
<front> -->
<title>F. Le Faucheur, L. Wu, B. Davie "MPLS Support of
Differentiated Services"</title>
<author> <!-- [rfced] Abbreviations
<organization/>
</author>
<date month="May" year="2002"/> a) FYI - We have added expansions for the following abbreviations
</front> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
</reference> expansion in the document carefully to ensure correctness.
<reference anchor="RFC4379"> Command Line Interface (CLI)
<front> Forwarding Equivalence Class (FEC)
<title>K. Kompella, G. Swallow "Detecting MPLS Data Plane Label Switching Router (LSR)
Failures"</title> Segment Routing (SR)
<author> b) As recommended in the Web Portion of the Style Guide
<organization/> <https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>, once an
</author> abbreviation is introduced, the abbreviated form should be used
thereafter. Please consider if you would like to apply this style for
the following terms:
<date month="February" year="2006"/> candidate path (CP)
</front> Operations, Administration, and Maintenance (OAM)
</reference> P2MP tree instance (PTI)
</references> Path Computation Element (PCE)
<references title="Informative References"> c) FYI - In the Introduction, note that we removed the abbreviation "MBB"
<!-- 10.2 --> from "Make-Before-Break (MBB)" as this term was only mentioned once.
-->
-&gt; <!-- [rfced] Please review the "Inclusive Language" portion of the online
<reference anchor="IANA-AF"> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
<front> and let us know if any changes are needed. Updates of this nature typically
<title>IANA Assigned Port Numbers, result in more precise language, which is helpful for readers.
"http://www.iana.org/assignments/address-family-numbers"</title>
<author> Note that our script did not flag any words in particular, but this should
<organization/> still be reviewed as a best practice.
</author> -->
<date/>
</front>
</reference>
</references>
</back> </back>
</rfc> </rfc>
<!-- generated from file C:\Users\hbidgoli\Downloads\draft-ietf-bier-pim-signali ng-08.nroff with nroff2xml 0.1.0 by Tomek Mrugalski -->
 End of changes. 133 change blocks. 
484 lines changed or deleted 505 lines changed or added

This html diff was produced by rfcdiff 1.48.