idnits 2.17.1 draft-ietf-ippm-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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 February 2022) is 814 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-14 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-12 == 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: 6 August 2022 D. Voyer 6 Bell Canada 7 M. Chen 8 Huawei 9 B. Janssens 10 Colt 11 R. Foote 12 Nokia 13 2 February 2022 15 Simple TWAMP (STAMP) Extensions for Segment Routing Networks 16 draft-ietf-ippm-stamp-srpm-03 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 6 August 2022. 44 Copyright Notice 46 Copyright (c) 2022 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 Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised 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 . . . . . . . . . . . . . . . . . . . 4 65 3. Destination Node Address TLV . . . . . . . . . . . . . . . . 4 66 4. Return Path TLV . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. Return Path Sub-TLVs . . . . . . . . . . . . . . . . . . 7 68 4.1.1. Return Path Control Code Sub-TLV . . . . . . . . . . 7 69 4.1.2. Return Address Sub-TLV . . . . . . . . . . . . . . . 8 70 4.1.3. Return Segment List Sub-TLVs . . . . . . . . . . . . 8 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 75 7.2. Informative References . . . . . . . . . . . . . . . . . 14 76 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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. A 87 comprehensive SR Performance Measurement (PM) toolset is one of the 88 essential requirements to measure network performance to provide 89 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, in the 95 form of TLVs, for STAMP. Note that the YANG data model defined in 96 [I-D.ietf-ippm-stamp-yang] can be used to provision the STAMP 97 Session-Sender and STAMP Session-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 S1 140 initiates a STAMP test packet and the STAMP Session-Reflector R1 141 transmits a reply STAMP test packet. The reply test packet may be 142 transmitted to the Session-Sender S1 on the same path (same set of 143 links and nodes) or a different path in the reverse direction from 144 the path taken towards the Session-Reflector R1. 146 The nodes S1 and R1 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 S1 (called head-end) with destination to node R1 (called 151 tail-end). 153 T1 T2 154 / \ 155 +-------+ Test Packet +-------+ 156 | | - - - - - - - - - ->| | 157 | S1 |=====================| R1 | 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 Session-Sender may need to transmit test packets to the Session- 170 Reflector with a different destination address not matching an 171 address on the Session-Reflector e.g. when the STAMP test packet is 172 encapsulated by a tunneling protocol or an MPLS Segment List with 173 IPv4 address from 127/8 range or Segment Routing Header (SRH) with 174 IPv6 address ::1/128. For testing ECMPs, the Session-Sender may 175 select different IPv4 addresses from 127/8 range or select different 176 Flow Label values for IPv6. When using IPv4 destination address from 177 127/8 range, the STAMP test packet may not reach the intended 178 Session-Reflector in an error condition, an un-intended node may 179 transmit reply test packets resulting in reporting of invalid 180 measurement metrics. 182 [RFC8972] defines STAMP test packets that can include one or more 183 optional TLVs. In this document, Destination Node Address TLV (Type 184 TBA1) is defined for STAMP test packet [RFC8972] and has the 185 following format shown in Figure 1: 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 |STAMP TLV Flags| Type=TBA1 | Length | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 . Address . 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Figure 1: Destination Node Address TLV Format 197 The Length field is used to decide the Address Family of the Address. 199 The STAMP TLV Flags are set using the procedures described in 200 [RFC8972]. 202 The Destination Node Address TLV is optional. The Destination Node 203 Address TLV indicates the address of the intended Session-Reflector 204 node of the test packet. When Session-Sender test packet destination 205 address is different than the actual Session-Reflector address, the 206 actual Session-Reflector address SHOULD be transmitted to the 207 Session-Reflector by including a Destination Node Address TLV. 209 D (Wrong Destination Flag): A one-bit flag at position TBA3. 211 D (Wrong Destination with Reply Required): A Session-Sender MUST set 212 the D flag to 0 before transmitting an extended STAMP test packet 213 when test packet reply is required. A Session-Reflector that 214 supports this TLV, MUST set the D flag to 1 if the Session-Reflector 215 determined that it is not the intended Destination as identified in 216 the Destination Node Address TLV. Otherwise, the Session-Reflector 217 MUST set the D flag in the reply test packet to 0. 219 D (Wrong Destination with No Reply Required): A Session-Sender MUST 220 set the D flag to 1 before transmitting an extended STAMP test packet 221 when test packet reply is not required. A Session-Reflector that 222 supports this TLV, MUST NOT reply and MUST drop the packet if the 223 Session-Reflector determined that it is not the intended Destination 224 as identified in the Destination Node Address TLV. 226 4. Return Path TLV 228 For end-to-end SR paths, the Session-Reflector may need to transmit 229 the reply test packet on a specific return path. The Session-Sender 230 can request this in the test packet to the Session-Reflector using a 231 Return Path TLV. With this TLV carried in the Session-Sender test 232 packet, signaling and maintaining dynamic SR network state for the 233 STAMP sessions on the Session-Reflector are avoided. 235 For links, the Session-Reflector may need to transmit the reply test 236 packet on the same incoming link in the reverse direction. The 237 Session-Sender can request this in the test packet to the Session- 238 Reflector using a Return Path TLV. 240 [RFC8972] defines STAMP test packets that can include one or more 241 optional TLVs. In this document, the TLV Type (value TBA2) is 242 defined for the Return Path TLV that carries the return path for the 243 Session-Sender test packet. The format of the Return Path TLV is 244 shown in Figure 2: 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 |STAMP TLV Flags| Type=TBA2 | Length | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Return Path Sub-TLVs | 252 . . 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 2: Return Path TLV 257 The STAMP TLV Flags are set using the procedures described in 258 [RFC8972]. 260 The Return Path TLV is optional. The Session-Sender MUST only insert 261 one Return Path TLV in the STAMP test packet. The Session-Reflector 262 that supports this TLV, MUST only process the first Return Path TLV 263 in the test packet and ignore other Return Path TLVs if present, and 264 it MUST NOT add Return Path TLV in the reply test packet. The 265 Session-Reflector that supports this TLV MUST reply using the Return 266 Path received in the Session-Sender test packet. Otherwise, the 267 procedure defined in [RFC8762] is followed by the Session-Reflector. 269 4.1. Return Path Sub-TLVs 271 The Return Path TLV contains one or more Sub-TLVs to carry the 272 information for the requested return path. A Return Path Sub-TLV can 273 carry Return Path Control Code, Return Path IP Address or Return Path 274 Segment List. 276 The STAMP Sub-TLV Flags are set using the procedures described in 277 [RFC8972]. 279 When Return Path Sub-TLV is present in the Session-Sender test 280 packet, the Session-Reflector that supports this TLV, MUST transmit 281 reply test packet using the return path information specified in the 282 Return Path Sub-TLV. 284 A Return Path TLV MUST NOT contain both Control Code Sub-TLV as well 285 as Return Address or Return Segment List Sub-TLV. 287 4.1.1. Return Path Control Code Sub-TLV 289 The format of the Return Path Control Code Sub-TLV is shown in 290 Figure 3. The Type of the Return Path Control Code Sub-TLV is 291 defined as following: 293 * Type (value 1): Return Path Control Code. The Session-Sender can 294 request the Session-Reflector to transmit the reply test packet 295 based on the flags defined in the Control Code field. 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 |STAMP TLV Flags| Type=1 | Length | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Control Code | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 3: Control Code Sub-TLV in Return Path TLV 307 Control Code Flags (32-bit): Defined as follows. 309 0x0: No Reply Requested. 311 0x1: Reply Requested on the Same Link. 313 When Control Code flag is set to 0x0 in the Session-Sender test 314 packet, the Session-Reflector does not transmit reply test packet to 315 the Session-Sender and terminates the STAMP test packet. Only the 316 one-way measurement is applicable in this case. Optionally, the 317 Session-Reflector may locally stream performance metrics via 318 telemetry using the information from the received test packet. All 319 other Return Path Sub-TLVs MUST be ignored in this case. 321 When Control Code flag is set to 0x1 in the Session-Sender test 322 packet, the Session-Reflector transmits the reply test packet over 323 the same incoming link where the test packet is received in the 324 reverse direction towards the Session-Sender. All other Return Path 325 Sub-TLVs MUST be ignored in this case. 327 4.1.2. Return Address Sub-TLV 329 The STAMP reply test packet may be transmitted to the Session-Sender 330 to a different destination address on the Session-Sender using Return 331 Path TLV. For this, the Session-Sender can specify in the test 332 packet the receiving destination node address for the Session- 333 Reflector reply test packet. When transmitting the STAMP test packet 334 to a different destination address, the Session-Sender MUST follow 335 the procedure defined in Section 4.3 of [RFC8762]. 337 The format of the Return Address Sub-TLV is shown in Figure 4. The 338 Address Family field indicates the type of the address, and it SHALL 339 be set to one of the assigned values in the "IANA Address Family 340 Numbers" registry. The Type of the Return Address Sub-TLV is defined 341 as following: 343 * Type (value 2): Return Address. Destination node address of the 344 Session-Reflector reply test packet different than the Source 345 Address in the Session-Sender test packet. 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 |STAMP TLV Flags| Type=2 | Length | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Reserved | Address Family | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 . Address . 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Figure 4: Return Address Sub-TLV in Return Path TLV 359 4.1.3. Return Segment List Sub-TLVs 361 The format of the Segment List Sub-TLVs in the Return Path TLV is 362 shown in Figures 5, 6, and 7. The segment entries MUST be in network 363 order. The Segment List Sub-TLV can be one of the following Types: 365 * Type (value 3): SR-MPLS Label Stack of the Return Path 367 * Type (value 4): SRv6 Segment List of the Return Path 369 * Type (value 5): Structured SRv6 Segment List of the Return Path 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 |STAMP TLV Flags| Type=3 | Length | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Segment(1) | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 . . 379 . . 380 . . 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Segment(n) (bottom of stack) | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Figure 5: SR-MPLS Segment List Sub-TLV in Return Path TLV 387 0 1 2 3 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 |STAMP TLV Flags| Type=4 | Length | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | | 393 | Segment(1) | 394 | | 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 . . 398 . . 399 . . 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | | 402 | Segment(n) (bottom of stack) | 403 | | 404 | | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 Figure 6: SRv6 Segment List Sub-TLV in Return Path TLV 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 |STAMP TLV Flags| Type=5 | Length | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | LB Length | LN Length | Fun. Length | Arg. Length | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | | 417 | Segment(1) | 418 | | 419 | | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 . . 422 . . 423 . . 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | LB Length | LN Length | Fun. Length | Arg. Length | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | | 428 | Segment(n) (bottom of stack) | 429 | | 430 | | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Figure 7: Structured SRv6 Segment List Sub-TLV in Return Path TLV 435 An SR-MPLS Label Stack Sub-TLV may carry only Binding SID 436 [I-D.ietf-pce-binding-label-sid] of the Return SR-MPLS Policy. 438 An SRv6 Segment List Sub-TLV and Structured SRv6 Segment List Sub-TLV 439 may carry only Binding SID [I-D.ietf-pce-binding-label-sid] of the 440 Return SRv6 Policy. 442 A Structured SRv6 Segment List Sub-TLV is used carry the structure 443 and behavior for SRv6 SIDs [RFC8986] used in the Return SRv6 path as 444 shown in Figure 7. The structure is intended for informational use 445 by the control and management planes. The fields in the structure of 446 the Sub-TLV are defined as follows [RFC8986]: 448 * LB Length: 1 octet. SRv6 SID Locator Block (LB) length in bits. 450 * LN Length: 1 octet. SRv6 SID Locator Node (LN) length in bits. 452 * Fun. Length: 1 octet. SRv6 SID Function length in bits. 454 * Arg. Length: 1 octet. SRv6 SID Arguments length in bits. 456 In Structured SRv6 Segment List Sub-TLV, the sum of all four sizes 457 MUST be less than or equal to 128 bits. If the sum of all four sizes 458 is larger than 128 bits, the Sub-TLV MUST be ignored by the Session- 459 Reflector. 461 The Session-Sender MUST only insert one Segment List Return Path Sub- 462 TLV in the test packet. The Session-Reflector MUST only process the 463 first Segment List Return Path Sub-TLV in the test packet and ignore 464 other Segment List Return Path Sub-TLVs if present. 466 Note that in addition to P2P SR paths, the Return Segment List Sub- 467 TLV is also applicable to P2MP SR paths. For example, for P2MP SR 468 paths, it may only carry the Node Segment Identifier of the Session- 469 Sender in order for the reply test packet to follow an SR path to the 470 Session-Sender. 472 5. Security Considerations 474 The usage of STAMP protocol is intended for deployment in limited 475 domains [RFC8799]. As such, it assumes that a node involved in STAMP 476 protocol operation has previously verified the integrity of the path 477 and the identity of the far-end Session-Reflector. 479 If desired, attacks can be mitigated by performing basic validation 480 and sanity checks, at the Session-Sender, of the timestamp fields in 481 received reply test packets. The minimal state associated with these 482 protocols also limits the extent of measurement disruption that can 483 be caused by a corrupt or invalid test packet to a single test cycle. 485 The security considerations specified in [RFC8762] and [RFC8972] also 486 apply to the extensions defined in this document. Specifically, the 487 message integrity protection using HMAC, as defined in [RFC8762] 488 Section 4.4, also apply to the procedure described in this document. 490 STAMP uses the well-known UDP port number that could become a target 491 of denial of service (DoS) or could be used to aid man-in-the-middle 492 (MITM) attacks. Thus, the security considerations and measures to 493 mitigate the risk of the attack documented in Section 6 of [RFC8545] 494 equally apply to the STAMP extensions in this document. 496 The STAMP extensions defined in this document may be used for 497 potential "proxying" attacks. For example, a Session-Sender may 498 specify a return path that has a destination different from that of 499 the Session-Sender. But normally, such attacks will not happen in an 500 SR domain where the Session-Senders and Session-Reflectors belong to 501 the same domain. In order to prevent using the extension defined in 502 this document for proxying any possible attacks, the return path has 503 destination to the same node where the forward path is from. The 504 Session-Reflector may drop the Session-Sender test packet when it 505 cannot determine whether the Return Path has the destination to the 506 Session-Sender. That means, the Session-Sender should choose a 507 proper source address according to the specified Return Path to help 508 the Session-Reflector to make that decision. 510 6. IANA Considerations 512 IANA has created the "STAMP TLV Types" registry for [RFC8972]. IANA 513 is requested to allocate a value for the Destination Address TLV Type 514 and a value for the Return Path TLV Type from the IETF Review TLV 515 range of the same registry. 517 +=======+==============================+===============+ 518 | Value | Description | Reference | 519 +=======+==============================+===============+ 520 | TBA1 | Destination Node Address TLV | This document | 521 +-------+------------------------------+---------------+ 522 | TBA2 | Return Path TLV | This document | 523 +-------+------------------------------+---------------+ 525 Table 1: STAMP TLV Types 527 IANA is requested to create a sub-registry for "Return Path Sub-TLV 528 Type". All code points in the range 1 through 175 in this registry 529 shall be allocated according to the "IETF Review" procedure as 530 specified in [RFC8126]. Code points in the range 176 through 239 in 531 this registry shall be allocated according to the "First Come First 532 Served" procedure as specified in [RFC8126]. Remaining code points 533 are allocated according to Table 2: 535 +===========+=========================+===============+ 536 | Value | Description | Reference | 537 +===========+=========================+===============+ 538 | 1 - 175 | IETF Review | This document | 539 +-----------+-------------------------+---------------+ 540 | 176 - 239 | First Come First Served | This document | 541 +-----------+-------------------------+---------------+ 542 | 240 - 251 | Experimental Use | This document | 543 +-----------+-------------------------+---------------+ 544 | 252 - 254 | Private Use | This document | 545 +-----------+-------------------------+---------------+ 547 Table 2: Return Path Sub-TLV Type Registry 549 IANA is requested to allocate the values for the following Sub-TLV 550 Types from this registry. 552 +======+========================================+===============+ 553 | Type | Description | Reference | 554 +======+========================================+===============+ 555 | 0 | Reserved | This document | 556 +------+----------------------------------------+---------------+ 557 | 1 | Return Path Control Code | This document | 558 +------+----------------------------------------+---------------+ 559 | 2 | Return Address | This document | 560 +------+----------------------------------------+---------------+ 561 | 3 | SR-MPLS Label Stack of the Return Path | This document | 562 +------+----------------------------------------+---------------+ 563 | 4 | SRv6 Segment List of the Return Path | This document | 564 +------+----------------------------------------+---------------+ 565 | 5 | Structured SRv6 Segment List of the | This document | 566 | | Return Path | | 567 +------+----------------------------------------+---------------+ 568 | 255 | Reserved | This document | 569 +------+----------------------------------------+---------------+ 571 Table 3: Return Path Sub-TLV Types 573 IANA has created the "STAMP TLV Flags" subregistry. IANA is 574 requested to allocate the following bit position in the "STAMP TLV 575 Flags" subregistry. 577 +==============+========+===================+===============+ 578 | Bit Position | Symbol | Description | Reference | 579 +==============+========+===================+===============+ 580 | TBA3 | D | Wrong Destination | This document | 581 +--------------+--------+-------------------+---------------+ 583 Table 4: STAMP TLV Flags 585 7. References 587 7.1. Normative References 589 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 590 Requirement Levels", BCP 14, RFC 2119, 591 DOI 10.17487/RFC2119, March 1997, 592 . 594 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 595 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 596 May 2017, . 598 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 599 Two-Way Active Measurement Protocol", RFC 8762, 600 DOI 10.17487/RFC8762, March 2020, 601 . 603 [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 604 and E. Ruffini, "Simple Two-Way Active Measurement 605 Protocol Optional Extensions", RFC 8972, 606 DOI 10.17487/RFC8972, January 2021, 607 . 609 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 610 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 611 (SRv6) Network Programming", RFC 8986, 612 DOI 10.17487/RFC8986, February 2021, 613 . 615 7.2. Informative References 617 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 618 Decraene, B., Litkowski, S., and R. Shakir, "Segment 619 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 620 July 2018, . 622 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 623 Writing an IANA Considerations Section in RFCs", BCP 26, 624 RFC 8126, DOI 10.17487/RFC8126, June 2017, 625 . 627 [RFC8545] Morton, A., Ed. and G. Mirsky, Ed., "Well-Known Port 628 Assignments for the One-Way Active Measurement Protocol 629 (OWAMP) and the Two-Way Active Measurement Protocol 630 (TWAMP)", RFC 8545, DOI 10.17487/RFC8545, March 2019, 631 . 633 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 634 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 635 . 637 [I-D.ietf-spring-segment-routing-policy] 638 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 639 P. Mattes, "Segment Routing Policy Architecture", Work in 640 Progress, Internet-Draft, draft-ietf-spring-segment- 641 routing-policy-14, 25 October 2021, 642 . 645 [I-D.ietf-pce-binding-label-sid] 646 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 647 and C. L. (editor), "Carrying Binding Label/Segment 648 Identifier in PCE-based Networks.", Work in Progress, 649 Internet-Draft, draft-ietf-pce-binding-label-sid-12, 24 650 January 2022, . 653 [I-D.ietf-ippm-stamp-yang] 654 Mirsky, G., Min, X., and W. S. Luo, "Simple Two-way Active 655 Measurement Protocol (STAMP) Data Model", Work in 656 Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-09, 657 12 July 2021, . 660 [IEEE802.1AX] 661 IEEE Std. 802.1AX, "IEEE Standard for Local and 662 metropolitan area networks - Link Aggregation", November 663 2008. 665 Acknowledgments 667 The authors would like to thank Thierry Couture for the discussions 668 on the use-cases for Performance Measurement in Segment Routing. The 669 authors would also like to thank Greg Mirsky, Mike Koldychev, Gyan 670 Mishra, Tianran Zhou, Al Mortons, Reshad Rahman, Zhenqiang Li, Frank 671 Brockners, and Cheng Li for providing comments and suggestions. 673 Authors' Addresses 675 Rakesh Gandhi (editor) 676 Cisco Systems, Inc. 677 Canada 679 Email: rgandhi@cisco.com 681 Clarence Filsfils 682 Cisco Systems, Inc. 684 Email: cfilsfil@cisco.com 686 Daniel Voyer 687 Bell Canada 689 Email: daniel.voyer@bell.ca 690 Mach(Guoyi) Chen 691 Huawei 693 Email: mach.chen@huawei.com 695 Bart Janssens 696 Colt 698 Email: Bart.Janssens@colt.net 700 Richard Foote 701 Nokia 703 Email: footer.foote@nokia.com