Summary

  • RFC 9633 defines an NMDA-conformant YANG model for DetNet application flows, traffic profiles, service sub-layers, forwarding sub-layers and selected operational state.
  • A configured maximum latency or loss is a requirement, and app-flow-status=ready is a scoped device assertion. Neither records the packets, clocks, observation points or interval needed to prove the bound was achieved.
  • A defensible service receipt joins desired and applied configuration, per-node operational state, exact flow selection, counter epochs, independent measurement and the application or authority that accepts the result.

The management read ended with a neat word: ready. The application deadline had already expired.

Both facts can be true. They describe different objects.

RFC 9633 defines ietf-detnet, a YANG module for configuring and reading Deterministic Networking state. It can identify an application flow, attach a traffic profile, connect service and forwarding sub-layers, and expose an operational application status. The model is substantial because DetNet is not one knob. A service exists through a chain of classifiers, profiles, interfaces, service functions and forwarding treatments distributed along a path.

The temptation is to let the clean tree become the verdict. A controller writes a maximum latency of 100 milliseconds. Every expected branch exists. The ingress reports ready. The resulting screenshot looks like proof that the deterministic service has been delivered.

It is not. The tree says what has been requested, related and reported at a management surface. The deadline belongs to packet events and clocks.

A requirement leaf is not a sample

The model's traffic-requirements container can carry minimum bandwidth, maximum latency, maximum latency variation, maximum loss, maximum consecutive-loss tolerance and maximum misordering. Those names resemble a performance report because they use measurable units. Their role is different: they express what the DetNet service is required to provide.

The companion traffic-spec describes the source's promise or request to the network. It can state an interval, packet limits and payload sizes. The network uses that declaration to allocate resources and adjust queues. A promise about offered traffic is neither an observation that the source honoured it nor a record that the network met its side of the bargain.

This distinction matters when an incident becomes contractual. A configured max-latency says which threshold to test. It does not supply packet timestamps. A configured max-loss says what loss rate would be unacceptable. It does not provide the transmitted and received population, their interval or their discontinuity epoch. A zero misordering tolerance expresses a requirement. It does not prove that the egress saw an ordered sequence.

The data model makes requirements machine-readable. It does not turn requirements into measurements by naming them precisely.

Ready has a scope

RFC 9633 defines application-status identities including none, ready, failed, out-of-service and partial-failed. The ingress and egress application-flow status leaves are operational state: they are config false, and incomplete configuration defaults to none.

That is useful evidence. A device can distinguish configured intent from state it reports at runtime. It can say that an application attachment is ready or failed instead of asking the operator to infer readiness from the mere presence of configuration.

Yet ready remains a typed assertion with a local reporting boundary. It does not carry an observation interval, a packet population, a remote clock comparison or an application acknowledgement. partial-failed makes the scope especially visible: some egress instances may be ready while others have failed, and the flow may still be usable when ingress is ready. A dashboard that flattens that condition into one green service tile has discarded evidence the model preserved.

The right question is not whether the status is useful. It is: ready for what, reported by which node, for which app-flow and sub-layer bindings, from which datastore and read time, under which configuration epoch?

One coherent tree can still be one node's truth

The RFC allows provisioning on devices along an end-to-end path without depending on a signalling protocol. This is operational freedom, not atomicity. Each device can receive management transactions through NETCONF or RESTCONF. NMDA gives a disciplined relationship among intended, applied and operational views. None of that creates one indivisible transaction across every node.

RFC 9633's own security discussion states the consequence plainly: DetNet is a configured data plane, and changes that are not coordinated across all devices on the path can cause denial of service. That warning is also an evidence rule. A successful edit on one node proves only that one management action reached that node. An end-to-end claim needs receipts from the whole required set, joined to the same service identity and configuration generation.

A stale branch is not always obvious. One router may hold the new traffic profile while another still binds the forwarding sub-layer to the old one. A management collector may read nodes seconds apart while a rollout is in motion. The resulting aggregate tree can contain individually truthful values that never coexisted as one path state.

The receipt therefore needs time and identity, not just values: candidate and running transaction identifiers where available, module revision, device identity, service and app-flow names, exact sub-layer references, read timestamps and a declared rule for when the distributed change became effective.

Secure management protects access, not empirical truth

The model is intended to be accessed through management protocols such as NETCONF and RESTCONF. SSH, TLS and the Network Configuration Access Control Model help authenticate channels and restrict who can read or alter sensitive nodes. They protect the control surface from unauthorized use.

They do not independently validate the physical or forwarding reality described by a device. A properly authorized user can write a mistaken profile. A correctly authenticated server can report state from a defective implementation. A secure response can be stale, partial or read from a node outside the actual packet path.

This is not a weakness unique to YANG. It is the ordinary boundary between the authority to state something and evidence that the stated outcome occurred. Conflating the two makes access control carry a burden it was never designed to bear.

Counters need an epoch; deadlines need clocks

RFC 9633's examples combine DetNet state with interface operational data, including statistics discontinuity time. That small field exposes a large accounting problem. A counter without its reset or discontinuity epoch may look cumulative while actually covering only part of the incident. Two counters read from different nodes may refer to different windows.

Latency is stricter still. An end-to-end one-way bound requires clocks whose relationship is known, observation points that bracket the declared service, and a rule for associating the same packet at ingress and egress. Loss requires a packet population and a treatment for duplicates, late arrivals and replicated flows. Consecutive loss and misordering require sequence semantics, not only aggregate totals.

The measurement may be active, passive or hybrid. That choice belongs to a separate OAM design; RFC 9633 does not silently choose it. Whatever method is used, its selector must match the YANG app-flow. A probe that follows another queue, label stack, DSCP or member path cannot close the configured service claim simply because its name is similar.

What a service receipt should contain

The first record is the declared service: app-flow identity, match fields, traffic profile, service and forwarding sub-layers, requirement values and configuration revision. The second is the management act: who was authorized, which devices accepted which change, and when it became intended and applied.

The third is operational state from every required node, preserving none, ready, failed, out-of-service and partial-failed without flattening them. Each read carries device identity, datastore context, timestamp and relevant discontinuity information.

The fourth is packet evidence. It names the observation points, direction, flow selector, clock basis, interval, packet population, sampling policy and treatment of replication, loss, lateness and reordering. The measured values are compared with the requirement leaves; they do not overwrite those leaves.

The fifth is the outcome. The application or operational authority states whether the observation was sufficient, whether the deadline mattered at that layer, and what action followed. A rollback, exception or waiver is part of that history. A green status is not allowed to erase it.

This layered receipt follows the discipline in Heng Lu's writing: coordination records, installed state and running outcomes are related but not identical. The minimum useful specification makes each boundary visible so later adopters can improve it without granting a management schema authority over facts it cannot observe.

Sources