idnits 2.17.1 draft-weng-ippm-srpm-path-consistency-over-srv6-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 3, 2022) is 783 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 126, but not defined == Missing Reference: 'RFC8174' is mentioned on line 126, but not defined == Missing Reference: 'SL' is mentioned on line 362, but not defined == Unused Reference: 'I-D.ietf-idr-segment-routing-te-policy' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-mpls-path-segment' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 439, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-srv6-path-segment' is defined on line 444, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-sr-policy-path-segment' is defined on line 449, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-stamp-srpm' is defined on line 454, but no explicit reference was found in the text == Unused Reference: 'RFC8986' is defined on line 482, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-11 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-07 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-17 == Outdated reference: A later version (-07) exists of draft-ietf-spring-srv6-path-segment-03 == Outdated reference: A later version (-09) exists of draft-ietf-idr-sr-policy-path-segment-05 == Outdated reference: A later version (-14) exists of draft-ietf-spring-stamp-srpm-03 Summary: 0 errors (**), 0 flaws (~~), 18 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPPM Working Group S. Weng 2 Internet Draft W. Cheng 3 Intended status: Informational China Mobile 4 Expires: Sep 3, 2022 C. Lin 5 New H3C Technologies 6 March 3, 2022 8 SRPM Path Consistency over SRv6 9 draft-weng-ippm-srpm-path-consistency-over-srv6-00 11 Abstract 13 Twamp can be used to measure the performance of end-to-end paths in 14 networks. Stamp [rfc8762] and twamp light are more lightweight 15 measurement methods. In the SRv6 network, it is also necessary to 16 measure the performance of SRv6 policy. This document describes a 17 method to measure srv6 policy through stamp and twamp light. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on September 3 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction ................................................ 2 60 1.1. Requirements Language .................................. 3 61 1.2. Terminology ............................................ 3 62 2. Requirement for consistent path ............................. 4 63 3. Correlate bidirectional path using Path Segment ............. 5 64 4. STAMP/TWAMP light Procedure with Path segment ............... 7 65 4.1. Stamp/twamp light Session-sender procedure ............. 7 66 4.2. Stamp/twamp light Session-reflector procedure .......... 8 67 5. IANA Considerations ........................................ 10 68 6. Security Considerations .................................... 10 69 7. References ................................................. 10 70 7.1. Normative References .................................. 10 71 Contributors .................................................. 12 72 Authors' Addresses ............................................ 13 74 1. Introduction 76 Segment Routing (SR) allows a headend node to steer a packet flow 77 along any path. Per-path states of Intermediate nodes are eliminated 78 thanks to source routing. The headend node steers a flow into an SR 79 Policy. The packets steered into an SR Policy carry an ordered list 80 of segments associated with that SR Policy. SR policy is used to 81 forward messages, so the quality of SR policy, such as packet loss 82 and delay, also needs to be measured. 84 The Simple Two-Way Active Measurement Protocol (STAMP) provides 85 capabilities for the measurement of various performance metrics in 86 IP networks [RFC8762] without the use of a control channel to pre- 87 signal session parameters. [RFC8972] defines optional extensions in 88 the form of TLVs for STAMP. 90 The STAMP test packets are transmitted along an IP path between a 91 Session-Sender and a Session-Reflector to measure performance delay 92 and packet loss along that IP path. It may be desired in SRv6 93 networks that the consistent path (same set of links and nodes) 94 between the Session-Sender and Session-Reflector is used for the 95 STAMP test packets in both directions. 97 [ietf-ippm-stamp-srpm] defines the Return Path TLV, Using Return 98 Path TLV, The Session-Sender can request this in the test packet to 99 the Session-Reflector. 101 Twamp light is also widely deployed, and stamp supports interworking 102 with twamp light. So there are four possible combinations to deploy 103 stamp and twamp light: 105 STAMP Session-Sender with STAMP Session-Reflector. 107 STAMP Session-Sender with TWAMP Light Session-Reflector. 109 TWAMP Light Session-Sender with STAMP Session-Reflector. 111 TWAMP Light Session-Sender with TWAMP Light Session-Reflector. 113 Twamp light does not support the TLV of stamp, so in order to meet 114 various deployment combinations, this document proposes a method to 115 realize the same path between Session-Sender and session-reflector 116 using path segment, which is also applicable to all scenarios where 117 twamp light and stamp are deployed. 119 1.1. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in 124 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 1.2. Terminology 129 STAMP: Simple Two-way Active Measurement Protocol 131 TWAMP: Two-Way Active Measurement Protocol 133 PTP: Precision Time Protocol 135 SR: Segment Routing 137 2. Requirement for consistent path 139 In the reference topology shown below, the procedure of stamp and 140 twamp light is similar. The Session-Sender S1 initiates a test 141 packet and the Session-Reflector R1 transmits a reply test packet. 142 The reply test packet may be transmitted to the Session-Sender S1 on 143 the consistent path (same set of links and nodes) or a different 144 path in the reverse direction from the path taken towards the 145 Session-Reflector R1. 147 T1 T2 148 / \ 149 +-------+ Test Packet +-------+ 150 | | - - - - - - - - - ->| | 151 | S1 |=====================| R1 | 152 | |<- - - - - - - - - - | | 153 +-------+ Reply Test Packet +-------+ 154 \ / 155 T4 T3 156 Session-Sender Session-Reflector 158 Figure 1: reference topology1 160 By recording the time stamp in the test packet, the delay of one-way 161 and two-way path can be measured. In the interaction process of a 162 test, the sender inserts the sending timestamp T1 into the test 163 packet. The reflector records the receiving timestamp T2 when 164 receiving the request message. Then reflector creates a reply packet 165 and inserts T1, T2 and the sending timestamp T3 of the reply packet 166 into the reply packet. Finally the sender receives the reply packet 167 and records the receiving timestamp T4. 169 In this way, the sender gets four timestamps. Bidirectional delay 170 can be obtained through t4-t1. If the one-way delay is calculated 171 through t2-t1, PTP is required to be deployed between sender and 172 reflector to ensure high-precision time synchronization, which is 173 not easy to achieve for existing networks. 175 Therefore, if the test packets in both directions can be guaranteed 176 to pass along the consistent path, the two-way delay can be obtained 177 by T4-T1, minus the time of processing packet on the reflector 178 calculated by T3-T2, and the final data is the sum of the delays in 179 two directions of transmitting packets along the consistent path. 181 3. Correlate bidirectional path using Path Segment 183 A Path Segment is defined to identify an SR path in [draft-ietf- 184 spring-srv6-path-segment]. SRv6 Path segments can be used to 185 correlate the two unidirectional SRv6 paths at both ends of the 186 path. 188 [draft-ietf-idr-sr-policy-path-segment] proposes an extension to BGP 189 SR Policy distribute SR policies carrying Path Segment and 190 bidirectional path information. 192 Through this extension, when distributing SRv6 policy to the 193 headend, reverse path information and path segment of segment list 194 can be carried together. 196 SID-B1 SID-B2 SID-C1 SID-C2 197 +--------B-----------------C-----------+ 198 SID-A1/ \ SID-D1 199 / \ 200 A D 201 \ /SID-D2 202 SID-A2\ SID-E1 SID-E2 / 203 +-------------------E-------------------+ 204 Figure 2: reference topology2 206 In this way, on the headend in both directions of the forward and 207 reverse paths, the path segment of the paths in both directions can 208 be obtained, and the paths in both directions use the same 209 intermediate link. 211 Refer to the reference topology2. There are two paths between NodeA 212 and NodeD, and All nodes allocate end.x Segments. 214 SRv6 policy is distributed to NodeA and NodeD respectively as the 215 headend to build symmetrical two-way paths. SRv6 policy includes a 216 candidate path, which contains two segment lists. 218 Each segment list contains both the corresponding path segment and 219 the reverse path segment of the reverse path: 221 NodeA NodeD 223 SRv6 Policy A-D SRv6 Policy D-A 224 Candidate Path1 Candidate Path1 225 Segment list1 Segment list1 226 SID-A1, SID-B2, SID-C2 SID-D1, SID-C1, SID-B1 227 Path Segment: SID-Path-A1 Path Segment: SID-Path-D1 228 Reverse Path Segment: Reverse Path Segment: 229 SID-Path-D1 SID-Path-A1 230 Segment list2 Segment list2 231 SID-A2, SID-E2 SID-D2, SID-E1 232 Path Segment: SID-Path-A2 Path Segment: SID-Path-D2 233 Reverse Path Segment: Reverse Path Segment: 234 SID-Path-D2 SID-Path-A2 236 The headend can use path segment in two directions to establish a 237 mapping table. Using this mapping table, the headend can index the 238 reverse path through the path segment of the forward path. 240 NodeA: 241 +-----------------+ +--------------------+ 242 | Path Segment | |Reverse Path Segment| 243 +-----------------+ +--------------------+ 244 | SID-Path-A1 |-+ | SID-Path-D1 |--+ 245 +-----------------+ | +--------------------+ | 246 | SID-Path-A2 | | | SID-Path-D2 |--|-+ 247 +-----------------+ | +--------------------+ | | 248 | | | | 249 | | +-----------------------+ | | 250 | | | segment List | | | 251 | | +-----------------------+ | | 252 | +->|SID-A1, SID-B2, SID-C2 |<----+ | 253 | +-----------------------+ | 254 +-------------->|SID-A2, SID-E2 |<------+ 255 +-----------------------+ 257 NodeD: 258 +-----------------+ +--------------------+ 259 | Path Segment | |Reverse Path Segment| 260 +-----------------+ +--------------------+ 261 | SID-Path-D1 |-+ | SID-Path-A1 |--+ 262 +-----------------+ | +--------------------+ | 263 | SID-Path-D2 | | | SID-Path-A2 |--|-+ 264 +-----------------+ | +--------------------+ | | 265 | | | | 266 | | +-----------------------+ | | 267 | | | segment List | | | 268 | | +-----------------------+ | | 269 | +->|SID-D1, SID-C1, SID-B1 |<----+ | 270 | +-----------------------+ | 271 +-------------->|SID-D2, SID-E1 |<------+ 272 +-----------------------+ 273 Figure 3: mapping table 275 4. STAMP/TWAMP light Procedure with Path segment 277 This document proposes that the test packets in the two directions 278 of stamp/twamp light are transmitted along the consistent path 279 through path segment. 281 Twamp light does not need to parse the TLV of stamp. Neither stamp 282 nor twamp light needs to modify the packet structure. Using SRH to 283 carry path segment, stamp and twamp light need to add some relevant 284 adaptation processing to meet the requirement. 286 4.1. Stamp/twamp light Session-sender procedure 288 For instance, the session-sender is Node A in Figure 2, and the 289 session is bounded with Segment List1 of Policy A-D. The test packet 290 is as follow: 292 +-----------------------------------------------------------+ 293 | IPv6 Header | 294 . Source IP Address = Session-Sender IPv6 Address . 295 . Destination IP Address = SegmentList[SL] . 296 . Next-Header = SRH (43) . 297 . . 298 +-----------------------------------------------------------+ 299 | SRH as specified in RFC 8754 | 300 . Next-Header = IPv6 . 301 . . 302 . . 303 +-----------------------------------------------------------+ 304 | IPv6 Header | 305 . Source IP Address = Session-Sender IPv6 Address . 306 . Destination IP Address = Session-Reflector IPv6 Address . 307 . Next-Header = UDP . 308 . . 309 +-----------------------------------------------------------+ 310 | UDP Header | 311 . . 312 +-----------------------------------------------------------+ 313 | Payload | 314 . . 315 +-----------------------------------------------------------+ 316 Figure 4: Encapsulation format of test packet 318 NodeA Encapsulates the path segment of segment list1 in SRH, and set 319 SRH.P-Flag. 321 The test packet is as follows: 323 A------------->B------------>C---------->D 324 +-----------------+ +-----------------+ 325 | SA=A's Ipv6Addr | | SA=A's Ipv6Addr | 326 +-----------------+ +-----------------+ 327 | DA=SID-A1 | | DA=D's ipv6Addr | 328 +-----------------+ +-----------------+ 329 | SL=3 | P-Flag=1 | | SL=0 | P-Flag=1 | 330 +-----------------+ +-----------------+ 331 | D's ipv6Addr | | D's ipv6Addr | 332 +-----------------+ +-----------------+ 333 | SID-C2 | | SID-C2 | 334 +-----------------+ +-----------------+ 335 | SID-B2 | | SID-B2 | 336 +-----------------+ +-----------------+ 337 | SID-A1 | | SID-A1 | 338 +-----------------+ +-----------------+ 339 | SID-Path-A1 | | SID-Path-A1 | 340 +-----------------+ +-----------------+ 341 | test-payload | | test-payload | 342 | | | | 343 +-----------------+ +-----------------+ 344 Figure 5: Example of test packet 346 4.2. Stamp/twamp light Session-reflector procedure 348 The test packet is forwarded along the path A->B->C-D. While packet 349 arrives at nodeD, SRH.SL is 0 and the destination address is the 350 IPv6 address of NodeD. Packet is delivered up to the stamp/twamp 351 light module in control plane. 353 Stamp/twamp light module on NodeD detects SRH.P-flag is set, 354 extracts the path segment of the forward path from SRH, gets the 355 path segment of the reverse path through the mapping table. When 356 reply test packet, stamp/twamp light module use the segment list 357 associated with path segment of the reverse path to encapsulate SRH. 359 +-----------------------------------------------------------+ 360 | IPv6 Header | 361 . Source IP Address = Session-Reflector IPv6 Address . 362 . Destination IP Address = SegmentList[SL] . 363 . Next-Header = SRH (43) . 364 . . 365 +-----------------------------------------------------------+ 366 | SRH as specified in RFC 8754 | 367 . Next-Header = IPv6 . 368 . . 369 . . 370 +-----------------------------------------------------------+ 371 | IPv6 Header | 372 . Source IP Address = Session-Reflector IPv6 Address . 373 . Destination IP Address = Session-Sender IPv6 Address . 374 . Next-Header = UDP . 375 . . 376 +-----------------------------------------------------------+ 377 | UDP Header | 378 . . 379 +-----------------------------------------------------------+ 380 | Payload | 381 . . 382 +-----------------------------------------------------------+ 383 Figure 6: Encapsulation format of reply test packet 385 The Example of reply test packet is as follows: 387 D------------->C------------>B---------->A 389 +-----------------+ +-----------------+ 390 | SA=D's Ipv6Addr | | SA=D's Ipv6Addr | 391 +-----------------+ +-----------------+ 392 | DA=SID-D1 | | DA=A's ipv6Addr | 393 +-----------------+ +-----------------+ 394 | SL=3 | P-Flag=0 | | SL=0 | P-Flag=0 | 395 +-----------------+ +-----------------+ 396 | A's ipv6Addr | | A's ipv6Addr | 397 +-----------------+ +-----------------+ 398 | SID-B1 | | SID-B1 | 399 +-----------------+ +-----------------+ 400 | SID-C1 | | SID-C1 | 401 +-----------------+ +-----------------+ 402 | SID-D1 | | SID-D1 | 403 +-----------------+ +-----------------+ 404 | reply test | | reply test | 405 | payload | | payload | 406 +-----------------+ +-----------------+ 407 Figure 7: Example of reply test packet 409 The reply test packet will be forward along the path D->C->B->A. In 410 this way, the forward and reverse paths of test packet are 411 guaranteed to be consistent. 413 5. IANA Considerations 415 This document has no IANA actions. 417 6. Security Considerations 419 The security requirements and mechanisms described in [RFC8402] and 420 [RFC8754] also apply to this document. 422 This document does not introduce any new security consideration. 424 7. References 426 7.1. Normative References 428 [I-D.ietf-idr-segment-routing-te-policy] Previdi, S., Filsfils, C., 429 Talaulikar, K., Mattes, P.,Rosen, E., Jain, D., and S. 430 Lin, "Advertising Segment Routing Policies in BGP", draft- 431 ietf-idr-segment-routing-te-policy-11 (work in progress), 432 November 2020 434 [I-D.ietf-spring-mpls-path-segment] Cheng, W., Li, H., Chen, M., 435 Gandhi, R., and R. Zigler, "Path Segment in MPLS Based 436 Segment Routing Network",draft-ietf-spring-mpls-path- 437 segment-07 (work in progress), December 2021. 439 [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Talaulikar, 440 K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment 441 Routing Policy Architecture", draft-ietf-spring-segment- 442 routing-policy-17 (work in progress),February 2022. 444 [I-D.ietf-spring-srv6-path-segment] Li, C., Cheng, W., Chen, M., 445 Dhody, D., and Y. Zhu, "Path Segment for SRv6 (Segment 446 Routing in IPv6)", draft-ietf-spring-srv6-path-segment-03 447 (work in progress),November 2021. 449 [I-D.ietf-idr-sr-policy-path-segment] Li, C., Li, Z., Yin, Y., 450 Cheng, W., Talaulikar, K., "SR Policy Extensions for Path 451 Segment and Bidirectional Path", draft-ietf-idr-sr-policy- 452 path-segment-05(work in progress), January 2022. 454 [I-D.ietf-spring-stamp-srpm] Gandhi, R., Filsfils, C., Voyer, D., 455 Chen, M., Janssens, B., and R. Foote, "Performance 456 Measurement Using Simple TWAMP (STAMP) for Segment Routing 457 Networks", Work in Progress, Internet-Draft, draft-ietf- 458 spring-stamp-srpm-03, 1 February 2022, 459 . 462 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, 463 L.,Decraene, B., Litkowski, S., and R. Shakir, "Segment 464 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,July 465 2018, . 467 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, 468 J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing 469 Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 470 . 472 [RFC8762] Greg Mirsky, Guo Jun, Henrik Nydell, Richard Foote, 473 "Simple Two-Way Active Measurement Protocol", RFC 8762, 474 DOI: 10.17487/RFC8762, March 2020, . 477 [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., 478 and E. Ruffini, "Simple Two-Way Active MeasurementProtocol 479 Optional Extensions", RFC 8972, DOI 10.17487/RFC8972, 480 January 2021, . 482 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 483 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 484 (SRv6) Network Programming", RFC 8986, DOI 485 0.17487/RFC8986, February 2021, . 488 Contributors 490 Yisong Liu contributed to the content of this document. 492 Authors' Addresses 494 Wengsijun 495 China Mobile 496 Beijing 497 CN 499 Email: wengsijun@chinamobile.com 501 Weiqiang Cheng 502 China Mobile 503 Beijing 504 CN 506 Email: chengweiqiang@chinamobile.com 508 Changwang Lin 509 New H3C Technologies 510 Beijing 511 China 513 Email: linchangwang.04414@h3c.com 515 Hao Li 516 New H3C Technologies 517 Beijing 518 China 520 Email: lihao@h3c.com