idnits 2.17.00 (12 Aug 2021) /tmp/idnits13447/draft-song-spring-siam-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (4 March 2022) is 71 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) == Unused Reference: 'RFC8200' is defined on line 296, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING H. Song 3 Internet-Draft Futurewei Technologies 4 Intended status: Standards Track G. Mishra 5 Expires: 5 September 2022 Verizon Inc. 6 T. Pan 7 BUPT 8 4 March 2022 10 SRv6 In-situ Active Measurement with IOAM 11 draft-song-spring-siam-03 13 Abstract 15 This draft describes an active measurement method for SRv6 which can 16 support hop-by-hop and end-to-end measurement on any SRv6 path using 17 existing protocols such as IOAM. A packet containing an SRH uses a 18 flag bit to indicate the packet is an active probing packet. The 19 measurement information, such as the IOAM header and data, is 20 encapsulated in UDP payload, indicated by a dedicated port number. 21 The probing packet originates from a segment source node, traverses 22 an arbitrary segment path, and terminates at a segment endpoint node, 23 as configured by the segment list in SRH. Each segment node on the 24 path, when detecting the flag, shall parse the UDP header and the 25 payload. In the case of IOAM, the node shall process the IOAM option 26 conforming to the standard procedures defined in the IOAM documents. 27 The method is compatible with some other SRv6 active measurement 28 proposals and support multiple applications. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 34 "OPTIONAL" in this document are to be interpreted as described in BCP 35 14 [RFC2119][RFC8174] when, and only when, they appear in all 36 capitals, as shown here. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on 5 September 2022. 55 Copyright Notice 57 Copyright (c) 2022 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 62 license-info) in effect on the date of publication of this document. 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. Code Components 65 extracted from this document must include Revised BSD License text as 66 described in Section 4.e of the Trust Legal Provisions and are 67 provided without warranty as described in the Revised BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. An Active Measurement Framework for SRv6 . . . . . . . . . . 3 73 3. SRv6 In-Situ Active Measurement with IOAM . . . . . . . . . . 4 74 4. Network Operation . . . . . . . . . . . . . . . . . . . . . . 5 75 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 6 76 6. Probing Packet Type Extension . . . . . . . . . . . . . . . . 7 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 82 10.2. Informative References . . . . . . . . . . . . . . . . . 8 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 85 1. Introduction 87 SRv6 network OAM needs various means to collect data, detect issues, 88 and measure its performance. [I-D.ietf-6man-spring-srv6-oam] 89 provides some mechanisms for SRv6 OAM. Some other general methods 90 for performance measurement such as [RFC8762] can also be applied for 91 SRv6. However, these methods have limited data coverage and 92 measurement capability. More mechanisms should be provided to enrich 93 the OAM coverage. 95 IOAM [I-D.ietf-ippm-ioam-data] can support extensible hop-by-hop data 96 collection for user traffic. It is beneficial for SRv6 network 97 monitor and measurement. Since it is designed for user-packet 98 measurement, [I-D.ali-spring-ioam-srv6] proposes to encapsulate IOAM 99 in SRH TLV options. 101 However, with its well-defined structure and functions, IOAM can also 102 be used for active measurement (i.e., in dedicated probing packets 103 without user payload) to fulfill many measurement tasks that are 104 inconvenient or infeasible to be applied on user traffic. For active 105 measurement, we can directly encapsulate the IOAM header and data in 106 the UDP-based probing packet payload. The similar method has been 107 proposed in [I-D.ietf-spring-stamp-srpm] to support STAMP for SRv6 108 measurement. IOAM is complement to STAMP by providing hop-by-hop 109 measurement capability. The high-level method can be generalized and 110 extended to support other performance measurement protocols under the 111 same framework. 113 Fully built on exiting protocol components, the SR-based active 114 measurement method using IOAM can support some useful applications. 115 For example, it can be used to support network-wide telemetry 116 coverage by using pre-planned paths 117 [I-D.tian-bupt-inwt-mechanism-policy]; it can be used to actively 118 measure the backup paths for SRv6 traffic engineering; and by setting 119 the path end as the path head in SRH, it can naturally support two- 120 way or round-trip measurement. 122 2. An Active Measurement Framework for SRv6 124 As specified by [RFC8754], the Segment Routing Header (SRH) contains 125 an 8-bit "Flags" field. This document defines the following flag bit 126 'T' to designate the packet as a dedicated probing packet for active 127 measurement. 129 0 1 2 3 4 5 6 7 130 +-+-+-+-+-+-+-+-+ 131 | |T| | 132 +-+-+-+-+-+-+-+-+ 134 Figure 1: A Hierarchical Edge Network 136 The O-bit defined in [I-D.ietf-6man-spring-srv6-oam] servers for user 137 traffic OAM, so the T-bit and O-bit are mutual exclusive. When T-bit 138 is set, O-bit must be cleared, and vice versa. 140 The Next Header of SRH is set to UDP. A destination UDP port is 141 reserved to encode the type of the payload. For example, a port 142 number has been proposed to be reserved for STAMP in 143 [I-D.ietf-spring-stamp-srpm]. Similarly, another port number should 144 be reserved for IOAM trace option. If the destination port number 145 matches the reserved values, the UDP payload would encapsulate the 146 corresponding protocol header. The source UDP port can be used or 147 ignored depending on each use case. The UDP checksum processing 148 procedure conforms to [RFC6936]. 150 3. SRv6 In-Situ Active Measurement with IOAM 152 We focus on a specific use case of the framework: using IOAM trace 153 option for hop-by-hop measurement. The IOAM header and data format 154 are specified in [I-D.ietf-ippm-ioam-data]. The complete active 155 probing packet format for IOAM is shown in Figure 2. The source UDP 156 port can be used as sequence number to track the probing packets on a 157 specific SR path. 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 160 |Ver (6)| Traffic Class | Flow Label | ^ 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 162 | Payload Length | NH : SRH | Hop Limit | | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 164 | Source Address (128 bits) | RFC 165 | + 8200 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 167 | Destination Address (128 bits) | | 168 | | V 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 170 | NH : UDP | Hdr Ext Len | Routing Type | Segments Left | ^ 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 172 | Last Entry | |1| Flags | Tag | | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RFC 174 | | 8754 175 | Segment List (m * 128 bits) | | 176 | | | 177 | | V 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 179 | Source Port (TBD) | Destination Port (TBD) | ^ 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+RFC768 181 | Length | Checksum | V 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 183 | Namespace-ID |NodeLen | Flags | RemainingLen| ^ 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 185 | IOAM-Trace-Type | Reserved | | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IOAM 187 | | | 188 | Node Data List (n * 32 bits) | | 189 | | | 190 | | V 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 193 Figure 2: The active probing packet format for IOAM trace option 195 4. Network Operation 197 To initiate an IOAM active measurement on a path, the probing packets 198 are generated at the SR source node. The source address is the 199 address of the SR source node and the destination address is the 200 address of first SR segment endpoint node. The SRH lists all the SR 201 segment endpoint nodes for which IOAM data will be collected. 203 Each SR node on the path including the source node, when detecting 204 the T-flag, in addition to normal SRH processing, will further parse 205 the UDP header and IOAM header, and as directed by the IOAM header, 206 add data to the IOAM node data list. 208 The last SR segment endpoint node will terminate the probing packet. 209 The collected data can be exported according to the specifications 210 for IOAM data export. 212 If an SR segment endpoint node on the path is incapable of processing 213 the probing packet, it should ignore the T-flag and continue 214 forwarding the packet. The last SR segment endpoint node MUST be 215 able to process and terminate the probing packets. 217 5. Applications 219 This section summarizes a list of applications of the SRv6 In-situ 220 Active Measurement (SIAM) approach. 222 * The method can be used as an alternative way for applying IOAM on 223 user traffic in SRv6, because the forwarding behavior in SRv6 224 networks is determined by the SRH. As long as a probing packet 225 has the same SRH as the user packet, the data collected can 226 faithfully reflect the user packet's forwarding experience along 227 the same path. In this case, in order to collect the on-path data 228 for a specific flow, all we need is to copy the SRH from the flow 229 packet and construct the probing packets. The probing packet rate 230 can match the original flow or arbitrarily configured. The edge 231 of the SR domain must terminate the probing packets to avoid 232 leakage. 234 * To support SRv6 traffic engineering, some alternative paths may be 235 pre-computed. It is desirable to constantly measure the 236 performance of these paths so the best path can be picked when a 237 flow is swapped. Since each path can be represented by an SRH, we 238 can construct the probing packets with these SRHs to actively 239 measure their status and performance. 241 * In an SRv6 network, it is easy to conduct round trip measurement 242 by setting the starting node and the end node of a path to the 243 same segment source node, and setting the destination node as an 244 intermediate node on the path. 246 * In order to detect or prevent gray network failures for SLA 247 guarantee, it is necessary to collect network-wide telemetry data 248 to gain full visibility within a SRv6 domain. We can apply the 249 algorithm described in [I-D.tian-bupt-inwt-mechanism-policy] to 250 calculate the minimum number of optimal SR paths to acheive the 251 full coverage, and construct probing packets on these paths. 253 6. Probing Packet Type Extension 255 The same framework can support other OAM protocols. In addition to 256 STAMP [I-D.ietf-spring-stamp-srpm], the active probing packets can 257 carry IOAM E2E option header and data[I-D.ietf-ippm-ioam-data], IOAM 258 DEX option header [I-D.ietf-ippm-ioam-direct-export], and other OAM 259 options. It is easy to use different reserved UDP port numbers to 260 differentiate the payload types. 262 7. Security Considerations 264 TBD 266 8. IANA Considerations 268 An SRH Flag bit 'T'. The bit position TBD 270 Optional UDP destination port numbers indicating different IOAM 271 options (TBD) 273 9. Acknowledgments 275 We acknowledge the comments and suggestions from Greg Mirsky and 276 Tianran Zhou which help to improve this document. 278 10. References 280 10.1. Normative References 282 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 283 Requirement Levels", BCP 14, RFC 2119, 284 DOI 10.17487/RFC2119, March 1997, 285 . 287 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 288 for the Use of IPv6 UDP Datagrams with Zero Checksums", 289 RFC 6936, DOI 10.17487/RFC6936, April 2013, 290 . 292 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 293 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 294 May 2017, . 296 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 297 (IPv6) Specification", STD 86, RFC 8200, 298 DOI 10.17487/RFC8200, July 2017, 299 . 301 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 302 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 303 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 304 . 306 10.2. Informative References 308 [I-D.ali-spring-ioam-srv6] 309 Ali, Z., Gandhi, R., Filsfils, C., Brockners, F., Nainar, 310 N., Pignataro, C., Li, C., Chen, M., and G. Dawra, 311 "Segment Routing Header encapsulation for In-situ OAM 312 Data", Work in Progress, Internet-Draft, draft-ali-spring- 313 ioam-srv6-05, 12 January 2022, . 316 [I-D.ietf-6man-spring-srv6-oam] 317 Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. 318 Chen, "Operations, Administration, and Maintenance (OAM) 319 in Segment Routing Networks with IPv6 Data plane (SRv6)", 320 Work in Progress, Internet-Draft, draft-ietf-6man-spring- 321 srv6-oam-13, 23 January 2022, 322 . 325 [I-D.ietf-ippm-ioam-data] 326 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 327 for In-situ OAM", Work in Progress, Internet-Draft, draft- 328 ietf-ippm-ioam-data-17, 13 December 2021, 329 . 332 [I-D.ietf-ippm-ioam-direct-export] 333 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 334 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 335 OAM Direct Exporting", Work in Progress, Internet-Draft, 336 draft-ietf-ippm-ioam-direct-export-07, 13 October 2021, 337 . 340 [I-D.ietf-spring-stamp-srpm] 341 Gandhi, R., Filsfils, C., Voyer, D., Chen, M., Janssens, 342 B., and R. Foote, "Performance Measurement Using Simple 343 TWAMP (STAMP) for Segment Routing Networks", Work in 344 Progress, Internet-Draft, draft-ietf-spring-stamp-srpm-03, 345 1 February 2022, . 348 [I-D.tian-bupt-inwt-mechanism-policy] 349 Pan, T., Gao, M., Song, E., Bian, Z., and X. Lin, "In-band 350 Network-Wide Telemetry", Work in Progress, Internet-Draft, 351 draft-tian-bupt-inwt-mechanism-policy-01, 25 October 2020, 352 . 355 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 356 Two-Way Active Measurement Protocol", RFC 8762, 357 DOI 10.17487/RFC8762, March 2020, 358 . 360 Authors' Addresses 362 Haoyu Song 363 Futurewei Technologies 364 Santa Clara, 365 United States of America 366 Email: haoyu.song@futurewei.com 368 Gyan Mishra 369 Verizon Inc. 370 Email: gyan.s.mishra@verizon.com 372 Tian Pan 373 BUPT 374 Email: pan@bupt.edu.cn