A YANG Network Data Model for Layer 2 VPNs
Extracted elements (29)
LDP and L2TP signaling options are bundled under a single 'ldp-or-l2tp' container because both protocols share the AGI, SAII, and TAII attachment identifier parameters (encoded per RFC 4446 §3.4); only the inner choice discriminates between LDP-specific and L2TP-specific leaves.
The 'connection' container deliberately excludes physical-layer configuration, which is left to dedicated device modules (e.g., RFC 8343 interfaces module). This avoids manipulating global parameters at the service level and reduces the risk of inadvertently impacting other services sharing the same physical interface.
The L2NM provides a network-centric (service-provider-internal) view deliberately distinct from the customer-facing L2SM (RFC 8466). Customer site information is not required in the L2NM; only PE-side VPN network access points are modeled. Mapping from L2SM to L2NM is implementation-specific and using the L2NM does not assume nor preclude exposure of the L2SM to customers.
The L2NM uses IANA-maintained YANG modules for encapsulation type and pseudowire type identities rather than embedding them in the L2NM itself. This provides flexibility to handle new types via IANA process without requiring a revision of the L2NM YANG module.
The three-level profile hierarchy (service-level 'global-parameters-profiles' → node-level 'active-global-parameters-profiles' → access-level override) allows VPN parameters to be defined once and reused across nodes and accesses, with more specific levels taking precedence over more general ones to minimize configuration duplication.
For LAG interfaces, implementations (typically network controllers) should ensure consistency of shared parameters such as LACP system-id across all involved PE nodes, since the L2NM supplies the same parameters to multiple nodes. The L2NM inherits the 'member-link-list' structure from the L2SM including IEEE 802.3ah OAM support per link.
Signaling types are constrained per VPN service type: VPLS and VPWS support l2tp-signaling, ldp-signaling, and bgp-signaling (l2vpn-bgp), while VPWS-EVPN, PBB-EVPN, MPLS-EVPN, and VXLAN-EVPN exclusively use bgp-signaling (evpn-bgp). Mixing incompatible signaling types with VPN types is not permitted per Table 1.
The YANG data models in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. Implementations of the L2NM must support NMDA datastores (configuration and operational state are clearly separated per NMDA conventions).
Values defined in 'active-global-parameters-profiles' at the VPN node level override the corresponding values defined at the VPN service level, and values adjusted at the VPN network access level take precedence over those inherited from the active node profile.
When 'mac-loop-prevention' or 'mac-addr-limit' data nodes are provided at the VPN network access level, they take precedence over the ones included in the 'global-parameters-profile' at the VPN service or VPN node levels.
A 'vpn-network-access' represents a single entry point to an L2VPN. It binds to an interface ('interface-id'), references an active VPN node profile, carries per-access signaling options (CE ID, remote CE ID, EVPN VPWS instance, DF preference), grouping metadata for redundancy and ESI assignment, Ethernet OAM configuration, and access-level service parameters.
A 'vpn-node' abstracts the set of policies applied on a PE for one VPN service. It carries a network element identifier ('ne-id'), a 32-bit 'router-id', a role (hub, spoke, any-to-any), and 'active-global-parameters-profiles' that reference and selectively override service-level profiles. Both administrative and operational status are maintained.
Each 'vpn-service' is identified by a locally significant 'vpn-id' and declares VPN type (vpls, vpws, vpws-evpn, pbb-evpn, mpls-evpn, vxlan-evpn), service topology (hub-spoke, any-to-any, custom), signaling type, underlay transport preference, BGP auto-discovery flag, and administrative/operational status with timestamps. A 'parent-service-id' correlates the network service to its originating service order.
Ethernet OAM at the VPN network access level models IEEE 802.1ag CFM (N2-UNI-C and N2-UNI-N MEPs with MAID, MEP ID, level, CCM interval, holdtime, and PCP priority) and ITU-T Y.1731 (performance monitoring type, loss measurement, synthetic loss, one-way/two-way delay measurement, and frame size). The structure is inherited from RFC 8466 §5.3.2.2.6.
For BGP-signaled L2VPNs, the L2VPN-BGP subtree provides CE range, pseudowire encapsulation type (drawn from 'iana-bgp-l2-encaps'), and VPLS Edge ID/range. The EVPN-BGP subtree adds service interface type (VLAN-based, VLAN-aware, VLAN bundle), MAC learning mode, ingress/P2MP replication, ARP/ND proxy with mobility threshold, BUM management, and PBB backbone source MAC.
L2TP signaling parameters include a Router ID to uniquely identify the PE and a pseudowire type drawn from the IANA-maintained 'iana-pseudowire-types' module, in addition to the shared AGI/SAII/TAII parameters common to the 'ldp-or-l2tp' grouping.
LDP signaling parameters include AGI (encoded as route-distinguisher), SAII (uint32), remote targets with TAII and peer IP address, targeted-LDP pseudowire type, pseudowire type (from 'iana-pseudowire-types'), MAC address withdraw flag, per-peer VC ID with pseudowire priority, and QinQ s-tag/c-tag values.
The 'bgp-auto-discovery' container supports two BGP flavors: 'l2vpn-bgp' (with a VPN ID per RFC 4761/RFC 6624) and 'evpn-bgp' (with EVPN type, auto-RT derivation based on Ethernet Tag ID, and a read-only 'auto-route-target' leaf). RD and RT structure mirrors the global-parameters-profile.
The 'connection' container configures Layer 2 interface properties for a VPN network access: encapsulation type (untagged, dot1q, priority-tagged, QinQ) with tag operations (pop, push, translate), LAG/LACP parameters (mode, speed, system-id, admin-key, system-priority, member-link list with per-link MTU and OAM 802.3ah), flow control, LLDP, and split-horizon group assignment.
The 'global-parameters-profile' defines reusable per-VPN-service parameters including Route Distinguisher assignment modes (directly-assigned, from-pool, full-auto, suffix-auto, no-rd), VPN route targets, local ASN, service MTU, CE VLAN preservation, CE VLAN CoS preservation, control-word negotiation, MAC address limit, MAC loop prevention, and multicast tree flavor.
The 'ietf-ethernet-segment' YANG module manages Ethernet Segments for EVPN services. Data nodes include ESI type (types 0–5 per RFC 7432 §5), direct or auto-assigned ESI (with optional pool name), redundancy mode (Single-Active or All-Active), DF election parameters, split-horizon filtering, PBB backbone source MAC, and a list of member network elements and interfaces.
The 'ietf-l2vpn-ntw' module uses two top-level containers: 'vpn-profiles' (reusable provider-defined policy profiles) and 'vpn-services' (the set of managed L2VPN services). Each 'vpn-service' contains 'vpn-nodes', which in turn contain 'vpn-network-accesses', forming a three-level hierarchy.
The 'service' container at the VPN network access level provides access-level Layer 2 MTU, bidirectional bandwidth (svc-pe-to-ce and svc-ce-to-pe) expressed as CIR/EIR/PIR/CBS/EBS/PBS per-CoS or aggregate, QoS classification rules (DSCP, dot1q, PCP, src/dst MAC, color-type) with profile binding, MAC ACL policies, and BUM (Broadcast/Unknown Unicast/Multicast) handling.
The 'signaling-option' container at the VPN node level covers BGP, LDP, and L2TP pseudowire signaling. It includes 'advertise-mtu' and 'mtu-allow-mismatch' flags applicable to all signaling types. LDP and L2TP are grouped under a common 'ldp-or-l2tp' structure because they share AGI, SAII, and TAII parameters.
The 'vpws-service-instance' container (present only for VPWS-EVPN VPN type) configures local and remote VPWS Service Instance (VSI) identifiers per RFC 8214. Each VSI can be directly assigned (uint32) or auto-assigned from a named pool or fully automatically; auto-assigned values are available as read-only leaves.
Section 10.1 registers four YANG modules in the IETF XML Registry and YANG Module Names registry: 'iana-bgp-l2-encaps', 'iana-pseudowire-types', 'ietf-ethernet-segment', and 'ietf-l2vpn-ntw', with their respective namespaces, prefixes, and RFC references.
The 'iana-bgp-l2-encaps' IANA-maintained YANG module provides identity values for BGP Layer 2 encapsulation types used in the 'pw-encapsulation-type' leaf of the L2NM BGP signaling subtree. Section 10.2 establishes the initial registry content and the process for adding new encapsulation type identities.
The 'iana-pseudowire-types' IANA-maintained YANG module provides identity values for pseudowire types used in the L2NM's LDP and L2TP signaling subtrees. Section 10.3 establishes the initial registry content and the process for IANA to add new pseudowire type identities.
The writable data nodes in 'ietf-l2vpn-ntw' and 'ietf-ethernet-segment' (VPN topology, signaling parameters, route targets, MAC policies, ESI assignments) are sensitive: unauthorized write access could disrupt L2VPN services or redirect traffic to unintended parties. Standard NETCONF/RESTCONF access control (NACM, RFC 8341) must be applied to restrict modification to authorized principals.