Summary

  • RFC 9617 defines a YANG model for enabling IOAM and binding profiles to flows, protocols and supported option types; it standardizes configuration, not an end-to-end observation verdict.
  • A packet must still match the referenced ACE with an accept forwarding action, receive the intended option, traverse participating nodes, survive capacity limits, and reach an in-band or direct-export evidence sink.
  • Reliable operations need separate receipts for active datastore state, packet selection, encapsulation, per-node contribution, export sequence, collector custody, analytical judgment, authorized action and service outcome.

The controller had a green configuration

An operator read the active datastore and found admin-config/enabled set to true. The intended profile existed. Its filter pointed at the expected access-control entry, its protocol type selected IPv6, and the trace sub-profile listed the desired fields. A configuration dashboard could reasonably show green.

Then a packet crossed the network without producing the expected record. The green state did not reveal whether the packet matched the ACE, whether the ACE's forwarding action was accept, whether ingress encapsulation occurred, whether all nodes supported the requested feature, whether preallocated space was sufficient, whether export failed, or whether the collector discarded the result.

RFC 9617 is useful precisely because it makes configuration legible. It is dangerous only when legibility is promoted into observation. A model instance says what the system is instructed and able to do. The packet path supplies a different class of evidence.

The YANG tree is a control surface

The ietf-ioam module follows the Network Management Datastore Architecture. It exposes read-only information, an administrative enable, and a list of named profiles. Each profile can identify a filter, carrier protocol and one or more sub-profiles for incremental trace, preallocated trace, direct export, proof of transit or edge-to-edge data.

This is a strong shared contract. A controller does not need a vendor-specific configuration grammar to express a trace type or select IPv6 rather than NSH. Feature statements let a client discover which optional branches an implementation supports. Interface references and imported types constrain what can be configured.

None of that is a packet capture. Schema validity shows that the instance conforms to the model. Feature presence shows that an implementation advertises support. Active-datastore readback shows that a value is currently stored. These receipts stop before traffic selection and execution.

enabled=true is necessary state, not a retrospective claim

RFC 9617 says that setting the administrative parameter to true enables IOAM configuration and data-plane functionality for the system. That does not mean every packet now contains IOAM data. Profiles, filters, protocol choices, feature support and node roles still decide the operational surface.

An operator should therefore read enabled=true as permission for configured behavior to occur, not proof that it occurred on a named flow. The distinction resembles a circuit breaker that has been armed: the state matters, but the event log still has to show which circuit, transition and consequence followed.

A later readback also lacks historical reach. It cannot prove that the flag was true when an earlier packet arrived, unless the system preserves configuration epochs and joins them to packet or export time. Current truth is not automatically past truth.

The ACE is where policy meets a packet

The model can bind a profile to an access-control entry. RFC 9617 adds a decisive condition: IOAM actions must be driven by accepted packets when the matched ACE's forwarding action is accept.

That condition prevents a profile reference from becoming a universal flow label. The configured ACE must be the one that actually matched after ACL ordering, interface scope, address family and implementation behavior. A different earlier rule can decide the packet. A packet can miss the ACL entirely. A nominally matching rule can have a non-accept action.

Forensic evidence therefore needs the active ACL revision, ACE identity, interface and direction, packet five-tuple or equivalent selector, match result, forwarding action and configuration epoch. “The profile points to ACE-7” is design intent. “This packet matched ACE-7 under revision X and triggered IOAM” is an execution receipt.

Protocol type names the carrier, not the observed envelope

The protocol-type parameter indicates where IOAM data is to be embedded, such as IPv6 or the Network Service Header. It allows a common profile to express which encapsulation rules apply.

But a stored value of IPv6 does not prove that a particular packet carried the IPv6 IOAM option. It does not show whether the packet entered at the intended encapsulating node, whether another tunnel changed the outer header, whether a size policy prevented insertion, or whether a downstream node recognized the option.

The configuration receipt should be joined to an ingress observation: original packet identity, matched profile, encapsulation action, resulting option type and size, namespace, trace-type bitmap and a stable correlation value where available. Without that join, the model describes a route to evidence rather than the evidence itself.

Supported features can still produce partial traces

Incremental and preallocated trace profiles select a node action, namespace, trace types and maximum length. The two allocation methods differ, but both rely on actual participating nodes to contribute the requested information.

Feature advertisement is local. One implementation may support incremental trace while another does not. A requested trace type can be unsupported or unavailable at a node. Preallocated space can impose a physical boundary on how many node-data entries fit. A record that contains four nodes cannot, by its length alone, prove that the packet traversed only four nodes.

This is why absence requires care. A missing node may indicate path avoidance, missing capability, nonparticipation, allocation exhaustion, option removal, export loss or decoding failure. RFC 9617 configures the available mechanisms; it does not collapse those causes into a single meaning.

Direct export creates another evidence path

The direct-export profile can include a flow ID and enable a sequence number. The flow ID helps correlate records for the same flow across nodes and packets. Sequence numbers can make some gaps visible.

Neither field guarantees completeness. A collector may begin after the first record, so no sequence gap exposes the missing prefix. A reset or rollover needs an epoch. Records can be generated and lost before collection. Several exporters can reuse local sequence spaces. A flow ID is a correlator under a defined scope, not a globally authoritative flow identity.

The export receipt needs exporter identity, boot or configuration epoch, flow-ID scope, sequence behavior, send time, transport result, collector receive time, decoding result and retention status. Only then can a missing number support a bounded loss inference.

Proof of transit is not supplied by the profile name

The model includes a Proof of Transit profile, but RFC 9617 defines only a base type and expects augmentation for a specific variant. The presence of the branch therefore does not manufacture a cryptographic or operational proof.

Likewise, the edge-to-edge profile configures data added by an encapsulating node and interpreted by a decapsulating node. Its presence does not prove that both endpoints handled the same packet or that the service between them succeeded. Configuration names a mechanism; its later evidence must be evaluated under that mechanism's own semantics.

This boundary also protects the existing IOAM integrity question. An integrity validator can answer whether protected fields were modified under its declared method. RFC 9617 answers how an operator configures IOAM behavior. Neither answer proves the other's complete chain.

Build a receipt ladder that can fail honestly

The first receipt is active configuration: model revision, datastore, features, interfaces, profile, ACL reference, protocol and sub-profile fields. The second is selection: the packet matched the intended ACE and was accepted. The third is execution: ingress inserted or triggered the option actually configured.

Next come observation receipts: each participating node wrote the expected field under the correct namespace; limits and unsupported features were disclosed; export records preserved their scope and sequence; the collector received, decoded and retained them. Analysis then produces a hypothesis or decision. An authorized controller may turn that decision into a change, which still needs installation and outcome evidence.

No single green state should impersonate this ladder. The value of RFC 9617 is that it makes the first step interoperable. Operational truth comes from keeping the later steps distinct.

Sources