Summary

  • RFC 9912, an IETF Informational RFC from April 2026, extends the DetNet reliability and availability architecture to networks that combine wired and wireless segments.
  • RAW installs a finite set of feasible paths for a flow—the recovery graph—before failure conditions arrive. A Point of Local Repair (PLR) in the DetNet Service sub-layer can then select a protection path locally.
  • The faster network-plane loop does not replace slower route computation. It observes conditions, makes a bounded decision and acts within the graph, while accounting for imperfect metrics, shared spectrum, constrained bandwidth and energy.
  • Strict recovery-graph control offers stronger path knowledge and authority; loose control leaves more choice to local behavior where observability or centralized control is limited.

Theo March analysis: wireless determinism here means an engineered budget of alternate paths, measurements and switching authority. It does not mean that a radio link is permanently stable, that redundancy is free, or that RAW changes the underlying radio technology. RFC 9912 is an architecture document, not evidence of universal deployment or vendor support.

Claim-to-RFC evidence ledger

Claim Evidence
RAW extends reliability and availability across mixed wired/wireless networks. RFC 9912, Abstract and Section 1
A recovery graph is a finite set of feasible DetNet paths, with strict and loose forms. RFC 9912, Sections 3.3.2 and 5
A PLR selects protection paths inside the installed graph. RFC 9912, Abstract and Section 6
RAW separates route computation from a faster observation-decision-action loop. RFC 9912, Sections 2 and 6.1–6.2
Use cases, technology limits and OAM boundaries remain distinct. RFC 9450, RFC 9913, and RFC 9551

Operator acceptance decision path

  1. Map each critical flow to a finite recovery graph and identify where the graph has no feasible protection path.
  2. Decide whether strict or loose control matches the available topology knowledge, policy authority and observability.
  3. Verify that OAM and other observations are fresh enough for the intended control interval; do not invent safe thresholds from the architecture alone.
  4. Budget spectrum, bandwidth, processing and energy for protection activation, including shared-resource contention.
  5. Test damping, hysteresis and failure scenarios, then accept only the behavior that is measurable in the target radio environment.

Sources