YANG Data Model for L3VPN Service Delivery
obsoleted by
- rfc-8299 — YANG Data Model for L3VPN Service Delivery
Extracted elements (26)
An NNI option A is modeled using the existing 'sites' container with 'site-vpn-flavor-nni' rather than a dedicated NNI construct. This allows the SP to recognize and apply NNI-specific default device parameters (ACLs, routing policies) while reusing the site abstraction. Options B and C are modeled separately in Section 6.15.
Route Target (RT) allocation for BGP PE-based VPNs is out of scope for the model; the management system is expected to allocate RTs automatically upon receiving a VPN service creation request, either by querying a network OSS or drawing from a pre-assigned RT pool. The model provides the topology request as input; the allocation mechanism is left to the implementation.
The model is a service-level abstraction intended for instantiation at the management/orchestration layer, not directly on network elements. A management system translates it into element-level configuration via NETCONF, CLI, or other mechanisms. How network elements are configured is explicitly out of scope.
The model uses YANG features extensively to allow modular implementations: IPv4/IPv6 support, individual routing protocols (rtg-ospf, rtg-bgp, rtg-rip, rtg-vrrp), QoS, encryption, cloud access, extranet VPN, site diversity, BFD, fast-reroute, and multicast are all gated by feature declarations, so implementations can advertise only supported capabilities.
This specification is limited to BGP PE-based VPNs as described in RFC 4026, RFC 4110, and RFC 4364. The service model is not intended for use directly on network elements; implementations must interact with element-level YANG models (BGP, VRF, BFD, etc.) via NETCONF/RESTCONF (RFC 6241, RFC 8040) or CLI. Section 8 discusses interaction with other YANG modules.
If a parameter is configured at both the site level and the site-network-access level, the access-level parameter MUST override the site-level parameter. This inheritance rule applies to routing, service, and security parameters.
If the 'strict' leaf in the bearer 'requested-type' is true, the management system MUST treat the media type as an inviolable constraint and cannot substitute another. If the 'always-on' leaf is set to true, the management system MUST elect an always-on media type (ruling out dial-access types).
In the any-to-any VPN service topology, all sites MUST have the 'any-to-any-role'. In the Hub-and-Spoke or Hub-and-Spoke Disjoint topologies, sites MUST have either a Hub role or a Spoke role.
The management system SHOULD honor all customer-specified site placement constraints. If a constraint is too strict and cannot be fulfilled, the management system MUST NOT provision the site and SHOULD provide relevant diagnostic information to the user.
The SP MUST honor the termination of the access on the location associated with the site-network-access on the customer side. The 'country-code' in site location SHOULD be expressed as an ISO ALPHA-2 code.
When a Hub site and a Spoke site must be meshed on the same PE, the management system MUST place them in different VRFs. The management system MUST take into account all constraints on Hub-and-Spoke connections in both the Hub-and-Spoke and Hub-and-Spoke Disjoint topologies.
When NAT44 is required for cloud access, the 'enabled' leaf MUST be set to true in the 'nat44' container. By default, all sites in the IP VPN MUST be authorized to access a configured cloud; per-site restrictions are applied via 'permit-site' or 'deny-site' leaf-lists using 'deny-any-except' or 'permit-any-except' semantics.
Access diversity constraints are specified via a 'groups' container (assigning site-network-accesses to named groups) and a 'constraints' list (specifying a constraint-type identity such as 'pop', 'pe', or 'linecard' and a target referencing another group, all other accesses, or all other groups). This drives multihoming placement without prescribing the SP's internal mechanism.
Cloud access is configured via the 'cloud-accesses' container under vpn-service, identified by a cloud-identifier string. It supports NAT44 address translation (with optional customer-provided IPv4 address) and per-site authorization filters. A private cloud may instead be addressed through NNI configuration.
Extranet VPN access is configured via the 'extranet-vpns' container on the accessing VPN only; no configuration is required on the target VPN. However, as a side effect, all sites in the target VPN gain access to all sites in the accessing VPN. The 'site-role' leaf specifies the accessing sites' role in the target VPN's service topology.
IP address allocation for site connections supports five modes: provider-dhcp, provider-dhcp-relay (customer provides DHCP server addresses), static-address, slaac (IPv6 only), and provider-dhcp-slaac (IPv6 only). In dynamic modes, the SP is expected to provide at minimum an IP address, mask, and default gateway.
Multicast service for IP VPNs is configured via the 'multicast' container. Parameters include customer tree flavors (bidirectional, shared, source-based), RP-to-group mappings with provider-managed or customer-managed RP options (redundancy, optimal-traffic-delivery), and RP discovery mechanism (auto-rp, static-rp default, or bsr-rp).
QoS classification policy rules support two match types: 'match-flow' (matching DSCP, dot1p, IPv4/IPv6 src/dst prefixes, L4 src/dst ports, port ranges, or IP protocol field) and 'match-application' (identity reference). Each rule maps to a 'target-class-id' string for downstream QoS profile application.
Routing protocol configuration supports OSPF (address-family, area-address, metric, optional sham-links keyed by target-site), BGP (autonomous-system, address-family), static (cascaded LAN prefixes with next-hops for IPv4 and IPv6), RIP (address-family), and VRRP (address-family). Multiple protocols can be active simultaneously at both site and access level.
Site VPN flavor determines how VPN multiplexing is performed: 'site-vpn-flavor-single' (one VPN), 'site-vpn-flavor-multi' (all logical accesses map to the same set of VPNs), 'site-vpn-flavor-sub' (each logical access maps to a different set of VPNs), and 'site-vpn-flavor-nni' (option A NNI).
The site-network-access model includes five major sub-containers: bearer (sub-Layer-3 attachment), ip-connection (IPv4/IPv6 addressing and BFD OAM), security (authentication and optional encryption with PSK or PKI), service (bandwidth, QoS, multicast, carriers' carrier), and routing-protocols (OSPF, BGP, static, RIP, VRRP).
The YANG module 'ietf-l3vpn-svc' is structured around two top-level containers: 'vpn-services' (global VPN parameters per customer, keyed by vpn-id) and 'sites' (per-site configuration including network accesses). This separation reflects the service abstraction: VPN-level policies and site-level connectivity are managed independently.
VPN attachment at the site-network-access level is expressed via the mandatory 'vpn-attachment' container, either by referencing a 'vpn-id' directly (with a 'site-role' leaf) for simple cases, or by referencing a 'vpn-policy-id' for multi-VPN scenarios with optional per-LAN-tag or per-prefix filtering.
VPN service topology is required configuration and supports three values: any-to-any (all sites communicate freely), Hub-and-Spoke (Spokes cannot communicate with each other; Hubs can), and Hub-and-Spoke Disjoint (Hubs also cannot communicate with each other). The default is any-to-any. New topologies can be added via augmentation.
Section 11 registers the YANG module 'ietf-l3vpn-svc' in the IANA YANG module registry with namespace 'urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc' and prefix 'l3vpn-svc', referencing RFC 8049.
Security configuration is provided at both site and site-network-access levels (access level overrides site level). The 'encryption' container (feature-gated) includes an 'enabled' leaf, a 'layer' enumeration, and a profile choice between a provider-defined profile name or a customer-defined algorithm with either PSK (preshared-key) or PKI key type.