Internet Engineering Task Force J. Parikh Internet-Draft Arista Networks Intended status: Experimental C. Pignataro Expires: 16 May 2026 Blue Fern Consulting A. Clemm Sympotech 12 November 2025 Variable Length Node Data Field Option for In-situ Operations, Administration, and Maintenance (IOAM) draft-parikh-ioam-variable-length-field-00 Abstract The purpose of this memo is to describe a new IOAM Node Data Field type, called Flex Field, for In-Situ Operations, Administration, and Maintenance (IOAM). This option type, under IOAM Trace Option-Types will allow one to append variable length node data in an IOAM packet, along a network path. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 16 May 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Parikh, et al. Expires 16 May 2026 [Page 1] Internet-Draft Abbreviated Title November 2025 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Background and Motivation . . . . . . . . . . . . . . . . . . 2 3. Transport Options for the Flex Field . . . . . . . . . . . . 4 4. IOAM Flex Field Option Type . . . . . . . . . . . . . . . . . 4 5. Sample Use Case . . . . . . . . . . . . . . . . . . . . . . . 6 6. Secutiry Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction In Situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information while the packet traverses a path between two points in the network. [RFC9197] defines the data fields and associated data types for IOAM. Currently, every node data field (but one) defined in there is of fixed length, i.e. 4-octet or 8-octet, the only variable length field in that document is for the Opaque State Snapshot (Section 4.4.2.13. of [RFC9197]). What if a network operator wants to add important variable length node data, from the nodes along a network path, in an IOAM packet? This memo proposes a new option type for In-Situ Operations, Administration, and Maintenance (IOAM) [RFC9197], to address that. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Background and Motivation As we had discussed in the previous section, the [RFC9197] talks about IOAM data fields and different IOAM nodes types. Parikh, et al. Expires 16 May 2026 [Page 2] Internet-Draft Abbreviated Title November 2025 The term "in situ", in IOAM, refers to the fact that the OAM data is added to the data packets rather than being sent within packets specifically dedicated to OAM. IOAM (which uses the data plane) is used to complement mechanisms, such as Ping or Traceroute (which use the control plane). Now, many applications, interested in telemetry data across a path are not only interested in the entire path's comprehensive telemetry, (to paint a more holistic picture), but also in each individual node's telemetry. For example: Individual packet latency of each node, across the path. (This might look same like traceroute, but unlke traceroute, we could, with this, be getting the data-plane latency) Per-interface performance metrics: • Microbursts • Packet Drops • Traffic Rates • Congestion • Timestamps • Path consistencies, etc. Sustainable Networking Applications: • Carbon-Intensity of each node along the path (And using that as an input to applications that attempt to minimize pollution attributable to specific networking traffic) • Power Utilization of each node along the path, etc. And so, as discussed above, using IOAM, which traverses in the data plane, we would get an accurate idea of how the above mentioned telemetry metrics would look, for actual data plane packets/traffic. Now, due to the nature of this field, and how it is designed, it will have an upper limit when it comes to "how many nodes (data) can this field accomodate" and we have decided to keep it at 255 (with variable length). This should idealy be able to address an administrative domain's needs. And it is and will be both, backwards compatible with existing IOAM data field definitions and forward compatible for if any new data fields are introduced in the future. Parikh, et al. Expires 16 May 2026 [Page 3] Internet-Draft Abbreviated Title November 2025 3. Transport Options for the Flex Field So, as discussed above, we will be using XX (undefined) [---preferrably the 21st bit, so it's next to the opaque state snapshot, for easy processing---] bit for, the IOAM-Trace-Type field present in the "Pre-allocated and Incremental Trace-Option headers" (Section 4.4.1. of [RFC9197]), to represent the new Flex Field defined in this document. And, due to the nature of this field, when present, the Node Length (Section 4.4.1. of [RFC9197]) present in the IOAM Header, will exclude the length of this field. With this, logic processor will know that the actual bits 0-11 are done and can start on the XX bit (i.e. this document) with it's own length. 4. IOAM Flex Field Option Type This section defines a new node data field for IOAM Flex Field Option Type. And like other IOAM Option Types [RFC9197], this field can be transported by a variety of transport protocols, including NSH, Segment Routing, Geneve, BIER, IPv6, etc. [RFC9378] Flex Field Node Data Field Option Type 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Namespace-ID | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Data | ~ ~ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Flex Field Option Type Length: A 24-bit field, which will represent the length of the Flex Field. The length field MUST be present and populated with the "number of 4 octect words" in the entire Flex Field, including the header octet word (this will allow us to have significant amount of data in this field, and also have a uniformity in the length field processing across the packet, since the Opaque State Snapshot also will have a similar length calculation). This field will also let Parikh, et al. Expires 16 May 2026 [Page 4] Internet-Draft Abbreviated Title November 2025 the processing node know till what size does the Flex Field goes, so that it won't accidentally consider the Opaque State Snapshot Data Field as a part of the Flex Field. Hop Count: A 8-bit fields to represent the hop count to record the number of nodes along the path that successfully processed the Flex Field. The encapsulating node MUST set the value to 1, and each subsequent node (transit nodes, as well as the decapsulating node prior to performing decapsulation) MUST increment its value by 1. If the Hop Count at a node exceeds 255, that node MUST set the Hop Count to 0 and set Flag 1 ("Node Hop Count Exceeded") to prevent further processing of the Flex Field. Namespace-ID: As discussed in [RFC9197], this is a 16-bit identifier of an IOAM- Namespace. The Namespace-ID value of 0x0000 is defined as the "Default-Namespace-ID" (Section 4.3. of [RFC9197]) and MUST be known to all the nodes implementing IOAM. The Namespace-ID is populated by the encapsulating node and MUST NOT be changed by any of the intermediate nodes. For any other Namespace-ID value that does not match any Namespace-ID the node is configured to operate on, the node MUST NOT change the contents of the IOAM-Data-Fields except for the Namespace Flag (see below) Flags: Flags are 4-bit in length, which are used to indicate errors, which are encountered during the process of populating the data in the Flex Field. Once a flag is set, no further aggregarion occurs along the path. The encapsulating node MUST set the value of Flags to 0 upon transmission. When an intermediate node encounters receives a packet in which any of operations on that packet; instead, the IOAM data MUST be the Flags are non-zero, the node MUST NOT perform further IOAM forwarded as-is unchanged. Here's how the flags are defined: • Flag 0: 0x0000: Default Flag value. • Flag 1: 0x0001: Node Hop Count Exceeded. • Flag 2: 0x0010: Length Error. • Flag 16: 0x1111: Other error. Reserved: A 12-bit field, reserved for future usage. The IOAM encapsulating node MUST set the value to zero upon transmission. And IOAM transit nodes MUST ignore the received value (unless this field us used in a future memo) Parikh, et al. Expires 16 May 2026 [Page 5] Internet-Draft Abbreviated Title November 2025 Data: This field is the variable length field which will contain the actual data that the operator would like to append. Now, what gets into this space is dependent on the Namespace specific definition that the operator chooses to have inside their domain. As discussed in Section 4.3. of [RFC9197], the significance of IOAM-Data-Fields is always within a particular IOAM-Namespace and so, this gives the operators flexibility to append different types of variable length data for different Namespaces. Example: IOAM-Namespaces can be used to identify different sets of devices (e.g., different types of devices) in a deployment; if an operator wants to insert different IOAM-Data-Fields based on the device, the devices could be grouped into multiple IOAM- Namespaces. 5. Sample Use Case TBD 6. Secutiry Considerations As discussed in [RFC9378], IOAM is focused on "limited domains", as defined in [RFC8799]. IOAM is not targeted for a deployment on the global Internet, which would incur additional considerations such as the crossing of Trust Boundaries, authentication of IOAM data, or the desire to obfuscate domain internals to outside parties. The part of the network that employs IOAM is referred to as the "IOAM-Domain". 7. IANA Considerations TBD 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Parikh, et al. Expires 16 May 2026 [Page 6] Internet-Draft Abbreviated Title November 2025 [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, . [RFC9378] Brockners, F., Ed., Bhandari, S., Ed., Bernier, D., and T. Mizrahi, Ed., "In Situ Operations, Administration, and Maintenance (IOAM) Deployment", RFC 9378, DOI 10.17487/RFC9378, April 2023, . 8.2. Informative References Acknowledgements TBD Authors' Addresses Jainam Parikh Arista Networks 5453 Great America Parkway Santa Clara, 95054 United States of America Email: jainam@parikhgroup.net Carlos Pignataro Blue Fern Consulting United States of America Email: carlos@bluefern.consulting Alexander Clemm Sympotech United States of America Email: ludwig@clemm.org Parikh, et al. Expires 16 May 2026 [Page 7]