YANG Data Models for Bearers and Attachment Circuits as a Service (ACaaS)
Extracted elements (30)
AC management is fully decoupled from higher-level service provisioning (e.g., VPN, network slice). This allows AC technology upgrades (new encryption schemes, routing protocols) to be made in one place rather than in each service model that uses ACs.
Groupings reusable across both the AC service model and the AC network model are placed in the shared 'ietf-ac-common' module (RFC 9833), while groupings reusable only among service models are kept in 'ietf-ac-svc'. This minimizes duplication and keeps service-layer and network-layer concerns separate.
The L2SM (RFC 8466) was rejected as the ACaaS reference model because it is primarily focused on Layer 2 aspects and does not cover Layer 3 provisioning, which is required for typical AC instantiation.
The L3SM (RFC 8299) was rejected because it does not sufficiently address Layer 2 provisioning, is limited to conventional L3VPN deployments, and does not support multiple BGP peer groups over a single AC — a common requirement in cloud and interconnection scenarios.
The 'ietf-ac-glue' module (RFC 9836) augments both the L2SM and L3SM to bind LxVPN services to ACs, referencing AC identifiers from 'ietf-ac-svc' and AC network references from 'ietf-ac-ntw'. The 'ietf-ac-ntw' module (RFC 9835) exposes the node-specific attachment interface details that the service model hides.
The YANG data models conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342, ensuring compatibility with NMDA-aware management systems. The models can be used independently of NETCONF/RESTCONF, consistent with RFC 8969.
A Child AC MAY rely upon more than one Parent AC; however, in such cases these parent ACs MUST NOT be overlapping. An example use case is a Child AC with separate L2 and L3 parent ACs.
An AC service activation with BGP routing SHOULD include at least the customer's ASN and the provider's ASN, enabling automated provisioning of BGP sessions without requiring manual exchange of configuration parameters.
For ACs requiring Layer 3 tunnel establishment, augmentations to 'l3-tunnel-service' MUST be conditional based on the tunnel type ('type') node to ensure correct conditional model structure.
The 'admin-status' attribute MUST NOT be influenced by the current operational state ('oper-status'). Administrative state represents deliberate operator intent and must remain independent of observed operational conditions.
The typedefs defined for each service/specific profile type and for AC references SHOULD be used when other YANG modules need to reference these profiles or ACs, to ensure consistent cross-model referencing.
Whenever a Parent AC is deleted, all its Child ACs MUST be deleted to maintain referential integrity in hierarchical AC configurations.
A bearer reference is a read-only, server-assigned string ('bearer-reference') that uniquely identifies a bearer within the provider network. Customers retrieve this reference and include it in AC service requests to unambiguously bind an AC to a specific bearer.
IS-IS routing support provides address-family, area-address, and authentication (key chain or explicit key/algorithm). RIP support includes address-family (determining whether RIPv2, RIPng, or both are enabled), authentication, and status. Both protocols support admin and operational status tracking.
OSPF routing support includes address-family, area-id (yang:dotted-quad), metric, sham-link support (for shared-area backdoor-link scenarios per RFC 4577), authentication for OSPFv2 and OSPFv3 via key chain or explicit key/algorithm, and admin/oper status tracking.
Placement constraints in both 'ietf-bearer-svc' and 'ietf-ac-svc' allow specifying diversity requirements (e.g., avoid placing two ACs on the same PE). Constraint targets may be a named group, all other bearers/ACs, or all other groups, using the 'placement-diversity' feature from RFC 9181.
Service provisioning profiles in 'ietf-ac-svc' define five reusable identifier types: encryption-profile, QoS-profile, failure-detection-profile, forwarding-profile, and routing-profile. These allow providers to maintain named policy bundles that can be referenced across multiple ACs.
The 'ac-group-profile' defines reusable parameter sets for groups of ACs, identified by 'name'. Data nodes set at the individual 'ac' level override group-profile values, enabling a hierarchical configuration pattern consistent with the bearer model's timing constraint override mechanism.
The BGP routing structure supports peer groups and individual neighbors with per-entry configuration of local-AS, peer-AS, address-family (ipv4/ipv6/dual-stack), role (per RFC 9234), local-address, max-prefix, authentication (TCP-AO or MD5 via key chain), BFD failure-detection-profile, and per-neighbor timing constraints.
The 'ietf-ac-svc' YANG module manages attachment circuits as a service, covering L2 connection, IP addressing, routing protocols (static, BGP, OSPF, IS-IS, RIP, VRRP), OAM/BFD, security, and service profiles. The PE-to-AC mapping is intentionally hidden from this service model and maintained internally by network controllers.
The 'ietf-bearer-svc' YANG module manages bearers — physical or logical links connecting customer termination points to a provider network. It exposes bearer lifecycle, admin/oper status with timestamps, placement constraints, physical synchronization (SyncE), parent/child LAG relationships, and a server-assigned bearer reference used in subsequent AC requests.
The 'ip-connection' container configures IPv4 and IPv6 addressing for an AC, supporting static address lists, dynamic allocation (number-based or explicit pool ranges), provider DHCP, DHCP relay with customer server addresses, and a 'l3-tunnel-service' placeholder for future tunnel augmentations.
The 'l2-connection' container configures Layer 2 AC properties: encapsulation type (dot1q with cvlan-id, QinQ with svlan-id/cvlan-id, priority-tagged), L2 tunnel services (pseudowire with vcid/far-end, VPLS, VXLAN with vni-id/peer-mode/peer-ip-address), L2VPN binding, and a bearer reference.
The 'oam' container defines BFD sessions per AC, each identified by an 'id' and supporting local-address, remote-address, a reference to a failure-detection-profile, and a holdtime (uint32).
The parent/child AC relationship enables a stable Parent AC to anchor dynamic Child ACs via 'parent-ref' and 'child-ref' nodes. A Child AC may reference multiple Parent ACs (e.g., separate L2 and L3 parents), and the 'server-reference' read-only node returns a provider-assigned internal identifier for each AC.
VRRP (RFC 9568) is modeled as a routing protocol on an AC with address-family and status. No authentication node is included because RFC 9568 Section 9 defines no current VRRP authentication mechanism.
IANA registers two YANG modules — 'ietf-bearer-svc' and 'ietf-ac-svc' — in the IETF XML Registry (RFC 3688) and the YANG Module Names registry (RFC 6020), with namespace URIs under urn:ietf:params:xml:ns:yang:.
BGP session authentication in the model supports TCP Authentication Option (TCP-AO per RFC 5925) and MD5 via key chains (RFC 8177), consistent with RFC 4364 Section 13.2. TCP-AO key chains should cover SendID and RecvID beyond the RFC 8177 baseline.
OSPF, IS-IS, and RIP routing instances each include an 'authentication' container supporting key chain references or explicit key/algorithm specification. This ensures PE-CE routing sessions for ACs can be cryptographically authenticated regardless of the IGP used.
The YANG modules use 'ietf-netconf-acm' (NACM, RFC 8341) for access control. Write access to bearer and AC provisioning data must be restricted to authorized administrators, as unauthorized modifications could disrupt network connectivity for all services delivered over affected bearers or ACs.