idnits 2.17.1 draft-ietf-ippm-ioam-direct-export-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 (February 17, 2021) is 1163 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 (-17) exists of draft-ietf-ippm-ioam-data-11 == Outdated reference: A later version (-10) exists of draft-ietf-ippm-ioam-flags-03 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-08 == Outdated reference: A later version (-07) exists of draft-spiegel-ippm-ioam-rawexport-04 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM H. Song 3 Internet-Draft Futurewei 4 Intended status: Standards Track B. Gafni 5 Expires: August 21, 2021 Nvidia 6 T. Zhou 7 Z. Li 8 Huawei 9 F. Brockners 10 Cisco 11 S. Bhandari, Ed. 12 Thoughtspot 13 R. Sivakolundu 14 Cisco 15 T. Mizrahi, Ed. 16 Huawei 17 February 17, 2021 19 In-situ OAM Direct Exporting 20 draft-ietf-ippm-ioam-direct-export-03 22 Abstract 24 In-situ Operations, Administration, and Maintenance (IOAM) is used 25 for recording and collecting operational and telemetry information. 26 Specifically, IOAM allows telemetry data to be pushed into data 27 packets while they traverse the network. This document introduces a 28 new IOAM option type called the Direct Export (DEX) option, which is 29 used as a trigger for IOAM data to be directly exported without being 30 pushed into in-flight data packets. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 21, 2021. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 69 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. The Direct Exporting (DEX) IOAM Option Type . . . . . . . . . 3 71 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3.2. The DEX Option Format . . . . . . . . . . . . . . . . . . 5 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 74 4.1. IOAM Type . . . . . . . . . . . . . . . . . . . . . . . . 6 75 4.2. IOAM DEX Flags . . . . . . . . . . . . . . . . . . . . . 6 76 5. Performance Considerations . . . . . . . . . . . . . . . . . 6 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 7.2. Informative References . . . . . . . . . . . . . . . . . 8 81 Appendix A. Hop Limit and Hop Count in Direct Exporting . . . . 8 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Introduction 86 IOAM [I-D.ietf-ippm-ioam-data] is used for monitoring traffic in the 87 network, and for incorporating IOAM data fields into in-flight data 88 packets. 90 IOAM makes use of four possible IOAM options, defined in 91 [I-D.ietf-ippm-ioam-data]: Pre-allocated Trace Option, Incremental 92 Trace Option, Proof of Transit (POT) Option, and Edge-to-Edge Option. 94 This document defines a new IOAM option type (also known as an IOAM 95 type) called the Direct Export (DEX) option. This option is used as 96 a trigger for IOAM nodes to export IOAM data to a receiving entity 97 (or entities). A "receiving entity" in this context can be, for 98 example, an external collector, analyzer, controller, decapsulating 99 node, or a software module in one of the IOAM nodes. 101 This draft has evolved from combining some of the concepts of PBT-I 102 from [I-D.song-ippm-postcard-based-telemetry] with immediate 103 exporting from [I-D.ietf-ippm-ioam-flags]. 105 2. Conventions 107 2.1. Requirement Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in BCP 112 14 [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 2.2. Terminology 117 Abbreviations used in this document: 119 IOAM: In-situ Operations, Administration, and Maintenance 121 OAM: Operations, Administration, and Maintenance 123 DEX: Direct EXporting 125 3. The Direct Exporting (DEX) IOAM Option Type 127 3.1. Overview 129 The DEX option is used as a trigger for exporting telemetry data to a 130 receiving entity (or entities). 132 This option is incorporated into data packets by an IOAM 133 encapsulating node, and removed by an IOAM decapsulating node, as 134 illustrated in Figure 1. The option can be read but not modified by 135 transit nodes. Note: the terms IOAM encapsulating, decapsulating and 136 transit nodes are as defined in [I-D.ietf-ippm-ioam-data]. 138 ^ 139 |Exported IOAM data 140 | 141 | 142 | 143 +--------------+------+-------+--------------+ 144 | | | | 145 | | | | 146 User +---+----+ +---+----+ +---+----+ +---+----+ 147 packets |Encapsu-| | Transit| | Transit| |Decapsu-| 148 --------->|lating |====>| Node |====>| Node |====>|lating |----> 149 |Node | | A | | B | |Node | 150 +--------+ +--------+ +--------+ +--------+ 151 Insert DEX Export Export Remove DEX 152 option and IOAM data IOAM data option and 153 export data export data 155 Figure 1: DEX Architecture 157 The DEX option is used as a trigger to export IOAM data. The trigger 158 applies to transit nodes, the decapsulating node, and the 159 encapsulating node: 161 o An IOAM encapsulating node configured to incorporate the DEX 162 option encapsulates the packet with the DEX option, and MAY export 163 the requested IOAM data immediately. The IOAM encapsulating node 164 is the only type of node allowed to push the DEX option. 166 o A transit node that processes a packet with the DEX option MAY 167 export the requested IOAM data. 169 o An IOAM decapsulating node that processes a packet with the DEX 170 option MAY export the requested IOAM data, and MUST decapsulate 171 the IOAM header. 173 As in [I-D.ietf-ippm-ioam-data], the DEX option may be incorporated 174 into all or a subset of the traffic that is forwarded by the 175 encapsulating node. Moreover, IOAM nodes MAY export data for all 176 traversing packets that carry the DEX option, or MAY selectively 177 export data only for a subset of these packets. 179 The DEX option specifies which data fields should be exported, as 180 specified in Section 3.2. The format and encapsulation of the packet 181 that contains the exported data is not within the scope of the 182 current document. For example, the export format can be based on 183 [I-D.spiegel-ippm-ioam-rawexport]. 185 A transit IOAM node that does not support the DEX option SHOULD 186 ignore it. A decapsulating node that does not support the DEX option 187 MUST remove it, along with any other IOAM options carried in the 188 packet if such exist. 190 3.2. The DEX Option Format 192 The format of the DEX option is depicted in Figure 2. The length of 193 the DEX option is either 8 octets or 16 octets, as the Flow ID and 194 the Sequence Number fields (summing up to 8 octets) are optional. It 195 is assumed that the lower layer protocol indicates the length of the 196 DEX option, thus indicating whether the two optional fields are 197 present. 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Namespace-ID | Flags | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | IOAM-Trace-Type | Reserved | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Flow ID (optional) | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Sequence Number (Optional) | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 Figure 2: DEX Option Format 213 Namespace-ID A 16-bit identifier of the IOAM namespace, as defined 214 in [I-D.ietf-ippm-ioam-data]. 216 Flags A 16-bit field, comprised of 16 one-bit subfields. 217 Flags are allocated by IANA, as defined in 218 Section 4.2. 220 IOAM-Trace-Type A 24-bit identifier which specifies which data fields 221 should be exported. The format of this field is as 222 defined in [I-D.ietf-ippm-ioam-data]. Specifically, 223 bit 23, which corresponds to the Checksum Complement 224 data field, should be assigned to be zero by the IOAM 225 encapsulating node, and ignored by transit and 226 decapsulating nodes. The reason for this is that the 227 Checksum Complement is intended for in-flight packet 228 modifications and is not relevant for direct 229 exporting. 231 Reserved This field SHOULD be ignored by the receiver. 233 Flow ID A 32-bit flow identifier. If the actual Flow ID is 234 shorter than 32 bits, it is zero padded in its most 235 significant bits. The field is set at the 236 encapsulating node. The Flow ID can be uniformly 237 assigned by a central controller or algorithmically 238 generated by the encapsulating node. The latter 239 approach cannot guarantee the uniqueness of Flow ID, 240 yet the conflict probability is small due to the 241 large Flow ID space. The Flow ID can be used to 242 correlate the exported data of the same flow from 243 multiple nodes and from multiple packets. 245 Sequence Number A 32-bit sequence number starting from 0 and 246 increasing by 1 for each following monitored packet 247 from the same flow at the encapsulating node. The 248 Sequence Number, when combined with the Flow ID, 249 provides a convenient approach to correlate the 250 exported data from the same user packet. 252 4. IANA Considerations 254 4.1. IOAM Type 256 The "IOAM Type Registry" was defined in Section 7.2 of 257 [I-D.ietf-ippm-ioam-data]. IANA is requested to allocate the 258 following code point from the "IOAM Type Registry" as follows: 260 TBD-type IOAM Direct Export (DEX) Option Type 262 If possible, IANA is requested to allocate code point 4 (TBD-type). 264 4.2. IOAM DEX Flags 266 IANA is requested to define an "IOAM DEX Flags" registry. This 267 registry includes 16 flag bits. Allocation should be performed based 268 on the "RFC Required" procedure, as defined in [RFC8126]. 270 5. Performance Considerations 272 The DEX option triggers exported packets to be exported to a 273 receiving entity (or entities). In some cases this may impact the 274 receiving entity's performance, or the performance along the paths 275 leading to it. 277 Therefore, rate limiting may be enabled so as to ensure that direct 278 exporting is used at a rate that does not significantly affect the 279 network bandwidth, and does not overload the receiving entity (or the 280 source node in the case of loopback). It should be possible to use 281 each DEX on a subset of the data traffic, and to load balance the 282 exported data among multiple receiving entities. 284 6. Security Considerations 286 The security considerations of IOAM in general are discussed in 287 [I-D.ietf-ippm-ioam-data]. Specifically, an attacker may try to use 288 the functionality that is defined in this document to attack the 289 network. 291 An attacker may attempt to overload network devices by injecting 292 synthetic packets that include the DEX option. Similarly, an on-path 293 attacker may maliciously incorporate the DEX option into transit 294 packets, or maliciously remove it from packets in which it is 295 incorporated. 297 Forcing DEX, either in synthetic packets or in transit packets may 298 overload the receiving entity (or entities). Since this mechanism 299 affects multiple devices along the network path, it potentially 300 amplifies the effect on the network bandwidth and on the receiving 301 entity's load. 303 The amplification effect of DEX may be worse in wide area networks in 304 which there are multiple IOAM domains. For example, if DEX is used 305 in IOAM domain 1 for exporting IOAM data to a receiving entity, then 306 the exported packets of domain 1 can be forwarded through IOAM domain 307 2, in which they are subject to DEX. The exported packets of domain 308 2 may in turn be forwarded through another IOAM domain (or through 309 domain 1), and theoretically this recursive amplification may 310 continue infinitely. 312 In order to mitigate the attacks described above, it should be 313 possible for IOAM-enabled devices to limit the exported IOAM data to 314 a configurable rate. 316 IOAM is assumed to be deployed in a restricted administrative domain, 317 thus limiting the scope of the threats above and their affect. This 318 is a fundamental assumption with respect to the security aspects of 319 IOAM, as further discussed in [I-D.ietf-ippm-ioam-data]. 321 7. References 322 7.1. Normative References 324 [I-D.ietf-ippm-ioam-data] 325 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 326 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 327 progress), November 2020. 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, 331 DOI 10.17487/RFC2119, March 1997, 332 . 334 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 335 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 336 May 2017, . 338 7.2. Informative References 340 [I-D.ietf-ippm-ioam-flags] 341 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 342 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 343 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-03 344 (work in progress), October 2020. 346 [I-D.song-ippm-postcard-based-telemetry] 347 Song, H., Zhou, T., Li, Z., Mirsky, G., Shin, J., and K. 348 Lee, "Postcard-based On-Path Flow Data Telemetry using 349 Packet Marking", draft-song-ippm-postcard-based- 350 telemetry-08 (work in progress), October 2020. 352 [I-D.spiegel-ippm-ioam-rawexport] 353 Spiegel, M., Brockners, F., Bhandari, S., and R. 354 Sivakolundu, "In-situ OAM raw data export with IPFIX", 355 draft-spiegel-ippm-ioam-rawexport-04 (work in progress), 356 November 2020. 358 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 359 Writing an IANA Considerations Section in RFCs", BCP 26, 360 RFC 8126, DOI 10.17487/RFC8126, June 2017, 361 . 363 Appendix A. Hop Limit and Hop Count in Direct Exporting 365 In order to help correlate and order the exported packets, it is 366 possible to include the Hop_Lim/Node_ID data field in exported 367 packets; if the IOAM-Trace-Type [I-D.ietf-ippm-ioam-data] has the 368 Hop_Lim/Node_ID bit set, then exported packets include the Hop_Lim/ 369 Node_ID data field, which contains the TTL/Hop Limit value from a 370 lower layer protocol. 372 An alternative approach was considered during the design of this 373 document, according to which a 1-octet Hop Count field would be 374 included in the DEX header (presumably by claiming some space from 375 the Flags field). The Hop Limit would starts from 0 at the 376 encapsulating node and be incremented by each IOAM transit node that 377 supports the DEX option. In this approach the Hop Count field value 378 would also be included in the exported packet. 380 The main advantage of the Hop_Lim/Node_ID approach is that it 381 provides information about the current hop count without requiring 382 each transit node to modify the DEX option, thus simplifying the data 383 plane functionality of Direct Exporting. The main advantage of the 384 Hop Count approach that was considered is that it counts the number 385 of IOAM-capable nodes without relying on the lower layer TTL, 386 especially when the lower layer cannot prvide the accurate TTL 387 information, e.g., Layer 2 Ethernet or hierarchical VPN. The Hop 388 Count approach would also explicitly allow to detect a case where an 389 IOAM-capable node fails to export packets. It would also be possible 390 to use a flag to indicate an optional Hop Count field, which enables 391 to control the tradeoff. On one hand it would address the use cases 392 that the Hop_Lim/Node_ID cannot cover, and on the other hand it would 393 not require transit switches to update the option if it was not 394 supported or disabled. For the sake of simplicity the Hop Count 395 approach was not pursued, and this field is not incorporated in the 396 DEX header. 398 Authors' Addresses 400 Haoyu Song 401 Futurewei 402 2330 Central Expressway 403 Santa Clara 95050 404 USA 406 Email: haoyu.song@huawei.com 408 Barak Gafni 409 Nvidia 410 350 Oakmead Parkway, Suite 100 411 Sunnyvale, CA 94085 412 U.S.A. 414 Email: gbarak@nvidia.com 415 Tianran Zhou 416 Huawei 417 156 Beiqing Rd. 418 Beijing 100095 419 China 421 Email: zhoutianran@huawei.com 423 Zhenbin Li 424 Huawei 425 156 Beiqing Rd. 426 Beijing 100095 427 China 429 Email: lizhenbin@huawei.com 431 Frank Brockners 432 Cisco Systems, Inc. 433 Hansaallee 249, 3rd Floor 434 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 435 Germany 437 Email: fbrockne@cisco.com 439 Shwetha Bhandari (editor) 440 Thoughtspot 441 3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout 442 Bangalore, KARNATAKA 560 102 443 India 445 Email: shwetha.bhandari@thoughtspot.com 447 Ramesh Sivakolundu 448 Cisco Systems, Inc. 449 170 West Tasman Dr. 450 SAN JOSE, CA 95134 451 U.S.A. 453 Email: sramesh@cisco.com 454 Tal Mizrahi (editor) 455 Huawei 456 8-2 Matam 457 Haifa 3190501 458 Israel 460 Email: tal.mizrahi.phd@gmail.com