Performance Measurement for Segment Routing Networks with MPLS Data Plane
draft-ietf-mpls-rfc6374-sr-17

MPLS Working Group                                        R. Gandhi, Ed.
Internet-Draft                                               C. Filsfils
Intended status: Standards Track                     Cisco Systems, Inc.
Expires: 20 April 2025                                          D. Voyer
                                                             Bell Canada
                                                              S. Salsano
                                        Universita di Roma "Tor Vergata"
                                                                 M. Chen
                                                                  Huawei
                                                         17 October 2024

  Performance Measurement for Segment Routing Networks with MPLS Data
                                 Plane
                     draft-ietf-mpls-rfc6374-sr-17

Abstract

   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).  Segment Routing enables the forwarding of
   packets through an ordered list of instructions, known as segments,
   which are imposed at the ingress node.  This document defines the
   procedures and extensions necessary to perform accurate measurement
   of packet loss and delay in SR-MPLS environments, ensuring that
   network operators can effectively measure and maintain the quality of
   service across their SR-based MPLS networks.  This includes coverage
   of links and end-to-end SR-MPLS paths, as well as SR Policies.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 20 April 2025.

Gandhi, et al.            Expires 20 April 2025                 [Page 1]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Reference Topology  . . . . . . . . . . . . . . . . . . .   5
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Query and Response Messages . . . . . . . . . . . . . . . . .   6
     4.1.  Query Message for Links and SR-MPLS Policies  . . . . . .   6
       4.1.1.  Query Message for Links . . . . . . . . . . . . . . .   6
       4.1.2.  Query Message for SR-MPLS Policies  . . . . . . . . .   6
     4.2.  Response Message for Links and SR-MPLS Policies . . . . .   7
       4.2.1.  One-way Measurement Mode  . . . . . . . . . . . . . .   7
       4.2.2.  Two-way Measurement Mode  . . . . . . . . . . . . . .   8
       4.2.3.  Loopback Measurement Mode . . . . . . . . . . . . . .   8
   5.  Delay and Loss Measurement  . . . . . . . . . . . . . . . . .   9
     5.1.  Delay Measurement Message . . . . . . . . . . . . . . . .   9
     5.2.  Loss Measurement Message  . . . . . . . . . . . . . . . .   9
     5.3.  Combined Loss/Delay Measurement Message . . . . . . . . .  10
     5.4.  Counters  . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.5.  Block Number for Counters . . . . . . . . . . . . . . . .  11
   6.  TLV Extensions  . . . . . . . . . . . . . . . . . . . . . . .  12
     6.1.  Return Path TLV Extension . . . . . . . . . . . . . . . .  12
       6.1.1.  Return Path Sub-TLV Extension . . . . . . . . . . . .  13
     6.2.  Block Number TLV Extension  . . . . . . . . . . . . . . .  14
   7.  ECMP for SR-MPLS Policies . . . . . . . . . . . . . . . . . .  15
   8.  Extended TE Link Metrics Advertisements . . . . . . . . . . .  16
   9.  Backwards Compatibility . . . . . . . . . . . . . . . . . . .  16
   10. Manageability Considerations  . . . . . . . . . . . . . . . .  16
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  16
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  18

Gandhi, et al.            Expires 20 April 2025                 [Page 2]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

     13.2.  Informative References . . . . . . . . . . . . . . . . .  19
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  21
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   Segment Routing (SR), as specified in [RFC8402], 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 [RFC9256], are used to steer traffic through
   specific, user-defined paths using a list of segments.

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

   [RFC6374] specifies protocol mechanisms to enable efficient and
   accurate measurement of packet loss, one-way and two-way delay, as
   well as related metrics such as delay-variation in MPLS networks.

   [RFC7876] specifies mechanisms for sending and processing out-of-band
   responses over a UDP return path when receiving query messages
   defined in [RFC6374].  These mechanisms can be applied to SR-MPLS
   networks.

   [RFC9341] defines the Alternate-Marking Method using block number as
   a data correlation mechanism for packet loss measurement.

   This document utilizes the mechanisms from [RFC6374], [RFC7876], and
   [RFC9341] for delay and loss measurements in SR-MPLS networks.  This
   includes coverage of links and end-to-end SR-MPLS paths, as well as
   SR Policies.

   This document defines Return Path and Block Number TLV extensions for
   [RFC6374], in Section 6, for delay and loss measurement in SR-MPLS
   networks.  These TLV extensions also apply to MPLS Label Switched
   Paths (LSPs) [RFC3031].  However, the procedure for delay and loss
   measurement of MPLS LSPs is outside the scope of this document.

2.  Conventions Used in This Document

Gandhi, et al.            Expires 20 April 2025                 [Page 3]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.2.  Abbreviations

   ACH: Associated Channel Header.

   DM: Delay Measurement.

   ECMP: Equal Cost Multi-Path.

   G-ACh: Generic Associated Channel (G-ACh).

   GAL: Generic Associated Channel (G-ACh) Label.

   LM: Loss Measurement.

   LSE: Label Stack Entry.

   MPLS: Multiprotocol Label Switching.

   PSID: Path Segment Identifier.

   SID: Segment Identifier.

   SL: Segment List.

   SR: Segment Routing.

   SR-MPLS: Segment Routing with MPLS data plane.

   TC: Traffic Class.

   TE: Traffic Engineering.

   TTL: Time-To-Live.

   URO: UDP Return Object.

Gandhi, et al.            Expires 20 April 2025                 [Page 4]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

2.3.  Reference Topology

   In the Reference Topology shown in Figure 1, the querier node Q1
   initiates a query message, and the responder node R1 transmits a
   response message for the query message received.  The response
   message may be sent back to the querier node Q1 on the same path
   (same set of links and nodes) or a different path in the reverse
   direction from the path taken towards the responder R1.

   T1 is a transmit timestamp, and T4 is a receive timestamp, both added
   by node Q1.  T2 is a receive timestamp, and T3 is a transmit
   timestamp, both added by node R1.

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

                          T1                T2
                         /                   \
                +-------+       Query         +-------+
                |       | - - - - - - - - - ->|       |
                |   Q1  |=====================|   R1  |
                |       |<- - - - - - - - - - |       |
                +-------+       Response      +-------+
                         \                   /
                          T4                T3
                 Querier                       Responder

                        Figure 1: Reference Topology

3.  Overview

   In this document, the procedures defined in [RFC6374], [RFC7876], and
   [RFC9341] are utilized for delay and loss measurement in SR-MPLS
   networks.  Specifically, the one-way, two-way, and round-trip delay
   measurements described in Section 2.4 of [RFC6374] are further
   elaborated for application within SR-MPLS networks.  Similarly, the
   packet loss measurement procedures outlined in Section 2.2 of
   [RFC6374] are extended for use in SR-MPLS networks.

Gandhi, et al.            Expires 20 April 2025                 [Page 5]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

   Packet loss measurement using the Alternate-Marking Method defined in
   [RFC9341] may employ the Block Number for data correlation.  This is
   achieved by utilizing the Block Number TLV extension defined in this
   document.

   In SR-MPLS networks, the query messages defined in [RFC6374] MUST be
   transmitted along the same path as 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.

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

   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 [RFC7471],
   [RFC8570], and [RFC8571].

4.  Query and Response Messages

4.1.  Query Message for Links and SR-MPLS Policies

4.1.1.  Query Message for Links

   The query message, as defined in [RFC6374], is sent over the links
   for both delay and loss measurement.  In each Label Stack Entry (LSE)
   [RFC3032] in the MPLS label stack, the TTL value MUST be set to 255
   [RFC5082].

4.1.2.  Query Message for SR-MPLS Policies

   An SR-MPLS Policy Candidate-Path may contain a number of Segment
   Lists (SLs) (i.e., a stack of MPLS labels) [RFC9256].  For delay and/
   or loss measurement for an end-to-end SR-MPLS Policy, the query
   messages MUST be transmitted for every SL of the SR-MPLS Policy
   Candidate-Path, by creating a separate session for each SL.  Each
   query message of a session contains an SR-MPLS label stack of the
   Candidate-Path, with the G-ACh Label (GAL) at the bottom of the stack
   (with S=1) as shown in Figure 2.  In each LSE in the MPLS label
   stack, the TTL value MUST be set to 255 [RFC5082].

Gandhi, et al.            Expires 20 April 2025                 [Page 6]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Label(1)             | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Label(n)             | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  GAL (value 13)       | TC  |1|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|Version| Reserved      |       Channel Type            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 2: Example Query Message Header for an End-to-end SR-MPLS
                                   Policy

   The fields "0001", Version, Reserved, and Channel Type shown in
   Figure 2 are specified in [RFC5586].

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

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

4.2.  Response Message for Links and SR-MPLS Policies

4.2.1.  One-way Measurement Mode

   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.  The URO TLV (Type=131) is defined in [RFC7876] and
   includes the UDP-Destination-Port and IP Address.  When the querier
   sets an IP address and a UDP port in the URO TLV, the response
   message MUST 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 MUST be set to "out-of-band response
   requested" [RFC6374].

Gandhi, et al.            Expires 20 April 2025                 [Page 7]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

4.2.2.  Two-way Measurement Mode

   In two-way measurement mode defined in Section 2.4 of [RFC6374], the
   response messages SHOULD 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.

   For links, the response message as defined in [RFC6374] is sent back
   on the same incoming link where the query message is received.  In
   this case, the "Control Code" in the query message MUST be set to
   "in-band response requested" [RFC6374].

   For end-to-end SR-MPLS paths, the responder transmits the response
   message (example as shown in Figure 2) 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.

4.2.3.  Loopback Measurement Mode

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

   The loopback mode is done by generating "queries" with the Response
   flag set to 1 and adding the Loopback Request object (Type 3)
   [RFC6374].  The label stack, as shown in Figure 3, in query messages,
   carries both the forward and reverse path labels in the MPLS header.
   The GAL is still carried at the bottom of the label stack (with S=1).

Gandhi, et al.            Expires 20 April 2025                 [Page 8]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Label(1)             | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Label(n)             | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Reverse Path Label(1)| TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Reverse Path Label(n)| TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  GAL (value 13)       | TC  |1|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|Version| Reserved      |       Channel Type            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 3: Example Query Message Header for an End-to-end SR-MPLS
                    Policy in Loopback Measurement Mode

5.  Delay and Loss Measurement

5.1.  Delay Measurement Message

   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.  For delay measurement, the same ACH value is used
   for both links and end-to-end SR-MPLS Policies.

5.2.  Loss Measurement Message

   The Loss Measurement (LM) protocol can perform two distinct kinds of
   loss measurement as described in Section 2.9.8 of [RFC6374].

   *  In inferred mode, LM will measure the loss of specially generated
      test messages to infer the approximate data plane loss level.
      Inferred mode LM provides only approximate loss accounting.

Gandhi, et al.            Expires 20 April 2025                 [Page 9]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

   *  In direct mode, LM will directly measure data plane packet loss.
      Direct mode LM provides perfect loss accounting but may require
      hardware support.

   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.  For loss measurement, the
   same ACH value is used for both links and end-to-end SR-MPLS
   Policies.

5.3.  Combined Loss/Delay Measurement Message

   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.  For
   combined loss and delay measurement, the same ACH value is used for
   both links and end-to-end SR-MPLS Policies.

5.4.  Counters

   The Path Segment Identifier (PSID) [RFC9545] MUST 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 direct mode, the PSID in the received query message, as shown in
   Figure 4, can be used to associate the received traffic counter on
   the responder to detect the transmit packet loss for the end-to-end
   SR-MPLS Policy.

   In inferred mode, the PSID in the received query messages, as shown
   in Figure 4, can be used to count the received query messages on the
   responder to detect the transmit packet loss for an end-to-end SR-
   MPLS Policy.

Gandhi, et al.            Expires 20 April 2025                [Page 10]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Label(1)             | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Label(n)             | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  PSID                 | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  GAL (value 13)       | TC  |1|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|Version| Reserved      |       Channel Type            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 4: Example with Path Segment Identifier for SR-MPLS Policy

   The fields "0001", Version, Reserved, and Channel Type shown in
   Figure 4 are specified in [RFC5586].

   Different values of PSID can be used per Candidate-Path for
   accounting received traffic to measure packet loss at the Candidate-
   Path level.  Similarly, different values of PSID can be used per
   Segment List of the Candidate-Path for accounting received traffic to
   measure packet loss at the Segment List level.  The same value of
   PSID can be used for all Segment Lists of the SR-MPLS Policy to
   measure packet loss at the SR-MPLS Policy level.

5.5.  Block Number for Counters

   The packet loss measurement using the Alternate-Marking Method
   defined in [RFC9341] may use the block number for data correlation
   for the traffic flow under measurement.  As defined in Section 3.1 of
   [RFC9341], the block number is used to divide the traffic flow into
   consecutive blocks and count the number of packets transmitted and
   received in each block for loss measurement.

   As described in Section 4.3 of [RFC9341], a protocol-based
   distributed solution can be used to exchange values of counters on
   the nodes for loss measurement.  That solution is further described
   in this document using the LM messages defined in [RFC6374].

Gandhi, et al.            Expires 20 April 2025                [Page 11]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

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

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

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

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

6.  TLV Extensions

6.1.  Return Path TLV Extension

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

   The querier may not be directly reachable from the responder in a
   network.  The querier in this case MUST send its reachability path
   information to the responder using the Return Path TLV.

Gandhi, et al.            Expires 20 April 2025                [Page 12]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

   [RFC6374] defines query and response messages that can include one or
   more optional TLVs.  A new TLV Type (TBA1) is defined in this
   document for the Return Path TLV to carry return path information in
   query messages.  The Return Path TLV is specific to a measurement
   session.  The format of the Return Path TLV is shown in Figure 5:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Type = TBA1  |    Length     |      Reserved                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Return Path Sub-TLV                        |
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 5: Return Path TLV

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

   The Return Path TLV is defined in the Mandatory TLV Type registry
   space [RFC6374].  The querier MUST only insert one Return Path TLV in
   the query message.  The responder that supports this TLV MUST only
   process the first Return Path TLV and ignore the other Return Path
   TLVs if present.  The responder that supports this TLV also MUST send
   the response message back on the return path specified in the Return
   Path TLV.  The responder also MUST NOT add a Return Path TLV in the
   response message.  The Reserved field MUST be set to 0 and MUST be
   ignored on the receive side.

6.1.1.  Return Path Sub-TLV Extension

   The Return Path TLV contains a Sub-TLV to carry the return path.  The
   format of the MPLS Label Stack Sub-TLV is shown in Figure 6.  The
   label entries in the Sub-TLV MUST be in network order.  The MPLS
   Label Stack Sub-TLV in the Return Path TLV is of the following type:

   *  Type (value 1): MPLS Label Stack of the Return Path

Gandhi, et al.            Expires 20 April 2025                [Page 13]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type=1     |    Length     |      Reserved                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Label(1)             | TC  |S|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Label(n)             | TC  |1|      TTL      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 6: MPLS Label Stack Sub-TLV in Return Path TLV

   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.

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

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

   The Reserved field MUST be set to 0 and MUST be ignored on the
   receive side.

6.2.  Block Number TLV Extension

   [RFC6374] defines query and response messages that can include one or
   more optional TLVs.  A new TLV Type (value TBA2) is defined in this
   document to carry the Block Number (8-bit) of the traffic counters in
   the LM query and response messages.  The format of the Block Number
   TLV is shown in Figure 7:

Gandhi, et al.            Expires 20 April 2025                [Page 14]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Type = TBA2  |    Length     | Reserved    |R| Block Number  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 7: Block Number TLV

   The Length is a one-byte field and is equal to 2 bytes.

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

   The Reserved field MUST be set to 0 and MUST be ignored on the
   receive side.

7.  ECMP for SR-MPLS Policies

   The SLs of an SR-MPLS Policy can have ECMPs between the source and
   transit nodes, between transit nodes, and between transit and
   destination nodes.  Usage of node SID [RFC8402] by the SLs of an SR-
   MPLS Policy can result in ECMP paths.  In addition, usage of Anycast
   SID [RFC8402] by the SLs of an SR-MPLS Policy can result in ECMP
   paths via transit nodes that are part of that Anycast group.  The
   query and response messages are sent to traverse different ECMP paths
   to measure the delay of each ECMP path of an SL.

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

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

Gandhi, et al.            Expires 20 April 2025                [Page 15]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

8.  Extended TE Link Metrics Advertisements

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

   *  For OSPF, IS-IS, and BGP-LS, protocol extensions defined in
      [RFC7471], [RFC8570], and [RFC8571], respectively, are used for
      advertising the extended TE link delay and loss metrics in the
      network.

   *  The extended TE link delay and loss metrics are advertised for
      Layer-2 LAG bundle member links in OSPF [RFC9356] and IS-IS
      [RFC8668] using the same protocol extensions defined in [RFC7471]
      and [RFC8570], respectively.

   *  The advertised delay-variance metric is computed as Packet Delay
      Variation (PDV), as described in Section 4.2 of [RFC5481].

9.  Backwards Compatibility

   The procedures defined in this document are backwards compatible with
   the procedures defined in [RFC6374] at both the querier and
   responder.  If the responder does not support the new Mandatory TLV
   Types defined in this document it will return Error 0x17: Unsupported
   Mandatory TLV Object as per [RFC6374].

10.  Manageability Considerations

   The manageability considerations described in Section 7 of [RFC6374]
   and Section 6 of [RFC7876] are applicable to this specification.

11.  Security Considerations

   The security considerations specified in [RFC6374], [RFC7471],
   [RFC8570], [RFC8571], [RFC7876], and [RFC9341] also apply to the
   procedures described in this document.

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

Gandhi, et al.            Expires 20 April 2025                [Page 16]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

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

12.  IANA Considerations

   IANA is requested to allocate values for the following Mandatory TLV
   Types for [RFC6374] from the "MPLS Loss/Delay Measurement TLV Object"
   registry contained within the "Generic Associated Channel (G-ACh)
   Parameters" registry set:

               +=======+==================+===============+
               | Value |   Description    | Reference     |
               +=======+==================+===============+
               | TBA1  | Return Path TLV  | This document |
               +-------+------------------+---------------+
               | TBA2  | Block Number TLV | This document |
               +-------+------------------+---------------+

                 Table 1: MPLS Loss/Delay Measurement TLV
                                  Types

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

   IANA is requested to create a registry for "Return Path Sub-TLV
   Type."  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:

Gandhi, et al.            Expires 20 April 2025                [Page 17]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

          +===========+=========================+===============+
          | 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 |
          +-----------+-------------------------+---------------+

                 Table 2: Return Path Sub-TLV Type Registry

   This document defines the following values in the Return Path Sub-TLV
   Type registry:

      +=======+=====================================+===============+
      | Value |             Description             | Reference     |
      +=======+=====================================+===============+
      | 0     |               Reserved              | This document |
      +-------+-------------------------------------+---------------+
      | 1     | MPLS Label Stack of the Return Path | This document |
      +-------+-------------------------------------+---------------+
      | 255   |               Reserved              | This document |
      +-------+-------------------------------------+---------------+

                     Table 3: Return Path Sub-TLV Types

13.  References

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374,
              DOI 10.17487/RFC6374, September 2011,
              <https://www.rfc-editor.org/info/rfc6374>.

   [RFC7876]  Bryant, S., Sivabalan, S., and S. Soni, "UDP Return Path
              for Packet Loss and Delay Measurement for MPLS Networks",
              RFC 7876, DOI 10.17487/RFC7876, July 2016,
              <https://www.rfc-editor.org/info/rfc7876>.

Gandhi, et al.            Expires 20 April 2025                [Page 18]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9341]  Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
              and T. Zhou, "Alternate-Marking Method", RFC 9341,
              DOI 10.17487/RFC9341, December 2022,
              <https://www.rfc-editor.org/info/rfc9341>.

13.2.  Informative References

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001,
              <https://www.rfc-editor.org/info/rfc3031>.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
              <https://www.rfc-editor.org/info/rfc3032>.

   [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
              Pignataro, "The Generalized TTL Security Mechanism
              (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
              <https://www.rfc-editor.org/info/rfc5082>.

   [RFC5481]  Morton, A. and B. Claise, "Packet Delay Variation
              Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,
              March 2009, <https://www.rfc-editor.org/info/rfc5481>.

   [RFC5586]  Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
              "MPLS Generic Associated Channel", RFC 5586,
              DOI 10.17487/RFC5586, June 2009,
              <https://www.rfc-editor.org/info/rfc5586>.

   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
              RFC 6790, DOI 10.17487/RFC6790, November 2012,
              <https://www.rfc-editor.org/info/rfc6790>.

   [RFC7471]  Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
              Previdi, "OSPF Traffic Engineering (TE) Metric
              Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
              <https://www.rfc-editor.org/info/rfc7471>.

Gandhi, et al.            Expires 20 April 2025                [Page 19]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8570]  Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
              D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
              Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
              2019, <https://www.rfc-editor.org/info/rfc8570>.

   [RFC8571]  Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
              C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
              IGP Traffic Engineering Performance Metric Extensions",
              RFC 8571, DOI 10.17487/RFC8571, March 2019,
              <https://www.rfc-editor.org/info/rfc8571>.

   [RFC8668]  Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri,
              M., and E. Aries, "Advertising Layer 2 Bundle Member Link
              Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668,
              December 2019, <https://www.rfc-editor.org/info/rfc8668>.

   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
              A., and P. Mattes, "Segment Routing Policy Architecture",
              RFC 9256, DOI 10.17487/RFC9256, July 2022,
              <https://www.rfc-editor.org/info/rfc9256>.

   [RFC9356]  Talaulikar, K., Ed. and P. Psenak, "Advertising Layer 2
              Bundle Member Link Attributes in OSPF", RFC 9356,
              DOI 10.17487/RFC9356, January 2023,
              <https://www.rfc-editor.org/info/rfc9356>.

   [RFC9545]  Cheng, W., Ed., Li, H., Li, C., Ed., Gandhi, R., and R.
              Zigler, "Path Segment Identifier in MPLS-Based Segment
              Routing Networks", RFC 9545, DOI 10.17487/RFC9545,
              February 2024, <https://www.rfc-editor.org/info/rfc9545>.

   [I-D.ietf-mpls-inband-pm-encapsulation]
              Cheng, W., Min, X., Zhou, T., Dai, J., and Y. Peleg,
              "Encapsulation For MPLS Performance Measurement with
              Alternate-Marking Method", Work in Progress, Internet-
              Draft, draft-ietf-mpls-inband-pm-encapsulation-18, 12
              September 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-mpls-inband-pm-encapsulation-18>.

Gandhi, et al.            Expires 20 April 2025                [Page 20]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

   [IEEE802.1AX]
              IEEE Std. 802.1AX, "IEEE Standard for Local and
              metropolitan area networks - Link Aggregation", November
              2008.

Acknowledgments

   The authors would like to thank Thierry Couture and Ianik Semco for
   the discussions on the use cases for performance measurement in
   segment routing networks.  The authors would like to thank Patrick
   Khordoc, Ruby Lin, and Haowei Shi for implementing the mechanisms
   defined in this document.  The authors would like to thank Greg
   Mirsky and Xiao Min for providing many useful comments and
   suggestions.  The authors would also like to thank Stewart Bryant,
   Sam Aldrin, Tarek Saad, and Rajiv Asati for their review comments.
   Thanks to Huaimo Chen, Yimin Shen, and Xufeng 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 review,
   Marcus Ihlar for TSV-ART review, Dhruv Dhody for OPSDIR review,
   Gunter Van de Velde, Paul Wouters, Eric Vyncke, Murray Kucherawy,
   John Scudder, and Roman Danyliw for IESG review.

Contributors

   Sagar Soni
   Cisco Systems, Inc.
   Email: sagsoni@cisco.com

   Zafar Ali
   Cisco Systems, Inc.
   Email: zali@cisco.com

   Pier Luigi Ventre
   CNIT
   Italy
   Email: pierluigi.ventre@cnit.it

Authors' Addresses

   Rakesh Gandhi (editor)
   Cisco Systems, Inc.
   Canada
   Email: rgandhi@cisco.com

   Clarence Filsfils
   Cisco Systems, Inc.
   Email: cfilsfil@cisco.com

Gandhi, et al.            Expires 20 April 2025                [Page 21]
Internet-Draft     Performance Measurement for SR-MPLS      October 2024

   Daniel Voyer
   Bell Canada
   Email: daniel.voyer@bell.ca

   Stefano Salsano
   Universita di Roma "Tor Vergata"
   Italy
   Email: stefano.salsano@uniroma2.it

   Mach(Guoyi) Chen
   Huawei
   Email: mach.chen@huawei.com

Gandhi, et al.            Expires 20 April 2025                [Page 22]