idnits 2.17.1 draft-ietf-ippm-ioam-direct-export-01.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 (August 5, 2020) is 1350 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-10 == Outdated reference: A later version (-10) exists of draft-ietf-ippm-ioam-flags-02 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-07 == Outdated reference: A later version (-07) exists of draft-spiegel-ippm-ioam-rawexport-03 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: February 6, 2021 Mellanox Technologies, Inc. 6 T. Zhou 7 Z. Li 8 Huawei 9 F. Brockners 10 S. Bhandari 11 R. Sivakolundu 12 Cisco 13 T. Mizrahi, Ed. 14 Huawei Smart Platforms iLab 15 August 5, 2020 17 In-situ OAM Direct Exporting 18 draft-ietf-ippm-ioam-direct-export-01 20 Abstract 22 In-situ Operations, Administration, and Maintenance (IOAM) is used 23 for recording and collecting operational and telemetry information. 24 Specifically, IOAM allows telemetry data to be pushed into data 25 packets while they traverse the network. This document introduces a 26 new IOAM option type called the Direct Export (DEX) option, which is 27 used as a trigger for IOAM data to be directly exported without being 28 pushed into in-flight data packets. 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 February 6, 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. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 67 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. The Direct Exporting (DEX) IOAM Option Type . . . . . . . . . 3 69 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3.2. The DEX Option Format . . . . . . . . . . . . . . . . . . 5 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 72 4.1. IOAM Type . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4.2. IOAM DEX Flags . . . . . . . . . . . . . . . . . . . . . 6 74 5. Performance Considerations . . . . . . . . . . . . . . . . . 6 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 7. Topics for Further Discussion . . . . . . . . . . . . . . . . 7 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 79 8.2. Informative References . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 IOAM [I-D.ietf-ippm-ioam-data] is used for monitoring traffic in the 85 network, and for incorporating IOAM data fields into in-flight data 86 packets. 88 IOAM makes use of four possible IOAM options, defined in 89 [I-D.ietf-ippm-ioam-data]: Pre-allocated Trace Option, Incremental 90 Trace Option, Proof of Transit (POT) Option, and Edge-to-Edge Option. 92 This document defines a new IOAM option type (also known as an IOAM 93 type) called the Direct Export (DEX) option. This option is used as 94 a trigger for IOAM nodes to export IOAM data to a receiving entity 95 (or entities). A "receiving entity" in this context can be, for 96 example, an external collector, analyzer, controller, decapsulating 97 node, or a software module in one of the IOAM nodes. 99 This draft has evolved from combining some of the concepts of PBT-I 100 from [I-D.song-ippm-postcard-based-telemetry] with immediate 101 exporting from [I-D.ietf-ippm-ioam-flags]. 103 2. Conventions 105 2.1. Requirement Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 2.2. Terminology 113 Abbreviations used in this document: 115 IOAM: In-situ Operations, Administration, and Maintenance 117 OAM: Operations, Administration, and Maintenance 119 DEX: Direct EXporting 121 3. The Direct Exporting (DEX) IOAM Option Type 123 3.1. Overview 125 The DEX option is used as a trigger for exporting telemetry data to a 126 receiving entity (or entities). 128 This option is incorporated into data packets by an IOAM 129 encapsulating node, and removed by an IOAM decapsulating node, as 130 illustrated in Figure 1. The option can be read but not modified by 131 transit nodes. Note: the terms IOAM encapsulating, decapsulating and 132 transit nodes are as defined in [I-D.ietf-ippm-ioam-data]. 134 ^ 135 |Exported IOAM data 136 | 137 | 138 | 139 +--------------+------+-------+--------------+ 140 | | | | 141 | | | | 142 User +---+----+ +---+----+ +---+----+ +---+----+ 143 packets |Encapsu-| | Transit| | Transit| |Decapsu-| 144 --------->|lating |====>| Node |====>| Node |====>|lating |----> 145 |Node | | A | | B | |Node | 146 +--------+ +--------+ +--------+ +--------+ 147 Insert DEX Export Export Remove DEX 148 option and IOAM data IOAM data option and 149 export data export data 151 Figure 1: DEX Architecture 153 The DEX option is used as a trigger to export IOAM data. The trigger 154 applies to transit nodes, the decapsulating node, and the 155 encapsulating node: 157 o An IOAM encapsulating node configured to incorporate the DEX 158 option encapsulates the packet with the DEX option, and MAY export 159 the requested IOAM data immediately. The IOAM encapsulating node 160 is the only type of node allowed to push the DEX option. 162 o A transit node that processes a packet with the DEX option MAY 163 export the requested IOAM data. 165 o An IOAM decapsulating node that processes a packet with the DEX 166 option MAY export the requested IOAM data, and MUST decapsulate 167 the IOAM header. 169 As in [I-D.ietf-ippm-ioam-data], the DEX option may be incorporated 170 into all or a subset of the traffic that is forwarded by the 171 encapsulating node. Moreover, IOAM nodes MAY export data for all 172 traversing packets that carry the DEX option, or MAY selectively 173 export data only for a subset of these packets. 175 The DEX option specifies which data fields should be exported, as 176 specified in Section 3.2. The format and encapsulation of the packet 177 that contains the exported data is not within the scope of the 178 current document. For example, the export format can be based on 179 [I-D.spiegel-ippm-ioam-rawexport]. 181 A transit IOAM node that does not support the DEX option SHOULD 182 ignore it. A decapsulating node that does not support the DEX option 183 MUST remove it, along with any other IOAM options carried in the 184 packet if such exist. 186 3.2. The DEX Option Format 188 The format of the DEX option is depicted in Figure 2. The length of 189 the DEX option is either 8 octets or 16 octets, as the Flow ID and 190 the Sequence Number fields (summing up to 8 octets) are optional. It 191 is assumed that the lower layer protocol indicates the length of the 192 DEX option, thus indicating whether the two optional fields are 193 present. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Namespace-ID | Flags | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | IOAM-Trace-Type | Reserved | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Flow ID (optional) | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Sequence Number (Optional) | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Figure 2: DEX Option Format 209 Namespace-ID A 16-bit identifier of the IOAM namespace, as defined 210 in [I-D.ietf-ippm-ioam-data]. 212 Flags A 16-bit field, comprised of 16 one-bit subfields. 213 Flags are allocated by IANA, as defined in 214 Section 4.2. 216 IOAM-Trace-Type A 24-bit identifier which specifies which data fields 217 should be exported. The format of this field is as 218 defined in [I-D.ietf-ippm-ioam-data]. Specifically, 219 bit 23, which corresponds to the Checksum Complement 220 data field, should be assigned to be zero by the IOAM 221 encapsulating node, and ignored by transit and 222 decapsulating nodes. The reason for this is that the 223 Checksum Complement is intended for in-flight packet 224 modifications and is not relevant for direct 225 exporting. 227 Reserved This field SHOULD be ignored by the receiver. 229 Flow ID A 32-bit flow identifier. If the actual Flow ID is 230 shorter than 32 bits, it is zero padded in its most 231 significant bits. The field is set at the 232 encapsulating node. The Flow ID can be uniformly 233 assigned by a central controller or algorithmically 234 generated by the encapsulating node. The latter 235 approach cannot guarantee the uniqueness of Flow ID, 236 yet the conflict probability is small due to the 237 large Flow ID space. The Flow ID can be used to 238 correlate the exported data of the same flow from 239 multiple nodes and from multiple packets. 241 Sequence Number A 32-bit sequence number starting from 0 and 242 increasing by 1 for each following monitored packet 243 from the same flow at the encapsulating node. The 244 Sequence Number, when combined with the Flow ID, 245 provides a convenient approach to correlate the 246 exported data from the same user packet. 248 4. IANA Considerations 250 4.1. IOAM Type 252 The "IOAM Type Registry" was defined in Section 7.2 of 253 [I-D.ietf-ippm-ioam-data]. IANA is requested to allocate the 254 following code point from the "IOAM Type Registry" as follows: 256 TBD-type IOAM Direct Export (DEX) Option Type 258 If possible, IANA is requested to allocate code point 4 (TBD-type). 260 4.2. IOAM DEX Flags 262 IANA is requested to define an "IOAM DEX Flags" registry. This 263 registry includes 16 flag bits. Allocation should be performed based 264 on the "RFC Required" procedure, as defined in [RFC8126]. 266 5. Performance Considerations 268 The DEX option triggers exported packets to be exported to a 269 receiving entity (or entities). In some cases this may impact the 270 receiving entity's performance, or the performance along the paths 271 leading to it. 273 Therefore, rate limiting may be enabled so as to ensure that direct 274 exporting is used at a rate that does not significantly affect the 275 network bandwidth, and does not overload the receiving entity (or the 276 source node in the case of loopback). It should be possible to use 277 each DEX on a subset of the data traffic, and to load balance the 278 exported data among multiple receiving entities. 280 6. Security Considerations 282 The security considerations of IOAM in general are discussed in 283 [I-D.ietf-ippm-ioam-data]. Specifically, an attacker may try to use 284 the functionality that is defined in this document to attack the 285 network. 287 An attacker may attempt to overload network devices by injecting 288 synthetic packets that include the DEX option. Similarly, an on-path 289 attacker may maliciously incorporate the DEX option into transit 290 packets, or maliciously remove it from packets in which it is 291 incorporated. 293 Forcing DEX, either in synthetic packets or in transit packets may 294 overload the receiving entity (or entities). Since this mechanism 295 affects multiple devices along the network path, it potentially 296 amplifies the effect on the network bandwidth and on the receiving 297 entity's load. 299 In order to mitigate the attacks described above, it should be 300 possible for IOAM-enabled devices to limit the exported IOAM data to 301 a configurable rate. 303 IOAM is assumed to be deployed in a restricted administrative domain, 304 thus limiting the scope of the threats above and their affect. This 305 is a fundamental assumption with respect to the security aspects of 306 IOAM, as further discussed in [I-D.ietf-ippm-ioam-data]. 308 7. Topics for Further Discussion 310 o Hop Limit / Hop Count: in order to help correlate and order the 311 exported packets, it is possible to include a 1-octet Hop Count 312 field in the DEX header (presumably by claiming some space from 313 the Flags field). Its value starts from 0 at the encapsulating 314 node and is incremented by each IOAM transit node that supports 315 the DEX option. The Hop Count field value is also included in the 316 exported packet. An alternative approach is to use the Hop_Lim/ 317 Node_ID data field; if the IOAM-Trace-Type 318 [I-D.ietf-ippm-ioam-data] has the Hop_Lim/Node_ID bit set, then 319 exported packets include the Hop_Lim/Node_ID data field, which 320 contains the TTL/Hop Limit value from a lower layer protocol. The 321 main advantage of the Hop_Lim/Node_ID approach is that it provides 322 information about the current hop count without requiring each 323 transit node to modify the DEX option, thus simplifying the data 324 plane functionality of Direct Exporting. The main advantage of 325 the Hop Count approach is that it counts the number of IOAM- 326 capable nodes without relying on the lower layer TTL, especially 327 when the lower layer cannot prvide the accurate TTL information, 328 e.g., Layer 2 Ethernet or hierarchical VPN. It also explicitly 329 allows to detect a case where an IOAM-capable node fails to export 330 packets. In order to facilitate the Hop Count approach it is 331 possible to use a flag to indicate an optional Hop Count field, 332 which enables to control the tradeoff. On one hand it addresses 333 the use cases that the Hop_Lim/Node_ID cannot cover, and on the 334 other hand it does not require transit switches to update the 335 option if it is not supported or disabled. Further discussion is 336 required about the tradeoff between the two alternatives. 338 8. References 340 8.1. Normative References 342 [I-D.ietf-ippm-ioam-data] 343 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 344 for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in 345 progress), July 2020. 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, 349 DOI 10.17487/RFC2119, March 1997, 350 . 352 8.2. Informative References 354 [I-D.ietf-ippm-ioam-flags] 355 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 356 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 357 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-02 358 (work in progress), July 2020. 360 [I-D.song-ippm-postcard-based-telemetry] 361 Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, 362 "Postcard-based On-Path Flow Data Telemetry", draft-song- 363 ippm-postcard-based-telemetry-07 (work in progress), April 364 2020. 366 [I-D.spiegel-ippm-ioam-rawexport] 367 Spiegel, M., Brockners, F., Bhandari, S., and R. 368 Sivakolundu, "In-situ OAM raw data export with IPFIX", 369 draft-spiegel-ippm-ioam-rawexport-03 (work in progress), 370 March 2020. 372 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 373 Writing an IANA Considerations Section in RFCs", BCP 26, 374 RFC 8126, DOI 10.17487/RFC8126, June 2017, 375 . 377 Authors' Addresses 379 Haoyu Song 380 Futurewei 381 2330 Central Expressway 382 Santa Clara 95050 383 USA 385 Email: haoyu.song@huawei.com 387 Barak Gafni 388 Mellanox Technologies, Inc. 389 350 Oakmead Parkway, Suite 100 390 Sunnyvale, CA 94085 391 U.S.A. 393 Email: gbarak@mellanox.com 395 Tianran Zhou 396 Huawei 397 156 Beiqing Rd. 398 Beijing 100095 399 China 401 Email: zhoutianran@huawei.com 403 Zhenbin Li 404 Huawei 405 156 Beiqing Rd. 406 Beijing 100095 407 China 409 Email: lizhenbin@huawei.com 410 Frank Brockners 411 Cisco Systems, Inc. 412 Hansaallee 249, 3rd Floor 413 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 414 Germany 416 Email: fbrockne@cisco.com 418 Shwetha Bhandari 419 Cisco Systems, Inc. 420 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 421 Bangalore, KARNATAKA 560 087 422 India 424 Email: shwethab@cisco.com 426 Ramesh Sivakolundu 427 Cisco Systems, Inc. 428 170 West Tasman Dr. 429 SAN JOSE, CA 95134 430 U.S.A. 432 Email: sramesh@cisco.com 434 Tal Mizrahi (editor) 435 Huawei Smart Platforms iLab 436 8-2 Matam 437 Haifa 3190501 438 Israel 440 Email: tal.mizrahi.phd@gmail.com