A YANG Data Model for In Situ Operations, Administration, and Maintenance (IOAM)
Extracted elements (25)
The 'flow-id' in the direct export profile can be assigned by a central controller or algorithmically by the encapsulating node. The document acknowledges that the algorithmic approach cannot guarantee uniqueness, but notes the probability of conflict is small due to the large (32-bit) ID space.
The model conforms to the Network Management Datastore Architecture (NMDA, RFC 8342), allowing operators to distinguish between intended and operational state. The 'info' container is config false (operational data), while 'profiles' and 'admin-config' are config true.
The POT profile intentionally only defines type 0 and requires augmentation for additional POT variants, aligning with RFC 9197 which defines only POT type 0. This avoids specifying configuration for unspecified cryptographic variants and allows extensibility.
The ietf-ioam module imports from three external YANG modules: ietf-access-control-list (RFC 8519) for ACL-based flow filtering, ietf-interfaces (RFC 8343) for interface references, and ietf-lime-time-types (RFC 8532) for timestamp type definitions.
The 'max-length' leaf and trace-type configuration are conditional on 'action-encapsulate' via YANG 'when' expressions, ensuring that transit and decapsulation nodes do not configure parameters that are only meaningful at the ingress/encapsulation node.
The 'enabled' leaf in 'admin-config' MUST be set to 'true' before anything in the /ioam/profiles/profile subtree can be edited. If 'false', any configuration in place is not used.
When the ACL filter type is used and the matched ACE 'forwarding' action is 'accept', IOAM actions MUST be driven by the accepted packets. This ties IOAM profile application to ACL-based flow identification.
Five YANG features gate the corresponding IOAM sub-profiles: 'incremental-trace', 'preallocated-trace', 'direct-export', 'proof-of-transit', and 'edge-to-edge'. A device advertises which options it supports by declaring these features.
The 'admin-config' container holds a single boolean 'enabled' leaf (default false) that gates all IOAM profile configuration. It MUST be set to 'true' before anything in the /ioam/profiles/profile subtree can be edited; if 'false', any configuration in place is not used.
The 'default-namespace' identity (Namespace-ID 0x0000) MUST be known to all nodes implementing IOAM; it is the mandatory base namespace used when no specific namespace is configured.
The direct export profile ('direct-export-profile') extends the tracing profile with two additional encapsulation-node-only leaves: 'flow-id' (uint32, for correlating exported data across nodes and packets) and 'enable-sequence-number' (boolean, default false, controls use of sequence number in the Direct Export Option).
The edge-to-edge profile ('e2e-profile') contains node-action and an 'e2e-types' container (conditional on action-encapsulate) with 'use-namespace' and a leaf-list of 'e2e-type'. It carries data added by the encapsulating node and interpreted only by the decapsulating node.
The 'filter' grouping supports an 'acl-filter' identity that references an ACE name via a leafref into /acl:acls/acl/aces/ace/name. The 'ace-name' leaf is only present when the filter-type is derived from 'acl-filter'.
The 'ietf-ioam' YANG module organizes IOAM configuration as a list of profiles under the top-level 'ioam' container. Each profile associates with one flow and contains sub-profiles for up to five IOAM option types: incremental tracing, pre-allocated tracing, direct export, proof of transit, and edge-to-edge.
The incremental tracing profile ('incremental-tracing-profile') has the same structure as the pre-allocated profile: node-action, trace-types, and max-length. Each node allocates and pushes its data immediately following the option header rather than into pre-allocated slots.
The 'node-action' identity hierarchy defines three roles: 'action-encapsulate' (ingress node that adds IOAM header), 'action-decapsulate' (egress node that removes IOAM header), and 'action-transit' (intermediate node). Default is 'action-transit'.
The pre-allocated tracing profile ('preallocated-tracing-profile') contains node-action, trace-types (use-namespace and trace-type list), and max-length. The 'max-length' field (uint32, in bytes) is conditional on 'action-encapsulate' and specifies the maximum length of the node data list.
The proof-of-transit profile ('pot-profile') contains 'use-namespace' (default default-namespace) and 'pot-type'. Only POT type 0 is defined (a 16-octet field); users must augment the module for additional POT types.
The 'protocol-type' leaf uses an identityref based on the 'protocol' identity to indicate the carrier encapsulation. Two base identities are defined: 'ipv6' (referencing RFC 9486) and 'nsh' (referencing RFC 9452).
The read-only 'info' container exposes 'timestamp-type' (identityref based on lime:timestamp-type, e.g., truncated PTP or NTP) and 'available-interface' list (keyed by if-name), assisting monitoring systems in interpreting IOAM data.
IANA registered the URI 'urn:ietf:params:xml:ns:yang:ietf-ioam' in the IETF XML Registry (RFC 3688) as an XML namespace for the ietf-ioam YANG module.
IANA registered the YANG module 'ietf-ioam' in the YANG Module Names registry (RFC 6020) with namespace 'urn:ietf:params:xml:ns:yang:ietf-ioam', prefix 'ioam', and reference RFC 9617.
NETCONF access MUST use SSH as the mandatory-to-implement secure transport (RFC 6242); RESTCONF access MUST use TLS 1.3 (RFC 8446) over HTTPS. The Network Configuration Access Control Model (NACM, RFC 8341) MUST be used to restrict which users can access IOAM configuration nodes.
Read access to /ioam/profiles/profile may reveal customer service deployment details and underlying network structure. Customer read access must be restricted to nodes representing only their own services to prevent disclosure of network topology or other tenants' services.
Unauthorized write access to /ioam/admin-config or /ioam/profiles/profile can disrupt IOAM functions, cause misbehaving profiles, and impact performance monitoring, data analytics, and network services for affected flows. These nodes are considered sensitive and require strict access control.