idnits 2.17.1 draft-ietf-ippm-stamp-srpm-02.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 (9 September 2021) is 960 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-13 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-10 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-stamp-yang-09 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: 13 March 2022 D. Voyer 6 Bell Canada 7 M. Chen 8 Huawei 9 B. Janssens 10 Colt 11 R. Foote 12 Nokia 13 9 September 2021 15 Simple TWAMP (STAMP) Extensions for Segment Routing Networks 16 draft-ietf-ippm-stamp-srpm-02 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 13 March 2022. 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 (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 62 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 64 2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 3 65 3. Destination Node Address TLV . . . . . . . . . . . . . . . . 4 66 4. Return Path TLV . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.1. Return Path Sub-TLVs . . . . . . . . . . . . . . . . . . 6 68 4.1.1. Return Path Control Code Sub-TLV . . . . . . . . . . 6 69 4.1.2. Return Address Sub-TLV . . . . . . . . . . . . . . . 7 70 4.1.3. Return Segment List Sub-TLVs . . . . . . . . . . . . 8 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 7.2. Informative References . . . . . . . . . . . . . . . . . 12 76 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 Segment Routing (SR) leverages the source routing paradigm for 82 Software Defined Networks (SDNs). SR is applicable to both 83 Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) forwarding 84 planes [RFC8402]. SR Policies as defined in 85 [I-D.ietf-spring-segment-routing-policy] are used to steer traffic 86 through a specific, user-defined paths using a stack of Segments. 87 Built-in SR Performance Measurement (PM) is one of the essential 88 requirements to provide Service Level Agreements (SLAs). 90 The Simple Two-Way Active Measurement Protocol (STAMP) provides 91 capabilities for the measurement of various performance metrics in IP 92 networks [RFC8762] without the use of a control channel to pre-signal 93 session parameters. [RFC8972] defines optional extensions for STAMP. 94 Note that the YANG data model defined in [I-D.ietf-ippm-stamp-yang] 95 can be used to provision the STAMP Session-Sender and STAMP Session- 96 Reflector. 98 The STAMP test packets are transmitted along an IP path between a 99 Session-Sender and a Session-Reflector to measure performance delay 100 and packet loss along that IP path. It may be desired in SR networks 101 that the same path (same set of links and nodes) between the Session- 102 Sender and Session-Reflector is used for the STAMP test packets in 103 both directions. This is achieved by using the STAMP [RFC8762] 104 extensions for SR-MPLS and SRv6 networks specified in this document 105 by augmenting the optional extensions defined in [RFC8972]. 107 2. Conventions Used in This Document 109 2.1. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119] [RFC8174] 114 when, and only when, they appear in all capitals, as shown here. 116 2.2. Abbreviations 118 MPLS: Multiprotocol Label Switching. 120 PM: Performance Measurement. 122 SID: Segment ID. 124 SL: Segment List. 126 SR: Segment Routing. 128 SR-MPLS: Segment Routing with MPLS forwarding plane. 130 SRv6: Segment Routing with IPv6 forwarding plane. 132 SSID: STAMP Session Identifier. 134 STAMP: Simple Two-Way Active Measurement Protocol. 136 2.3. Reference Topology 138 In the reference topology shown below, the STAMP Session-Sender S1 139 initiates a STAMP test packet and the STAMP Session-Reflector R1 140 transmits a reply test packet. The reply test packet may be 141 transmitted to the Session-Sender S1 on the same path (same set of 142 links and nodes) or a different path in the reverse direction from 143 the path taken towards the Session-Reflector R1. 145 The nodes S1 and R1 may be connected via a link or an SR path 146 [RFC8402]. The link may be a physical interface, virtual link, or 147 Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member link. The 148 SR path may be an SR Policy [I-D.ietf-spring-segment-routing-policy] 149 on node S1 (called head-end) with destination to node R1 (called 150 tail-end). 152 T1 T2 153 / \ 154 +-------+ Test Packet +-------+ 155 | | - - - - - - - - - ->| | 156 | S1 |=====================| R1 | 157 | |<- - - - - - - - - - | | 158 +-------+ Reply Test Packet +-------+ 159 \ / 160 T4 T3 162 STAMP Session-Sender STAMP Session-Reflector 164 Reference Topology 166 3. Destination Node Address TLV 168 The Session-Sender may need to transmit test packets to the Session- 169 Reflector with a different destination address not matching an 170 address on the Session-Reflector e.g. when the STAMP test packet is 171 encapsulated by a tunneling protocol or an MPLS Segment List with 172 IPv4 address from 127/8 range or Segment Routing Header (SRH) with 173 IPv6 address ::1/128. For testing ECMPs, the Session-Sender may 174 select different IPv4 addresses from 127/8 range or select different 175 Flow Label values for IPv6. In an error condition, the STAMP test 176 packet may not reach the intended Session-Reflector, an un-intended 177 node may transmit reply test packets resulting in reporting of 178 invalid measurement metrics. 180 [RFC8972] defines STAMP test packets that can include one or more 181 optional TLVs. In this document, Destination Node Address TLV (Type 182 TBA1) is defined for STAMP test packet [RFC8972] and has the 183 following format shown in Figure 1: 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 |STAMP TLV Flags| Type=TBA1 | Length | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 . Address . 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Figure 1: Destination Node Address TLV Format 194 The Length field is used to decide the Address Family of the Address. 196 The STAMP TLV Flags are set using the procedures described in 197 [RFC8972]. 199 The Destination Node Address TLV is optional. The Destination Node 200 Address TLV indicates the address of the intended Session-Reflector 201 node of the test packet. When Session-Sender test packet destination 202 address is different than the actual Session-Reflector address, the 203 actual Session-Reflector address MUST be transmitted to the Session- 204 Reflector with a Destination Node Address TLV. 206 The Session-Reflector that supports this TLV, MUST transmit reply 207 test packet with Error D (Wrong Destination) in the STAMP TLV Flags 208 field if it is not the intended destination of the received Session- 209 Sender test packet. 211 D (Wrong Destination): A one-bit flag at position TBA3. A Session- 212 Sender MUST set the D flag to 0 before transmitting an extended STAMP 213 test packet. A Session-Reflector MUST set the D flag to 1 if the 214 Session-Reflector determined that it is not the intended Destination 215 as identified in the Destination Node Address TLV. Otherwise, the 216 Session-Reflector MUST set the D flag in the Reply test packet to 0. 218 Note that the Destination Node Address TLV is applicable to the P2P 219 SR paths only. 221 4. Return Path TLV 223 For end-to-end SR paths, the Session-Reflector may need to transmit 224 the reply test packet on a specific return path. The Session-Sender 225 can request this in the test packet to the Session-Reflector using a 226 Return Path TLV. With this TLV carried in the Session-Sender test 227 packet, signaling and maintaining dynamic SR network state for the 228 STAMP sessions on the Session-Reflector are avoided. 230 For links, the Session-Reflector may need to transmit the reply test 231 packet on the same incoming link in the reverse direction. The 232 Session-Sender can request this in the test packet to the Session- 233 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 Session-Sender test packet. The format of the Return Path TLV is 239 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 Session-Sender MUST only insert 256 one Return Path TLV in the STAMP test packet. The Session-Reflector 257 that supports this TLV, MUST only process the first Return Path TLV 258 in the test packet and ignore other Return Path TLVs if present, and 259 it MUST NOT add Return Path TLV in the reply test packet. The 260 Session-Reflector that supports this TLV MUST reply using the Return 261 Path received in the Session-Sender test packet. Otherwise, the 262 procedure defined in [RFC8762] is followed by the Session-Reflector. 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 Session-Reflector that supports this TLV, MUST transmit 276 reply test packet using the return path information specified in the 277 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 * Type (value 1): Return Path Control Code. The Session-Sender can 289 request the Session-Reflector to transmit the reply test packet 290 based on the flags defined in the Control Code field. 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 |STAMP TLV Flags| Type | Length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Control Code | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Figure 3: Control Code Sub-TLV in Return Path TLV 302 Control Code Flags (32-bit): Defined as follows. 304 0x0: No Reply Requested. 306 0x1: Reply Requested on the Same Link. 308 When Control Code flag is set to 0x0 in the Session-Sender test 309 packet, the Session-Reflector does not transmit reply test packet to 310 the Session-Sender and terminates the STAMP test packet. Only the 311 one-way measurement is applicable in this case. Optionally, the 312 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 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. All other Return Path 320 Sub-TLVs are ignored in this case. 322 4.1.2. Return Address Sub-TLV 324 The STAMP reply test packet may be transmitted to the Session-Sender 325 to a different destination address on the Session-Sender using Return 326 Path TLV. For this, the Session-Sender can specify in the test 327 packet the receiving destination node address for the Session- 328 Reflector reply test packet. When transmitting the STAMP test packet 329 to a different destination address, the Session-Sender MUST follow 330 the procedure defined in Section 4.3 of [RFC8762]. 332 The format of the Return Address Sub-TLV is shown in Figure 4. The 333 Address Family field indicates the type of the address, and it SHALL 334 be set to one of the assigned values in the "IANA Address Family 335 Numbers" registry. The Type of the Return Address Sub-TLV is defined 336 as following: 338 * Type (value 2): Return Address. Destination node address of the 339 Session-Reflector reply test packet different than the Source 340 Address in the Session-Sender test packet. 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 |STAMP TLV Flags| Type | Length | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Reserved | Address Family | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 . Address . 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Figure 4: Return Address Sub-TLV in Return Path TLV 354 4.1.3. Return Segment List Sub-TLVs 356 The format of the Segment List Sub-TLVs in the Return Path TLV is 357 shown in Figure 5. The segment entries MUST be in network order. 358 The Segment List Sub-TLV can be one of the following Types: 360 * Type (value 3): SR-MPLS Label Stack of the Return Path 362 * Type (value 4): SRv6 Segment List of the Return Path 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 |STAMP TLV Flags| Type | Length | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Segment(1) | 370 . . 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 . . 373 . . 374 . . 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Segment(n) (bottom of stack) | 377 . . 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Figure 5: Segment List Sub-TLV in Return Path TLV 381 An SR-MPLS Label Stack Sub-TLV may carry only Binding SID 382 [I-D.ietf-pce-binding-label-sid] of the Return SR-MPLS Policy. 384 An SRv6 Segment List Sub-TLV may carry only Binding SID 385 [I-D.ietf-pce-binding-label-sid] of the Return SRv6 Policy. 387 The Session-Sender MUST only insert one Segment List Return Path Sub- 388 TLV in the test packet. The Session-Reflector MUST only process the 389 first Segment List Return Path Sub-TLV in the test packet and ignore 390 other Segment List Return Path Sub-TLVs if present. 392 Note that in addition to the P2P SR paths, the Return Segment List 393 Sub-TLV is also applicable to the P2MP SR paths. For example, for 394 P2MP SR paths, it may only carry the Node Segment Identifier of the 395 Session-Sender in order for the reply test packet to follow an SR 396 path to the Session-Sender. 398 5. Security Considerations 400 The usage of STAMP protocol is intended for deployment in limited 401 domains [RFC8799]. As such, it assumes that a node involved in STAMP 402 protocol operation has previously verified the integrity of the path 403 and the identity of the far-end Session-Reflector. 405 If desired, attacks can be mitigated by performing basic validation 406 and sanity checks, at the Session-Sender, of the timestamp fields in 407 received reply test packets. The minimal state associated with these 408 protocols also limits the extent of measurement disruption that can 409 be caused by a corrupt or invalid test packet to a single test cycle. 411 The security considerations specified in [RFC8762] and [RFC8972] also 412 apply to the extensions defined in this document. Specifically, the 413 message integrity protection using HMAC, as defined in [RFC8762] 414 Section 4.4, also apply to the procedure described in this document. 416 STAMP uses the well-known UDP port number that could become a target 417 of denial of service (DoS) or could be used to aid man-in-the-middle 418 (MITM) attacks. Thus, the security considerations and measures to 419 mitigate the risk of the attack documented in Section 6 of [RFC8545] 420 equally apply to the STAMP extensions in this document. 422 The STAMP extensions defined in this document may be used for 423 potential "proxying" attacks. For example, a Session-Sender may 424 specify a return path that has a destination different from that of 425 the Session-Sender. But normally, such attacks will not happen in an 426 SR domain where the Session-Senders and Session-Reflectors belong to 427 the same domain. In order to prevent using the extension defined in 428 this document for proxying any possible attacks, the return path has 429 destination to the same node where the forward path is from. The 430 Session-Reflector may drop the Session-Sender test packet when it 431 cannot determine whether the Return Path has the destination to the 432 Session-Sender. That means, the Session-Sender should choose a 433 proper source address according to the specified Return Path to help 434 the Session-Reflector to make that decision. 436 6. IANA Considerations 438 IANA has created the "STAMP TLV Types" registry for [RFC8972]. IANA 439 is requested to allocate a value for the Destination Address TLV Type 440 and a value for the Return Path TLV Type from the IETF Review TLV 441 range of the same registry. 443 +=======+==============================+===============+ 444 | Value | Description | Reference | 445 +=======+==============================+===============+ 446 | TBA1 | Destination Node Address TLV | This document | 447 +-------+------------------------------+---------------+ 448 | TBA2 | Return Path TLV | This document | 449 +-------+------------------------------+---------------+ 451 Table 1: STAMP TLV Types 453 IANA is requested to create a sub-registry for "Return Path Sub-TLV 454 Type". All code points in the range 1 through 175 in this registry 455 shall be allocated according to the "IETF Review" procedure as 456 specified in [RFC8126]. Code points in the range 176 through 239 in 457 this registry shall be allocated according to the "First Come First 458 Served" procedure as specified in [RFC8126]. Remaining code points 459 are allocated according to Table 2: 461 +===========+=========================+===============+ 462 | Value | Description | Reference | 463 +===========+=========================+===============+ 464 | 1 - 175 | IETF Review | This document | 465 +-----------+-------------------------+---------------+ 466 | 176 - 239 | First Come First Served | This document | 467 +-----------+-------------------------+---------------+ 468 | 240 - 251 | Experimental Use | This document | 469 +-----------+-------------------------+---------------+ 470 | 252 - 254 | Private Use | This document | 471 +-----------+-------------------------+---------------+ 473 Table 2: Return Path Sub-TLV Type Registry 475 IANA is requested to allocate the values for the following Sub-TLV 476 Types from this registry. 478 +======+========================================+===============+ 479 | Type | Description | Reference | 480 +======+========================================+===============+ 481 | 0 | Reserved | This document | 482 +------+----------------------------------------+---------------+ 483 | 1 | Return Path Control Code | This document | 484 +------+----------------------------------------+---------------+ 485 | 2 | Return Address | This document | 486 +------+----------------------------------------+---------------+ 487 | 3 | SR-MPLS Label Stack of the Return Path | This document | 488 +------+----------------------------------------+---------------+ 489 | 4 | SRv6 Segment List of the Return Path | This document | 490 +------+----------------------------------------+---------------+ 491 | 255 | Reserved | This document | 492 +------+----------------------------------------+---------------+ 494 Table 3: Return Path Sub-TLV Types 496 IANA has created the "STAMP TLV Flags" subregistry. IANA is 497 requested to allocate the following bit position in the "STAMP TLV 498 Flags" subregistry. 500 +==============+========+===================+===============+ 501 | Bit Position | Symbol | Description | Reference | 502 +==============+========+===================+===============+ 503 | TBA3 | D | Wrong Destination | This document | 504 +--------------+--------+-------------------+---------------+ 506 Table 4: STAMP TLV Flags 508 7. References 510 7.1. Normative References 512 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 513 Requirement Levels", BCP 14, RFC 2119, 514 DOI 10.17487/RFC2119, March 1997, 515 . 517 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 518 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 519 May 2017, . 521 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 522 Two-Way Active Measurement Protocol", RFC 8762, 523 DOI 10.17487/RFC8762, March 2020, 524 . 526 [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 527 and E. Ruffini, "Simple Two-Way Active Measurement 528 Protocol Optional Extensions", RFC 8972, 529 DOI 10.17487/RFC8972, January 2021, 530 . 532 7.2. Informative References 534 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 535 Decraene, B., Litkowski, S., and R. Shakir, "Segment 536 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 537 July 2018, . 539 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 540 Writing an IANA Considerations Section in RFCs", BCP 26, 541 RFC 8126, DOI 10.17487/RFC8126, June 2017, 542 . 544 [RFC8545] Morton, A., Ed. and G. Mirsky, Ed., "Well-Known Port 545 Assignments for the One-Way Active Measurement Protocol 546 (OWAMP) and the Two-Way Active Measurement Protocol 547 (TWAMP)", RFC 8545, DOI 10.17487/RFC8545, March 2019, 548 . 550 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 551 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 552 . 554 [I-D.ietf-spring-segment-routing-policy] 555 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 556 P. Mattes, "Segment Routing Policy Architecture", Work in 557 Progress, Internet-Draft, draft-ietf-spring-segment- 558 routing-policy-13, 28 May 2021, 559 . 562 [I-D.ietf-pce-binding-label-sid] 563 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 564 and C. L. (editor), "Carrying Binding Label/Segment 565 Identifier in PCE-based Networks.", Work in Progress, 566 Internet-Draft, draft-ietf-pce-binding-label-sid-10, 10 567 July 2021, . 570 [I-D.ietf-ippm-stamp-yang] 571 Mirsky, G., Min, X., and W. S. Luo, "Simple Two-way Active 572 Measurement Protocol (STAMP) Data Model", Work in 573 Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-09, 574 12 July 2021, . 577 [IEEE802.1AX] 578 IEEE Std. 802.1AX, "IEEE Standard for Local and 579 metropolitan area networks - Link Aggregation", November 580 2008. 582 Acknowledgments 584 The authors would like to thank Thierry Couture for the discussions 585 on the use-cases for Performance Measurement in Segment Routing. The 586 authors would also like to thank Greg Mirsky, Mike Koldychev, Gyan 587 Mishra, Tianran Zhou, Al Mortons, Reshad Rahman, Zhenqiang Li, Frank 588 Brockners, and Cheng Li for providing comments and suggestions. 590 Authors' Addresses 592 Rakesh Gandhi (editor) 593 Cisco Systems, Inc. 594 Canada 596 Email: rgandhi@cisco.com 598 Clarence Filsfils 599 Cisco Systems, Inc. 601 Email: cfilsfil@cisco.com 603 Daniel Voyer 604 Bell Canada 606 Email: daniel.voyer@bell.ca 608 Mach(Guoyi) Chen 609 Huawei 611 Email: mach.chen@huawei.com 612 Bart Janssens 613 Colt 615 Email: Bart.Janssens@colt.net 617 Richard Foote 618 Nokia 620 Email: footer.foote@nokia.com