Summary

  • RFC 9938 is an IETF Informational framework. It gathers controller-plane concepts and requirements that could support a later solution; it explicitly leaves controller-plane protocol details to subsequent documents.
  • A flow request, path computation, reservation plan or controller configuration step is not a service receipt. It cannot alone establish every-hop admission and retention, PREOF operation, measured bounds, application delivery or authority to make a consequential decision.

The architecture review looked complete. A central controller could learn topology and capabilities, take a flow request through an API, calculate a path and configure nodes through NETCONF/YANG. A distributed option could carry signaling through the network. A hybrid option could combine the two. The slide titled that capability “deterministic service.”

That is one layer too high.

RFC 9938, published in March 2026, is A Framework for the Deterministic Networking (DetNet) Controller Plane. It is an IETF Informational document. Its abstract describes a framework overview of concepts and requirements that could be the basis for a future solution specification. Its introduction says the document does not provide the protocol details for a controller-plane solution; those solutions are for later documents.

That limitation is not a defect. It is the document's most useful operating fact. A framework makes the unfinished seams visible: what a controller needs to learn, request, calculate, allocate, configure and monitor before anyone can claim a deterministic result. It should not be misread as a receipt saying those things have happened in one network at one time for one service.

Three architectures are choices, not proof

RFC 9938 describes three types of DetNet control-plane architecture: fully distributed signaling, fully centralized SDN-like control and a hybrid model. The choice matters. In a centralized example, a controller collects topology and DetNet-capability information, receives a flow-establishment request through a UNI, API or northbound interface, and configures nodes using a mechanism such as NETCONF/YANG, DetNet YANG or a PCE-based controller. In a distributed example, network configuration information propagates through signaling protocols. In the hybrid case, protocols and controllers share the work.

None of those sentences describes one mandatory deployment. They describe possible information exchanges and their trade-offs. RFC 9938 even says that the protocol extensions requested for different hybrid combinations are future work.

This distinction protects operations as well as accuracy. “The controller received the request” proves that an input reached a control point. “The controller calculated a path” proves an algorithm produced a candidate under the information it had. “A configuration transaction was sent” proves an attempted instruction. Each fact is useful. None is the same fact as: every participating node accepted the relevant state, retained it through the service epoch, attached the desired queues and buffers, formed the intended protection graph, and carried the intended traffic inside the promised bound.

DetNet requirements expose the missing receipt

The requirements in RFC 9938 make the gap concrete. The controller plane is expected to support dynamic instantiation, modification and deletion of flows. That may include explicit-path determination, link bandwidth, buffer and other resource reservation, queueing discipline, bidirectional handling and aggregation. It must support the service-layer functions associated with Packet Replication, Elimination, and Ordering Functions (PREOF), and it must handle information about node and link characteristics.

Those are requirements to be satisfied by a solution, not a declaration that a solution has satisfied them. A path calculation is not a resource admission. A reservation request is not a reservation retained after a later change. A device configuration acknowledgement is not necessarily a proof that the relevant forwarding and queue state is effective for the particular flow. A collection of paths is not proof that replication, elimination and ordering are operating on the intended traffic population.

The multi-domain section sharpens the point. Controller-plane functions across domains would have to collaborate; controllers may need to discover one another, authenticate and negotiate per-hop behavior. Crossing a boundary adds both a technical and a governance seam. One controller's green state does not erase the evidence or authority required at another operator's boundary.

Build the service receipt, not a larger dashboard

The right response is not to demand that RFC 9938 become a universal controller. It is to preserve a receipt for each step its framework separates.

Start with the request: service and tenant identity, endpoints, direction, traffic specification, requested bound, requester and authority. Preserve the controller decision: topology/capability snapshot, algorithm and policy version, candidate path, rejected alternatives and configuration epoch. Preserve admission: per-node acknowledgement, allocated resource and queue, label or encapsulation state, protection role and expiry or renewal state. Preserve observation: what traffic population, direction, measurement method, time source and interval were used.

Preserve outcome: an independently observed service result at the boundary that suffered the consequence.

This is the practical meaning of Heng Lu's Running-Code Primacy. A shared framework, a model and a controller intention have value, but they do not outrank state that operators can locally verify in running systems. Minimum Initial Specification applies the same restraint: common semantics should name the deterministic facts needed for interoperability, not turn a planning or orchestration layer into an unchallengeable oracle.

Sources