idnits 2.17.1 draft-ietf-ippm-ioam-direct-export-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 : ---------------------------------------------------------------------------- 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 (November 1, 2020) is 1269 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-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-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: May 5, 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 November 1, 2020 17 In-situ OAM Direct Exporting 18 draft-ietf-ippm-ioam-direct-export-02 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 May 5, 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 78 7.2. Informative References . . . . . . . . . . . . . . . . . 8 79 Appendix A. Hop Limit and Hop Count in Direct Exporting . . . . 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. References 310 7.1. Normative References 312 [I-D.ietf-ippm-ioam-data] 313 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 314 for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in 315 progress), July 2020. 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, 319 DOI 10.17487/RFC2119, March 1997, 320 . 322 7.2. Informative References 324 [I-D.ietf-ippm-ioam-flags] 325 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 326 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 327 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-03 328 (work in progress), October 2020. 330 [I-D.song-ippm-postcard-based-telemetry] 331 Song, H., Zhou, T., Li, Z., Mirsky, G., Shin, J., and K. 332 Lee, "Postcard-based On-Path Flow Data Telemetry using 333 Packet Marking", draft-song-ippm-postcard-based- 334 telemetry-08 (work in progress), October 2020. 336 [I-D.spiegel-ippm-ioam-rawexport] 337 Spiegel, M., Brockners, F., Bhandari, S., and R. 338 Sivakolundu, "In-situ OAM raw data export with IPFIX", 339 draft-spiegel-ippm-ioam-rawexport-03 (work in progress), 340 March 2020. 342 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 343 Writing an IANA Considerations Section in RFCs", BCP 26, 344 RFC 8126, DOI 10.17487/RFC8126, June 2017, 345 . 347 Appendix A. Hop Limit and Hop Count in Direct Exporting 349 In order to help correlate and order the exported packets, it is 350 possible to include the Hop_Lim/Node_ID data field in exported 351 packets; if the IOAM-Trace-Type [I-D.ietf-ippm-ioam-data] has the 352 Hop_Lim/Node_ID bit set, then exported packets include the Hop_Lim/ 353 Node_ID data field, which contains the TTL/Hop Limit value from a 354 lower layer protocol. 356 An alternative approach was considered during the design of this 357 document, according to which a 1-octet Hop Count field would be 358 included in the DEX header (presumably by claiming some space from 359 the Flags field). The Hop Limit would starts from 0 at the 360 encapsulating node and be incremented by each IOAM transit node that 361 supports the DEX option. In this approach the Hop Count field value 362 would also be included in the exported packet. 364 The main advantage of the Hop_Lim/Node_ID approach is that it 365 provides information about the current hop count without requiring 366 each transit node to modify the DEX option, thus simplifying the data 367 plane functionality of Direct Exporting. The main advantage of the 368 Hop Count approach that was considered is that it counts the number 369 of IOAM-capable nodes without relying on the lower layer TTL, 370 especially when the lower layer cannot prvide the accurate TTL 371 information, e.g., Layer 2 Ethernet or hierarchical VPN. The Hop 372 Count approach would also explicitly allow to detect a case where an 373 IOAM-capable node fails to export packets. It would also be possible 374 to use a flag to indicate an optional Hop Count field, which enables 375 to control the tradeoff. On one hand it would address the use cases 376 that the Hop_Lim/Node_ID cannot cover, and on the other hand it would 377 not require transit switches to update the option if it was not 378 supported or disabled. For the sake of simplicity the Hop Count 379 approach was not pursued, and this field is not incorporated in the 380 DEX header. 382 Authors' Addresses 384 Haoyu Song 385 Futurewei 386 2330 Central Expressway 387 Santa Clara 95050 388 USA 390 Email: haoyu.song@huawei.com 392 Barak Gafni 393 Mellanox Technologies, Inc. 394 350 Oakmead Parkway, Suite 100 395 Sunnyvale, CA 94085 396 U.S.A. 398 Email: gbarak@mellanox.com 400 Tianran Zhou 401 Huawei 402 156 Beiqing Rd. 403 Beijing 100095 404 China 406 Email: zhoutianran@huawei.com 408 Zhenbin Li 409 Huawei 410 156 Beiqing Rd. 411 Beijing 100095 412 China 414 Email: lizhenbin@huawei.com 415 Frank Brockners 416 Cisco Systems, Inc. 417 Hansaallee 249, 3rd Floor 418 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 419 Germany 421 Email: fbrockne@cisco.com 423 Shwetha Bhandari 424 Cisco Systems, Inc. 425 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 426 Bangalore, KARNATAKA 560 087 427 India 429 Email: shwethab@cisco.com 431 Ramesh Sivakolundu 432 Cisco Systems, Inc. 433 170 West Tasman Dr. 434 SAN JOSE, CA 95134 435 U.S.A. 437 Email: sramesh@cisco.com 439 Tal Mizrahi (editor) 440 Huawei Smart Platforms iLab 441 8-2 Matam 442 Haifa 3190501 443 Israel 445 Email: tal.mizrahi.phd@gmail.com