Summary

  • RFC 9647 turns Babel management into an inspectable YANG-based interface by defining the ietf-babel YANG 1.1 module, compatible with the Network Management Datastore Architecture (NMDA), but it does not by itself prove that configured state became effective network behaviour.
  • The model exposes operational evidence such as interfaces, MAC and DTLS security objects, neighbour-related information and route state fields including prefix, router ID, neighbour, metrics, sequence number, next hop, feasibility and selection, while leaving implementations responsible for populating mandatory read-only information.
  • Operators evaluating Babel correctness need a multi-layer evidence chain: model revision and datastore origin, effective interface policy, security identity attachment, authenticated exchanges, route chronology, forwarding state and independent reachability tests.
  • A selected route is a management projection of implementation state rather than a packet-level measurement. It can support diagnosis, but it cannot replace proof from forwarding systems and external observation.

Babel deployments rarely fail because a single configuration value is missing. More often, they fail because different layers of evidence stop agreeing. A management system may contain a route object that says a prefix is selected. A device may report an enabled Babel interface. A neighbour record may exist. Yet none of those observations alone proves that packets are being forwarded correctly, that authentication succeeded with the intended identity, or that the network will converge correctly after a failure.

RFC 9647 addresses a specific operational problem: it creates a standardized YANG management model for Babel so that operators and controllers can inspect and configure important parts of Babel operation. It does not create a universal truth source for the entire routing lifecycle. The standard improves visibility into the protocol management surface, but the remaining proof obligation still belongs to the operator, implementation and surrounding network systems.

Published as a Standards Track document in October 2024, RFC 9647 defines the ietf-babel YANG 1.1 module. The module is compatible with NMDA as defined by RFC 8342, and it builds on the Babel management work described in RFC 9046. Its scope is Babel management over IPv6, providing a structured model for configuration and state retrieval rather than replacing Babel protocol behaviour specifications.

The distinction matters because YANG is a model of management information. It is not automatically a measurement instrument for every implementation decision between a configuration datastore and a packet leaving an interface.

What RFC 9647 makes visible

The value of RFC 9647 is that it establishes a common vocabulary for Babel management. Instead of relying on vendor-specific or implementation-specific representations, operators can reason about recurring objects and state transitions through the ietf-babel model.

The model covers several operational areas:

  • Babel enablement.
  • Protocol constants and timers.
  • Interface configuration.
  • MAC key sets.
  • DTLS objects.
  • Route information.

Route state is particularly important because it exposes the routing system’s internal view of selected paths. The model includes fields such as prefix, router ID, neighbour, received and calculated metric, sequence number, next hop, feasible status and selected status.

These fields are valuable diagnostic evidence. A route entry can show that an implementation has received information, evaluated it and represented the outcome. However, a selected route remains a management projection of implementation state. It is not an independent packet-forwarding measurement and it is not a reachability test performed from outside the routing system.

A route marked selected answers a question similar to: “Which path does the Babel implementation currently consider active?” It does not automatically answer: “Can traffic reach the destination?” or “Will forwarding continue correctly after this link disappears?”

The read-only state boundary

A central operational limitation is explicitly identified by RFC 9647: YANG cannot itself mandate that implementations populate mandatory read-only information-model attributes. A model can define that operational state exists, but it cannot force an implementation to expose meaningful runtime evidence.

This creates an important evidence boundary.

A missing operational attribute can mean several different things:

  • the implementation has not populated the state;
  • the state is unavailable at that management layer;
  • the information is delayed;
  • the implementation exposes only part of the model;
  • the operator is reading the wrong datastore or origin.

Therefore, the absence of information is not automatically evidence of a protocol failure. It is evidence that the operational chain has not been completed.

For serious operational assurance, the question is not only whether a field exists in the schema. The question is whether the deployed implementation provides the required state, at the required time, from the required datastore, with sufficient provenance to support a decision.

Administrative intent is not operational reality

RFC 9647 separates administrative intent from operational state. The enable leaf demonstrates this distinction.

An operator can express that Babel should be enabled in intended or running configuration. Operational state can then show the actual running condition. Those two observations can differ because of implementation constraints, conflicts, unsupported features or deployment conditions.

This is a common pattern in modern network management. A controller may successfully write desired state. That does not prove that every lower layer accepted, applied and acted upon it.

For Babel operations, the evidence chain begins with the configuration datastore but cannot end there. The operator must connect:

  1. The requested configuration.
  2. The applied configuration.
  3. The operational representation.
  4. The protocol behaviour.
  5. The forwarding outcome.

Each transition requires separate evidence.

Interface defaults create hidden decisions

Babel interface behaviour is not simply a matter of enabling a port. RFC 9647 exposes configuration choices that interact with the operational environment.

The standard describes default behaviour differences between wired and wireless interfaces. Wired interfaces use defaults based on two-out-of-three and split horizon. Wireless interfaces use ETX without split horizon. These defaults represent operational assumptions about link characteristics.

Those assumptions can become inaccurate when topology is more complicated.

Examples include:

  • radios connected behind wired ports;
  • tunnels that do not behave like ordinary wired links;
  • metered fallback paths;
  • interfaces where timers require deliberate tuning.

In such cases, operators may need explicit overrides rather than relying on classification defaults.

The management model makes those decisions visible, but it does not determine whether the chosen classification matches physical and economic reality. A tunnel may technically appear wired while carrying different failure characteristics. A backup path may be reachable but unsuitable for normal traffic because of cost constraints.

The model helps expose the choice. It does not remove the need to validate the choice.

Security objects require attachment proof

RFC 9647 includes MAC and DTLS objects, allowing security-related configuration to be represented through YANG. This is important because Babel deployments relying on authentication need more than a statement that security material exists.

Default-apply settings for MAC and DTLS can add references to newly created interfaces. That behaviour simplifies configuration management, but it introduces another verification point.

Operators must still prove:

  • which interfaces received the reference;
  • whether per-interface enablement is active;
  • whether the intended key or DTLS object is attached;
  • whether authentication exchanges actually succeeded.

Sensitive MAC keys and DTLS private keys receive NACM protections under RFC 8341. This reduces exposure through management access control, but access protection is not equivalent to protocol success.

RFC 9647 also makes its security scope clear. Its security discussion is limited to the YANG model itself. The broader Babel protocol, MAC authentication and DTLS-related security considerations remain covered by RFC 8966, RFC 8967 and RFC 8968.

The ten-receipt evidence chain

A practical Babel assurance process can be organized around ten receipts. Each receipt closes one possible gap between management state and observed behaviour.

1. Module revision and feature receipt

Confirm the deployed ietf-babel module revision, supported features and namespace information. A controller must know what model it is reading before interpreting state.

2. Datastore, origin and time receipt

Record whether information came from intended, running or operational state, along with collection time. State without temporal context can create false conclusions.

3. Required read-only state receipt

Verify that the implementation populates the operational attributes needed for the investigation. The schema alone is insufficient.

4. Interface classification receipt

Confirm whether interfaces are treated as wired, wireless or another operational category, and whether that classification reflects the real link environment.

5. Effective policy receipt

Capture defaults and overrides, including timers, split horizon choices and other interface-specific behaviour.

6. Security identity and attachment receipt

Show that MAC keys and DTLS objects exist, are protected appropriately, and are actually attached where expected.

7. Authentication and handshake receipt

Verify successful security exchanges rather than assuming that configured objects produced working authentication.

8. Neighbour and route chronology receipt

Examine how neighbours appeared, changed and influenced route state over time. A single snapshot can hide transition failures.

9. RIB and FIB installation receipt

Confirm that selected routes entered the forwarding decision path. Routing state and forwarding state are related but distinct.

10. Packet forwarding, recovery and independent reachability receipt

Validate behaviour through traffic observation, failure tests or external measurement. A management state claim must eventually meet a real network outcome.

This chain does not make Babel unique; it reflects a broader principle in infrastructure operations. Control-plane visibility is necessary, but not sufficient.

Operational decisions after RFC 9647

RFC 9647 changes the economics of Babel operations by reducing ambiguity in management interfaces. It allows automation systems and operators to ask more consistent questions. But it also exposes where automation must remain cautious.

A system that treats a selected route as equivalent to successful service availability collapses several evidence layers into one. A more reliable system treats the route selection as one receipt among many.

The practical decisions are therefore about evidence quality:

  • Which operational fields are required for assurance?
  • Which implementations provide enough read-only state?
  • Which defaults match actual link economics?
  • Which security attachments require explicit verification?
  • Which failures require packet-level confirmation?

The standard improves the ability to ask these questions systematically.

Sources