China Telecom

fufengc@chinatelecom.cn

China Telecom

huangcanc@chinatelecom.cn

Huawei

lana.wubo@huawei.com

ONSEN Working Group defines a YANG data model for L3VPN service delivery. The base L3VPN Service Model (L3SM) has limitations regarding dynamic service features. In addition, emerging technologies including SRv6 and quantum security bring new service capabilities available to customers, which are not natively supported by L3SM. This document defines a set of extensions to address the limitations of L3SM. These augmentations are designed to be backward-compatible and do not obsolete .

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 4 May 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.

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. There are two main drivers for dynamic L3VPN service. First, with the rise of compute services, operational experience with transmission service for data-intensive workloads has identified requirements not addressed by the base L3SM model. A typical use case is large-scale data transfers from customer premises to remote AI compute clusters for training and computing, which may involve Tbit-scale bulk data movement. Such workloads require task-oriented high bandwidth: a large bandwidth allocation is provisioned temporarily during data transfer tasks, and the connection is either torn down or reverted to a baseline low-bandwidth once the task completes. Second, SD-WAN solutions natively support dynamic bandwidth and on-demand service adjustments. Customers now expect similar flexible capabilities for their managed traditional VPN services, resulting in operator requirements for dynamic service features within traditional VPN offerings. Customers require two typical types of dynamic L3VPN services (specified in ), including: Dynamic networking provisioning: The ability to establish and tear down connectivity on demand, rather than maintaining persistent connections. Dynamic bandwidth adjustment: The ability to modify bandwidth allocations on demand. These operational requirements create corresponding gaps in the service model. Furthermore, emerging technologies including SRv6 and quantum security bring new service capabilities available to customers, creating gaps in the original L3SM model. Large-scale SRv6 deployments enable operators to offer new value-added services such as network slicing service and on-path telemetry service atop traditional L3VPN. Quantum-security deployments introduce a new value-added quantum-security service. Network slicing is defined in and on-path telemetry is defined in . In summary, the gaps mainly include: L3SM does not support dynamic networking service. L3SM does not support dynamic bandwidth adjustment service. L3SM lacks integration with network slicing constructs to deliver differentiated service tiers. L3SM lacks support for flow-oriented on-path telemetry value-added services for L3VPN performance monitoring, limiting end-to-end service quality visibility. L3SM does not support quantum-safe encryption service. This document defines YANG augmentations to to address these gaps. The extensions are designed to be backward compatible: implementations that do not require these capabilities can ignore the newly added parameters. The scope of this document is limited to implementation-agnostic service model extensions. This document focuses on the service characteristics exposed to the customers. Implementation details of underlying mechanisms (e.g., signaling protocols, encryption algorithms, security mechanisms, on-path telemetry implementation-specific techniques) are out of scope. SRv6 serves as one of the drivers for some services, but the underlying transport technology is not restricted to SRv6; MPLS is also applicable. In addition, SRv6 EVPN-related VPN instantiation mechanisms are treated as underlying implementation details and are out of scope for this service model. Such mechanisms may be specified in network service models such as the L3NM or device-level YANG models.

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 acronyms which are defined in other RFC documents: AC: Attachment Circuit, as defined in . CE: Customer Edge, as defined in . COA: Change of Authorization, as defined in . ESP: Encapsulating Security Payload, as defined in . IKE: Internet Key Exchange, as defined in . L3SM: Layer 3 VPN Service Model, as defined in . L3VPN: Layer 3 Virtual Private Network, as defined in . PE: Provider Edge, as defined in . PSK: Pre-Shared Key, as defined in . PQC: Post-Quantum Cryptography. Cryptographic algorithms designed to resist adversarial attacks from cryptographically-relevant quantum computers as defined in . QKD: Quantum key distribution. A procedure to generate and distribute symmetric cryptographic keys with information-theoretic security leveraging quantum-physical principles, as defined in . The document defines the following term: Dynamic L3VPN: A Layer 3 VPN service that can support short-lived high-bandwidth capabilities. There are two primary service types. The core difference between these two services is whether to establish and tear down a VPN tunnel during the service lifecycle. The first is dynamic networking provisioning. It means on-demand establishment and release of end-to-end VPN tunnels. It involves VPN connection establishment and teardown processes during the implementation of this kind of service. Once the connection is established, high bandwidth is allocated simultaneously. The second is dynamic bandwidth adjustment. It means customers have ordered a long-live VPN with a baseline bandwidth and require temporary bandwidth scaling. It does not involve VPN connection establishment and teardown processes, and only requires on-demand modification of the bandwidth rate during the implementation of this kind of service. To simplify service provisioning for network providers, these two capabilities are mutually exclusive for a given VPN service; only one may be active at any given time. Scenarios in which a customer orders both dynamic networking service and dynamic bandwidth adjustment service at the same time are out of scope.

The idea of the L3VPN service model defined in is to propose an abstracted interface between customers and network operators to manage configuration of components of an L3VPN service. The extensions in this document follow the same service data model usage as the base L3SM. An example of extended L3VPN service delivery is shown in Figure 1. A typical scenario is that customers order an L3VPN service and delivers the service requests to the orchestrator. The orchestrator is responsible for translating the service models into network models. This layered modeling process aligns with the framework specified in . The usage of the 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 three profiles, including bandwidth adjustment ranges, provisioning delay SLOs and performance monitoring policies. These profiles are predefined and standardized by the provider and the provider can propose these profiles to the customers. /l3vpn-svc/sites/site: Adds a site-level unified traffic classification-policy container that defines a set of ordered rules to classify customer traffic and generates a set of "class-id" values. The "class-id" can be reused across various service functions modules including "qos", "security". Different modules shall use identical "class-id" values for traffic matching when handling the same traffic flows, and different "class-id" values when handling distinct traffic flows. Adds a new container ("oam"), and augments the existing containers ("qos", "security") . /l3vpn-svc/sites/site/site-network-accesses/site-network-access: Adds a new container ("dynamic-l3vpn"), a site-network-access-level unified traffic classification-policy container and augments the existing containers ("qos", "security"). The parameter inheritance mechanism defined in for site-level and site-network-access-level nodes also applies to this document. The detailed parameters will be described later in this document. Figure 2 illustrates the overall module augmentation tree structure.

Overall Augmentation Tree Structure

Figure 3 illustrates the module augmentation subtree structure of dynamic L3VPN.

Augmentation Dynamic L3VPN Subtree Structure | /l3vpn-svc:l3vpn-svc/vpn-profiles | /valid-provider-identifiers | /l3vpn-svc-ext:bandwidth-adjustment-profile-identifier | /id +--rw (dynamic-type)? +--:(dynamic-networking) | ... +--:(dynamic-bandwidth-adjustment) | ... ]]>

A dynamic-L3VPN service has the following common data nodes, applicable to both dynamic service types: "dynamic-l3vpn": Provides the container to group all parameters associated with dynamic service provisioning. This parameter is configurable only when the "dynamic-l3vpn" feature is enabled. "max-adjustment-bandwidth-range": Indicates the maximum allowed adjustment bandwidth value for this dynamic L3VPN. This parameter is a factor that operators need to consider when selecting appropriate bearer solution for physical access links. As an illustration, operators may deploy GE links between CE and PE when the maximum bandwidth is less than 1Gbps. If the required bandwidth exceeds 10Gbps, 50G or 100G links can be adopted as the access medium instead. The exact bearer solution is implementation-specific and determined by the actual deployment. "dynamic-type": Indicates the type of dynamic L3VPN service and is a YANG choice node. The dynamic-networking type and dynamic-bandwidth-adjustment type are defined so far.

Customers require task-based and short-lived connections. VPN tunnels are set up only when transmission tasks start and torn down upon the transmission task completion. Typical scenarios include but are not limited to data computation offloading from local sites to remote cloud DCs, and data circulation services among different organizations or enterprises. Task-based connections are driven by two main factors: security and cost. For security considerations, some customers prefer to remain unreachable when the data transmission task is finished. From the cost perspective, task-based connections improve the cost efficiency for customers, since they do not need to occupy network resources continuously. Given the short-lived nature of higher-bandwidth allocations, these connections make customers more sensitive to provisioning latency relative to conventional L3VPN services. 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. Note that provisioning latency here excludes physical device deployment time; it refers only to the time required to logically establish or tear down the VPN tunnels via configurations.

Gaps 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. Gaps 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 support for diverse dynamic networking provisioning capabilities, such as specifying recurring schedules within a single configuration. Operators may offer discounted bandwidth during off-peak hours. Consequently, customers may want to use this temporary high-bandwidth networking service only during these daily off-peak periods. This means that the customer subscription may be recurring.

This YANG data model defines the data structure for on-demand establishment 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 4 illustrates the module augmentation subtree structure of dynamic networking.

Augmentation Dynamic Networking Subtree Structure | /l3vpn-svc:l3vpn-svc/vpn-profiles | /valid-provider-identifiers | /l3vpn-svc-ext:provisioning-delay-profile-identifier | /id | +--rw networking-schedule | +--rw schedule* [schedule-id] | +--rw schedule-id string | +--rw (schedule-type)? | | +--:(period) | | | +--rw period | | | +--rw period-description? string | | | +--rw period-start? | | | yang:date-and-time | | | +--rw time-zone-identifier? | | | sys:timezone-name | | | +--rw (period-type)? | | | +--:(explicit) | | | | +--rw period-end? | | | | yang:date-and-time | | | +--:(duration) | | | +--rw duration? duration | | +--:(daily-recurrence) | | +--rw daily-recurrence | | +--rw recurrence-first | | | +--rw start-time? | | | yang:date-and-time | | | +--rw duration? duration | | +--rw time-zone-identifier? | | sys:timezone-name | | +--rw (recurrence-end)? | | | +--:(until) | | | | +--rw until? | | | | yang:date-and-time | | | +--:(count) | | | +--rw count? uint32 | | +--rw frequency? identityref | | +--rw interval? uint32 | +--ro actual-start-time? yang:date-and-time | +--ro actual-stop-time? yang:date-and-time +--:(dynamic-bandwidth-adjustment) ]]>

A dynamic networking provisioning service has the following main data nodes: "connection-provisioning-latency": Specifies the SLO for the time offset between requested-start and actual-start timestamps of the VPN connection. This SLO applies only to connection activation. The latency for connection teardown (between requested-stop and actual-stop timestamps) is out of scope for this attribute. Network operators may predefine a set of latency-related templates, and customers can select a template that matches their service requirements. The connection-provisioning-latency attribute MAY reference such a predefined latency template. "schedule": Specifies exact time slots for dynamic networking service. The schedule constructs used in this document is aligned with . Two types of schedules are supported: period-based schedules, and recurrence-with-time-zone schedules. "period": Is used for a period-based schedule and is imported from "period-of-time" of . Two types of period-based schedules are supported. Immediate order: If "period-start" is omitted, the service becomes active immediately upon configuration commit. A non-negative time duration ("duration") specifies the provisioned duration of the VPN service and defines how long the service remains active after activation. Future reservation: "period-start" and "period-end" are set to a future timestamp, and the start of the period be no later than the end of the period. This indicates a service order scheduled for a future time. Multiple "period-of-time" entries MAY exist within a single schedule with the "schedule-id" as the key. "recurrence": Is used for a recurrence-based schedule and is imported from "recurrence-with-time-zone" of . It supports daily recurrence, which is also one of the most typical subscription models. "actual-start-time" and "actual-end-time": Report the actual date and time when the bearer was enabled/ disabled. They are read-only parameters. The time offset between the actual timestamps and the expected timestamps represents the actual service provisioning delay. This value is used by customers to validate whether the service meets the connection-provisioning-latency SLO constraints. Note that "requested-site-start/stop" under "sites" node and scheduled requested start/stop time under "dynamic-l3vpn" node are different, and they are often used together to form a complete service subscription. As an illustration, the site subscription charge is determined by factors such as "requested-site-start" and "requested-site-stop", while the dynamic networking charge depends on the duration of the dynamic service subscription. In other words, the customer typically incurs two separate charges. The dynamic-networking capability described in this document applies to end-to-end VPN tunnel lifecycles and does not imply dynamic creation or deletion of physical site and physical devices. In conventional L3VPN, a site refers to a physical location and associated customer premises equipment. The "requested-site-start" and "requested-site-stop" under "sites" node still represent the requested start/stop time of the physical site. When customers use dynamic networking service, sites are typically still static and seldom rebuilt or dismantled from operational practice, while the logical end-to-end tunnels among sites may be established or torn down on demand. Dynamic networking scheduled activation SHALL NOT extend beyond the active time window of the associated site; dynamic networking may only be initiated when the associated site is active.

Some customers require a persistent connection for regular service use with a baseline bandwidth. When special requirements arise, for example large-data-transmission workloads, higher-bandwidth SHALL be provisioned temporarily on top of the existing persistent VPN. After the completion of the workload, the temporary higher-bandwidth setting is revoked, and the service reverts back to its baseline bandwidth while keeping the persistent VPN connection intact. Given their short-lived nature of higher-bandwidth, customers may be concerned about bandwidth adjustment provisioning latency and may require such latency to be exposed as an SLO attribute. This attribute quantifies the time offset between requested-start and actual-start timestamps for bandwidth increase operation.

Gaps in : The base L3SM specifies static bandwidth parameters ("svc-input-bandwidth", "svc-output-bandwidth") without support for elastic bandwidth adjustment for temporary higher-bandwidth and bandwidth adjustment provisioning latency constraints.

This YANG data model defines the data structures to support dynamic bandwidth adjustments. Figure 5 illustrates the module augmentation subtree structure.

Augmentation Dynamic Bandwidth Adjustment Subtree Structure /l3vpn-svc:l3vpn-svc/vpn-profiles /valid-provider-identifiers /l3vpn-svc-ext:provisioning-delay-profile-identifier /id +--rw temporary-input-bandwidth? uint64 +--rw temporary-output-bandwidth? uint64 +--rw bandwidth-adjustment-schedule +--rw schedule* [schedule-id] +--rw schedule-id string +--rw (schedule-type)? | +--:(period) | | +--rw period | | +--rw period-description? string | | +--rw period-start? | | yang:date-and-time | | +--rw time-zone-identifier? | | sys:timezone-name | | +--rw (period-type)? | | +--:(explicit) | | | +--rw period-end? | | | yang:date-and-time | | +--:(duration) | | +--rw duration? duration | +--:(daily-recurrence) | +--rw daily-recurrence | +--rw recurrence-first | | +--rw start-time? | | yang:date-and-time | | +--rw duration? duration | +--rw time-zone-identifier? | sys:timezone-name | +--rw (recurrence-end)? | | +--:(until) | | | +--rw until? | | | yang:date-and-time | | +--:(count) | | +--rw count? uint32 | +--rw frequency? identityref | +--rw interval? uint32 +--ro actual-start-time? yang:date-and-time +--ro actual-stop-time? yang:date-and-time ]]>

A dynamic bandwidth adjustment service has the following main data nodes: bandwidth-adjustment-provisioning-latency: Specifies the SLO for the time offset between expected-start (specified in the "schedule") and actual-start timestamps of the bandwidth after adjustment. This attribute MAY reference a predefined latency template. "temporary-svc-input-bandwidth" and "temporary-svc-output-bandwidth": Indicate the desired temporary input and output bandwidth after bandwidth adjustment. These two parameters are absolute values, not delta offsets from the baseline bandwidth. The existing "svc-input-bandwidth" and "svc-output-bandwidth" in represent the baseline bandwidth. When combined with the baseline service bandwidth, the temporary bandwidth parameters allow customers to perform flexible on-demand bandwidth adjustments for the VPN service. "actual-start-time" and "actual-stop-time": Reports the actual timestamps when the bandwidth adjustment takes effect. These are read-only status values. The time offset between the actual timestamps and the expected timestamps represents the actual bandwidth adjustment provisioning latency. This value is used by customers to validate whether the service meets the bandwidth-adjustment-provisioning-latency SLO constraints. "schedule": Specifies exact time slots for dynamic bandwidth adjustment service. The data structure follows the same pattern as the "schedule" described in ; details are not repeated here.

With the widespread deployment of network slicing service, L3SM shall support network slicing-specific SLO/SLE parameters including isolation. Customers expect QoS flow classification policies to be reusable across other functional modules in the same L3VPN service, such as "security", to reduce the complexity of flow classification definitions.

L3SM defined in 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 for reuse by other functional modules.

This YANG data model defines extensions for "qos". Figure 6 illustrates the module augmentation subtree structure.

Augmentation QoS Subtree Structure

This document augments the following data node: "isolation": Specifies 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. Traffic-classification subtree structure is shown in Figure 7. The "classification-policy" defined in this document reuses the definition of "classification-policy" from . The difference is its placement: it is located under "site" and "site-network-access", rather than the original location defined in .

Traffic-classification Subtree Structure

Customers require 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. Customers require encryption service to safeguard security throughout the full data transmission process. Driven by encryption service charges or forwarding performance constraints of the CE or PE equipment, customers or network operators require fine-grained traffic encryption for designated flows instead of full traffic on the access circuits.

L3SM in 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 support for quantum key distribution (QKD) and post-quantum cryptography (PQC) integration. The encryption mechanism defined in only applies to full traffic on access circuits and operates at a relatively coarse granularity.

Figure 8 illustrates the module augmentation subtree structure of enhanced security.

Augmentation Security Subtree Structure | /l3vpn-svc:l3vpn-svc/vpn-profiles | /valid-provider-identifiers | /encryption-profile-identifier/id +--:(customer-profile) +--rw classes +--rw class* [class-id] +--rw class-id string +--rw algorithm? string +--rw (key-type)? | +--:(psk) | +--rw pre-shared-key? string +--rw post-quantum-encryption {post-quantum-encryption}? +--rw post-quantum-policy | +--rw pqc-only-acceptable? boolean | +--rw qkd-only-acceptable? boolean | +--rw failure-action? identityref +--rw pqc {pqc}? | +--rw enable? boolean | +--rw algorithm? string | +--ro pqc-status? identityref +--rw qkd {qkd}? +--rw enable? boolean +--rw qkd-key-pool-id? string +--rw key-refresh-interval? uint32 +--ro qkd-status? identityref ]]>

The extended security service has the following main data nodes: "class-id": Distinguishes different traffic classification rules for customers. 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": Aggregates all configuration items associated with post-quantum-encryption and is gated by the "post-quantum-encryption" feature. It includes two primary categories of quantum-resistant security services: PQC and QKD. "post-quantum-policy": Specifies the availability and failover policy for post-quantum encryption. This policy controls the behavior of the encryption service when PQC, QKD, or both experience failures. Depending on the configured policy, the service may continue using post-quantum-based encryption when only one of PQC or QKD remains operational, or it may fall back to conventional cryptography or terminate upon such partial or total failure. Detailed policy combination examples for the following nodes are provided in . "pqc-only-acceptable": Indicates whether the customer wants to maintain post-quantum communication when QKD-derived keys are not used. This applies to scenarios where only PQC is available, QKD is unavailable, or QKD has not been ordered by the customer. If true, continue to use post-quantum encryption. If false, execute the "failure-action". "qkd-only-acceptable":Indicates whether the customer wants to maintain post-quantum communication when PQC is not used. This applies to scenarios where only QKD is available and PQC is unavailable or PQC has not been ordered by the customer. If true, continue to use post-quantum encryption. If false, execute the "failure-action". "failure-action": Specifies the action to be executed uniformly for all scenarios where the validity conditions for post-quantum are not met. Typical actions include fallback to conventional crypto or terminate. "pqc": Aggregates all items associated with PQC. "algorithm": Specifies PQC algorithm. "pqc-status": Reports the current operational state of PQC encryption. "qkd": Aggregates all items associated with QKD-based encryption. "key-refresh-interval": Specifies the time interval for automatic refresh of quantum keys stored within the quantum key pool. "qkd-key-pool-id": Specifies 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, CE-to-CE segment, or PE-to-PE segment the paired endpoints (CE and PE, PE and PE or CE and CE) shall use the same qkd-key-pool-id. "qkd-status": Reports the current operational state of qkd encryption. The selection of encryption boundaries is recommended to depend on CE ownership, while staying as close as practicable to the operator's administrative boundary. When CEs are operator-owned, the encryption may be applied for CE-to-CE protection. When CEs are customer-owned, PE-to-PE protection is the recommended deployment option. Note: these are deployment recommendations only; the service model does not mandate specific encryption termination points. Note that if a customer requires both QKD and PQC services simultaneously, operators need to integrate these two quantum-resistant mechanisms. A typical implementation leverages PQC during the IKE negotiation phase, and combines key material derived from PQC with QKD keys to produce the final session symmetric key. This is merely an illustrative example and imposes no restrictions on operator-specific implementations. The detailed deployment approach is left to the network operators.

Customers require end-to-end performance monitoring for fast fault detection and service quality observability.

Gaps in :The base L3SM lacks native monitoring configuration options and service-level performance metrics.

Figure 9 illustrates the module augmentation subtree structure of "perf-mon".

Augmentation Performance Monitoring Subtree Structure | | /l3vpn-svc:l3vpn-svc/vpn-profiles | | /valid-provider-identifiers | | /l3vpn-svc-ext:perf-mon-profile-identifier | | /id | +--:(custom) {perf-mon-custom}? | +--rw measurement-interval? uint32 +--ro status? identityref +--ro metrics +--ro one-way-min-delay? yang:gauge64 +--ro one-way-max-delay? yang:gauge64 +--ro one-way-delay-variation? yang:gauge64 +--ro one-way-packet-loss? decimal64 +--ro two-way-min-delay? yang:gauge64 +--ro two-way-max-delay? yang:gauge64 +--ro two-way-delay-variation? yang:gauge64 +--ro two-way-packet-loss? decimal64 ]]>

The perf-mon service has the following main data nodes: "enable": Enables performance monitoring for the L3VPN service (default false). "monitoring": Contains configuration and read-only state parameters for VPN service monitoring. The sub-items below describe the reporting granularity, aggregation rules, and target-site selection constraints. Customer requirements are centered on end-to-end performance monitoring from a local site to specified target sites, rather than details such as low-level per-access-circuit metrics. Therefore, performance monitoring parameters are reported using the "target-site-id" as the key and the reporting granularity. The model outputs one set of performance metrics and monitoring configuration parameters for each local site to each designated target site. For a site with dual access (such as access to two PEs), only one aggregated set of parameters is recommended to be exposed. The operator determines the aggregation method (e.g., average, maximum) for metrics collected from the two PEs to the target site. The specific aggregation method is implementation-specific and out scope of this document. In addition, the set of selectable target-sites is governed by service logic. For a spoke site, only hub sites may be selected as target sites. For hub sites or any-to-any service topologies, all other sites may be selected as target sites. "perf-mon-profile": Defines two mutually-exclusive options for performance monitoring configuration: The "standard" case references a pre-provisioned performance-monitoring profile defined under "valid-provider-identifiers". The "custom" case enables service-specific custom performance monitoring. It includes "measurement-interval", which specifies the performance measurement interval, and is aligned with . "status": Indicates the operational status of this monitoring session and whether monitoring is functioning normally. "pm-metrics": Specifies 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. Monitoring parameters are aligned with those defined in . It specifies an end-to-end slice service YANG model, and includes performance monitoring related requirements similar to this document.

This modules augments the L3SM. This module uses references defined in . module ietf-l3vpn-svc-ext { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc-ext"; prefix "l3vpn-svc-ext"; import ietf-l3vpn-svc { prefix "l3vpn-svc"; reference "RFC 8299: YANG Data Model for L3VPN Service Delivery"; } import ietf-schedule { prefix "schedule"; reference "RFC 9922: YANG Data Model for Scheduling"; } import ietf-yang-types { prefix "yang"; reference "RFC 6991: Common YANG Data Types"; } import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } organization "IETF ONSEN Working Group"; contact WG List: <onsen@ietf.org> description "This module defines extensions to the ietf-l3vpn-svc YANG module for dynamic L3VPN service capabilities, including dynamic bandwidth adjustment, scheduled activation, end-to-end performance monitoring, enhanced QoS, and class-based security policies with post-quantum encryption support."; reference "RFC 8299, RFC 9922"; identity service-isolation-type { description "Base identity for L3VPN service isolation types."; } identity traffic-isolation { base service-isolation-type; description "Isolation requirement for separating customer L3VPN traffic from other services or tenants, enforced via forwarding plane separation."; } identity failure-action-type { description "Base identity for post-quantum encryption failure actions."; } identity fallback-classic { base failure-action-type; description "Fall back to conventional cryptographic algorithms when post-quantum encryption is unavailable."; } identity block-traffic { base failure-action-type; description "Block traffic when post-quantum encryption is unavailable."; } identity crypto-status-type { description "Base identity for cryptographic component operational status."; } identity crypto-up { base crypto-status-type; description "Cryptographic component is fully operational."; } identity crypto-down { base crypto-status-type; description "Cryptographic component is not operational."; } identity crypto-degraded { base crypto-status-type; description "Cryptographic component is operating in degraded mode."; } identity perf-mon-status-type { description "Base identity for performance monitoring session status."; } identity perf-mon-active { base perf-mon-status-type; description "Monitoring session is active and collecting metrics."; } identity perf-mon-inactive { base perf-mon-status-type; description "Monitoring session is administratively disabled."; } identity perf-mon-error { base perf-mon-status-type; description "Monitoring session is in error state."; } feature dynamic-l3vpn { description "Support time-scheduled dynamic L3VPN service activation and adjustment."; } feature perf-mon { description "Support end-to-end performance monitoring for L3VPN service endpoints."; } feature perf-mon-custom { description "Support custom performance monitoring parameters."; if-feature perf-mon; } feature post-quantum-encryption { description "Support post-quantum encryption capabilities."; } feature pqc { description "Support Post-Quantum Cryptography (PQC) algorithm suite."; if-feature post-quantum-encryption; } feature qkd { description "Support Quantum Key Distribution (QKD) key supply."; if-feature post-quantum-encryption; } grouping schedule-entry-grouping { description "Reusable schedule entry structure, encapsulating standard ietf-schedule groupings. "; leaf schedule-id { type string; description "Unique identifier for this schedule entry. The identifier is unique within the parent list scope."; } choice schedule-type { description "Select the schedule time specification model. The two cases are mutually exclusive."; case period { container period { description "A schedule defined by an start and end time window."; uses schedule:period-of-time; } } case daily-recurrence { container daily-recurrence { description "A recurring schedule based on the standard recurrence grouping with associated time zone information."; uses schedule:recurrence-with-time-zone; } } } leaf actual-start-time { type yang:date-and-time; config false; description "UTC timestamp of the actual start time for the most recently activated schedule instance. "; } leaf actual-stop-time { type yang:date-and-time; config false; description "UTC timestamp of the actual stop time for the most recently activated schedule instance."; } } grouping classification-policy-grouping { description "Reusable traffic classification policy aligned with RFC 8299 structure. This grouping may be applied at site or site-network-access level."; list classification-policy { key "policy-id"; description "Traffic classification policy entry. Each policy defines a set of match rules and a target QoS class for matched flows."; leaf policy-id { type string; description "Identifier for classification policy."; } choice match-type { description "Select the category of traffic match criteria. Cases are mutually exclusive."; case match-flow { description "Match based on packet header fields."; container match-flow { description "Flow-based match criteria from packet headers."; leaf dscp { type inet:dscp; description "Match DSCP value."; } leaf dot1p { type uint8; description "Match 802.1p priority value."; } leaf ipv4-src-prefix { type inet:ipv4-prefix; description "Match IPv4 source prefix."; } leaf ipv6-src-prefix { type inet:ipv6-prefix; description "Match IPv6 source prefix."; } leaf ipv4-dst-prefix { type inet:ipv4-prefix; description "Match IPv4 destination prefix."; } leaf ipv6-dst-prefix { type inet:ipv6-prefix; description "Match IPv6 destination prefix."; } leaf l4-src-port { type inet:port-number; description "Match L4 source port."; } container l4-src-port-range { description "Match L4 source port within a contiguous range."; leaf lower-port { type inet:port-number; description "Lower bound of the source port range."; } leaf upper-port { type inet:port-number; description "Upper bound of the source port range."; } } leaf l4-dst-port { type inet:port-number; description "Match L4 destination port."; } container l4-dst-port-range { description "Match L4 destination port within a contiguous range."; leaf lower-port { type inet:port-number; description "Lower bound of the destination port range."; } leaf upper-port { type inet:port-number; description "Upper bound of the destination port range."; } } leaf protocol-field { type union { type inet:protocol-number; type string; } description "Match IP protocol field value."; } list target-sites { key "site-id"; description "Match traffic destined to the listed target sites."; leaf site-id { type l3vpn-svc:svc-id; description "Target site identifier."; } } } } case match-application { description "Match based on application identifier."; leaf match-application { type string; description "Identifier of the application to match."; } } } leaf target-class-id { type string; description "Identifier of target QoS class for matching traffic."; } } } grouping extended-qos-grouping { description "Extended QoS configuration with class-based policies, applicable at site and site-network-access level."; container qos { description "QoS configuration parameters."; choice qos-profile { description "Select the source of QoS profile definition. Cases are mutually exclusive."; case custom { description "User-defined custom QoS classes."; container classes { description "List of QoS treatment classes."; list class { key "class-id"; description "Single QoS class entry."; leaf class-id { type string; description "QoS class identifier."; } leaf direction { type identityref { base l3vpn-svc:qos-profile-direction; } description "Traffic direction this QoS class applies to."; } leaf rate-limit { type decimal64 { fraction-digits 2; } description "Rate-limit value."; } leaf guaranteed-bw-percent { type decimal64 { fraction-digits 2; } description "Guaranteed bandwidth percentage relative to the access capacity."; } leaf end-to-end { type empty; description "End-to-end QoS treatment flag."; } leaf-list isolation { type identityref { base service-isolation-type; } description "Reference to isolation policies applied to this QoS class."; } container latency { description "Latency objective configuration."; choice flavor { description "Select latency objective mode. Cases are mutually exclusive."; case lowest { leaf use-lowest-latency { type empty; description "Request lowest achievable latency."; } } case boundary { leaf latency-boundary { type uint16; description "Latency boundary threshold in milliseconds."; } } } } container jitter { description "Jitter objective configuration."; choice flavor { description "Select jitter objective mode. Cases are mutually exclusive."; case lowest { leaf use-lowest-jitter { type empty; description "Request lowest achievable jitter."; } } case boundary { leaf jitter-boundary { type uint16; description "Jitter boundary threshold in milliseconds."; } } } } } } } } } } grouping site-perf-mon-grouping { description "Site-level end-to-end performance monitoring configuration."; container oam { description "Operations, Administration and Maintenance functions."; container perf-mon { if-feature perf-mon; description "Performance monitoring configuration."; leaf enable { type boolean; default false; description "Enable performance monitoring function."; } container monitoring { description "Container holding performance monitoring session entries."; list monitor { key "target-site-id"; description "Performance monitoring session to a remote target site."; leaf target-site-id { type l3vpn-svc:svc-id; description "Identifier of the target site to monitor."; } container measurement-profile { description "Measurement profile configuration."; choice profile-type { description "Type of measurement profile. Cases are mutually exclusive."; case standard { description "Standard provider-defined measurement profile."; leaf profile-id { type leafref { path "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-profiles/l3vpn-svc:valid-provider-identifiers/l3vpn-svc-ext:perf-mon-profile-identifier/l3vpn-svc-ext:id"; } description "Reference to the provider-defined perf-mon profile. Profiles are defined by the service provider; customers may only reference existing identifiers."; } } case custom { if-feature perf-mon-custom; description "Custom measurement parameters defined locally on this site."; leaf measurement-interval { type uint32; units "seconds"; description "Measurement polling interval in seconds."; } } } } leaf status { type identityref { base perf-mon-status-type; } config false; description "Operational status of this monitoring session."; } container metrics { config false; description "Collected performance metrics, updated by the monitoring agent."; leaf one-way-min-delay { type yang:gauge64; units "microseconds"; description "One-way minimum delay."; } leaf one-way-max-delay { type yang:gauge64; units "microseconds"; description "One-way maximum delay."; } leaf one-way-delay-variation { type yang:gauge64; units "microseconds"; description "One-way delay variation (jitter)."; } leaf one-way-packet-loss { type decimal64 { fraction-digits 4; } description "One-way packet loss ratio."; } leaf two-way-min-delay { type yang:gauge64; units "microseconds"; description "Two-way minimum round-trip delay."; } leaf two-way-max-delay { type yang:gauge64; units "microseconds"; description "Two-way maximum round-trip delay."; } leaf two-way-delay-variation { type yang:gauge64; units "microseconds"; description "Two-way round-trip delay variation (jitter)."; } leaf two-way-packet-loss { type decimal64 { fraction-digits 4; } description "Two-way round-trip packet loss ratio."; } } } } } } } grouping extended-security-grouping { description "Extended security configuration with encryption profile and class-based custom policies, aligned with the QoS class design pattern. Applicable at site or site-network-access level."; container encryption-profile { description "Encryption profile selection and parameters."; choice profile { description "Select between provider-managed or customer-defined profile. Cases are mutually exclusive."; case provider-profile { description "Reference to provider-defined encryption profile."; leaf profile-name { type leafref { path "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-profiles/l3vpn-svc:valid-provider-identifiers/l3vpn-svc:encryption-profile-identifier/l3vpn-svc:id"; } description "Name of the provider-defined encryption profile. Profiles are managed by the service provider."; } } case customer-profile { description "Customer-defined local encryption profile with class-based policies. This case permits direct specification of cryptographic parameters on this site or site-network-access, as an alternative to referencing a provider template."; container classes { description "List of custom security classes."; list class { key "class-id"; description "Single security class entry."; leaf class-id { type string; description "Security class identifier."; } leaf algorithm { type string; description "Conventional cryptographic algorithm name."; } choice key-type { description "Key delivery type. Cases are mutually exclusive."; case psk { leaf pre-shared-key { type string; description "Pre-shared key material."; } } } container post-quantum-encryption { if-feature post-quantum-encryption; description "Post-quantum encryption configuration for this security class."; container post-quantum-policy { description "Availability and failover policy for post-quantum encryption. The boolean flags control acceptable combinations of PQC and QKD."; leaf pqc-only-acceptable { type boolean; default false; description "When true, a post-quantum security association is acceptable if PQC is operational, even when QKD is unavailable or disabled. If both pqc-only-acceptable and qkd-only-acceptable are false, both PQC and QKD are required for a valid post-quantum session."; } leaf qkd-only-acceptable { type boolean; default false; description "When true, a post-quantum security association is acceptable if QKD is operational, even when PQC is unavailable or disabled. If both pqc-only-acceptable and qkd-only-acceptable are false, both PQC and QKD are required for a valid post-quantum session."; } leaf failure-action { type identityref { base failure-action-type; } default fallback-classic; description "Action to take when post-quantum encryption does not meet the minimum availability requirements."; } } container pqc { if-feature pqc; description "PQC specific configuration and status."; leaf enable { type boolean; default false; description "Enable PQC algorithm suite."; } leaf algorithm { type string; description "Post-quantum cryptographic algorithm or algorithm suite name. Common values include 'kyber-768', 'kyber-1024', 'dilithium-3', 'dilithium-5', etc."; } leaf pqc-status { type identityref { base crypto-status-type; } config false; description "Operational status of PQC, reported by the local crypto stack."; } } container qkd { if-feature qkd; description "QKD key-supply configuration and status."; leaf enable { type boolean; default false; description "Enable QKD key delivery."; } leaf qkd-key-pool-id { type string; description "Identifier for the QKD key pool."; } leaf key-refresh-interval { type uint32; units "seconds"; description "QKD key refresh interval in seconds."; } leaf qkd-status { type identityref { base crypto-status-type; } config false; description "Operational status of QKD key supply, reported by the QKD integration."; } } } } } } } } } augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-profiles/l3vpn-svc:valid-provider-identifiers" { description "Add provider-defined profile identifiers for dynamic L3VPN extensions, aligned with RFC 8299 naming and structure conventions. These identifiers are managed by the service provider and referenced from site and site-network-access configuration."; list bandwidth-adjustment-profile-identifier { key "id"; description "Identifier for a provider-defined bandwidth adjustment profile."; leaf id { type string; description "Unique identifier for the bandwidth adjustment profile."; } } list provisioning-delay-profile-identifier { key "id"; description "Identifier for a provider-defined provisioning delay profile."; leaf id { type string; description "Unique identifier for the provisioning delay profile."; } } list perf-mon-profile-identifier { key "id"; description "Identifier for a provider-defined performance monitoring profile."; leaf id { type string; description "Unique identifier for the performance monitoring profile."; } } } augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" { description "Add site-level classification, QoS and OAM performance monitoring extensions."; uses classification-policy-grouping; uses extended-qos-grouping; uses site-perf-mon-grouping; } augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site/l3vpn-svc:security" { description "Augment site-level security with encryption profile extension."; uses extended-security-grouping; } augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site/l3vpn-svc:site-network-accesses/l3vpn-svc:site-network-access" { description "Augment site-network-access for dynamic service, bandwidth adjustment, classification and QoS extensions."; uses classification-policy-grouping; uses extended-qos-grouping; container service { description "Dynamic-l3vpn service parameters at access level."; container dynamic-l3vpn { if-feature dynamic-l3vpn; description "Dynamic scheduled bandwidth-adjustment configuration."; leaf max-adjustment-bandwidth-range { type leafref { path "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-profiles/l3vpn-svc:valid-provider-identifiers/l3vpn-svc-ext:bandwidth-adjustment-profile-identifier/l3vpn-svc-ext:id"; } description "Reference to bandwidth-adjustment profile identifier. Profiles are provider-managed and define bounds for dynamic bandwidth changes."; } choice dynamic-type { description "Selection of the dynamic L3VPN service capability. The cases are mutually exclusive; only one dynamic capability may be configured on a single site-network-access entry."; case dynamic-networking { description "Dynamic networking capability, for scheduled activation of connectivity between L3VPN sites."; leaf connection-provisioning-latency { type leafref { path "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-profiles/l3vpn-svc:valid-provider-identifiers/l3vpn-svc-ext:provisioning-delay-profile-identifier/l3vpn-svc-ext:id"; } description "Reference to provisioning-delay profile identifier. Profiles are provider-managed and define the provisioning latency expectation for dynamic networking setup."; } container networking-schedule { description "Scheduled activation for dynamic networking service."; list schedule { key "schedule-id"; description "One schedule entry for dynamic networking service."; uses schedule-entry-grouping; } } } case dynamic-bandwidth-adjustment { description "Dynamic bandwidth adjustment capability. When activated by the associated schedule, the access bandwidth temporarily switches to the configured temporary-input-bandwidth and temporary-output-bandwidth values."; leaf bandwidth-adjustment-provisioning-latency { type leafref { path "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-profiles/l3vpn-svc:valid-provider-identifiers/l3vpn-svc-ext:provisioning-delay-profile-identifier/l3vpn-svc-ext:id"; } description "Reference to provisioning-delay profile identifier. Profiles are provider-managed and define the provisioning latency expectation for bandwidth adjustment changes."; } leaf temporary-input-bandwidth { type uint64; units "bits-per-second"; description "Temporary burst input bandwidth applied during schedule activation."; } leaf temporary-output-bandwidth { type uint64; units "bits-per-second"; description "Temporary burst output bandwidth applied during schedule activation."; } container bandwidth-adjustment-schedule { description "Scheduled adjustment for dynamic bandwidth service."; list schedule { key "schedule-id"; description "One schedule entry for dynamic bandwidth service."; uses schedule-entry-grouping; } } } } } } } augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site/l3vpn-svc:site-network-accesses/l3vpn-svc:site-network-access/l3vpn-svc:security" { description "Augment site-network-access-level security with encryption profile extension."; uses extended-security-grouping; } }

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 . 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 L3VPN networking capabilities allow on-demand establishment of VPN connectivity. Implementations MUST enforce authorization checks to prevent customers from establishing L3VPN connectivity to untrusted or unauthorized peers. Detailed trust and authorization mechanisms are implementation-specific and out-of-scope for this document.

Harvard University IBM ETSI

Complete Tree Structure | | /l3vpn-svc:l3vpn-svc/vpn-profiles | | /valid-provider-identifiers | | /l3vpn-svc-ext:perf-mon-profile-identifier/id | +--:(custom) {perf-mon-custom}? | +--rw measurement-interval? uint32 +--ro status? identityref +--ro metrics +--ro one-way-min-delay? yang:gauge64 +--ro one-way-max-delay? yang:gauge64 +--ro one-way-delay-variation? yang:gauge64 +--ro one-way-packet-loss? decimal64 +--ro two-way-min-delay? yang:gauge64 +--ro two-way-max-delay? yang:gauge64 +--ro two-way-delay-variation? yang:gauge64 +--ro two-way-packet-loss? decimal64 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites /l3vpn-svc:site/l3vpn-svc:security: +--rw encryption-profile +--rw (profile)? +--:(provider-profile) | +--rw profile-name? -> | /l3vpn-svc:l3vpn-svc/vpn-profiles | /valid-provider-identifiers | /encryption-profile-identifier/id +--:(customer-profile) +--rw classes +--rw class* [class-id] +--rw class-id string +--rw algorithm? string +--rw (key-type)? | +--:(psk) | +--rw pre-shared-key? string +--rw post-quantum-encryption {post-quantum-encryption}? +--rw post-quantum-policy | +--rw pqc-only-acceptable? boolean | +--rw qkd-only-acceptable? boolean | +--rw failure-action? identityref +--rw pqc {pqc}? | +--rw enable? boolean | +--rw algorithm? string | +--ro pqc-status? identityref +--rw qkd {qkd}? +--rw enable? boolean +--rw qkd-key-pool-id? string +--rw key-refresh-interval? uint32 +--ro qkd-status? identityref augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites /l3vpn-svc:site/l3vpn-svc:site-network-accesses /l3vpn-svc:site-network-access: +--rw classification-policy* [policy-id] | +--rw policy-id string | +--rw (match-type)? | | +--:(match-flow) | | | +--rw match-flow | | | +--rw dscp? inet:dscp | | | +--rw dot1p? uint8 | | | +--rw ipv4-src-prefix? inet:ipv4-prefix | | | +--rw ipv6-src-prefix? inet:ipv6-prefix | | | +--rw ipv4-dst-prefix? inet:ipv4-prefix | | | +--rw ipv6-dst-prefix? inet:ipv6-prefix | | | +--rw l4-src-port? inet:port-number | | | +--rw l4-src-port-range | | | | +--rw lower-port? inet:port-number | | | | +--rw upper-port? inet:port-number | | | +--rw l4-dst-port? inet:port-number | | | +--rw l4-dst-port-range | | | | +--rw lower-port? inet:port-number | | | | +--rw upper-port? inet:port-number | | | +--rw protocol-field? union | | | +--rw target-sites* [site-id] | | | +--rw site-id l3vpn-svc:svc-id | | +--:(match-application) | | +--rw match-application? string | +--rw target-class-id? string +--rw qos | +--rw (qos-profile)? | +--:(custom) | +--rw classes | +--rw class* [class-id] | +--rw class-id string | +--rw direction? identityref | +--rw rate-limit? decimal64 | +--rw guaranteed-bw-percent? decimal64 | +--rw end-to-end? empty | +--rw isolation* identityref | +--rw latency | | +--rw (flavor)? | | +--:(lowest) | | | +--rw use-lowest-latency? empty | | +--:(boundary) | | +--rw latency-boundary? uint16 | +--rw jitter | +--rw (flavor)? | +--:(lowest) | | +--rw use-lowest-jitter? empty | +--:(boundary) | +--rw jitter-boundary? uint16 +--rw service +--rw dynamic-l3vpn {dynamic-l3vpn}? +--rw bandwidth-adjustment-profile-id? -> | /l3vpn-svc:l3vpn-svc/vpn-profiles | /valid-provider-identifiers | /l3vpn-svc-ext:bandwidth-adjustment-profile-identifier | /id +--rw (dynamic-type)? +--:(dynamic-networking) | +--rw connection-provisioning-latency? -> | /l3vpn-svc:l3vpn-svc/vpn-profiles | /valid-provider-identifiers | /l3vpn-svc-ext:provisioning-delay-profile-identifier | /id | +--rw networking-schedule | +--rw schedule* [schedule-id] | +--rw schedule-id string | +--rw (schedule-type)? | | +--:(period) | | | +--rw period | | | +--rw period-description? string | | | +--rw period-start? yang:date-and-time | | | +--rw time-zone-identifier? sys:timezone-name | | | +--rw (period-type)? | | | +--:(explicit) | | | | +--rw period-end? yang:date-and-time | | | +--:(duration) | | | +--rw duration? duration | | +--:(daily-recurrence) | | +--rw daily-recurrence | | +--rw recurrence-first | | | +--rw start-time? yang:date-and-time | | | +--rw duration? duration | | +--rw time-zone-identifier? sys:timezone-name | | +--rw (recurrence-end)? | | | +--:(until) | | | | +--rw until? yang:date-and-time | | | +--:(count) | | | +--rw count? uint32 | | +--rw frequency? identityref | | +--rw interval? uint32 | +--ro actual-start-time? yang:date-and-time | +--ro actual-stop-time? yang:date-and-time +--:(dynamic-bandwidth-adjustment) +--rw connection-provisioning-latency? -> | /l3vpn-svc:l3vpn-svc/vpn-profiles | /valid-provider-identifiers | /l3vpn-svc-ext:provisioning-delay-profile-identifier | /id +--rw temporary-input-bandwidth? uint64 +--rw temporary-output-bandwidth? uint64 +--rw bandwidth-adjustment-schedule +--rw schedule* [schedule-id] +--rw schedule-id string +--rw (schedule-type)? | +--:(period) | | +--rw period | | +--rw period-description? string | | +--rw period-start? yang:date-and-time | | +--rw time-zone-identifier? sys:timezone-name | | +--rw (period-type)? | | +--:(explicit) | | | +--rw period-end? yang:date-and-time | | +--:(duration) | | +--rw duration? duration | +--:(daily-recurrence) | +--rw daily-recurrence | +--rw recurrence-first | | +--rw start-time? yang:date-and-time | | +--rw duration? duration | +--rw time-zone-identifier? sys:timezone-name | +--rw (recurrence-end)? | | +--:(until) | | | +--rw until? yang:date-and-time | | +--:(count) | | +--rw count? uint32 | +--rw frequency? identityref | +--rw interval? uint32 +--ro actual-start-time? yang:date-and-time +--ro actual-stop-time? yang:date-and-time augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site /l3vpn-svc:site-network-accesses /l3vpn-svc:site-network-access/l3vpn-svc:security: +--rw encryption-profile +--rw (profile)? +--:(provider-profile) | +--rw profile-name? -> | /l3vpn-svc:l3vpn-svc/vpn-profiles | /valid-provider-identifiers | /encryption-profile-identifier/id +--:(customer-profile) +--rw classes +--rw class* [class-id] +--rw class-id string +--rw algorithm? string +--rw (key-type)? | +--:(psk) | +--rw pre-shared-key? string +--rw post-quantum-encryption {post-quantum-encryption}? +--rw post-quantum-policy | +--rw pqc-only-acceptable? boolean | +--rw qkd-only-acceptable? boolean | +--rw failure-action? identityref +--rw pqc {pqc}? | +--rw enable? boolean | +--rw algorithm? string | +--ro pqc-status? identityref +--rw qkd {qkd}? +--rw enable? boolean +--rw qkd-key-pool-id? string +--rw key-refresh-interval? uint32 +--ro qkd-status? identityref ]]>

This example illustrates the configuration for an immediately activated dynamic networking service. By omitting period-start, activation takes place when the configuration is applied. The PT2H duration defines a service lifetime of two hours, after which the service is automatically terminated. ban-prof-01 dynamic-networking lat-prof-01 sch-001 PT2H ]]>

This example illustrates the configuration for a recurring dynamic bandwidth adjustment service. The baseline bandwidth is 1 Gbps, and the temporary bursted bandwidth is 2 Gbps. Bandwidth is temporarily increased every day from 02:00 to 04:00 UTC, for a total of thirty occurrences. During each window, the service operates at the configured temporary bandwidth values (2 Gbps). After a window ends, bandwidth automatically reverts to the baseline bandwidth values (1 Gbps). The recurring activation stops once thirty matching events have taken place. lat-prof-02 2000000 2000000 sch-002 2026-11-01T02:00:00Z PT2H Asia/Shanghai 30 ext:daily 1 ]]>

This section provides illustrative configuration examples for combining the post-quantum policy parameters. These policy combinations are illustrative; operators may further constrain allowed policy combinations on their deployment. High security strict mode: Quantum-based security is used only when both PQC and QKD are available. The service is blocked if either mechanism fails.

Availability-First Mode: Quantum-based security is enabled if at least one of PQC or QKD is available. If both become unavailable, the encryption mechanism falls back to conventional cryptography.

PQC as baseline, QKD as enhancement: Quantum-based security is allowed when PQC is available (QKD alone is insufficient). If PQC is unavailable, the encryption mechanism falls back to conventional cryptography.

QKD as baseline, PQC as enhancement: Quantum-based security is allowed when QKD is available (PQC alone is insufficient). If QKD is unavailable, the encryption mechanism falls back to conventional cryptography.

This example illustrates site-level security configuration for the L3VPN service extension using a customer-specific security profile that enables PQC, QKD and conventional encryption capabilities. Key configuration elements are as follows: A security class with identifier "high-security-flow" is defined under the customer-profile branch. Conventional encryption uses the AES-256-GCM algorithm. The post-quantum encryption policy accepts PQC-only availability, does not accept QKD-only availability, and falls back to conventional encryption when no post-quantum technology meets the availability requirements. PQC is enabled with the kyber-768 algorithm suite. QKD key delivery is enabled, associated with key pool "qkd-pool-core-01", with a key refresh interval of 3600 seconds. The same encryption profile structure applies to the site-network-access level security node, differing only in the augmentation path. site-01 high-security-flow aes-256-gcm true false l3vpn-svc-ext:fallback-classic true kyber-768 true qkd-pool-core-01 3600 ]]>

This section provides an example of site-level end-to-end performance monitoring configuration and metrics for the L3VPN service extension. The example includes two performance monitoring sessions to different remote target sites, illustrating both the standard provider-defined profile mode and the customized mode. Key configuration elements are as follows: A monitoring session targeting site "site-02" uses a standard provider-defined measurement profile, referenced by the profile identifier "perf-mon-standard-1". A monitoring session targeting site "site-03" uses customized measurement parameters, with a measurement interval of 30 seconds. site-01 true site-02 perf-mon-standard-1 site-03 30 ]]>

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

The following authors contributed significantly to this document.