Summary

  • RFC 9835 stores a service-side attachment-circuit reference beside the node-scoped AC actually provisioned in the network. That correlation makes intent traceable; it does not prove bearer continuity, forwarding or delivery.
  • A complete operating record must preserve scope, inherited profiles, local overrides, parent-child dependencies, administrative state and operational state. Bare names and one green status discard the distinctions the model was built to retain.
  • The decisive receipt remains downstream: the intended configuration reached the correct targets, observable state followed it, scoped OAM passed, the whole service was healthy and customer traffic succeeded.

The order existed before the circuit did

Imagine an enterprise orders a new connection for a branch office. The service portal returns a stable identifier. An orchestrator accepts the request, chooses a provider edge and creates an attachment circuit. A dashboard now shows the same identifier beside a green symbol. Has the branch received service?

The identifier can prove that several systems are talking about the same request. It cannot prove that the physical or logical bearer is intact, that the correct interface was configured, that a VLAN or IP attachment is usable, that routing converged, that all VPN accesses are healthy or that the branch can exchange traffic. Correlation answers “which object?” before operations can answer “what happened?”

RFC 9835, published on the Standards Track in September 2025, specifies the ietf-ac-ntw network model for attachment circuits. The companion RFC Editor record fixes its status and publication identity. The model is not a marketing abstraction for connectivity. It is a structured account of the provider-side object that must be provisioned before or during service delivery.

That distinction is the article’s central control. The request, reference, configured AC, observed AC and delivered service are related records. They are not synonyms.

A bearer is not an attachment circuit

RFC 9833 supplies the common vocabulary. A bearer is the physical or logical link connecting a customer node or site to the provider network. The attachment circuit is the provisioned setup over that bearer that enables data exchange. One bearer may host several ACs, such as several VLANs over one physical link. One customer edge may terminate several ACs, and one AC may serve several peer service attachment points.

The cardinality matters. If a bearer fails, several ACs can fail together. If one AC is misconfigured, the bearer may remain healthy. A bearer reference can identify where a service should be bound without demonstrating that the requested service was correctly instantiated there.

RFC 9834 exposes bearers and ACs through customer-facing service models. RFC 9835 describes the network-side AC. RFC 9836 supplies the glue that lets Layer 2 and Layer 3 VPN service and network models refer to those ACs. The architecture therefore does not eliminate boundaries. It makes them addressable.

An honest inventory should preserve at least the bearer reference, customer-facing service reference, network ID, node ID, AC name and SAP binding. Compressing those fields into one global “circuit ID” may make a dashboard simpler while making an incident impossible to reconstruct.

svc-ref is a join, not a verdict

RFC 9835 says the network model uses the AC reference exposed by the service model to facilitate correlation between the service request and the actual AC provisioned in the network. The svc-ref stored on the network AC is therefore a powerful join key.

Its evidentiary ceiling is equally important. The reference says which service-side object the network AC is meant to implement. It does not prove that the reference was issued to the right customer, that the mapping was current, that the chosen node was correct or that the resulting configuration executed. A database can contain a perfectly valid foreign key to a failed service.

Names also have scope. In RFC 9835, the network AC name is unique within a node, not across the whole network. Whether service and network layers use the same naming convention is explicitly deployment-specific. Two nodes may each have an ac-17; one service may retain a stable external reference while its implementation moves to another node. Comparing bare names across systems invites false joins.

A durable receipt must record the tuple and its epoch: service reference, network, node, local AC name, controller or orchestrator that made the mapping, and the time at which it became authoritative. If the implementation moves, the customer-facing reference can remain stable, but the old and new mappings must not be made to look simultaneous.

This is where RFC 8969 helps. It distinguishes customer service models from network models and device models. Translation between them is operational work. The shared vocabulary reduces ambiguity; it does not make translation infallible.

Configuration is assembled from several places

RFC 9835 permits network-level profiles to factor common configuration across ACs. An AC inherits a profile value unless it refines the same node locally; the AC-specific value then takes precedence. That is efficient, but it makes the effective configuration a derived object.

An audit that stores only the profile name is incomplete. So is one that stores only the local override. To explain an incident, an operator needs the profile revision, the inherited values, each override, the precedence rule and the effective configuration sent to the device. Otherwise a later profile edit can rewrite the apparent history of an earlier deployment.

RFC 9836 adds another precedence boundary. When an AC is referenced for a VPN network access, the AC information takes precedence over overlapping inline information. This answers which intent wins. It does not prove that a controller applied the winning intent atomically, that all devices interpreted it alike or that rollback restored the prior state.

RFC 8342, the Network Management Datastore Architecture, gives the wider distinction among intended configuration and operational state. RFC 8345 provides the base network model that RFC 9835 augments. Together they make it possible to ask a better question than “is the object present?”: what was intended, what became effective, and what is operationally observed?

Parent-child convenience carries deletion power

The model can represent a Parent AC shared by several peer SAPs and Child ACs holding peer-specific information. Children inherit the parent’s properties. RFC 9835 then states a strong lifecycle rule: when a Parent AC is deleted, all its Child ACs must be deleted.

That rule prevents orphans inside the model. It also creates a high-impact control surface. A parent deletion can expand from one administrative act into several dependent removals. The schema does not prove that a production controller enumerated the right children, coordinated device removal, protected unrelated services, stopped billing or preserved rollback evidence.

Before approving deletion, the operator should produce a dependency receipt: exact parent identity and scope, child list, bound SAPs, services, bearers, effective profiles, current operational status and the expected device changes. After execution, it should compare that set with observed network state and customer traffic. “The parent row is gone” is evidence about the model, not about the absence of residual forwarding or customer harm.

The reverse warning also holds. Keeping a parent row does not prove that its bearer, child ACs or peer SAPs remain available. Symbolic continuity can survive operational failure.

Administrative and operational status must disagree visibly

RFC 9835 maintains administrative and operational status separately and identifies mismatch as a possible anomaly trigger. The common model in RFC 9833 includes states such as awaiting validation, awaiting processing, administratively prohibited and rejected. Those are workflow facts, not packet facts.

An approved request can wait for processing. A configured AC can be operationally down. An operationally up interface can carry the wrong VLAN, route or policy. A local AC can appear healthy while another access in the VPN is broken. The model’s separation is not bureaucratic duplication; it prevents one actor’s completion state from impersonating another layer’s evidence.

RFC 9408 makes the scope problem even clearer. A SAP is the provider-edge reference point where services can be delivered. Its service status at one SAP is not the overall network-level status of a service spanning several SAPs. Both administrative and operational evidence should be checked at the relevant point, then joined with the wider VPN state.

The L3VPN common types in RFC 9181, the L3VPN network model in RFC 9182 and the L2VPN network model in RFC 9291 provide the broader service structures into which these accesses fit. RFC 9543 extends the context to network slice services. None turns one local AC status into universal proof of customer experience.

The receipt ladder must reach the customer

The reliable operating sequence has nine distinguishable records:

  1. the customer or service process requested a bearer or AC;
  2. the service system accepted the request and assigned a reference;
  3. the orchestrator mapped it to a network, node, SAP and AC;
  4. profiles and local overrides produced an effective configuration;
  5. the controller submitted that configuration to the intended targets;
  6. operational state reported what those targets actually exposed;
  7. scoped OAM or protocol tests exercised the expected path;
  8. end-to-end service state covered every required access; and
  9. customer traffic or an application canary confirmed usable delivery.

Not every provider will retain these as nine separate databases. The point is semantic: a receipt at one rung cannot silently acquire the authority of the next.

The RFC record supports the model and its boundaries. It does not establish a named deployment, product conformance, incident, adoption rate, restoration time, saving or SLA result. This article therefore proposes an evidence practice; it does not report that anyone has implemented it.

Read access is also power

The security considerations in RFC 9835 warn that unauthorized reads can expose customer peer-SAP identities. Its writable subtrees can affect addressing, routing, filtering, encryption, keys and service binding. A controller account able to edit the join between service intent and network AC can redirect more than metadata.

Access control should consequently follow the same layers. A commercial system may create the service request without receiving permission to write routing keys. A network controller may update device intent without rewriting who the customer is. An observer may read operational state without gaining authority to alter the AC. Audit records should identify the authenticated actor, scope and old/new values, not merely the API that returned success.

The durable gain from RFC 9835 is a traceable seam. It lets an operator connect a promise made at the service layer to the object built inside the network while keeping their scopes visible. Automation becomes accountable when that seam leads onward to observation and customer outcome. It becomes theatre when the reference itself is treated as proof that the circuit worked.

Sources