idnits 2.17.1 draft-ietf-ippm-stamp-srpm-00.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 04, 2021) is 1056 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-11 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-08 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-stamp-yang-07 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM Working Group R. Gandhi, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: December 6, 2021 D. Voyer 6 Bell Canada 7 M. Chen 8 Huawei 9 B. Janssens 10 Colt 11 R. Foote 12 Nokia 13 June 04, 2021 15 Simple TWAMP (STAMP) Extensions for Segment Routing Networks 16 draft-ietf-ippm-stamp-srpm-00 18 Abstract 20 Segment Routing (SR) leverages the source routing paradigm. SR is 21 applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 22 (SRv6) forwarding planes. This document specifies RFC 8762 (Simple 23 Two-Way Active Measurement Protocol (STAMP)) extensions for SR 24 networks, for both SR-MPLS and SRv6 forwarding planes by augmenting 25 the optional extensions defined in RFC 8972. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 6, 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 63 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 65 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 3 66 3. Destination Node Address TLV . . . . . . . . . . . . . . . . 4 67 4. Return Path TLV . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.1. Return Path Sub-TLVs . . . . . . . . . . . . . . . . . . 6 69 4.1.1. Return Path Control Code Sub-TLV . . . . . . . . . . 7 70 4.1.2. Return Address Sub-TLV . . . . . . . . . . . . . . . 7 71 4.1.3. Return Segment List Sub-TLVs . . . . . . . . . . . . 8 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 7.2. Informative References . . . . . . . . . . . . . . . . . 12 77 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 Segment Routing (SR) leverages the source routing paradigm and 83 greatly simplifies network operations for Software Defined Networks 84 (SDNs). SR is applicable to both Multiprotocol Label Switching (SR- 85 MPLS) and IPv6 (SRv6) forwarding planes [RFC8402]. SR Policies as 86 defined in [I-D.ietf-spring-segment-routing-policy] are used to steer 87 traffic through a specific, user-defined paths using a stack of 88 Segments. Built-in SR Performance Measurement (PM) is one of the 89 essential requirements to provide Service Level Agreements (SLAs). 91 The Simple Two-way Active Measurement Protocol (STAMP) provides 92 capabilities for the measurement of various performance metrics in IP 93 networks [RFC8762] without the use of a control channel to pre-signal 94 session parameters. [RFC8972] defines optional extensions for STAMP. 95 Note that the YANG data model defined in [I-D.ietf-ippm-stamp-yang] 96 can be used to provision the STAMP Session-Sender and STAMP Session- 97 Reflector. 99 The STAMP test packets are transmitted along an IP path between a 100 Session-Sender and a Session-Reflector to measure performance delay 101 and packet loss along that IP path. It may be desired in SR networks 102 that the same path (same set of links and nodes) between the Session- 103 Sender and Session-Reflector is used for the STAMP test packets in 104 both directions. This is achieved by using the STAMP [RFC8762] 105 extensions for SR-MPLS and SRv6 networks specified in this document 106 by augmenting the optional extensions defined in [RFC8972]. 108 2. Conventions Used in This Document 110 2.1. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119] [RFC8174] 115 when, and only when, they appear in all capitals, as shown here. 117 2.2. Abbreviations 119 MPLS: Multiprotocol Label Switching. 121 PM: Performance Measurement. 123 SID: Segment ID. 125 SL: Segment List. 127 SR: Segment Routing. 129 SR-MPLS: Segment Routing with MPLS forwarding plane. 131 SRv6: Segment Routing with IPv6 forwarding plane. 133 SSID: STAMP Session Identifier. 135 STAMP: Simple Two-way Active Measurement Protocol. 137 2.3. Reference Topology 139 In the reference topology shown below, the STAMP Session-Sender R1 140 initiates a STAMP test packet and the STAMP Session-Reflector R3 141 transmits a reply test packet. The reply test packet may be 142 transmitted to the STAMP Session-Sender R1 on the same path (same set 143 of links and nodes) or a different path in the reverse direction from 144 the path taken towards the Session-Reflector. 146 The nodes R1 and R3 may be connected via a link or an SR path 147 [RFC8402]. The link may be a physical interface, virtual link, or 148 Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member link. The 149 SR path may be an SR Policy [I-D.ietf-spring-segment-routing-policy] 150 on node R1 (called head-end) with destination to node R3 (called 151 tail-end). 153 T1 T2 154 / \ 155 +-------+ Test Packet +-------+ 156 | | - - - - - - - - - ->| | 157 | R1 |=====================| R3 | 158 | |<- - - - - - - - - - | | 159 +-------+ Reply Test Packet +-------+ 160 \ / 161 T4 T3 163 STAMP Session-Sender STAMP Session-Reflector 165 Reference Topology 167 3. Destination Node Address TLV 169 The STAMP Session-Sender may need to transmit test packets to the 170 STAMP Session-Reflector with a different destination address not 171 matching an address on the Session-Reflector e.g. when the STAMP test 172 packet is encapsulated by a tunneling protocol or an MPLS Segment 173 List with IPv4 address from 127/8 range or Segment Routing Header 174 (SRH) with an IPv6 address. Here, Session-Sender may select an IPv4 175 address from 127/8 range or select a Flow Label in case of IPv6 176 address ::1/128 for testing ECMPs. In an error condition, the STAMP 177 test packet may not reach the intended STAMP Session-Reflector, an 178 un-intended node may transmit reply test packets resulting in 179 reporting of invalid measurement metrics. 181 [RFC8972] defines STAMP test packets that can include one or more 182 optional TLVs. In this document, Destination Node Address TLV (Type 183 TBA1) is defined for STAMP test packet [RFC8972] and has the 184 following format shown in Figure 1: 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 |STAMP TLV Flags| Type=TBA1 | Length | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 . Address . 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 1: Destination Node Address TLV Format 196 The Length field is used to decide the Address Family of the Address. 198 The STAMP TLV Flags are set using the procedures described in 199 [RFC8972]. 201 The Destination Node Address TLV is optional. The Destination Node 202 Address TLV indicates the address of the intended Session-Reflector 203 node of the test packet. 205 The STAMP Session-Reflector that supports this TLV, MUST transmit 206 reply test packet with Error D (Wrong Destination) in the STAMP TLV 207 Flags field if it is not the intended destination of the received 208 Session-Sender test packet. 210 D (Wrong Destination): A one-bit flag. A Session-Sender MUST set the 211 D flag to 0 before transmitting an extended STAMP test packet. A 212 Session-Reflector MUST set the D flag to 1 if the Session-Reflector 213 determined that it is not the intended Destination as identified in 214 the Destination Node Address TLV. Otherwise, the Session-Reflector 215 MUST set the D flag in the Reply test packet to 0. 217 Note that the Destination Node Address TLV is applicable to the P2P 218 SR paths only. 220 4. Return Path TLV 222 For end-to-end SR paths, the STAMP Session-Reflector may need to 223 transmit the reply test packet on a specific return path. The STAMP 224 Session-Sender can request this in the test packet to the STAMP 225 Session-Reflector using a Return Path TLV. With this TLV carried in 226 the STAMP Session-Sender test packet, signaling and maintaining 227 dynamic SR network state for the STAMP sessions on the Session- 228 Reflector are avoided. 230 For links, the STAMP Session-Reflector may need to transmit the reply 231 test packet on the same incoming link in the reverse direction. The 232 STAMP Session-Sender can request this in the test packet to the STAMP 233 Session-Reflector using a Return Path TLV. 235 [RFC8972] defines STAMP test packets that can include one or more 236 optional TLVs. In this document, the TLV Type (value TBA2) is 237 defined for the Return Path TLV that carries the return path for the 238 STAMP Session-Sender test packet. The format of the Return Path TLV 239 is shown in Figure 2: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 |STAMP TLV Flags| Type=TBA2 | Length | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Return Path Sub-TLVs | 247 . . 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Figure 2: Return Path TLV 252 The STAMP TLV Flags are set using the procedures described in 253 [RFC8972]. 255 The Return Path TLV is optional. The STAMP Session-Sender MUST only 256 insert one Return Path TLV in the STAMP test packet. The STAMP 257 Session-Reflector that supports this TLV, MUST only process the first 258 Return Path TLV in the test packet and ignore other Return Path TLVs 259 if present, and it MUST NOT add Return Path TLV in the reply test 260 packet. The Session-Reflector that supports this TLV MUST reply 261 using the Return Path received in the Session-Sender test packet. 262 Otherwise, the procedure defined in [RFC8762] is followed. 264 4.1. Return Path Sub-TLVs 266 The Return Path TLV contains one or more Sub-TLVs to carry the 267 information for the requested return path. A Return Path Sub-TLV can 268 carry Return Path Control Code, Return Path IP Address or Return Path 269 Segment List. 271 The STAMP Sub-TLV Flags are set using the procedures described in 272 [RFC8972]. 274 When Return Path Sub-TLV is present in the Session-Sender test 275 packet, the STAMP Session-Reflector that supports this TLV, MUST 276 transmit reply test packet using the return path information 277 specified in the Return Path Sub-TLV. 279 A Return Path TLV MUST NOT contain both Control Code Sub-TLV as well 280 as Return Address or Return Segment List Sub-TLV. 282 4.1.1. Return Path Control Code Sub-TLV 284 The format of the Return Path Control Code Sub-TLV is shown in 285 Figure 3. The Type of the Return Path Control Code Sub-TLV is 286 defined as following: 288 o Type (value 1): Return Path Control Code. The STAMP Session- 289 Sender can request the STAMP Session-Reflector to transmit the 290 reply test packet based on the flags defined in the Control Code 291 field. 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 |STAMP TLV Flags| Type | Length | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Control Code | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Figure 3: Control Code Sub-TLV in Return Path TLV 303 Control Code Flags (32-bit): Defined as follows. 305 0x0: No Reply Requested. 307 0x1: Reply Requested on the Same Link. 309 When Control Code flag is set to 0x0 in the STAMP Session-Sender test 310 packet, the Session-Reflector does not transmit reply test packet to 311 the Session-Sender and terminates the STAMP test packet. Optionally, 312 the Session-Reflector may locally stream performance metrics via 313 telemetry using the information from the received test packet. All 314 other Return Path Sub-TLVs are ignored in this case. 316 When Control Code flag is set to 0x1 in the STAMP Session-Sender test 317 packet, the Session-Reflector transmits the reply test packet over 318 the same incoming link where the test packet is received in the 319 reverse direction towards the Session-Sender. 321 4.1.2. Return Address Sub-TLV 323 The STAMP reply test packet may be transmitted to the Session-Sender 324 to a different destination address on the Session-Sender using Return 325 Path TLV. For this, the Session-Sender can specify in the test 326 packet the receiving destination node address for the Session- 327 Reflector reply test packet. When transmitting the STAMP test packet 328 to a different destination address, the Session-Sender MUST follow 329 the procedure defined in Section 4.3 of [RFC8762]. 331 The format of the Return Address Sub-TLV is shown in Figure 4. The 332 Address Family field indicates the type of the address, and it SHALL 333 be set to one of the assigned values in the "IANA Address Family 334 Numbers" registry. The Type of the Return Address Sub-TLV is defined 335 as following: 337 o Type (value 2): Return Address. Destination node address of the 338 STAMP Session-Reflector reply test packet different than the 339 Source Address in the Session-Sender test packet. 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 |STAMP TLV Flags| Type | Length | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Reserved | Address Family | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 . Address . 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Figure 4: Return Address Sub-TLV in Return Path TLV 353 4.1.3. Return Segment List Sub-TLVs 355 The format of the Segment List Sub-TLVs in the Return Path TLV is 356 shown in Figure 5. The segment entries MUST be in network order. 357 The Segment List Sub-TLV can be one of the following Types: 359 o Type (value 3): SR-MPLS Label Stack of the Return Path 361 o Type (value 4): SRv6 Segment List of the Return Path 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 |STAMP TLV Flags| Type | Length | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Segment(1) | 368 . . 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 . . 371 . . 372 . . 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Segment(n) (bottom of stack) | 375 . . 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 Figure 5: Segment List Sub-TLV in Return Path TLV 380 An SR-MPLS Label Stack Sub-TLV may carry only Binding SID 381 [I-D.ietf-pce-binding-label-sid] of the Return SR-MPLS Policy. 383 An SRv6 Segment List Sub-TLV may carry only Binding SID 384 [I-D.ietf-pce-binding-label-sid] of the Return SRv6 Policy. 386 The STAMP Session-Sender MUST only insert one Segment List Return 387 Path Sub-TLV in the test packet. The STAMP Session-Reflector MUST 388 only process the first Segment List Return Path Sub-TLV in the test 389 packet and ignore other Segment List Return Path Sub-TLVs if present. 391 Note that in addition to the P2P SR paths, the Return Segment List 392 Sub-TLV is also applicable to the P2MP SR paths. For example, for 393 P2MP SR paths, it may only carry the Node Segment Identifier of the 394 Session-Sender in order for the reply test packet to follow an SR 395 path to the Session-Sender. 397 5. Security Considerations 399 The performance measurement is intended for deployment in well- 400 managed private and service provider networks. As such, it assumes 401 that a node involved in a measurement operation has previously 402 verified the integrity of the path and the identity of the STAMP 403 Session-Reflector. 405 If desired, attacks can be mitigated by performing basic validation 406 and sanity checks, at the STAMP Session-Sender, of the timestamp 407 fields in received reply test packets. The minimal state associated 408 with these protocols also limits the extent of measurement disruption 409 that can be caused by a corrupt or invalid test packet to a single 410 test cycle. 412 The security considerations specified in [RFC8762] and [RFC8972] also 413 apply to the extensions defined in this document. 415 The STAMP extensions defined in this document may be used for 416 potential "proxying" attacks. For example, a Session-Sender may 417 specify a return path that has a destination different from that of 418 the Session-Sender. But normally, such attacks will not happen in an 419 SR domain where the Session-Senders and Session-Reflectors belong to 420 the same domain. In order to prevent using the extension defined in 421 this document for proxying any possible attacks, the return path has 422 destination to the same node where the forward path is from. The 423 Session-Reflector may drop the Session-Sender test packet when it 424 cannot determine whether the Return Path has the destination to the 425 Session-Sender. That means, when sending reply test packet, the 426 Session-Sender should choose a proper source address according the 427 specified Return Path to help the Session-Reflector to make the 428 decision. 430 6. IANA Considerations 432 IANA will create a "STAMP TLV Type" registry for [RFC8972]. IANA is 433 requested to allocate a value for the following Destination Address 434 TLV Type from the IETF Review TLV range of this registry. This TLV 435 is to be carried in the STAMP test packets. 437 o Type TBA1: Destination Node Address TLV 439 IANA is also requested to allocate a value for the following Return 440 Path TLV Type from the IETF Review TLV range of the same registry. 441 This TLV is to be carried in the STAMP test packets. 443 o Type TBA2: Return Path TLV 445 IANA is requested to create a sub-registry for "Return Path Sub-TLV 446 Type". All code points in the range 1 through 175 in this registry 447 shall be allocated according to the "IETF Review" procedure as 448 specified in [RFC8126]. Code points in the range 176 through 239 in 449 this registry shall be allocated according to the "First Come First 450 Served" procedure as specified in [RFC8126]. Remaining code points 451 are allocated according to Table 1: 453 +-----------+--------------+---------------+ 454 | Value | Description | Reference | 455 +-----------+--------------+---------------+ 456 | 0 | Reserved | This document | 457 | 1 - 175 | Unassigned | This document | 458 | 176 - 239 | Unassigned | This document | 459 | 240 - 251 | Experimental | This document | 460 | 252 - 254 | Private Use | This document | 461 | 255 | Reserved | This document | 462 +-----------+--------------+---------------+ 464 Table 1: Return Path Sub-TLV Type Registry 466 IANA is requested to allocate the values for the following Sub-TLV 467 Types from this registry. 469 o Type (value 1): Return Path Control Code 471 o Type (value 2): Return Address 473 o Type (value 3): SR-MPLS Label Stack of the Return Path 475 o Type (value 4): SRv6 Segment List of the Return Path 477 7. References 479 7.1. Normative References 481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 482 Requirement Levels", BCP 14, RFC 2119, 483 DOI 10.17487/RFC2119, March 1997, 484 . 486 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 487 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 488 May 2017, . 490 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 491 Two-Way Active Measurement Protocol", RFC 8762, 492 DOI 10.17487/RFC8762, March 2020, 493 . 495 [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 496 and E. Ruffini, "Simple Two-Way Active Measurement 497 Protocol Optional Extensions", RFC 8972, 498 DOI 10.17487/RFC8972, January 2021, 499 . 501 7.2. Informative References 503 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 504 Decraene, B., Litkowski, S., and R. Shakir, "Segment 505 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 506 July 2018, . 508 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 509 Writing an IANA Considerations Section in RFCs", BCP 26, 510 RFC 8126, DOI 10.17487/RFC8126, June 2017, 511 . 513 [I-D.ietf-spring-segment-routing-policy] 514 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 515 P. Mattes, "Segment Routing Policy Architecture", draft- 516 ietf-spring-segment-routing-policy-11 (work in progress), 517 April 2021. 519 [I-D.ietf-pce-binding-label-sid] 520 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 521 and C. Li, "Carrying Binding Label/Segment Identifier in 522 PCE-based Networks.", draft-ietf-pce-binding-label-sid-08 523 (work in progress), April 2021. 525 [I-D.ietf-ippm-stamp-yang] 526 Mirsky, G., Min, X., and W. S. Luo, "Simple Two-way Active 527 Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- 528 stamp-yang-07 (work in progress), March 2021. 530 [IEEE802.1AX] 531 IEEE Std. 802.1AX, "IEEE Standard for Local and 532 metropolitan area networks - Link Aggregation", November 533 2008. 535 Acknowledgments 537 The authors would like to thank Thierry Couture for the discussions 538 on the use-cases for Performance Measurement in Segment Routing. The 539 authors would also like to thank Greg Mirsky, Mike Koldychev, Gyan 540 Mishra, Tianran Zhou, and Cheng Li for providing comments and 541 suggestions. 543 Authors' Addresses 544 Rakesh Gandhi (editor) 545 Cisco Systems, Inc. 546 Canada 548 Email: rgandhi@cisco.com 550 Clarence Filsfils 551 Cisco Systems, Inc. 553 Email: cfilsfil@cisco.com 555 Daniel Voyer 556 Bell Canada 558 Email: daniel.voyer@bell.ca 560 Mach(Guoyi) Chen 561 Huawei 563 Email: mach.chen@huawei.com 565 Bart Janssens 566 Colt 568 Email: Bart.Janssens@colt.net 570 Richard Foote 571 Nokia 573 Email: footer.foote@nokia.com