idnits 2.17.1 draft-ietf-ippm-ioam-direct-export-07.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 (October 13, 2021) is 925 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) == Missing Reference: 'RFC XXXX' is mentioned on line 389, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-15 == Outdated reference: A later version (-10) exists of draft-ietf-ippm-ioam-flags-06 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-10 == Outdated reference: A later version (-07) exists of draft-spiegel-ippm-ioam-rawexport-05 Summary: 0 errors (**), 0 flaws (~~), 6 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: April 16, 2022 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 October 13, 2021 19 In-situ OAM Direct Exporting 20 draft-ietf-ippm-ioam-direct-export-07 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 or locally 30 aggregated without being pushed into in-flight data packets. The 31 exporting method and format are outside the scope of this document. 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 April 16, 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 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 70 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. The Direct Exporting (DEX) IOAM Option Type . . . . . . . . . 3 72 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3.1.1. DEX Packet Selection . . . . . . . . . . . . . . . . 5 74 3.1.2. Responding to the DEX Trigger . . . . . . . . . . . . 5 75 3.2. The DEX Option Format . . . . . . . . . . . . . . . . . . 6 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 4.1. IOAM Type . . . . . . . . . . . . . . . . . . . . . . . . 8 78 4.2. IOAM DEX Flags . . . . . . . . . . . . . . . . . . . . . 8 79 4.3. IOAM DEX Extension-Flags . . . . . . . . . . . . . . . . 9 80 5. Performance Considerations . . . . . . . . . . . . . . . . . 9 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 85 8.2. Informative References . . . . . . . . . . . . . . . . . 11 86 Appendix A. Hop Limit in Direct Exporting . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Introduction 91 IOAM [I-D.ietf-ippm-ioam-data] is used for monitoring traffic in the 92 network, and for incorporating IOAM data fields into in-flight data 93 packets. 95 IOAM makes use of four possible IOAM options, defined in 96 [I-D.ietf-ippm-ioam-data]: Pre-allocated Trace Option, Incremental 97 Trace Option, Proof of Transit (POT) Option, and Edge-to-Edge Option. 99 This document defines a new IOAM option type (also known as an IOAM 100 type) called the Direct Export (DEX) option. This option is used as 101 a trigger for IOAM nodes to locally aggregate and process IOAM data, 102 and/or to export it to a receiving entity (or entities). Throughout 103 the document this functionality is referred to as collection and/or 104 exporting. A "receiving entity" in this context can be, for example, 105 an external collector, analyzer, controller, decapsulating node, or a 106 software module in one of the IOAM nodes. 108 Note that even though the IOAM Option-Type is called "Direct Export", 109 it depends on the deployment whether the receipt of a packet with DEX 110 option type leads to the creation of another packet. Some 111 deployments might simply use the packet with the DEX option type to 112 trigger local processing of OAM data. The functionality of this 113 local processing is not within the scope of this document. 115 This draft has evolved from combining some of the concepts of PBT-I 116 from [I-D.song-ippm-postcard-based-telemetry] with immediate 117 exporting from [I-D.ietf-ippm-ioam-flags]. 119 2. Conventions 121 2.1. Requirement Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 2.2. Terminology 131 Abbreviations used in this document: 133 IOAM: In-situ Operations, Administration, and Maintenance 135 OAM: Operations, Administration, and Maintenance 137 DEX: Direct EXporting 139 3. The Direct Exporting (DEX) IOAM Option Type 141 3.1. Overview 143 The DEX option is used as a trigger for collecting IOAM data locally 144 or for exporting it to a receiving entity (or entities). 145 Specifically, the DEX option can be used as a trigger for collecting 146 IOAM data by an IOAM node and locally aggregating it; thus, this 147 aggregated data can be periodically pushed to a receiving entity, or 148 pulled by a receiving entity on-demand. 150 This option is incorporated into data packets by an IOAM 151 encapsulating node, and removed by an IOAM decapsulating node, as 152 illustrated in Figure 1. The option can be read but not modified by 153 transit nodes. Note: the terms IOAM encapsulating, decapsulating and 154 transit nodes are as defined in [I-D.ietf-ippm-ioam-data]. 156 ^ 157 |Exported IOAM data 158 | 159 | 160 | 161 +--------------+------+-------+--------------+ 162 | | | | 163 | | | | 164 User +---+----+ +---+----+ +---+----+ +---+----+ 165 packets |Encapsu-| | Transit| | Transit| |Decapsu-| 166 --------->|lating |====>| Node |====>| Node |====>|lating |----> 167 |Node | | A | | B | |Node | 168 +--------+ +--------+ +--------+ +--------+ 169 Insert DEX Export Export Remove DEX 170 option and IOAM data IOAM data option and 171 export data export data 173 Figure 1: DEX Architecture 175 The DEX option is used as a trigger to collect and/or export IOAM 176 data. The trigger applies to transit nodes, the decapsulating node, 177 and the encapsulating node: 179 o An IOAM encapsulating node configured to incorporate the DEX 180 option encapsulates (possibly a subset of) the packets it forwards 181 with the DEX option, and MAY export and/or collect the requested 182 IOAM data immediately. Only IOAM encapsulating nodes are allowed 183 to add the DEX option type to a packet. 185 o A transit node that processes a packet with the DEX option MAY 186 export and/or collect the requested IOAM data. 188 o An IOAM decapsulating node that processes a packet with the DEX 189 option MAY export and/or collect the requested IOAM data, and MUST 190 decapsulate the IOAM header. 192 As in [I-D.ietf-ippm-ioam-data], the DEX option can be incorporated 193 into all or a subset of the traffic that is forwarded by the 194 encapsulating node, as further discussed in Section 3.1.1 below. 195 Moreover, IOAM nodes respond to the DEX trigger by exporting and/or 196 collection IOAM data either for all traversing packets that carry the 197 DEX option, or selectively only for a subset of these packets, as 198 further discussed in Section 3.1.2 below. 200 3.1.1. DEX Packet Selection 202 If an IOAM encapsulating node incorporates the DEX option into all 203 the traffic it forwards it may lead to an excessive amount of 204 exported data, which may overload the network and the receiving 205 entity. Therefore, an IOAM encapsulating node that supports the DEX 206 option MUST support the ability to incorporate the DEX option 207 selectively into a subset of the packets that are forwarded by it. 209 Various methods of packet selection and sampling have been previously 210 defined, such as [RFC7014] and [RFC5475]. Similar techniques can be 211 applied by an IOAM encapsulating node to apply DEX to a subset of the 212 forwarded traffic. 214 The subset of traffic that is forwarded or transmitted with a DEX 215 option SHOULD NOT exceed 1/N of the interface capacity on any of the 216 IOAM encapsulating node's interfaces. It is noted that this 217 requirement applies to the total traffic that incorporates a DEX 218 option, including traffic that is forwarded by the IOAM encapsulating 219 node and probe packets that are generated by the IOAM encapsulating 220 node. In this context N is a parameter that can be configurable by 221 network operators. If there is an upper bound, M, on the number of 222 IOAM transit nodes in any path in the network, then it is recommended 223 to use an N such that N >> M. The rationale is that a packet that 224 includes a DEX option may trigger an exported packet from each IOAM 225 transit node along the path for a total of M exported packets. Thus, 226 if N >> M then the number of exported packets is significantly lower 227 than the number of data packets forwarded by the IOAM encapsulating 228 node. If there is no prior knowledge about the network topology or 229 size, it is recommended to use N>100. 231 3.1.2. Responding to the DEX Trigger 233 The DEX option specifies which data fields should be exported and/or 234 collected, as specified in Section 3.2. As mentioned above, the data 235 can be locally collected, and optionally can be aggregated and 236 exported to a receiving entity, either proactively or on-demand. If 237 IOAM data is exported, the format and encapsulation of the packet 238 that contains the exported data is not within the scope of the 239 current document. For example, the export format can be based on 240 [I-D.spiegel-ippm-ioam-rawexport]. 242 An IOAM node that performs DEX-triggered exporting MUST support the 243 ability to limit the rate of the exported packets. The rate of 244 exported packets SHOULD be limited so that the number of exported 245 packets is significantly lower than the number of packets that are 246 forwarded by the device. The exported data rate SHOULD NOT exceed 1/ 247 N of the interface capacity on any of the IOAM node's interfaces. It 248 is recommended to use N>100. Depending on the IOAM node's 249 architecture considerations, the export rate may be limited to a 250 lower number in order to avoid loading the IOAM node. An IOAM node 251 MAY maintain a counter or a set of counters that count the events in 252 which the IOAM node receives a packet with the DEX option type and 253 does not collect and/or export data due to the rate limits. 255 Exported packets SHOULD NOT be exported over a path or a tunnel that 256 is subject to IOAM direct exporting. Furthermore, IOAM encapsulating 257 nodes that can identify a packet as an IOAM exported packet MUST NOT 258 push a DEX option into such a packet. This requirement is intended 259 to prevent nested exporting and/or exporting loops. 261 A transit or decapsulating IOAM node that receives an unknown IOAM 262 option type ignores it (as defined in [I-D.ietf-ippm-ioam-data]), and 263 specifically nodes that do not support the DEX option ignore it. 264 Note that as per [I-D.ietf-ippm-ioam-data] a decapsulating node 265 removes the IOAM encapsulation and all its IOAM options, and 266 specifically in the case where one of these options is a (possibly 267 unknown) DEX option. 269 3.2. The DEX Option Format 271 The format of the DEX option is depicted in Figure 2. The length of 272 the DEX option is at least 8 octets. The DEX option MAY include one 273 or more optional fields. The existence of the optional fields is 274 indicated by the corresponding flags in the Extension-Flags field. 275 Two optional fields are defined in this document, the Flow ID and the 276 Sequence Number fields. Every optional field MUST be exactly 4 277 octets long. Thus, the Extension-Flags field explicitly indicates 278 the length of the DEX option. Defining a new optional field requires 279 an allocation of a corresponding flag in the Extension-Flags field, 280 as specified in Section 4.2. 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Namespace-ID | Flags |Extension-Flags| 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | IOAM-Trace-Type | Reserved | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Flow ID (optional) | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Sequence Number (Optional) | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Figure 2: DEX Option Format 296 Namespace-ID A 16-bit identifier of the IOAM namespace, as defined 297 in [I-D.ietf-ippm-ioam-data]. 299 Flags An 8-bit field, comprised of 8 one-bit subfields. 300 Flags are allocated by IANA, as defined in 301 Section 4.2. 303 Extension-Flags An 8-bit field, comprised of 8 one-bit subfields. 304 Extension-Flags are allocated by IANA, as defined in 305 Section 4.3. Every bit in the Extension-Flag field 306 that is set to 1 indicates the existence of a 307 corresponding optional 4-octet field. An IOAM node 308 that receives a DEX option with an unknown flag set 309 to 1 MUST ignore the corresponding optional field. 311 IOAM-Trace-Type A 24-bit identifier which specifies which data fields 312 should be exported. The format of this field is as 313 defined in [I-D.ietf-ippm-ioam-data]. Specifically, 314 the bit that corresponds to the Checksum Complement 315 data field should be assigned to be zero by the IOAM 316 encapsulating node, and ignored by transit and 317 decapsulating nodes. The reason for this is that the 318 Checksum Complement is intended for in-flight packet 319 modifications and is not relevant for direct 320 exporting. 322 Reserved This field SHOULD be ignored by the receiver. 324 Optional fields The optional fields, if present, reside after the 325 Reserved field. The order of the optional fields is 326 according to the respective bits that are enabled in 327 the Extension-Flags field. Each optional field is 4 328 octets long. 330 Flow ID An optional 32-bit field representing the flow 331 identifier. If the actual Flow ID is shorter than 32 332 bits, it is zero padded in its most significant bits. 333 The field is set at the encapsulating node. The Flow 334 ID can be uniformly assigned by a central controller 335 or algorithmically generated by the encapsulating 336 node. The latter approach cannot guarantee the 337 uniqueness of Flow ID, yet the conflict probability 338 is small due to the large Flow ID space. The Flow ID 339 can be used to correlate the exported data of the 340 same flow from multiple nodes and from multiple 341 packets. 343 Sequence Number An optional 32-bit sequence number starting from 0 344 and increasing by 1 for each following monitored 345 packet from the same flow at the encapsulating node. 346 The Sequence Number, when combined with the Flow ID, 347 provides a convenient approach to correlate the 348 exported data from the same user packet. 350 4. IANA Considerations 352 4.1. IOAM Type 354 The "IOAM Type Registry" was defined in Section 7.2 of 355 [I-D.ietf-ippm-ioam-data]. IANA is requested to allocate the 356 following code point from the "IOAM Type Registry" as follows: 358 TBD-type IOAM Direct Export (DEX) Option Type 360 If possible, IANA is requested to allocate code point 4 (TBD-type). 362 4.2. IOAM DEX Flags 364 IANA is requested to define an "IOAM DEX Flags" registry. This 365 registry includes 8 flag bits. Allocation is based on the "RFC 366 Required" procedure, as defined in [RFC8126]. 368 New registration requests MUST use the following template: 370 Bit: Desired bit to be allocated in the 8 bit Flags field of the DEX 371 option. 373 Description: Brief description of the newly registered bit. 375 Reference: Reference to the document that defines the new bit. 377 4.3. IOAM DEX Extension-Flags 379 IANA is requested to define an "IOAM DEX Extension-Flags" registry. 380 This registry includes 8 flag bits. Bit 0 (the most significant bit) 381 and bit 1 in the registry are allocated by this document, and 382 described in Section 3.2. Allocation of the other bits should be 383 performed based on the "RFC Required" procedure, as defined in 384 [RFC8126]. 386 Bit 0 "Flow ID [RFC XXXX] [RFC Editor: please replace with the RFC 387 number of the current document]" 389 Bit 1 "Sequence Number [RFC XXXX] [RFC Editor: please replace with 390 the RFC number of the current document]" 392 New registration requests MUST use the following template: 394 Bit: Desired bit to be allocated in the 8 bit Extension-Flags field 395 of the DEX option. 397 Description: Brief description of the newly registered bit. 399 Reference: Reference to the document that defines the new bit. 401 5. Performance Considerations 403 The DEX option triggers IOAM data to be collected and/or exported 404 packets to be exported to a receiving entity (or entities). In some 405 cases this may impact the receiving entity's performance, or the 406 performance along the paths leading to it. 408 Therefore, the performance impact of these exported packets is 409 limited by taking two measures: at the encapsulating nodes, by 410 selective DEX encapsulation (Section 3.1.1), and at the transit 411 nodes, by limiting exporting rate (Section 3.1.2). These two 412 measures ensure that direct exporting is used at a rate that does not 413 significantly affect the network bandwidth, and does not overload the 414 receiving entity. Moreover, it is possible to load balance the 415 exported data among multiple receiving entities, although the 416 exporting method is not within the scope of this document. 418 It should be noted that in some networks DEX data may be exported 419 over an out-of-band network, in which a large volume of exported 420 traffic does not compromise user traffic. In this case an operator 421 may choose to disable the exporting rate limiting. 423 6. Security Considerations 425 The security considerations of IOAM in general are discussed in 426 [I-D.ietf-ippm-ioam-data]. Specifically, an attacker may try to use 427 the functionality that is defined in this document to attack the 428 network. 430 An attacker may attempt to overload network devices by injecting 431 synthetic packets that include the DEX option. Similarly, an on-path 432 attacker may maliciously incorporate the DEX option into transit 433 packets, or maliciously remove it from packets in which it is 434 incorporated. 436 Forcing DEX, either in synthetic packets or in transit packets may 437 overload the receiving entity (or entities). Since this mechanism 438 affects multiple devices along the network path, it potentially 439 amplifies the effect on the network bandwidth and on the receiving 440 entity's load. 442 The amplification effect of DEX may be worse in wide area networks in 443 which there are multiple IOAM domains. For example, if DEX is used 444 in IOAM domain 1 for exporting IOAM data to a receiving entity, then 445 the exported packets of domain 1 can be forwarded through IOAM domain 446 2, in which they are subject to DEX. The exported packets of domain 447 2 may in turn be forwarded through another IOAM domain (or through 448 domain 1), and theoretically this recursive amplification may 449 continue infinitely. 451 In order to mitigate the attacks described above, the following 452 requirements (Section 3) have been defined: 454 o Selective DEX (Section 3.1.1) is applied by IOAM encpsulating 455 nodes in order to limit the potential impact of DEX attacks to a 456 small fraction of the traffic. 458 o Rate limiting of exported traffic (Section 3.1.2) is applied by 459 IOAM nodes in order to prevent overloading attacks and in order to 460 significantly limit the scale of amplification attacks. 462 o IOAM encapsulating nodes are required to avoid pushing the DEX 463 option into IOAM exported packets (Section 3.1.2), thus preventing 464 some of the amplification and export loop scenarios. 466 Although the exporting method is not within the scope of this 467 document, any exporting method MUST secure the exported data from the 468 IOAM node to the receiving entity. Specifically, an IOAM node that 469 performs DEX exporting MUST send the exported data to a pre- 470 configured trusted receiving entity. Furthermore, an IOAM node MUST 471 gain explicit consent to export data to a receiving entity before 472 starting to send exported data. 474 IOAM is assumed to be deployed in a restricted administrative domain, 475 thus limiting the scope of the threats above and their affect. This 476 is a fundamental assumption with respect to the security aspects of 477 IOAM, as further discussed in [I-D.ietf-ippm-ioam-data]. 479 7. Acknowledgments 481 The authors thank Martin Duke, Tommy Pauly, Greg Mirsky, and other 482 members of the IPPM working group for many helpful comments. 484 8. References 486 8.1. Normative References 488 [I-D.ietf-ippm-ioam-data] 489 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 490 for In-situ OAM", draft-ietf-ippm-ioam-data-15 (work in 491 progress), October 2021. 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, 495 DOI 10.17487/RFC2119, March 1997, 496 . 498 [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. 499 Raspall, "Sampling and Filtering Techniques for IP Packet 500 Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, 501 . 503 [RFC7014] D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow 504 Selection Techniques", RFC 7014, DOI 10.17487/RFC7014, 505 September 2013, . 507 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 508 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 509 May 2017, . 511 8.2. Informative References 513 [I-D.ietf-ippm-ioam-flags] 514 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 515 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 516 Lemon, "In-situ OAM Loopback and Active Flags", draft- 517 ietf-ippm-ioam-flags-06 (work in progress), August 2021. 519 [I-D.song-ippm-postcard-based-telemetry] 520 Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou, 521 T., Li, Z., Shin, J., and K. Lee, "Postcard-based On-Path 522 Flow Data Telemetry using Packet Marking", draft-song- 523 ippm-postcard-based-telemetry-10 (work in progress), July 524 2021. 526 [I-D.spiegel-ippm-ioam-rawexport] 527 Spiegel, M., Brockners, F., Bhandari, S., and R. 528 Sivakolundu, "In-situ OAM raw data export with IPFIX", 529 draft-spiegel-ippm-ioam-rawexport-05 (work in progress), 530 July 2021. 532 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 533 Writing an IANA Considerations Section in RFCs", BCP 26, 534 RFC 8126, DOI 10.17487/RFC8126, June 2017, 535 . 537 Appendix A. Hop Limit in Direct Exporting 539 In order to help correlate and order the exported packets, it is 540 possible to include the Hop_Lim/Node_ID data field in exported 541 packets; if the IOAM-Trace-Type [I-D.ietf-ippm-ioam-data] has the 542 Hop_Lim/Node_ID bit set, then exported packets include the Hop_Lim/ 543 Node_ID data field, which contains the TTL/Hop Limit value from a 544 lower layer protocol. 546 An alternative approach was considered during the design of this 547 document, according to which a 1-octet Hop Count field would be 548 included in the DEX header (presumably by claiming some space from 549 the Flags field). The Hop Limit would starts from 0 at the 550 encapsulating node and be incremented by each IOAM transit node that 551 supports the DEX option. In this approach the Hop Count field value 552 would also be included in the exported packet. 554 Authors' Addresses 556 Haoyu Song 557 Futurewei 558 2330 Central Expressway 559 Santa Clara 95050 560 USA 562 Email: haoyu.song@futurewei.com 563 Barak Gafni 564 Nvidia 565 350 Oakmead Parkway, Suite 100 566 Sunnyvale, CA 94085 567 U.S.A. 569 Email: gbarak@nvidia.com 571 Tianran Zhou 572 Huawei 573 156 Beiqing Rd. 574 Beijing 100095 575 China 577 Email: zhoutianran@huawei.com 579 Zhenbin Li 580 Huawei 581 156 Beiqing Rd. 582 Beijing 100095 583 China 585 Email: lizhenbin@huawei.com 587 Frank Brockners 588 Cisco Systems, Inc. 589 Hansaallee 249, 3rd Floor 590 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 591 Germany 593 Email: fbrockne@cisco.com 595 Shwetha Bhandari (editor) 596 Thoughtspot 597 3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout 598 Bangalore, KARNATAKA 560 102 599 India 601 Email: shwetha.bhandari@thoughtspot.com 602 Ramesh Sivakolundu 603 Cisco Systems, Inc. 604 170 West Tasman Dr. 605 SAN JOSE, CA 95134 606 U.S.A. 608 Email: sramesh@cisco.com 610 Tal Mizrahi (editor) 611 Huawei 612 8-2 Matam 613 Haifa 3190501 614 Israel 616 Email: tal.mizrahi.phd@gmail.com