YANG Data Model for L3VPN Service Delivery
obsoletes
- rfc-8049 — YANG Data Model for L3VPN Service Delivery
Extracted elements (26)
RFC 8299 obsoletes RFC 8049 with a module of the same name (`ietf-l3vpn-svc`) that is not backward compatible. Retaining the module name is justified under RFC 7950 Section 11 because RFC 8049's module was unimplementable due to broken XPATH expressions in `must` statements, making an interoperability conflict between the two versions impossible in practice.
The L3VPN service model is intentionally an abstraction layer to be instantiated at an orchestration or management system, not directly on network elements. The management system is responsible for translating this model into device-specific configuration (via CLI, NETCONF/RESTCONF, or other means). This separation keeps the service model vendor-neutral and operator-agnostic.
The module defined in RFC 8299 is not backward compatible with RFC 8049. RFC 8049 could not be implemented because several `must` expressions used broken XPATH (rejected by tools that fully parse XPATH), and ACL rule ordering in RFC 8049 contradicted the English-language prose. RFC 8299 fixes these by rewriting `must` as `when` statements, switching to relative paths, and adopting `ordered-by user` for ACL rules.
By default, all sites in an IP VPN MUST be authorized to access a configured cloud resource. If restrictions are required, the operator MAY configure the `permit-site` or `deny-site` leaf-lists to limit or deny specific sites from accessing a cloud target.
If IP source address translation (NAT44) is required for cloud access, the `enabled` leaf MUST be set to `true` inside the `nat44` container. If the SP provides the translated address, the `customer-address` leaf is not required.
In the any-to-any VPN service topology, all sites MUST have the `any-to-any-role`. In Hub-and-Spoke or Hub-and-Spoke disjoint topologies, sites MUST be assigned either a Hub role or a Spoke role.
The management system MUST take into account constraints on Hub-and-Spoke connections. For example, if a Hub site and a Spoke site are meshed on the same PE, they must be placed in different VRFs to enforce the Hub-and-Spoke policy.
When 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 that can be specified at either level.
A `site` represents a customer office's logical connection to one or more VPNs. Each site contains a unique `site-id`, `locations`, `devices` (optional CE equipment requests), `management` type (customer-managed, co-managed, provider-managed), `vpn-policies`, `security`, `service`, `routing-protocols`, and one or more `site-network-access` entries defining individual IP logical connections.
Carriers' Carriers (CsC) functionality is modeled as a feature-gated boolean `carrierscarrier` leaf under the VPN service, and a `carrierscarrier` container under the site service specifying the `signalling-type` (BGP or LDP). This enables a carrier customer to use the provider's MPLS network as a transit backbone.
Cloud access is configured via the `cloud-accesses` container under a VPN service. Each `cloud-access` entry references a provider-defined cloud identifier, supports NAT44 address translation, and uses `permit-any`, `deny-any-except` (with `permit-site` list), or `permit-any-except` (with `deny-site` list) authorization flavors.
Extranet VPN connectivity is modeled via the `extranet-vpns` container under a customer VPN. Configuring VPN A to list VPN B as an extranet grants VPN A's sites access to VPN B's resources; as a side-effect, all VPN B sites also gain access to all VPN A sites. No configuration is required on VPN B itself. More selective cross-VPN access requires a VPN policy.
IP address allocation for site-network-access connections supports five methods: `provider-dhcp`, `provider-dhcp-relay`, `static-address` (both IPv4 and IPv6), `slaac` (IPv6 only), and `provider-dhcp-slaac` (IPv6 only). The `slaac` and `provider-dhcp-slaac` options are enforced by YANG `when` statements to apply only to IPv6 contexts.
Multicast service is configured globally per VPN via the `multicast` container, which specifies customer tree flavors (bidirectional, shared, source-based), RP-to-group mappings (provider-managed or customer-managed), RP redundancy, optimal delivery, and RP discovery mechanisms (`auto-rp`, `static-rp`, `bsr-rp`; default is `static-rp` for ASM). A single RP discovery mechanism is permitted per VPN.
Network-to-Network Interfaces (NNIs) are modeled using `site-vpn-flavor-nni`. Three NNI interconnect options are supported: Option A (VRF-to-VRF, modeled as a site with direct routing between ASBRs), Option B (per-VPN ASBR redistribution of labeled routes), and Option C (multihop eBGP with labeled unicast). Each option has distinct configuration requirements in the YANG tree.
QoS is configured at both site and site-network-access levels via a `qos` container. It includes a `qos-classification-policy` with rules matched by flow (DSCP, dot1p, IPv4/IPv6 prefixes, L4 ports, protocol field) or application (identityref), and a `qos-profile` that references either a provider-defined standard profile or a custom set of classes with rate-limit, latency, jitter, and bandwidth guarantees.
Routing protocol support per site and site-network-access includes: `ospf` (with address family, area-address, metric, and optional OSPF sham-links), `bgp` (with autonomous-system and address-family), `static` (with cascaded IPv4/IPv6 LAN prefix and next-hop lists), `rip`, and `vrrp`. Multiple routing protocols may be active simultaneously.
Site availability is modeled via the `access-priority` leaf (uint32) under the `availability` container of each `site-network-access`. Higher values indicate higher priority. This parameter informs the management system how to rank accesses during multihoming and traffic protection scenarios.
Site diversity is modeled via the `access-diversity` container within each `site-network-access`. Diversity groups are assigned to accesses, and constraints of types such as `siteLevel`, `peLevel`, `popLevel`, or `lineLevel` are applied between access groups, supporting single-CE, dual-CE, and multi-POP multihoming scenarios.
The model defines four site VPN flavors: `site-vpn-flavor-single` (one VPN), `site-vpn-flavor-multi` (multiple VPNs with all accesses in the same VPN set), `site-vpn-flavor-sub` (multiple VPNs with each access mapped to a different VPN subset), and `site-vpn-flavor-nni` (represents an Option A NNI). These flavors govern how VPN multiplexing is performed for a site.
The model defines three VPN service topology types: `any-to-any` (all sites communicate freely, single RT sufficient), `hub-and-spoke` (Spokes reach only Hubs; Hubs can reach each other, requiring two RTs), and `hub-and-spoke-disjoint` (Spokes reach only Hubs; Hubs cannot reach each other, also requiring two RTs). The default topology is any-to-any. New topologies may be added via YANG augmentation.
The service-level parameters per site-network-access include `svc-input-bandwidth` (uint64, ingress committed bandwidth in bps), `svc-output-bandwidth` (uint64, egress committed bandwidth in bps), and `svc-mtu` (uint16, Layer 3 MTU in bytes). These are mandatory fields within the `service` container.
The YANG module `ietf-l3vpn-svc` is structured around two top-level containers: `vpn-services` (holding global VPN parameters per customer) and `sites` (holding customer site definitions including network accesses, routing, security, and service parameters). A supplementary `vpn-profiles` container holds valid provider-supplied identifiers such as cloud, encryption, QoS, and BFD profile references.
IANA has registered the YANG module `ietf-l3vpn-svc` in the 'IANA Module Names' registry with namespace `urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc` and prefix `l3vpn-svc`. This registration replaces the entry made for RFC 8049 under the same module name.
The model includes an encryption container at both site and site-network-access levels, supporting layer selection (Layer 2 or Layer 3) and either a provider-supplied encryption profile or a customer-defined algorithm with a pre-shared key (`preshared-key` string). The preshared key is stored in plaintext within the YANG model; implementations should apply appropriate data-at-rest protections and access controls to this sensitive leaf.
The YANG module `ietf-l3vpn-svc` defines configuration data nodes that are readable and writable; unauthorized access could allow an attacker to read sensitive VPN topology and addressing information, or to modify VPN configurations, potentially disrupting service or enabling traffic interception. Implementations MUST use secure management protocols (e.g., NETCONF over SSH) and enforce appropriate access control (e.g., NACM per RFC 8341).