]> Arista Networks

5453 Great America Parkway Santa Clara 95054 US jainam@parikhgroup.net

Blue Fern Consulting

US carlos@bluefern.consulting

Sympotech

US ludwig@clemm.org

General Internet Engineering Task Force IOAM 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.

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. 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 (). 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) , to address that.

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 when, and only when, they appear in all capitals, as shown here.

Background and Motivation As we had discussed in the previous section, the talks about IOAM data fields and different IOAM nodes types. 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.

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" (), to represent the new Flex Field defined in this document. And, due to the nature of this field, when present, the Node Length () 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.

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 , this field can be transported by a variety of transport protocols, including NSH, Segment Routing, Geneve, BIER, IPv6, etc.

Flex Field Node Data Field Option Type

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 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 , this is a 16-bit identifier of an IOAM-Namespace. The Namespace-ID value of 0x0000 is defined as the "Default-Namespace-ID" () 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)

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 , 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.

Sample Use Case TBD

Secutiry Considerations As discussed in , 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".

IANA Considerations TBD

References Normative References &RFC.2119; &RFC.8174; &RFC.9197; &RFC.9378; Informative References

Acknowledgements TBD