A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery
Extracted elements (31)
Cloud access and Internet access share a single cloud-access container because they share sufficient commonality at the service request level. Distinguishing Internet access from cloud access, or supporting private cloud access differently, is handled via augmentation or by using the site container with NNI flavor.
The L2SM is intentionally a service-layer abstraction model, not a device configuration model. It serves as input to an orchestration layer that translates it into network element configurations; the actual configuration of network elements via CLI, NETCONF, or device-specific YANG models is explicitly out of scope.
The model makes extensive use of YANG features to allow modular implementations, so capabilities such as site diversity, QoS, cloud access, extranet VPN, LAG, BFD, and Carriers' Carrier can be supported optionally. New behaviors or service types are intended to be added via YANG augmentation.
When VPN A lists VPN B as an extranet target, all sites in VPN B gain access to all sites in VPN A — the relationship is bidirectional despite only VPN A requiring explicit configuration. This non-obvious side-effect is explicitly called out and must be understood by operators.
The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. Its structure and usage are intentionally comparable to the Layer 3 VPN service model (L3SM) defined in RFC 8299.
By default, all sites in the L2VPN SHOULD be permitted to access the cloud or the Internet. Restrictions SHOULD be applied only when explicitly required, using permit-site or deny-site leaf-lists in the cloud-access container.
In the any-to-any VPN service topology, all sites MUST have the same role ('any-to-any-role'). In Hub-and-Spoke and Hub-and-Spoke-Disjoint topologies, sites MUST be assigned either a Hub role or a Spoke role.
L2CP solutions MUST NOT assume that all CEs are always running Layer 2 control protocols such as GARP/GMRP, because a CE may be a router that is unaware of Layer 2 details.
The management system MUST take into account constraints on Hub-and-Spoke-Disjoint connections, ensuring that Hub sites cannot communicate with each other as required by the topology definition.
MAC loop prevention is configurable at both site and site-network-access levels with protection-type, frequency, and retry-timer parameters. MAC address limits are set via limit-number, time-interval, and action, controlling behavior when the MAC table overflow threshold is reached.
NNI inter-AS connectivity is modeled with three option flavors: Option A (back-to-back VRF attachment), Option B (ASBR-to-ASBR with RT redistribution), and Option C (multihop MP-EBGP). The site-vpn-flavor-nni value identifies a site as an NNI interconnect point between administrative domains.
Per-access service bandwidth (svc-bandwidth) is specified by direction, type, optional cos-id, and the rate parameters CIR, CBS, EIR (optional), EBS (optional), PIR (optional), and PBS (optional). The svc-mtu leaf sets the service MTU for the network access.
QoS classification policy rules support two match types: match-flow (dscp, dot1q, pcp, src-mac, dst-mac, color-type, target-sites, any, vpn-id) and match-application (identityref). Matched flows are assigned a target-class-id for downstream QoS treatment via standard (pre-defined provider profile) or custom (per-class bandwidth, delay, jitter, loss) QoS profiles.
The availability container under site-network-access supports single-active and all-active redundancy modes for multihomed sites, with an access-priority value used to rank accesses within the same redundancy group.
The Carriers' Carrier feature (carrierscarrier) supports SP-to-SP carrier-grade L2VPN service. The signaling-type parameter under the carrierscarrier container specifies the pseudowire signaling protocol used in the carrier-within-carrier scenario.
The cloud-access container provides authorization rules for public cloud and Internet access. It uses a locally administered cloud-identifier and supports permit-site and deny-site leaf-lists implementing 'deny-any-except' or 'permit-any-except' policies.
The connection container's tagged-interface sub-container supports five VLAN tagging variants: priority-tagged (frame-priority level), dot1q-vlan-tagged (one or more CVLANs), qinq (CVLANs plus single SVLAN), qinany (unknown CVLANs plus single SVLAN), and vxlan (VNI identifier plus a peer-list of IP addresses).
The cvlan-id-to-svc-map container maps lists of CVLANs to a specific VPN service (VLAN-bundling). CE-VLAN ID preservation and CE-VLAN CoS preservation are configurable per vpn-service and ensure that VLAN header values are maintained end-to-end across all site-network-accesses in the service.
The extranet-vpns container allows a VPN to access resources in another VPN. A local-sites-role leaf specifies the role (e.g., spoke-role) that local sites assume in the target extranet VPN topology. No service configuration is required on the target VPN.
The frame-delivery container defines BUM (Broadcast, Unknown Unicast, Multicast) parameters for an L2VPN, including customer-tree-flavors (bidirectional, shared, source-based), per-frame-type delivery modes (bum-frame-delivery), and multicast group-to-port mappings via static configuration or GARP/GMRP.
The l2cp-control container manages Layer 2 Control Protocol handling for STP/RSTP/MSTP, PAUSE, LACP/LAMP, Link OAM, ESMC, 802.1x, E-LMI, LLDP, PTP peer delay, and GARP/MRP. Each protocol is assigned discard-mode, peer-mode, or tunnel-mode action.
The lag-interfaces sub-container models Link Aggregation Groups with LACP configuration (enabled, active/passive mode, speed, mini-link-num, system-priority), micro-BFD per-member-link monitoring (RFC 7130) with interval and hold-timer, and per-member-link physical attributes (speed, mode, link-mtu, 802.3ah OAM).
The OAM container integrates IEEE 802.1ag CFM (cfm-802.1-ag sub-container: MAID, MEP-ID/level/direction, remote-MEP-ID, CCM interval/holdtime, alarm-priority defect) and ITU-T Y.1731 PM (y-1731 sub-container: loss measurement, one-way/two-way delay measurement, frame size, session type) per site-network-access.
The site-network-access is composed of three parameter classes: bearer (sub-Layer 2 attachment requirements, e.g., access media type), connection (Layer 2 protocol properties including encapsulation-type and eth-inf-type), and availability (redundancy mode). Access type is either point-to-point or multipoint.
The untagged-interface sub-container configures basic physical properties (speed, mode, phy-mtu, lldp) along with optional advanced UNI features: IEEE 802.3ah link OAM and uni-loop-prevention (set to 'true' to enable MAC loop detection/prevention at the UNI).
The vpn-svc-type parameter supports six L2VPN service flavors: point-to-point LDP/L2TP VPWS, EVPN VPWS (RFC 8214), multipoint VPLS, rooted-multipoint VPLS, BGP MPLS-based EVPN (RFC 7432), and multipoint EVPN VPWS. Additional types can be added via YANG augmentation.
The YANG module 'ietf-l2vpn-svc' is structured around two top-level containers: 'vpn-services' (global VPN parameters per customer, keyed by vpn-id) and 'sites' (site connection details, keyed by site-id). A vpn-profiles container holds shared provider identifiers (cloud, QoS, BFD, remote-carrier).
Three VPN topologies are modeled: any-to-any (all sites communicate freely, single RT; default), Hub-and-Spoke (Spokes reach only Hubs, two RTs), and Hub-and-Spoke Disjoint (Hubs cannot communicate with each other, at least two RTs). Route Target allocation is performed by the management system.
VPN policies under the site container allow fine-grained traffic attachment rules using filter entries (type, lan-tag) mapped to VPN references with site-role assignments, enabling multi-VPN site attachments more complex than simple single-VPN connections.
The document registers the YANG module 'ietf-l2vpn-svc' in the IANA 'YANG Module Names' registry with namespace 'urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc' and prefix 'l2vpn-svc', referencing RFC 8466.
The ietf-l2vpn-svc YANG module contains writable data nodes that are potentially sensitive, including VPN topology configurations, cloud access authorization policies, and site attachment rules. Unauthorized access could allow VPN misconfiguration, traffic leakage between VPNs, or denial of service. Implementations must enforce access control (e.g., via NETCONF access control model, RFC 8341).