SPRING Working Group R. Gandhi, Ed. Internet-Draft C. Filsfils Intended status: Informational Cisco Systems, Inc. Expires: 30 November 2023 D. Voyer Bell Canada M. Chen Huawei B. Janssens Colt R. Foote Nokia 29 May 2023 Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing Networks draft-ietf-spring-stamp-srpm-07 Abstract Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes procedures for Performance Measurement in SR networks using the mechanisms defined in RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) and its optional extensions defined in RFC 8972 and further augmented in draft-ietf-ippm-stamp-srpm. The procedure described is used for both links and end-to-end SR paths including SR Policies and SR Flexible Algorithm IGP paths as well as services, and is applicable to both SR-MPLS and SRv6 data planes. 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 30 November 2023. Gandhi, et al. Expires 30 November 2023 [Page 1] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 Copyright Notice Copyright (c) 2023 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 . . . . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Example STAMP Reference Model . . . . . . . . . . . . . . 6 4. Delay Measurement for Links and SR Paths . . . . . . . . . . 8 4.1. Session-Sender Test Packet . . . . . . . . . . . . . . . 8 4.1.1. Session-Sender Test Packet for Links . . . . . . . . 8 4.1.2. Session-Sender Test Packet for SR Paths . . . . . . . 9 4.1.3. Session-Sender Test Packet for Service over SR Path . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Session-Reflector Test Packet . . . . . . . . . . . . . . 12 4.2.1. One-Way Measurement Mode . . . . . . . . . . . . . . 13 4.2.2. Two-Way Measurement Mode . . . . . . . . . . . . . . 13 4.2.3. Loopback Measurement Mode . . . . . . . . . . . . . . 15 4.3. Delay Measurement for P2MP SR Policies . . . . . . . . . 19 4.4. Additional STAMP Test Packet Processing Rules . . . . . . 20 4.4.1. TTL . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.4.2. IPv6 Hop Limit . . . . . . . . . . . . . . . . . . . 20 4.4.3. Router Alert Option . . . . . . . . . . . . . . . . . 20 4.4.4. IPv6 Flow Label . . . . . . . . . . . . . . . . . . . 21 4.4.5. UDP Checksum . . . . . . . . . . . . . . . . . . . . 21 5. Packet Loss Measurement for Links and SR Paths . . . . . . . 21 6. Direct Measurement for Links and SR Paths . . . . . . . . . . 21 7. STAMP Session State for Links and SR Paths . . . . . . . . . 22 8. ECMP Support for SR Policies . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 Gandhi, et al. Expires 30 November 2023 [Page 2] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 11.2. Informative References . . . . . . . . . . . . . . . . . 25 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction Segment Routing (SR) leverages the source routing paradigm and greatly simplifies network operations for Software Defined Networks (SDNs). SR is applicable to both Multiprotocol Label Switching (SR- MPLS) and IPv6 (SRv6) data planes [RFC8402]. SR takes advantage of the Equal-Cost Multipaths (ECMPs) between source and transit nodes, between transit nodes and between transit and destination nodes. SR Policies as defined in [RFC9256] are used to steer traffic through a specific, user-defined paths using a stack of Segments. A comprehensive SR Performance Measurement (PM) toolset is one of the essential requirements to measure network performance to provide Service Level Agreements (SLAs). The Simple Two-Way Active Measurement Protocol (STAMP) provides capabilities for the measurement of various performance metrics in IP networks [RFC8762] without the use of a control channel to pre-signal session parameters. [RFC8972] defines optional extensions, in the form of TLVs, for STAMP. [I-D.ietf-ippm-stamp-srpm] augments that framework to define STAMP extensions for SR networks. This document describes procedures for Performance Measurement in SR networks using the mechanisms defined in STAMP [RFC8762] and its optional extensions defined in [RFC8972] and further augmented in [I-D.ietf-ippm-stamp-srpm]. The procedure described is used for both links and end-to-end SR paths including SR Policies [RFC8402] and SR Flexible Algorithm IGP paths [RFC9350] as well as services, and is applicable to both SR-MPLS and SRv6 data planes. 2. Conventions Used in This Document 2.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.2. Abbreviations BSID: Binding Segment ID. C-SID: Compressed Segment ID. Gandhi, et al. Expires 30 November 2023 [Page 3] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 DM: Delay Measurement. ECMP: Equal Cost Multi-Path. HL: Hop Limit. HMAC: Hashed Message Authentication Code. LM: Loss Measurement. MPLS: Multiprotocol Label Switching. NTP: Network Time Protocol. OWAMP: One-Way Active Measurement Protocol. PM: Performance Measurement. PSID: Path Segment Identifier. PTP: Precision Time Protocol. SHA: Secure Hash Algorithm. SID: Segment ID. SL: Segment List. SR: Segment Routing. SRH: Segment Routing Header. SR-MPLS: Segment Routing with MPLS data plane. SRv6: Segment Routing with IPv6 data plane. SSID: STAMP Session Identifier. STAMP: Simple Two-Way Active Measurement Protocol. TC: Traffic Class. TTL: Time To Live. Gandhi, et al. Expires 30 November 2023 [Page 4] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 2.3. Reference Topology In the Reference Topology shown below, the STAMP Session-Sender S1 initiates a STAMP test packet and the STAMP Session-Reflector R1 transmits a reply STAMP test packet. The reply test packet may be transmitted to the STAMP Session-Sender S1 on the same path (same set of links and nodes) or a different path in the reverse direction from the path taken towards the Session-Reflector. The nodes S1 and R1 may be connected via a link or an SR path [RFC8402]. The link may be a physical interface, virtual link, or Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member link. The SR path may be an SR Policy [RFC9256] on node S1 (called head-end) with destination to node R1 (called tail-end) [RFC8402] or SR Flexible Algorithm IGP path [RFC9350]. T1 T2 / \ +-------+ Test Packet +-------+ | | - - - - - - - - - ->| | | S1 |=====================| R1 | | |<- - - - - - - - - - | | +-------+ Reply Test Packet +-------+ \ / T4 T3 STAMP Session-Sender STAMP Session-Reflector Reference Topology 3. Overview For performance measurement in SR networks, the STAMP Session-Sender and Session-Reflector can use the base test packets defined [RFC8762]. The test packets defined in [RFC8972], however, are preferred because of the extensions being used in SR environments. The STAMP test packets MUST be encapsulated and transmitted on a desired SR path under measurement. The STAMP test packets are encapsulated using IP/UDP header and may use Destination UDP port 862 [RFC8762]. In this document, the STAMP test packets using IP/UDP header are considered for SR networks, where the STAMP test packets are further encapsulated with an SR-MPLS or SRv6 header. Gandhi, et al. Expires 30 November 2023 [Page 5] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 The STAMP test packets are used in one-way, two-way (i.e., round- trip) and loopback measurement modes in SR networks. Note that one- way and round-trip are referred to in [RFC8762] and are further described in this document because of the introduction of loopback measurement mode in SR networks. The procedures defined in this document are also applicable to measure packet loss in SR networks. The procedure defined in [RFC8762] is used to measure packet loss based on the transmission and reception of the STAMP test packets. The optional STAMP extensions defined in [RFC8972] are used for direct measurement of packet loss in SR networks. The STAMP test packets are transmitted on the same path as the data traffic flow under measurement to measure the delay and packet loss experienced by the data traffic flow. Typically, the STAMP test packets are transmitted along an IP path between a Session-Sender and a Session-Reflector to measure delay and packet loss along that IP path. Matching the forward and reverse direction paths for STAMP test packets, even for directly connected nodes are not guaranteed. It may be desired in SR networks that the same path (same set of links and nodes) between the Session-Sender and Session-Reflector be used for the STAMP test packets in both directions. This is achieved by using the optional STAMP extensions for SR-MPLS and SRv6 networks specified in [I-D.ietf-ippm-stamp-srpm]. The STAMP Session-Reflector uses the return path parameters for the reply test packet from the received STAMP test packet, as described in [I-D.ietf-ippm-stamp-srpm]. This way signaling and maintaining dynamic SR network state for the STAMP sessions on the Session- Reflector are avoided. 3.1. Example STAMP Reference Model An example of a STAMP reference model with some of the typical measurement parameters including the Destination UDP port for STAMP test session is shown in the following Figure 1: Gandhi, et al. Expires 30 November 2023 [Page 6] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 +------------+ | Controller | +------------+ / \ Destination UDP Port / \ Destination UDP Port Authentication Mode / \ Authentication Mode Keychain / \ Keychain Timestamp Format / \ Timestamp Format Packet Loss Type / \ Session-Reflector Mode Delay Measurement Mode / \ v v +-------+ +-------+ | | | | | S1 |==========| R1 | | | | | +-------+ +-------+ STAMP Session-Sender STAMP Session-Reflector Figure 1: Example STAMP Reference Model A Destination UDP port number MUST be selected as described in [RFC8762]. The same Destination UDP port is used for the STAMP test sessions for link and end-to-end SR paths. In this case, the Destination UDP port does not distinguish between the link or end-to- end SR path STAMP test sessions. Example of the Timestamp Format is Precision Time Protocol 64-bit truncated (PTPv2) [IEEE1588] and Network Time Protocol (NTP). By default, the Session-Reflector replies in kind to the timestamp format received in the received Session-Sender test packet, as indicated by the "Z" field in the Error Estimate field as described in [RFC8762]. The Session-Reflector mode can be Stateful or Stateless as defined in [RFC8762]. Example of Delay Measurement Mode is one-way, two-way (i.e., round- trip) and loopback mode as described in this document. Example of Packet Loss Type can be round-trip, near-end (forward direction) and far-end (backward direction) packet loss as defined in [RFC8762]. When using the authentication mode for the STAMP test sessions, the matching Authentication Type (e.g., HMAC-SHA-256) and Keychain MUST be user-configured on STAMP Session-Sender and STAMP Session- Reflector [RFC8762]. Gandhi, et al. Expires 30 November 2023 [Page 7] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 The controller shown in the example reference model is intended for provisioning the STAMP test sessions and not intended for the dynamic signaling of the SR parameters for STAMP test sessions between the STAMP Session-Sender and STAMP Session-Reflector. Note that the YANG data model defined in [I-D.ietf-ippm-stamp-yang] can be used to provision the STAMP Session-Sender and STAMP Session- Reflector and for streaming telemetry of the operational data. 4. Delay Measurement for Links and SR Paths 4.1. Session-Sender Test Packet The content of an example Session-Sender test packet using an IP and UDP header [RFC0768] is shown in Figure 2. The payload contains the Session-Sender test packet defined in Section 3 of [RFC8972] as transmitted in an IP network. Note that [RFC8972] updates the Session-Sender test packet defined in [RFC8762] with optional STAMP Session Identifier (SSID). The SR encapsulation of the STAMP test packet is further described later in this document. +---------------------------------------------------------------+ | IP Header | . Source IP Address = Session-Sender IPv4 or IPv6 Address . . Destination IP Address=Session-Reflector IPv4 or IPv6 Address. . Protocol = UDP . . . +---------------------------------------------------------------+ | UDP Header | . Source Port = Dynamically chosen by Session-Sender . . Destination Port = User-configured Destination Port | 862 . . . +---------------------------------------------------------------+ | Payload = Test Packet as specified in Section 3 of RFC 8972 | . in Figure 1 and Figure 3 . . . +---------------------------------------------------------------+ Figure 2: Example Session-Sender Test Packet 4.1.1. Session-Sender Test Packet for Links The Session-Sender test packet as shown in Figure 2 is transmitted over the link for delay measurement. The local and remote IP addresses of the link are used as Source and Destination Addresses, respectively. For IPv6 links, the link local addresses [RFC7404] can be used in the IPv6 header. The Session-Sender MAY use the local Address Resolution Protocol (ARP) table, Neighbor Solicitation or Gandhi, et al. Expires 30 November 2023 [Page 8] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 other bootstrap method to find the IP address for the links and refresh. SR encapsulation (e.g., adjacency SID of the link) can be added for transmitting the STAMP test packets for links. 4.1.2. Session-Sender Test Packet for SR Paths The delay measurement for end-to-end SR path in an SR network is applicable to both end-to-end SR-MPLS and SRv6 paths including SR Policies and SR Flexible Algorithm IGP path. The Session-Sender (the head-end of the SR Policy, for example) IPv4 or IPv6 address MUST be used as the Source Address in the IP header of the STAMP test packet. The Session-Reflector (the SR Policy endpoint, for example) IPv4 or IPv6 address MUST be used as the Destination Address in the IP header of the STAMP test packet. In the case of SR Policy with Color-Only Destination Steering, with endpoint as unspecified address (the null endpoint is 0.0.0.0 for IPv4 or :: for IPv6 (all bits set to the 0 value)) as defined in Section 8.8.1 of [RFC9256], the loopback address from the range 127/8 for IPv4, or the loopback address ::1/128 for IPv6 [RFC4291] can be used as the ultimate Destination Address in the IP header of the STAMP test packets, respectively. In the case of SR-MPLS Flexible Algorithm IGP path, the STAMP test packets carry the Flexible Algorithm Node SID on the Session- Reflector in the MPLS header. In the case of SRv6 Flexible Algorithm IGP path, the STAMP test packets carry the Flexible Algorithm Node SID on the Session-Sender and Session-Reflector as the Source and Destination Address in the IPv6 header, respectively. 4.1.2.1. Session-Sender Test Packet for SR-MPLS Policies An SR-MPLS Policy may contain a number of Segment Lists (SLs). Each Segment List may contain a number of MPLS Labels. A Session-Sender test packet MUST be transmitted using each Segment List of the SR- MPLS Policy. The content of an example Session-Sender test packet for an end-to-end SR-MPLS Policy is shown in Figure 3. Gandhi, et al. Expires 30 November 2023 [Page 9] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Segment(1) | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Segment(n) | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSID (optional) | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Test Packet as shown in Figure 2 | . . +---------------------------------------------------------------+ Figure 3: Example Session-Sender Test Packet for SR-MPLS Policy The Segment List can be empty in the case of a single-hop SR-MPLS Policy with Implicit NULL label. The Path Segment Identifier (PSID) [I-D.ietf-spring-mpls-path-segment] of an SR-MPLS Policy can be carried in the MPLS header as shown in Figure 3, and can be used for direct measurement as described in Section 6, titled "Direct Measurement for Links and SR Paths". 4.1.2.2. Session-Sender Test Packet for SRv6 Policies An SRv6 Policy may contain a number of Segment Lists. Each Segment List may contain a number of SRv6 SIDs as defined in [RFC8986]. The Segment in the Segment List may be an SRv6 C-SID container as defined in [I-D.draft-ietf-spring-srv6-srh-compression]. A Session-Sender test packet MUST be transmitted using each Segment List of the SRv6 Policy. An SRv6 Policy may contain an SRv6 Segment Routing Header (SRH) carrying a Segment List as described in [RFC8754] and [I-D.draft-ietf-spring-srv6-srh-compression]. The content of an example Session-Sender test packet for an end-to-end SRv6 Policy using an SRH is shown in Figure 4. The SRv6 network programming is described in [RFC8986]. The procedure defined for Upper-Layer (UL) Header processing for SRv6 End SIDs in Section 4.1.1 of [RFC8986] MUST be used to process the IPv6/ UDP header in the received test packets on the Session-Reflector. Gandhi, et al. Expires 30 November 2023 [Page 10] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 +---------------------------------------------------------------+ | IP Header | . Source IP Address = Session-Sender IPv6 Address . . Destination IP Address=Session-Reflector IPv6 Address | . . Segment List[Segments Left] . . Next-Header = 43, Routing Type = SRH (4) . . . +---------------------------------------------------------------+ | SRH as specified in RFC 8754 | . . . Next-Header = UDP (17) . . . +---------------------------------------------------------------+ | UDP Header | . Source Port = Dynamically chosen by Session-Sender . . Destination Port = User-configured Destination Port | 862 . . . +---------------------------------------------------------------+ | Payload = Test Packet as specified in Section 3 of RFC 8972 | . in Figure 1 and Figure 3 . . . +---------------------------------------------------------------+ Figure 4: Example Session-Sender Test Packet for SRv6 Policy The Destination Address may carry SRv6 C-SIDs [I-D.draft-ietf-spring-srv6-srh-compression]. The Segment List (SL) of an SR Policy may be empty and no SRH may be carried. The Path Segment Identifier (PSID) [I-D.ietf-spring-srv6-path-segment] of the SRV6 Policy can be carried in the SRH as shown in Figure 4 and can be used for direct measurement as described in Section 6, titled "Direct Measurement for Links and SR Paths". 4.1.3. Session-Sender Test Packet for Service over SR Path The delay measurement procedure defined in this document for end-to- end SR path is also applicable to VPN services in an SR network for both SR-MPLS and SRv6 data planes. Gandhi, et al. Expires 30 November 2023 [Page 11] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 4.1.3.1. Session-Sender Test Packet for Service over SR-MPLS Path The delay measurement of end-to-end VPN service over SR-MPLS path, the same MPLS label stack as the data packets of the service including the service MPLS label is used by the Session-Sender test packets. The Source Address and Destination Address added in the IP header of the test packets MUST be reachable via the specific IP table lookup associated with the service MPLS label used. 4.1.3.2. Session-Sender Test Packet for Service over SRv6 Path The delay measurement of end-to-end VPN service over SRv6 path, the same IPv6/SRv6 header as the data packets of the service including the service SRv6 SID (for example, End.DT6 SID, End.DT4 SID, etc. defined in [RFC8986]) is used by the Session-Sender test packets. An inner IP header MUST be added in the test packets and the Source Address and Destination Address added in the inner IP header MUST be reachable via the specific IPv4 or IPv6 table lookup associated with the service SRv6 SID. 4.2. Session-Reflector Test Packet The Session-Reflector reply test packet uses the IP/UDP information from the received test packet as shown in Figure 5. The payload contains the Session-Reflector test packet defined in Section 3 of [RFC8972]. +---------------------------------------------------------------+ | IP Header | . Source IP Address = Session-Reflector IPv4 or IPv6 Address . . Destination IP Address . . = Source IP Address from Received Test Packet . . Protocol = UDP . . . +---------------------------------------------------------------+ | UDP Header | . Source Port = As chosen by Session-Reflector . . Destination Port = Source Port from Received Test Packet . . . +---------------------------------------------------------------+ | Payload = Test Packet as specified in Section 3 of RFC 8972 | . in Figure 2 and Figure 4 . . . +---------------------------------------------------------------+ Figure 5: Example Session-Reflector Test Packet Gandhi, et al. Expires 30 November 2023 [Page 12] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 4.2.1. One-Way Measurement Mode In one-way delay measurement mode, a reply test packet as shown in Figure 5 is transmitted by the Session-Reflector, for both links and end-to-end SR Policies. The reply test packet MAY be transmitted on the same path or a different path in the reverse direction. The Session-Sender address may not be reachable via IP route from the Session-Reflector. The Session-Sender in this case MUST send its reachability path information to the Session-Reflector using the Return Path TLV defined in [I-D.ietf-ippm-stamp-srpm]. In this mode, as per Reference Topology, all timestamps T1, T2, T3, and T4 are collected by the STAMP test packets. However, only timestamps T1 and T2 are used to measure one-way delay as (T2 - T1). Note that delay value (T2-T1) is also referred to as near-end (forward direction) one-way delay and delay value (T4-T3) is referred to as far-end (backward direction) one-way delay. The one-way delay measurement mode requires the clocks on the Session-Sender and Session-Reflector to be synchronized. 4.2.2. Two-Way Measurement Mode In two-way (i.e., round-trip) delay measurement mode, a reply test packet as shown in Figure 5 SHOULD be transmitted by the Session- Reflector on the same path in the reverse direction as the forward direction, e.g., on the reverse direction link or associated reverse SR path [I-D.ietf-pce-sr-bidir-path]. In two-way delay measurement mode for links, the Session-Sender can request in the test packet to the Session-Reflector to transmit the reply test packet back on the same link in an ECMP environment. It may use the Control Code Sub-TLV in the Return Path TLV defined in [I-D.ietf-ippm-stamp-srpm]. The Session-Reflector MUST transmit the reply test packet on the same link where the test packet is received when the Control Code Sub-TLV [I-D.ietf-ippm-stamp-srpm] is included in the test packet. In two-way delay measurement mode for end-to-end SR paths, the Session-Sender can request in the test packet to the Session- Reflector to transmit the reply test packet back on a specific reverse path in an ECMP environment. It may use a Segment List sub- TLV in the Return Path TLV defined in [I-D.ietf-ippm-stamp-srpm]. The Session-Reflector MUST transmit the reply test packet on the specified reverse path when the Return Path TLV [I-D.ietf-ippm-stamp-srpm] is included in the test packet. Gandhi, et al. Expires 30 November 2023 [Page 13] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 In this mode, as per Reference Topology, all timestamps T1, T2, T3, and T4 are collected by the test packets. All four timestamps are used to measure two-way delay as ((T4 - T1) - (T3 - T2)). When clock synchronization on the Session-Sender and Session-Reflector nodes is not possible, the one-way delay can be derived using two-way delay divided by two. 4.2.2.1. Session-Reflector Test Packet for SR-MPLS Policies The content of an example Session-Reflector reply test packet transmitted on the same path as the data traffic flow under measurement for two-way delay measurement of an end-to-end SR-MPLS Policy is shown in Figure 6. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Segment(1) | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Segment(n) | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Test Packet as shown in Figure 5 | . . +---------------------------------------------------------------+ Figure 6: Example Session-Reflector Test Packet for SR-MPLS Policy 4.2.2.2. Session-Reflector Test Packet for SRv6 Policies The content of an example Session-Reflector reply test packet transmitted on the same path as the data traffic flow under measurement for two-way delay measurement of an end-to-end SRv6 Policy using an SRH is shown in Figure 7. The procedure defined for Upper-Layer Header processing for SRv6 End SIDs in Section 4.1.1 in [RFC8986] MUST be used to process the IPv6/ UDP header in the received reply test packets on the Session-Sender. Gandhi, et al. Expires 30 November 2023 [Page 14] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 +---------------------------------------------------------------+ | IP Header | . Source IP Address = Session-Reflector IPv6 Address . . Destination IP Address=Session-Sender IPv6 Address | . . Segment List[Segments Left] . . Next-Header = 43, Routing Type = SRH (4) . . . +---------------------------------------------------------------+ | SRH as specified in RFC 8754 | . . . Next-Header = UDP (17) . . . +---------------------------------------------------------------+ | UDP Header | . Source Port = As chosen by Session-Reflector . . Destination Port = Source Port from Received Test Packet . . . +---------------------------------------------------------------+ | Payload = Test Packet as specified in Section 3 of RFC 8972 | . in Figure 2 and Figure 4 . . . +---------------------------------------------------------------+ Figure 7: Example Session-Reflector Test Packet for SRv6 Policy 4.2.3. Loopback Measurement Mode The Session-Sender test packets are transmitted in loopback mode to measure loopback delay of a bidirectional circular path. In this mode, the received Session-Sender test packets MUST NOT be punted out of the fast path in forwarding (i.e., to slow path or control-plane) at the Session-Reflector. In other words, the Session-Reflector does not process them and generate Session-Reflector test packets. This is a new measurement mode, not defined by the STAMP process in [RFC8762]. In this mode, as per Reference Topology, the test packet received back at the Session-Sender retrieves the timestamp T1 from the test packet and adds the received timestamp T4 locally. Both these timestamps are used to measure the loopback delay as (T4 - T1). The one-way delay can be derived using the loopback delay divided by two. In loopback mode, the loopback delay includes the processing delay on the Session-Reflector. The Session-Reflector processing delay component includes only the time required to loop the test packet from the incoming interface to the outgoing interface in the forwarding plane. Gandhi, et al. Expires 30 November 2023 [Page 15] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 4.2.3.1. Loopback Measurement Mode STAMP Packet Processing The Session-Sender MUST set the Destination UDP port to the UDP port it uses to receive the reply test packets (other than UDP port 862). Since the Session-Reflector does not support the STAMP process, the loopback function simply makes the necessary changes to the encapsulation including IP, SR and UDP headers to forward the test packet to the Session-Sender. The typical Session-Reflector test packet is not used in this mode. The loopback function simply returns the received Session-Sender test packet to the Session-Sender without STAMP modifications defined in [RFC8762]. The Session-Sender may use the STAMP Session ID (SSID) field in the received reply test packet or local configuration to identify its test session that uses the loopback mode. At the Session-Sender, the 'Session-Sender Sequence Number', 'Session-Sender Timestamp', 'Session-Sender Error Estimate', and 'Session-Sender TTL' fields in the received Session-Sender test packets are not applicable in this mode and MUST be ignored. 4.2.3.2. Loopback Measurement Mode for Links In the case of loopback mode for links, an inner IP header for return path is added as shown in Figure 9 in the Session-Sender test packets and it MUST set the Destination Address equal to the Session-Sender address. +---------------------------------------------------------------+ | Inner IP Header (Return Path) | . Source IP Address = Session-Sender IP Address . . Destination IP Address = Session-Sender IP Address . . Protocol = UDP . . . +---------------------------------------------------------------+ | UDP Header | . Source Port = Dynamically chosen by Session-Sender . . Destination Port = Source Port . . . +---------------------------------------------------------------+ | Payload = Test Packet as specified in Section 3 of RFC 8972 | . in Figure 1 and Figure 3 . . . +---------------------------------------------------------------+ Figure 8: Example Session-Sender Return Test Packet in Loopback Gandhi, et al. Expires 30 November 2023 [Page 16] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 +---------------------------------------------------------------+ | IP Header | . Source IP Address = Session-Sender IP Address . . Destination IP Address = Session-Reflector IP Address . . . +---------------------------------------------------------------+ | Test Packet as shown in Figure 8 | . . +---------------------------------------------------------------+ Figure 9: Example Session-Sender Test Packet in Loopback 4.2.3.3. Loopback Measurement Mode for SR-MPLS Policies In the case of loopback mode for SR-MPLS paths, the SR-MPLS header can contain the MPLS label stack of the forward SR path only or both the forward and the reverse SR paths. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Segment(1) | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Segment(n) | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Test Packet as shown in Figure 8 | . . +---------------------------------------------------------------+ Figure 10: Example Session-Sender Test Packet for SR-MPLS in Loopback 4.2.3.3.1. Reverse SR-MPLS Path In the case where the packet carries both the forward and the reverse SR paths, in order to receive the return test packet on a specific SR path in an ECMP environment, the MPLS label stack of the specific reverse direction path is used. For example, it may contain the corresponding MPLS label stack of the Reverse SR Policy [I-D.ietf-pce-sr-bidir-path] or the Binding SID of the reverse SR Policy or the node Segment Identifier of the Session-Sender. The IP header of the SR-MPLS Session-Sender test packets MUST set the Destination Address equal to the Session-Sender address as shown in Figure 10. Gandhi, et al. Expires 30 November 2023 [Page 17] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 4.2.3.3.2. Reverse IP/UDP Path In the case of loopback mode for SR-MPLS paths, the SR-MPLS header can contain the MPLS label stack of the forward SR path only. In the case of Penultimate Hop Popping (PHP) for SR-MPLS Policy, the Session-Sender MUST ensure that the STAMP test packets reach the Session-Reflector (for example, by adding an IPv4 header for the forward direction path). The inner IP header for return path of the SR-MPLS Session-Sender test packets MUST set the Destination Address equal to the Session-Sender address as shown in Figure 10. 4.2.3.4. Loopback Measurement Mode for SRv6 Policies In the case of loopback mode for SRv6 paths, the test packet can either contain the Segment List of the forward SRv6 path only or both the forward and the reverse SRv6 paths. 4.2.3.4.1. Reverse SRv6 Path In the case where the packet carries both the forward and the reverse SRv6 paths, in order to receive the return test packet on a specific path in an ECMP environment, the Segment List carries the specific reverse direction SRv6 path. For example, the Segment List may contain the Segment List of the Reverse SR Policy [I-D.ietf-pce-sr-bidir-path] or the Binding SID of the reverse SR Policy or the node Segment Identifier of the Session-Sender. In this case, an inner IPv6 header is not required. In the case of loopback mode for SRv6 paths, the IPv6 Destination Address can also contain the SRv6 C-SID container [I-D.draft-ietf-spring-srv6-srh-compression] for both the forward and the reverse paths. In the case where the packet contains both the forward and the reverse SRv6 paths as the C-SID container in the IPv6 Destination Address, an inner IPv6 header is not required. 4.2.3.4.2. Reverse IP/UDP Path In the case of loopback mode for SRv6 paths, the test packet can contain the Segment List of the forward SRv6 path only. In the case where the packet contains only the forward SRv6 path, an inner IPv6 header (before the UDP header) is added that MUST set the Destination Address equal to the Session-Sender address. In this case, the inner IPv6 return path is used to forward the packet to the Session-Sender. Gandhi, et al. Expires 30 November 2023 [Page 18] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 In the case of loopback mode for SRv6 paths, the IPv6 Destination Address can also contain the SRv6 C-SID container [I-D.draft-ietf-spring-srv6-srh-compression] for the forward path only. In the case of Penultimate Segment Popping (PSP) for SRv6 Policy, the Session-Sender MUST ensure that the STAMP test packets reach the Session-Reflector (for example, by adding the Node SID of the Session-Reflector in the path). 4.3. Delay Measurement for P2MP SR Policies The Point-to-Multipoint (P2MP) SR path that originates from a root node terminates on multiple destinations called leaf nodes (e.g., P2MP SR Policy [I-D.ietf-pim-sr-p2mp-policy]). The procedures for delay and loss measurement described in this document for end-to-end P2P SR Policies are also equally applicable to the P2MP SR Policies. The procedure for one-way measurement is defined as following: * The Session-Sender root node transmits test packets using the Tree-SID defined in [I-D.ietf-pim-sr-p2mp-policy] for the P2MP SR- MPLS Policy as shown in Figure 11. The Session-Sender test packets may contain the replication SID as defined in [I-D.ietf-spring-sr-replication-segment]. * The Destination Address MUST be set to the loopback address from the range 127/8 for IPv4, or the loopback address ::1/128 for IPv6. * Each Session-Reflector leaf node MUST transmit its node address in the Source Address of the reply test packets shown in Figure 5. This allows the Session-Sender root node to identify the Session- Reflector leaf nodes of the P2MP SR Policy. * The P2MP root node measures the delay for each P2MP leaf node individually. * The Return Segment List Sub-TLV defined in [I-D.ietf-ippm-stamp-srpm] is also applicable to the P2MP SR paths. For P2MP SR paths, the TLV may carry the Node Segment Identifier of the Session-Sender in order for the reply test packet to follow an SR path to the Session-Sender. Gandhi, et al. Expires 30 November 2023 [Page 19] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tree-SID | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Test Packet as shown in Figure 2 | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Example Session-Sender Test Packet with Tree-SID for SR-MPLS Policy The considerations for two-way measurement mode (e.g., for co-routed bidirectional SR-MPLS path) and loopback measurement mode for P2MP SR-MPLS Policy are outside the scope of this document. 4.4. Additional STAMP Test Packet Processing Rules The processing rules described in this section are applicable to the STAMP test packets for links and end-to-end SR paths including SR Policies. 4.4.1. TTL The TTL field in the IPv4 and MPLS headers of the Session-Sender and Session-Reflector test packet MUST be set to 255 as per Generalized TTL Security Mechanism (GTSM) [RFC5082]. 4.4.2. IPv6 Hop Limit The Hop Limit (HL) field in the IPv6 and SRH headers of the Session- Sender and Session-Reflector test packet MUST be set to 255 as per Generalized TTL Security Mechanism (GTSM) [RFC5082]. 4.4.3. Router Alert Option The Router Alert IP option (RAO) [RFC2113] MUST NOT be set in the STAMP test packets for links and end-to-end SR paths. Gandhi, et al. Expires 30 November 2023 [Page 20] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 4.4.4. IPv6 Flow Label The Flow Label field in the IPv6 header of the STAMP test packet is set to the value that is used by the data traffic flow on the SR path being measured by the Session-Sender. The Session-Reflector returns the same Flow Label value it received in the STAMP test packet IPv6 header in the STAMP reply test packet, and it can be based on the local policy on the Session-Reflector. 4.4.5. UDP Checksum For IPv4 test packets, where the hardware is not capable of re- computing the UDP checksum or adding checksum complement [RFC7820], the Session-Sender can set the UDP checksum value to 0 [RFC8085]. For IPv6 test packets, where the hardware is not capable of re- computing the UDP checksum or adding checksum complement [RFC7820], the Session-Sender and Session-Reflector can use the procedure defined in [RFC6936] for the UDP checksum for the UDP port being used for STAMP. 5. Packet Loss Measurement for Links and SR Paths The procedure described in Section 4 for delay measurement using STAMP test packets can also be used to detect packet loss for links and end-to-end SR paths. The Sequence Number field in the STAMP test packet is used as described in Section 4 "Theory of Operation" where Stateful and Stateless Session-Reflector operations are defined [RFC8762], to detect round-trip, near-end (forward direction) and far-end (backward direction) packet loss. In the case of Stateless Session-Reflector, only the detection of round-trip packet loss is applicable. In the case of the loopback mode introduced in this document, only the detection of round-trip packet loss is applicable. This method as defined in [RFC8762] can be used for inferred packet loss measurement, however, it provides only approximate view of the data packet loss. 6. Direct Measurement for Links and SR Paths The STAMP "Direct Measurement" TLV (Type 5) defined in [RFC8972] can be used in SR networks for data packet loss measurement. The STAMP test packets with this TLV are transmitted using the procedures described in Section 4 for delay measurement using STAMP test packets to collect the transmit and receive counters of the data packet flow for the links and end-to-end SR paths. Gandhi, et al. Expires 30 November 2023 [Page 21] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 In the case of the Stateless Session-Reflector, the direct measurement is not applicable. In the case of the loopback mode introduced in this document, the direct measurement is not applicable. The PSID carried in the received data packet for the traffic flow under measurement can be used to measure receive data packets (for receive traffic counter) for an end-to-end SR path on the Stateful Session-Reflector. The PSID in the received Session-Sender test packet header can be used to associate the receive traffic counter on the Stateful Session-Reflector to the end-to-end SR path. The STAMP "Direct Measurement" TLV (Type 5) lacks the support to identify the Block Number of the Direct Measurement traffic counters, which is required for the Alternate-Marking Method [RFC9341] for accurate data packet loss metric. 7. STAMP Session State for Links and SR Paths The STAMP test session state monitoring allows to know if the performance measurement test is active or idle. The threshold-based notification for delay and packet loss may not be generated if the delay and packet loss values do not change significantly. For an unambiguous monitoring, the controller needs to distinguish the cases whether the performance measurement is active, or delay and packet loss values are not changing significantly to cross the threshold. The STAMP test session state is initially notified as active as soon as one or more reply test packets are received at the Session-Sender. The STAMP test session state is notified as idle (or failed) when consecutive N number of reply test packets are not received at the Session-Sender after the session state is notified as active, where N (consecutive packet loss count) is a locally provisioned value. The failed state of the STAMP test session on the Session-Sender also indicates that the connectivity verification to the Session-Reflector has failed. In the loopback mode where the Session-Reflector does not generate reply test packets, the connectivity failure on the reverse direction path can cause the return test packets to not reach the Session- Sender. This is also true in the case where the return test packets are generated by the stateless Session-Reflector, e.g., in two-way mode. The stateful Session-Reflector can solve this issue by maintaining the forwarding direction state and signaling the STAMP test session state to the Session-Sender based on the Packet Loss Count, N. This signaling is outside the scope of this document. Gandhi, et al. Expires 30 November 2023 [Page 22] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 8. ECMP Support for SR Policies An SR Policy can have ECMPs between the source and transit nodes, between transit nodes and between transit and destination nodes. Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP paths via transit nodes part of that Anycast group. The test packets SHOULD be transmitted to traverse different ECMP paths to measure end-to-end delay of an SR Policy. Forwarding plane has various hashing functions available to forward packets on specific ECMP paths. The mechanisms described in [RFC8029] and [RFC5884] for handling ECMPs are also applicable to the delay measurement. For SR-MPLS Policy, sweeping of MPLS entropy label [RFC6790] values can be used in Session-Sender test packets and Session-Reflector test packets to take advantage of the hashing function in forwarding plane to influence the ECMP path taken by them. In IPv4 header of the Session-Sender test packets, sweeping of Session-Reflector Address from the range 127/8 can be used to exercise ECMP paths. In this case, both the forward and the return paths MUST be SR-MPLS paths when using the loopback mode. As specified in [RFC6437], Flow Label field in the outer IPv6 header can also be used for sweeping to exercise different IPv6 ECMP paths. 9. Security Considerations The usage of STAMP protocol is intended for deployment in limited domains [RFC8799]. As such, it assumes that a node involved in STAMP protocol operation has previously verified the integrity of the path and the identity of the far-end Session-Reflector. If desired, attacks can be mitigated by performing basic validation and sanity checks, at the Session-Sender, of the counter or timestamp fields in received measurement reply test packets. The minimal state associated with these protocols also limits the extent of measurement disruption that can be caused by a corrupt or invalid packet to a single test cycle. Use of HMAC-SHA-256 in the authenticated mode protects the data integrity of the test packets. SRv6 can use the HMAC protection authentication defined for SRH [RFC8754]. Cryptographic measures may be enhanced by the correct configuration of access-control lists and firewalls. Gandhi, et al. Expires 30 November 2023 [Page 23] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 The security considerations specified in [RFC8762] and [RFC8972] also apply to the procedures described in this document. Specifically, the message integrity protection using HMAC, as defined in Section 4.4 of [RFC8762] also apply to the procedure described in this document. The Security Considerations specified in [I-D.ietf-ippm-stamp-srpm] are also equally applicable to the procedures defined in this document. STAMP uses the well-known UDP port number that could become a target of denial of service (DoS) or could be used to aid man-in-the-middle (MITM) attacks. Thus, the security considerations and measures to mitigate the risk of the attack documented in Section 6 of [RFC8545] equally apply to the procedures in this document. When using the procedures defined in [RFC6936], the security considerations specified in [RFC6936] also apply. 10. IANA Considerations This document does not require any IANA action. 11. References 11.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Gandhi, et al. Expires 30 November 2023 [Page 24] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, March 2020, . [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., and E. Ruffini, "Simple Two-Way Active Measurement Protocol Optional Extensions", RFC 8972, DOI 10.17487/RFC8972, January 2021, . [I-D.ietf-ippm-stamp-srpm] Gandhi, R., Filsfils, C., Voyer, D., Chen, M., Janssens, B., and R. Foote, "Simple TWAMP (STAMP) Extensions for Segment Routing Networks", Work in Progress, Internet- Draft, draft-ietf-ippm-stamp-srpm-12, 29 May 2023, . 11.2. Informative References [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", March 2008. [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, DOI 10.17487/RFC2113, February 1997, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [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, . [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, June 2010, . [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, . Gandhi, et al. Expires 30 November 2023 [Page 25] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, . [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local Addressing inside an IPv6 Network", RFC 7404, DOI 10.17487/RFC7404, November 2014, . [RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)", RFC 7820, DOI 10.17487/RFC7820, March 2016, . [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, . [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., and T. Mizrahi, "Alternate-Marking Method", RFC 9341, DOI 10.17487/RFC9341, December 2022, . [RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", RFC 9350, February 2023, . [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, . [RFC8545] Morton, A., Ed. and G. Mirsky, Ed., "Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP)", RFC 8545, DOI 10.17487/RFC8545, March 2019, . Gandhi, et al. Expires 30 November 2023 [Page 26] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . [RFC9256] Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, July 2022, . [I-D.draft-ietf-spring-srv6-srh-compression] Cheng, W., Filsfils, C., Li, Z., Decraene, B., Cai, D., Voyer, D., Clad, F., and S. Zadok, "Compressed SRv6 Segment List Encoding in SRH", Work in Progress, Internet- Draft, draft-ietf-spring-srv6-srh-compression-04, 31 March 2023, . [I-D.ietf-spring-sr-replication-segment] (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., and Z. Zhang, "SR Replication Segment for Multi-point Service Delivery", Work in Progress, Internet-Draft, draft-ietf-spring-sr-replication-segment-13, 2 March 2023, . [I-D.ietf-pim-sr-p2mp-policy] (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., and Z. Zhang, "Segment Routing Point-to-Multipoint Policy", Work in Progress, Internet-Draft, draft-ietf-pim- sr-p2mp-policy-06, 13 April 2023, . [I-D.ietf-spring-mpls-path-segment] Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, "Path Segment in MPLS Based Segment Routing Network", Work in Progress, Internet-Draft, draft-ietf-spring-mpls-path- Gandhi, et al. Expires 30 November 2023 [Page 27] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 segment-08, 28 September 2022, . [I-D.ietf-spring-srv6-path-segment] Li, C., Cheng, W., Chen, M., Dhody, D., and Y. Zhu, "Path Segment for SRv6 (Segment Routing in IPv6)", Work in Progress, Internet-Draft, draft-ietf-spring-srv6-path- segment-06, 4 May 2023, . [I-D.ietf-pce-sr-bidir-path] Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, "Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths", Work in Progress, Internet-Draft, draft-ietf- pce-sr-bidir-path-11, 8 March 2023, . [I-D.ietf-ippm-stamp-yang] Mirsky, G., Min, X., and W. S. Luo, "Simple Two-way Active Measurement Protocol (STAMP) Data Model", Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-11, 13 March 2023, . [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 for the discussions on the use-cases for Performance Measurement in Segment Routing. The authors would also like to thank Greg Mirsky, Gyan Mishra, Xie Jingrong, Amit Dhamija, and Mike Koldychev for reviewing this document and providing useful comments and suggestions. Patrick Khordoc and Radu Valceanu have helped improve the mechanisms described in this document. Authors' Addresses Rakesh Gandhi (editor) Cisco Systems, Inc. Canada Email: rgandhi@cisco.com Gandhi, et al. Expires 30 November 2023 [Page 28] Internet-Draft Using Simple TWAMP for Segment Routing May 2023 Clarence Filsfils Cisco Systems, Inc. Email: cfilsfil@cisco.com Daniel Voyer Bell Canada Email: daniel.voyer@bell.ca Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com Bart Janssens Colt Email: Bart.Janssens@colt.net Richard Foote Nokia Email: footer.foote@nokia.com Gandhi, et al. Expires 30 November 2023 [Page 29]