rfc9779.original.xml   rfc9779.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
<!ENTITY I-D.ietf-mpls-inband-pm-encapsulation SYSTEM
"https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-i
nband-pm-encapsulation.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.2119.xml">
<!ENTITY RFC3031 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.3031.xml">
<!ENTITY RFC3032 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.3032.xml">
<!ENTITY RFC6374 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.6374.xml">
<!ENTITY RFC7876 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.7876.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8174.xml">
<!ENTITY RFC9341 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.9341.xml">
<!ENTITY RFC5481 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.5481.xml">
<!ENTITY RFC5586 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.5586.xml">
<!ENTITY RFC6790 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.6790.xml">
<!ENTITY RFC7471 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.7471.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8126.xml">
<!ENTITY RFC8402 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8402.xml">
<!ENTITY RFC8570 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8570.xml">
<!ENTITY RFC8571 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8571.xml">
<!ENTITY RFC8668 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8668.xml">
<!ENTITY RFC9256 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.9256.xml">
<!ENTITY RFC9356 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.9356.xml">
<!ENTITY RFC9545 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.9545.xml">
<!ENTITY RFC5082 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.5082.xml">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="d
raft-ietf-mpls-rfc6374-sr-17" category="std" ipr="trust200902" obsoletes="" upda <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="d
tes="" xml:lang="en" sortRefs="false" consensus="yes" symRefs="true" tocInclude= raft-ietf-mpls-rfc6374-sr-17" number="9779" category="std" ipr="trust200902" obs
"true" version="3"> oletes="" updates="" xml:lang="en" sortRefs="false" consensus="yes" symRefs="tru
<!-- xml2rfc v2v3 conversion 3.12.3 --> e" tocInclude="true" version="3">
<!-- Generated by id2xml 1.5.0 on 2020-03-06T17:47:05Z -->
<!-- [rfced] May we update the document title as shown below for clarity?
Original:
Performance Measurement for Segment Routing Networks with MPLS Data
Plane
Perhaps:
Performance Measurement for Segment Routing Networks over the MPLS Data Plane
-->
<front> <front>
<title abbrev="Performance Measurement for SR-MPLS">Performance Measurement <title abbrev="Performance Measurement for SR-MPLS">Performance Measurement
for Segment Routing Networks with MPLS Data Plane</title> for Segment Routing Networks with the MPLS Data Plane</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-mpls-rfc6374-sr-17"/> <seriesInfo name="RFC" value="9779"/>
<author fullname="Rakesh Gandhi" initials="R." role="editor" surname="Gandhi "> <author fullname="Rakesh Gandhi" initials="R." role="editor" surname="Gandhi ">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Canada</street> <country>Canada</country>
</postal> </postal>
<email>rgandhi@cisco.com</email> <email>rgandhi@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils"> <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<email>cfilsfil@cisco.com</email> <email>cfilsfil@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Daniel Voyer" initials="D." surname="Voyer"> <author fullname="Daniel Voyer" initials="D." surname="Voyer">
<organization>Bell Canada</organization> <organization>Bell Canada</organization>
<address> <address>
<email>daniel.voyer@bell.ca</email> <email>daniel.voyer@bell.ca</email>
</address> </address>
</author> </author>
<author fullname="Stefano Salsano" initials="S." surname="Salsano"> <author fullname="Stefano Salsano" initials="S." surname="Salsano">
<organization>Universita di Roma "Tor Vergata"</organization> <organization>Universita di Roma "Tor Vergata"</organization>
<address> <address>
<postal> <postal>
<street>Italy</street> <country>Italy</country>
</postal> </postal>
<email>stefano.salsano@uniroma2.it</email> <email>stefano.salsano@uniroma2.it</email>
</address> </address>
</author> </author>
<author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen"> <author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<email>mach.chen@huawei.com</email> <email>mach.chen@huawei.com</email>
</address> </address>
</author> </author>
<date day="17" month="October" year="2024"/> <date month="April" year="2025"/>
<workgroup>MPLS Working Group</workgroup> <area>RTG</area>
<abstract> <workgroup>mpls</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<!-- [rfced] We have updated the text below for readability and to clarify the
relationship between SR-MPLS and its expansion. Please review and let us
know any objections.
Original:
This document specifies the application of the MPLS loss and delay
measurement techniques, originally defined in RFC 6374, RFC 7876, and
RFC 9341 within Segment Routing (SR) networks that utilize the MPLS
data plane (SR-MPLS).
Current:
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).
-->
<abstract>
<t> <t>
This document specifies the application of the MPLS loss and delay measurement This document specifies the application of the MPLS loss and delay
techniques, originally defined in RFC 6374, RFC 7876, and RFC 9341 within measurement techniques (originally defined in RFCs 6374, 7876, and
Segment Routing (SR) networks that utilize the MPLS data plane (SR-MPLS). Segmen 9341) within Segment Routing (SR) networks that utilize the MPLS data
t Routing plane, also referred to as Segment Routing over MPLS (SR-MPLS). SR
enables the forwarding of packets through an ordered list of instructions, enables the forwarding of packets through an ordered list of
known as segments, which are imposed at the ingress node. instructions, known as segments, which are imposed at the ingress
This document defines the procedures and extensions necessary to perform node. This document defines the procedures and extensions necessary
accurate measurement of packet loss and delay in SR-MPLS environments, ensuring to perform accurate measurement of packet loss and delay in SR-MPLS
that network operators can effectively measure and maintain the quality of environments, ensuring that network operators can effectively measure
service across their SR-based MPLS networks. This includes coverage of links and maintain the quality of service across their SR-based MPLS
and end-to-end SR-MPLS paths, as well as SR Policies. networks. This includes coverage of links and end-to-end SR-MPLS
paths, as well as SR Policies.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sect-1" numbered="true" toc="default"> <section anchor="sect-1" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t> <!-- [rfced] We have updated the text below to demonstrate a 1:1
Segment Routing (SR), as specified in <xref target="RFC8402" format="default"/>, relationship between abbreviation and expansion. Please review.
leverages the source routing
paradigm and applies to both the Multiprotocol Label Switching (SR-MPLS) and
IPv6 (SRv6) data planes. 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="de
fault"/>, are used to steer
traffic through specific, user-defined paths using a list of segments.
</t>
<t> Original:
A comprehensive SR Performance Measurement toolset is one of the essential
requirements for measuring network performance to provide Service Level
Agreements (SLAs).
</t>
<t> Segment Routing (SR), as specified in [RFC8402], leverages the source
<xref target="RFC6374" format="default"/> specifies protocol mechanisms to enabl routing paradigm and applies to both the Multiprotocol Label
e efficient and accurate measurement of packet loss, one-way and two-way delay, Switching (SR-MPLS) and IPv6 (SRv6) data planes.
as well as related metrics such as delay-variation in MPLS networks.
</t>
<t> Current:
<xref target="RFC7876" format="default"/> specifies mechanisms for sending and p
rocessing out-of-band responses over a UDP return path when receiving query mess
ages defined in <xref target="RFC6374" format="default"/>. These mechanisms can
be applied to SR-MPLS networks.
</t>
<t> Segment Routing (SR), as specified in [RFC8402], leverages the source
<xref target="RFC9341" format="default"/> defines the Alternate-Marking Method u routing paradigm and applies to both the Multiprotocol Label
sing block number as a data correlation mechanism for packet loss measurement. Switching (MPLS) and Internet Protocol version 6 (IPv6) data planes.
</t> These are referred to as Segment Routing over MPLS (SR-MPLS) and
Segment Routing over IPv6 (SRv6), respectively.
<t> -->
This document utilizes the mechanisms from <xref target="RFC6374" format="defaul
t"/>, <xref target="RFC7876" format="default"/>, and <xref target="RFC9341" form
at="default"/> for delay and loss measurements in SR-MPLS networks. This include
s coverage of links and end-to-end SR-MPLS paths, as well as SR Policies.
</t>
<t> <t>Segment Routing (SR), as specified in <xref target="RFC8402"/>,
This document defines Return Path and Block Number TLV extensions for <xref targ leverages the source routing paradigm and applies to both the
et="RFC6374" format="default"/>, in Section 6, for delay and loss measurement in Multiprotocol Label Switching (MPLS) and Internet Protocol version 6
SR-MPLS networks. These TLV extensions also apply to MPLS Label Switched Paths (IPv6) data planes. These are referred to as Segment Routing over MPLS
(LSPs) <xref target="RFC3031" format="default"/>. However, the procedure for del (SR-MPLS) and Segment Routing over IPv6 (SRv6), respectively. SR takes
ay and loss measurement of MPLS LSPs is outside the scope of this document. advantage of Equal-Cost Multipaths (ECMPs) between source and transit
</t> nodes, between transit nodes, and between transit and destination
nodes. SR Policies, defined in <xref target="RFC9256"
format="default"/>, are used to steer traffic through specific,
user-defined paths using a list of segments.</t>
<t>A comprehensive SR Performance Measurement toolset is one of the
essential requirements for measuring network performance to provide
Service Level Agreements (SLAs).</t>
<t><xref target="RFC6374" format="default"/> specifies protocol
mechanisms to enable efficient and accurate measurement of packet loss,
one-way and two-way delay, as well as related metrics such as
delay-variation in MPLS networks.</t>
<t><xref target="RFC7876" format="default"/> specifies mechanisms for
sending and processing out-of-band responses over a UDP return path when
receiving query messages defined in <xref target="RFC6374"
format="default"/>. These mechanisms can be applied to SR-MPLS networks.</
t>
<t><xref target="RFC9341" format="default"/> defines the
Alternate-Marking Method using Block Numbers as a data correlation
mechanism for packet loss measurement.</t>
<t>This document utilizes the mechanisms from <xref target="RFC6374"
format="default"/>, <xref target="RFC7876" format="default"/>, and <xref
target="RFC9341" format="default"/> for delay and loss measurements in
SR-MPLS networks. This includes coverage of links and end-to-end SR-MPLS
paths, as well as SR Policies.</t>
<!-- [rfced] For clarity, please consider whether the following suggested update
conveys the intended meaning.
Original:
This document defines Return Path and Block Number TLV extensions for
[RFC6374], in Section 6, for delay and loss measurement in SR-MPLS
networks.
Current:
This document extends [RFC6374] by defining Return Path and Block Number TLVs
(see Section 6) for delay and loss measurement in SR-MPLS networks.
-->
<!-- [rfced] Does "also apply" mean "can also be used"?
Original:
These TLV extensions also apply to MPLS Label Switched
Paths (LSPs) [RFC3031].
Perhaps:
These TLVs can also be used in MPLS Label Switched
Paths (LSPs) [RFC3031].
-->
<t>This document extends <xref target="RFC6374"/> by defining
Return Path and Block Number TLVs (see <xref target="sect-6"/>) for delay
and loss measurement in SR-MPLS
networks. These TLVs also apply to MPLS Label Switched Paths
(LSPs) <xref target="RFC3031" format="default"/>. However, the procedure
for delay and loss measurement of MPLS LSPs is outside the scope of this
document.</t>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default"> <section anchor="sect-2" numbered="true" toc="default">
<name>Conventions Used in This Document</name> <name>Conventions Used in This Document</name>
<section anchor="sect-2.1" numbered="true" toc="default"> <section anchor="sect-2.1" numbered="true" toc="default">
<name>Requirements Language</name> <name>Requirements Language</name>
<t>
<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", ",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
described in BCP 14 <xref target="RFC2119" format="default"/> <xref target=" "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
RFC8174" format="default"/> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
when, and only when, they appear in all capitals, as shown here. be
</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
<section anchor="sect-2.2" numbered="true" toc="default"> <section anchor="sect-2.2" numbered="true" toc="default">
<name>Abbreviations</name> <name>Abbreviations</name>
<t>
ACH: Associated Channel Header.</t> <dl spacing="normal" newline="false">
<t> <dt>ACH:</dt><dd>Associated Channel Header</dd>
DM: Delay Measurement.</t> <dt>DM:</dt><dd>Delay Measurement</dd>
<t> <dt>ECMP:</dt><dd>Equal-Cost Multipath</dd>
ECMP: Equal Cost Multi-Path.</t> <dt>G-ACh:</dt><dd>Generic Associated Channel</dd>
<t> <dt>GAL:</dt><dd>Generic Associated Channel Label</dd>
G-ACh: Generic Associated Channel (G-ACh).</t> <dt>LM:</dt><dd>Loss Measurement</dd>
<t> <dt>LSE:</dt><dd>Label Stack Entry</dd>
GAL: Generic Associated Channel (G-ACh) Label.</t> <dt>MPLS:</dt><dd>Multiprotocol Label Switching</dd>
<t> <dt>PSID:</dt><dd>Path Segment Identifier</dd>
LM: Loss Measurement.</t> <dt>SID:</dt><dd>Segment Identifier</dd>
<t> <dt>SL:</dt><dd>Segment List</dd>
LSE: Label Stack Entry.</t> <dt>SR:</dt><dd>Segment Routing</dd>
<t> <dt>SR-MPLS:</dt><dd>Segment Routing over MPLS</dd>
MPLS: Multiprotocol Label Switching.</t> <dt>TC:</dt><dd>Traffic Class</dd>
<t> <dt>TE:</dt><dd>Traffic Engineering</dd>
PSID: Path Segment Identifier.</t> <dt>TTL:</dt><dd>Time to Live</dd>
<t> <dt>URO:</dt><dd>UDP Return Object</dd>
SID: Segment Identifier.</t> </dl>
<t>
SL: Segment List.</t>
<t>
SR: Segment Routing.</t>
<t>
SR-MPLS: Segment Routing with MPLS data plane.</t>
<t>
TC: Traffic Class.</t>
<t>
TE: Traffic Engineering.</t>
<t>
TTL: Time-To-Live.</t>
<t>
URO: UDP Return Object.</t>
</section> </section>
<section anchor="sect-2.3" numbered="true" toc="default"> <section anchor="sect-2.3" numbered="true" toc="default">
<name>Reference Topology</name> <name>Reference Topology</name>
<t> <t>In the reference topology shown in <xref
In the Reference Topology shown in Figure 1, the querier node Q1 initiates a que target="ure-reference-topology"/>, the querier node Q1 initiates a
ry message, and the responder node R1 transmits a response message for the query query message, and the responder node R1 transmits a response message
message received. The response message may be sent back to the querier node Q1 for the query message received. The response message may be sent back
on the same path (same set of links and nodes) or a different path in the revers to the querier node Q1 on the same path (the same set of links and nodes)
e direction from the path taken towards the responder R1. or on a different path in the reverse direction from the path taken
</t> towards the responder R1.</t>
<t> <t>T1 is a transmit timestamp, and T4 is a receive timestamp; both are
T1 is a transmit timestamp, and T4 is a receive timestamp, both added by node Q1 added by node Q1. T2 is a receive timestamp, and T3 is a transmit
. T2 is a receive timestamp, and T3 is a transmit timestamp, both added by node timestamp; both are added by node R1.</t>
R1.
</t>
<t> <t>SR is enabled with the MPLS data plane on nodes Q1 and R1. The
SR is enabled with the MPLS data plane on nodes Q1 and R1. nodes Q1 and R1 are connected via a channel (<xref target="RFC6374"
The nodes Q1 and R1 are connected via a channel (Section 2.9.1 of <xref target=" sectionFormat="of" section="2.9.1"/>). The channel may be a directly
RFC6374" format="default"/>). connected link enabled with MPLS (<xref target="RFC6374"
The channel may be a directly connected link enabled with MPLS (Section 2.9.1 of sectionFormat="of" section="2.9.1"/>) or an SR-MPLS path <xref
<xref target="RFC6374" format="default"/>) target="RFC8402" format="default"/>. The link may be a physical
or an SR-MPLS path <xref target="RFC8402" format="default"/>. interface, a virtual link, a Link Aggregation Group (LAG) <xref
The link may be a physical interface, a virtual link, or a Link Aggregation Grou target="IEEE802.1AX" format="default"/>, or a LAG member link. The
p (LAG) <xref target="IEEE802.1AX" format="default"/>, SR-MPLS path may be an SR-MPLS Policy <xref target="RFC9256"
or a LAG member link. The SR-MPLS path may be an SR-MPLS Policy <xref target="RF format="default"/> on node Q1 (called the "head-end") with the destinatio
C9256" format="default"/> n
on node Q1 (called head-end) with the destination to node R1 (called tail-end). to node R1 (called the "tail-end").</t>
</t>
<figure anchor="ure-reference-topology"> <figure anchor="ure-reference-topology">
<name>Reference Topology</name> <name>Reference Topology</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
T1 T2
T1 T2 / \
/ \ +-------+ Query +-------+
+-------+ Query +-------+ | | - - - - - - - - - ->| |
| | - - - - - - - - - ->| | | Q1 |=====================| R1 |
| Q1 |=====================| R1 | | |<- - - - - - - - - - | |
| |<- - - - - - - - - - | | +-------+ Response +-------+
+-------+ Response +-------+ \ /
\ / T4 T3
T4 T3 Querier Responder
Querier Responder
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="sect-3" numbered="true" toc="default"> <section anchor="sect-3" numbered="true" toc="default">
<name>Overview</name> <name>Overview</name>
<t> <t>
In this document, the procedures defined in In this document, the procedures defined in <xref target="RFC6374"
<xref target="RFC6374" format="default"/>, <xref target="RFC7876" format="defaul format="default"/>, <xref target="RFC7876" format="default"/>, and
t"/>, and <xref target="RFC9341" format="default"/> <xref target="RFC9341" format="default"/> are utilized for delay and
are utilized for delay and loss measurement in SR-MPLS networks. Specifically, loss measurement in SR-MPLS networks. Specifically, the one-way,
the one-way, two-way, and round-trip delay measurements described in Section two-way, and round-trip delay measurements described in <xref
2.4 of <xref target="RFC6374" format="default"/> are further elaborated for app target="RFC6374" sectionFormat="of" section="2.4"/> are further
lication within SR-MPLS elaborated for application within SR-MPLS networks. Similarly, the
networks. Similarly, the packet loss measurement procedures outlined in Section packet loss measurement procedures outlined in <xref
2.2 of <xref target="RFC6374" format="default"/> are extended for use in SR-MPLS target="RFC6374" sectionFormat="of" section="2.2"/> are extended for
networks. use in SR-MPLS networks.</t>
</t>
<t>
Packet loss measurement using the Alternate-Marking Method defined in <xref targ
et="RFC9341" format="default"/>
may employ the Block Number for data correlation. This is achieved by utilizing
the Block Number TLV extension defined in this document.
</t>
<t> <t>Packet loss measurement using the Alternate-Marking Method
In SR-MPLS networks, the query messages defined in <xref target="RFC6374" fo defined in <xref target="RFC9341" format="default"/> may employ the
rmat="default"/> Block Number for data correlation. This is achieved by utilizing the
MUST be transmitted along the same path as Block Number TLV extension defined in this document.</t>
the data traffic for links and end-to-end SR-MPLS paths,
to collect both transmit and receive timestamps for delay measurement and
to collect both transmit and receive traffic counters for loss measurement.
</t>
<t> <t>In SR-MPLS networks, the query messages defined in <xref
If it is desired in SR-MPLS networks that the same path (i.e., the same set of target="RFC6374" format="default"/> <bcp14>MUST</bcp14> be
links and nodes) between the querier and responder be used in both directions transmitted along the same path as the data traffic for links and
of the measurement, this can be achieved by using the Return Path TLV extension end-to-end SR-MPLS paths. This is to collect both transmit and receive
defined in this document. timestamps for delay measurement and to collect both transmit and
</t> receive traffic counters for loss measurement.</t>
<t> <t>If it is desired in SR-MPLS networks that the same path (i.e.,
The performance measurement procedures for links can be used to compute the same set of links and nodes) between the querier and responder
extended Traffic Engineering (TE) metrics for delay and loss, as described be used in both directions of the measurement, then this can be achieve
herein. These metrics are advertised in the network using the routing protocol d
extensions defined in <xref target="RFC7471" format="default"/>, <xref target="R by using the Return Path TLV extension defined in this document.</t>
FC8570" format="default"/>, and <xref target="RFC8571" format="default"/>.
</t> <t>The performance measurement procedures for links can be used to
compute extended Traffic Engineering (TE) metrics for delay and
loss, as described herein. These metrics are advertised in the
network using the routing protocol extensions defined in <xref
target="RFC7471" format="default"/>, <xref target="RFC8570"
format="default"/>, and <xref target="RFC8571"
format="default"/>.</t>
</section> </section>
<section anchor="sect-4" numbered="true" toc="default"> <section anchor="sect-4" numbered="true" toc="default">
<name>Query and Response Messages</name> <name>Query and Response Messages</name>
<section anchor="sect-4.1" numbered="true" toc="default"> <section anchor="sect-4.1" numbered="true" toc="default">
<name>Query Message for Links and SR-MPLS Policies</name> <name>Query Message for Links and SR-MPLS Policies</name>
<section anchor="sect-4.1.1" numbered="true" toc="default"> <section anchor="sect-4.1.1" numbered="true" toc="default">
<name>Query Message for Links</name> <name>Query Message for Links</name>
<t> <t>The query message, as defined in <xref target="RFC6374"
The query message, as defined in <xref target="RFC6374" format="default"/>, is s format="default"/>, is sent over the links for both delay and loss
ent over the links for both delay and loss measurement. In each Label Stack Entr measurement. In each Label Stack Entry (LSE) <xref target="RFC3032"
y (LSE) <xref target="RFC3032" format="default"/> in the MPLS label stack, the T format="default"/> in the MPLS label stack, the TTL value
TL value MUST be set to 255 <xref target="RFC5082" format="default"/>. <bcp14>MUST</bcp14> be set to 255 <xref target="RFC5082"
</t> format="default"/>.</t>
</section> </section>
<section anchor="sect-4.1.2" numbered="true" toc="default"> <section anchor="sect-4.1.2" numbered="true" toc="default">
<name>Query Message for SR-MPLS Policies</name> <name>Query Message for SR-MPLS Policies</name>
<t> <t>An SR-MPLS Policy Candidate-Path may contain a number of Segment
An SR-MPLS Policy Candidate-Path may contain a number of Segment Lists (SL Lists (SLs) (i.e., a stack of MPLS labels) <xref target="RFC9256"
s) format="default"/>. For delay and/or loss measurement for an
(i.e., a stack of MPLS labels) <xref target="RFC9256" format="default"/>. end-to-end SR-MPLS Policy, the query messages <bcp14>MUST</bcp14> be
For delay and/or loss measurement for an end-to-end SR-MPLS Policy, transmitted for every SL of the SR-MPLS Policy Candidate-Path. This
the query messages MUST be transmitted for every SL of the SR-MPLS Policy is done by creating a separate session for each SL. Each query
Candidate-Path, by creating a separate session for each SL. message of a session contains an SR-MPLS label stack of the
Each query message of a session contains an SR-MPLS label stack of the Can Candidate-Path, with the G-ACh Label (GAL) at the bottom of the
didate-Path, stack (with S=1) as shown in <xref
with the G-ACh Label (GAL) at the bottom of the stack (with S=1) as shown target="ure-header-for-an-end-to-end-sr-mpls-policy"/>. In each LSE
in Figure 2. in the MPLS label stack, the TTL value <bcp14>MUST</bcp14> be set to
In each LSE in the MPLS label stack, the TTL value MUST be set to 255 <xre 255 <xref target="RFC5082" format="default"/>.</t>
f target="RFC5082" format="default"/>.
</t>
<figure anchor="ure-header-for-an-end-to-end-sr-mpls-policy"> <figure anchor="ure-header-for-an-end-to-end-sr-mpls-policy">
<name>Example Query Message Header for an End-to-end SR-MPLS Policy< /name> <name>Example Query Message Header for an End-to-End SR-MPLS Policy< /name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(1) | TC |S| TTL | | Label(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(n) | TC |S| TTL | | Label(n) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL (value 13) | TC |1| TTL | | GAL (value 13) | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type | |0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
<t> <t>The fields 0001, Version, Reserved, and Channel Type shown in
The fields "0001", Version, Reserved, and Channel Type shown in Figure 2 are spe <xref target="ure-header-for-an-end-to-end-sr-mpls-policy"/> are
cified in <xref target="RFC5586" format="default"/>. specified in <xref target="RFC5586" format="default"/>.</t>
</t>
<t> <t>The SR-MPLS label stack can be empty in the case of a one-hop
The SR-MPLS label stack can be empty in the case of a one-hop SR-MPLS Policy wit SR-MPLS Policy with an Implicit NULL label.</t>
h an Implicit NULL label.
</t>
<t> <!-- [rfced] Seemingly, Success (0x1) is a Control Code. If this is correct, ma
For an SR-MPLS Policy, to ensure that the query message is processed by the inte y we udpate the text as follows?
nded responder, the Destination Address TLV (Type 129) <xref target="RFC6374" fo
rmat="default"/> containing an address of the responder can be sent in the query Original:
messages. The responder that supports this TLV MUST return Success in "Control The responder that supports this TLV MUST return
Code" <xref target="RFC6374" format="default"/> if it is the intended destinatio Success in "Control Code" [RFC6374] if it is the intended destination
n for the query. Otherwise, it MUST return 0x15: Error - Invalid Destination Nod for the query.
e Identifier <xref target="RFC6374" format="default"/>.
</t> Perhaps:
The responder that supports this TLV MUST return
Control Code 0x1 (Success) [RFC6374] if it is the intended destination
for the query.
-->
<t>For an SR-MPLS Policy, to ensure that the query message is
processed by the intended responder, the Destination Address TLV
(Type 129) <xref target="RFC6374" format="default"/> containing an
address of the responder can be sent in the query messages. The
responder that supports this TLV <bcp14>MUST</bcp14> return Success
in "Control Code" <xref target="RFC6374" format="default"/> 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"/>.</t>
</section> </section>
</section> </section>
<section anchor="sect-4.2" numbered="true" toc="default"> <section anchor="sect-4.2" numbered="true" toc="default">
<name>Response Message for Links and SR-MPLS Policies</name> <name>Response Message for Links and SR-MPLS Policies</name>
<section anchor="sect-4.2.1" numbered="true" toc="default"> <section anchor="sect-4.2.1" numbered="true" toc="default">
<name>One-way Measurement Mode</name> <name>One-Way Measurement Mode</name>
<t> <!-- [rfced] Could the text below be adjusted for clarity? Specifically, what
In one-way measurement mode defined in Section 2.4 of <xref target="RFC6374" for is being sent as "the destination address"?
mat="default"/>, the querier can receive "out-of-band" response messages with an
IP/UDP header by properly setting the UDP Return Object (URO) TLV in the query Original:
message. The URO TLV (Type=131) is defined in <xref target="RFC7876" format="def When the querier sets an IP address and a UDP port in the URO TLV, the
ault"/> and includes the UDP-Destination-Port and IP Address. When the querier s response message MUST be sent to that IP address as the destination address
ets an IP address and a UDP port in the URO TLV, the response message MUST be se and UDP port as the destination port.
nt to that IP address as the destination address and UDP port as the destination
port. In addition, the "Control Code" in the query message MUST be set to "out- Perhaps:
of-band response requested" <xref target="RFC6374" format="default"/>. When the querier sets an IP address and a UDP port in the URO TLV, the
</t> response message MUST be sent to that IP address, with that IP address as
the destination address and the UDP port as the destination port.
-->
<!-- [rfced] May we update "out-of-band response messages" to "Out-of-Band Respo
nse Requested messages..."? It is unclear whether the text refers to the Respon
se Requested messages or res ponses to Out-of-Band Response Requested messages.
Original:
In one-way measurement mode defined in Section 2.4 of [RFC6374], the
querier can receive "out-of-band" response messages with an IP/UDP
header by properly setting the UDP Return Object (URO) TLV in the
query message.
-->
<t>In the one-way measurement mode defined in <xref target="RFC6374"
sectionFormat="of" section="2.4"/>, the querier can receive
out-of-band response messages with an IP/UDP header by properly
setting the UDP Return Object (URO) TLV in the query message. The
URO TLV (Type 131) is defined in <xref target="RFC7876"
format="default"/> 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 as the destination address and 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"/>.</t>
</section> </section>
<section anchor="sect-4.2.2" numbered="true" toc="default"> <section anchor="sect-4.2.2" numbered="true" toc="default">
<name>Two-way Measurement Mode</name> <name>Two-Way Measurement Mode</name>
<t> <!-- [rfced] How may we update the text below for clarity and readability?
In two-way measurement mode defined in Section 2.4 of <xref target="RFC6374" for
mat="default"/>, the response messages SHOULD be sent back in-band on the same l
ink or the same end-to-end SR-MPLS path (same set of links and nodes) in the rev
erse direction to the querier, in order to perform accurate two-way delay measur
ement.
</t>
<t> Original:
For links, the response message as defined in <xref target="RFC6374" format="def In two-way measurement mode defined in Section 2.4 of [RFC6374], the
ault"/> is sent back on the same incoming link where the query message is receiv response messages SHOULD be sent back in-band on the same link or the
ed. In this case, the "Control Code" in the query message MUST be set to "in-ban same end-to-end SR-MPLS path (same set of links and nodes) in the
d response requested" <xref target="RFC6374" format="default"/>. reverse direction to the querier, in order to perform accurate two-
</t> way delay measurement.
<t> Perhaps:
For end-to-end SR-MPLS paths, the responder transmits the response message (exam In the two-way measurement mode defined in Section 2.4 of [RFC6374], the
ple as shown in Figure 2) on a specific return SR-MPLS path. The querier can req response messages SHOULD be sent back one of two ways: either they are sent
uest in the query message for the responder to send the response message back on back in-band on the same link, or they are sent back on the same end-to-end
a given return path using the MPLS Label Stack sub-TLV in the Return Path TLV d SR-MPLS path (i.e., the same set of links and nodes) in the reverse
efined in this document. direction to the querier. This is done in order to perform accurate two-
</t> way delay measurement.
-->
<t>In the two-way measurement mode defined in <xref target="RFC6374"
sectionFormat="of" section="2.4"/>, the response messages
<bcp14>SHOULD</bcp14> be sent back in-band on the same link or the
same end-to-end SR-MPLS path (same set of links and nodes) in the
reverse direction to the querier, in order to perform accurate
two-way delay measurement.</t>
<t>For links, the response message as defined in <xref
target="RFC6374" format="default"/> is sent back on the same
incoming link where the query message is received. In this case, the
Control Code in the query message <bcp14>MUST</bcp14> be set to
In-band Response Requested <xref target="RFC6374"
format="default"/>.</t>
<!-- [rfced] For readability, we suggest the update below. Please review to ens
ure it does not impact the intended meaning.
Original:
The querier can request in the query message for the responder
to 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.
Perhaps:
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>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"/>) on a specific
return SR-MPLS path. The querier can request in the query message for
the responder to 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>
<section anchor="sect-4.2.3" numbered="true" toc="default"> <section anchor="sect-4.2.3" numbered="true" toc="default">
<name>Loopback Measurement Mode</name> <name>Loopback Measurement Mode</name>
<t> <t>The loopback measurement mode defined in <xref target="RFC6374"
The loopback measurement mode defined in Section 2.8 of <xref target="RFC6374" f sectionFormat="of" section="2.8"/> is used to measure round-trip
ormat="default"/> is used to measure round-trip delay for a bidirectional circul delay for a bidirectional circular path <xref target="RFC6374"
ar path <xref target="RFC6374" format="default"/> in SR-MPLS networks. In this m format="default"/> in SR-MPLS networks. In this mode for SR-MPLS,
ode for SR-MPLS, the received query messages are not punted out of the fast path the received query messages are not punted out of the fast path in
in forwarding (i.e., to the slow path or control plane) at the responder. In ot forwarding (i.e., to the slow path or control plane) at the
her words, the responder does not process the payload or generate response messa responder. In other words, the responder does not process the
ges. The loopback function simply returns the received query message to the quer payload or generate response messages. The loopback function simply
ier without responder modifications <xref target="RFC6374" format="default"/>. returns the received query message to the querier without responder
</t> modifications <xref target="RFC6374" format="default"/>.</t>
<t> <t>The loopback mode is done by generating "queries" with the
The loopback mode is done by generating "queries" with the Response flag set to Response flag set to 1 and adding the Loopback Request object (Type
1 and adding the Loopback Request object (Type 3) <xref target="RFC6374" format= 3) <xref target="RFC6374" format="default"/>. In query messages, the
"default"/>. The label stack, as shown in Figure 3, in query messages, carries b label stack, as shown in <xref
oth the forward and reverse path labels in the MPLS header. The GAL is still car target="ure-header-for-an-end-to-end-sr-mpls-policy-in-loopback"/>,
ried at the bottom of the label stack (with S=1). carries both the forward and reverse path labels in the MPLS
</t> 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-loopbac k"> <figure anchor="ure-header-for-an-end-to-end-sr-mpls-policy-in-loopbac k">
<name>Example Query Message Header for an End-to-end SR-MPLS Policy in Loopback Measurement Mode</name> <name>Example Query Message Header for an End-to-End SR-MPLS Policy in the Loopback Measurement Mode</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(1) | TC |S| TTL | | Label(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(n) | TC |S| TTL | | Label(n) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse Path Label(1)| TC |S| TTL | | Reverse Path Label(1)| TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse Path Label(n)| TC |S| TTL | | Reverse Path Label(n)| TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL (value 13) | TC |1| TTL | | GAL (value 13) | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type | |0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sect-5" numbered="true" toc="default"> <section anchor="sect-5" numbered="true" toc="default">
<name>Delay and Loss Measurement</name> <name>Delay and Loss Measurement</name>
<section anchor="sect-5.1" numbered="true" toc="default"> <section anchor="sect-5.1" numbered="true" toc="default">
<name>Delay Measurement Message</name> <name>Delay Measurement Message</name>
<t> <!-- [rfced] Please review these similar sentences and let us know if we may
As defined in <xref target="RFC6374" format="default"/>, MPLS Delay Measurement update them for readability.
(DM) query and response messages use the Associated Channel Header (ACH) (value
0x000C for delay measurement) <xref target="RFC6374" format="default"/>, which i More specifically, what does "which" refer to in the examples below? Does it
dentifies the message type and the message payload as defined in Section 3.2 <xr refer to the ACH or the different values in parentheses?
ef target="RFC6374" format="default"/> following the ACH. For delay measurement,
the same ACH value is used for both links and end-to-end SR-MPLS Policies. In addition, we were unable to find "Combined DM+LM" in RFC 6374 as seen in
</t> the third example. Should this be updated to "combined LM/DM message" as used
in RFC 6374?
Original:
As defined in [RFC6374], MPLS Delay Measurement (DM) query and
response messages use the Associated Channel Header (ACH) (value
0x000C for delay measurement) [RFC6374], which identifies the message
type and the message payload as defined in Section 3.2 [RFC6374]
following the ACH.
As defined in [RFC6374], MPLS LM query and response messages use the
Associated Channel Header (ACH) (value 0x000A for direct loss
measurement or value 0x000B for inferred loss measurement), which
identifies the message type and the message payload defined in
Section 3.1 [RFC6374] following the ACH.
As defined in [RFC6374], Combined DM+LM query and response messages
use the Associated Channel Header (ACH) (value 0x000D for direct loss
and delay measurement or value 0x000E for inferred loss and delay
measurement), which identifies the message type and the message
payload defined in Section 3.3 [RFC6374] following the ACH.
Perhaps:
As defined in [RFC6374], MPLS Delay Measurement (DM) query and response
messages use the Associated Channel Header (ACH) (with the value 0x000C for
delay measurement). This value identifies the message type and the
message payload that follow the ACH, as defined in Section 3.2 of [RFC6374].
As defined in [RFC6374], MPLS LM query and response messages use the ACH
(with the value 0x000A for direct loss measurement or the value 0x000B for
inferred loss measurement). This value identifies the message type and the
message payload that follow the ACH, as defined in Section 3.1 of [RFC6374].
As defined in [RFC6374], combined DM+LM query and response messages use the
ACH (with the value 0x000D for direct loss and delay measurement or the
value 0x000E for inferred loss and delay measurement). This value
identifies the message type and the message payload that follows the ACH,
as defined in Section 3.3 of [RFC6374].
-->
<t>As defined in <xref target="RFC6374" format="default"/>, MPLS Delay
Measurement (DM) query and response messages use the Associated Channel
Header (ACH) (value 0x000C for delay measurement) <xref target="RFC6374"
format="default"/>, which identifies the message type and the message
payload as defined in <xref target="RFC6374" sectionFormat="of"
section="3.2"/> following the ACH. For delay measurement, the same ACH
value is used for both links and end-to-end SR-MPLS Policies.</t>
</section> </section>
<section anchor="sect-5.2" numbered="true" toc="default"> <section anchor="sect-5.2" numbered="true" toc="default">
<name>Loss Measurement Message</name> <name>Loss Measurement Message</name>
<t> <t>The Loss Measurement (LM) protocol can perform two distinct kinds of
The Loss Measurement (LM) protocol can perform two distinct kinds of loss measur loss measurement as described in <xref target="RFC6374"
ement as described in Section 2.9.8 of <xref target="RFC6374" format="default"/> sectionFormat="of" section="2.9.8"/>.</t>
.
</t>
<ul spacing="normal"> <ul spacing="normal">
<li>In inferred mode, LM will measure the loss of specially generated test m <li>In the inferred mode, LM will measure the loss of specially generated
essages to infer the approximate data plane loss level. Inferred mode LM provide test messages to infer the approximate data plane loss level. Inferred
s only approximate loss accounting.</li> mode LM provides only approximate loss accounting.</li>
<li>In direct mode, LM will directly measure data plane packet loss. Direct <li>In the direct mode, LM will directly measure data plane packet
mode LM provides perfect loss accounting but may require hardware support.</li> loss. Direct mode LM provides perfect loss accounting but may require
</ul> hardware support.</li>
</ul>
<t> <t>As defined in <xref target="RFC6374" format="default"/>, MPLS LM
As defined in <xref target="RFC6374" format="default"/>, MPLS LM query and respo query and response messages use the ACH (value 0x000A for direct loss
nse messages use the Associated Channel Header (ACH) (value 0x000A for direct lo measurement or value 0x000B for inferred loss measurement), which
ss measurement or value 0x000B for inferred loss measurement), which identifies identifies the message type and the message payload defined in <xref
the message type and the message payload defined in Section 3.1 <xref target="RF target="RFC6374" sectionFormat="of" section="3.1"/> following the
C6374" format="default"/> following the ACH. For loss measurement, the same ACH ACH. For loss measurement, the same ACH value is used for both links and
value is used for both links and end-to-end SR-MPLS Policies. end-to-end SR-MPLS Policies.</t>
</t>
</section> </section>
<section anchor="sect-5.3" numbered="true" toc="default"> <section anchor="sect-5.3" numbered="true" toc="default">
<name>Combined Loss/Delay Measurement Message</name> <name>Combined Loss/Delay Measurement Message</name>
<t> <t>As defined in <xref target="RFC6374" format="default"/>, combined
As defined in <xref target="RFC6374" format="default"/>, Combined DM+LM query an DM+LM query and response messages use the ACH (value 0x000D for
d response messages use the Associated Channel Header (ACH) (value 0x000D for di direct loss and delay measurement or value 0x000E for inferred loss
rect loss and delay measurement or value 0x000E for inferred loss and delay meas and delay measurement), which identifies the message type and the
urement), which identifies the message type and the message payload defined in S message payload defined in <xref target="RFC6374" sectionFormat="of"
ection 3.3 <xref target="RFC6374" format="default"/> following the ACH. For comb section="3.3"/> following the ACH. For combined loss and delay
ined loss and delay measurement, the same ACH value is used for both links and e measurement, the same ACH value is used for both links and end-to-end
nd-to-end SR-MPLS Policies. SR-MPLS Policies.</t>
</t>
</section> </section>
<section anchor="sect-5.4" numbered="true" toc="default"> <section anchor="sect-5.4" numbered="true" toc="default">
<name>Counters</name> <name>Counters</name>
<t> <!-- [rfced] In the instances below, we have adjusted "for accounting received
The Path Segment Identifier (PSID) <xref target="RFC9545" format="default"/> MUS traffic". Please review to ensure these changes do not alter your meaning.
T be carried in the received data packet for the traffic flow under measurement
for accounting received traffic on the egress node of the SR-MPLS Policy. In dir
ect mode, the PSID in the received query message, as shown in Figure 4, can be u
sed to associate the received traffic counter on the responder to detect the tra
nsmit packet loss for the end-to-end SR-MPLS Policy.
</t>
<t> Original:
In inferred mode, the PSID in the received query messages, as shown in Figure 4, The Path Segment Identifier (PSID) [RFC9545] MUST be carried in the
can be used to count the received query messages on the responder to detect the received data packet for the traffic flow under measurement for accounting
transmit packet loss for an end-to-end SR-MPLS Policy. received traffic on the egress node of the SR-MPLS Policy.
</t>
Different values of PSID can be used per Candidate-Path for accounting
received traffic to measure packet loss at the Candidate- Path level.
Current:
The Path Segment Identifier (PSID) [RFC9545] MUST 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.
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.
-->
<t>The Path Segment Identifier (PSID) <xref target="RFC9545"
format="default"/> <bcp14>MUST</bcp14> be carried in the received data
packet for the traffic flow under measurement, in order to account for re
ceived
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"/>) can be
used to associate the received traffic counter on the responder to
detect the transmit packet loss for the end-to-end SR-MPLS Policy.</t>
<t>In the inferred mode, the PSID in the received query messages (as show
n
in <xref target="ure-with-path-segment-identifier-for-sr-mpls-policy"/>)
can be
used to count the received query messages on the responder to detect
the transmit packet loss for an end-to-end SR-MPLS Policy.</t>
<figure anchor="ure-with-path-segment-identifier-for-sr-mpls-policy"> <figure anchor="ure-with-path-segment-identifier-for-sr-mpls-policy">
<name>Example with Path Segment Identifier for SR-MPLS Policy</name> <name>Example with the PSID for SR-MPLS Policy</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(1) | TC |S| TTL | | Label(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(n) | TC |S| TTL | | Label(n) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSID | TC |S| TTL | | PSID | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL (value 13) | TC |1| TTL | | GAL (value 13) | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type | |0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
<t> <t>The fields 0001, Version, Reserved, and Channel Type shown in <xref
The fields "0001", Version, Reserved, and Channel Type shown in Figure 4 are spe target="ure-with-path-segment-identifier-for-sr-mpls-policy"/> are
cified in <xref target="RFC5586" format="default"/>. specified in <xref target="RFC5586" format="default"/>.</t>
</t>
<t> <t>Different values of the PSID can be used per Candidate-Path to account fo
Different values of PSID can be used per Candidate-Path for accounting received r
traffic to measure packet loss at the Candidate-Path level. Similarly, different received traffic and to measure packet loss at the Candidate-Path
values of PSID can be used per Segment List of the Candidate-Path for accountin level. Similarly, different values of the PSID can be used per Segment List
g received traffic to measure packet loss at the Segment List level. The same va (SL) of
lue of PSID can be used for all Segment Lists of the SR-MPLS Policy to measure p the Candidate-Path for accounting received traffic to measure packet loss
acket loss at the SR-MPLS Policy level. at the SL level. The same value of the PSID can be used for all
</t> SLs of the SR-MPLS Policy to measure packet loss at the SR-MPLS
Policy level.</t>
</section> </section>
<section anchor="sect-5.5" numbered="true" toc="default"> <section anchor="sect-5.5" numbered="true" toc="default">
<name>Block Number for Counters</name> <name>Block Number for Counters</name>
<t> <t>The packet loss measurement using the Alternate-Marking Method defined
The packet loss measurement using the Alternate-Marking Method defined in <xref in <xref target="RFC9341" format="default"/> may use the block number for
target="RFC9341" format="default"/> may use the block number for data correlatio data correlation for the traffic flow under measurement. As defined in
n for the traffic flow under measurement. As defined in Section 3.1 of <xref tar <xref target="RFC9341" sectionFormat="of" section="3.1"/>, the block
get="RFC9341" format="default"/>, the block number is used to divide the traffic number is used to divide the traffic flow into consecutive blocks and
flow into consecutive blocks and count the number of packets transmitted and re count the number of packets transmitted and received in each block for
ceived in each block for loss measurement. loss measurement.</t>
</t>
<t> <t>As described in <xref target="RFC9341" sectionFormat="of"
As described in Section 4.3 of <xref target="RFC9341" format="default"/>, a prot section="4.3"/>, a protocol-based distributed solution can be used to
ocol-based distributed solution can be used to exchange values of counters on th exchange values of counters on the nodes for loss measurement. That
e nodes for loss measurement. That solution is further described in this documen solution is further described in this document using the LM messages
t using the LM messages defined in <xref target="RFC6374" format="default"/>. defined in <xref target="RFC6374" format="default"/>.</t>
</t>
<t> <t>The querier node assigns a block number to the block of data packets of
The querier node assigns a block number to the block of data packets of the traf the traffic flow under measurement. The querier counts the number of
fic flow under measurement. The querier counts the number of packets transmitted packets transmitted in each block. The mechanism for the assignment of the
in each block. The mechanism for the assignment of the block number is a local block number is a local decision on the querier and is outside the scope
decision on the querier and is outside the scope of this document. of this document.</t>
</t>
<t> <t>As an example, the querier can use the procedure defined in <xref
As an example, the querier can use the procedure defined in <xref target="I-D.ie target="RFC9714" format="default"/> for
tf-mpls-inband-pm-encapsulation" format="default"/> for alternate marking of the alternate marking of the data packets of the traffic flow under
data packets of the traffic flow under measurement. The responder counts the nu measurement. The responder counts the number of received packets in each
mber of received packets in each block based on the marking in the received data block based on the marking in the received data packets. The querier and
packets. The querier and responder maintain separate sets of transmit and recei responder maintain separate sets of transmit and receive counters for each
ve counters for each marking. The marking can be used as a block number or a sep marking. The marking can be used as a block number, or a separate block
arate block number can be incremented when the marking changes. Other methods ca number can be incremented when the marking changes. Other methods can be
n be defined for alternate marking of the data packets of the traffic flow under defined for alternate marking of the data packets of the traffic flow
measurement to assign a block number for the counters. under measurement to assign a block number for the counters.</t>
</t>
<t> <!-- [rfced] In the text below, does "while" mean "at the same time", or does
The LM query and response messages defined in <xref target="RFC6374" format="def it represent a contrast (like "whereas" or "on the other hand")?
ault"/> are used to measure packet loss for the block of data packets transmitte
d with the previous marking while data packets carry alternate marking. Specific
ally, LM query and response messages carry the transmit and receive counters (wh
ich are currently not incrementing) along with their block number to correlate f
or loss measurement.
</t>
<t> Original:
"The assumption of the block number mechanism is that The LM query and response messages defined in [RFC6374] are used to
the measurement nodes are time synchronized" as specified in Section 4.3 of <xre measure packet loss for the block of data packets transmitted with
f target="RFC9341" format="default"/> is not necessary, as the block number on t the previous marking while data packets carry alternate marking.
he responder can be synchronized based on the received LM query messages.
</t>
</section> Perhaps:
</section> The LM query and response messages defined in [RFC6374] are used to measure
packet loss for the block of data packets transmitted with the previous
marking, whereas data packets carry alternate marking.
-->
<t>The LM query and response messages defined in <xref target="RFC6374"
format="default"/> are used to measure packet loss for the block of data
packets transmitted with the previous marking while 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>
<!-- [rfced] FYI - The quoted text below appears differently in RFC 9341. We
have updated to match RFC 9341.
Original:
"The assumption of the block number mechanism is that the measurement
nodes are time synchronized" as specified in Section 4.3 of [RFC9341]
is not necessary, as the block number on the responder can be
synchronized based on the received LM query messages.
Current:
Section 4.3 of [RFC9341] specifies: "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><xref target="RFC9341" sectionFormat="of" section="4.3"/> 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="default"> <section anchor="sect-6" numbered="true" toc="default">
<name>TLV Extensions</name> <name>TLV Extensions</name>
<section anchor="sect-6.1" numbered="true" toc="default"> <section anchor="sect-6.1" numbered="true" toc="default">
<name>Return Path TLV Extension</name> <name>Return Path TLV Extension</name>
<t> <t>In the two-way measurement mode, the responder may transmit the
In two-way measurement mode, the responder may transmit the response message on response message on a specific return path, for example, in an ECMP
a specific return path, for example, in an ECMP environment. The querier can req environment. The querier can request in the query message for the
uest in the query message for the responder to send a response message back on a responder to send a response message back on a given return path
given return path (e.g., co-routed bidirectional path). This allows the respond (e.g., a co-routed bidirectional path). This allows the responder to
er to avoid creating and maintaining additional states (containing return paths) avoid creating and maintaining additional states (containing return
for the sessions. paths) for the sessions.</t>
</t>
<t> <t>The querier may not be directly reachable from the responder in a
The querier may not be directly reachable from the responder in a network. The q network. In this case, the querier <bcp14>MUST</bcp14> send its
uerier in this case MUST send its reachability path information to the responder reachability path information to the responder using the Return Path
using the Return Path TLV. TLV.</t>
</t>
<t> <t><xref target="RFC6374" format="default"/> defines query and
<xref target="RFC6374" format="default"/> defines query and response messages th response messages that can include one or more optional TLVs. This docume
at can include one or more optional TLVs. A new TLV Type (TBA1) is defined in th nt defines the the Return Path TLV (5) to
is document for the Return Path TLV to carry return path information in query me carry return path information in query messages. The Return Path TLV
ssages. The Return Path TLV is specific to a measurement session. The format of is specific to a measurement session. The format of the Return Path
the Return Path TLV is shown in Figure 5: TLV is shown in <xref target="ure-return-path-tlv"/> below:</t>
</t>
<figure anchor="ure-return-path-tlv"> <figure anchor="ure-return-path-tlv">
<name>Return Path TLV</name> <name>Return Path TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBA1 | Length | Reserved | | Type = 5 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Path Sub-TLV | | Return Path Sub-TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
<t> <t>The Length is a one-byte field and is equal to the length of the
The Length is a one-byte field and is equal to the length of the Return Path Sub Return Path Sub-TLV and the Reserved field in bytes. The Length
-TLV and the Reserved field in bytes. Length MUST NOT be 0 or 1. <bcp14>MUST NOT</bcp14> be 0 or 1.</t>
</t>
<t> <t>The Return Path TLV is defined in the "Mandatory TLV Type"
The Return Path TLV is defined in the Mandatory TLV Type registry space <xref ta registry space <xref target="RFC6374" format="default"/>. The
rget="RFC6374" format="default"/>. The querier MUST only insert one Return Path querier <bcp14>MUST</bcp14> only insert one Return Path TLV in the
TLV in the query message. The responder that supports this TLV MUST only process query message. The responder that supports this TLV
the first Return Path TLV and ignore the other Return Path TLVs if present. The <bcp14>MUST</bcp14> only process the first Return Path TLV and
responder that supports this TLV also MUST send the response message back on th ignore the other Return Path TLVs if present. The responder that
e return path specified in the Return Path TLV. The responder also MUST NOT add supports this TLV also <bcp14>MUST</bcp14> send the response message
a Return Path TLV in the response message. The Reserved field MUST be set to 0 a back on the return path specified in the Return Path TLV. The
nd MUST be ignored on the receive side. responder also <bcp14>MUST NOT</bcp14> add a Return Path TLV in the
</t> response message.</t>
<t>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="default"> <section anchor="sect-6.1.1" numbered="true" toc="default">
<name>Return Path Sub-TLV Extension</name> <name>Return Path Sub-TLV Extension</name>
<t> <t>The Return Path TLV contains a Sub-TLV to carry the return path. The
The Return Path TLV contains a Sub-TLV to carry the return path. The format of t format of the MPLS Label Stack Sub-TLV is shown in <xref
he MPLS Label Stack Sub-TLV is shown in Figure 6. The label entries in the Sub-T target="ure-segment-list-sub-tlv-in-return-path-tlv"/>. The label
LV MUST be in network order. The MPLS Label Stack Sub-TLV in the Return Path TLV entries in the Sub-TLV <bcp14>MUST</bcp14> be in network order. The MPLS
is of the following type: Label Stack Sub-TLV in the Return Path TLV is of the following type:</t>
</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Type (value 1): MPLS Label Stack of the Return Path</li> <li>Type (value 1): MPLS Label Stack of the Return Path</li>
</ul> </ul>
<figure anchor="ure-segment-list-sub-tlv-in-return-path-tlv"> <figure anchor="ure-segment-list-sub-tlv-in-return-path-tlv">
<name>MPLS Label Stack Sub-TLV in Return Path TLV</name> <name>MPLS Label Stack Sub-TLV in the Return Path TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=1 | Length | Reserved | | Type=1 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(1) | TC |S| TTL | | Label(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(n) | TC |1| TTL | | Label(n) | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
<t> <!-- [rfced] Is "LSE" singular or plural in the text below?
The MPLS Label Stack contains a list of 32-bit LSE that includes a 20-bit label
value, 8-bit TTL value, 3-bit TC value, and 1-bit EOS (S) field. An MPLS Label S
tack Sub-TLV may carry a stack of labels or a Binding SID label <xref target="RF
C8402" format="default"/> of the Return SR-MPLS Policy.
</t>
<t> Original:
The Length is a one-byte field and is equal to the length of the label stack fie The MPLS Label Stack contains a list of 32-bit LSE that includes a
ld and the Reserved field in bytes. Length MUST NOT be 0 or 1. 20-bit label value, 8-bit TTL value, 3-bit TC value, and 1-bit EOS
</t> (S) field.
<t> Perhaps (LSE is plural):
The Return Path TLV MUST carry only one Return Path Sub-TLV. The MPLS Label The MPLS Label Stack contains a list of 32-bit LSEs that each include a
Stack in the Return Path Sub-TLV MUST contain at least one MPLS Label. The respo 20-bit label value, an 8-bit TTL value, a 3-bit TC value, and a 1-bit EOS
nder that supports this Sub-TLV MUST only process the first Return Path Sub-TLV (S) field.
and ignore the other Return Path Sub-TLVs if present. The responder that support
s this Sub-TLV MUST send the response message back on the return path specified
in the Return Path Sub-TLV.
</t>
<t> -->
The Reserved field MUST be set to 0 and MUST be ignored on the receive side.
</t> <t>The MPLS Label Stack contains a list of 32-bit LSE that includes
a 20-bit label value, an 8-bit TTL value, a 3-bit TC value, and a 1-bit
EOS
(S) field. An MPLS Label Stack Sub-TLV may carry a stack of labels
or a Binding SID label <xref target="RFC8402" format="default"/> of
the Return SR-MPLS Policy.</t>
<t>The 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>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>The Reserved field <bcp14>MUST</bcp14> be set to 0 and
<bcp14>MUST</bcp14> be ignored on the receive side.</t>
</section> </section>
</section> </section>
<section anchor="sect-6.2" numbered="true" toc="default"> <section anchor="sect-6.2" numbered="true" toc="default">
<name>Block Number TLV Extension</name> <name>Block Number TLV Extension</name>
<t> <t><xref target="RFC6374" format="default"/> defines query and
<xref target="RFC6374" format="default"/> defines query and response messages th response messages that can include one or more optional TLVs. This docume
at can include one or more optional TLVs. A new TLV Type (value TBA2) is defined nt defines the Block Number TLV (6) to carry (8-bit) Block Number of
in this document to carry the Block Number (8-bit) of the traffic counters in t the traffic counters in the LM query and response
he LM query and response messages. The format of the Block Number TLV is shown i messages. The format of the Block Number TLV is shown in <xref
n Figure 7: target="ure-block-number-tlv"/>:</t>
</t>
<figure anchor="ure-block-number-tlv"> <figure anchor="ure-block-number-tlv">
<name>Block Number TLV</name> <name>Block Number TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBA2 | Length | Reserved |R| Block Number | | Type=6 | Length | Reserved |R| Block Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
<t> <t>The Length is a one-byte field and is equal to 2 bytes.</t>
The Length is a one-byte field and is equal to 2 bytes.
</t>
<t> <t>The Block Number TLV is defined in the "Mandatory TLV Type" registry
The Block Number TLV is defined in the Mandatory TLV Type registry space <xr space <xref target="RFC6374" format="default"/>. The querier
ef target="RFC6374" format="default"/>. <bcp14>MUST</bcp14> only insert one Block Number TLV in the query
The querier MUST only insert one Block Number TLV in the query message to id message to identify the Block Number for the traffic counters in the
entify the Block Number for forward direction. The responder that supports this TLV
the traffic counters in the forward direction. The responder that supports t <bcp14>MUST</bcp14> only insert one Block Number TLV in the response
his TLV MUST only insert one message to identify the Block Number for the traffic counters in the
Block Number TLV in the response message to identify the Block Number for th reverse direction. The responder also <bcp14>MUST</bcp14> return the
e traffic counters in the reverse direction. first Block Number TLV from the query message and ignore the other
The responder also MUST return the first Block Number TLV from the query mes Block Number TLVs if present. The Block Number TLV is specific to a
sage and ignore the other Block Number TLVs if present. measurement session. The R flag is used to indicate the query and
The Block Number TLV is specific to a measurement session. response message direction associated with the Block Number. The R
The R flag is used to indicate the query and response message direction asso flag <bcp14>MUST</bcp14> be clear in the query message for the Block
ciated with the Block Number. Number associated with Counter 1 and Counter 2, and set in the
The R flag MUST be clear in the query message for the Block Number associate response message for the Block Number associated with Counter 3 and
d with Counter 1 and Counter 2, Counter 4.</t>
and set in the response message for the Block Number associated with Counter
3 and Counter 4.
</t>
<t> <t>The Reserved field <bcp14>MUST</bcp14> be set to 0 and
The Reserved field MUST be set to 0 and MUST be ignored on the receive side. <bcp14>MUST</bcp14> be ignored on the receive side.</t>
</t>
</section> </section>
</section> </section>
<section anchor="sect-7" numbered="true" toc="default"> <section anchor="sect-7" numbered="true" toc="default">
<name>ECMP for SR-MPLS Policies</name> <name>ECMP for SR-MPLS Policies</name>
<t> <t>The SLs of an SR-MPLS Policy can have ECMPs between the source and
The SLs of an SR-MPLS Policy can have ECMPs between the source and transit nodes transit nodes, between transit nodes, and between transit and
, between transit nodes, and between transit and destination nodes. Usage of nod destination nodes. Usage of a node SID <xref target="RFC8402"
e SID <xref target="RFC8402" format="default"/> by the SLs of an SR-MPLS Policy format="default"/> by the SLs of an SR-MPLS Policy can result in ECMP
can result in ECMP paths. In addition, usage of Anycast SID <xref target="RFC840 paths. In addition, usage of an Anycast SID <xref target="RFC8402"
2" format="default"/> by the SLs of an SR-MPLS Policy can result in ECMP paths v format="default"/> by the SLs of an SR-MPLS Policy can result in ECMP
ia transit nodes that are part of that Anycast group. The query and response mes paths via transit nodes that are part of that anycast group. The query
sages are sent to traverse different ECMP paths to measure the delay of each ECM and response messages are sent to traverse different ECMP paths to
P path of an SL. measure the delay of each ECMP path of an SL.</t>
</t>
<t>
The forwarding plane has various hashing functions available to forward packets
on specific ECMP paths. For end-to-end SR-MPLS Policy delay measurement, differe
nt entropy label <xref target="RFC6790" format="default"/> values can be used in
query and response messages to take advantage of the hashing function in the fo
rwarding plane to influence the ECMP path taken by them.
</t>
<t> <t>The forwarding plane has various hashing functions available to
The considerations for loss measurement for different ECMP paths of an SR-MPLS P forward packets on specific ECMP paths. For end-to-end SR-MPLS Policy
olicy are outside the scope of this document. delay measurement, different entropy label values <xref target="RFC6790"
</t> format="default"/> can be used in query and response messages to
take advantage of the hashing function in the forwarding plane to
influence the ECMP path taken by them.</t>
<t>The considerations for loss measurement for different ECMP paths of
an SR-MPLS Policy are outside the scope of this document.</t>
</section> </section>
<section anchor="sect-8" numbered="true" toc="default"> <section anchor="sect-8" numbered="true" toc="default">
<name>Extended TE Link Metrics Advertisements</name> <name>Extended TE Link Metrics Advertisement</name>
<t> <t>The extended TE metrics for link delay (namely, average delay,
The extended TE metrics for link delay (namely, average delay, minimum delay, ma minimum delay, maximum delay, and delay-variance) and packet loss can be
ximum delay and delay-variance) and packet loss can be computed using the perfor computed using the performance measurement procedures described in this
mance measurement procedures described in this document and advertised in the ro document and can be advertised in the routing domain as follows:</t>
uting domain as follows:
</t>
<ul spacing="normal"> <ul spacing="normal">
<li>For OSPF, IS-IS, and BGP-LS, protocol extensions defined in <xref target <li>For OSPF, IS-IS, and the Border Gateway Protocol - Link State
="RFC7471" format="default"/>, <xref target="RFC8570" format="default"/>, and <x (BGP-LS), the protocol extensions defined in <xref target="RFC7471"
ref target="RFC8571" format="default"/>, respectively, are used for advertising format="default"/>, <xref target="RFC8570" format="default"/>, and
the extended TE link delay and loss metrics in the network.</li> <xref target="RFC8571" format="default"/>, respectively, are used for
<li>The extended TE link delay and loss metrics are advertised for Layer-2 L advertising the extended TE link delay and loss metrics in the
AG bundle member links in OSPF <xref target="RFC9356" format="default"/> and IS- network.</li>
IS <xref target="RFC8668" format="default"/> using the same protocol extensions <li>The extended TE link delay and loss metrics are advertised for
defined in <xref target="RFC7471" format="default"/> and <xref target="RFC8570" Layer-2 LAG bundle member links in OSPF <xref target="RFC9356"
format="default"/>, respectively.</li> format="default"/> and IS-IS <xref target="RFC8668" format="default"/>
<li>The advertised delay-variance metric is computed as Packet Delay Variati using the same protocol extensions defined in <xref target="RFC7471"
on (PDV), as described in Section 4.2 of <xref target="RFC5481" format="default" format="default"/> and <xref target="RFC8570" format="default"/>,
/>.</li> respectively.</li>
</ul> <li>The advertised delay-variance metric is computed as Packet Delay
Variation (PDV), as described in <xref target="RFC5481"
sectionFormat="of" section="4.2"/>.</li>
</ul>
</section> </section>
<section anchor="sect-9" numbered="true" toc="default"> <section anchor="sect-9" numbered="true" toc="default">
<name>Backwards Compatibility</name> <name>Backwards Compatibility</name>
<t> <t>The procedures defined in this document are backwards compatible with
The procedures defined in this document are backwards compatible with the proced the procedures defined in <xref target="RFC6374" format="default"/> at
ures defined in <xref target="RFC6374" format="default"/> at both the querier an both the querier and the responder. If the responder does not support the
d responder. If the responder does not support the new Mandatory TLV Types defin new Mandatory TLV Types defined in this document, it will return Error
ed in this document it will return Error 0x17: Unsupported Mandatory TLV Object 0x17: Unsupported Mandatory TLV Object as per <xref target="RFC6374"
as per <xref target="RFC6374" format="default"/>. format="default"/>.</t>
</t>
</section> </section>
<section anchor="sect-10" numbered="true" toc="default"> <section anchor="sect-10" numbered="true" toc="default">
<name>Manageability Considerations</name> <name>Manageability Considerations</name>
<t> <t>The manageability considerations described in <xref target="RFC6374"
The manageability considerations described in Section 7 of <xref target="RFC6374 sectionFormat="of" section="7"/> and <xref target="RFC7876"
" format="default"/> and Section 6 of <xref target="RFC7876" format="default"/> sectionFormat="of" section="6"/> are applicable to this
are applicable to this specification. specification.</t>
</t>
</section> </section>
<section anchor="sect-11" numbered="true" toc="default"> <section anchor="sect-11" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>The security considerations specified in <xref target="RFC6374"
The security considerations specified in <xref target="RFC6374" format="default" format="default"/>, <xref target="RFC7471" format="default"/>, <xref
/>, <xref target="RFC7471" format="default"/>, <xref target="RFC8570" format="de target="RFC8570" format="default"/>, <xref target="RFC8571"
fault"/>, <xref target="RFC8571" format="default"/>, <xref target="RFC7876" form format="default"/>, <xref target="RFC7876" format="default"/>, and <xref
at="default"/>, and <xref target="RFC9341" format="default"/> also apply to the target="RFC9341" format="default"/> also apply to the procedures
procedures described in this document. described in this document.</t>
</t>
<t> <t>The procedure defined in this document is intended for deployment in
The procedure defined in this document is intended for deployment in a single op a single operator administrative domain. As such, the querier node, the
erator administrative domain. As such, the querier node, responder node, forward responder node, the forward path, and the return paths are provisioned
, and return paths are provisioned by the operator for the probe session. It is by the operator for the probe session. It is assumed that the operator
assumed that the operator has verified the integrity of the forward and return p has verified the integrity of the forward and return paths of the probe
aths of the probe packets. packets.</t>
</t>
<t> <t>The Return Path TLV extensions defined in this document may be used
The "Return Path" TLV extensions defined in this document may be used for potent for potential address spoofing. For example, a query message may carry a
ial address spoofing. For example, a query message may carry a return path that return path that has a destination that is not local at the querier. To
has a destination that is not local at the querier. To prevent such possible att prevent such possible attacks, the responder may drop the query messages
acks, the responder may drop the query messages when it cannot determine whether when it cannot determine whether the return path has the destination
the return path has the destination local at the querier. The querier may send local at the querier. The querier may send a proper source address in
a proper source address in the "Source Address" TLV that the responder can use t the Source Address TLV. The responder can use this to make that
o make that determination, for example, by checking the access control list prov determination, for example, by checking the access control list
isioned by the operator. provisioned by the operator.</t>
</t>
</section> </section>
<section anchor="sect-12" numbered="true" toc="default"> <section anchor="sect-12" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is requested to allocate values for the following Mandatory
TLV Types for <xref target="RFC6374" format="default"/> from the "MPLS Loss/D <t>IANA has allocated values for the following Mandatory TLV
elay Measurement TLV Object" Types <xref target="RFC6374" format="default"/> from the "MPLS
registry contained within the "Generic Associated Channel (G-ACh) Parameters" Loss/Delay Measurement TLV Object" registry contained within the
registry set:</t> "Generic Associated Channel (G-ACh) Parameters" registry group:</t>
<table anchor="iana-tlv-type-tbl" align="center"> <table anchor="iana-tlv-type-tbl" align="center">
<name>MPLS Loss/Delay Measurement TLV Types</name> <name>MPLS Loss/Delay Measurement TLV Types</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left">Code</th>
<th align="center">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<!-- [rfced] We have removed "TLV" from the Descriptions to align with the IANA
registries <https://www.iana.org/assignments/g-ach-parameters>. Please let us
know any corrections.
Original:
| TBA1 | Return Path TLV | This document |
| TBA2 | Block Number TLV | This document |
Current:
| 5 | Return Path | RFC 9779 |
| 6 | Block Number | RFC 9779 |
-->
<tr> <tr>
<td align="left">TBA1</td> <td align="left">5</td>
<td align="center">Return Path TLV</td> <td align="left">Return Path</td>
<td align="left">This document</td> <td align="left">RFC 9779</td>
</tr> </tr>
<tr> <tr>
<td align="left">TBA2</td> <td align="left">6</td>
<td align="center">Block Number TLV</td> <td align="left">Block Number</td>
<td align="left">This document</td> <td align="left">RFC 9779</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>The Block Number TLV is carried in the query and response messages,
The Block Number TLV is carried in the query and response messages, and the Retu and the Return Path TLV is carried in the query messages.</t>
rn Path TLV is carried in the query messages.
</t>
<t> <!-- [rfced] Should the registry name be plural? Note that we will ask IANA to
IANA is requested to create a registry for "Return Path Sub-TLV Type." All code update their registry if this change is accepted.
points in the range 0 through 175 in this registry shall be allocated according
to the "IETF Review" procedure as specified in <xref target="RFC8126" format="de Current: Return Path Sub-TLV Type
fault"/>. Code points in the range 176 through 239 in this registry shall be all Perhaps: Return Path Sub-TLV Types
ocated according to the "First Come, First Served" procedure as specified in <xr -->
ef target="RFC8126" format="default"/>. Remaining code points are allocated acco <!-- [rfced] Much of this text duplicates what appears in the table. Perhaps th
rding to <xref target="iana-return-path-tbl" format="default"/>: e text should just indicate that the code points are assigned as defined in Tabl
</t> e 2?
Section 12:
All code points in the range 0 through 175 in this registry
shall be allocated according to the "IETF Review" procedure as
specified in [RFC8126]. Code points in the range 176 through 239 in
this registry shall be allocated according to the "First Come, First
Served" procedure as specified in [RFC8126]. Remaining code points
are allocated according to Table 2:
Table 2:
| Value | Description | Reference |
+===========+=========================+===============+
| 1 - 175 | IETF Review | This document |
| 176 - 239 | First Come First Served | This document |
| 240 - 251 | Experimental Use | This document |
| 252 - 254 | Private Use | This document |
-->
<t>IANA has created the "Return Path Sub-TLV Type" registry.
All code points in the range 0 through 175 in this registry shall be
allocated according to the "IETF Review" procedure as specified in <xref
target="RFC8126" format="default"/>. Code points in the range 176 through
239 in this registry shall be allocated according to the "First Come
First Served" procedure as specified in <xref target="RFC8126"
format="default"/>. Remaining code points are allocated according to
<xref target="iana-return-path-tbl" format="default"/>:</t>
<table anchor="iana-return-path-tbl" align="center"> <table anchor="iana-return-path-tbl" align="center">
<name>Return Path Sub-TLV Type Registry</name> <name>Return Path Sub-TLV Type Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left">Value</th>
<th align="center">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">1 - 175</td> <td align="left">1 - 175</td>
<td align="center">IETF Review</td> <td align="left">IETF Review</td>
<td align="left">This document</td> <td align="left">RFC 9779</td>
</tr> </tr>
<tr> <tr>
<td align="left">176 - 239</td> <td align="left">176 - 239</td>
<td align="center">First Come First Served</td> <td align="left">First Come First Served</td>
<td align="left">This document</td> <td align="left">RFC 9779</td>
</tr> </tr>
<tr> <tr>
<td align="left">240 - 251</td> <td align="left">240 - 251</td>
<td align="center">Experimental Use</td> <td align="left">Experimental Use</td>
<td align="left">This document</td> <td align="left">RFC 9779</td>
</tr> </tr>
<tr> <tr>
<td align="left">252 - 254</td> <td align="left">252 - 254</td>
<td align="center">Private Use</td> <td align="left">Private Use</td>
<td align="left">This document</td> <td align="left">RFC 9779</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>This document defines the following values in the Return Path Sub-TLV T
ype registry:</t> <t>This document defines the following values in the "Return Path Sub-TLV
Type" registry:</t>
<table anchor="iana-return-path-type-tbl" align="center"> <table anchor="iana-return-path-type-tbl" align="center">
<name>Return Path Sub-TLV Types</name> <name>Return Path Sub-TLV Types</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left">Value</th>
<th align="center">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0</td> <td align="left">0</td>
<td align="center">Reserved</td> <td align="left">Reserved</td>
<td align="left">This document</td> <td align="left">RFC 9779</td>
</tr> </tr>
<tr> <tr>
<td align="left">1</td> <td align="left">1</td>
<td align="center">MPLS Label Stack of the Return Path</td> <td align="left">MPLS Label Stack of the Return Path</td>
<td align="left">This document</td> <td align="left">RFC 9779</td>
</tr> </tr>
<tr> <tr>
<td align="left">255</td> <td align="left">255</td>
<td align="center">Reserved</td> <td align="left">Reserved</td>
<td align="left">This document</td> <td align="left">RFC 9779</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
&RFC2119; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.
&RFC6374; xml"/>
&RFC7876; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6374.
&RFC8174; xml"/>
&RFC9341; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7876.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9341.
xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
&RFC3031; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3031.
&RFC3032; xml"/>
&RFC5082; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3032.
&RFC5481; xml"/>
&RFC5586; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5082.
&RFC6790; xml"/>
&RFC7471; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5481.
&RFC8126; xml"/>
&RFC8402; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5586.
&RFC8570; xml"/>
&RFC8571; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6790.
&RFC8668; xml"/>
&RFC9256; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7471.
&RFC9356; xml"/>
&RFC9545; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8570.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8571.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8668.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9356.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9545.
xml"/>
&I-D.ietf-mpls-inband-pm-encapsulation; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9714.xml"
/>
<!-- 2020 XML for [IEEE802.1AX] below:
<reference anchor="IEEE802.1AX"> <reference anchor="IEEE802.1AX">
<front> <front>
<title>IEEE Standard for Local and metropolitan area networks - Link Aggregation</title> <title>IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation</title>
<author> <author>
<organization> <organization>IEEE</organization>
IEEE Std. 802.1AX </author>
</organization> <date month="May" year="2020"/>
</front>
<seriesInfo name="IEEE Std 802.1AX-2020"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9105034"/>
</reference>
-->
<reference anchor="IEEE802.1AX">
<front>
<title>IEEE Standard for Local and Metropolitan Area Networks - Link
Aggregation</title>
<author>
<organization>IEEE</organization>
</author> </author>
<date month="November" year="2008"/> <date month="November" year="2008"/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.1AX-2008"/>
</reference> </reference>
</references> </references>
</references> </references>
<section numbered="false" anchor="acknowledgments" toc="default"> <section numbered="false" anchor="acknowledgments" toc="default">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t> <!-- [rfced] Would it make sense to refer to the MPLS Review Team (assuming that
The authors would like to thank Thierry Couture and Ianik Semco for the discussi is correct), as we are unsure what MPLS-RT refers to and we are unable to find
ons on the use cases for performance measurement in segment routing networks. Th information about it.
e authors would like to thank Patrick Khordoc, Ruby Lin, and Haowei Shi for impl
ementing the mechanisms defined in this document. The authors would like to than Original:
k Greg Mirsky and Xiao Min for providing many useful comments and suggestions. T Thanks to Huaimo Chen, Yimin Shen, and Xufeng Liu for MPLS-RT expert
he authors would also like to thank Stewart Bryant, Sam Aldrin, Tarek Saad, and review, ...
Rajiv Asati for their review comments. Thanks to Huaimo Chen, Yimin Shen, and Xu -->
feng Liu for MPLS-RT expert review, Zhaohui Zhang for RTGDIR early review, Tony
Li for shepherd's review, Ned Smith for SECDIR review, Roni Even for Gen-ART rev <t>The authors would like to thank <contact fullname="Thierry Couture"/>
iew, Marcus Ihlar for TSV-ART review, Dhruv Dhody for OPSDIR review, Gunter Van and <contact fullname="Ianik Semco"/> for the discussions on the use
de Velde, Paul Wouters, Eric Vyncke, Murray Kucherawy, John Scudder, and Roman D cases for performance measurement in segment routing networks. The
anyliw for IESG review. authors would like to thank <contact fullname="Patrick Khordoc"/>,
</t> <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-RT 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>
<section numbered="false" anchor="contributors" toc="default"> <section numbered="false" anchor="contributors" toc="default">
<name>Contributors</name> <name>Contributors</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Sagar Soni
Cisco Systems, Inc.
Email: sagsoni@cisco.com
Zafar Ali <contact fullname="Sagar Soni">
Cisco Systems, Inc. <organization>Cisco Systems, Inc.</organization>
Email: zali@cisco.com <address>
<email>sagsoni@cisco.com</email>
</address>
</contact>
<contact fullname="Zafar Ali">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>zali@cisco.com</email>
</address>
</contact>
<contact fullname="Pier Luigi Ventre">
<organization>CNIT</organization>
<address>
<postal>
<country>Italy</country>
</postal>
<email>pierluigi.ventre@cnit.it</email>
</address>
</contact>
Pier Luigi Ventre
CNIT
Italy
Email: pierluigi.ventre@cnit.it
]]></artwork>
</section> </section>
</back> </back>
<!-- [rfced] [IEEE802.1AX] references the 2008 version of this IEEE Standard.
May we update this reference to use the current standard from 2020 as seen
in the following URL: <https://ieeexplore.ieee.org/document/9105034>? -->
<!-- [rfced] We removed the quotes around Control Code throughout to align with
use in RFC 6374. We have also removed the quotes and capitalized "in-band
response requested" and "out-of-band response requested" to match what appears
in RFC 6374 and the IANA registry. Please review and let us know if
corrections are needed.
-->
<!-- [rfced] Please review the following changes and questions regarding the
terms used in this document:
a) RFC 8402 uses "node-SID" and "Anycast-SID" rather than "node SID" and
"Anycast SID". May we update these to match the usage from RFC 8402?
b) We note different capitalization of label stack vs. Label Stack. We believe
the lowercase "label stack" is used in general text, but "Label Stack" is capita
lized when it refers to the the TLV. Please confirm that MPLS Label Stack is ca
pitalized correctly in the following:
Original:
The MPLS Label Stack contains a list of 32-bit LSE that includes a
20-bit label value, 8-bit TTL value, 3-bit TC value, and 1-bit EOS
(S) field. An MPLS Label Stack Sub-TLV may carry a stack of labels
or a Binding SID label [RFC8402] of the Return SR-MPLS Policy.
-->
<!-- [rfced] Please review the following questions and changes regarding
the abbreviations used in this document.
a) Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations should be
expanded upon first use. Is "EOS" in the text below an abbreviation? If so,
how may it be expanded?
1-bit EOS (S) field
b) FYI - We have expanded the abbreviation below. Please review to
ensure correctness.
Border Gateway Protocol - Link State (BGP-LS)
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice. -->
</rfc> </rfc>
 End of changes. 136 change blocks. 
780 lines changed or deleted 1101 lines changed or added

This html diff was produced by rfcdiff 1.48.