A YANG Data Model for Virtual Network (VN) Operations
Extracted elements (27)
A VN is modeled as a single abstract TE node with a connectivity matrix because this is the simplest representation for customers to express end-to-end connectivity without worrying about provider-internal topology details, consistent with service model principles in RFC 8309.
An empty 'underlay' container is deliberately included in the vn-member grouping to serve as an augmentation anchor for underlay technologies not modeled by RFC 8795 (e.g., Segment Routing Policy per RFC 9256). This future-proofs the model without prematurely encoding SR specifics.
Operational state is included in the same YANG tree as configuration, consistent with the Network Management Datastore Architecture (NMDA, RFC 8342), rather than maintaining a separate operational state tree.
The 'ap' container includes a 'pe' leaf allowing an AP to be created with only PE node information when customer access details are not yet known at VN creation time; customer access information can be added later. This supports phased provisioning workflows.
The VN compute RPC is provided as a pre-instantiation 'dry-run' operation so the CNC can view the full computed VN as a single entity before committing resources; this cannot be achieved with per-tunnel path computation or 'compute-only' tunnel setup, which lack the unified VN view.
The VN type (Type 1 vs Type 2) is not explicitly labeled in the YANG data model because the model itself is identical for both types; the type is implicitly determined by whether the referenced TE topology's connectivity matrix includes an underlay path (Type 2) or not (Type 1). This avoids a redundant discriminator field.
VN-level constraints and optimization criteria are delegated to the TE Topology model (RFC 8795) via a leafref to the abstract node's connectivity-matrix rather than duplicating them in the VN model. The vn-compute RPC is an exception, including constraints directly to allow standalone use without a pre-existing abstract topology.
For Type 2 VNs, the underlay topology referenced by the single abstract node may be either a Native/White topology or a Grey topology as defined in RFC 8453; the choice can be mutually agreed between CNC and MDSC prior to VN creation or established during VN instantiation.
The VN model can be used alongside existing customer service models — L3VPN Service Model (RFC 8299), L2VPN Service Model (RFC 8466), and L1 Connectivity Service Model — to provide complete lifecycle service management; future work on TE-SERVICE-MAPPING defines the VN-to-service mapping.
The VN YANG model is tightly coupled with the TE Topology model (RFC 8795); any underlay technology not supported by RFC 8795 is also unsupported by the VN model unless the 'underlay' container is augmented by a separate future model.
NETCONF access to the ietf-vn module MUST use SSH (RFC 6242) as the mandatory-to-implement secure transport at the lowest NETCONF layer.
RESTCONF access to the ietf-vn module MUST use TLS (RFC 8446) as the mandatory-to-implement secure transport at the lowest RESTCONF layer.
The abstract-node leaf in the VNAP list carries a YANG 'must' constraint requiring that the referenced network node be TE-enabled (i.e., have a 'tet:te-node-id' present); this is enforced at the data model layer.
A VN member (grouping 'vn-member') is keyed by 'vnm-id' and describes a single edge-to-edge link in the VN. It contains 'src' and 'dest' containers (each referencing an AP and optionally a VNAP plus a 'multi-src'/'multi-dest' boolean), a 'connectivity-matrix-id' leafref into the TE Topology model, and an empty 'underlay' container for augmentation.
Five VN computation error identities are defined, all based on 'vn-computation-error-reason': vn-computation-error-not-ready, vn-computation-error-no-cnc, vn-computation-error-no-resource, vn-computation-error-path-not-found, and vn-computation-ap-unknown. These are used as the 'error-reason' identityref in the vn-compute RPC output.
The 'access-point' container maintains a list of Access Points (APs) keyed by 'ap-id'. Each AP has fields for 'id', 'pe' (leafref to TE node), 'max-bandwidth', 'avl-bandwidth', and a nested 'vn-ap' list of VN Access Points.
The 'multi-src-dest' feature (optional YANG feature) enables flagging VN member sources or destinations as part of a pool; only one is selected at a time. Selection result is conveyed via the read-only 'if-selected' boolean leaf on each vn-member.
The 'virtual-network' container holds a list of VNs keyed by 'vn-id'. Each VN carries a 'te-topology-identifier' (provider-id, client-id, topology-id), an optional 'abstract-node' leafref, a list of 'vn-member' entries, 'admin-status', read-only 'oper-status', and an optional 'vn-level-diversity' policy leaf.
The VN Access Point (VNAP) list within each AP is keyed by 'ap-id' and carries references to the associated VN ('vn'), abstract node ('abstract-node'), and Link Termination Point ('ltp') in the abstract TE topology layer. A 'must' constraint enforces that the referenced abstract-node is TE enabled.
The 'vn-compute' RPC provides pre-instantiation VN computation. Its input accepts a TE topology identifier, optional abstract-node, VN-level and per-member path constraints (te-bandwidth, link-protection, priority, metric-bounds, affinities, SRLGs, disjointness), optimization criteria, class-of-service, and a vn-member-list. The output mirrors the member list with 'compute-status', 'if-selected', and 'error-info' (error-description, error-timestamp, error-reason identityref).
The 'vn-policy' grouping exposes a single leaf 'vn-level-diversity' of type 'te-types:te-path-disjointness', expressing the desired disjointness (node, link, SRLG) across all VN members of a VN.
Three typedefs are defined: 'vn-id' (non-empty string, VN identifier), 'ap-id' (non-empty string, AP or VNAP identifier), and 'vnm-id' (non-empty string, VN-member identifier). A fourth typedef 'vn-compute-status' aliases 'te-types:te-common-status', with only 'up' and 'down' considered meaningful; all others treated as unknown.
IANA has registered the YANG module 'ietf-vn' in the 'YANG Module Names' registry (RFC 6020) with namespace 'urn:ietf:params:xml:ns:yang:ietf-vn', prefix 'vn', and reference RFC 9731.
IANA has registered URI 'urn:ietf:params:xml:ns:yang:ietf-vn' in the 'ns' registry within the 'IETF XML Registry' (RFC 3688), with registrant contact the IESG.
Read-only nodes 'oper-status' and 'if-selected' may be sensitive as they reveal the current operational state of the VN and which vn-member is selected among multi-source/multi-destination options; read access should be controlled via NACM.
The 'vn-compute' RPC is sensitive because invoking it triggers computation at the MDSC and reveals VN information; access to this operation should be restricted via NACM. The MDSC represents a single point of failure and a significant threat vector requiring protection against malicious attacks and rogue elements.
Write access to the writable config nodes 'ap' (id, pe, max-bandwidth, avl-bandwidth), 'vn-ap' (id, vn, abstract-node, ltp, max-bandwidth), 'vn' (id, te-topology-identifier, abstract-node), and 'vn-member' (id, src/ap, src/vn-ap-id, dest/ap, dest/vn-ap-id, connectivity-matrix-id) without proper protection can allow an attacker to manipulate VN service delivery. NACM (RFC 8341) MUST be used to restrict access.