China Telecom

fufengc@chinatelecom.cn

China Telecom

huangcanc@chinatelecom.cn

Huawei

lana.wubo@huawei.com

ONSEN Working Group RFC8299 defines a YANG data model for L3VPN service delivery. This document defines a set of extensions that address the limitations of the L3VPN Service Model (L3SM). The extensions enable (1)dynamic network provisioning with temporary connectivity, (2) dynamic bandwidth adjustment, (3) integration of isolation in Slice Service Templates to enhance QoS provisioning, (4) performance monitoring for enriching service quality visibility, (5)quantum-safe encryption integrating both PQC and QKD.

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 January 2027.

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

RFC 8299 defines the Layer 3 VPN Service Model (L3SM), which provides a customer-facing abstraction for Layer 3 VPN services. L3SM assumes relatively static service characteristics: persistent connectivity between fixed sites with bandwidth parameters specified at service creation time. Operational experience with data-intensive workloads (e.g., large- scale data transfer, temporary compute clusters) has identified requirements not addressed by the base L3SM model: Dynamic network provisioning: The ability to establish and tear down connectivity on demand, rather than maintaining persistent connections. Conventional L3VPN services must perform frequent network reconfigurations to support such dynamic networking. Frequent reconfigurations for dynamic networking may introduce potential risks to network stability and are generally unacceptable for network operations. Dynamic bandwidth adjustment: The ability to modify bandwidth allocations within specific provisioning delay. These operational requirements create corresponding gaps in the service model. Furthermore, large-scale SRv6 deployments expose additional technical limitations in the original L3SM data model: L3SM does not support temporary connectivity with explicit activation/deactivation time windows. L3SM does not provide parameters for bandwidth adjustment with spefic bandwidth adjustment ranges and adjustment time constraints. L3SM lacks integration with network slicing constructs required to deliver differentiated service tiers over SRv6 transport. L3SM lacks support for performance monitoring, limiting end-to-end service quality visibility. L3SM does not provide parameters for quantum-safe encryption. Most of the existing L3SM functional modules (eg., qos, security) are configured under site and site-network-access nodes, without unified global VPN-service settings. This results in extensive duplicated configurations across individual sites and increases overall operational complexity. This document defines YANG augmentations to RFC 8299 to address these gaps. The extensions are designed to be backward compatible: implementations that do not require these capabilities can ignore the new parameters. The scope of this document is limited to service model extensions. Implementation details of underlying mechanisms (e.g., signaling protocols, encryption algorithms, security mechanisms ) are out of scope.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 in and when, and only when, they appear in all capitals, as shown here. This document uses the following terms: AC: Attachment Circuit, as defined in . CE: Customer Edge, as defined in . COA: Change of Authorization, as defined in . Dynamic-L3VPN: A Layer 3 VPN service supporting dynamic network provisioning and/or dynamic bandwidth adjustment. L3SM: Layer 3 VPN Service Model, as defined in . L3VPN: Layer 3 Virtual Private Network, as defined in . PE: Provider Edge, as defined in . PQC:Post Quantum Cryptography. QKD:Quantum key distribution. Slice Service Template (SST): A reusable policy container defining Service Level Objectives (SLOs) and Service Level Expectations (SLEs) for network slices, as defined in [I-D.ietf-teas-ietf-network-slice-nbi-yang].

The L3VPN service model defined in provides a service-level abstraction for L3VPN services, decoupling service intent from device configuration. The extensions in this document follow the same service data model usage as the base L3VPN Service Model (L3SM). A typical scenario is also to use this model as input to an orchestration layer responsible for translating service intent into device configurations. An example of extended L3VPN service delivery is shown in Figure 1. The main difference is that these extensions introduce additional service-level attributes and policy constructs to support newer, more dynamic service delivery models. The usage of this service model is not limited to this example. The extended data model continues to be applicable for any component of management systems and northbound consumers, but not directly by network elements.

Extended L3VPN Service Delivery Example

The extensions are defined in the module ietf-l3vpn-svc-ext, which augments the base L3SM module (ietf-l3vpn-svc) at the following locations: /l3vpn-svc/vpn-profiles: Adds profiles for bandwidth adjustment ranges, provisioning delay SLOs and performance monitoring policies. All such profiles are predefined and standardized by the provider and the provider can propose these profiles to the customer. /l3vpn-svc/vpn-services/vpn-service: Adds four containers (dynamic-attribute container, qos container, perf-mon container, security container) for globle VPN service configuration that apply across all sites. /l3vpn-svc/sites/site: Traffic classification policies defined in are nested solely under the QOS container and cannot be reused by other functional modules, resulting in insufficient flexibility. Adds a site-level unified classification-policy container that defines a set of ordered rules to classify customer traffic and generates a set of class-id values, which can be reused accross various service functions modules including QoS, security, and performance monitoring. When different modules process identical traffic flows, they adopt the same class-id values to match traffic. When different modules process distinct traffic flows, they adopt different class-id values to match traffic. Add site-level functional containers (dynamic-attribute container, qos container, perf-mon container, security container). When a site carries service requirements that cannot be fully covered by the global vpn-service settings, relevant parameters may be configured within the containers under the corresponding site node. /l3vpn-svc/sites/site/site-network-accesses/site-network-access/ service: Add site-network-access-level functional containers (dynamic-attribute container, qos container, perf-mon container, security container) . When a site-network-access carries service requirements that cannot be fully covered by the site-level vpn-service settings, relevant parameters may be configured within the containers under the corresponding site-network-access node. The parameter inheritance mechanism defined in for site-level and site-network-access-level nodes also applies to this document. Furthermore, this document additionally introduce an inheritance mechanism at the global vpn-service level. Overall, this document defines a three-level hierarchy for service configuration. Some parameters can be configured at vpn-service level, the site level and the site-network-access level, e.g., services, security. Inheritance applies when parameters are defined at the vpn-service level and site level. If a parameter is configured at the global vpn-service level, the site-level parameter MUST override the global vpn-service parameter. If a parameter is configured at the site-level, and the access-level parameter MUST override the site-level parameter. Those parameters will be described later in this document. Figure 2 illustrates the module augmentation tree structure.

Augmentation Tree Structure

Requirement: Customers with workloads including, but not limited to, data computation offloaded to cloud DCs, periodic data circulation for audit or other purpose and temporary event organization demand task-based connectivity: VPN tunnels are set up only when data transmission tasks start and torn down upon task completion. This avoids the extra costs incurred by persistent long-term VPN subscriptions from operators. Customers require connection provisioning latency to be provided as an SLO attribute, which quantifies the time offset between the requested-start and actual-start timestamps. Gap in : L3SM assumes persistent connectivity; it doesn't provide parameters to specify the requested-start time and requested-stop time of AC connections or activation time constraints. Gap in : The ietf-bearer-svc data yang model defined in provides the requested-start and requested-stop nodes to specify the expected activation and deactivation date and time of a bearer; but it lacks nodes to indicate whether the connection remains always-on throughout the requested period. In certain scenarios, the connection does not operate in always-on mode over the requested time window; its activation is limited to specific time slots on designated calendar days. A list-type node for L3VPN activation times shall be provided to allow customers to specify multiple connection periods in a single configuration. Extensions: In L3SM, a site refers to a physical location and associated customer premises equipment. AC represents a logical VPN access channel provided by the operator for customers. After configured by the operator, an AC can be bound to a VPN instance to implement end-to-end VPN networking services. From operational practice,sites are typically static and seldom rebuilt or dismantled, while logic access links may be established and bounded to VPN instanceon demand. As an implementation example, dynamic networking mainly refers to the on-demand establishment, association and teardown of ACs. This document is not limited to any specific implementation approach. This YANG data model defines support for on-demand establishment, association and release of VPN connectivity , with specified provisioning delay constraints. The detailed implementation mechanisms for fast activation and deactivation of L3VPN connections are implementation-specific and out of scope of this document. Figure 3 illustrates the module augmentation subtree structure of dynamic networking.

Augmentation Dynamic Networking Subtree Structure

dynamic-attribute: The dynamic-attribute container groups all parameters associated with dynamic service provisioning. This parameter is configurable only when the dynamic networking and/or bandwidth adjustment feature is enabled. If this feature is not enabled, the service shall adopt the conventional L3SM model which assumes persistent connectivity. always-on: Boolean flag indicating whether the connection is consistent (default true) . The requested-start and requested-stop parameters are only configurable when always-on is enabled. If always-on is false, the customer need to specify the exact time slots. connection-provisioning-delay: Latency parameter specifying the time offset between requested activation and actual activation of the connection. Network operators may predefine a set of latency-related templates, from which customers may select the one matching their service requirements. The connection-provisioning-delay attribute can reference a predefined latency template. active-networking-policy:The active-networking-policy container groups parameters associated with dynamic networking service capabilities, including connection-provisioning-delay and specify exact time slots for networking service ,which is only valid when the always-on attribute is set to false. policy-mode: There are two types of requirements for specifying exact time slots: immediate activation and scheduled activation. Upon reaching the scheduled active time, the network controller should deploy relevant configurations to bring up the specified connections, and when reaching the scheduled tear-down time, the network controller should deploy corresponding configurations to tear down this connection. In addition to bring up or tearing down the target access link, the controller should simultaneously add or remove all relevant configurations associated with the VPN service that reference this access link from other access links. Immediate activation means that service configurations are deployed right after customer subscription. Under the immediate activation mode, the start time does not need to be specified, and the end time is derived from the reserved duration. Scheduled activation means supports for explicit calendar date-specific activation, allowing customers to suscribe a list of exact valid dates(YYYY-MM-DD) and corresponding intra-day time slots on which the dynamic networking service takes effect. connection-provisioning-delay monitoring: The read-write start-time and end-time are configured to express customers' expected time to enable/ disable the connection, while the corresponding read-only actual-start-time and actual-end-time reports the actual date and time when the bearer was enable/ disable. The difference between the actual timestamps and the expected timestamps represents the actual service provisioning delay. This value is used by customers to check whether the service meets the connection-provisioning-delay SLO constraints.

Requirement: Customers maintain a low-bandwidth persistent connection for regular use. When special requirements arise (such as large data transmission workloads), higher-bandwidth connections may be provisioned temporarily. Customers require bandwidth adjustment provisioning latency to be provided as an SLO attribute, which quantifies the adjustment time offset between the requested-start/stop time and actual-start/end timestamps. Gap in : L3SM specifies static bandwidth parameters (svc-input-bandwidth, svc-output-bandwidth) without support for elastic bandwidth adjustment and adjustment provisioning delay constraints. Extensions: This YANG data model defines support for adjustment of bandwidth allocations. Figure 4 illustrates the module augmentation subtree structure of dynamic bandwidth adjustment.

Augmentation Dynamic bandwidth Subtree Structure

dynamic-bandwidth-attribute: The dynamic-bandwidth-attribute container groups parameters associated with dynamic bandwidth adjustment service including bandwidth-provisioning-delay, max-adjustment-bandwidth-range and specify exact time slots for bandwidth adjustment service. When alway-on is true, the svc-input-bandwidth node and the svc-output-bandwidth node under /site-network-access/service indicates the base bandwidth value applicable to the access link. dynamic-bandwidth-enabled: Boolean flag indicating whether bandwidth adjustment is enabledd (default false). maximum-bandwidth-adjustment-profile: Maximum range allowed for a bandwidth modification. This parameter is a factor that operators take into account when selecting appropriate bearer solution for access links. As an illustration, operators may deploy GE links between CE and PE when the maximum bandwidth is less than 1 Gbps. If the required bandwidth exceeds 10 Gbps, 50G-PON or 100G interfaces can be adopted as the access medium instead. The exact approach to be adopted is implementation-specific and determined by the actual deployment. bandwidth-adjustment-provisioning-delay: Maximum allowed delay to complete a bandwidth modification. Network operators may predefine a set of latency-related templates, from which customers may select the one matching their service requirements. bandwidth-flex-policy:There are two types of requirements to specify exact time slots: immediate activation and scheduled activation. Immediate activation means that service configurations are deployed right after customer subscription. scheduled activation means supports for explicit calendar date-specific activation, allowing customers to suscribe a list of exact valid dates(YYYY-MM-DD) and corresponding intra-day time slots on which the dynamic bandwidth service takes effect. Upon reaching the scheduled adjustment time, the network controller should deploy relevant configurations to adjust the bandwidth to a new value, and when the scheduled bandwidth restoration time arrives, the controller shall revert the bandwidth of the access link to its baseline value. Operators may adopt different bandwidth adjustment implementation mechanisms according to distinct SLO requirements for adjustment latency. bandwidth-adjustment-provisioning-delay monitoring: The read-write start-time and stop-time are configured to express customers' expected time to adjust the bandwidth of the connection, while the corresponding read-only actual-start-time and actual-end-time reports the actual date and time when the bandwidth adjustment was completed. The offset between the actual timestamps and the expected timestamps represents the actual service provisioning delay. This value is used by customers to check whether the service meets the bandwidth-adjustment-provisioning-delay SLO constraints.

Requirement: With the widespread deployment of SRv6 network slicing, L3VPN services require slicing-specific SLO/SLE parameters including isolation. L3SM shall support binding L3VPN instances to dedicated slicing SLO/SLE guarantees. Customers expect QoS flow classification policies to be reusable across other functional modules in the same L3VPN service, such as security and performance monitoring, to reduce the complexity of flow classification definitions. The provisioning of QoS functionality consists of traffic classification policies and QoS policies. As noted above, reusable flow classification policies are required. For QoS policies, customers require a globally applicable QoS policy to eliminate the high complexity of separate configurations per site and per link. Sites or links with special requirements may be assigned customized settings individually. Gap in : L3SM provides basic QoS profiles but lacks integration with network slicing constructs and parameterized SLO/SLE specifications. Traffic classification policies reside under the QoS container, making them inconvenient to be reused by other functional modules. defines QoS policies at the site and site-network-access levels, without support for the vpn-service level. This results in extensive duplicated configurations across individual sites and increases operational complexity. Extensions: This YANG data model defines support for enhanced qos. Figure 5 illustrates the module augmentation subtree structure of enhanced qos.

Augmentation Qos Subtree Structure

isolation: Specify the requirement that the L3VPN Service is not impacted by the existence of other customers or services in the same network. The definition of isolation aligns with [I-D.ietf-teas-ietf-network-slice-nbi-yang], enabling consistent policy application across VPN and slice services. As mentioned above, the provisioning of QoS functionality consists of traffic classification policies and QoS policies. QoS profiles serve as containers for QoS policies. QoS profiles can be supplied as standardized templates by the operators, or customized independently by customers. QoS policies are appropriate for global definition under the vpn-service node and applicable accross all sites and access links. Traffic classification policies ought to be tied to specific sites and access links, and therefore should be defined at the site level and access link level to enable reuse across different functional modules. Traffic-classification subtree structure is shown in Figure 6.

Traffic-classification Subtree Structure

The global qos policy subtree structure is shown in Figure 7.

Global qos policy Subtree Structure

Requirement: Provide end-to-end service quality visibility. Gap in :The base L3SM lacks native monitoring configuration options and service-level performance metrics. Extensions: Figure 8 illustrates the module augmentation subtree structure of perf-mon.

Augmentation Performance Monitoring Subtree Structure

monitoring-enabled: Boolean flag to enable performance monitoring for the L3VPN service (default false). measurement-interval: Specifies the performance measurement interval, in seconds. pm-attributes (read-only): A set of operational state and service-level performance metrics, including delay, packet loss and jitter, to enrich operational state data and enhance end-to-end quality visibility.

Requirement: Support quantum-safe encryption for high-security data transmission scenarios, defending data against potential cracking threats brought by future cryptographically relevant quantum computers and providing long-term transmission confidentiality. Support ce-ce encryption to safeguard security throughout the full data transmission process. Support fine-grained traffic encryption to encrypt designated flows instead of full-traffic encryption. Driven by service charges and forwarding performance constraints, customers demand flow-granular encryption. Gap in : L3SM defines basic encryption enablement, including specifying the encryption algorithm applied to ESP payloads and specifying PSK applied for peer authentication during the IKE negotiation phase. But L3SM lacks parameters for quantum key distribution (QKD) and post-quantum cryptography (PQC) integration. The current specification only supports encryption across the CE-to-PE segment. For scenarios where CEs are managed by the operator, customers require encryption service across the whole CE-to-CE path. The encryption mechanism defined in only applies to full traffic on access links and operates at a relatively coarse granularity. Editor's Note: The ce-ce/PE-PE quantum-safe encryption service type for quantum-safe security is TBD. Extensions: Figure 9 illustrates the module augmentation subtree structure of enhanced security.

Augmentation security Subtree Structure

fine-grained traffic matching: Class-id distinguishes different traffic classification rules for customers. slist contains traffic classification entries for customers, which .The customer-profile container is defined as a list with class-id serving as its list key. Each entry defines the mapping between a class-id and its associated encryption policy. post-quantum-encryption-config: The post-quantum-encryption-config container aggregates all configuration items associated with post-quantum-encryption and it is gated by the post-quantum-encryption feature. The post-quantum-encryption-config container unifies configuration for the two primary categories of quantum-resistant security services: Post-Quantum Cryptography (PQC) and Quantum Key Distribution (QKD). If a customer requires both QKD and PQC services simultaneously, operators need to integrate the two quantum-resistant mechanisms. A typical implementation leverages PQC during IKE negotiation, and combines key material derived from PQC with QKD keys to produce the final session symmetric key. This document merely provides an illustrative example and imposes no restrictions on operator-specific implementations. The detailed deployment approach is left to operator. post-quantum-encryption-enable: Boolean flag for post-quantum-encryption activation, including activation of PQC, QKD, or both. The specific activation policy is left to the operators. For instance, some operators may deploy only PQC, while others adopt QKD or a combination of both. quantum-failover-mode:Failover behavior when quantum ike-key generation fails (fallback to conventional crypto or terminate). quantum-encryption-status: a read-only parameter, reports the current operational state of post-quantum encryption. PQC-config: The PQC-config container aggregates all configuration items associated with PQC-based encryption. At present, only a boolean enable leaf is specified to turn PQC encryption on or off. The PQC-config container can easily be augmented with other configuration parameters in future. qkd-config: The qkd-config container aggregates all configuration items associated with QKD-based encryption, and can easily be augmented with other configuration parameters. qkd-enable: Boolean flag for QKD-based encryption activation. key-refresh-interval: this leaf specifies the time interval, measured in seconds, at which the quantum key pool shall automatically refresh its stored quantum keys. qkd-key-pool-id: this leaf specify the identifier of a QKD key pool managed by the QKD key management entity (KME). A QKD key pool stores pre-generated symmetric quantum keys shared between paired QKD endpoints. Identical qkd-key-pool-id values shall be configured on both endpoints of any QKD link. For QKD-based encryption deployed over either the CE-to-PE or CE-to-CE segment, the paired endpoints (CE and PE, or CE and CE) shall share the same qkd-key-pool-id.

Editor's note: This modules augments the L3SM. The l3vpn-svc-ext is TBD.

Editor's note:The Service Model Usage Example is TBD.

This document requests IANA to register the following URI in the "IETF XML Registry": URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc-ext Registrant Contact: The IESG XML: N/A; the requested URI is an XML namespace. This document requests IANA to register the following YANG module in the "YANG Module Names" registry: Name: ietf-l3vpn-svc-ext Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc-ext Prefix: l3vpn-svc-ext Reference: RFC XXXX

The extensions defined in this document inherit the security considerations of RFC 8299. Additional considerations: Dynamic provisioning mechanisms (e.g., RADIUS COA) MUST be secured using mutual authentication and integrity protection. Quantum encryption parameters are sensitive; access to these configuration nodes SHOULD be restricted to authorized administrators. Communication between customers and service orchestrators SHOULD use TLS 1.3 or equivalent encryption. Dynamic networking capabilities require appropriate security mechanisms to prevent customers from establishing L3VPNs with untrusted peers. The specific implementation details of the mutual trust mechanisms are out of scope.

Harvard University IBM

The VPN instances on the PE devices may be pre-configured as defined in , with the VPN instance bound to an AC only when establishing end-to-end VPN connectivity. Alternatively, the VPN instance may also be dynamically configured via configuration commands based on customer requirements. The dynamic-L3VPN service provisioning and lifecycle procedure is as follows, and we take customer A ordering dynamic-L3VPN service as an example.

Dynamic-L3VPN Service Orchestration Procedure | | | | | | | | | | 2. Submit VPN Service Info | | | | (Peer, BW, Start, End) | | | +------------->| | | | | | | | | | | 3. Configure CE | | | +------------->| | | | | | | | | | | 4. Connect to PE | | | +---------->| | | | | | | | | | 5. Bind AC to VPN | | | |<-------------+ | | | | | | 6. Submit Dynamic BW Request| | | +------------->| | | | | | | | | | | 7. Update Bandwidth (PE) | | | +------------------------->| | | | | | | | 8. Request Add User to VPN | | | +------------->| | | | | | | | | | | 9. Config New CE & PE | | | +------------------------->| | | | | | | | 10. Request Remove User | | | +------------->| | | | | | | | | | | 11. Config: Remove AC | | | +------------->| | | | | | | | | | 12. Config:Remove AC from PE | | +------------------------->| | | | | | | ]]>

The procedure consists of 12 key steps covering the full lifecycle of dynamic-L3VPN: registration, initial service provisioning, dynamic bandwidth adjustment, peer addition/removal, and resource cleanup. The Network Controller coordinates configuration across CEs and PEs to ensure end-to-end service delivery, while the Ordering System acts as the interface between customers and the network infrastructure. SRv6 (defined in and ) may be used for path optimization in dynamic-L3VPN. Customer A registers in the service ordering system. Customer A enters VPN service parameters into the ordering system, including peer VPN customers, bandwidth requirement, start time, and end time, etc. The Network controller provisions configuration to the CE devices of the involved customers. Each CE device establishes a connection to its attached PE device. The Network controller sends configuration or signaling to the PE devices to bind the customer's AC to the VPN instance. Customer A submits an elastic bandwidth adjustment request via the ordering system. The Network controller delivers configuration or signaling to the PE devices to modify the bandwidth of the VPN service. Customer A submits a request via the ordering system to add one or more new customers to the VPN. The Network controller provisions the new customers' CE device and sends configuration or signaling to the corresponding PE devices. Customer A submits a request via the ordering system to remove one or more existing customers from the VPN. The Network controller updates the configuration of the removed customers' CE devices. The Network controller sends configuration or signaling to the corresponding PE devices to delete the associated AC from the VPN.

The authors wish to thank Mingjiang Fu, Zhenlin Tan, Wenkuan Qu of China Telecom for their contributions to the dynamic L3VPN operational requirements.

The following authors contributed significantly to this document.