A Network YANG Data Model for Attachment Circuits
Extracted elements (28)
BGP authentication follows the recommendations of RFC 4364 Section 13.2: TCP-AO (RFC 5925) is the preferred option, with MD5 supported for installed-base compatibility. TCP-AO parameters (SendID, RecvID per RFC 5925 Section 3.1) are assumed preconfigured in the referenced key chain, extending beyond the scope of RFC 8177.
Profile-based factorization at the network level (via 'ac-profile' and specific provisioning profiles) avoids redundant configuration across ACs. Values specified at the AC level take precedence over inherited profile values, enabling both reuse and selective overrides—consistent with the pattern established in RFC 9182 and RFC 9291.
Unlike the AC service model (RFC 9834), where an AC is scoped to a network, 'ietf-ac-ntw' identifies an AC uniquely within the scope of a node. This reflects that the network model operates at PE-node granularity, directly anchoring ACs to physical or logical network elements.
YANG feature flags (e.g., 'layer2-ac', 'layer3-ac', 'rtg-bgp', 'bfd') gate conditional subtrees to accommodate deployments that support only a subset of capabilities, avoiding a monolithic module that requires full implementation. This allows, for example, Layer-2-only or routing-protocol-specific deployments.
The 'ietf-ac-glue' module (RFC 9836) augments both service models (L2SM RFC 8466, L3SM RFC 8299) and network models (L2NM RFC 9291, L3NM RFC 9182) with AC references from 'ietf-ac-svc' and 'ietf-ac-ntw', binding LxVPN services to their underlying ACs.
The 'ietf-ac-ntw' module imports 'ietf-ac-svc' and 'ietf-bearer-svc' (RFC 9834) for AC and bearer service references, and 'ietf-ac-common' (RFC 9833) for shared groupings. The AC model ecosystem forms a layered dependency: ac-common is imported by bearer-svc, ac-svc, and ac-ntw; ac-ntw imports ac-svc for network-to-service correlation.
The module supports both UNI and NNI use cases per RFC 9408, with the AC 'role' set accordingly. In NNI deployments (e.g., inter-AS with ASBRs), an ASBR treats the adjacent network's ASBR as a CE, and the AC role is set to 'ietf-sap-ntw:nni'.
Whenever a Parent AC is deleted, all Child ACs of that AC MUST be deleted. Child ACs are referenced using the read-only 'child-ref' container.
AC status tracking maintains both 'admin-status' (read-write, with 'last-change' timestamp) and 'oper-status' (read-only, with 'last-change' timestamp). A mismatch between administrative and operational status can serve as an anomaly detection trigger.
An AC may belong to one or multiple groups via the 'group' list keyed by 'group-id'. The 'precedence' leaf (identityref) associates redundancy or protection constraints with grouped ACs, consistent with RFC 9181.
BFD OAM sessions are configured per AC under the 'oam' container. Each session (keyed by 'dest-addr') supports 'source-address', a failure-detection profile reference, 'session-type', 'desired-min-tx-interval', and 'required-min-rx-interval'. BFD can additionally be enabled per static route or BGP neighbor.
BGP support includes peer groups and per-neighbor configuration. Key parameters are 'peer-as', 'local-as', 'address-family', 'role' (RFC 9234 values), 'site-of-origin' (Route Origin Extended Community for loop prevention per RFC 4364 Section 7), 'bgp-max-prefix', 'bgp-timers' (hold-time and keepalive), BFD per-neighbor, and authentication via TCP-AO or MD5 key chains.
IS-IS support includes 'area-address', 'level' (Level 1, Level 2, or both), 'address-family', 'metric', 'passive' mode, per-instance 'status', and authentication via either a key-chain reference (RFC 8177) or explicit key/algorithm specification.
Multiple routing protocol instances ('routing-protocol', keyed by 'id') can be defined per AC to accommodate scenarios requiring multiple instances of the same protocol on the same AC. Supported types include static, BGP, OSPF, IS-IS, RIP, and VRRP, each controlled by a feature flag from 'ietf-vpn-common'.
OSPF support includes 'area-id' (dotted-quad), 'address-family', 'sham-links' (for backdoor link scenarios per RFC 4577/RFC 6565), 'max-lsa', 'passive' mode, and authentication. Authentication covers both OSPFv2 (RFC 5709, RFC 7474) and OSPFv3 (RFC 7166); RFC 4552 IPsec-based authentication is explicitly not supported.
Parent/Child AC relationships are expressed via 'parent-ref' (read-write, pointing to a parent AC on a specific node/network) and 'child-ref' (read-only, listing child ACs). Child ACs inherit parent properties; values set at the child level take precedence.
Provisioning profiles defined at the network level include 'encryption-profile-identifier', 'qos-profile-identifier', 'failure-detection-profile-identifier', 'forwarding-profile-identifier', and 'routing-profile-identifier'. The 'ac-profile' (keyed by name) groups routing-protocol and OAM parameters reusable across ACs.
RIP support includes 'address-family' (determining RIPv2 or RIPng), four configurable timers (update-interval, invalid-interval, holddown-interval, flush-interval in seconds), 'default-metric', and authentication via key chain or explicit key/algorithm.
Static routing uses 'cascaded-lan-prefixes' with separate IPv4 and IPv6 prefix lists. Each entry includes 'next-hop' (IP address or predefined type), optional 'lan-tag' for local policy enforcement, 'metric' for IGP export, 'preference' for route selection among equal destinations, BFD enable/profile reference, and per-entry admin/oper status.
The 'ietf-ac-ntw' YANG module augments both the 'ietf-network' model (RFC 8345) and the Service Attachment Point (SAP) model (RFC 9408) to provision attachment circuits on Provider Edges. ACs are managed under network nodes, with each AC uniquely identified by a name within the scope of a node (not a network).
The 'ip-connection' container (gated by 'layer3-ac') supports IPv4 and IPv6 address assignment via provider DHCP, DHCP relay, static addressing, or SLAAC (IPv6). 'address-allocation-type' selects the mode; 'local-address' and 'prefix-length' define the PE interface address and, for SLAAC, the advertised prefix.
The 'l2-connection' container (gated by the 'layer2-ac' feature) manages Layer 2 encapsulation type (dot1q, QinQ, priority-tagged), tag manipulation operations (pop/push/translate), L2 tunnel services (pseudowire, VPLS, VXLAN), bearer reference, and LAG interface configuration.
The SAP model (RFC 9408) is augmented with an 'ac' list under each SAP node, referencing ACs by leafref triplet (ac-ref, node-ref, network-ref). This allows controllers to filter available SAPs by service type and retrieve the ACs bound to each SAP.
The 'svc-ref' leaf stores a reference to the AC exposed at the service layer via 'ietf-ac-svc' (RFC 9834), enabling correlation between AC service requests and the actual AC provisioned in the network. Whether naming conventions are shared across service and network layers is deployment-specific.
VRRP support (RFC 9568) includes 'vrrp-group', 'backup-peer', 'virtual-ip-address' (list), 'priority', 'ping-reply', and per-instance status. No authentication node is included because VRRP currently has no defined authentication mechanism per RFC 9568 Section 9.
RFC 9835 registers the 'ietf-ac-ntw' YANG module in the IANA 'YANG Module Names' registry with namespace 'urn:ietf:params:xml:ns:yang:ietf-ac-ntw' and prefix 'ac-ntw'.
All routing protocols in the model (BGP, OSPF, IS-IS, RIP) include an 'authentication' container supporting key chains (RFC 8177) or explicit key/algorithm configuration. The 'security' container at the AC level references 'encryption-profile-identifier' for encryption policy. These mechanisms protect routing sessions established over ACs from spoofing and tampering.
The YANG module exposes writable data nodes that control network-level AC provisioning; unauthorized modification could disrupt connectivity or redirect traffic. The model relies on NETCONF access control (RFC 8341/NACM) to restrict write access. Read-only operational nodes (oper-status, child-ref, last-change) are protected from configuration writes by their 'config false' designation.