<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="utf-8"?>

<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
  <!ENTITY I-D.ietf-mpls-inband-pm-encapsulation SYSTEM
    "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-inband-pm-encapsulation.xml">
  <!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY RFC3031 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml">
  <!ENTITY RFC3032 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml">
  <!ENTITY RFC6374 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6374.xml">
  <!ENTITY RFC7876 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7876.xml">
  <!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
  <!ENTITY RFC9341 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9341.xml">
  <!ENTITY RFC5481 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5481.xml">
  <!ENTITY RFC5586 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5586.xml">
  <!ENTITY RFC6790 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6790.xml">
  <!ENTITY RFC7471 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7471.xml">
  <!ENTITY RFC8126 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml">
  <!ENTITY RFC8402 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml">
  <!ENTITY RFC8570 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8570.xml">
  <!ENTITY RFC8571 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8571.xml">
  <!ENTITY RFC8668 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8668.xml">
  <!ENTITY RFC9256 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml">
  <!ENTITY RFC9356 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9356.xml">
  <!ENTITY RFC9545 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9545.xml">
  <!ENTITY RFC5082 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5082.xml">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="draft-ietf-mpls-rfc6374-sr-17" number="9779" category="std" ipr="trust200902" obsoletes="" updates="" xml:lang="en" sortRefs="false" consensus="yes" symRefs="true" tocInclude="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.12.3 -->
  <!-- Generated by id2xml 1.5.0 on 2020-03-06T17:47:05Z -->

    <front>
    <title abbrev="Performance Measurement for SR-MPLS">Performance Measurement for Segment Routing Networks with the MPLS Data Plane</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-mpls-rfc6374-sr-17"/> name="RFC" value="9779"/>
    <author fullname="Rakesh Gandhi" initials="R." role="editor" surname="Gandhi">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>Canada</street>
          <country>Canada</country>
        </postal>
        <email>rgandhi@cisco.com</email>
      </address>
    </author>
    <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>cfilsfil@cisco.com</email>
      </address>
    </author>
    <author fullname="Daniel Voyer" initials="D." surname="Voyer">
      <organization>Bell Canada</organization>
      <address>
        <email>daniel.voyer@bell.ca</email>
      </address>
    </author>
    <author fullname="Stefano Salsano" initials="S." surname="Salsano">
      <organization>Universita di Roma "Tor Vergata"</organization>
      <address>
        <postal>
          <street>Italy</street>
          <country>Italy</country>
        </postal>
        <email>stefano.salsano@uniroma2.it</email>
      </address>
    </author>
    <author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
      <organization>Huawei</organization>
      <address>
        <email>mach.chen@huawei.com</email>
      </address>
    </author>
    <date day="17" month="October" year="2024"/>
    <workgroup>MPLS Working Group</workgroup> month="April" year="2025"/>
<area>RTG</area>
    <workgroup>mpls</workgroup>

<keyword>Delay Measurement</keyword>
<keyword>Loss Measurement</keyword>
<keyword>Link Measurement</keyword>
<keyword>SR-MPLS Policy Measurement</keyword>

<abstract>
      <t>
	This document specifies the application of the MPLS loss and delay
	measurement
techniques, originally techniques (originally defined in RFC RFCs 6374, RFC 7876, and RFC 9341
	9341) within Segment Routing (SR) networks that utilize the MPLS data plane (SR-MPLS).
	plane, also referred to as Segment Routing over MPLS (SR-MPLS). SR
	enables the forwarding of packets through an ordered list of
	instructions, known as segments, which are imposed at the ingress
	node.  This document defines the procedures and extensions necessary
	to perform accurate measurement of packet loss and delay in SR-MPLS
	environments, ensuring that network operators can effectively measure
	and maintain the quality of service across their SR-based MPLS
	networks. This includes coverage of links and end-to-end SR-MPLS
	paths, as well as SR Policies.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>

      <t>
Segment

      <t>Segment Routing (SR), as specified in <xref target="RFC8402" format="default"/>, target="RFC8402"/>,
      leverages the source routing paradigm and applies to both the
      Multiprotocol Label Switching (SR-MPLS) (MPLS) and
IPv6 (SRv6) Internet Protocol version 6
      (IPv6) data planes.  These are referred to as Segment Routing over MPLS
      (SR-MPLS) and Segment Routing over IPv6 (SRv6), respectively.  SR takes
      advantage of Equal-Cost Multipaths (ECMPs) between source and transit
      nodes, between transit nodes, and between transit and destination
      nodes. SR Policies, defined in <xref target="RFC9256"
      format="default"/>, are used to steer traffic through specific,
      user-defined paths using a list of segments.
     </t>

      <t>
A segments.</t>

      <t>A comprehensive SR Performance Measurement toolset is one of the
      essential requirements for measuring network performance to provide
      Service Level Agreements (SLAs).
      </t>

<t>
<xref (SLAs).</t>

      <t><xref target="RFC6374" format="default"/> specifies protocol
      mechanisms to enable efficient and accurate measurement of packet loss,
      one-way and two-way delay, as well as related metrics such as
      delay-variation in MPLS networks.
</t>

<t>
<xref networks.</t>

      <t><xref target="RFC7876" format="default"/> specifies mechanisms for
      sending and processing out-of-band responses over a UDP return path when
      receiving query messages defined in <xref target="RFC6374"
      format="default"/>. These mechanisms can be applied to SR-MPLS networks.
</t>

<t>
<xref networks.</t>

      <t><xref target="RFC9341" format="default"/> defines the
      Alternate-Marking Method using block number Block Numbers as a data correlation
      mechanism for packet loss measurement.
</t>

<t>
This measurement.</t>

      <t>This document utilizes the mechanisms from <xref target="RFC6374"
      format="default"/>, <xref target="RFC7876" format="default"/>, and <xref
      target="RFC9341" format="default"/> for delay and loss measurements in
      SR-MPLS networks. This includes coverage of links and end-to-end SR-MPLS
      paths, as well as SR Policies.
</t>

<t>
This Policies.</t>

      <t>This document defines extends <xref target="RFC6374"/> by defining
      Return Path and Block Number TLV extensions for TLVs (see <xref target="RFC6374" format="default"/>, in Section 6, target="sect-6"/>) for delay and loss measurement in SR-MPLS
      networks. These TLV extensions TLVs can also apply to be used in MPLS Label Switched Paths
      (LSPs) <xref target="RFC3031" format="default"/>. However, the procedure
      for delay and loss measurement of MPLS LSPs is outside the scope of this document.
</t>
      document.</t>

   </section>

    <section anchor="sect-2" numbered="true" toc="default">
      <name>Conventions Used in This Document</name>
      <section anchor="sect-2.1" numbered="true" toc="default">
        <name>Requirements Language</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" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/>
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>

      </section>
      <section anchor="sect-2.2" numbered="true" toc="default">
        <name>Abbreviations</name>
        <t>
   ACH: Associated

	<dl spacing="normal" newline="false">
	  <dt>ACH:</dt><dd>Associated Channel Header.</t>
        <t>
   DM: Delay Measurement.</t>
        <t>
   ECMP: Equal Cost Multi-Path.</t>
        <t>
   G-ACh: Generic Header</dd>
	  <dt>DM:</dt><dd>Delay Measurement</dd>
	  <dt>ECMP:</dt><dd>Equal-Cost Multipath</dd>
	  <dt>G-ACh:</dt><dd>Generic Associated Channel (G-ACh).</t>
        <t>
   GAL: Generic Channel</dd>
	  <dt>GAL:</dt><dd>Generic Associated Channel (G-ACh) Label.</t>
        <t>
   LM: Loss Measurement.</t>
        <t>
   LSE: Label Label</dd>
	  <dt>LM:</dt><dd>Loss Measurement</dd>
	  <dt>LSE:</dt><dd>Label Stack Entry.</t>
        <t>
   MPLS: Multiprotocol Entry</dd>
	  <dt>MPLS:</dt><dd>Multiprotocol Label Switching.</t>
        <t>
   PSID: Path Segment Identifier.</t>
        <t>
   SID: Segment Identifier.</t>
        <t>
   SL: Segment List.</t>
        <t>
   SR: Segment Routing.</t>
        <t>
   SR-MPLS: Switching</dd>
	  <dt>PSID:</dt><dd>Path Segment Identifier</dd>
	  <dt>SID:</dt><dd>Segment Identifier</dd>
	  <dt>SL:</dt><dd>Segment List</dd>
	  <dt>SR:</dt><dd>Segment Routing</dd>
	  <dt>SR-MPLS:</dt><dd>Segment Routing with MPLS data plane.</t>
        <t>
   TC: Traffic Class.</t>
        <t>
   TE: Traffic Engineering.</t>
        <t>
   TTL: Time-To-Live.</t>
        <t>
   URO: UDP over MPLS</dd>
	  <dt>TC:</dt><dd>Traffic Class</dd>
	  <dt>TE:</dt><dd>Traffic Engineering</dd>
	  <dt>TTL:</dt><dd>Time to Live</dd>
	  <dt>URO:</dt><dd>UDP Return Object.</t> Object</dd>
	</dl>
      </section>

      <section anchor="sect-2.3" numbered="true" toc="default">
        <name>Reference Topology</name>

<t>
In

	<t>In the Reference Topology reference topology shown in Figure 1, <xref
	target="ure-reference-topology"/>, the querier node Q1 initiates a
	query message, and the responder node R1 transmits a response message
	for the query message received. The response message may be sent back
	to the querier node Q1 on the same path (same (the same set of links and nodes)
	or on a different path in the reverse direction from the path taken
	towards the responder R1.
</t>

<t>
T1 R1.</t>

	<t>T1 is a transmit timestamp, and T4 is a receive timestamp, timestamp; both are
	added by node Q1. T2 is a receive timestamp, and T3 is a transmit timestamp,
	timestamp; both are added by node R1.
</t>

<t>
SR R1.</t>

	<t>SR is enabled with the MPLS data plane on nodes Q1 and R1.  The
	nodes Q1 and R1 are connected via a channel (Section 2.9.1 of <xref (<xref target="RFC6374" format="default"/>).
	sectionFormat="of" section="2.9.1"/>).  The channel may be a directly
	connected link enabled with MPLS (Section 2.9.1 of <xref (<xref target="RFC6374" format="default"/>)
	sectionFormat="of" section="2.9.1"/>) or an SR-MPLS path <xref
	target="RFC8402" format="default"/>.  The link may be a physical
	interface, a virtual link, or a Link Aggregation Group (LAG) <xref
	target="IEEE802.1AX" format="default"/>, or a LAG member link. The
	SR-MPLS path may be an SR-MPLS Policy <xref target="RFC9256"
	format="default"/> on node Q1 (called head-end) the "head-end") with the destination
	to node R1 (called tail-end).
</t> the "tail-end").</t>

        <figure anchor="ure-reference-topology">
          <name>Reference Topology</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
          T1                T2
         /                   \
+-------+       Query         +-------+
|       | - - - - - - - - - ->|       |
|   Q1  |=====================|   R1  |
|       |<- - - - - - - - - - |       |
+-------+       Response      +-------+
         \                   /
          T4                T3
 Querier                       Responder
]]></artwork>
        </figure>

      </section>
    </section>

    <section anchor="sect-3" numbered="true" toc="default">
      <name>Overview</name>

      <t>
          In this document, the procedures defined in <xref target="RFC6374"
          format="default"/>, <xref target="RFC7876" format="default"/>, and
          <xref target="RFC9341" format="default"/> are utilized for delay and
          loss measurement in SR-MPLS networks. Specifically, the one-way,
          two-way, and round-trip delay measurements described in Section
2.4 of <xref
          target="RFC6374" format="default"/> sectionFormat="of" section="2.4"/> are further
          elaborated for application within SR-MPLS networks. Similarly, the
          packet loss measurement procedures outlined in Section
2.2 of <xref
          target="RFC6374" format="default"/> sectionFormat="of" section="2.2"/> are extended for
          use in SR-MPLS networks.
      </t>
      <t>
Packet networks.</t>

	  <t>Packet loss measurement using the Alternate-Marking Method
	  defined in <xref target="RFC9341" format="default"/> may employ the
	  Block Number for data correlation. This is achieved by utilizing the
	  Block Number TLV extension defined in this document.
      </t>

      <t>
    In document.</t>

	  <t>In SR-MPLS networks, the query messages defined in <xref
	  target="RFC6374" format="default"/>
    MUST <bcp14>MUST</bcp14> be
	  transmitted along the same path as the data traffic for links and
	  end-to-end SR-MPLS paths, paths. This is to collect both transmit and receive
	  timestamps for delay measurement and to collect both transmit and
	  receive traffic counters for loss measurement.
      </t>

      <t>
If measurement.</t>

	  <t>If it is desired in SR-MPLS networks that the same path (i.e.,
	  the same set of links and nodes) between the querier and responder
	  be used in both directions of the measurement, then this can be achieved
	  by using the Return Path TLV extension defined in this document.
      </t>

      <t>
The document.</t>

	  <t>The performance measurement procedures for links can be used to
	  compute extended Traffic Engineering (TE) metrics for delay and
	  loss, as described herein. These metrics are advertised in the
	  network using the routing protocol extensions defined in <xref
	  target="RFC7471" format="default"/>, <xref target="RFC8570"
	  format="default"/>, and <xref target="RFC8571" format="default"/>.
      </t>
	  format="default"/>.</t>

    </section>

    <section anchor="sect-4" numbered="true" toc="default">
      <name>Query and Response Messages</name>
      <section anchor="sect-4.1" numbered="true" toc="default">
        <name>Query Message for Links and SR-MPLS Policies</name>
        <section anchor="sect-4.1.1" numbered="true" toc="default">
          <name>Query Message for Links</name>

<t>
The

	  <t>The query message, as defined in <xref target="RFC6374"
	  format="default"/>, is sent over the links for both delay and loss
	  measurement. In each Label Stack Entry (LSE) <xref target="RFC3032"
	  format="default"/> in the MPLS label stack, the TTL value MUST
	  <bcp14>MUST</bcp14> be set to 255 <xref target="RFC5082" format="default"/>.
</t>
	  format="default"/>.</t>
        </section>

        <section anchor="sect-4.1.2" numbered="true" toc="default">
          <name>Query Message for SR-MPLS Policies</name>

      <t>
      An

	  <t>An SR-MPLS Policy Candidate-Path may contain a number of Segment
	  Lists (SLs) (i.e., a stack of MPLS labels) <xref target="RFC9256"
	  format="default"/>. For delay and/or loss measurement for an
	  end-to-end SR-MPLS Policy, the query messages MUST <bcp14>MUST</bcp14> be
	  transmitted for every SL of the SR-MPLS Policy Candidate-Path, Candidate-Path.  This
	  is done by creating a separate session for each SL.  Each query
	  message of a session contains an SR-MPLS label stack of the
	  Candidate-Path, with the G-ACh Label (GAL) at the bottom of the
	  stack (with S=1) as shown in Figure 2. <xref
	  target="ure-header-for-an-end-to-end-sr-mpls-policy"/>.  In each LSE
	  in the MPLS label stack, the TTL value MUST <bcp14>MUST</bcp14> be set to
	  255 <xref target="RFC5082" format="default"/>.
</t> format="default"/>.</t>

          <figure anchor="ure-header-for-an-end-to-end-sr-mpls-policy">
            <name>Example Query Message Header for an End-to-end End-to-End SR-MPLS Policy</name>
            <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Label(1)             | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Label(n)             | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  GAL (value 13)       | TC  |1|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved      |       Channel Type            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>

<t>
The

	  <t>The fields "0001", 0001, Version, Reserved, and Channel Type shown in Figure 2
	  <xref target="ure-header-for-an-end-to-end-sr-mpls-policy"/> are
	  specified in <xref target="RFC5586" format="default"/>.
</t>

<t>
The format="default"/>.</t>

	  <t>The SR-MPLS label stack can be empty in the case of a one-hop
	  SR-MPLS Policy with an Implicit NULL label.
</t>

<t>
For label.</t>

	  <t>For an SR-MPLS Policy, to ensure that the query message is
	  processed by the intended responder, the Destination Address TLV
	  (Type 129) <xref target="RFC6374" format="default"/> containing an
	  address of the responder can be sent in the query messages. The
	  responder that supports this TLV MUST <bcp14>MUST</bcp14> return Success in "Control Code" Control Code 0x1 (Success) <xref target="RFC6374" format="default"/> if it is
	  the intended destination for the query. Otherwise, it MUST
	  <bcp14>MUST</bcp14> return 0x15: Error - 0x15: Invalid Destination Node
	  Identifier <xref target="RFC6374" format="default"/>.
</t> format="default"/>.</t>

        </section>
      </section>
      <section anchor="sect-4.2" numbered="true" toc="default">
        <name>Response Message for Links and SR-MPLS Policies</name>
        <section anchor="sect-4.2.1" numbered="true" toc="default">
          <name>One-way
          <name>One-Way Measurement Mode</name>

<t>

<!-- [rfced] May we update "out-of-band response messages" to "Out-of-Band Response Requested messages..."?  It is unclear whether the text refers to the Response Requested messages or res ponses to Out-of-Band Response Requested messages.

Original:
   In one-way measurement mode defined in Section 2.4 of [RFC6374], the
   querier can receive "out-of-band" response messages with an IP/UDP
   header by properly setting the UDP Return Object (URO) TLV in the
   query message.
-->

	  <t>In the one-way measurement mode defined in <xref target="RFC6374" format="default"/>,
	  sectionFormat="of" section="2.4"/>, the querier can receive "out-of-band" response messages with an IP/UDP header "out-of-band" by properly
	  setting the UDP Return Object (URO) TLV in the query message. The
	  URO TLV (Type=131) (Type 131) is defined in <xref target="RFC7876"
	  format="default"/> and includes the UDP-Destination-Port and IP Address.
	  address.  When the querier sets an IP address and a UDP port in the URO TLV, the response message MUST <bcp14>MUST</bcp14> be sent to that IP address, with that IP address as the destination address and the UDP port as the destination port. In addition, the "Control Code" Control Code in the query message MUST
	  <bcp14>MUST</bcp14> be set to "out-of-band response requested" Out-of-band Response Requested <xref
	  target="RFC6374" format="default"/>.
</t> format="default"/>.</t>

        </section>
        <section anchor="sect-4.2.2" numbered="true" toc="default">
          <name>Two-way
          <name>Two-Way Measurement Mode</name>

<t>
   In the two-way measurement mode defined in Section 2.4 of <xref target="RFC6374" format="default"/>, sectionFormat="of" section="2.4"/>, the
   response messages SHOULD <bcp14>SHOULD</bcp14> be sent back one of two ways: either they are sent
   back in-band on the same link link, or they are sent back on the same end-to-end
   SR-MPLS path (same (i.e., the same set of links and nodes) in the reverse
   direction to the querier, querier. This is done in order to perform accurate two-way two-
   way delay measurement.
</t>

<t>
For measurement.</t>

	  <t>For links, the response message as defined in <xref
	  target="RFC6374" format="default"/> is sent back on the same
	  incoming link where the query message is received. In this case, the "Control Code"
	  Control Code in the query message MUST <bcp14>MUST</bcp14> be set to "in-band response requested"
	  In-band Response Requested <xref target="RFC6374" format="default"/>.
</t>

<t>
For
	  format="default"/>.</t>

<t>For end-to-end SR-MPLS paths, the responder transmits the response
         message (example (see the example as shown in Figure 2) <xref
         target="ure-header-for-an-end-to-end-sr-mpls-policy"/>) on a specific
         return SR-MPLS path. The    In the query message, the querier can request in the query message for that the responder to send the response message back on a given return  path using the MPLS Label Stack sub-TLV Sub-TLV in the Return Path TLV defined in this document.
</t>
	</section>

        <section anchor="sect-4.2.3" numbered="true" toc="default">
          <name>Loopback Measurement Mode</name>

<t>
The

	  <t>The loopback measurement mode defined in Section 2.8 of <xref target="RFC6374" format="default"/>
	  sectionFormat="of" section="2.8"/> is used to measure round-trip
	  delay for a bidirectional circular path <xref target="RFC6374"
	  format="default"/> in SR-MPLS networks. In this mode for SR-MPLS,
	  the received query messages are not punted out of the fast path in
	  forwarding (i.e., to the slow path or control plane) at the
	  responder. In other words, the responder does not process the
	  payload or generate response messages. The loopback function simply
	  returns the received query message to the querier without responder
	  modifications <xref target="RFC6374" format="default"/>.
</t>

<t>
The format="default"/>.</t>

	  <t>The loopback mode is done by generating "queries" with the
	  Response flag set to 1 and adding the Loopback Request object (Type
	  3) <xref target="RFC6374" format="default"/>. The In query messages, the
	  label stack, as shown in Figure 3, in query messages, <xref
	  target="ure-header-for-an-end-to-end-sr-mpls-policy-in-loopback"/>,
	  carries both the forward and reverse path labels in the MPLS
	  header. The GAL is still carried at the bottom of the label stack
	  (with S=1).
</t> S=1).</t>

          <figure anchor="ure-header-for-an-end-to-end-sr-mpls-policy-in-loopback">
            <name>Example Query Message Header for an End-to-end End-to-End SR-MPLS Policy in the Loopback Measurement Mode</name>
            <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Label(1)             | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Label(n)             | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Reverse Path Label(1)| TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Reverse Path Label(n)| TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  GAL (value 13)       | TC  |1|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved      |       Channel Type            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>

         </section>
      </section>
    </section>

    <section anchor="sect-5" numbered="true" toc="default">
      <name>Delay and Loss Measurement</name>

      <section anchor="sect-5.1" numbered="true" toc="default">
        <name>Delay Measurement Message</name>

    <t>

<!-- [rfced] Please review these similar sentences and let us know if we may
update them for readability.

More specifically, what does "which" refer to in the examples below? Does it
refer to the ACH or the different values in parentheses?

In addition, we were unable to find "Combined DM+LM" in RFC 6374 as seen in
the third example. Should this be updated to "combined LM/DM message" as used
in RFC 6374?

Original:
   As defined in <xref target="RFC6374" format="default"/>, [RFC6374], MPLS Delay Measurement (DM) query and
   response messages use the Associated Channel Header (ACH) (value
   0x000C for delay measurement) <xref target="RFC6374" format="default"/>, [RFC6374], which identifies the message
   type and the message payload as defined in Section 3.2 <xref target="RFC6374" format="default"/> [RFC6374]
   following the ACH.

   As defined in [RFC6374], MPLS LM query and response messages use the
   Associated Channel Header (ACH) (value 0x000A for direct loss
   measurement or value 0x000B for inferred loss measurement), which
   identifies the message type and the message payload defined in
   Section 3.1 [RFC6374] following the ACH.

   As defined in [RFC6374], Combined DM+LM query and response messages
   use the Associated Channel Header (ACH) (value 0x000D for direct loss
   and delay measurement or value 0x000E for inferred loss and delay
   measurement), which identifies the message type and the message
   payload defined in Section 3.3 [RFC6374] following the ACH.

Perhaps:
   As defined in [RFC6374], MPLS Delay Measurement (DM) query and response
   messages use the Associated Channel Header (ACH) (with the value 0x000C for
   delay measurement). This value identifies the message type and the
   message payload that follow the ACH, as defined in Section 3.2 of [RFC6374].

   As defined in [RFC6374], MPLS LM query and response messages use the ACH
   (with the value 0x000A for direct loss measurement or the value 0x000B for
   inferred loss measurement). This value identifies the message type and the
   message payload that follow the ACH, as defined in Section 3.1 of [RFC6374].

   As defined in [RFC6374], combined DM+LM query and response messages use the
   ACH (with the value 0x000D for direct loss and delay measurement or the
   value 0x000E for inferred loss and delay measurement). This value
   identifies the message type and the message payload that follows the ACH,
   as defined in Section 3.3 of [RFC6374].

-->

    <t>As defined in <xref target="RFC6374" format="default"/>, MPLS Delay
    Measurement (DM) query and response messages use the Associated Channel
    Header (ACH) (with the value 0x000C for delay measurement). This value identifies the message type and message
    payload that follow the ACH, as defined in <xref target="RFC6374" sectionFormat="of"
    section="3.2"/>. For delay measurement, the same ACH
    value is used for both links and end-to-end SR-MPLS Policies.
</t> Policies.</t>

    </section>

    <section anchor="sect-5.2" numbered="true" toc="default">
      <name>Loss Measurement Message</name>

      <t>
The

      <t>The Loss Measurement (LM) protocol can perform two distinct kinds of
      loss measurement as described in Section 2.9.8 of <xref target="RFC6374" format="default"/>.
</t>
      sectionFormat="of" section="2.9.8"/>.</t>

      <ul spacing="normal">
	<li>In the inferred mode, LM will measure the loss of specially generated
	test messages to infer the approximate data plane loss level. Inferred
	mode LM provides only approximate loss accounting.</li>
	<li>In the direct mode, LM will directly measure data plane packet
	loss. Direct mode LM provides perfect loss accounting but may require
	hardware support.</li>
      </ul>

<t>
As

      <t>As defined in <xref target="RFC6374" format="default"/>, MPLS LM
      query and response messages use the Associated Channel Header (ACH) (value ACH (with the value 0x000A for direct loss
      measurement or value 0x000B for inferred loss measurement), which measurement). This value identifies the message type and the message payload that follow the ACH, as defined in Section 3.1 <xref
      target="RFC6374" format="default"/> following the ACH. sectionFormat="of" section="3.1"/>. For loss measurement, the same ACH value is used for both links and
      end-to-end SR-MPLS Policies.
</t> Policies.</t>

      </section>

      <section anchor="sect-5.3" numbered="true" toc="default">
        <name>Combined Loss/Delay Measurement Message</name>

    <t>
As

	<t>As defined in <xref target="RFC6374" format="default"/>, Combined DM+LM combined
	 LM/DM query and response messages use the Associated Channel Header (ACH) (value ACH (with the value 0x000D for
	direct loss and delay measurement or the value 0x000E for inferred loss
	and delay measurement), which identifies measurement).  The value identies the message type and the
	message payload that follows the ACH, as defined in Section 3.3 <xref target="RFC6374" format="default"/> following the ACH. sectionFormat="of"
	section="3.3"/>. For combined loss and delay
	measurement, the same ACH value is used for both links and end-to-end
	SR-MPLS Policies.
</t> Policies.</t>
      </section>

      <section anchor="sect-5.4" numbered="true" toc="default">
        <name>Counters</name>

<t>
The

<t>The Path Segment Identifier (PSID) <xref target="RFC9545"
	format="default"/> MUST <bcp14>MUST</bcp14> be carried in the received data
	packet for the traffic flow under measurement measurement, in order to account for accounting received
	traffic on the egress node of the SR-MPLS Policy. In the direct mode, the
	PSID in the received query message, as message (as shown in Figure 4, <xref
	target="ure-with-path-segment-identifier-for-sr-mpls-policy"/>) can be
	used to associate the received traffic counter on the responder to
	detect the transmit packet loss for the end-to-end SR-MPLS Policy.
</t>

<t>
In Policy.</t>

	<t>In the inferred mode, the PSID in the received query messages, as messages (as shown
	in Figure 4, <xref target="ure-with-path-segment-identifier-for-sr-mpls-policy"/>) can be
	used to count the received query messages on the responder to detect
	the transmit packet loss for an end-to-end SR-MPLS Policy.
</t> Policy.</t>

        <figure anchor="ure-with-path-segment-identifier-for-sr-mpls-policy">
          <name>Example with Path Segment Identifier the PSID for SR-MPLS Policy</name>

          <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Label(1)             | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Label(n)             | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  PSID                 | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  GAL (value 13)       | TC  |1|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved      |       Channel Type            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

    <t>
The

    <t>The fields "0001", 0001, Version, Reserved, and Channel Type shown in Figure 4 <xref
    target="ure-with-path-segment-identifier-for-sr-mpls-policy"/> are
    specified in <xref target="RFC5586" format="default"/>.
</t>

<t>
Different format="default"/>.</t>

    <t>Different values of the PSID can be used per Candidate-Path to account for accounting
    received traffic and to measure packet loss at the Candidate-Path
    level. Similarly, different values of the PSID can be used per Segment List (SL) of
    the Candidate-Path for accounting received traffic to measure packet loss
    at the Segment List SL level. The same value of the PSID can be used for all Segment Lists
    SLs of the SR-MPLS Policy to measure packet loss at the SR-MPLS
    Policy level.
</t> level.</t>

      </section>

      <section anchor="sect-5.5" numbered="true" toc="default">
        <name>Block Number for Counters</name>

    <t>
The

    <t>The packet loss measurement using the Alternate-Marking Method defined
    in <xref target="RFC9341" format="default"/> may use the block number for
    data correlation for the traffic flow under measurement. As defined in Section 3.1 of
    <xref target="RFC9341" format="default"/>, sectionFormat="of" section="3.1"/>, the block
    number is used to divide the traffic flow into consecutive blocks and
    count the number of packets transmitted and received in each block for
    loss measurement.
</t>

<t>
As measurement.</t>

    <t>As described in Section 4.3 of <xref target="RFC9341" format="default"/>, sectionFormat="of"
    section="4.3"/>, a protocol-based distributed solution can be used to
    exchange values of counters on the nodes for loss measurement. That
    solution is further described in this document using the LM messages
    defined in <xref target="RFC6374" format="default"/>.
</t>

<t>
The format="default"/>.</t>

    <t>The querier node assigns a block number to the block of data packets of
    the traffic flow under measurement. The querier counts the number of
    packets transmitted in each block. The mechanism for the assignment of the
    block number is a local decision on the querier and is outside the scope
    of this document.
</t>

<t>
As document.</t>

    <t>As an example, the querier can use the procedure defined in <xref target="I-D.ietf-mpls-inband-pm-encapsulation"
    target="RFC9714" format="default"/> for
    alternate marking of the data packets of the traffic flow under
    measurement. The responder counts the number of received packets in each
    block based on the marking in the received data packets. The querier and
    responder maintain separate sets of transmit and receive counters for each
    marking. The marking can be used as a block number number, or a separate block
    number can be incremented when the marking changes. Other methods can be
    defined for alternate marking of the data packets of the traffic flow
    under measurement to assign a block number for the counters.
</t>

<t>
The counters.</t>

<t>The LM query and response messages defined in <xref target="RFC6374"
    format="default"/> are used to measure packet loss for the block of data
    packets transmitted with the previous marking while marking, whereas data packets carry
    alternate marking. Specifically, LM query and response messages carry the
    transmit and receive counters (which are currently not incrementing) along
    with their block number to correlate for loss measurement.
</t>

<t> measurement.</t>

<t><xref target="RFC9341" sectionFormat="of" section="4.3"/> specifies that:
"The assumption of the block number this BN mechanism is that the measurement nodes are time synchronized" as specified in Section 4.3 of <xref target="RFC9341" format="default"/>
synchronized." However, this is not necessary, as the block number on the
responder can be synchronized based on the received LM query messages.
</t> messages.</t>

</section>
</section>

    <section anchor="sect-6" numbered="true" toc="default">
      <name>TLV Extensions</name>
      <section anchor="sect-6.1" numbered="true" toc="default">
        <name>Return Path TLV Extension</name>

<t>
In

	<t>In the two-way measurement mode, the responder may transmit the
	response message on a specific return path, for example, in an ECMP
	environment. The querier can request in the query message for the
	responder to send a response message back on a given return path
	(e.g., a co-routed bidirectional path). This allows the responder to
	avoid creating and maintaining additional states (containing return
	paths) for the sessions.
</t>

<t>
The sessions.</t>

	<t>The querier may not be directly reachable from the responder in a
	network. The querier in In this case MUST case, the querier <bcp14>MUST</bcp14> send its
	reachability path information to the responder using the Return Path TLV.
</t>

<t>
<xref
	TLV.</t>

	<t><xref target="RFC6374" format="default"/> defines query and
	response messages that can include one or more optional TLVs. A new TLV Type (TBA1) is defined in this This document for defines the the Return Path TLV (5) to
	carry return path information in query messages. The Return Path TLV
	is specific to a measurement session. The format of the Return Path
	TLV is shown in Figure 5:
</t> <xref target="ure-return-path-tlv"/> below:</t>

        <figure anchor="ure-return-path-tlv">
          <name>Return Path TLV</name>
          <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Type = TBA1 5     |    Length     |      Reserved                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Return Path Sub-TLV                        |
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

<t>
The

	  <t>The Length is a one-byte field and is equal to the length of the
	  Return Path Sub-TLV and the Reserved field in bytes.  The Length MUST NOT
	  <bcp14>MUST NOT</bcp14> be 0 or 1.
</t>

<t>
The 1.</t>

	  <t>The Return Path TLV is defined in the Mandatory "Mandatory TLV Type Type"
	  registry space <xref target="RFC6374" format="default"/>. The
	  querier MUST <bcp14>MUST</bcp14> only insert one Return Path TLV in the
	  query message. The responder that supports this TLV MUST
	  <bcp14>MUST</bcp14> only process the first Return Path TLV and
	  ignore the other Return Path TLVs if present. The responder that
	  supports this TLV also MUST <bcp14>MUST</bcp14> send the response message
	  back on the return path specified in the Return Path TLV. The
	  responder also MUST NOT <bcp14>MUST NOT</bcp14> add a Return Path TLV in the
	  response message. The message.</t>

	  <t>The Reserved field MUST <bcp14>MUST</bcp14> be set to 0 and MUST
	  <bcp14>MUST</bcp14> be ignored on the receive side.
</t> side.</t>

        <section anchor="sect-6.1.1" numbered="true" toc="default">
          <name>Return Path Sub-TLV Extension</name>

      <t>
The

      <t>The Return Path TLV contains a Sub-TLV to carry the return path. The
      format of the MPLS Label Stack Sub-TLV is shown in Figure 6. <xref
      target="ure-segment-list-sub-tlv-in-return-path-tlv"/>. The label
      entries in the Sub-TLV MUST <bcp14>MUST</bcp14> be in network order. The MPLS
      Label Stack Sub-TLV in the Return Path TLV is of the following type:
</t> type:</t>

          <ul spacing="normal">
            <li>Type (value 1): MPLS Label Stack of the Return Path</li>
          </ul>
          <figure anchor="ure-segment-list-sub-tlv-in-return-path-tlv">
            <name>MPLS Label Stack Sub-TLV in the Return Path TLV</name>
            <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type=1     |    Length     |      Reserved                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Label(1)             | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Label(n)             | TC  |1|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>

<t>
The

	  <t>The MPLS Label Stack label stack contains a list of 32-bit LSE LSEs that includes
	  a 20-bit label value, an 8-bit TTL value, a 3-bit TC value, and a 1-bit EOS End of Stack (S) field. An MPLS Label Stack Sub-TLV may carry a stack of labels
	  or a Binding SID label <xref target="RFC8402" format="default"/> of
	  the Return SR-MPLS Policy.
</t>

<t>
The Policy.</t>

	  <t>The Length is a one-byte field and is equal to the length of the
	  label stack field and the Reserved field in bytes. The Length MUST NOT
	  <bcp14>MUST NOT</bcp14> be 0 or 1.
</t>

<t>
    The 1.</t>

	  <t>The Return Path TLV MUST <bcp14>MUST</bcp14> carry only one Return
	  Path Sub-TLV. The MPLS Label Stack in the Return Path Sub-TLV MUST
	  <bcp14>MUST</bcp14> contain at least one MPLS Label. The responder
	  that supports this Sub-TLV MUST <bcp14>MUST</bcp14> only process the
	  first Return Path Sub-TLV and ignore the other Return Path Sub-TLVs
	  if present. The responder that supports this Sub-TLV MUST
	  <bcp14>MUST</bcp14> send the response message back on the return
	  path specified in the Return Path Sub-TLV.
    </t>

    <t>
The Sub-TLV.</t>

	  <t>The Reserved field MUST <bcp14>MUST</bcp14> be set to 0 and MUST
	  <bcp14>MUST</bcp14> be ignored on the receive side.
</t> side.</t>

        </section>
      </section>
      <section anchor="sect-6.2" numbered="true" toc="default">
        <name>Block Number TLV Extension</name>

    <t>
<xref

	<t><xref target="RFC6374" format="default"/> defines query and
	response messages that can include one or more optional TLVs. A new TLV Type (value TBA2) is defined in this This document to carry defines the Block Number TLV (6) to carry (8-bit) Block Number of
	the traffic counters in the LM query and response
	messages. The format of the Block Number TLV is shown in Figure 7:
</t> <xref
	target="ure-block-number-tlv"/>:</t>

        <figure anchor="ure-block-number-tlv">
          <name>Block Number TLV</name>
          <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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Type = TBA2    Type=6     |    Length     | Reserved    |R| Block Number  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

<t>
The

	<t>The Length is a one-byte field and is equal to 2 bytes.
</t>

<t>
    The bytes.</t>

	<t>The Block Number TLV is defined in the Mandatory "Mandatory TLV Type Type" registry
	space <xref target="RFC6374" format="default"/>.  The querier MUST
	<bcp14>MUST</bcp14> only insert one Block Number TLV in the query
	message to identify the Block Number for the traffic counters in the
	forward direction. The responder that supports this TLV MUST
	<bcp14>MUST</bcp14> only insert one Block Number TLV in the response
	message to identify the Block Number for the traffic counters in the
	reverse direction.  The responder also MUST <bcp14>MUST</bcp14> return the
	first Block Number TLV from the query message and ignore the other
	Block Number TLVs if present.  The Block Number TLV is specific to a
	measurement session.  The R flag is used to indicate the query and
	response message direction associated with the Block Number.  The R
	flag MUST <bcp14>MUST</bcp14> be clear in the query message for the Block
	Number associated with Counter 1 and Counter 2, and set in the
	response message for the Block Number associated with Counter 3 and
	Counter 4.
    </t>

    <t>
    The 4.</t>

	<t>The Reserved field MUST <bcp14>MUST</bcp14> be set to 0 and MUST
	<bcp14>MUST</bcp14> be ignored on the receive side.
</t> side.</t>

      </section>
    </section>

    <section anchor="sect-7" numbered="true" toc="default">
      <name>ECMP for SR-MPLS Policies</name>

      <t>
The

      <t>The SLs of an SR-MPLS Policy can have ECMPs between the source and
      transit nodes, between transit nodes, and between transit and
      destination nodes. Usage of node SID a node-SID <xref target="RFC8402"
      format="default"/> by the SLs of an SR-MPLS Policy can result in ECMP
      paths. In addition, usage of Anycast SID an Anycast-SID <xref target="RFC8402"
      format="default"/> by the SLs of an SR-MPLS Policy can result in ECMP
      paths via transit nodes that are part of that Anycast anycast group. The query
      and response messages are sent to traverse different ECMP paths to
      measure the delay of each ECMP path of an SL.
</t>

<t>
The SL.</t>

      <t>The forwarding plane has various hashing functions available to
      forward packets on specific ECMP paths. For end-to-end SR-MPLS Policy
      delay measurement, different entropy label values <xref target="RFC6790"
      format="default"/> values can be used in query and response messages to
      take advantage of the hashing function in the forwarding plane to
      influence the ECMP path taken by them.
</t>

<t>
The them.</t>

      <t>The considerations for loss measurement for different ECMP paths of
      an SR-MPLS Policy are outside the scope of this document.
</t> document.</t>
    </section>

    <section anchor="sect-8" numbered="true" toc="default">
      <name>Extended TE Link Metrics Advertisements</name>

      <t>
The Advertisement</name>

      <t>The extended TE metrics for link delay (namely, average delay,
      minimum delay, maximum delay delay, and delay-variance) and packet loss can be
      computed using the performance measurement procedures described in this
      document and can be advertised in the routing domain as follows:
</t> follows:</t>

      <ul spacing="normal">
	<li>For OSPF, IS-IS, and BGP-LS, the Border Gateway Protocol - Link State
	(BGP-LS), the protocol extensions defined in <xref target="RFC7471"
	format="default"/>, <xref target="RFC8570" format="default"/>, and
	<xref target="RFC8571" format="default"/>, respectively, are used for
	advertising the extended TE link delay and loss metrics in the
	network.</li>
	<li>The extended TE link delay and loss metrics are advertised for
	Layer-2 LAG bundle member links in OSPF <xref target="RFC9356"
	format="default"/> and IS-IS <xref target="RFC8668" format="default"/>
	using the same protocol extensions defined in <xref target="RFC7471"
	format="default"/> and <xref target="RFC8570" format="default"/>,
	respectively.</li>
	<li>The advertised delay-variance metric is computed as Packet Delay
	Variation (PDV), as described in Section 4.2 of <xref target="RFC5481" format="default"/>.</li>
	sectionFormat="of" section="4.2"/>.</li>
      </ul>

    </section>
    <section anchor="sect-9" numbered="true" toc="default">
      <name>Backwards Compatibility</name>

      <t>
The

      <t>The procedures defined in this document are backwards compatible with
      the procedures  defined in <xref target="RFC6374"  format="default"/> at
      both the querier and the responder.  If the responder does not support the
      new Mandatory TLV Types defined in this document document, it will return Error
      0x17: Unsupported Mandatory TLV Object as per <xref target="RFC6374" format="default"/>.
</t>
      format="default"/>.</t>
    </section>

    <section anchor="sect-10" numbered="true" toc="default">
      <name>Manageability Considerations</name>

      <t>
The

      <t>The manageability considerations described in Section 7 of <xref target="RFC6374" format="default"/>
      sectionFormat="of" section="7"/> and Section 6 of <xref target="RFC7876" format="default"/>
      sectionFormat="of" section="6"/> are applicable to this specification.
</t>
      specification.</t>
    </section>

    <section anchor="sect-11" numbered="true" toc="default">
      <name>Security Considerations</name>

      <t>
The

      <t>The security considerations specified in <xref target="RFC6374"
      format="default"/>, <xref target="RFC7471" format="default"/>, <xref
      target="RFC8570" format="default"/>, <xref target="RFC8571"
      format="default"/>, <xref target="RFC7876" format="default"/>, and <xref
      target="RFC9341" format="default"/> also apply to the procedures
      described in this document.
</t>

<t>
The document.</t>

      <t>The procedure defined in this document is intended for deployment in
      a single operator administrative domain. As such, the querier node, the
      responder node, forward, the forward path, and the return paths are provisioned
      by the operator for the probe session. It is assumed that the operator
      has verified the integrity of the forward and return paths of the probe packets.
</t>

<t>
The "Return Path"
      packets.</t>

      <t>The Return Path TLV extensions defined in this document may be used
      for potential address spoofing. For example, a query message may carry a
      return path that has a destination that is not local at the querier. To
      prevent such possible attacks, the responder may drop the query messages
      when it cannot determine whether the return path has the destination
      local at the querier. The querier may send a proper source address in
      the "Source Address" TLV that the Source Address TLV. The responder can use this to make that
      determination, for example, by checking the access control list
      provisioned by the operator.
</t> operator.</t>

    </section>

    <section anchor="sect-12" numbered="true" toc="default">
      <name>IANA Considerations</name>

      <t>IANA is requested to allocate has allocated values for the following Mandatory TLV
      Types for <xref target="RFC6374" format="default"/> from the "MPLS
      Loss/Delay Measurement TLV Object" registry contained within the
      "Generic Associated Channel (G-ACh) Parameters" registry set:</t> group:</t>

      <table anchor="iana-tlv-type-tbl" align="center">
        <name>MPLS Loss/Delay Measurement TLV Types</name>
        <thead>
          <tr>
            <th align="left">Value</th> align="left">Code</th>
            <th align="center">Description</th> align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">TBA1</td> align="left">5</td>
            <td align="center">Return Path TLV</td> align="left">Return Path</td>
            <td align="left">This document</td> align="left">RFC 9779</td>
          </tr>
          <tr>
            <td align="left">TBA2</td> align="left">6</td>
            <td align="center">Block Number TLV</td> align="left">Block Number</td>
            <td align="left">This document</td> align="left">RFC 9779</td>
          </tr>
        </tbody>
      </table>

      <t>
The

     <t>The Block Number TLV is carried in the query and response messages,
     and the Return Path TLV is carried in the query messages.
</t>

<t>
IANA is requested to create a registry for messages.</t>

     <t>IANA has created the "Return Path Sub-TLV Type." Types" registry.
All code points in the range 0 through 175 in this registry shall be allocated according to the "IETF Review" procedure as specified in <xref target="RFC8126" format="default"/>. Code points in the range 176 through 239 in this registry shall be are allocated according to per the "First Come, First Served" procedure as specified registration policies shown in <xref target="RFC8126" format="default"/>. Remaining code points are allocated according to target="iana-return-path-tbl"/> (see <xref target="iana-return-path-tbl" format="default"/>: target="RFC8126"/>).
</t>

      <table anchor="iana-return-path-tbl" align="center">
        <name>Return Path Sub-TLV Type Registry</name>
        <thead>
          <tr>
            <th align="left">Value</th>
            <th align="center">Description</th> align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">1 - 175</td>
            <td align="center">IETF align="left">IETF Review</td>
            <td align="left">This document</td> align="left">RFC 9779</td>
          </tr>
          <tr>
            <td align="left">176 - 239</td>
            <td align="center">First align="left">First Come First Served</td>
            <td align="left">This document</td> align="left">RFC 9779</td>
          </tr>
          <tr>
            <td align="left">240 - 251</td>
            <td align="center">Experimental align="left">Experimental Use</td>
            <td align="left">This document</td> align="left">RFC 9779</td>
          </tr>
          <tr>
            <td align="left">252 - 254</td>
            <td align="center">Private align="left">Private Use</td>
            <td align="left">This document</td> align="left">RFC 9779</td>
          </tr>
        </tbody>
      </table>

      <t>This document defines the following values in the Return "Return Path Sub-TLV Type
      Type" registry:</t>

      <table anchor="iana-return-path-type-tbl" align="center">
        <name>Return Path Sub-TLV Types</name>
        <thead>
          <tr>
            <th align="left">Value</th>
            <th align="center">Description</th> align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">0</td>
            <td align="center">Reserved</td> align="left">Reserved</td>
            <td align="left">This document</td> align="left">RFC 9779</td>
          </tr>
          <tr>
            <td align="left">1</td>
            <td align="center">MPLS align="left">MPLS Label Stack of the Return Path</td>
            <td align="left">This document</td> align="left">RFC 9779</td>
          </tr>
          <tr>
            <td align="left">255</td>
            <td align="center">Reserved</td> align="left">Reserved</td>
            <td align="left">This document</td> align="left">RFC 9779</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
    &RFC2119;
    &RFC6374;
    &RFC7876;
    &RFC8174;
    &RFC9341;
    <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.6374.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7876.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.9341.xml"/>
      </references>

      <references>
       <name>Informative References</name>
    &RFC3031;
    &RFC3032;
    &RFC5082;
    &RFC5481;
    &RFC5586;
    &RFC6790;
    &RFC7471;
    &RFC8126;
    &RFC8402;
    &RFC8570;
    &RFC8571;
    &RFC8668;
    &RFC9256;
    &RFC9356;
    &RFC9545;

      &I-D.ietf-mpls-inband-pm-encapsulation;
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5082.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5481.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5586.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6790.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7471.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8570.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8571.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8668.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9356.xml"/>
    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9545.xml"/>

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

        <reference anchor="IEEE802.1AX">
          <front>
            <title>IEEE Standard for Local and metropolitan area networks Metropolitan Area Networks - Link Aggregation</title>
            <author>
              <organization>
                   IEEE Std. 802.1AX
              </organization>
              <organization>IEEE</organization>
            </author>
            <date month="November" year="2008"/> month="May" year="2020"/>
          </front>
	  <seriesInfo name="IEEE" value="Std 802.1AX-2020"/>
	  <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9105034"/>
        </reference>

      </references>
    </references>

    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>

<t>
The

      <t>The authors would like to thank Thierry Couture and Ianik Semco <contact fullname="Thierry Couture"/>
      and <contact fullname="Ianik Semco"/> for the discussions on the use
      cases for performance measurement in segment routing networks. The
      authors would like to thank Patrick Khordoc, Ruby Lin, and Haowei Shi <contact fullname="Patrick Khordoc"/>,
      <contact fullname="Ruby Lin"/>, and <contact fullname="Haowei Shi"/> for
      implementing the mechanisms defined in this document. The authors would
      like to thank Greg Mirsky and Xiao Min <contact fullname="Greg Mirsky"/> and <contact
      fullname="Xiao Min"/> for providing many useful comments and
      suggestions. The authors would also like to thank Stewart Bryant, Sam Aldrin, Tarek Saad, and Rajiv Asati <contact
      fullname="Stewart Bryant"/>, <contact fullname="Sam Aldrin"/>, <contact
      fullname="Tarek Saad"/>, and <contact fullname="Rajiv Asati"/> for their
      review comments. Thanks to Huaimo Chen, Yimin Shen, and Xufeng Liu <contact fullname="Huaimo Chen"/>,
      <contact fullname="Yimin Shen"/>, and <contact fullname="Xufeng Liu"/>
      for MPLS-RT the MPLS expert review, Zhaohui Zhang review; <contact fullname="Zhaohui Zhang"/> for
      the RTGDIR early review, Tony Li review; <contact fullname="Tony Li"/> for shepherd's review, Ned Smith
      review; <contact fullname="Ned Smith"/> for the SECDIR review, Roni Even review; <contact
      fullname="Roni Even"/> for the Gen-ART review, Marcus Ihlar review; <contact fullname="Marcus
      Ihlar"/> for the TSV-ART review, Dhruv Dhody review; <contact fullname="Dhruv Dhody"/> for
      the OPSDIR review, Gunter review; and <contact fullname="Gunter Van de Velde, Paul Wouters, Eric Vyncke, Murray Kucherawy, John Scudder, and Roman Danyliw Velde"/>,
      <contact fullname="Paul Wouters"/>, <contact fullname="Éric Vyncke"/>,
      <contact fullname="Murray Kucherawy"/>, <contact fullname="John
      Scudder"/>, and <contact fullname="Roman Danyliw"/> for the IESG review.
</t>
      review.</t>

    </section>
    <section numbered="false" anchor="contributors" toc="default">
      <name>Contributors</name>
      <artwork name="" type="" align="left" alt=""><![CDATA[
Sagar Soni
Cisco

    <contact fullname="Sagar Soni">
      <organization>Cisco Systems, Inc.
Email: sagsoni@cisco.com

Zafar Ali
Cisco Inc.</organization>
      <address>
        <email>sagsoni@cisco.com</email>
      </address>
    </contact>

    <contact fullname="Zafar Ali">
      <organization>Cisco Systems, Inc.
Email: zali@cisco.com

Pier Inc.</organization>
      <address>
        <email>zali@cisco.com</email>
      </address>
    </contact>

    <contact fullname="Pier Luigi Ventre
CNIT
Italy
Email: pierluigi.ventre@cnit.it
]]></artwork> Ventre">
      <organization>CNIT</organization>
      <address>
        <postal>
          <country>Italy</country>
        </postal>
        <email>pierluigi.ventre@cnit.it</email>
      </address>
    </contact>

    </section>
  </back>

</rfc>