idnits 2.17.1 draft-ietf-ippm-ioam-direct-export-04.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The subset of traffic that is forwarded or transmitted with a DEX option SHOULD not exceed 1/N of the interface capacity on any of the IOAM encapsulating node's interfaces. It is noted that this requirement applies to the total traffic that incorporates a DEX option, including traffic that is forwarded by the IOAM encapsulating node and probe packets that are generated by the IOAM encapsulating node. In this context N is a parameter that can be configurable by network operators. If there is an upper bound, M, on the number of IOAM transit nodes in any path in the network, then it is recommended to use an N such that N >> M. The rationale is that a packet that includes a DEX option may trigger an exported packet from each IOAM transit node along the path for a total of M exported packets. Thus, if N >> M then the number of exported packets is significantly lower than the number of data packets forwarded by the IOAM encapsulating node. If there is no prior knowledge about the network topology or size, it is recommended to use N>100. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: An IOAM node that performs DEX-triggered exporting MUST support the ability to limit the rate of the exported packets. The rate of exported packets SHOULD be limited so that the number of exported packets is significantly lower than the number of packets that are exported by the device. The exported data rate SHOULD not exceed 1/N of the interface capacity on any of the IOAM node's interfaces. It is recommended to use N>100. Depending on the IOAM node's architecture considerations, the export rate may be limited to a lower number in order to avoid loading the IOAM node. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Exported packets SHOULD not be exported over a path or a tunnel that is subject to IOAM direct exporting. Furthermore, IOAM encapsulating nodes that push a DEX option into traversing packets MUST avoid pushing an IOAM header into IOAM exported packets. This requirement is intended to prevent nested exporting and/or exporting loops. -- The document date (July 1, 2021) is 1023 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-12 == Outdated reference: A later version (-10) exists of draft-ietf-ippm-ioam-flags-04 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-09 == Outdated reference: A later version (-07) exists of draft-spiegel-ippm-ioam-rawexport-04 Summary: 0 errors (**), 0 flaws (~~), 8 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: January 2, 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 July 1, 2021 19 In-situ OAM Direct Exporting 20 draft-ietf-ippm-ioam-direct-export-04 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 January 2, 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 . . . . . . . . . . . . . . . . . . . . . 7 77 4.1. IOAM Type . . . . . . . . . . . . . . . . . . . . . . . . 7 78 4.2. IOAM DEX Flags . . . . . . . . . . . . . . . . . . . . . 8 79 5. Performance Considerations . . . . . . . . . . . . . . . . . 8 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 83 7.2. Informative References . . . . . . . . . . . . . . . . . 10 84 Appendix A. Hop Limit and Hop Count in Direct Exporting . . . . 10 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 87 1. Introduction 89 IOAM [I-D.ietf-ippm-ioam-data] is used for monitoring traffic in the 90 network, and for incorporating IOAM data fields into in-flight data 91 packets. 93 IOAM makes use of four possible IOAM options, defined in 94 [I-D.ietf-ippm-ioam-data]: Pre-allocated Trace Option, Incremental 95 Trace Option, Proof of Transit (POT) Option, and Edge-to-Edge Option. 97 This document defines a new IOAM option type (also known as an IOAM 98 type) called the Direct Export (DEX) option. This option is used as 99 a trigger for IOAM nodes to locally aggregate and process IOAM data, 100 and/or to export it to a receiving entity (or entities). A 101 "receiving entity" in this context can be, for example, an external 102 collector, analyzer, controller, decapsulating node, or a software 103 module in one of the IOAM nodes. 105 Note that even though the IOAM Option-Type is called "Direct Export", 106 it depends on the deployment whether the receipt of a packet with DEX 107 option type leads to the creation of another packet. Some 108 deployments might simply use the packet with the DEX option type to 109 trigger local processing of OAM data. 111 This draft has evolved from combining some of the concepts of PBT-I 112 from [I-D.song-ippm-postcard-based-telemetry] with immediate 113 exporting from [I-D.ietf-ippm-ioam-flags]. 115 2. Conventions 117 2.1. Requirement Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 2.2. Terminology 127 Abbreviations used in this document: 129 IOAM: In-situ Operations, Administration, and Maintenance 131 OAM: Operations, Administration, and Maintenance 133 DEX: Direct EXporting 135 3. The Direct Exporting (DEX) IOAM Option Type 137 3.1. Overview 139 The DEX option is used as a trigger for collecting IOAM data locally 140 or for exporting it to a receiving entity (or entities). 141 Specifically, the DEX option can be used as a trigger for collecting 142 IOAM data by an IOAM node and locally aggregating it; thus, this 143 aggregated data can be periodically pushed to a receiving entity, or 144 pulled by a receiving entity on-demand. 146 This option is incorporated into data packets by an IOAM 147 encapsulating node, and removed by an IOAM decapsulating node, as 148 illustrated in Figure 1. The option can be read but not modified by 149 transit nodes. Note: the terms IOAM encapsulating, decapsulating and 150 transit nodes are as defined in [I-D.ietf-ippm-ioam-data]. 152 ^ 153 |Exported IOAM data 154 | 155 | 156 | 157 +--------------+------+-------+--------------+ 158 | | | | 159 | | | | 160 User +---+----+ +---+----+ +---+----+ +---+----+ 161 packets |Encapsu-| | Transit| | Transit| |Decapsu-| 162 --------->|lating |====>| Node |====>| Node |====>|lating |----> 163 |Node | | A | | B | |Node | 164 +--------+ +--------+ +--------+ +--------+ 165 Insert DEX Export Export Remove DEX 166 option and IOAM data IOAM data option and 167 export data export data 169 Figure 1: DEX Architecture 171 The DEX option is used as a trigger to collect and/or export IOAM 172 data. The trigger applies to transit nodes, the decapsulating node, 173 and the encapsulating node: 175 o An IOAM encapsulating node configured to incorporate the DEX 176 option encapsulates (possibly a subset of) the packets it forwards 177 with the DEX option, and MAY export and/or collect the requested 178 IOAM data immediately. Only IOAM encapsulating nodes are allowed 179 to add the DEX option type to a packet. 181 o A transit node that processes a packet with the DEX option MAY 182 export and/or collect the requested IOAM data. 184 o An IOAM decapsulating node that processes a packet with the DEX 185 option MAY export and/or collect the requested IOAM data, and MUST 186 decapsulate the IOAM header. 188 As in [I-D.ietf-ippm-ioam-data], the DEX option can be incorporated 189 into all or a subset of the traffic that is forwarded by the 190 encapsulating node, as further discussed in Section 3.1.1 below. 191 Moreover, IOAM nodes respond to the DEX trigger by exporting and/or 192 collection IOAM data either for all traversing packets that carry the 193 DEX option, or selectively only for a subset of these packets, as 194 further discussed in Section 3.1.2 below. 196 3.1.1. DEX Packet Selection 198 If an IOAM encapsulating node incorporates the DEX option into all 199 the traffic it forwards it may lead to an excessive amount of 200 exported data, which may overload the network and the receiving 201 entity. Therefore, an IOAM encapsulating node that supports the DEX 202 option MUST support the ability to incorporate the DEX option 203 selectively into a subset of the packets that are forwarded by it. 205 Various methods of packet selection and sampling have been previously 206 defined, such as [RFC7014] and [RFC5475]. Similar techniques can be 207 applied by an IOAM encapsulating node to apply DEX to a subset of the 208 forwarded traffic. 210 The subset of traffic that is forwarded or transmitted with a DEX 211 option SHOULD not exceed 1/N of the interface capacity on any of the 212 IOAM encapsulating node's interfaces. It is noted that this 213 requirement applies to the total traffic that incorporates a DEX 214 option, including traffic that is forwarded by the IOAM encapsulating 215 node and probe packets that are generated by the IOAM encapsulating 216 node. In this context N is a parameter that can be configurable by 217 network operators. If there is an upper bound, M, on the number of 218 IOAM transit nodes in any path in the network, then it is recommended 219 to use an N such that N >> M. The rationale is that a packet that 220 includes a DEX option may trigger an exported packet from each IOAM 221 transit node along the path for a total of M exported packets. Thus, 222 if N >> M then the number of exported packets is significantly lower 223 than the number of data packets forwarded by the IOAM encapsulating 224 node. If there is no prior knowledge about the network topology or 225 size, it is recommended to use N>100. 227 3.1.2. Responding to the DEX Trigger 229 The DEX option specifies which data fields should be exported and/or 230 collected, as specified in Section 3.2. As mentioned above, the data 231 can be locally collected, and optionally can be aggregated and 232 exported to a receiving entity, either proactively or on-demand. If 233 IOAM data is exported, the format and encapsulation of the packet 234 that contains the exported data is not within the scope of the 235 current document. For example, the export format can be based on 236 [I-D.spiegel-ippm-ioam-rawexport]. 238 An IOAM node that performs DEX-triggered exporting MUST support the 239 ability to limit the rate of the exported packets. The rate of 240 exported packets SHOULD be limited so that the number of exported 241 packets is significantly lower than the number of packets that are 242 exported by the device. The exported data rate SHOULD not exceed 1/N 243 of the interface capacity on any of the IOAM node's interfaces. It 244 is recommended to use N>100. Depending on the IOAM node's 245 architecture considerations, the export rate may be limited to a 246 lower number in order to avoid loading the IOAM node. 248 Exported packets SHOULD not be exported over a path or a tunnel that 249 is subject to IOAM direct exporting. Furthermore, IOAM encapsulating 250 nodes that push a DEX option into traversing packets MUST avoid 251 pushing an IOAM header into IOAM exported packets. This requirement 252 is intended to prevent nested exporting and/or exporting loops. 254 A transit IOAM node that does not support the DEX option SHOULD 255 ignore it. A decapsulating node that does not support the DEX option 256 MUST remove it, along with any other IOAM options carried in the 257 packet if such exist. 259 3.2. The DEX Option Format 261 The format of the DEX option is depicted in Figure 2. The length of 262 the DEX option is either 8 octets or 16 octets, as the Flow ID and 263 the Sequence Number fields (summing up to 8 octets) are optional. It 264 is assumed that the lower layer protocol indicates the length of the 265 DEX option, thus indicating whether the two optional fields are 266 present. 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Namespace-ID | Flags | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | IOAM-Trace-Type | Reserved | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Flow ID (optional) | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Sequence Number (Optional) | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Figure 2: DEX Option Format 282 Namespace-ID A 16-bit identifier of the IOAM namespace, as defined 283 in [I-D.ietf-ippm-ioam-data]. 285 Flags A 16-bit field, comprised of 16 one-bit subfields. 286 Flags are allocated by IANA, as defined in 287 Section 4.2. 289 IOAM-Trace-Type A 24-bit identifier which specifies which data fields 290 should be exported. The format of this field is as 291 defined in [I-D.ietf-ippm-ioam-data]. Specifically, 292 bit 23, which corresponds to the Checksum Complement 293 data field, should be assigned to be zero by the IOAM 294 encapsulating node, and ignored by transit and 295 decapsulating nodes. The reason for this is that the 296 Checksum Complement is intended for in-flight packet 297 modifications and is not relevant for direct 298 exporting. 300 Reserved This field SHOULD be ignored by the receiver. 302 Flow ID A 32-bit flow identifier. If the actual Flow ID is 303 shorter than 32 bits, it is zero padded in its most 304 significant bits. The field is set at the 305 encapsulating node. The Flow ID can be uniformly 306 assigned by a central controller or algorithmically 307 generated by the encapsulating node. The latter 308 approach cannot guarantee the uniqueness of Flow ID, 309 yet the conflict probability is small due to the 310 large Flow ID space. The Flow ID can be used to 311 correlate the exported data of the same flow from 312 multiple nodes and from multiple packets. 314 Sequence Number A 32-bit sequence number starting from 0 and 315 increasing by 1 for each following monitored packet 316 from the same flow at the encapsulating node. The 317 Sequence Number, when combined with the Flow ID, 318 provides a convenient approach to correlate the 319 exported data from the same user packet. 321 4. IANA Considerations 323 4.1. IOAM Type 325 The "IOAM Type Registry" was defined in Section 7.2 of 326 [I-D.ietf-ippm-ioam-data]. IANA is requested to allocate the 327 following code point from the "IOAM Type Registry" as follows: 329 TBD-type IOAM Direct Export (DEX) Option Type 331 If possible, IANA is requested to allocate code point 4 (TBD-type). 333 4.2. IOAM DEX Flags 335 IANA is requested to define an "IOAM DEX Flags" registry. This 336 registry includes 16 flag bits. Allocation should be performed based 337 on the "RFC Required" procedure, as defined in [RFC8126]. 339 5. Performance Considerations 341 The DEX option triggers IOAM data to be collected and/or exported 342 packets to be exported to a receiving entity (or entities). In some 343 cases this may impact the receiving entity's performance, or the 344 performance along the paths leading to it. 346 Therefore, the performance impact of these exported packets is 347 limited by taking two measures: at the encapsulating nodes, by 348 selective DEX encapsulation (Section 3.1.1), and at the transit 349 nodes, by limiting exporting rate (Section 3.1.2). These two 350 measures ensure that direct exporting is used at a rate that does not 351 significantly affect the network bandwidth, and does not overload the 352 receiving entity. Moreover, it is possible to load balance the 353 exported data among multiple receiving entities, although the 354 exporting method is not within the scope of this document. 356 6. Security Considerations 358 The security considerations of IOAM in general are discussed in 359 [I-D.ietf-ippm-ioam-data]. Specifically, an attacker may try to use 360 the functionality that is defined in this document to attack the 361 network. 363 An attacker may attempt to overload network devices by injecting 364 synthetic packets that include the DEX option. Similarly, an on-path 365 attacker may maliciously incorporate the DEX option into transit 366 packets, or maliciously remove it from packets in which it is 367 incorporated. 369 Forcing DEX, either in synthetic packets or in transit packets may 370 overload the receiving entity (or entities). Since this mechanism 371 affects multiple devices along the network path, it potentially 372 amplifies the effect on the network bandwidth and on the receiving 373 entity's load. 375 The amplification effect of DEX may be worse in wide area networks in 376 which there are multiple IOAM domains. For example, if DEX is used 377 in IOAM domain 1 for exporting IOAM data to a receiving entity, then 378 the exported packets of domain 1 can be forwarded through IOAM domain 379 2, in which they are subject to DEX. The exported packets of domain 380 2 may in turn be forwarded through another IOAM domain (or through 381 domain 1), and theoretically this recursive amplification may 382 continue infinitely. 384 In order to mitigate the attacks described above, the following 385 requirements (Section 3) have been defined: 387 o Selective DEX (Section 3.1.1) is applied by IOAM encpsulating 388 nodes in order to limit the potential impact of DEX attacks to a 389 small fraction of the traffic. 391 o Rate limiting of exported traffic (Section 3.1.2) is applied by 392 IOAM nodes in order to prevent overloading attacks and in order to 393 significantly limit the scale of amplification attacks. 395 o IOAM encapsulating nodes are required to avoid pushing the DEX 396 option into IOAM exported packets (Section 3.1.2), thus preventing 397 some of the amplification and export loop scenarios. 399 Although the exporting method is not within the scope of this 400 document, any exporting method MUST secure the exported data from the 401 IOAM node to the receiving entity. Specifically, an IOAM node that 402 performs DEX exporting MUST send the exported data to a pre- 403 configured trusted receiving entity. 405 IOAM is assumed to be deployed in a restricted administrative domain, 406 thus limiting the scope of the threats above and their affect. This 407 is a fundamental assumption with respect to the security aspects of 408 IOAM, as further discussed in [I-D.ietf-ippm-ioam-data]. 410 7. References 412 7.1. Normative References 414 [I-D.ietf-ippm-ioam-data] 415 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 416 for In-situ OAM", draft-ietf-ippm-ioam-data-12 (work in 417 progress), February 2021. 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, 421 DOI 10.17487/RFC2119, March 1997, 422 . 424 [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. 425 Raspall, "Sampling and Filtering Techniques for IP Packet 426 Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, 427 . 429 [RFC7014] D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow 430 Selection Techniques", RFC 7014, DOI 10.17487/RFC7014, 431 September 2013, . 433 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 434 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 435 May 2017, . 437 7.2. Informative References 439 [I-D.ietf-ippm-ioam-flags] 440 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 441 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 442 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-04 443 (work in progress), February 2021. 445 [I-D.song-ippm-postcard-based-telemetry] 446 Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou, 447 T., Li, Z., Shin, J., and K. Lee, "Postcard-based On-Path 448 Flow Data Telemetry using Packet Marking", draft-song- 449 ippm-postcard-based-telemetry-09 (work in progress), 450 February 2021. 452 [I-D.spiegel-ippm-ioam-rawexport] 453 Spiegel, M., Brockners, F., Bhandari, S., and R. 454 Sivakolundu, "In-situ OAM raw data export with IPFIX", 455 draft-spiegel-ippm-ioam-rawexport-04 (work in progress), 456 November 2020. 458 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 459 Writing an IANA Considerations Section in RFCs", BCP 26, 460 RFC 8126, DOI 10.17487/RFC8126, June 2017, 461 . 463 Appendix A. Hop Limit and Hop Count in Direct Exporting 465 In order to help correlate and order the exported packets, it is 466 possible to include the Hop_Lim/Node_ID data field in exported 467 packets; if the IOAM-Trace-Type [I-D.ietf-ippm-ioam-data] has the 468 Hop_Lim/Node_ID bit set, then exported packets include the Hop_Lim/ 469 Node_ID data field, which contains the TTL/Hop Limit value from a 470 lower layer protocol. 472 An alternative approach was considered during the design of this 473 document, according to which a 1-octet Hop Count field would be 474 included in the DEX header (presumably by claiming some space from 475 the Flags field). The Hop Limit would starts from 0 at the 476 encapsulating node and be incremented by each IOAM transit node that 477 supports the DEX option. In this approach the Hop Count field value 478 would also be included in the exported packet. 480 The main advantage of the Hop_Lim/Node_ID approach is that it 481 provides information about the current hop count without requiring 482 each transit node to modify the DEX option, thus simplifying the data 483 plane functionality of Direct Exporting. The main advantage of the 484 Hop Count approach that was considered is that it counts the number 485 of IOAM-capable nodes without relying on the lower layer TTL, 486 especially when the lower layer cannot prvide the accurate TTL 487 information, e.g., Layer 2 Ethernet or hierarchical VPN. The Hop 488 Count approach would also explicitly allow to detect a case where an 489 IOAM-capable node fails to export packets. It would also be possible 490 to use a flag to indicate an optional Hop Count field, which enables 491 to control the tradeoff. On one hand it would address the use cases 492 that the Hop_Lim/Node_ID cannot cover, and on the other hand it would 493 not require transit switches to update the option if it was not 494 supported or disabled. For the sake of simplicity the Hop Count 495 approach was not pursued, and this field is not incorporated in the 496 DEX header. 498 Authors' Addresses 500 Haoyu Song 501 Futurewei 502 2330 Central Expressway 503 Santa Clara 95050 504 USA 506 Email: haoyu.song@huawei.com 508 Barak Gafni 509 Nvidia 510 350 Oakmead Parkway, Suite 100 511 Sunnyvale, CA 94085 512 U.S.A. 514 Email: gbarak@nvidia.com 516 Tianran Zhou 517 Huawei 518 156 Beiqing Rd. 519 Beijing 100095 520 China 522 Email: zhoutianran@huawei.com 523 Zhenbin Li 524 Huawei 525 156 Beiqing Rd. 526 Beijing 100095 527 China 529 Email: lizhenbin@huawei.com 531 Frank Brockners 532 Cisco Systems, Inc. 533 Hansaallee 249, 3rd Floor 534 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 535 Germany 537 Email: fbrockne@cisco.com 539 Shwetha Bhandari (editor) 540 Thoughtspot 541 3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout 542 Bangalore, KARNATAKA 560 102 543 India 545 Email: shwetha.bhandari@thoughtspot.com 547 Ramesh Sivakolundu 548 Cisco Systems, Inc. 549 170 West Tasman Dr. 550 SAN JOSE, CA 95134 551 U.S.A. 553 Email: sramesh@cisco.com 555 Tal Mizrahi (editor) 556 Huawei 557 8-2 Matam 558 Haifa 3190501 559 Israel 561 Email: tal.mizrahi.phd@gmail.com