idnits 2.17.1 draft-song-spring-siam-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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. 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 (6 December 2021) is 870 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 (-06) exists of draft-ali-spring-ioam-srv6-04 == Outdated reference: A later version (-13) exists of draft-ietf-6man-spring-srv6-oam-12 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-16 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 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 T. Pan 5 Expires: 9 June 2022 BUPT 6 6 December 2021 8 SRv6 In-situ Active Measurement 9 draft-song-spring-siam-02 11 Abstract 13 This draft describes a data-plane in-band active measurement method 14 for SRv6. A packet containing an SRH uses a flag bit to indicate it 15 is an active probing packet. The measurement information, such as 16 the IOAM header and data, is encapsulated in UDP payload. The 17 probing packet originates from a segment source node and terminates 18 at a configured segment endpoint node. Each segment node on the 19 path, when detecting the flag, parses the UDP header and the payload. 20 In case of IOAM, the node adds data to the IOAM node data fields. 21 The method avoids the performance and encapsulation issues for 22 applying IOAM as well as other measurement techniques in SRv6 23 networks. Multiple applications can be supported by the method. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 29 "OPTIONAL" in this document are to be interpreted as described in BCP 30 14 [RFC2119][RFC8174] when, and only when, they appear in all 31 capitals, as shown here. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 9 June 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. In-situ Active Measurement for SRv6 . . . . . . . . . . . . . 3 68 3. Network Operation . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Applications . . . . . . . . . . . . . . . . . . . . . . . . 5 70 5. Probing Packet Type Extension . . . . . . . . . . . . . . . . 6 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 9.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 To support SRv6 network operation, we need various means to collect 82 data and measure the performance of SRv6 network. 83 [I-D.ietf-6man-spring-srv6-oam] provides some mechanisms for SRv6 84 OAM. Some other general methods for performance measurement such as 85 [RFC8762] can also be applied for SRv6. However, these methods have 86 limited data coverage and measurement capability. 88 [I-D.ietf-ippm-ioam-data] supports extensible data collection for 89 user traffic. It is beneficial for SRv6 network monitor and 90 measurement. [I-D.ali-spring-ioam-srv6] proposes to encapsulate IOAM 91 in SRH TLV. However, when applying to user packets, IOAM's overhead 92 may cause packet fragmentation and its processing may affect the 93 packet forwarding throughput. Moreover, due to the extension header 94 limitations asserted by [RFC8200], it is not easy to come up with a 95 scheme to encapsulate the IOAM header and data in other locations in 96 SRv6 user packets. 98 Fortunately, the forwarding behavior in SRv6 networks is determined 99 by the SRH. To conduct in-band measurement, the IOAM header and data 100 do not need to be added to user packets. Instead, they can be 101 encapsulated in an independent packet dedicated for measurement. As 102 long as this packet has the same SRH as the user packet, the data 103 collected can faithfully reflect the user packet's forwarding 104 experience, so the result is similar to that by applying IOAM on SRv6 105 user packets. This approach retains the benefits of in-situ 106 measurement but avoids the aforementioned issues. 108 In this case, the IOAM header and data processing can even be done in 109 slow path, without worrying about delaying the user traffic. Because 110 of this, the potential limitation of the forwarding hardware's header 111 processing capability (e.g., the header parsing depth) is no longer 112 an issue. 114 This SR-based active measurement approach also supports some other 115 applications. For example, it can be used to support network-wide 116 telemetry 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 The approach is built on existing protocol components with limited 123 extra requirements. 125 2. In-situ Active Measurement for SRv6 127 As specified by [RFC8754], the Segment Routing Header (SRH) contains 128 an 8-bit "Flags" field. This document defines the following flag bit 129 'T' to designate the packet as a dedicated probing packet for active 130 measurement. 132 0 1 2 3 4 5 6 7 133 +-+-+-+-+-+-+-+-+ 134 | |T| | 135 +-+-+-+-+-+-+-+-+ 137 Figure 1: A Hierarchical Edge Network 139 The O-bit defined in [I-D.ietf-6man-spring-srv6-oam] servers for user 140 traffic OAM, so the T-bit and O-bit are mutual exclusive. When T-bit 141 is set, O-bit must be cleared, and vice versa. 143 The Next Header of SRH is set to UDP. A destination UDP port is 144 reserved to encode the type of the payload. For example, a port 145 number is reserved for IOAM. If the destination port number is of 146 the IOAM type, the UDP payload would encapsulate the IOAM header and 147 data as specified in [I-D.ietf-ippm-ioam-data]. The source UDP port 148 can be used as sequence number to track the probing packets on a 149 specific SR path. 151 The complete active probing packet format for IOAM is shown in 152 Figure 2. 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 155 |Ver (6)| Traffic Class | Flow Label | ^ 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 157 | Payload Length | NH : SRH | Hop Limit | | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 159 | Source Address (128 bits) | RFC8200 160 | + | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 162 | Destination Address (128 bits) | | 163 | | V 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 165 | NH : UDP | Hdr Ext Len | Routing Type | Segments Left | ^ 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 167 | Last Entry | |1| Flags | Tag | | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RFC8754 169 | | | 170 | Segment List (m * 128 bits) | | 171 | | | 172 | | V 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 174 | Source Port (TBD) | Destination Port (TBD) | ^ 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RFC768 176 | Length | Checksum | V 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 178 | Namespace-ID |NodeLen | Flags | RemainingLen| ^ 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 180 | IOAM-Trace-Type | Reserved | | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IOAM 182 | | | 183 | Node Data List (n * 32 bits) | | 184 | | | 185 | | V 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 188 Figure 2: The active probing packet format for IOAM 190 3. Network Operation 192 The SR source node constructs the probing packets. The source 193 address is the address of the SR source node and the destination 194 address is the address of first SR segment endpoint node. The SRH 195 lists all the SR segment endpoint nodes for which IOAM data will be 196 collected. 198 Each SR node on the path, when detecting the T-flag, in addition to 199 normal SRH processing, will further parse the UDP header and IOAM 200 header, and as directed by the IOAM header, add data to the IOAM node 201 data list. 203 The last SR segment endpoint node will terminate the probing packet. 204 The collected data can be exported and analyzed according to 205 configuration. 207 If an SR segment endpoint node on the path is incapable of processing 208 the probing packet, it should ignore the T-flag and continue 209 forwarding the packet. 211 4. Applications 213 This section summarizes a list of applications of the SRv6 In-situ 214 Active Measurement (SIAM) approach. 216 * As described in Section 1, this is an easy way to apply IOAM in 217 SRv6. In order to collect the on-path data for a specific flow, 218 all we need is to copy the SRH from the flow packet and construct 219 the probing packets. The probing packet rate can match the 220 original flow or arbitrarily configured. The edge of the SR 221 domain must terminate the probing packets to avoid leakage. 223 * To support SRv6 traffic engineering, some alternative paths may be 224 pre-computed. It is desirable to measure the performance of these 225 paths so the best path can be picked when a flow is swapped. 226 Since each path can be represented by an SRH, we can construct the 227 probing packets with these SRHs to actively measure their status 228 and performance. 230 * In an SRv6 network, it is easy to conduct round trip measurement 231 by setting the starting node and the end node of a path to the 232 same segment source node, and setting the destination node as an 233 intermediate node on the path. 235 * To collect the network wide telemetry data and gain global 236 visibility within a SRv6 domain, we can apply the algorithm 237 described in [I-D.tian-bupt-inwt-mechanism-policy] to calculate 238 the optimal SR paths, and construct probing packets on these 239 paths. 241 5. Probing Packet Type Extension 243 The same scheme is also suitable for other types of probing packets. 244 For example, The probing packets can carry IOAM E2E option header and 245 data, IOAM DEX option header, and other OAM headers and data. It is 246 easy to use different reserved UDP port numbers to differentiate the 247 payload types. 249 6. Security Considerations 251 7. IANA Considerations 253 An SRH Flag bit 'T'. The bit position TBD 255 Optional UDP destination port numbers indicating different IOAM 256 options (TBD) 258 8. Acknowledgments 260 9. References 262 9.1. Normative References 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, 266 DOI 10.17487/RFC2119, March 1997, 267 . 269 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 270 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 271 May 2017, . 273 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 274 (IPv6) Specification", STD 86, RFC 8200, 275 DOI 10.17487/RFC8200, July 2017, 276 . 278 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 279 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 280 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 281 . 283 9.2. Informative References 285 [I-D.ali-spring-ioam-srv6] 286 Ali, Z., Gandhi, R., Filsfils, C., Brockners, F., Nainar, 287 N., Pignataro, C., Li, C., Chen, M., and G. Dawra, 288 "Segment Routing Header encapsulation for In-situ OAM 289 Data", Work in Progress, Internet-Draft, draft-ali-spring- 290 ioam-srv6-04, 12 July 2021, . 293 [I-D.ietf-6man-spring-srv6-oam] 294 Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. 295 Chen, "Operations, Administration, and Maintenance (OAM) 296 in Segment Routing Networks with IPv6 Data plane (SRv6)", 297 Work in Progress, Internet-Draft, draft-ietf-6man-spring- 298 srv6-oam-12, 28 November 2021, 299 . 302 [I-D.ietf-ippm-ioam-data] 303 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 304 for In-situ OAM", Work in Progress, Internet-Draft, draft- 305 ietf-ippm-ioam-data-16, 8 November 2021, 306 . 309 [I-D.tian-bupt-inwt-mechanism-policy] 310 Pan, T., Gao, M., Song, E., Bian, Z., and X. Lin, "In-band 311 Network-Wide Telemetry", Work in Progress, Internet-Draft, 312 draft-tian-bupt-inwt-mechanism-policy-01, 25 October 2020, 313 . 316 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 317 Two-Way Active Measurement Protocol", RFC 8762, 318 DOI 10.17487/RFC8762, March 2020, 319 . 321 Authors' Addresses 322 Haoyu Song 323 Futurewei Technologies 324 Santa Clara, 325 United States of America 327 Email: haoyu.song@futurewei.com 329 Tian Pan 330 BUPT 331 Beijing 332 China 334 Email: pan@bupt.edu.cn