A Common YANG Data Model for Attachment Circuits
Extracted elements (30)
TCP-AO parameters (SendID, RecvID per RFC 5925 Section 3.1) are assumed to be preconfigured within the key chain referenced by the model rather than modeled explicitly, consistent with RFC 9182's approach. No assumption is made about how such a key chain is preconfigured outside this model.
The AC model ecosystem is layered: ietf-ac-common is imported by ietf-bearer-svc, ietf-ac-svc, and ietf-ac-ntw; ietf-ac-glue augments L2/L3 VPN service and network models (LxSM/LxNM) with AC references. This layering enables data inheritance from service to network models per RFC 8969 and facilitates correlation between service requests and network provisioning.
The common AC module is intentionally a pure library of groupings, identities, and types that exposes no writable data nodes, read-only state, or RPCs on its own. This design keeps security concerns in the consuming modules and allows the common module to be reused across service, network, and device model layers without introducing independent management attack surface.
The model explicitly covers only authentication options common to OSPFv2 (RFC 4577) and OSPFv3 (RFC 6565) and deliberately omits RFC 4552 (IPsec for OSPFv3). This avoids version-specific divergence in what is intended as a shared base module.
The authentication groupings support supplying explicit keys as ASCII strings rather than hexadecimal strings. Hexadecimal keys would afford greater entropy per octet but are excluded from this version because the underlying device modules (e.g., RFC 8695) do not support that format.
Authentication groupings for OSPF ('ospf-authentication'), IS-IS ('isis-authentication'), and RIP ('rip-authentication') each support either a key-chain reference or explicit key (key-id uint32, key string, crypto-algorithm). All are conditioned on an 'enabled' boolean leaf.
Bandwidth groupings define CIR, CBS, EIR, EBS, PIR, PBS (all uint64, units bps or bytes). The 'bandwidth-per-type' grouping supports per-CoS breakdown (keyed by cos-id uint8, using DSCP or 802.1p value) or aggregate bandwidth, selectable per bw-type identityref from vpn-common.
BGP peer group groupings ('bgp-peer-group-without-name' and 'bgp-peer-group-with-name') carry local-as, peer-as (inet:as-number), address-family (identityref supporting dual-stack), and role (bgp-role identityref per RFC 9234). The 'with-name' variant adds a name string leaf.
Four new administrative-status identities are defined extending vpn-common:administrative-status: 'awaiting-validation' (pending admin approval), 'awaiting-processing' (approved but awaiting activation processing), 'admin-prohibited' (blocked by policy), and 'rejected' (request rejected for reasons not covered by other types).
IPv4 and IPv6 connection groupings ('ipv4-connection' and 'ipv6-connection') provide local-address, virtual-address (for redundancy), prefix-length, address-allocation-type, and a choice between dynamic allocation (DHCP server/relay, explicit address pools) and static-addresses (ordered list of address-id + customer-address entries).
Layer 2 encapsulation groupings cover dot1q (tag-type + cvlan-id uint16 range 1..4094), priority-tagged (tag-type only), and qinq (tag-type + svlan-id + cvlan-id, both uint16 range 1..4094). These are used to represent VLAN tagging schemes on AC bearers.
Static routing groupings ('ipv4-static-rtg' and 'ipv6-static-rtg') define keyed lists of LAN prefixes where each entry carries lan (prefix), lan-tag (string for policy tagging), next-hop (union of ip-address or predefined-next-hop identityref), metric (uint32), and service-status. They are guarded by vpn-common:ipv4/ipv6 feature checks.
The 'ac-profile-cfg' grouping defines a 'valid-provider-identifiers' container listing provider-scoped profile references: encryption-profile-identifier, qos-profile-identifier, failure-detection-profile-identifier, forwarding-profile-identifier, and routing-profile-identifier. A nacm:default-deny-write statement restricts write access.
The 'address-allocation-type' identity hierarchy covers: provider-dhcp, provider-dhcp-relay, provider-dhcp-slaac (IPv6 only), static-address, slaac (IPv6 only), and dynamic-infra. SLAAC-based identities are conditioned on the 'vpn-common:ipv6' feature, and a YANG 'must' constraint prevents SLAAC from being set for IPv4 allocation.
The 'bfd' grouping carries a single holdtime leaf (uint32, units milliseconds) per RFC 5880 Section 6.8.18, representing the expected BFD hold time for failure detection on an AC. The 'redundancy-group' grouping provides a list of groups keyed by group-id with a precedence identityref (primary/secondary).
The 'bgp-authentication' grouping supports three keying-material options: TCP-AO (enable-ao boolean + ao-keychain key-chain-ref per RFC 5925), MD5 (md5-keychain key-chain-ref per RFC 4364 Section 13.2), and explicit (key-id uint32, key string, crypto-algorithm identityref). The keying-material container is conditioned on enabled='true'.
The 'ietf-ac-common' YANG module (namespace urn:ietf:params:xml:ns:yang:ietf-ac-common, prefix ac-common) defines reusable features, types, identities, and groupings for attachment circuits. It is designed to be imported by service models (e.g., ietf-ac-svc, ietf-bearer-svc) and network/device models (e.g., ietf-ac-ntw) to ensure consistent AC structures.
The 'l2-tunnel-type' identity hierarchy defines three Layer 2 tunnel types for ACs: pseudowire, VPLS (Virtual Private LAN Service), and VXLAN. The 'l2-tunnel-service' grouping selects among these using a type leaf and includes conditional sub-containers for each tunnel type.
The 'l3-tunnel-type' identity hierarchy defines three Layer 3 tunnel types: ip-in-ip (RFC 2003), ipsec (RFC 4301), and gre (RFC 1701/1702/7676). These are used to control Layer 3 tunnel selection for an AC.
The 'ospf-basic' grouping requires area-id (yang:dotted-quad, mandatory) and optionally address-family and metric (uint16). The 'isis-basic' grouping requires area-address (string matching pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}', mandatory) and optionally address-family.
The 'precedence-type' identity provides primary and secondary subtypes used to tag redundancy roles of ACs. The 'redundancy-group' grouping associates an AC with one or more group-ids and assigns a precedence (primary/secondary) for redundancy or protection constraint coordination per RFC 9181.
The 'pseudowire' grouping carries a vcid (uint32 VC identifier) and far-end (union of uint32 or inet:ip-address) per RFC 8077 Section 6.1. The 'vpls' grouping similarly has vcid and a leaf-list far-end. The 'vxlan' grouping carries vni-id (uint32), peer-mode (identityref, default static-mode), and peer-ip-address leaf-list.
The 'role' identity classifies the network role of an AC: uni (User-to-Network Interface), nni (Network-to-Network Interface), and public-nni (public peering, e.g., at an IXP). The 'bgp-role' identity (per RFC 9234) covers provider, client, rs, rs-client, and peer roles for BGP session establishment.
The 'service-status' grouping provides admin-status (writable identityref plus read-only last-change timestamp) and oper-status (read-only) containers for tracking service lifecycle. The 'op-instructions' grouping adds requested-start/stop and actual-start/stop (yang:date-and-time) leaves for scheduling.
Three YANG features are defined: 'layer2-ac' (support for ACs with Layer 2 properties), 'layer3-ac' (support for ACs with Layer 3 properties), and 'server-assigned-reference' (support for server-generated references that a client can use in subsequent requests, e.g., referencing a bearer when creating an AC).
IANA registered the YANG module 'ietf-ac-common' in the 'YANG Module Names' subregistry (RFC 6020) within the 'YANG Parameters' registry, with namespace urn:ietf:params:xml:ns:yang:ietf-ac-common, prefix ac-common, and reference RFC 9833.
IANA registered URI 'urn:ietf:params:xml:ns:yang:ietf-ac-common' in the 'ns' subregistry of the IETF XML Registry (RFC 3688) with IESG as registrant contact.
Modules reusing the authentication groupings ('bgp-authentication', 'ospf-authentication', 'isis-authentication', 'rip-authentication') inherit the security considerations of RFC 8177 (YANG Key Chain model). ASCII-only key representation limits key entropy compared to hexadecimal encoding.
Modules that reuse groupings such as 'ipv4-lan-prefixes' or 'ipv6-lan-prefixes' may expose privacy-related customer topology information. Disclosing such data may violate the customer-provider trust relationship and must be addressed in the security considerations of the consuming module.
The 'ietf-ac-common' module must be accessed via YANG management protocols (NETCONF/RESTCONF) using a secure transport layer (SSH, TLS, or QUIC) with mutual authentication. NACM (RFC 8341) should be used to restrict access to authorized users.