A YANG Network Data Model for Layer 3 VPNs
Extracted elements (26)
Early L3NM versions reused RFC 8299 data nodes to avoid duplication, but that approach was abandoned in favor of the shared 'ietf-vpn-common' module (RFC 9181) because reusing L3SM nodes was interpreted as implying that L3NM deployment depends on L3SM, which is not intended.
'parent-service-id' is included in the VPN service data structure specifically to correlate the network-layer L3VPN with its triggering service order (e.g., an L3SM instance, a network slice, or a VPN+), enabling a controller to populate description fields and trace network instantiation back to a customer request.
Static routing uses separate IPv4 and IPv6 container structures rather than a combined address-family-agnostic container; a unified design was considered but abandoned specifically to ease mapping with the structure provided in RFC 8299.
The L3NM was initially built with a 'prune and extend' approach from RFC 8299 (L3SM) but is not defined as an augmentation of L3SM because a specific structure is required to meet network-oriented L3 needs; this design also ensures a service provider may deploy the L3NM without exposing or using the L3SM.
The reference architecture advocates a clear separation between service orchestration (L3SM at customer interface) and network orchestration (L3NM within the provider network), rather than a monolithic orchestrator, to keep network-centric information hidden from customers and to allow independent evolution of each layer.
Both the L3SM and the L3NM can operate within the ACTN framework (RFC 8453): the L3SM is used at the CNC-to-MDSC interface, while the L3NM is used at the MDSC-to-PNC interface and between parent and child MDSC in hierarchical multi-domain deployments.
The 'ietf-l3vpn-ntw' YANG data model conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.
It is RECOMMENDED to use the dual-stack address family for data nodes whose value is identical for both IPv4 and IPv6; if dual-stack and single-family entries coexist for the same data node, the dual-stack value takes precedence over the IPv4 or IPv6 value.
When static addresses are used, the 'primary-address' leafref MUST be set to the 'address-id' of the intended primary address to distinguish the primary connection address among multiple statically assigned addresses on the same VPN network access.
A 'vpn-network-access' (keyed by 'id') represents a PE-side attachment point; 'vpn-network-access-type' may be point-to-point, multipoint, irb (from an L2VPN identified by 'l2vpn-id'), or loopback. It aggregates connection, ip-connection, routing-protocols, oam, security, and service sub-containers.
A 'vpn-node' represents a set of policies applied on a PE (referenced by 'ne-id') within one L3VPN service; it references 'active-vpn-instance-profiles' (which override service-level values), supports optional MSDP configuration for multicast RP redundancy, redundancy 'groups', and admin/operational 'status' tracking.
BGP CE-PE configuration covers 'peer-as', 'local-as', 'multihop', 'as-override', 'allow-own-as', 'prepend-global-as', 'send-default-route', 'site-of-origin' (Route Origin Extended Community for loop prevention per RFC 4364 §7), 'bgp-max-prefix' with 'violate-action' and 'restart-timer', 'bgp-timers' (hold-time and keepalive), and 'authentication'.
Each 'vpn-service' is uniquely identified by 'vpn-id' (locally scoped to the network controller) and carries 'vpn-type', 'vpn-service-topology' (hub-spoke, any-to-any, or custom), 'status' (admin and operational with timestamps), 'underlay-transport' (abstract instance or ordered protocol list), 'vpn-instance-profiles', and 'vpn-nodes'.
IS-IS CE-PE configuration includes 'area-address', 'level' (Level 1, Level 2, or both), 'metric', 'mode' (active for sending/receiving PDUs, or passive for suppressing updates), and authentication via key chain or explicit key/algorithm.
OSPF CE-PE configuration includes 'area-id' (dotted-quad), 'metric', 'sham-links' (for sites sharing an OSPF area with a backdoor link), 'max-lsa', and authentication options (IPsec for OSPFv3, Authentication Trailer for OSPFv2/v3). The implementation chooses OSPFv2 or OSPFv3 when IPv4 or dual-stack is requested.
The 'connection' container defines Layer 2 connectivity including 'encapsulation' (dot1q with cvlan-id, QinQ with svlan-id/cvlan-id, priority-tagged), 'l2-tunnel-service' (pseudowire with vcid, VPLS, VXLAN with vni-id and peer-mode), 'bearer-reference' for L3SM correlation, and optional LAG interface ('lag-interface-id' with member links).
The 'ietf-l3vpn-ntw' module defines two top-level containers under 'l3vpn-ntw': 'vpn-profiles' for provider-maintained common profiles and 'vpn-services' (a list keyed by 'vpn-id') that nests 'vpn-nodes', which in turn contain 'vpn-network-accesses', forming a hierarchical network-centric model of L3VPN services.
The 'ip-connection' container specifies Layer 3 addressing per address family; for both IPv4 and IPv6 it supports 'provider-dhcp' (local server or relay), 'dhcp-relay' (customer DHCP servers), and 'static-addresses' (explicit address pools with start/end addresses). IPv6 additionally supports SLAAC using 'local-address' and 'prefix-length' to derive the advertised prefix.
The OAM container exposes BFD per VPN network access: 'session-type' (classic BFD per RFC 5880 or Seamless BFD per RFC 7880), 'desired-min-tx-interval' and 'required-min-rx-interval' in microseconds, 'local-multiplier', 'holdtime' in milliseconds, a 'profile' leafref to a BFD profile, and optional meticulous BFD authentication via key chain.
The 'routing-protocols' container allows multiple CE-PE routing instances (each with a unique 'id' and 'type'), supporting static, BGP, OSPF, IS-IS, RIP, and VRRP. Each instance can reference provider 'routing-profiles'; low-level policies are deferred to device configuration outside the L3NM scope.
The 'vpn-profiles' container holds 'valid-provider-identifiers' with named identifiers for encryption, QoS, BFD, forwarding, routing, and optional external-connectivity profiles; these are local policy references used when building VPN services and do not prescribe the internal definition of those profiles.
VPN instance profiles (keyed by 'profile-id') factorize reusable parameters; they include 'role', 'local-as', RD assignment modes (directly-assigned, auto-assigned full or from pool, suffix variants, or no-rd), and per-address-family 'vpn-targets' for RT import/export rules and 'maximum-routes' limits.
This document registers the YANG module 'ietf-l3vpn-ntw' in the IANA 'YANG Module Names' registry with namespace 'urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw' and prefix 'l3vpn-ntw'.
BGP authentication in the L3NM follows RFC 4364 §13.2 recommendations; supported options are TCP-AO (via key-chain reference requiring SendID/RecvID beyond RFC 8177), MD5 (via key-chain), explicit key with crypto algorithm, and IPsec SA. TCP-AO key chains are assumed to be pre-configured outside the L3NM.
No authentication data node is included for VRRP because RFC 5798 §9 defines no VRRP authentication mechanism; deployments relying on VRRP for PE-CE gateway redundancy should be aware that VRRP protocol traffic cannot be authenticated through the L3NM.
The L3NM YANG module contains sensitive data nodes (keying material, authentication keys, crypto algorithms) across BGP, OSPF, IS-IS, RIP, and BFD configurations. Access to the module MUST be restricted using NETCONF access control (NACM, RFC 8341) and transmitted only over secure, authenticated transports such as NETCONF over SSH.