idnits 2.17.1 draft-ietf-ippm-ioam-direct-export-06.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 8, 2021) is 963 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 380, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-14 == Outdated reference: A later version (-10) exists of draft-ietf-ippm-ioam-flags-05 == 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: February 9, 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 August 8, 2021 19 In-situ OAM Direct Exporting 20 draft-ietf-ippm-ioam-direct-export-06 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 February 9, 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 . . . . . . . . . . . . . . . . 8 80 5. Performance Considerations . . . . . . . . . . . . . . . . . 9 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 84 7.2. Informative References . . . . . . . . . . . . . . . . . 11 85 Appendix A. Hop Limit in Direct Exporting . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 IOAM [I-D.ietf-ippm-ioam-data] is used for monitoring traffic in the 91 network, and for incorporating IOAM data fields into in-flight data 92 packets. 94 IOAM makes use of four possible IOAM options, defined in 95 [I-D.ietf-ippm-ioam-data]: Pre-allocated Trace Option, Incremental 96 Trace Option, Proof of Transit (POT) Option, and Edge-to-Edge Option. 98 This document defines a new IOAM option type (also known as an IOAM 99 type) called the Direct Export (DEX) option. This option is used as 100 a trigger for IOAM nodes to locally aggregate and process IOAM data, 101 and/or to export it to a receiving entity (or entities). A 102 "receiving entity" in this context can be, for example, an external 103 collector, analyzer, controller, decapsulating node, or a software 104 module in one of the IOAM nodes. 106 Note that even though the IOAM Option-Type is called "Direct Export", 107 it depends on the deployment whether the receipt of a packet with DEX 108 option type leads to the creation of another packet. Some 109 deployments might simply use the packet with the DEX option type to 110 trigger local processing of OAM data. 112 This draft has evolved from combining some of the concepts of PBT-I 113 from [I-D.song-ippm-postcard-based-telemetry] with immediate 114 exporting from [I-D.ietf-ippm-ioam-flags]. 116 2. Conventions 118 2.1. Requirement Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 2.2. Terminology 128 Abbreviations used in this document: 130 IOAM: In-situ Operations, Administration, and Maintenance 132 OAM: Operations, Administration, and Maintenance 134 DEX: Direct EXporting 136 3. The Direct Exporting (DEX) IOAM Option Type 138 3.1. Overview 140 The DEX option is used as a trigger for collecting IOAM data locally 141 or for exporting it to a receiving entity (or entities). 142 Specifically, the DEX option can be used as a trigger for collecting 143 IOAM data by an IOAM node and locally aggregating it; thus, this 144 aggregated data can be periodically pushed to a receiving entity, or 145 pulled by a receiving entity on-demand. 147 This option is incorporated into data packets by an IOAM 148 encapsulating node, and removed by an IOAM decapsulating node, as 149 illustrated in Figure 1. The option can be read but not modified by 150 transit nodes. Note: the terms IOAM encapsulating, decapsulating and 151 transit nodes are as defined in [I-D.ietf-ippm-ioam-data]. 153 ^ 154 |Exported IOAM data 155 | 156 | 157 | 158 +--------------+------+-------+--------------+ 159 | | | | 160 | | | | 161 User +---+----+ +---+----+ +---+----+ +---+----+ 162 packets |Encapsu-| | Transit| | Transit| |Decapsu-| 163 --------->|lating |====>| Node |====>| Node |====>|lating |----> 164 |Node | | A | | B | |Node | 165 +--------+ +--------+ +--------+ +--------+ 166 Insert DEX Export Export Remove DEX 167 option and IOAM data IOAM data option and 168 export data export data 170 Figure 1: DEX Architecture 172 The DEX option is used as a trigger to collect and/or export IOAM 173 data. The trigger applies to transit nodes, the decapsulating node, 174 and the encapsulating node: 176 o An IOAM encapsulating node configured to incorporate the DEX 177 option encapsulates (possibly a subset of) the packets it forwards 178 with the DEX option, and MAY export and/or collect the requested 179 IOAM data immediately. Only IOAM encapsulating nodes are allowed 180 to add the DEX option type to a packet. 182 o A transit node that processes a packet with the DEX option MAY 183 export and/or collect the requested IOAM data. 185 o An IOAM decapsulating node that processes a packet with the DEX 186 option MAY export and/or collect the requested IOAM data, and MUST 187 decapsulate the IOAM header. 189 As in [I-D.ietf-ippm-ioam-data], the DEX option can be incorporated 190 into all or a subset of the traffic that is forwarded by the 191 encapsulating node, as further discussed in Section 3.1.1 below. 192 Moreover, IOAM nodes respond to the DEX trigger by exporting and/or 193 collection IOAM data either for all traversing packets that carry the 194 DEX option, or selectively only for a subset of these packets, as 195 further discussed in Section 3.1.2 below. 197 3.1.1. DEX Packet Selection 199 If an IOAM encapsulating node incorporates the DEX option into all 200 the traffic it forwards it may lead to an excessive amount of 201 exported data, which may overload the network and the receiving 202 entity. Therefore, an IOAM encapsulating node that supports the DEX 203 option MUST support the ability to incorporate the DEX option 204 selectively into a subset of the packets that are forwarded by it. 206 Various methods of packet selection and sampling have been previously 207 defined, such as [RFC7014] and [RFC5475]. Similar techniques can be 208 applied by an IOAM encapsulating node to apply DEX to a subset of the 209 forwarded traffic. 211 The subset of traffic that is forwarded or transmitted with a DEX 212 option SHOULD NOT exceed 1/N of the interface capacity on any of the 213 IOAM encapsulating node's interfaces. It is noted that this 214 requirement applies to the total traffic that incorporates a DEX 215 option, including traffic that is forwarded by the IOAM encapsulating 216 node and probe packets that are generated by the IOAM encapsulating 217 node. In this context N is a parameter that can be configurable by 218 network operators. If there is an upper bound, M, on the number of 219 IOAM transit nodes in any path in the network, then it is recommended 220 to use an N such that N >> M. The rationale is that a packet that 221 includes a DEX option may trigger an exported packet from each IOAM 222 transit node along the path for a total of M exported packets. Thus, 223 if N >> M then the number of exported packets is significantly lower 224 than the number of data packets forwarded by the IOAM encapsulating 225 node. If there is no prior knowledge about the network topology or 226 size, it is recommended to use N>100. 228 3.1.2. Responding to the DEX Trigger 230 The DEX option specifies which data fields should be exported and/or 231 collected, as specified in Section 3.2. As mentioned above, the data 232 can be locally collected, and optionally can be aggregated and 233 exported to a receiving entity, either proactively or on-demand. If 234 IOAM data is exported, the format and encapsulation of the packet 235 that contains the exported data is not within the scope of the 236 current document. For example, the export format can be based on 237 [I-D.spiegel-ippm-ioam-rawexport]. 239 An IOAM node that performs DEX-triggered exporting MUST support the 240 ability to limit the rate of the exported packets. The rate of 241 exported packets SHOULD be limited so that the number of exported 242 packets is significantly lower than the number of packets that are 243 forwarded by the device. The exported data rate SHOULD NOT exceed 1/ 244 N of the interface capacity on any of the IOAM node's interfaces. It 245 is recommended to use N>100. Depending on the IOAM node's 246 architecture considerations, the export rate may be limited to a 247 lower number in order to avoid loading the IOAM node. 249 Exported packets SHOULD NOT be exported over a path or a tunnel that 250 is subject to IOAM direct exporting. Furthermore, IOAM encapsulating 251 nodes that can identify a packet as an IOAM exported packet MUST NOT 252 push a DEX option into such a packet. This requirement is intended 253 to prevent nested exporting and/or exporting loops. 255 A transit IOAM node that does not support the DEX option SHOULD 256 ignore it. A decapsulating node that does not support the DEX option 257 MUST remove it, along with any other IOAM options carried in the 258 packet if such exist. 260 3.2. The DEX Option Format 262 The format of the DEX option is depicted in Figure 2. The length of 263 the DEX option is at least 8 octets. The DEX option MAY include one 264 or more optional fields. The existence of the optional fields is 265 indicated by the corresponding flags in the Extension-Flags field. 266 Two optional fields are defined in this document, the Flow ID and the 267 Sequence Number fields. Every optional field MUST be exactly 4 268 octets long. Thus, the Extension-Flags field explicitly indicates 269 the length of the DEX option. Defining a new optional field requires 270 an allocation of a corresponding flag in the Extension-Flags field, 271 as specified in Section 4.2. 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Namespace-ID | Flags |Extension-Flags| 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | IOAM-Trace-Type | Reserved | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Flow ID (optional) | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Sequence Number (Optional) | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Figure 2: DEX Option Format 287 Namespace-ID A 16-bit identifier of the IOAM namespace, as defined 288 in [I-D.ietf-ippm-ioam-data]. 290 Flags An 8-bit field, comprised of 8 one-bit subfields. 291 Flags are allocated by IANA, as defined in 292 Section 4.2. 294 Extension-Flags An 8-bit field, comprised of 8 one-bit subfields. 295 Extension-Flags are allocated by IANA, as defined in 296 Section 4.3. Every bit in the Extension-Flag field 297 that is set to 1 indicates the existence of a 298 corresponding optional 4-octet field. An IOAM node 299 that receives a DEX option with an unknown flag set 300 to 1 MUST ignore the corresponding optional field. 302 IOAM-Trace-Type A 24-bit identifier which specifies which data fields 303 should be exported. The format of this field is as 304 defined in [I-D.ietf-ippm-ioam-data]. Specifically, 305 the bit that corresponds to the Checksum Complement 306 data field should be assigned to be zero by the IOAM 307 encapsulating node, and ignored by transit and 308 decapsulating nodes. The reason for this is that the 309 Checksum Complement is intended for in-flight packet 310 modifications and is not relevant for direct 311 exporting. 313 Reserved This field SHOULD be ignored by the receiver. 315 Optional fields The optional fields, if present, reside after the 316 Reserved field. The order of the optional fields is 317 according to the respective bits that are enabled in 318 the Extension-Flags field. Each optional field is 4 319 octets long. 321 Flow ID An optional 32-bit field representing the flow 322 identifier. If the actual Flow ID is shorter than 32 323 bits, it is zero padded in its most significant bits. 324 The field is set at the encapsulating node. The Flow 325 ID can be uniformly assigned by a central controller 326 or algorithmically generated by the encapsulating 327 node. The latter approach cannot guarantee the 328 uniqueness of Flow ID, yet the conflict probability 329 is small due to the large Flow ID space. The Flow ID 330 can be used to correlate the exported data of the 331 same flow from multiple nodes and from multiple 332 packets. 334 Sequence Number An optional 32-bit sequence number starting from 0 335 and increasing by 1 for each following monitored 336 packet from the same flow at the encapsulating node. 337 The Sequence Number, when combined with the Flow ID, 338 provides a convenient approach to correlate the 339 exported data from the same user packet. 341 4. IANA Considerations 343 4.1. IOAM Type 345 The "IOAM Type Registry" was defined in Section 7.2 of 346 [I-D.ietf-ippm-ioam-data]. IANA is requested to allocate the 347 following code point from the "IOAM Type Registry" as follows: 349 TBD-type IOAM Direct Export (DEX) Option Type 351 If possible, IANA is requested to allocate code point 4 (TBD-type). 353 4.2. IOAM DEX Flags 355 IANA is requested to define an "IOAM DEX Flags" registry. This 356 registry includes 8 flag bits. Allocation is based on the "RFC 357 Required" procedure, as defined in [RFC8126]. 359 New registration requests MUST use the following template: 361 Bit: Desired bit to be allocated in the 8 bit Flags field of the DEX 362 option. 364 Description: Brief description of the newly registered bit. 366 Reference: Reference to the document that defines the new bit. 368 4.3. IOAM DEX Extension-Flags 370 IANA is requested to define an "IOAM DEX Extension-Flags" registry. 371 This registry includes 8 flag bits. Bit 0 (the most significant bit) 372 and bit 1 in the registry are allocated by this document, and 373 described in Section 3.2. Allocation of the other bits should be 374 performed based on the "RFC Required" procedure, as defined in 375 [RFC8126]. 377 Bit 0 "Flow ID [RFC XXXX] [RFC Editor: please replace with the RFC 378 number of the current document]" 380 Bit 1 "Sequence Number [RFC XXXX] [RFC Editor: please replace with 381 the RFC number of the current document]" 383 New registration requests MUST use the following template: 385 Bit: Desired bit to be allocated in the 8 bit Extension-Flags field 386 of the DEX option. 388 Description: Brief description of the newly registered bit. 390 Reference: Reference to the document that defines the new bit. 392 5. Performance Considerations 394 The DEX option triggers IOAM data to be collected and/or exported 395 packets to be exported to a receiving entity (or entities). In some 396 cases this may impact the receiving entity's performance, or the 397 performance along the paths leading to it. 399 Therefore, the performance impact of these exported packets is 400 limited by taking two measures: at the encapsulating nodes, by 401 selective DEX encapsulation (Section 3.1.1), and at the transit 402 nodes, by limiting exporting rate (Section 3.1.2). These two 403 measures ensure that direct exporting is used at a rate that does not 404 significantly affect the network bandwidth, and does not overload the 405 receiving entity. Moreover, it is possible to load balance the 406 exported data among multiple receiving entities, although the 407 exporting method is not within the scope of this document. 409 6. Security Considerations 411 The security considerations of IOAM in general are discussed in 412 [I-D.ietf-ippm-ioam-data]. Specifically, an attacker may try to use 413 the functionality that is defined in this document to attack the 414 network. 416 An attacker may attempt to overload network devices by injecting 417 synthetic packets that include the DEX option. Similarly, an on-path 418 attacker may maliciously incorporate the DEX option into transit 419 packets, or maliciously remove it from packets in which it is 420 incorporated. 422 Forcing DEX, either in synthetic packets or in transit packets may 423 overload the receiving entity (or entities). Since this mechanism 424 affects multiple devices along the network path, it potentially 425 amplifies the effect on the network bandwidth and on the receiving 426 entity's load. 428 The amplification effect of DEX may be worse in wide area networks in 429 which there are multiple IOAM domains. For example, if DEX is used 430 in IOAM domain 1 for exporting IOAM data to a receiving entity, then 431 the exported packets of domain 1 can be forwarded through IOAM domain 432 2, in which they are subject to DEX. The exported packets of domain 433 2 may in turn be forwarded through another IOAM domain (or through 434 domain 1), and theoretically this recursive amplification may 435 continue infinitely. 437 In order to mitigate the attacks described above, the following 438 requirements (Section 3) have been defined: 440 o Selective DEX (Section 3.1.1) is applied by IOAM encpsulating 441 nodes in order to limit the potential impact of DEX attacks to a 442 small fraction of the traffic. 444 o Rate limiting of exported traffic (Section 3.1.2) is applied by 445 IOAM nodes in order to prevent overloading attacks and in order to 446 significantly limit the scale of amplification attacks. 448 o IOAM encapsulating nodes are required to avoid pushing the DEX 449 option into IOAM exported packets (Section 3.1.2), thus preventing 450 some of the amplification and export loop scenarios. 452 Although the exporting method is not within the scope of this 453 document, any exporting method MUST secure the exported data from the 454 IOAM node to the receiving entity. Specifically, an IOAM node that 455 performs DEX exporting MUST send the exported data to a pre- 456 configured trusted receiving entity. 458 IOAM is assumed to be deployed in a restricted administrative domain, 459 thus limiting the scope of the threats above and their affect. This 460 is a fundamental assumption with respect to the security aspects of 461 IOAM, as further discussed in [I-D.ietf-ippm-ioam-data]. 463 7. References 465 7.1. Normative References 467 [I-D.ietf-ippm-ioam-data] 468 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 469 for In-situ OAM", draft-ietf-ippm-ioam-data-14 (work in 470 progress), June 2021. 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, 474 DOI 10.17487/RFC2119, March 1997, 475 . 477 [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. 478 Raspall, "Sampling and Filtering Techniques for IP Packet 479 Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, 480 . 482 [RFC7014] D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow 483 Selection Techniques", RFC 7014, DOI 10.17487/RFC7014, 484 September 2013, . 486 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 487 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 488 May 2017, . 490 7.2. Informative References 492 [I-D.ietf-ippm-ioam-flags] 493 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 494 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 495 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-05 496 (work in progress), July 2021. 498 [I-D.song-ippm-postcard-based-telemetry] 499 Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou, 500 T., Li, Z., Shin, J., and K. Lee, "Postcard-based On-Path 501 Flow Data Telemetry using Packet Marking", draft-song- 502 ippm-postcard-based-telemetry-10 (work in progress), July 503 2021. 505 [I-D.spiegel-ippm-ioam-rawexport] 506 Spiegel, M., Brockners, F., Bhandari, S., and R. 507 Sivakolundu, "In-situ OAM raw data export with IPFIX", 508 draft-spiegel-ippm-ioam-rawexport-05 (work in progress), 509 July 2021. 511 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 512 Writing an IANA Considerations Section in RFCs", BCP 26, 513 RFC 8126, DOI 10.17487/RFC8126, June 2017, 514 . 516 Appendix A. Hop Limit in Direct Exporting 518 In order to help correlate and order the exported packets, it is 519 possible to include the Hop_Lim/Node_ID data field in exported 520 packets; if the IOAM-Trace-Type [I-D.ietf-ippm-ioam-data] has the 521 Hop_Lim/Node_ID bit set, then exported packets include the Hop_Lim/ 522 Node_ID data field, which contains the TTL/Hop Limit value from a 523 lower layer protocol. 525 An alternative approach was considered during the design of this 526 document, according to which a 1-octet Hop Count field would be 527 included in the DEX header (presumably by claiming some space from 528 the Flags field). The Hop Limit would starts from 0 at the 529 encapsulating node and be incremented by each IOAM transit node that 530 supports the DEX option. In this approach the Hop Count field value 531 would also be included in the exported packet. 533 Authors' Addresses 535 Haoyu Song 536 Futurewei 537 2330 Central Expressway 538 Santa Clara 95050 539 USA 541 Email: haoyu.song@futurewei.com 543 Barak Gafni 544 Nvidia 545 350 Oakmead Parkway, Suite 100 546 Sunnyvale, CA 94085 547 U.S.A. 549 Email: gbarak@nvidia.com 551 Tianran Zhou 552 Huawei 553 156 Beiqing Rd. 554 Beijing 100095 555 China 557 Email: zhoutianran@huawei.com 559 Zhenbin Li 560 Huawei 561 156 Beiqing Rd. 562 Beijing 100095 563 China 565 Email: lizhenbin@huawei.com 566 Frank Brockners 567 Cisco Systems, Inc. 568 Hansaallee 249, 3rd Floor 569 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 570 Germany 572 Email: fbrockne@cisco.com 574 Shwetha Bhandari (editor) 575 Thoughtspot 576 3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout 577 Bangalore, KARNATAKA 560 102 578 India 580 Email: shwetha.bhandari@thoughtspot.com 582 Ramesh Sivakolundu 583 Cisco Systems, Inc. 584 170 West Tasman Dr. 585 SAN JOSE, CA 95134 586 U.S.A. 588 Email: sramesh@cisco.com 590 Tal Mizrahi (editor) 591 Huawei 592 8-2 Matam 593 Haifa 3190501 594 Israel 596 Email: tal.mizrahi.phd@gmail.com