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