A Common YANG Data Model for Layer 2 and Layer 3 VPNs
Extracted elements (26)
The module defines 'inbound-bw' and 'outbound-bw' feature identifiers to supersede the 'input'/'output' terminology from L3SM (RFC 8299), explicitly noting that the L3SM terminology should be deprecated in favor of the directional terms defined here.
The 'qos-classification-policy' grouping intentionally limits Layer 4 match criteria to TCP and UDP in this revision, noting that future revisions may add SCTP or payload-based bitmask matching. Transport protocols using TCP/UDP as substrate may need to match on the 'protocol' field under 'l3' combined with TCP/UDP criteria.
The 'underlay-transport' grouping supports both abstract transport identifiers (VPN+, network slices, virtual networks) and explicit ordered protocol lists, reflecting that some deployments configure underlay via abstraction layers while others specify exact protocol stacks. The 'protocol' leaf-list is ordered-by user to preserve operator-specified priority.
The 'vpn-profile-cfg' grouping intentionally avoids defining the internal structure of profiles (encryption, QoS, routing, forwarding). This design allows the module to 'glue' a VPN service with locally defined value-added features (e.g., NAT instance binding, cloud connectivity) without prescribing how such features are implemented, supporting provider-specific extensions.
The 'vpn-route-targets' grouping is modeled as a list (rather than a simple leaf-list) to support use cases where an RT identifier is needed, such as associating an operator with specific RTs or expressing AND/OR operations across multiple RT entries.
The L3SM (RFC 8299) uses 'input'/'output' to identify bandwidth direction; the 'ietf-vpn-common' module replaces this with 'inbound-bw'/'outbound-bw' identities and feature flags. The L3SM terminology is declared deprecated in this document, establishing a migration path for future L3SM revisions.
The module imports and depends on four external YANG modules: ietf-netconf-acm (RFC 8341) for NACM, ietf-routing-types (RFC 8294) for route-target and route-distinguisher types, ietf-yang-types (RFC 6991) for yang:date-and-time, and ietf-packet-fields (RFC 8519) for ACL header field groupings used in QoS classification.
When the 'ietf-vpn-common' module is accessed via NETCONF, the mandatory-to-implement secure transport is SSH (RFC 6242). When accessed via RESTCONF, the mandatory-to-implement secure transport is TLS (RFC 8446).
Reusing the 'vpn-description' grouping from this module exposes privacy-related information, specifically the 'customer-name' leaf. Disclosing customer identity in network management data may constitute a violation of the customer-provider trust relationship and should be protected via NACM access controls in consuming modules.
The 'ietf-vpn-common' YANG module (namespace urn:ietf:params:xml:ns:yang:ietf-vpn-common) defines a reusable set of identities, types, and groupings shared across L2 and L3 VPN models including L3NM (RFC 9182) and L2NM. It does not expose any standalone data nodes; it is a library module meant to be imported by other VPN YANG modules.
The module defines feature flags for optional capabilities including encapsulation types (dot1q, qinq, vxlan, qinany, lag-interface), multicast (multicast, igmp, mld, pim), address families (ipv4, ipv6), routing protocols (rtg-ospf, rtg-bgp, rtg-rip, rtg-isis, rtg-vrrp, bfd), service constraints (bearer-reference, placement-diversity), and bandwidth/QoS (qos, inbound-bw, outbound-bw, encryption, fast-reroute, external-connectivity, extranet-vpn, carriers-carrier).
The 'placement-constraints' grouping defines a list of constraints keyed by constraint-type (identityref based on placement-diversity, covering bearer-diverse, pe-diverse, pop-diverse, linecard-diverse, same-pe, same-bearer). Each constraint specifies a target via a choice: specific group IDs, all-other-accesses, or all-other-groups.
The 'ports' grouping provides a YANG choice for source and destination port specification, each capable of expressing either a range (lower-port to upper-port, both inet:port-number) or a single port with an operator (e.g., eq, lt, gt). It reuses the 'port-range-or-operator' grouping from ietf-packet-fields (RFC 8519).
The 'qos-classification-policy' grouping defines a user-ordered list of QoS rules, each matching either by flow (IPv4/IPv6 L3 header fields or TCP/UDP L4 header fields reusing RFC 8519 packet-fields groupings) or by application identity (customer-application identityref). Each rule maps to a target-class-id string for internal CoS identification.
The 'route-distinguisher' grouping provides a YANG choice among five RD assignment modes: directly-assigned (explicit rt-types:route-distinguisher), directly-assigned-suffix (explicit uint16 Assigned Number subfield), auto-assigned (from named pool or full-auto, with read-only auto-assigned-rd leaf), auto-assigned-suffix (auto Assigned Number only, read-only auto-assigned-rd-suffix uint16), and no-rd (empty leaf).
The 'routing-protocol-type' identity hierarchy covers static-routing, bgp-routing, ospf-routing, rip-routing, isis-routing (with level-1/level-2/level-1-2 sub-identities), vrrp-routing, direct-routing (for directly connected LANs), pim-proto, and any-routing (policy wildcard). BFD session types classic-bfd and s-bfd are also defined.
The 'service-status' grouping defines a container 'status' with two sub-containers: 'admin-status' (writable, identityref based on administrative-status, with last-change timestamp) and 'oper-status' (read-only config false, identityref based on operational-status with last-change). Administrative status values include admin-up, admin-down, admin-testing, and admin-pre-deployment.
The 'service-type' identity hierarchy enumerates supported VPN service types: l3vpn (RFC 4364), vpls (RFC 4761/4762), vpws (RFC 4664), vpws-evpn (RFC 8214), pbb-evpn (RFC 7623), mpls-evpn (RFC 7432), and vxlan-evpn (RFC 8365). Used to identify the VPN service type in consuming models.
The 'underlay-transport' grouping provides a YANG choice between two cases: 'abstract' (transport-instance-id string plus instance-type identityref covering virtual-network, enhanced-vpn, ietf-network-slice) and 'protocol' (ordered leaf-list of protocol-type identityrefs covering IP-in-IP, GRE, VXLAN, Geneve, LDP, MPLS-in-UDP, SR/SRv6, RSVP-TE, BGP-LU).
The 'vpn-description' grouping provides common VPN administrative identification: vpn-id (string, locally significant), vpn-name (string), vpn-description (string), and customer-name (string). Intended for reuse at the service or network model level.
The 'vpn-profile-cfg' grouping defines a container 'valid-provider-identifiers' holding lists of profile identifier references: external-connectivity-identifier, encryption-profile-identifier, qos-profile-identifier, bfd-profile-identifier, forwarding-profile-identifier, and routing-profile-identifier. The grouping applies nacm:default-deny-write to protect profile bindings.
The 'vpn-route-targets' grouping models BGP Route Target import/export rules as a list of vpn-target entries (keyed by uint8 id), each containing a list of route-target values and a mandatory route-target-type leaf. A 'vpn-policies' container holds import-policy and export-policy string references. Applicable to both L3VPN (RFC 4364) and L2VPN (RFC 4664).
The 'vpn-signaling-type' identity hierarchy covers bgp-signaling (RFC 6624, RFC 7432), ldp-signaling (RFC 5036), and l2tp-signaling (RFC 3931), used to identify the control-plane signaling mode for a VPN service type.
The 'vpn-topology' identity hierarchy defines four topologies: any-to-any (all sites communicate freely), hub-spoke (spokes communicate with hubs only; hubs can communicate with each other), hub-spoke-disjoint (hubs cannot communicate with each other), and custom (controlled by import/export policies for complex hub-spoke roles).
IANA registered the URI 'urn:ietf:params:xml:ns:yang:ietf-vpn-common' in the 'ns' subregistry of the IETF XML Registry (RFC 3688), and registered the YANG module 'ietf-vpn-common' with prefix 'vpn-common' in the 'YANG Module Names' subregistry of the YANG Parameters registry (RFC 6020).
The 'ietf-vpn-common' module itself does not expose any writable data nodes, read-only state nodes, or RPCs, so it introduces no direct security issues. However, modules that reuse its groupings must identify their own security considerations, particularly because groupings like 'vpn-description' expose privacy-sensitive data (e.g., 'customer-name') whose disclosure could violate customer-provider trust relationships.