<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" submissionType="IETF" docName="draft-ietf-mpls-rfc6374-sr-17" number="9779" category="std" ipr="trust200902" obsoletes="" updates="" xml:lang="en" sortRefs="false" consensus="true" symRefs="true" tocInclude="true" prepTime="2025-05-08T11:16:18" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-sr-17" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9779" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Performance Measurement for SR-MPLS">Performance Measurement for Segment Routing Networks with the MPLS Data Plane</title>
    <seriesInfo name="RFC" value="9779" stream="IETF"/>
    <author fullname="Rakesh Gandhi" initials="R." role="editor" surname="Gandhi">
      <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <country>Canada</country>
        </postal>
        <email>rgandhi@cisco.com</email>
      </address>
    </author>
    <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
      <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
      <address>
        <email>cfilsfil@cisco.com</email>
      </address>
    </author>
    <author fullname="Daniel Voyer" initials="D." surname="Voyer">
      <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <country>Canada</country>
        </postal>
        <email>davoyer@cisco.com</email>
      </address>
    </author>
    <author fullname="Stefano Salsano" initials="S." surname="Salsano">
      <organization showOnFrontPage="true">Universita di Roma "Tor Vergata"</organization>
      <address>
        <postal>
          <country>Italy</country>
        </postal>
        <email>stefano.salsano@uniroma2.it</email>
      </address>
    </author>
    <author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
      <organization showOnFrontPage="true">Huawei</organization>
      <address>
        <email>mach.chen@huawei.com</email>
      </address>
    </author>
    <date month="05" 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 pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
	This document specifies the application of the MPLS loss and delay
	measurement techniques (originally defined in RFCs 6374, 7876, and
	9341) within Segment Routing (SR) networks that utilize the MPLS data
	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>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9779" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions-used-in-this-do">Conventions Used in This Document</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-abbreviations">Abbreviations</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reference-topology">Reference Topology</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overview">Overview</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-query-and-response-messages">Query and Response Messages</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-query-message-for-links-and">Query Message for Links and SR-MPLS Policies</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.1.2">
                  <li pn="section-toc.1-1.4.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.1.1"><xref derivedContent="4.1.1" format="counter" sectionFormat="of" target="section-4.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-query-message-for-links">Query Message for Links</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.2.1"><xref derivedContent="4.1.2" format="counter" sectionFormat="of" target="section-4.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-query-message-for-sr-mpls-p">Query Message for SR-MPLS Policies</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-response-message-for-links-">Response Message for Links and SR-MPLS Policies</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-one-way-measurement-mode">One-Way Measurement Mode</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-two-way-measurement-mode">Two-Way Measurement Mode</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.3.1"><xref derivedContent="4.2.3" format="counter" sectionFormat="of" target="section-4.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-loopback-measurement-mode">Loopback Measurement Mode</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-delay-and-loss-measurement">Delay and Loss Measurement</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-delay-measurement-message">Delay Measurement Message</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-loss-measurement-message">Loss Measurement Message</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-combined-loss-delay-measure">Combined Loss/Delay Measurement Message</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-counters">Counters</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.5">
                <t indent="0" pn="section-toc.1-1.5.2.5.1"><xref derivedContent="5.5" format="counter" sectionFormat="of" target="section-5.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-block-number-for-counters">Block Number for Counters</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tlv-extensions">TLV Extensions</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-return-path-tlv-extension">Return Path TLV Extension</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.1.2">
                  <li pn="section-toc.1-1.6.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.1.2.1.1"><xref derivedContent="6.1.1" format="counter" sectionFormat="of" target="section-6.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-return-path-sub-tlv-extensi">Return Path Sub-TLV Extension</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-block-number-tlv-extension">Block Number TLV Extension</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ecmp-for-sr-mpls-policies">ECMP for SR-MPLS Policies</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-extended-te-link-metrics-ad">Extended TE Link Metrics Advertisement</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-backwards-compatibility">Backwards Compatibility</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-manageability-consideration">Manageability Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" format="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.13.2">
              <li pn="section-toc.1-1.13.2.1">
                <t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent="13.1" format="counter" sectionFormat="of" target="section-13.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.13.2.2">
                <t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent="13.2" format="counter" sectionFormat="of" target="section-13.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.16">
            <t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="sect-1" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Segment Routing (SR), as specified in <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>,
      leverages the source routing paradigm and applies to both the
      Multiprotocol Label Switching (MPLS) and 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" sectionFormat="of" derivedContent="RFC9256"/>, are used to steer traffic through specific,
      user-defined paths using a list of segments.</t>
      <t indent="0" pn="section-1-2">A comprehensive SR Performance Measurement toolset is one of the
      essential requirements for measuring network performance to provide
      Service Level Agreements (SLAs).</t>
      <t indent="0" pn="section-1-3"><xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> 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 indent="0" pn="section-1-4"><xref target="RFC7876" format="default" sectionFormat="of" derivedContent="RFC7876"/> 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" sectionFormat="of" derivedContent="RFC6374"/>. These mechanisms can be applied to SR-MPLS networks.</t>
      <t indent="0" pn="section-1-5"><xref target="RFC9341" format="default" sectionFormat="of" derivedContent="RFC9341"/> defines the
      Alternate-Marking Method using Block Numbers as a data correlation
      mechanism for packet loss measurement.</t>
      <t indent="0" pn="section-1-6">This document utilizes the mechanisms from <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>, <xref target="RFC7876" format="default" sectionFormat="of" derivedContent="RFC7876"/>, and <xref target="RFC9341" format="default" sectionFormat="of" derivedContent="RFC9341"/> 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 indent="0" pn="section-1-7">This document extends <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> by defining
      Return Path and Block Number TLVs (see <xref target="sect-6" format="default" sectionFormat="of" derivedContent="Section 6"/>) for delay and loss measurement in SR-MPLS
      networks. These TLVs can also be used in MPLS Label Switched Paths
      (LSPs) <xref target="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/>. However, the procedure
      for delay and loss measurement of MPLS LSPs is outside the scope of this
      document.</t>
    </section>
    <section anchor="sect-2" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-conventions-used-in-this-do">Conventions Used in This Document</name>
      <section anchor="sect-2.1" numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-requirements-language">Requirements Language</name>
        <t indent="0" pn="section-2.1-1">
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
      </section>
      <section anchor="sect-2.2" numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
        <name slugifiedName="name-abbreviations">Abbreviations</name>
        <dl spacing="normal" newline="false" indent="3" pn="section-2.2-1">
          <dt pn="section-2.2-1.1">ACH:</dt>
          <dd pn="section-2.2-1.2">Associated Channel Header</dd>
          <dt pn="section-2.2-1.3">DM:</dt>
          <dd pn="section-2.2-1.4">Delay Measurement</dd>
          <dt pn="section-2.2-1.5">ECMP:</dt>
          <dd pn="section-2.2-1.6">Equal-Cost Multipath</dd>
          <dt pn="section-2.2-1.7">G-ACh:</dt>
          <dd pn="section-2.2-1.8">Generic Associated Channel</dd>
          <dt pn="section-2.2-1.9">GAL:</dt>
          <dd pn="section-2.2-1.10">Generic Associated Channel Label</dd>
          <dt pn="section-2.2-1.11">LM:</dt>
          <dd pn="section-2.2-1.12">Loss Measurement</dd>
          <dt pn="section-2.2-1.13">LSE:</dt>
          <dd pn="section-2.2-1.14">Label Stack Entry</dd>
          <dt pn="section-2.2-1.15">MPLS:</dt>
          <dd pn="section-2.2-1.16">Multiprotocol Label Switching</dd>
          <dt pn="section-2.2-1.17">PSID:</dt>
          <dd pn="section-2.2-1.18">Path Segment Identifier</dd>
          <dt pn="section-2.2-1.19">SID:</dt>
          <dd pn="section-2.2-1.20">Segment Identifier</dd>
          <dt pn="section-2.2-1.21">SL:</dt>
          <dd pn="section-2.2-1.22">Segment List</dd>
          <dt pn="section-2.2-1.23">SR:</dt>
          <dd pn="section-2.2-1.24">Segment Routing</dd>
          <dt pn="section-2.2-1.25">SR-MPLS:</dt>
          <dd pn="section-2.2-1.26">Segment Routing over MPLS</dd>
          <dt pn="section-2.2-1.27">TC:</dt>
          <dd pn="section-2.2-1.28">Traffic Class</dd>
          <dt pn="section-2.2-1.29">TE:</dt>
          <dd pn="section-2.2-1.30">Traffic Engineering</dd>
          <dt pn="section-2.2-1.31">TTL:</dt>
          <dd pn="section-2.2-1.32">Time to Live</dd>
          <dt pn="section-2.2-1.33">URO:</dt>
          <dd pn="section-2.2-1.34">UDP Return Object</dd>
        </dl>
      </section>
      <section anchor="sect-2.3" numbered="true" toc="include" removeInRFC="false" pn="section-2.3">
        <name slugifiedName="name-reference-topology">Reference Topology</name>
        <t indent="0" pn="section-2.3-1">In the reference topology shown in <xref target="ure-reference-topology" format="default" sectionFormat="of" derivedContent="Figure 1"/>, 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 (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 indent="0" pn="section-2.3-2">T1 is a transmit timestamp, and T4 is a receive timestamp; both are
	added by node Q1. T2 is a receive timestamp, and T3 is a transmit
	timestamp; both are added by node R1.</t>
        <t indent="0" pn="section-2.3-3">SR is enabled with the MPLS data plane on nodes Q1 and R1.  The
	nodes Q1 and R1 are connected via a channel (<xref target="RFC6374" sectionFormat="of" section="2.9.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6374#section-2.9.1" derivedContent="RFC6374"/>).  The channel may be a directly
	connected link enabled with MPLS (<xref target="RFC6374" sectionFormat="of" section="2.9.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6374#section-2.9.1" derivedContent="RFC6374"/>) or an SR-MPLS path <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>.  The link may be a physical
	interface, a virtual link, a Link Aggregation Group (LAG) <xref target="IEEE802.1AX" format="default" sectionFormat="of" derivedContent="IEEE802.1AX"/>, or a LAG member link. The
	SR-MPLS path may be an SR-MPLS Policy <xref target="RFC9256" format="default" sectionFormat="of" derivedContent="RFC9256"/> on node Q1 (called the "head-end") with the destination
	to node R1 (called the "tail-end").</t>
        <figure anchor="ure-reference-topology" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-reference-topology-2">Reference Topology</name>
          <artwork name="" type="" align="left" alt="" pn="section-2.3-4.1">
          T1                T2
         /                   \
+-------+       Query         +-------+
|       | - - - - - - - - - -&gt;|       |
|   Q1  |=====================|   R1  |
|       |&lt;- - - - - - - - - - |       |
+-------+       Response      +-------+
         \                   /
          T4                T3
 Querier                       Responder
</artwork>
        </figure>
      </section>
    </section>
    <section anchor="sect-3" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-overview">Overview</name>
      <t indent="0" pn="section-3-1">
          In this document, the procedures defined in <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>, <xref target="RFC7876" format="default" sectionFormat="of" derivedContent="RFC7876"/>, and
          <xref target="RFC9341" format="default" sectionFormat="of" derivedContent="RFC9341"/> are utilized for delay and
          loss measurement in SR-MPLS networks. Specifically, the one-way,
          two-way, and round-trip delay measurements described in <xref target="RFC6374" sectionFormat="of" section="2.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6374#section-2.4" derivedContent="RFC6374"/> are further
          elaborated for application within SR-MPLS networks. Similarly, the
          packet loss measurement procedures outlined in <xref target="RFC6374" sectionFormat="of" section="2.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6374#section-2.2" derivedContent="RFC6374"/> are extended for
          use in SR-MPLS networks.</t>
      <t indent="0" pn="section-3-2">Packet loss measurement using the Alternate-Marking Method
	  defined in <xref target="RFC9341" format="default" sectionFormat="of" derivedContent="RFC9341"/> may employ the
	  Block Number for data correlation. This is achieved by utilizing the
	  Block Number TLV extension defined in this document.</t>
      <t indent="0" pn="section-3-3">In SR-MPLS networks, the query messages defined in <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> <bcp14>MUST</bcp14> be
	  transmitted along the same path as the data traffic for links and
	  end-to-end SR-MPLS 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 indent="0" pn="section-3-4">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 indent="0" pn="section-3-5">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" sectionFormat="of" derivedContent="RFC7471"/>, <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>, and <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/>.</t>
    </section>
    <section anchor="sect-4" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-query-and-response-messages">Query and Response Messages</name>
      <section anchor="sect-4.1" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-query-message-for-links-and">Query Message for Links and SR-MPLS Policies</name>
        <section anchor="sect-4.1.1" numbered="true" toc="include" removeInRFC="false" pn="section-4.1.1">
          <name slugifiedName="name-query-message-for-links">Query Message for Links</name>
          <t indent="0" pn="section-4.1.1-1">The query message, as defined in <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>, is sent over the links for both delay and loss
	  measurement. In each Label Stack Entry (LSE) <xref target="RFC3032" format="default" sectionFormat="of" derivedContent="RFC3032"/> in the MPLS label stack, the TTL value
	  <bcp14>MUST</bcp14> be set to 255 <xref target="RFC5082" format="default" sectionFormat="of" derivedContent="RFC5082"/>.</t>
        </section>
        <section anchor="sect-4.1.2" numbered="true" toc="include" removeInRFC="false" pn="section-4.1.2">
          <name slugifiedName="name-query-message-for-sr-mpls-p">Query Message for SR-MPLS Policies</name>
          <t indent="0" pn="section-4.1.2-1">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" sectionFormat="of" derivedContent="RFC9256"/>. For delay and/or loss measurement for an
	  end-to-end SR-MPLS Policy, the query messages <bcp14>MUST</bcp14> be
	  transmitted for every SL of the SR-MPLS Policy 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 <xref target="ure-header-for-an-end-to-end-sr-mpls-policy" format="default" sectionFormat="of" derivedContent="Figure 2"/>.  In each LSE
	  in the MPLS label stack, the TTL value <bcp14>MUST</bcp14> be set to
	  255 <xref target="RFC5082" format="default" sectionFormat="of" derivedContent="RFC5082"/>.</t>
          <figure anchor="ure-header-for-an-end-to-end-sr-mpls-policy" align="left" suppress-title="false" pn="figure-2">
            <name slugifiedName="name-example-query-message-heade">Example Query Message Header for an End-to-End SR-MPLS Policy</name>
            <artwork name="" type="" align="left" alt="" pn="section-4.1.2-2.1">
 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 indent="0" pn="section-4.1.2-3">The fields 0001, Version, Reserved, and Channel Type shown in
	  <xref target="ure-header-for-an-end-to-end-sr-mpls-policy" format="default" sectionFormat="of" derivedContent="Figure 2"/> are
	  specified in <xref target="RFC5586" format="default" sectionFormat="of" derivedContent="RFC5586"/>.</t>
          <t indent="0" pn="section-4.1.2-4">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 indent="0" pn="section-4.1.2-5">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" sectionFormat="of" derivedContent="RFC6374"/> containing an
	  address of the responder can be sent in the query messages. The
	  responder that supports this TLV <bcp14>MUST</bcp14> return Control Code 0x1 (Success) <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> if it is
	  the intended destination for the query. Otherwise, it
	  <bcp14>MUST</bcp14> return Error 0x15: Invalid Destination Node
	  Identifier <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>.</t>
        </section>
      </section>
      <section anchor="sect-4.2" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-response-message-for-links-">Response Message for Links and SR-MPLS Policies</name>
        <section anchor="sect-4.2.1" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.1">
          <name slugifiedName="name-one-way-measurement-mode">One-Way Measurement Mode</name>
          <t indent="0" pn="section-4.2.1-1">In one-way measurement mode, as defined in <xref target="RFC6374" sectionFormat="of" section="2.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6374#section-2.4" derivedContent="RFC6374"/>, the querier can set the UDP Return Object (URO) TLV in the query
message. This enables the querier to receive the out-of-band response
message encapsulated in an IP/UDP header sent to the IP address and
UDP port specified in the URO TLV. The
	  URO TLV (Type 131) is defined in <xref target="RFC7876" format="default" sectionFormat="of" derivedContent="RFC7876"/> and includes the UDP-Destination-Port and IP
	  address.  When the querier sets an IP address and a UDP port in the URO TLV, the response message <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 in the query message
	  <bcp14>MUST</bcp14> be set to Out-of-band Response Requested <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>.</t>
        </section>
        <section anchor="sect-4.2.2" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.2">
          <name slugifiedName="name-two-way-measurement-mode">Two-Way Measurement Mode</name>
          <t indent="0" pn="section-4.2.2-1">
   In the two-way measurement mode defined in <xref target="RFC6374" sectionFormat="of" section="2.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6374#section-2.4" derivedContent="RFC6374"/>, the
   response messages <bcp14>SHOULD</bcp14> be sent back one of two ways: either they are sent
   back in-band on the same link, or they are sent back on the same end-to-end
   SR-MPLS path (i.e., the same set of links and nodes) in the reverse
   direction to the querier. This is done in order to perform accurate two-way delay measurement.</t>
          <t indent="0" pn="section-4.2.2-2">For links, the response message as defined in <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> is sent back on the same
	  incoming link where the query message is received. In this case, the
	  Control Code in the query message <bcp14>MUST</bcp14> be set to
	  In-band Response Requested <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>.</t>
          <t indent="0" pn="section-4.2.2-3">For end-to-end SR-MPLS paths, the responder transmits the response
         message (see the example as shown in <xref target="ure-header-for-an-end-to-end-sr-mpls-policy" format="default" sectionFormat="of" derivedContent="Figure 2"/>) on a specific
         return SR-MPLS path.    In the query message, the querier can request that the responder send the response message back on a given return  path using the MPLS Label Stack Sub-TLV in the Return Path TLV defined in this document.
</t>
        </section>
        <section anchor="sect-4.2.3" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.3">
          <name slugifiedName="name-loopback-measurement-mode">Loopback Measurement Mode</name>
          <t indent="0" pn="section-4.2.3-1">The loopback measurement mode defined in <xref target="RFC6374" sectionFormat="of" section="2.8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6374#section-2.8" derivedContent="RFC6374"/> is used to measure round-trip
	  delay for a bidirectional circular path <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> 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" sectionFormat="of" derivedContent="RFC6374"/>.</t>
          <t indent="0" pn="section-4.2.3-2">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" sectionFormat="of" derivedContent="RFC6374"/>. In query messages, the
	  label stack, as shown in <xref target="ure-header-for-an-end-to-end-sr-mpls-policy-in-loopback" format="default" sectionFormat="of" derivedContent="Figure 3"/>,
	  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>
          <figure anchor="ure-header-for-an-end-to-end-sr-mpls-policy-in-loopback" align="left" suppress-title="false" pn="figure-3">
            <name slugifiedName="name-example-query-message-header">Example Query Message Header for an End-to-End SR-MPLS Policy in the Loopback Measurement Mode</name>
            <artwork name="" type="" align="left" alt="" pn="section-4.2.3-3.1">
 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="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-delay-and-loss-measurement">Delay and Loss Measurement</name>
      <section anchor="sect-5.1" numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-delay-measurement-message">Delay Measurement Message</name>
        <t indent="0" pn="section-5.1-1">As defined in <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>, MPLS Delay
    Measurement (DM) query and response messages use the Associated Channel
    Header (ACH) (with value 0x000C for delay measurement). The value identifies the message type and message
    payload that follow the ACH, as defined in <xref target="RFC6374" sectionFormat="of" section="3.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6374#section-3.2" derivedContent="RFC6374"/>. For delay measurement, the same ACH
    value is used for both links and end-to-end SR-MPLS Policies.</t>
      </section>
      <section anchor="sect-5.2" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-loss-measurement-message">Loss Measurement Message</name>
        <t indent="0" pn="section-5.2-1">The Loss Measurement (LM) protocol can perform two distinct kinds of
      loss measurement as described in <xref target="RFC6374" sectionFormat="of" section="2.9.8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6374#section-2.9.8" derivedContent="RFC6374"/>.</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.2-2">
          <li pn="section-5.2-2.1">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 pn="section-5.2-2.2">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 indent="0" pn="section-5.2-3">As defined in <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>, MPLS LM
      query and response messages use the ACH (with value 0x000A for direct loss
      measurement or value 0x000B for inferred loss measurement). This value identifies the message type and message payload that follow the ACH, as defined in <xref target="RFC6374" sectionFormat="of" section="3.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6374#section-3.1" derivedContent="RFC6374"/>. For loss measurement, the same ACH value is used for both links and
      end-to-end SR-MPLS Policies.</t>
      </section>
      <section anchor="sect-5.3" numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-combined-loss-delay-measure">Combined Loss/Delay Measurement Message</name>
        <t indent="0" pn="section-5.3-1">As defined in <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>, combined
	 LM/DM query and response messages use the ACH (with value 0x000D for
	direct loss and delay measurement or value 0x000E for inferred loss
	and delay measurement).  The value identifies the message type and the
	message payload that follows the ACH, as defined in <xref target="RFC6374" sectionFormat="of" section="3.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6374#section-3.3" derivedContent="RFC6374"/>. For combined loss and delay
	measurement, the same ACH value is used for both links and end-to-end
	SR-MPLS Policies.</t>
      </section>
      <section anchor="sect-5.4" numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-counters">Counters</name>
        <t indent="0" pn="section-5.4-1">The Path Segment Identifier (PSID) <xref target="RFC9545" format="default" sectionFormat="of" derivedContent="RFC9545"/> <bcp14>MUST</bcp14> be carried in the received data
	packet for the traffic flow under measurement, in order to account for received
	traffic on the egress node of the SR-MPLS Policy. In the direct mode, the
	PSID in the received query message (as shown in <xref target="ure-with-path-segment-identifier-for-sr-mpls-policy" format="default" sectionFormat="of" derivedContent="Figure 4"/>) 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 indent="0" pn="section-5.4-2">In the inferred mode, the PSID in the received query messages (as shown
	in <xref target="ure-with-path-segment-identifier-for-sr-mpls-policy" format="default" sectionFormat="of" derivedContent="Figure 4"/>) 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>
        <figure anchor="ure-with-path-segment-identifier-for-sr-mpls-policy" align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-example-with-the-psid-for-s">Example with the PSID for SR-MPLS Policy</name>
          <artwork name="" type="" align="left" alt="" pn="section-5.4-3.1">
 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 indent="0" pn="section-5.4-4">The fields 0001, Version, Reserved, and Channel Type shown in <xref target="ure-with-path-segment-identifier-for-sr-mpls-policy" format="default" sectionFormat="of" derivedContent="Figure 4"/> are
    specified in <xref target="RFC5586" format="default" sectionFormat="of" derivedContent="RFC5586"/>.</t>
        <t indent="0" pn="section-5.4-5">Different values of the PSID can be used per Candidate-Path to account for
    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 SL level. The same value of the PSID can be used for all
    SLs of the SR-MPLS Policy to measure packet loss at the SR-MPLS
    Policy level.</t>
      </section>
      <section anchor="sect-5.5" numbered="true" toc="include" removeInRFC="false" pn="section-5.5">
        <name slugifiedName="name-block-number-for-counters">Block Number for Counters</name>
        <t indent="0" pn="section-5.5-1">The packet loss measurement using the Alternate-Marking Method defined
    in <xref target="RFC9341" format="default" sectionFormat="of" derivedContent="RFC9341"/> may use the block number for
    data correlation for the traffic flow under measurement. As defined in
    <xref target="RFC9341" sectionFormat="of" section="3.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9341#section-3.1" derivedContent="RFC9341"/>, 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 indent="0" pn="section-5.5-2">As described in <xref target="RFC9341" sectionFormat="of" section="4.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9341#section-4.3" derivedContent="RFC9341"/>, 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" sectionFormat="of" derivedContent="RFC6374"/>.</t>
        <t indent="0" pn="section-5.5-3">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 indent="0" pn="section-5.5-4">As an example, the querier can use the procedure defined in <xref target="RFC9714" format="default" sectionFormat="of" derivedContent="RFC9714"/> 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, 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 indent="0" pn="section-5.5-5">The LM query and response messages defined in <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> are used to measure packet loss for the block of data
    packets transmitted with the previous 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 indent="0" pn="section-5.5-6"><xref target="RFC9341" sectionFormat="of" section="4.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9341#section-4.3" derivedContent="RFC9341"/> specifies that:
"The assumption of this BN mechanism is that the measurement nodes are time
synchronized." However, this is not necessary, as the block number on the
responder can be synchronized based on the received LM query messages.</t>
      </section>
    </section>
    <section anchor="sect-6" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-tlv-extensions">TLV Extensions</name>
      <section anchor="sect-6.1" numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-return-path-tlv-extension">Return Path TLV Extension</name>
        <t indent="0" pn="section-6.1-1">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 indent="0" pn="section-6.1-2">The querier may not be directly reachable from the responder in a
	network. In this case, the querier <bcp14>MUST</bcp14> send its
	reachability path information to the responder using the Return Path
	TLV.</t>
        <t indent="0" pn="section-6.1-3"><xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> defines query and
	response messages that can include one or more optional TLVs. This document defines 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 <xref target="ure-return-path-tlv" format="default" sectionFormat="of" derivedContent="Figure 5"/> below:</t>
        <figure anchor="ure-return-path-tlv" align="left" suppress-title="false" pn="figure-5">
          <name slugifiedName="name-return-path-tlv">Return Path TLV</name>
          <artwork name="" type="" align="left" alt="" pn="section-6.1-4.1">
 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 = 5     |    Length     |      Reserved                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Return Path Sub-TLV                        |
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
        </figure>
        <t indent="0" pn="section-6.1-5">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
	  <bcp14>MUST NOT</bcp14> be 0 or 1.</t>
        <t indent="0" pn="section-6.1-6">The Return Path TLV is defined in the "Mandatory TLV Type"
	  registry space <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>. The
	  querier <bcp14>MUST</bcp14> only insert one Return Path TLV in the
	  query message. The responder that supports this TLV
	  <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 <bcp14>MUST</bcp14> send the response message
	  back on the return path specified in the Return Path TLV. The
	  responder also <bcp14>MUST NOT</bcp14> add a Return Path TLV in the
	  response message.</t>
        <t indent="0" pn="section-6.1-7">The Reserved field <bcp14>MUST</bcp14> be set to 0 and
	  <bcp14>MUST</bcp14> be ignored on the receive side.</t>
        <section anchor="sect-6.1.1" numbered="true" toc="include" removeInRFC="false" pn="section-6.1.1">
          <name slugifiedName="name-return-path-sub-tlv-extensi">Return Path Sub-TLV Extension</name>
          <t indent="0" pn="section-6.1.1-1">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 <xref target="ure-segment-list-sub-tlv-in-return-path-tlv" format="default" sectionFormat="of" derivedContent="Figure 6"/>. The label
      entries in the Sub-TLV <bcp14>MUST</bcp14> be in network order. The MPLS
      Label Stack Sub-TLV in the Return Path TLV is of the following type:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1.1-2">
            <li pn="section-6.1.1-2.1">Type (value 1): MPLS Label Stack of the Return Path</li>
          </ul>
          <figure anchor="ure-segment-list-sub-tlv-in-return-path-tlv" align="left" suppress-title="false" pn="figure-6">
            <name slugifiedName="name-mpls-label-stack-sub-tlv-in">MPLS Label Stack Sub-TLV in the Return Path TLV</name>
            <artwork name="" type="" align="left" alt="" pn="section-6.1.1-3.1">
 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 indent="0" pn="section-6.1.1-4">The MPLS label stack contains a list of 32-bit LSEs that includes
	  a 20-bit label value, an 8-bit TTL value, a 3-bit TC value, and a 1-bit 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" sectionFormat="of" derivedContent="RFC8402"/> of
	  the Return SR-MPLS Policy.</t>
          <t indent="0" pn="section-6.1.1-5">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
	  <bcp14>MUST NOT</bcp14> be 0 or 1.</t>
          <t indent="0" pn="section-6.1.1-6">The Return Path TLV <bcp14>MUST</bcp14> carry only one Return
	  Path Sub-TLV. The MPLS Label Stack in the Return Path Sub-TLV
	  <bcp14>MUST</bcp14> contain at least one MPLS Label. The responder
	  that supports this Sub-TLV <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
	  <bcp14>MUST</bcp14> send the response message back on the return
	  path specified in the Return Path Sub-TLV.</t>
          <t indent="0" pn="section-6.1.1-7">The Reserved field <bcp14>MUST</bcp14> be set to 0 and
	  <bcp14>MUST</bcp14> be ignored on the receive side.</t>
        </section>
      </section>
      <section anchor="sect-6.2" numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-block-number-tlv-extension">Block Number TLV Extension</name>
        <t indent="0" pn="section-6.2-1"><xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> defines query and
	response messages that can include one or more optional TLVs. This document 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 <xref target="ure-block-number-tlv" format="default" sectionFormat="of" derivedContent="Figure 7"/>:</t>
        <figure anchor="ure-block-number-tlv" align="left" suppress-title="false" pn="figure-7">
          <name slugifiedName="name-block-number-tlv">Block Number TLV</name>
          <artwork name="" type="" align="left" alt="" pn="section-6.2-2.1">
 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=6     |    Length     | Reserved    |R| Block Number  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
        </figure>
        <t indent="0" pn="section-6.2-3">The Length is a one-byte field and is equal to 2 bytes.</t>
        <t indent="0" pn="section-6.2-4">The Block Number TLV is defined in the "Mandatory TLV Type" registry
	space <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>.  The querier
	<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
	<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 <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 <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 indent="0" pn="section-6.2-5">The Reserved field <bcp14>MUST</bcp14> be set to 0 and
	<bcp14>MUST</bcp14> be ignored on the receive side.</t>
      </section>
    </section>
    <section anchor="sect-7" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-ecmp-for-sr-mpls-policies">ECMP for SR-MPLS Policies</name>
      <t indent="0" pn="section-7-1">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 a node-SID <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/> by the SLs of an SR-MPLS Policy can result in ECMP
      paths. In addition, usage of an Anycast-SID <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/> by the SLs of an SR-MPLS Policy can result in ECMP
      paths via transit nodes that are part of that 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 indent="0" pn="section-7-2">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" sectionFormat="of" derivedContent="RFC6790"/> 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 indent="0" pn="section-7-3">The considerations for loss measurement for different ECMP paths of
      an SR-MPLS Policy are outside the scope of this document.</t>
    </section>
    <section anchor="sect-8" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-extended-te-link-metrics-ad">Extended TE Link Metrics Advertisement</name>
      <t indent="0" pn="section-8-1">The extended TE metrics for link delay (namely, average delay,
      minimum delay, maximum 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>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-2">
        <li pn="section-8-2.1">For OSPF, IS-IS, and the Border Gateway Protocol - Link State
	(BGP-LS), the protocol extensions defined in <xref target="RFC7471" format="default" sectionFormat="of" derivedContent="RFC7471"/>, <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>, and
	<xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/>, respectively, are used for
	advertising the extended TE link delay and loss metrics in the
	network.</li>
        <li pn="section-8-2.2">The extended TE link delay and loss metrics are advertised for
	Layer-2 LAG bundle member links in OSPF <xref target="RFC9356" format="default" sectionFormat="of" derivedContent="RFC9356"/> and IS-IS <xref target="RFC8668" format="default" sectionFormat="of" derivedContent="RFC8668"/>
	using the same protocol extensions defined in <xref target="RFC7471" format="default" sectionFormat="of" derivedContent="RFC7471"/> and <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>,
	respectively.</li>
        <li pn="section-8-2.3">The advertised delay-variance metric is computed as Packet Delay
	Variation (PDV), as described in <xref target="RFC5481" sectionFormat="of" section="4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5481#section-4.2" derivedContent="RFC5481"/>.</li>
      </ul>
    </section>
    <section anchor="sect-9" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-backwards-compatibility">Backwards Compatibility</name>
      <t indent="0" pn="section-9-1">The procedures defined in this document are backwards compatible with
      the procedures  defined in <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> at
      both the querier and the responder.  If the responder does not support the
      new Mandatory TLV Types defined in this document, it will return Error
      0x17: Unsupported Mandatory TLV Object as per <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>.</t>
    </section>
    <section anchor="sect-10" numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-manageability-consideration">Manageability Considerations</name>
      <t indent="0" pn="section-10-1">The manageability considerations described in <xref target="RFC6374" sectionFormat="of" section="7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6374#section-7" derivedContent="RFC6374"/> and <xref target="RFC7876" sectionFormat="of" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7876#section-6" derivedContent="RFC7876"/> are applicable to this
      specification.</t>
    </section>
    <section anchor="sect-11" numbered="true" toc="include" removeInRFC="false" pn="section-11">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-11-1">The security considerations specified in <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/>, <xref target="RFC7471" format="default" sectionFormat="of" derivedContent="RFC7471"/>, <xref target="RFC8570" format="default" sectionFormat="of" derivedContent="RFC8570"/>, <xref target="RFC8571" format="default" sectionFormat="of" derivedContent="RFC8571"/>, <xref target="RFC7876" format="default" sectionFormat="of" derivedContent="RFC7876"/>, and <xref target="RFC9341" format="default" sectionFormat="of" derivedContent="RFC9341"/> also apply to the procedures
      described in this document.</t>
      <t indent="0" pn="section-11-2">The procedure defined in this document is intended for deployment in
      a single operator administrative domain. As such, the querier node, the
      responder node, 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 indent="0" pn="section-11-3">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. The responder can use this to make that
      determination, for example, by checking the access control list
      provisioned by the operator.</t>
    </section>
    <section anchor="sect-12" numbered="true" toc="include" removeInRFC="false" pn="section-12">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-12-1">IANA has allocated values for the following Mandatory TLV
      Types <xref target="RFC6374" format="default" sectionFormat="of" derivedContent="RFC6374"/> from the "MPLS
      Loss/Delay Measurement TLV Object" registry contained within the
      "Generic Associated Channel (G-ACh) Parameters" registry group:</t>
      <table anchor="iana-tlv-type-tbl" align="center" pn="table-1">
        <name slugifiedName="name-mpls-loss-delay-measurement">MPLS Loss/Delay Measurement TLV Types</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Code</th>
            <th align="left" colspan="1" rowspan="1">Description</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">5</td>
            <td align="left" colspan="1" rowspan="1">Return Path</td>
            <td align="left" colspan="1" rowspan="1">RFC 9779</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">6</td>
            <td align="left" colspan="1" rowspan="1">Block Number</td>
            <td align="left" colspan="1" rowspan="1">RFC 9779</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-12-3">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 indent="0" pn="section-12-4">IANA has created the "Return Path Sub-TLV Types" registry.
All code points are allocated per the registration policies shown in <xref target="iana-return-path-tbl" format="default" sectionFormat="of" derivedContent="Table 2"/> (see <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>).
</t>
      <table anchor="iana-return-path-tbl" align="center" pn="table-2">
        <name slugifiedName="name-return-path-sub-tlv-types-r">Return Path Sub-TLV Types Registry</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Value</th>
            <th align="left" colspan="1" rowspan="1">Description</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">1 - 175</td>
            <td align="left" colspan="1" rowspan="1">IETF Review</td>
            <td align="left" colspan="1" rowspan="1">RFC 9779</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">176 - 239</td>
            <td align="left" colspan="1" rowspan="1">First Come First Served</td>
            <td align="left" colspan="1" rowspan="1">RFC 9779</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">240 - 251</td>
            <td align="left" colspan="1" rowspan="1">Experimental Use</td>
            <td align="left" colspan="1" rowspan="1">RFC 9779</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">252 - 254</td>
            <td align="left" colspan="1" rowspan="1">Private Use</td>
            <td align="left" colspan="1" rowspan="1">RFC 9779</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-12-6">This document defines the following values in the "Return Path Sub-TLV
      Types" registry:</t>
      <table anchor="iana-return-path-type-tbl" align="center" pn="table-3">
        <name slugifiedName="name-return-path-sub-tlv-types">Return Path Sub-TLV Types</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Value</th>
            <th align="left" colspan="1" rowspan="1">Description</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">0</td>
            <td align="left" colspan="1" rowspan="1">Reserved</td>
            <td align="left" colspan="1" rowspan="1">RFC 9779</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">1</td>
            <td align="left" colspan="1" rowspan="1">MPLS Label Stack of the Return Path</td>
            <td align="left" colspan="1" rowspan="1">RFC 9779</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">255</td>
            <td align="left" colspan="1" rowspan="1">Reserved</td>
            <td align="left" colspan="1" rowspan="1">RFC 9779</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <references pn="section-13">
      <name slugifiedName="name-references">References</name>
      <references pn="section-13.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC6374" target="https://www.rfc-editor.org/info/rfc6374" quoteTitle="true" derivedAnchor="RFC6374">
          <front>
            <title>Packet Loss and Delay Measurement for MPLS Networks</title>
            <author fullname="D. Frost" initials="D." surname="Frost"/>
            <author fullname="S. Bryant" initials="S." surname="Bryant"/>
            <date month="September" year="2011"/>
            <abstract>
              <t indent="0">Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6374"/>
          <seriesInfo name="DOI" value="10.17487/RFC6374"/>
        </reference>
        <reference anchor="RFC7876" target="https://www.rfc-editor.org/info/rfc7876" quoteTitle="true" derivedAnchor="RFC7876">
          <front>
            <title>UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks</title>
            <author fullname="S. Bryant" initials="S." surname="Bryant"/>
            <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/>
            <author fullname="S. Soni" initials="S." surname="Soni"/>
            <date month="July" year="2016"/>
            <abstract>
              <t indent="0">RFC 6374 defines a protocol for Packet Loss and Delay Measurement for MPLS networks (MPLS-PLDM). This document specifies the procedures to be used when sending and processing out-of-band MPLS performance management Responses over an UDP/IP return path.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7876"/>
          <seriesInfo name="DOI" value="10.17487/RFC7876"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC9341" target="https://www.rfc-editor.org/info/rfc9341" quoteTitle="true" derivedAnchor="RFC9341">
          <front>
            <title>Alternate-Marking Method</title>
            <author fullname="G. Fioccola" initials="G." role="editor" surname="Fioccola"/>
            <author fullname="M. Cociglio" initials="M." surname="Cociglio"/>
            <author fullname="G. Mirsky" initials="G." surname="Mirsky"/>
            <author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
            <author fullname="T. Zhou" initials="T." surname="Zhou"/>
            <date month="December" year="2022"/>
            <abstract>
              <t indent="0">This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic. This technology can be applied in various situations and for different protocols. According to the classification defined in RFC 7799, it could be considered Passive or Hybrid depending on the application. This document obsoletes RFC 8321.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9341"/>
          <seriesInfo name="DOI" value="10.17487/RFC9341"/>
        </reference>
      </references>
      <references pn="section-13.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC3031" target="https://www.rfc-editor.org/info/rfc3031" quoteTitle="true" derivedAnchor="RFC3031">
          <front>
            <title>Multiprotocol Label Switching Architecture</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="A. Viswanathan" initials="A." surname="Viswanathan"/>
            <author fullname="R. Callon" initials="R." surname="Callon"/>
            <date month="January" year="2001"/>
            <abstract>
              <t indent="0">This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3031"/>
          <seriesInfo name="DOI" value="10.17487/RFC3031"/>
        </reference>
        <reference anchor="RFC3032" target="https://www.rfc-editor.org/info/rfc3032" quoteTitle="true" derivedAnchor="RFC3032">
          <front>
            <title>MPLS Label Stack Encoding</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="D. Tappan" initials="D." surname="Tappan"/>
            <author fullname="G. Fedorkow" initials="G." surname="Fedorkow"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <author fullname="A. Conta" initials="A." surname="Conta"/>
            <date month="January" year="2001"/>
            <abstract>
              <t indent="0">This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3032"/>
          <seriesInfo name="DOI" value="10.17487/RFC3032"/>
        </reference>
        <reference anchor="RFC5082" target="https://www.rfc-editor.org/info/rfc5082" quoteTitle="true" derivedAnchor="RFC5082">
          <front>
            <title>The Generalized TTL Security Mechanism (GTSM)</title>
            <author fullname="V. Gill" initials="V." surname="Gill"/>
            <author fullname="J. Heasley" initials="J." surname="Heasley"/>
            <author fullname="D. Meyer" initials="D." surname="Meyer"/>
            <author fullname="P. Savola" initials="P." role="editor" surname="Savola"/>
            <author fullname="C. Pignataro" initials="C." surname="Pignataro"/>
            <date month="October" year="2007"/>
            <abstract>
              <t indent="0">The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC 3682. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5082"/>
          <seriesInfo name="DOI" value="10.17487/RFC5082"/>
        </reference>
        <reference anchor="RFC5481" target="https://www.rfc-editor.org/info/rfc5481" quoteTitle="true" derivedAnchor="RFC5481">
          <front>
            <title>Packet Delay Variation Applicability Statement</title>
            <author fullname="A. Morton" initials="A." surname="Morton"/>
            <author fullname="B. Claise" initials="B." surname="Claise"/>
            <date month="March" year="2009"/>
            <abstract>
              <t indent="0">Packet delay variation metrics appear in many different standards documents. The metric definition in RFC 3393 has considerable flexibility, and it allows multiple formulations of delay variation through the specification of different packet selection functions.</t>
              <t indent="0">Although flexibility provides wide coverage and room for new ideas, it can make comparisons of independent implementations more difficult. Two different formulations of delay variation have come into wide use in the context of active measurements. This memo examines a range of circumstances for active measurements of delay variation and their uses, and recommends which of the two forms is best matched to particular conditions and tasks. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5481"/>
          <seriesInfo name="DOI" value="10.17487/RFC5481"/>
        </reference>
        <reference anchor="RFC5586" target="https://www.rfc-editor.org/info/rfc5586" quoteTitle="true" derivedAnchor="RFC5586">
          <front>
            <title>MPLS Generic Associated Channel</title>
            <author fullname="M. Bocci" initials="M." role="editor" surname="Bocci"/>
            <author fullname="M. Vigoureux" initials="M." role="editor" surname="Vigoureux"/>
            <author fullname="S. Bryant" initials="S." role="editor" surname="Bryant"/>
            <date month="June" year="2009"/>
            <abstract>
              <t indent="0">This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5586"/>
          <seriesInfo name="DOI" value="10.17487/RFC5586"/>
        </reference>
        <reference anchor="RFC6790" target="https://www.rfc-editor.org/info/rfc6790" quoteTitle="true" derivedAnchor="RFC6790">
          <front>
            <title>The Use of Entropy Labels in MPLS Forwarding</title>
            <author fullname="K. Kompella" initials="K." surname="Kompella"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="S. Amante" initials="S." surname="Amante"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <author fullname="L. Yong" initials="L." surname="Yong"/>
            <date month="November" year="2012"/>
            <abstract>
              <t indent="0">Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6790"/>
          <seriesInfo name="DOI" value="10.17487/RFC6790"/>
        </reference>
        <reference anchor="RFC7471" target="https://www.rfc-editor.org/info/rfc7471" quoteTitle="true" derivedAnchor="RFC7471">
          <front>
            <title>OSPF Traffic Engineering (TE) Metric Extensions</title>
            <author fullname="S. Giacalone" initials="S." surname="Giacalone"/>
            <author fullname="D. Ward" initials="D." surname="Ward"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="A. Atlas" initials="A." surname="Atlas"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <date month="March" year="2015"/>
            <abstract>
              <t indent="0">In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection.</t>
              <t indent="0">This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance.</t>
              <t indent="0">Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7471"/>
          <seriesInfo name="DOI" value="10.17487/RFC7471"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8402" quoteTitle="true" derivedAnchor="RFC8402">
          <front>
            <title>Segment Routing Architecture</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
            <author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
            <author fullname="R. Shakir" initials="R." surname="Shakir"/>
            <date month="July" year="2018"/>
            <abstract>
              <t indent="0">Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.</t>
              <t indent="0">SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.</t>
              <t indent="0">SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8402"/>
          <seriesInfo name="DOI" value="10.17487/RFC8402"/>
        </reference>
        <reference anchor="RFC8570" target="https://www.rfc-editor.org/info/rfc8570" quoteTitle="true" derivedAnchor="RFC8570">
          <front>
            <title>IS-IS Traffic Engineering (TE) Metric Extensions</title>
            <author fullname="L. Ginsberg" initials="L." role="editor" surname="Ginsberg"/>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
            <author fullname="S. Giacalone" initials="S." surname="Giacalone"/>
            <author fullname="D. Ward" initials="D." surname="Ward"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <date month="March" year="2019"/>
            <abstract>
              <t indent="0">In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.</t>
              <t indent="0">This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.</t>
              <t indent="0">Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.</t>
              <t indent="0">This document obsoletes RFC 7810.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8570"/>
          <seriesInfo name="DOI" value="10.17487/RFC8570"/>
        </reference>
        <reference anchor="RFC8571" target="https://www.rfc-editor.org/info/rfc8571" quoteTitle="true" derivedAnchor="RFC8571">
          <front>
            <title>BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions</title>
            <author fullname="L. Ginsberg" initials="L." role="editor" surname="Ginsberg"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <date month="March" year="2019"/>
            <abstract>
              <t indent="0">This document defines new BGP - Link State (BGP-LS) TLVs in order to carry the IGP Traffic Engineering Metric Extensions defined in the IS-IS and OSPF protocols.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8571"/>
          <seriesInfo name="DOI" value="10.17487/RFC8571"/>
        </reference>
        <reference anchor="RFC8668" target="https://www.rfc-editor.org/info/rfc8668" quoteTitle="true" derivedAnchor="RFC8668">
          <front>
            <title>Advertising Layer 2 Bundle Member Link Attributes in IS-IS</title>
            <author fullname="L. Ginsberg" initials="L." role="editor" surname="Ginsberg"/>
            <author fullname="A. Bashandy" initials="A." surname="Bashandy"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="M. Nanduri" initials="M." surname="Nanduri"/>
            <author fullname="E. Aries" initials="E." surname="Aries"/>
            <date month="December" year="2019"/>
            <abstract>
              <t indent="0">There are deployments where the Layer 3 interface on which IS-IS operates is a Layer 2 interface bundle. Existing IS-IS advertisements only support advertising link attributes of the Layer 3 interface. If entities external to IS-IS wish to control traffic flows on the individual physical links that comprise the Layer 2 interface bundle, link attribute information about the bundle members is required.</t>
              <t indent="0">This document introduces the ability for IS-IS to advertise the link attributes of Layer 2 (L2) Bundle Members.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8668"/>
          <seriesInfo name="DOI" value="10.17487/RFC8668"/>
        </reference>
        <reference anchor="RFC9256" target="https://www.rfc-editor.org/info/rfc9256" quoteTitle="true" derivedAnchor="RFC9256">
          <front>
            <title>Segment Routing Policy Architecture</title>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <author fullname="A. Bogdanov" initials="A." surname="Bogdanov"/>
            <author fullname="P. Mattes" initials="P." surname="Mattes"/>
            <date month="July" year="2022"/>
            <abstract>
              <t indent="0">Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.</t>
              <t indent="0">This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9256"/>
          <seriesInfo name="DOI" value="10.17487/RFC9256"/>
        </reference>
        <reference anchor="RFC9356" target="https://www.rfc-editor.org/info/rfc9356" quoteTitle="true" derivedAnchor="RFC9356">
          <front>
            <title>Advertising Layer 2 Bundle Member Link Attributes in OSPF</title>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="P. Psenak" initials="P." surname="Psenak"/>
            <date month="January" year="2023"/>
            <abstract>
              <t indent="0">There are deployments where the Layer 3 (L3) interface on which OSPF operates is a Layer 2 (L2) interface bundle. Existing OSPF advertisements only support advertising link attributes of the L3 interface. If entities external to OSPF wish to control traffic flows on the individual physical links that comprise the L2 interface bundle, link attribute information for the bundle members is required.</t>
              <t indent="0">This document defines the protocol extensions for OSPF to advertise the link attributes of L2 bundle members. The document also specifies the advertisement of these OSPF extensions via the Border Gateway Protocol - Link State (BGP-LS) and thereby updates RFC 9085.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9356"/>
          <seriesInfo name="DOI" value="10.17487/RFC9356"/>
        </reference>
        <reference anchor="RFC9545" target="https://www.rfc-editor.org/info/rfc9545" quoteTitle="true" derivedAnchor="RFC9545">
          <front>
            <title>Path Segment Identifier in MPLS-Based Segment Routing Networks</title>
            <author fullname="W. Cheng" initials="W." role="editor" surname="Cheng"/>
            <author fullname="H. Li" initials="H." surname="Li"/>
            <author fullname="C. Li" initials="C." role="editor" surname="Li"/>
            <author fullname="R. Gandhi" initials="R." surname="Gandhi"/>
            <author fullname="R. Zigler" initials="R." surname="Zigler"/>
            <date month="February" year="2024"/>
            <abstract>
              <t indent="0">A Segment Routing (SR) path is identified by an SR segment list. A subset of segments from the segment list cannot be leveraged to distinguish one SR path from another as they may be partially congruent. SR path identification is a prerequisite for various use cases such as performance measurement and end-to-end 1+1 path protection.</t>
              <t indent="0">In an SR over MPLS (SR-MPLS) data plane, an egress node cannot determine on which SR path a packet traversed the network from the label stack because the segment identifiers are removed from the label stack as the packet transits the network.</t>
              <t indent="0">This document defines a Path Segment Identifier (PSID) to identify an SR path on the egress node of the path.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9545"/>
          <seriesInfo name="DOI" value="10.17487/RFC9545"/>
        </reference>
        <reference anchor="RFC9714" target="https://www.rfc-editor.org/info/rfc9714" quoteTitle="true" derivedAnchor="RFC9714">
          <front>
            <title>Encapsulation for MPLS Performance Measurement with the Alternate-Marking Method</title>
            <author fullname="W. Cheng" initials="W." role="editor" surname="Cheng"/>
            <author fullname="X. Min" initials="X." role="editor" surname="Min"/>
            <author fullname="T. Zhou" initials="T." surname="Zhou"/>
            <author fullname="J. Dai" initials="J." surname="Dai"/>
            <author fullname="Y. Peleg" initials="Y." surname="Peleg"/>
            <date month="February" year="2025"/>
            <abstract>
              <t indent="0">This document defines the encapsulation for MPLS performance
measurement with the Alternate-Marking Method, which performs
flow-based packet loss, delay, and jitter measurements on MPLS
traffic.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9714"/>
          <seriesInfo name="DOI" value="10.17487/RFC9714"/>
        </reference>
        <reference anchor="IEEE802.1AX" quoteTitle="true" target="https://doi.org/10.1109/IEEESTD.2020.9105034" derivedAnchor="IEEE802.1AX">
          <front>
            <title>IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation</title>
            <author>
              <organization showOnFrontPage="true">IEEE</organization>
            </author>
            <date 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="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank <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 <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 <contact fullname="Greg Mirsky"/> and <contact fullname="Xiao Min"/> for providing many useful comments and
      suggestions. The authors would also like to thank <contact fullname="Stewart Bryant"/>, <contact fullname="Sam Aldrin"/>, <contact fullname="Tarek Saad"/>, and <contact fullname="Rajiv Asati"/> for their
      review comments. Thanks to <contact fullname="Huaimo Chen"/>,
      <contact fullname="Yimin Shen"/>, and <contact fullname="Xufeng Liu"/>
      for the MPLS expert review; <contact fullname="Zhaohui Zhang"/> for
      the RTGDIR early review; <contact fullname="Tony Li"/> for shepherd's
      review; <contact fullname="Ned Smith"/> for the SECDIR review; <contact fullname="Roni Even"/> for the Gen-ART review; <contact fullname="Marcus       Ihlar"/> for the TSV-ART review; <contact fullname="Dhruv Dhody"/> for
      the OPSDIR review; and <contact fullname="Gunter Van de 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>
    </section>
    <section numbered="false" anchor="contributors" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors</name>
      <contact fullname="Sagar Soni">
        <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
        <address>
          <email>sagsoni@cisco.com</email>
        </address>
      </contact>
      <contact fullname="Zafar Ali">
        <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
        <address>
          <email>zali@cisco.com</email>
        </address>
      </contact>
      <contact fullname="Pier Luigi Ventre">
        <organization showOnFrontPage="true">CNIT</organization>
        <address>
          <postal>
            <country>Italy</country>
          </postal>
          <email>pierluigi.ventre@cnit.it</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Rakesh Gandhi" initials="R." role="editor" surname="Gandhi">
        <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
        <address>
          <postal>
            <country>Canada</country>
          </postal>
          <email>rgandhi@cisco.com</email>
        </address>
      </author>
      <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
        <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
        <address>
          <email>cfilsfil@cisco.com</email>
        </address>
      </author>
      <author fullname="Daniel Voyer" initials="D." surname="Voyer">
        <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
        <address>
          <postal>
            <country>Canada</country>
          </postal>
          <email>davoyer@cisco.com</email>
        </address>
      </author>
      <author fullname="Stefano Salsano" initials="S." surname="Salsano">
        <organization showOnFrontPage="true">Universita di Roma "Tor Vergata"</organization>
        <address>
          <postal>
            <country>Italy</country>
          </postal>
          <email>stefano.salsano@uniroma2.it</email>
        </address>
      </author>
      <author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
        <organization showOnFrontPage="true">Huawei</organization>
        <address>
          <email>mach.chen@huawei.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
