idnits 2.17.00 (12 Aug 2021) /tmp/idnits22987/draft-ietf-spring-stamp-srpm-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (1 February 2022) is 102 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-ietf-ippm-stamp-srpm-02 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-14 == Outdated reference: A later version (-07) exists of draft-ietf-spring-sr-replication-segment-06 == Outdated reference: A later version (-04) exists of draft-ietf-pim-sr-p2mp-policy-03 == Outdated reference: A later version (-09) exists of draft-ietf-pce-sr-bidir-path-08 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group R. Gandhi, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: 5 August 2022 D. Voyer 6 Bell Canada 7 M. Chen 8 Huawei 9 B. Janssens 10 Colt 11 R. Foote 12 Nokia 13 1 February 2022 15 Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing 16 Networks 17 draft-ietf-spring-stamp-srpm-03 19 Abstract 21 Segment Routing (SR) leverages the source routing paradigm. SR is 22 applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 23 (SRv6) data planes. This document describes procedures for 24 Performance Measurement in SR networks using the mechanisms defined 25 in RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) and 26 its optional extensions defined in RFC 8972 and further augmented in 27 draft-ietf-ippm-stamp-srpm. The procedure described is applicable to 28 SR-MPLS and SRv6 data planes and is used for both links and end-to- 29 end SR paths including SR Policies. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 5 August 2022. 48 Copyright Notice 50 Copyright (c) 2022 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 66 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 67 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 68 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 4 69 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Example STAMP Reference Model . . . . . . . . . . . . . . 6 71 4. Delay Measurement for Links and SR Paths . . . . . . . . . . 7 72 4.1. Session-Sender Test Packet . . . . . . . . . . . . . . . 7 73 4.1.1. Session-Sender Test Packet for Links . . . . . . . . 8 74 4.1.2. Session-Sender Test Packet for SR Paths . . . . . . . 8 75 4.2. Session-Reflector Test Packet . . . . . . . . . . . . . . 10 76 4.2.1. One-Way Measurement Mode . . . . . . . . . . . . . . 11 77 4.2.2. Two-Way Measurement Mode . . . . . . . . . . . . . . 11 78 4.2.3. Loopback Measurement Mode . . . . . . . . . . . . . . 13 79 4.3. Delay Measurement for P2MP SR Policies . . . . . . . . . 15 80 4.4. Additional STAMP Test Packet Processing Rules . . . . . . 16 81 4.4.1. TTL . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 4.4.2. IPv6 Hop Limit . . . . . . . . . . . . . . . . . . . 16 83 4.4.3. Router Alert Option . . . . . . . . . . . . . . . . . 16 84 4.4.4. UDP Checksum . . . . . . . . . . . . . . . . . . . . 16 85 4.4.5. Destination Node Address . . . . . . . . . . . . . . 16 86 5. Packet Loss Measurement for Links and SR Paths . . . . . . . 17 87 6. Direct Measurement for Links and SR Paths . . . . . . . . . . 17 88 7. STAMP Session State for Links and SR Paths . . . . . . . . . 17 89 8. ECMP Support for SR Policies . . . . . . . . . . . . . . . . 18 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 94 11.2. Informative References . . . . . . . . . . . . . . . . . 20 95 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 98 1. Introduction 100 Segment Routing (SR) leverages the source routing paradigm and 101 greatly simplifies network operations for Software Defined Networks 102 (SDNs). SR is applicable to both Multiprotocol Label Switching (SR- 103 MPLS) and IPv6 (SRv6) data planes [RFC8402]. SR takes advantage of 104 the Equal-Cost Multipaths (ECMPs) between source and transit nodes, 105 between transit nodes and between transit and destination nodes. SR 106 Policies as defined in [I-D.ietf-spring-segment-routing-policy] are 107 used to steer traffic through a specific, user-defined paths using a 108 stack of Segments. A comprehensive SR Performance Measurement (PM) 109 toolset is one of the essential requirements to measure network 110 performance to provide Service Level Agreements (SLAs). 112 The Simple Two-Way Active Measurement Protocol (STAMP) provides 113 capabilities for the measurement of various performance metrics in IP 114 networks [RFC8762] without the use of a control channel to pre-signal 115 session parameters. [RFC8972] defines optional extensions, in the 116 form of TLVs, for STAMP. [I-D.ietf-ippm-stamp-srpm] augments that 117 framework to define STAMP extensions for SR networks. 119 This document describes procedures for Performance Measurement in SR 120 networks using the mechanisms defined in STAMP [RFC8762] and its 121 optional extensions defined in [RFC8972] and further augmented in 122 [I-D.ietf-ippm-stamp-srpm]. The procedure described is applicable to 123 SR-MPLS and SRv6 data planes and is used for both links and end-to- 124 end SR paths including SR Policies [RFC8402]. 126 2. Conventions Used in This Document 128 2.1. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119] [RFC8174] 133 when, and only when, they appear in all capitals, as shown here. 135 2.2. Abbreviations 137 BSID: Binding Segment ID. 139 DM: Delay Measurement. 141 ECMP: Equal Cost Multi-Path. 143 HL: Hop Limit. 145 HMAC: Hashed Message Authentication Code. 147 LM: Loss Measurement. 149 MPLS: Multiprotocol Label Switching. 151 NTP: Network Time Protocol. 153 OWAMP: One-Way Active Measurement Protocol. 155 PM: Performance Measurement. 157 PSID: Path Segment Identifier. 159 PTP: Precision Time Protocol. 161 SHA: Secure Hash Algorithm. 163 SID: Segment ID. 165 SL: Segment List. 167 SR: Segment Routing. 169 SRH: Segment Routing Header. 171 SR-MPLS: Segment Routing with MPLS data plane. 173 SRv6: Segment Routing with IPv6 data plane. 175 SSID: STAMP Session Identifier. 177 STAMP: Simple Two-Way Active Measurement Protocol. 179 TC: Traffic Class. 181 TTL: Time To Live. 183 2.3. Reference Topology 185 In the Reference Topology shown below, the STAMP Session-Sender S1 186 initiates a STAMP test packet and the STAMP Session-Reflector R1 187 transmits a reply STAMP test packet. The reply test packet may be 188 transmitted to the STAMP Session-Sender S1 on the same path (same set 189 of links and nodes) or a different path in the reverse direction from 190 the path taken towards the Session-Reflector. 192 The nodes S1 and R1 may be connected via a link or an SR path 193 [RFC8402]. The link may be a physical interface, virtual link, or 194 Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member link. The 195 SR path may be an SR Policy [I-D.ietf-spring-segment-routing-policy] 196 on node S1 (called head-end) with destination to node R1 (called 197 tail-end). 199 T1 T2 200 / \ 201 +-------+ Test Packet +-------+ 202 | | - - - - - - - - - ->| | 203 | S1 |=====================| R1 | 204 | |<- - - - - - - - - - | | 205 +-------+ Reply Test Packet +-------+ 206 \ / 207 T4 T3 209 STAMP Session-Sender STAMP Session-Reflector 211 Reference Topology 213 3. Overview 215 For performance measurement in SR networks, the STAMP Session-Sender 216 and Session-Reflector can use the base test packets defined 217 [RFC8762]. The test packets defined in [RFC8972], however, are 218 preferred because of the extensions being used in SR environments. 219 The STAMP test packets MUST be encapsulated to be transmitted on a 220 desired path under measurement. The STAMP test packets are 221 encapsulated using IP/UDP header and may use Destination UDP port 862 222 [RFC8762]. In this document, the STAMP test packets using IP/UDP 223 header are considered for SR networks, where the STAMP test packets 224 are further encapsulated with an SR header. 226 The STAMP test packets are used in one-way, two-way (i.e. round-trip) 227 and loopback measurement modes. Note that one-way and round-trip are 228 referred to in [RFC8762] and are further described in this document 229 because of the introduction of loopback measurement mode in SR 230 networks. The procedures defined in this document are also used to 231 measure packet loss in SR networks. 233 The procedure defined in [RFC8762] is used to measure packet loss 234 based on the transmission and reception of the STAMP test packets. 235 The optional STAMP extensions defined in [RFC8972] are used for 236 direct measurement of packet loss in SR networks. 238 The STAMP test packets are transmitted on the same path as the data 239 traffic flow under measurement to measure the delay and packet loss 240 experienced by the data traffic flow. 242 Typically, the STAMP test packets are transmitted along an IP path 243 between a Session-Sender and a Session-Reflector to measure delay and 244 packet loss along that IP path. Matching the forward and reverse 245 direction paths for STAMP test packets, even for directly connected 246 nodes is not guaranteed. 248 It may be desired in SR networks that the same path (same set of 249 links and nodes) between the Session-Sender and Session-Reflector be 250 used for the STAMP test packets in both directions. This is achieved 251 by using the optional STAMP extensions for SR-MPLS and SRv6 networks 252 specified in [I-D.ietf-ippm-stamp-srpm]. The STAMP Session-Reflector 253 uses the return path parameters for the reply test packet from the 254 received STAMP test packet, as described in 255 [I-D.ietf-ippm-stamp-srpm]. This way signaling and maintaining 256 dynamic SR network state for the STAMP sessions on the Session- 257 Reflector are avoided. 259 3.1. Example STAMP Reference Model 261 An example of a STAMP reference model with some of the typical 262 measurement parameters including the Destination UDP port for STAMP 263 test session is shown in the following Figure 1: 265 +------------+ 266 | Controller | 267 +------------+ 268 / \ 269 Destination UDP Port / \ Destination UDP Port 270 Authentication Mode / \ Authentication Mode 271 Key-chain / \ Key-chain 272 Timestamp Format / \ Timestamp Format 273 Packet Loss Type / \ Session-Reflector Mode 274 Delay Measurement Mode / \ 275 v v 276 +-------+ +-------+ 277 | | | | 278 | S1 |==========| R1 | 279 | | | | 280 +-------+ +-------+ 282 STAMP Session-Sender STAMP Session-Reflector 284 Figure 1: Example STAMP Reference Model 286 A Destination UDP port number MUST be selected as described in 287 [RFC8762]. The same Destination UDP port can be used for STAMP test 288 sessions for link and end-to-end SR paths. In this case, the 289 Destination UDP port does not distinguish between link or end-to-end 290 SR path measurements. 292 Example of the Timestamp Format is Precision Time Protocol 64-bit 293 truncated (PTPv2) [IEEE1588] and Network Time Protocol (NTP). By 294 default, the Session-Reflector replies in kind to the timestamp 295 format received in the received Session-Sender test packet, as 296 indicated by the "Z" field in the Error Estimate field as described 297 in [RFC8762]. 299 The Session-Reflector mode can be Stateful or Stateless as defined in 300 [RFC8762]. 302 Example of Delay Measurement Mode is one-way, two-way (i.e. round- 303 trip) and loopback mode as described in this document. 305 Example of Packet Loss Type can be round-trip, near-end (forward) and 306 far-end (backward) packet loss as defined in [RFC8762]. 308 When using the authenticated mode for the STAMP test sessions, the 309 matching Authentication Type (e.g. HMAC-SHA-256) and Key-chain MUST 310 be user-configured on STAMP Session-Sender and STAMP Session- 311 Reflector [RFC8762]. 313 The controller shown in the example reference model is not intended 314 for the dynamic signaling of the SR parameters for STAMP test 315 sessions between the STAMP Session-Sender and STAMP Session- 316 Reflector. 318 Note that the YANG data model defined in [I-D.ietf-ippm-stamp-yang] 319 can be used to provision the STAMP Session-Sender and STAMP Session- 320 Reflector. 322 4. Delay Measurement for Links and SR Paths 324 4.1. Session-Sender Test Packet 326 The content of an example Session-Sender test packet using an UDP 327 header [RFC0768] is shown in Figure 2. The payload contains the 328 Session-Sender test packet defined in Section 3 of [RFC8972] as 329 transmitted in an IP network. The SR encapsulation of the STAMP test 330 packet is further described later in this document. 332 +---------------------------------------------------------------+ 333 | IP Header | 334 . Source IP Address = Session-Sender IPv4 or IPv6 Address . 335 . Destination IP Address=Session-Reflector IPv4 or IPv6 Address. 336 . Protocol = UDP . 337 . . 338 +---------------------------------------------------------------+ 339 | UDP Header | 340 . Source Port = As chosen by Session-Sender . 341 . Destination Port = User-configured Destination Port | 862 . 342 . . 343 +---------------------------------------------------------------+ 344 | Payload = Test Packet as specified in Section 3 of RFC 8972 | 345 . in Figure 1 and Figure 3 . 346 . . 347 +---------------------------------------------------------------+ 349 Figure 2: Example Session-Sender Test Packet 351 4.1.1. Session-Sender Test Packet for Links 353 The Session-Sender test packet as shown in Figure 2 is transmitted 354 over the link under delay measurement. The local and remote IP 355 addresses of the link are used as Source and Destination Addresses, 356 respectively. For IPv6 links, the link local addresses [RFC7404] can 357 be used in the IPv6 header. The Session-Sender MAY use the local 358 Address Resolution Protocol (ARP) table, Neighbor Solicitation or 359 other bootstrap method to find the IP address for the links and 360 refresh. SR encapsulation (e.g. adjacency SID of the link) can be 361 added for transmitting the STAMP test packets for links. 363 4.1.2. Session-Sender Test Packet for SR Paths 365 The delay measurement for end-to-end SR path in an SR network is 366 applicable to both end-to-end SR-MPLS and SRv6 paths including SR 367 Policies. 369 The Session-Sender (the head-end of the SR Policy) IPv4 or IPv6 370 address MUST be used as the Source Address in the IP header of the 371 STAMP test packet. The Session-Reflector (the SR Policy endpoint) 372 IPv4 or IPv6 address MUST be used as the Destination Address in the 373 IP header of the STAMP test packet. 375 In the case of Color-Only Destination Steering, with IPv4 endpoint of 376 0.0.0.0 or IPv6 endpoint of ::0 377 [I-D.ietf-spring-segment-routing-policy], the loopback address from 378 the range 127/8 for IPv4, or the loopback address ::1/128 for IPv6 379 [RFC4291] can be used as the Session-Reflector Address, respectively. 381 4.1.2.1. Session-Sender Test Packet for SR-MPLS Policies 383 An SR-MPLS Policy may contain a number of Segment Lists (SLs). A 384 Session-Sender test packet MUST be transmitted for each Segment List 385 of the SR-MPLS Policy. The content of an example Session-Sender test 386 packet for an end-to-end SR-MPLS Policy is shown in Figure 3. 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Segment(1) | TC |S| TTL | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 . . 394 . . 395 . . 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Segment(n) | TC |S| TTL | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | PSID | TC |S| TTL | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Test Packet as shown in Figure 2 | 402 . . 403 +---------------------------------------------------------------+ 405 Figure 3: Example Session-Sender Test Packet for SR-MPLS Policy 407 The Segment List can be empty in case of a single-hop SR-MPLS Policy 408 with Implicit NULL label. 410 The Path Segment Identifier (PSID) 411 [I-D.ietf-spring-mpls-path-segment] of an SR-MPLS Policy can be 412 carried in the MPLS header as shown in Figure 3, and can be used for 413 direct measurement as described in Section 6, titled "Direct 414 Measurement for Links and SR Paths". 416 4.1.2.2. Session-Sender Test Packet for SRv6 Policies 418 An SRv6 Policy may contain a number of Segment Lists. Each Segment 419 List may contain a number of SRv6 SIDs as defined in [RFC8986] and 420 [I-D.filsfils-spring-net-pgm-extension-srv6-usid]. A Session-Sender 421 test packet MUST be transmitted for each Segment List of the SRv6 422 Policy. An SRv6 Policy may contain an SRv6 Segment Routing Header 423 (SRH) carrying a Segment List as described in [RFC8754]. The content 424 of an example Session-Sender test packet for an end-to-end SRv6 425 Policy using an SRH is shown in Figure 4. 427 The SRv6 network programming is described in [RFC8986]. The 428 procedure defined for Upper-Layer Header processing for SRv6 End SIDs 429 in Section 4.1.1 in [RFC8986] MUST be used to process the IPv6/UDP 430 header in the received test packets on the Session-Reflector. 432 +---------------------------------------------------------------+ 433 | IP Header | 434 . Source IP Address = Session-Sender IPv6 Address . 435 . Destination IP Address = Destination IPv6 Address . 436 . Next-Header = SRH (43) . 437 . . 438 +---------------------------------------------------------------+ 439 | SRH as specified in RFC 8754 | 440 . . 441 . Next-Header = UDP (17) . 442 . . 443 +---------------------------------------------------------------+ 444 | UDP Header | 445 . Source Port = As chosen by Session-Sender . 446 . Destination Port = User-configured Destination Port | 862 . 447 . . 448 +---------------------------------------------------------------+ 449 | Payload = Test Packet as specified in Section 3 of RFC 8972 | 450 . in Figure 1 and Figure 3 . 451 . . 452 +---------------------------------------------------------------+ 454 Figure 4: Example Session-Sender Test Packet for SRv6 Policy 456 The Segment List (SL) may be empty and no SRH is carried in that 457 case. 459 The Path Segment Identifier (PSID) 460 [I-D.ietf-spring-srv6-path-segment] of the SRV6 Policy can be carried 461 in the SRH as shown in Figure 4 and can be used for direct 462 measurement as described in Section 6, titled "Direct Measurement for 463 Links and SR Paths". 465 4.2. Session-Reflector Test Packet 467 The Session-Reflector reply test packet uses the IP/UDP information 468 from the received test packet as shown in Figure 5. The payload 469 contains the Session-Reflector test packet defined in Section 3 of 470 [RFC8972]. 472 +---------------------------------------------------------------+ 473 | IP Header | 474 . Source IP Address = Session-Reflector IPv4 or IPv6 Address . 475 . Destination IP Address . 476 . = Source IP Address from Received Test Packet . 477 . Protocol = UDP . 478 . . 479 +---------------------------------------------------------------+ 480 | UDP Header | 481 . Source Port = As chosen by Session-Reflector . 482 . Destination Port = Source Port from Received Test Packet . 483 . . 484 +---------------------------------------------------------------+ 485 | Payload = Test Packet as specified in Section 3 of RFC 8972 | 486 . in Figure 2 and Figure 4 . 487 . . 488 +---------------------------------------------------------------+ 490 Figure 5: Example Session-Reflector Test Packet 492 4.2.1. One-Way Measurement Mode 494 In one-way delay measurement mode, a reply test packet as shown in 495 Figure 5 is transmitted by the Session-Reflector, for both links and 496 end-to-end SR Policies. The reply test packet MAY be transmitted on 497 the same path or a different path in the reverse direction. 499 The Session-Sender address may not be reachable via IP route from the 500 Session-Reflector. The Session-Sender in this case MUST send its 501 reachability path information to the Session-Reflector using the 502 Return Path TLV defined in [I-D.ietf-ippm-stamp-srpm]. 504 In this mode, as per Reference Topology, all timestamps T1, T2, T3, 505 and T4 are collected by the STAMP test packets. However, only 506 timestamps T1 and T2 are used to measure one-way delay as (T2 - T1). 507 The one-way delay measurement mode requires the clocks on the 508 Session-Sender and Session-Reflector to be synchronized. 510 4.2.2. Two-Way Measurement Mode 512 In two-way (i.e. round-trip) delay measurement mode, a reply test 513 packet as shown in Figure 5 SHOULD be transmitted by the Session- 514 Reflector on the same path in the reverse direction as the forward 515 direction, e.g. on the reverse direction link or associated reverse 516 SR path [I-D.ietf-pce-sr-bidir-path]. 518 For two-way delay measurement mode for links, the Session-Reflector 519 MUST transmit the reply test packet on the same link where the test 520 packet is received when the Control Code Sub-TLV 521 [I-D.ietf-ippm-stamp-srpm] is included in the test packet. The 522 Session-Sender can request in the test packet to the Session- 523 Reflector to transmit the reply test packet back on the same link 524 using the Control Code Sub-TLV in the Return Path TLV defined in 525 [I-D.ietf-ippm-stamp-srpm]. 527 For two-way delay measurement mode for end-to-end SR paths, the 528 Session-Reflector MUST transmit the reply test packet on a specific 529 reverse path when the Return Path TLV [I-D.ietf-ippm-stamp-srpm] is 530 included in the test packet. The Session-Sender can request in the 531 test packet to the Session-Reflector to transmit the reply test 532 packet back on a given reverse path using a Segment List sub-TLV in 533 the Return Path TLV defined in [I-D.ietf-ippm-stamp-srpm]. 535 In this mode, as per Reference Topology, all timestamps T1, T2, T3, 536 and T4 are collected by the test packets. All four timestamps are 537 used to measure two-way delay as ((T4 - T1) - (T3 - T2)). When clock 538 synchronization on the Session-Sender and Session-Reflector nodes is 539 not possible, the one-way delay can be derived using two-way delay 540 divided by two. 542 4.2.2.1. Session-Reflector Test Packet for SR-MPLS Policies 544 The content of an example Session-Reflector reply test packet 545 transmitted on the same path as the data traffic flow under 546 measurement for two-way delay measurement of an end-to-end SR-MPLS 547 Policy is shown in Figure 6. 549 0 1 2 3 550 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 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Segment(1) | TC |S| TTL | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 . . 555 . . 556 . . 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Segment(n) | TC |S| TTL | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Test Packet as shown in Figure 5 | 561 . . 562 +---------------------------------------------------------------+ 564 Figure 6: Example Session-Reflector Test Packet for SR-MPLS Policy 566 4.2.2.2. Session-Reflector Test Packet for SRv6 Policies 568 The content of an example Session-Reflector reply test packet 569 transmitted on the same path as the data traffic flow under 570 measurement for two-way delay measurement of an end-to-end SRv6 571 Policy using an SRH is shown in Figure 7. 573 The procedure defined for Upper-Layer Header processing for SRv6 End 574 SIDs in Section 4.1.1 in [RFC8986] MUST be used to process the IPv6/ 575 UDP header in the received reply test packets on the Session-Sender. 577 +---------------------------------------------------------------+ 578 | IP Header | 579 . Source IP Address = Session-Reflector IPv6 Address . 580 . Destination IP Address = Destination IPv6 Address . 581 . Next-Header = SRH (43) . 582 . . 583 +---------------------------------------------------------------+ 584 | SRH as specified in RFC 8754 | 585 . . 586 . Next-Header = UDP (17) . 587 . . 588 +---------------------------------------------------------------+ 589 | UDP Header | 590 . Source Port = As chosen by Session-Reflector . 591 . Destination Port = Source Port from Received Test Packet . 592 . . 593 +---------------------------------------------------------------+ 594 | Payload = Test Packet as specified in Section 3 of RFC 8972 | 595 . in Figure 2 and Figure 4 . 596 . . 597 +---------------------------------------------------------------+ 599 Figure 7: Example Session-Reflector Test Packet for SRv6 Policy 601 4.2.3. Loopback Measurement Mode 603 The Session-Sender test packets are transmitted in loopback mode to 604 measure loopback delay of a bidirectional circular path. In this 605 mode, the received Session-Sender test packets MUST NOT be punted out 606 of the fast path in forwarding (i.e. to slow path or control-plane) 607 at the Session-Reflector. In other words, the Session-Reflector does 608 not process them and generate Session-Reflector test packets. This 609 is a new measurement mode, not defined by the STAMP process in 610 [RFC8762]. 612 In this mode, as per Reference Topology, the test packet received 613 back at the Session-Sender retrieves the timestamp T1 from the test 614 packet and adds the received timestamp T4 locally. Both these 615 timestamps are used to measure the loopback delay as (T4 - T1). The 616 one-way delay can be derived using the loopback delay divided by two. 617 In loopback mode, the loopback delay includes the processing delay on 618 the Session-Reflector. The Session-Reflector processing delay 619 component includes only the time required to loop the test packet 620 from the incoming interface to the outgoing interface in the 621 forwarding plane. 623 4.2.3.1. Loopback Measurement Mode STAMP Packet Processing 625 The Session-Sender MUST set the Destination UDP port to the UDP port 626 it uses to receive the reply test packets. Since the Session- 627 Reflector does not support the STAMP process, the loopback function 628 simply makes the necessary changes to the encapsulation including IP 629 and UDP headers to return the test packet to the Session-Sender. The 630 typical Session-Reflector test packet is not used in this mode. The 631 loopback function simply returns the received Session-Sender test 632 packet to the Session-Sender without STAMP modifications defined in 633 [RFC8762]. 635 The Session-Sender may use the STAMP Session ID (SSID) field in the 636 received reply test packet or local configuration to identify its 637 test session that uses the loopback mode. In the received Session- 638 Sender test packet at the Session-Sender, the 'Session-Sender 639 Sequence Number', 'Session-Sender Timestamp', 'Session-Sender Error 640 Estimate', and 'Session-Sender TTL' fields are not present in this 641 mode. 643 4.2.3.2. Loopback Measurement Mode for SR Policies 645 In case of SR-MPLS paths, the SR-MPLS header can contain the MPLS 646 label stack of the forward path only or both forward and the reverse 647 paths. The IP header of the SR-MPLS Session-Sender test packets MUST 648 set the Destination Address equal to the Session-Sender address. 650 In case of SRv6 paths, the SRH can contain the Segment List of the 651 forward path only or both forward and the reverse paths. In the 652 former case, an inner IPv6 header (after SRH and before the UDP 653 header) MUST be added that contains the Destination Address equal to 654 the Session-Sender address. 656 4.3. Delay Measurement for P2MP SR Policies 658 The Point-to-Multipoint (P2MP) SR path that originates from a root 659 node terminates on multiple destinations called leaf nodes (e.g. 660 P2MP SR Policy [I-D.ietf-pim-sr-p2mp-policy]). 662 The procedures for delay and loss measurement described in this 663 document for end-to-end P2P SR Policies are also equally applicable 664 to the P2MP SR Policies. The procedure for one-way measurement is 665 defined as following: 667 * The Session-Sender root node transmits test packets using the 668 Tree-SID defined in [I-D.ietf-pim-sr-p2mp-policy] for the P2MP SR- 669 MPLS Policy as shown in Figure 8. The Session-Sender test packets 670 may contain the replication SID as defined in 671 [I-D.ietf-spring-sr-replication-segment]. 673 * The Destination Address MUST be set to the loopback address from 674 the range 127/8 for IPv4, or the loopback address ::1/128 for 675 IPv6. 677 * Each Session-Reflector leaf node MUST transmit its node address in 678 the Source Address of the reply test packets shown in Figure 5. 679 This allows the Session-Sender root node to identify the Session- 680 Reflector leaf nodes of the P2MP SR Policy. 682 * The P2MP root node measures the delay for each P2MP leaf node 683 individually. 685 0 1 2 3 686 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 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Tree-SID | TC |S| TTL | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 . . 691 . . 692 . . 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Test Packet as shown in Figure 2 | 695 . . 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 Figure 8: Example Session-Sender Test Packet with Tree-SID for 699 SR-MPLS Policy 701 The considerations for two-way measurement mode (e.g. for co-routed 702 bidirectional SR-MPLS path) and loopback measurement mode for P2MP 703 SR-MPLS Policy are outside the scope of this document. 705 4.4. Additional STAMP Test Packet Processing Rules 707 The processing rules described in this section are applicable to the 708 STAMP test packets for links and end-to-end SR paths including SR 709 Policies. 711 4.4.1. TTL 713 The TTL field in the IPv4 and MPLS headers of the Session-Sender and 714 Session-Reflector test packet is set to 255 as per Generalized TTL 715 Security Mechanism (GTSM) [RFC5082]. 717 4.4.2. IPv6 Hop Limit 719 The Hop Limit (HL) field in the IPv6 and SRH headers of the Session- 720 Sender and Session-Reflector test packet is set to 255 as per 721 Generalized TTL Security Mechanism (GTSM) [RFC5082]. 723 4.4.3. Router Alert Option 725 The Router Alert IP option (RAO) [RFC2113] is not set in the STAMP 726 test packets for links and end-to-end SR paths. 728 4.4.4. UDP Checksum 730 For IPv4 test packets, where the hardware is not capable of re- 731 computing the UDP checksum or adding checksum complement [RFC7820], 732 the Session-Sender can set the UDP checksum value to 0 [RFC8085]. 734 For IPv6 test packets, where the hardware is not capable of re- 735 computing the UDP checksum or adding checksum complement [RFC7820], 736 the Session-Sender and Session-Reflector can use the procedure 737 defined in [RFC6936] for the UDP checksum for the UDP port being used 738 for STAMP. 740 4.4.5. Destination Node Address 742 The "Destination Node Address" TLV [I-D.ietf-ippm-stamp-srpm] MUST be 743 carried in the Session-Sender test packet to identify the intended 744 Session-Reflector, when using IPv4 Session-Reflector Address from 745 127/8 range, (e.g. when the STAMP test packet is encapsulated by a 746 tunneling protocol or an MPLS Segment List) or when using IPv6 747 Session-Reflector Address of ::1/128 (e.g. when the STAMP test packet 748 is encapsulated by an SRH). 750 5. Packet Loss Measurement for Links and SR Paths 752 The procedure described in Section 4 for delay measurement using 753 STAMP test packets can be used to detect (test) packet loss for links 754 and end-to-end SR paths. The Sequence Number field in the STAMP test 755 packet is used as described in Section 4 "Theory of Operation" where 756 Stateful and Stateless Session-Reflector operations are defined 757 [RFC8762], to detect round-trip, near-end (forward) and far-end 758 (backward) packet loss. In the case of the loopback mode introduced 759 in this document, only the round-trip packet loss is applicable. 761 This method can be used for inferred packet loss measurement, 762 however, it provides only approximate view of the data packet loss. 764 6. Direct Measurement for Links and SR Paths 766 The STAMP "Direct Measurement" TLV (Type 5) defined in [RFC8972] can 767 be used in SR networks for data packet loss measurement. The STAMP 768 test packets with this TLV are transmitted using the procedures 769 described in Section 4 to collect the transmit and receive counters 770 of the data flow for the links and end-to-end SR paths. In the case 771 of the loopback mode introduced in this document, the direct 772 measurement is not applicable. 774 The PSID carried in the received data packet for the traffic flow 775 under measurement can be used to measure receive data packets (for 776 receive traffic counter) for an end-to-end SR path on the Session- 777 Reflector. The PSID in the received Session-Sender test packet 778 header can be used to associate the receive traffic counter on the 779 Session-Reflector to the end-to-end SR path. 781 The STAMP "Direct Measurement" TLV (Type 5) lacks the support to 782 identify the Block Number of the Direct Measurement traffic counters, 783 which is required for the Alternate-Marking Method [RFC8321] for 784 accurate data packet loss metric. 786 7. STAMP Session State for Links and SR Paths 788 The STAMP test session state allows to know if the performance 789 measurement test is active or idle. The threshold-based notification 790 may not be generated if the delay values do not change significantly. 791 For an unambiguous monitoring, the controller needs to distinguish 792 the cases whether the performance measurement is active, or delay 793 values are not changing to cross a threshold. 795 The STAMP test session state initially is declared active when one or 796 more reply test packets are received at the Session-Sender. The 797 STAMP test session state is declared idle (or failed) when 798 consecutive N number of reply test packets are not received at the 799 Session-Sender, where N is locally provisioned value. The failed 800 state of the STAMP test session on the Session-Sender also indicates 801 that the connectivity verification to the Session-Reflector has 802 failed. 804 8. ECMP Support for SR Policies 806 An SR Policy can have ECMPs between the source and transit nodes, 807 between transit nodes and between transit and destination nodes. 808 Usage of Anycast SID [RFC8402] by an SR Policy can result in ECMP 809 paths via transit nodes part of that Anycast group. The test packets 810 SHOULD be transmitted to traverse different ECMP paths to measure 811 end-to-end delay of an SR Policy. 813 Forwarding plane has various hashing functions available to forward 814 packets on specific ECMP paths. The mechanisms described in 815 [RFC8029] and [RFC5884] for handling ECMPs are also applicable to the 816 delay measurement. 818 For SR-MPLS Policy, sweeping of MPLS entropy label [RFC6790] values 819 can be used in Session-Sender test packets and Session-Reflector test 820 packets to take advantage of the hashing function in forwarding plane 821 to influence the ECMP path taken by them. 823 In IPv4 header of the Session-Sender test packets, sweeping of 824 Session-Reflector Address from the range 127/8 can be used to 825 exercise ECMP paths. In this case, both the forward and the return 826 paths MUST be SR-MPLS paths when using the loopback mode. 828 As specified in [RFC6437], Flow Label field in the outer IPv6 header 829 can also be used for sweeping to exercise different IPv6 ECMP paths. 831 9. Security Considerations 833 The usage of STAMP protocol is intended for deployment in limited 834 domains [RFC8799]. As such, it assumes that a node involved in STAMP 835 protocol operation has previously verified the integrity of the path 836 and the identity of the far-end Session-Reflector. 838 If desired, attacks can be mitigated by performing basic validation 839 and sanity checks, at the Session-Sender, of the counter or timestamp 840 fields in received measurement reply test packets. The minimal state 841 associated with these protocols also limits the extent of measurement 842 disruption that can be caused by a corrupt or invalid packet to a 843 single test cycle. 845 Use of HMAC-SHA-256 in the authenticated mode protects the data 846 integrity of the test packets. SRv6 can use the the HMAC protection 847 authentication defined for SRH [RFC8754]. Cryptographic measures may 848 be enhanced by the correct configuration of access-control lists and 849 firewalls. 851 The security considerations specified in [RFC8762] and [RFC8972] also 852 apply to the procedures described in this document. Specifically, 853 the message integrity protection using HMAC, as defined in 854 Section 4.4 of [RFC8762] also apply to the procedure described in 855 this document. 857 The Security Considerations specified in [I-D.ietf-ippm-stamp-srpm] 858 are also equally applicable to the procedures defined in this 859 document. 861 STAMP uses the well-known UDP port number that could become a target 862 of denial of service (DoS) or could be used to aid man-in-the-middle 863 (MITM) attacks. Thus, the security considerations and measures to 864 mitigate the risk of the attack documented in Section 6 of [RFC8545] 865 equally apply to the procedures in this document. 867 When using the procedures defined in [RFC6936], the security 868 considerations specified in [RFC6936] also apply. 870 10. IANA Considerations 872 This document does not require any IANA action. 874 11. References 876 11.1. Normative References 878 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 879 DOI 10.17487/RFC0768, August 1980, 880 . 882 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 883 Requirement Levels", BCP 14, RFC 2119, 884 DOI 10.17487/RFC2119, March 1997, 885 . 887 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 888 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 889 RFC 6790, DOI 10.17487/RFC6790, November 2012, 890 . 892 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 893 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 894 May 2017, . 896 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 897 Two-Way Active Measurement Protocol", RFC 8762, 898 DOI 10.17487/RFC8762, March 2020, 899 . 901 [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 902 and E. Ruffini, "Simple Two-Way Active Measurement 903 Protocol Optional Extensions", RFC 8972, 904 DOI 10.17487/RFC8972, January 2021, 905 . 907 [I-D.ietf-ippm-stamp-srpm] 908 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., Janssens, 909 B., and R. Foote, "Simple TWAMP (STAMP) Extensions for 910 Segment Routing Networks", Work in Progress, Internet- 911 Draft, draft-ietf-ippm-stamp-srpm-02, 9 September 2021, 912 . 915 11.2. Informative References 917 [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock 918 Synchronization Protocol for Networked Measurement and 919 Control Systems", March 2008. 921 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 922 DOI 10.17487/RFC2113, February 1997, 923 . 925 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 926 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 927 2006, . 929 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 930 Pignataro, "The Generalized TTL Security Mechanism 931 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 932 . 934 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 935 "Bidirectional Forwarding Detection (BFD) for MPLS Label 936 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 937 June 2010, . 939 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 940 "IPv6 Flow Label Specification", RFC 6437, 941 DOI 10.17487/RFC6437, November 2011, 942 . 944 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 945 for the Use of IPv6 UDP Datagrams with Zero Checksums", 946 RFC 6936, DOI 10.17487/RFC6936, April 2013, 947 . 949 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 950 Addressing inside an IPv6 Network", RFC 7404, 951 DOI 10.17487/RFC7404, November 2014, 952 . 954 [RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way 955 Active Measurement Protocol (OWAMP) and Two-Way Active 956 Measurement Protocol (TWAMP)", RFC 7820, 957 DOI 10.17487/RFC7820, March 2016, 958 . 960 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 961 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 962 Switched (MPLS) Data-Plane Failures", RFC 8029, 963 DOI 10.17487/RFC8029, March 2017, 964 . 966 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 967 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 968 March 2017, . 970 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 971 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 972 "Alternate-Marking Method for Passive and Hybrid 973 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 974 January 2018, . 976 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 977 Decraene, B., Litkowski, S., and R. Shakir, "Segment 978 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 979 July 2018, . 981 [RFC8545] Morton, A., Ed. and G. Mirsky, Ed., "Well-Known Port 982 Assignments for the One-Way Active Measurement Protocol 983 (OWAMP) and the Two-Way Active Measurement Protocol 984 (TWAMP)", RFC 8545, DOI 10.17487/RFC8545, March 2019, 985 . 987 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 988 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 989 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 990 . 992 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 993 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 994 . 996 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 997 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 998 (SRv6) Network Programming", RFC 8986, 999 DOI 10.17487/RFC8986, February 2021, 1000 . 1002 [I-D.filsfils-spring-net-pgm-extension-srv6-usid] 1003 Filsfils, C., Garvia, P. C., Cai, D., Voyer, D., Meilik, 1004 I., Patel, K., Henderickx, W., Jonnalagadda, P., Melman, 1005 D., Liu, Y., and J. Guichard, "Network Programming 1006 extension: SRv6 uSID instruction", Work in Progress, 1007 Internet-Draft, draft-filsfils-spring-net-pgm-extension- 1008 srv6-usid-12, 13 December 2021, 1009 . 1012 [I-D.ietf-spring-segment-routing-policy] 1013 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1014 P. Mattes, "Segment Routing Policy Architecture", Work in 1015 Progress, Internet-Draft, draft-ietf-spring-segment- 1016 routing-policy-14, 25 October 2021, 1017 . 1020 [I-D.ietf-spring-sr-replication-segment] 1021 (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., 1022 and Z. Zhang, "SR Replication Segment for Multi-point 1023 Service Delivery", Work in Progress, Internet-Draft, 1024 draft-ietf-spring-sr-replication-segment-06, 25 October 1025 2021, . 1028 [I-D.ietf-pim-sr-p2mp-policy] 1029 (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., 1030 and Z. Zhang, "Segment Routing Point-to-Multipoint 1031 Policy", Work in Progress, Internet-Draft, draft-ietf-pim- 1032 sr-p2mp-policy-03, 23 August 2021, 1033 . 1036 [I-D.ietf-spring-mpls-path-segment] 1037 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 1038 "Path Segment in MPLS Based Segment Routing Network", Work 1039 in Progress, Internet-Draft, draft-ietf-spring-mpls-path- 1040 segment-07, 20 December 2021, 1041 . 1044 [I-D.ietf-spring-srv6-path-segment] 1045 Li, C., Cheng, W., Chen, M., Dhody, D., and Y. Zhu, "Path 1046 Segment for SRv6 (Segment Routing in IPv6)", Work in 1047 Progress, Internet-Draft, draft-ietf-spring-srv6-path- 1048 segment-03, 27 November 2021, 1049 . 1052 [I-D.ietf-pce-sr-bidir-path] 1053 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 1054 "Path Computation Element Communication Protocol (PCEP) 1055 Extensions for Associated Bidirectional Segment Routing 1056 (SR) Paths", Work in Progress, Internet-Draft, draft-ietf- 1057 pce-sr-bidir-path-08, 9 September 2021, 1058 . 1061 [I-D.ietf-ippm-stamp-yang] 1062 Mirsky, G., Min, X., and W. S. Luo, "Simple Two-way Active 1063 Measurement Protocol (STAMP) Data Model", Work in 1064 Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-09, 1065 12 July 2021, . 1068 [IEEE802.1AX] 1069 IEEE Std. 802.1AX, "IEEE Standard for Local and 1070 metropolitan area networks - Link Aggregation", November 1071 2008. 1073 Acknowledgments 1075 The authors would like to thank Thierry Couture for the discussions 1076 on the use-cases for Performance Measurement in Segment Routing. The 1077 authors would also like to thank Greg Mirsky, Gyan Mishra, Xie 1078 Jingrong, and Mike Koldychev for reviewing this document and 1079 providing useful comments and suggestions. Patrick Khordoc and Radu 1080 Valceanu have helped improve the mechanisms described in this 1081 document. 1083 Authors' Addresses 1085 Rakesh Gandhi (editor) 1086 Cisco Systems, Inc. 1087 Canada 1089 Email: rgandhi@cisco.com 1091 Clarence Filsfils 1092 Cisco Systems, Inc. 1094 Email: cfilsfil@cisco.com 1096 Daniel Voyer 1097 Bell Canada 1099 Email: daniel.voyer@bell.ca 1101 Mach(Guoyi) Chen 1102 Huawei 1104 Email: mach.chen@huawei.com 1106 Bart Janssens 1107 Colt 1109 Email: Bart.Janssens@colt.net 1111 Richard Foote 1112 Nokia 1114 Email: footer.foote@nokia.com