Summary

  • RFC 9731's vn-compute RPC operates before instantiation. It can return a computed VN and connectivity-matrix references, but the specification explicitly says that it does not create a VN or reserve resources.
  • An accepted request, a computed abstraction, committed configuration, domain admission, instantiated tunnels, converged operational state, traffic observation and customer service are separate evidence states.
  • The safest approval records the topology, policy, constraints and resource snapshot behind the computation, then requires the actual resource owners to issue later receipts before anyone calls the network live.

The capacity review opened with a polished diagram. Every endpoint was connected. Each member had a path. The optimization objective had been satisfied. The first line of the recommendation said, “The network is ready.”

Nothing had been reserved.

The diagram came from a valid computation, not from a failed controller or a misleading model. The mistake happened after the result returned. A representation of what could be built was promoted into evidence that capacity had been committed, configuration had been accepted, tunnels existed and customer traffic could pass.

RFC 9731 makes that promotion indefensible. Its vn-compute operation is a pre-instantiation facility. The document says plainly that the computation does not create a virtual network or reserve any resources in the system.

That sentence is not a caveat at the edge of the model. It defines an authority boundary.

A customer view is deliberately incomplete

RFC 9731 defines a YANG model for Virtual Network operations. ACTN is its primary example, although the model is intended to be usable more generally and alongside service models for several network layers.

In the ACTN setting, a Customer Network Controller communicates with a Multi-Domain Service Coordinator. Access Points describe customer endpoint characteristics. Virtual Network Access Points describe how an access point is partitioned among VNs and connect the customer view toward provider-edge termination.

A Type 1 VN can appear as a set of edge-to-edge abstract links. A Type 2 VN can expose virtual nodes and links and can carry an intended path. Both are useful because the customer should not need the provider's entire internal network to express a requirement.

The abstraction is valuable precisely because it omits detail. It is not a defective underlay map. But the same omission means it cannot silently become proof about every hidden resource, policy and domain decision underneath it.

RFC 8309, which RFC 9731 cites for the service-model concept, states the principle in another form: a service model does not assume how a service is actually engineered and delivered. The customer view expresses intent and exposes selected state. It does not inherit all of the provider's execution evidence.

The computation precedes instantiation

Section 4.3.1 introduces VN compute as a way to view the full VN before instantiation. The caller can supply constraints and optimization criteria at the VN level or for individual members. Member-level values can override broader values.

The result can include a reference to a single-node abstract topology and, for each VN member, a reference to the connectivity-matrix entry where path properties can be found.

This is more useful than a generic “path found” response. It lets the caller inspect a structured result, relate members to an abstract topology and compare the computation with the requested constraints.

It still is not a reservation.

The MDSC computes from the supplied input and from information available locally or obtained in coordination with the CNC. The resulting VN is a calculation over an information state. No live VN is created. No resource changes owner. No domain is bound merely because its capacity was visible to the calculation.

The distinction resembles the difference between a quotation and a settled purchase, but the network case is harder. A computed path can depend on multiple domains, topology abstractions, local policies, optimization objectives and resource views that change on different clocks.

“Available” is not “committed”

The YANG module can report computation failures such as MDSC not ready, a dependent CNC being unavailable, no available resource, no path found or an unknown access point.

The presence of a “no available resource” failure can tempt an operator into treating the absence of that error as proof that resources have been secured. It proves no such thing.

At most, the computation found a result under the information and constraints it used. A later admission step may face a different resource state. Another requester may have committed the capacity. A local policy may have changed. An abstract link may have been remapped. A domain that participated in computation may reject the eventual configuration.

Availability is a property of the calculation's evidence snapshot. Reservation is an act by an authority that can commit the resource. Those claims need different authors.

A successful RPC has a narrow receipt

A successful vn-compute response can support several precise statements: the request was accepted; the computation completed rather than returning a defined error; the result contained particular members and topology references; the stated constraints were represented; and the response was produced at a particular time.

It does not alone show that the requester was authorized to create the live VN, that configuration entered the intended datastore, that every domain admitted the work, or that tunnels and Label Switched Paths came up. It also says nothing about traffic delivery, loss, latency, protection behavior or customer acceptance.

The useful discipline is not to distrust the RPC. It is to preserve its actual scope. “Computed successfully” is a strong receipt when it is not forced to carry the weight of later events.

One schema tree does not collapse reality layers

RFC 9731 follows the Network Management Datastore Architecture and includes operational state in the same tree as configuration. That design helps clients navigate related information. It does not make intended configuration and observed operational state interchangeable.

A configured VN member can exist while its operational state is down. Operational state can reflect an old configuration during convergence. A reader can retrieve a combined tree while different leaves were authored by different mechanisms and at different times.

The evidence record therefore needs datastore and timestamp context. Was a value intended, applied or operational? Was it returned from running state, operational state or a computation output? Which controller and model revision produced it?

Schema proximity is not causal identity.

The connectivity matrix is a reference, not a tunnel

The computed output refers to connectivity-matrix entries in an abstract topology. Those entries express valid switching combinations and potential TE paths through an abstract node.

The reference is meaningful. It lets the customer correlate a VN member with path properties without exposing the entire underlay. But a reference does not allocate bandwidth. It does not show that every underlay segment accepted configuration. It does not prove that an LSP was signaled, installed or forwarding.

If a later system copies the matrix identifier into a change ticket and labels the ticket “provisioned,” it has changed the semantics without adding evidence. The identifier still points to a modeled result.

Resource authority remains local

Multi-domain coordination makes the boundary more important. An MDSC can coordinate a computation without possessing unilateral authority to spend every domain's capacity.

Each domain may have its own admission policy, maintenance state, quotas, protection requirements and competing requests. A customer constraint can shape the calculation, but it does not override those authorities.

A defensible handoff names the owner of each later decision: the computation service signs the input and result snapshot; the configuration authority records the intended VN; each resource owner records admission or rejection; provisioning records the actual underlay objects; operations records convergence and health; and service observation records traffic at the customer boundary.

The chain can be automated. Automation does not eliminate the authorship of each state.

Freshness has to survive the gap

The most dangerous computed result is not obviously wrong. It is a correct result that outlives its evidence.

Between computation and instantiation, topology can change, resources can be consumed, policy can be edited, an access point can disappear or a dependent controller can become unavailable. The longer the gap, the more the result resembles a historical option rather than a current proposal.

An approval packet should bind the computation to the input constraints, member identifiers, abstract-topology and matrix versions, policy revision, resource-view timestamp, participating controllers and an expiry condition.

Without that envelope, a later operator cannot tell whether the result was recomputed or merely replayed.

Error categories do not cover the whole lifecycle

RFC 9731 defines useful computation-error reasons. They help distinguish an unready coordinator, unavailable dependency, missing resource, absent path and unknown endpoint.

These errors apply to the computation stage. A later reservation can fail for a reason that did not exist during computation. Provisioning can partially succeed. Operational state can fail to converge. Traffic can take a path whose abstract properties remain valid but whose observed performance does not meet the customer's need.

Treating the computation error set as the failure model for the whole service would erase those later stages. Each stage needs its own negative evidence as well as its success receipt.

Authorization must follow the operation

The security considerations for RFC 9731 rely on protected management protocols and the Network Configuration Access Control Model. The document notes that configuration and operational information can be sensitive, and that the vn-compute RPC can reveal VN information.

Permission to compute can therefore be powerful: it may disclose topology, endpoints, policies and potential capacity. That does not mean the same identity should be allowed to instantiate or modify the VN.

Read, compute, configure, reserve and delete are different capabilities. A least-authority design can allow a planning system to request computations while reserving live changes for a separately approved actor. The computation becomes decision support, not an implicit change request.

Discard is not rollback

Pre-instantiation computation creates no VN and reserves nothing. Discarding its output should therefore be cheap: stop using the result and, if needed, compute again.

Once configuration and resources have been committed, reversal is different. It may require deleting tunnels, releasing capacity, restoring previous policies, coordinating domains and protecting traffic.

Calling both actions “rollback” hides the point at which real state and real cost appeared. Before commitment, cancellation discards a proposal. After commitment, rollback changes a running system and requires evidence of restored service.

A practical receipt chain

First, capture the accepted computation request and its information snapshot. Second, retain the computed members, matrix references and errors. Third, create a distinct configuration decision with its approver. Fourth, collect resource admission from every required domain. Fifth, record the actual tunnel or LSP identifiers and installed state. Sixth, observe operational convergence. Seventh, test traffic at the customer edge. Finally, preserve customer-visible acceptance or the unresolved gap.

No receipt needs to claim more than it knows. The strength comes from joining them by stable identifiers and time.

RFC 9731 supplies the most important guardrail at the beginning: the network in the calculation is not yet the network in production.

Sources