Summary

  • RFCs 9833–9836 define separate YANG views for a bearer, a customer-facing attachment-circuit service, the provider’s network attachment circuit and the references that bind those objects to L2 or L3 VPNs.
  • A provider may validate and approve a request while it remains awaiting-processing. Service and network identifiers may also follow different naming conventions. Acceptance and name equality therefore cannot prove realization.
  • The defensible evidence chain continues through network mapping, PE/SAP placement, intended and applied configuration, operational state, OAM and observed traffic. Each is a receipt with its own authority.

The customer portal showed a circuit. The provider network did not yet contain the circuit that the portal appeared to name.

That is not necessarily fraud, an outage or a standards violation. It is a boundary that RFC 9833, RFC 9834, RFC 9835 and RFC 9836 make unusually visible. Published in September 2025 as Standards Track documents, the four RFCs divide an attachment-circuit service into linked models. The split is not paperwork. It prevents one layer’s identifier and status from silently becoming authority over another layer’s resources.

The publication records for RFC 9833, RFC 9834, RFC 9835 and RFC 9836 establish IETF consensus and IESG approval. They do not establish that a provider has implemented the modules, accepted a particular order, configured a device or carried a packet. A standard is a coordination artifact. Operational truth begins where running systems preserve the references and expose the states the standard distinguishes.

The bearer is not the attachment circuit

A bearer is the underlying wired or wireless link. An attachment circuit is the setup over that bearer that lets a customer termination exchange data with a provider network. One bearer can carry several ACs. One AC can involve several customer edges or peer service attachment points. A customer edge can terminate several ACs across one or more bearers.

The cardinality matters. If an operator treats “bearer up” as “customer AC active”, it may report the health of a shared physical or logical substrate while the requested service binding is absent. If it treats a bearer identifier as the lifecycle key for every service above it, withdrawing one order can affect siblings that never granted that authority.

RFC 9834 lets a provider assign a bearer reference that the customer retrieves and later places in an AC service request. The provider can accept or reject customer-supplied identifiers, and an AC identifier is unique only inside the provider domain. The reference is therefore a scoped handle, not a universal truth. Its evidentiary value depends on who issued it, which domain accepts it and whether it still resolves to the intended bearer.

The order is deliberately portable

RFC 8309 defines a customer service model as the service requested or experienced by the customer, not the internal engineering by which the provider realizes it. RFC 9834 follows that rule. The customer describes the AC it wants; the provider retains decisions about provider-edge nodes, service attachment points, interfaces, topology and technology.

This is a feature of the design. A common service vocabulary can be stable while different providers make localized implementation decisions. It also creates an evidence obligation. The customer-facing object cannot be used as proof of a hidden PE/interface mapping that it was designed not to expose.

An accepted service request should therefore produce its own receipt: authenticated requester, authorization scope, bearer or peer-SAP reference, stable service-layer AC identifier, requested parameters, validation result and administrative status. None of those fields proves that the provider has selected network resources.

RFC 9833 makes the gap explicit with states such as awaiting-validation, awaiting-processing, admin-prohibited and rejected. In particular, a request can be approved and validated while still awaiting the work required for activation. A dashboard that renders every accepted request as green has compressed away a state the common model intentionally preserves.

The provider network needs another identity

RFC 9835 defines ietf-ac-ntw, the provider-side network model. It maps the service reference to the actual network AC and carries the detailed PE/SAP placement that the customer model omits. This is where an order begins to acquire a concrete network realization.

The RFC expressly leaves service-layer and network-layer naming conventions to the deployment. The two identifiers may be equal, but equality is not guaranteed and must not be inferred. The reference edge is the evidence. A controller that joins records because two strings happen to match can attach telemetry to the wrong order, especially after migration, import, rename or reuse.

Nor does a network-model row complete the chain. RFC 8969 places network models between service intent and device configuration, and calls for operational state and statistics to flow back up. The model can describe what orchestration intends to instantiate. It cannot by its mere existence prove that lower systems accepted or applied the result.

Glue is a relationship, not an outcome

RFC 9836 adds ietf-ac-glue. It augments the L3VPN service model in RFC 8299, the L2VPN service model in RFC 8466, the L3VPN network model in RFC 9181 and related network structures so that the VPN request and realization can point to the correct service and network AC identities. Comparable topology and service-assurance context appears in RFC 8345 and RFC 9543.

The glue reference answers a precise question: which AC object is associated with this VPN object? It does not prove that resources were allocated, device configuration was applied, the endpoint is reachable or an SLA is met. On a shared AC, it also does not give one VPN’s lifecycle operation authority over every other service using that circuit.

The failure mode is easy to miss. A valid service AC can map to network AC A while the VPN glue points to network AC B. Each object exists. Every identifier parses. The error lives in the relationship. A health screen that checks only object presence will approve the wrong graph.

Intended, applied and observed remain different

RFC 8342 distinguishes configured values, intended configuration and operational state. The intended view can differ from what is operational because of propagation delay, hardware interaction, protocols or other systems. Comparing <intended> with <operational> tells an operator how much intended configuration is actually in use.

The complete attachment-circuit receipt chain is therefore longer than an order status: authenticate and authorize the principal; issue or resolve the bearer reference; accept the AC service request; map the service identity to a network AC identity; select PE/SAP/interface resources; bind the correct VPN; produce intended device configuration; observe applied configuration and operational state; then measure OAM, reachability, traffic and service outcomes separately.

This chain is not a demand for one orchestrator or one internal architecture. RFC 7950 supplies the YANG language, while operators can choose different implementations. The common requirement is narrower: preserve the semantic distinctions and the references needed to reconcile them.

Security guidance must be equally exact. Writable model data and detailed topology can be sensitive; RFC 9408 provides a broader framework for evaluating YANG module security. But this evidence set identifies no breached provider and no exploited controller. It just shows why authorization must be attached to the correct layer and object. An authenticated request is not permission to mutate every resource that shares a bearer.

This is the practical form of Heng Lu’s minimum initial specification and localized future decision: standardize the deterministic references that participants must share, while leaving topology, resource selection and sequencing with the operator that owns them. His running-code primacy asks where those distinctions survive in deployed software. And his reality-first editorial discipline keeps the conclusion bounded. Four Standards Track RFCs define a strong control map. They do not certify a single live circuit.

Sources