ONSEN Working Group C. Huang Internet-Draft China Telecom Intended status: Standards Track C. Xie Expires: 2 May 2027 China Telecom 2 November 2026 Extensions to the YANG Network Data Model for L3VPN draft-huang-onsen-update-l3nm-network-models-00 Abstract RFC 9182 defines a YANG network data model for Layer 3 VPNs (L3NM), which provides a network-centric view of L3VPN services and is used by orchestrators to drive network controllers. A companion effort extends the L3VPN Service Model (L3SM, RFC 8299) with dynamic and enhanced service features, including dynamic networking provisioning, dynamic bandwidth adjustment, QoS enhancements for network slicing, performance monitoring, and quantum-safe encryption [I-D.fu-onsen-update-l3sm-service-models]. At the network layer, such dynamic service requirements translate into time-scheduled resource reservations that the network confirms for feasibility and reserves in advance of the activation moment (Section 1.1). These enhanced service features cannot be realized by the network unless corresponding capabilities are exposed at the network layer. The base L3NM defined in RFC 9182 exhibits gaps in these areas. This document defines a set of YANG augmentations to the L3NM to close those gaps. The augmentations are designed to be backward-compatible and do not obsolete RFC 9182. Status of This Memo 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 as Internet-Drafts. 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 2 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Huang & Xie Expires 2 May 2027 [Page 1] Internet-Draft L3NM Service Extensions November 2026 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. Table of Contents 1. Introduction 1.1. Time Scheduling versus Reactive Re-provisioning 2. Terminology 3. Network Data Model Usage and Relationship to the Extended L3SM 4. L3NM Augmentations Overview 5. L3NM Augmentations Description 5.1. Overall Tree Structure 5.2. Time-Scheduled Networking Provisioning 5.2.1. Requirements 5.2.2. Gaps in RFC 9182 5.2.3. Extensions 5.3. Time-Scheduled Bandwidth Adjustment 5.3.1. Requirements 5.3.2. Gaps in RFC 9182 5.3.3. Extensions 5.4. Extensions for "qos" 5.4.1. Requirements 5.4.2. Gaps in RFC 9182 5.4.3. Extensions 5.5. Performance Monitoring 5.5.1. Requirements 5.5.2. Gaps in RFC 9182 5.5.3. Extensions 5.6. Extensions for "security" 5.6.1. Requirements 5.6.2. Gaps in RFC 9182 5.6.3. Extensions 6. L3NM Augmentation YANG Module 7. IANA Considerations 8. Security Considerations 9. References 9.1. Normative References 9.2. Informative References Appendix A. Data Model Examples A.1. Configuration of Time-Scheduled Networking Service A.2. Configuration of Time-Scheduled Bandwidth Adjustment A.3. Performance Monitoring A.4. Configuration of Post-Quantum Security Service Acknowledgments Authors' Addresses Huang & Xie Expires 2 May 2027 [Page 2] Internet-Draft L3NM Service Extensions November 2026 1. Introduction RFC 9182 [RFC9182] defines the Layer 3 VPN Network Model (L3NM), a YANG data model that provides a network-centric view of L3VPN services. In the layered management framework of [RFC8969], an orchestrator exposes the customer-facing L3VPN Service Model (L3SM, [RFC8299]) northbound and translates service requests into L3NM instances that are delivered to network controllers. [RFC9181] defines a companion YANG data model for L3VPN service delivery. The base L3SM assumes relatively static service characteristics: persistent connectivity between fixed sites with bandwidth parameters specified at service creation time. [I-D.fu-onsen-update-l3sm- service-models] extends the L3SM to address emerging service requirements, including: * Dynamic networking provisioning: on-demand establishment and release of VPN connectivity with provisioning-delay SLO constraints. * Dynamic bandwidth adjustment: temporary bandwidth scaling on top of a persistent baseline bandwidth. * QoS enhancements: isolation requirements aligned with IETF network slicing, and reusable traffic classification policies. * Performance monitoring: end-to-end, site-to-site performance metrics for service quality observability. * Security enhancements: fine-grained per-class traffic encryption and quantum-safe encryption based on Post-Quantum Cryptography (PQC) and Quantum Key Distribution (QKD). Service requests expressed with these extensions cannot be honored by the network unless the corresponding capabilities are exposed to the network controllers through the network model. The base L3NM, however, exhibits gaps in these areas: * L3NM assumes persistent VPN services; it provides no means to specify activation/deactivation schedules for VPN connectivity or provisioning-delay SLOs. * L3NM specifies static bandwidth parameters ("pe-to-ce-bandwidth"/"ce-to-pe-bandwidth") without support for scheduled, temporary bandwidth adjustment. * L3NM lacks constructs to bind QoS classes to isolation requirements for network slicing over, e.g., SRv6-based transport, scatters traffic classification rules under the "qos" container only (preventing reuse by other functional modules), and provides no means to activate QoS action rules according to time schedules. Huang & Xie Expires 2 May 2027 [Page 3] Internet-Draft L3NM Service Extensions November 2026 * L3NM provides only access-circuit-level OAM (e.g., BFD) and lacks end-to-end, node-to-node performance monitoring configuration and metrics. * L3NM defines coarse-grained encryption enablement and lacks support for PQC and QKD integration. This document defines YANG augmentations to the L3NM to address these gaps, mirroring the service-layer capabilities defined in [I-D.fu-onsen-update-l3sm-service-models]. 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 network data model extensions. Implementation details of the underlying mechanisms (e.g., signaling protocols, scheduling engines, encryption algorithms) are out of scope. 1.1. Time Scheduling versus Reactive Re-provisioning One could argue that the network model needs no change at all: whenever a customer's resource demand varies, the orchestrator could simply push a new service request to the network controller at that moment. This reactive approach, however, provides no guarantee that the network can honor the request at the moment it is made. For example, a temporary demand for very large bandwidth may exceed the residual capacity available when the change is requested, causing the request to be rejected or the service to be degraded at the worst possible time. Time scheduling addresses this by making the intended changes visible to the network in advance. A schedule such as "raise the bandwidth to X every workday between 09:00 and 18:00" allows the controller to perform advance admission control -- confirming, days ahead, that the required resources will still be available on day N at time T -- and to reserve the corresponding network resources ahead of time. This is fundamentally different from reacting to demand changes as they occur: in the reactive model the network allocates resources "now" and therefore needs no notion of time, whereas scheduled services require the network model itself to carry the time dimension so that feasibility checks and resource reservations can be performed before the activation moment. Accordingly, the "dynamic" service requirements expressed in the extended L3SM map, at the network layer, to time-scheduled resource reservation requirements. The constructs defined in this document are therefore named "time-scheduled-*" rather than "dynamic-*". 2. Terminology Huang & Xie Expires 2 May 2027 [Page 4] Internet-Draft L3NM Service Extensions November 2026 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the following terms which are defined in other documents: AC: Attachment Circuit [RFC9833]. CE: Customer Edge [RFC4026]. L3NM: Layer 3 VPN Network Model [RFC9182]. L3SM: Layer 3 VPN Service Model [RFC8299]. L3VPN: Layer 3 Virtual Private Network [RFC4026]. PE: Provider Edge [RFC4026]. PQC: Post-Quantum Cryptography [RFC9958]. QKD: Quantum Key Distribution [ETSI-GR-QKD-007]. This document reuses the term "Dynamic-L3VPN" defined in [I-D.fu-onsen-update-l3sm-service-models], which covers two service types: dynamic networking provisioning and dynamic bandwidth adjustment. At the network layer, these service types are realized as time-scheduled resource reservations (Section 1.1); the corresponding constructs defined in this document are therefore named "time-scheduled-*". The following terms are used for tree diagrams in this document: they reuse the notation defined in Section 4 of [RFC8340]. 3. Network Data Model Usage and Relationship to the Extended L3SM The extensions in this document follow the same network data model usage as the base L3NM. A typical delivery flow is shown in Figure 1. A customer orders an enhanced L3VPN service using the extended L3SM; the orchestrator translates the service parameters into network-level parameters using the extended L3NM defined in this document, and delivers them to the network controller(s), which in turn configure the network elements. Huang & Xie Expires 2 May 2027 [Page 5] Internet-Draft L3NM Service Extensions November 2026 +----------------+ | Customer | +-------+--------+ | L3SM (RFC 8299) + L3SM extensions | [I-D.fu-onsen-update-l3sm-service-models] +-------+--------+ | Orchestrator | +-------+--------+ | L3NM (RFC 9182) + L3NM extensions | (this document) +-------+--------+ | Network | | Controller | +-------+--------+ | Device configuration models +----+----+------+ | | | +-+-+ +-+-+ +-+--+ |PE1| |PE2| |DCGW| +---+ +---+ +----+ Figure 1: Extended L3VPN Network Model Delivery Table 1 summarizes the correspondence between the extended L3SM data nodes and the extended L3NM data nodes defined in this document. +-------------------------------+-------------------------------+ | Extended L3SM node | Extended L3NM node | +-------------------------------+-------------------------------+ | /l3vpn-svc/vpn-profiles/ | /l3vpn-ntw/vpn-profiles/ | | valid-provider-identifiers | valid-provider-identifiers | | (bandwidth-adjustment, | (bandwidth-adjustment, | | provisioning-latency, | provisioning-delay, | | perf-mon identifiers) | perf-mon identifiers) | | /l3vpn-svc/sites/site | vpn-nodes/vpn-node | | site-network-accesses/ | vpn-network-accesses/ | | site-network-access | vpn-network-access | | svc-input-bandwidth | ce-to-pe-bandwidth | | svc-output-bandwidth | pe-to-ce-bandwidth | | dynamic-l3vpn | time-scheduled-l3vpn | | networking-schedule | networking-schedule | | (period-of-time or | (period-of-time or | | icalendar-recurrence per | icalendar-recurrence per | | [RFC9922]) | [RFC9922]) | | temporary-input-bandwidth | temporary-ce-to-pe-bandwidth | | temporary-output-bandwidth | temporary-pe-to-ce-bandwidth | | bandwidth-adjustment-schedule | bandwidth-adjustment-schedule | | (period-of-time or | (period-of-time or | | icalendar-recurrence per | icalendar-recurrence per | | [RFC9922]) | [RFC9922]) | | classification-policy (site) | classification-policy | | | (vpn-node) | | classification-policy (site- | classification-policy | | network-access) | (vpn-network-access) | Huang & Xie Expires 2 May 2027 [Page 6] Internet-Draft L3NM Service Extensions November 2026 | oam/perf-mon, monitor | perf-mon, monitor | | [target-site-id] | [target-vpn-node-id] | | security customer-profile | security classes/class | | classes/class | | | qos custom classes isolation | qos-action rule isolation | +-------------------------------+-------------------------------+ Table 1: L3SM Extension to L3NM Extension Mapping Note on bandwidth direction: from the customer perspective of the L3SM, "svc-input-bandwidth" is the upload rate into the provider network, which maps to the L3NM "ce-to-pe-bandwidth"; "svc-output-bandwidth" maps to "pe-to-ce-bandwidth". Note on schedules: both layers express activation time slots with the "period-of-time" and "icalendar-recurrence" groupings of [RFC9922]. A schedule entry therefore covers an explicit start and end time ("period-start"/"period-end") or a duration, an optional time zone, and recurring patterns ("frequency", "interval", "byday", "workweek-start", bounded by "until" or "count"), so the schedule subtrees translate verbatim between the two layers. The parameter inheritance mechanism defined in [RFC9182] between the "vpn-node" level and the "vpn-network-access" level also applies to the extensions defined in this document (e.g., for classification policies). 4. L3NM Augmentations Overview The extensions are defined in the module "ietf-l3vpn-ntw-ext", which augments the base L3NM module ("ietf-l3vpn-ntw") at the following locations: * /l3vpn-ntw/vpn-profiles/valid-provider-identifiers: Adds three profile identifier lists: bandwidth adjustment profiles, provisioning-delay SLO profiles, and performance monitoring profiles. These profiles are predefined and standardized by the operator and can be referenced by multiple VPN services. * /l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node: Adds a node-level unified "classification-policy" list that defines a set of ordered rules to classify customer traffic and generates "class-id" values reusable across functional modules ("qos", "security", "perf-mon"). Also adds a "perf-mon" container for end-to-end performance monitoring towards other VPN nodes. Huang & Xie Expires 2 May 2027 [Page 7] Internet-Draft L3NM Service Extensions November 2026 * /l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/ vpn-network-accesses/vpn-network-access: Adds an access-level "classification-policy" list; augments "service" with a "time-scheduled-l3vpn" container, which carries the activation schedule ("networking-schedule") and the temporary bandwidth schedule ("bandwidth-adjustment-schedule"), both reusing the groupings of [RFC9922]; augments "qos" with per-class isolation requirements and time-scheduled activation of QoS action rules; augments "security" with fine-grained per-class encryption including post-quantum options. Different modules MUST use identical "class-id" values for traffic matching when handling the same traffic flows, and different "class-id" values when handling distinct traffic flows. 5. L3NM Augmentations Description 5.1. Overall Tree Structure Figure 2 illustrates the overall module augmentation tree structure. module: ietf-l3vpn-ntw-ext augment /l3nm:l3vpn-ntw/l3nm:vpn-profiles /l3nm:valid-provider-identifiers: +--rw bandwidth-adjustment-profile-identifier* [id] | +--rw id string +--rw provisioning-delay-profile-identifier* [id] | +--rw id string +--rw perf-mon-profile-identifier* [id] +--rw id string augment /l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service /l3nm:vpn-nodes/l3nm:vpn-node: +--rw classification-policy* [rule-id] | ... +--rw perf-mon {perf-mon}? ... augment /l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service /l3nm:vpn-nodes/l3nm:vpn-node /l3nm:vpn-network-accesses/l3nm:vpn-network-access: +--rw classification-policy* [rule-id] | ... +--rw service | +--rw time-scheduled-l3vpn {time-scheduled-l3vpn}? | | ... | +--rw qos | ... +--rw security ... Figure 2: Overall Augmentation Tree Structure Huang & Xie Expires 2 May 2027 [Page 8] Internet-Draft L3NM Service Extensions November 2026 5.2. Time-Scheduled Networking Provisioning 5.2.1. Requirements Customers require task-based and short-lived VPN connectivity: VPN connectivity is established only when a transmission task starts and torn down upon task completion. At the network layer, this requires the controller to activate and deactivate the configuration of VPN nodes and VPN network accesses according to specified time slots. Because higher-bandwidth allocations are short-lived, customers are more sensitive to provisioning latency than with conventional L3VPN services. The connection provisioning latency, quantified as the time offset between the requested-start and actual-start timestamps, needs to be exposed as an SLO attribute. Provisioning latency here excludes physical device deployment time; it refers only to the time required to logically activate or deactivate the VPN configuration. 5.2.2. Gaps in RFC 9182 The L3NM assumes persistent VPN services. It does not provide parameters to specify the requested start and stop times of VPN network accesses, nor activation time constraints. The "ietf-bearer-svc" model [RFC9834] provides "requested-start" and "requested-stop" nodes for a bearer, but it lacks support for diverse time-scheduled provisioning capabilities, such as specifying multiple connection periods in a single configuration or recurring schedules. 5.2.3. Extensions This document defines the data structure for time-scheduled activation and deactivation of VPN connectivity at the VPN network access level, with specified provisioning-delay constraints. The detailed mechanisms for fast activation and deactivation of L3VPN configuration are implementation-specific and out of scope of this document. The time-scheduled-networking capability applies to the lifecycle of the logical VPN connectivity; it does not imply on-the-fly creation or deletion of physical devices or sites. Figure 3 illustrates the module augmentation subtree structure of time-scheduled networking provisioning. Huang & Xie Expires 2 May 2027 [Page 9] Internet-Draft L3NM Service Extensions November 2026 augment /l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service /l3nm:vpn-nodes/l3nm:vpn-node /l3nm:vpn-network-accesses/l3nm:vpn-network-access: +--rw service +--rw time-scheduled-l3vpn {time-scheduled-l3vpn}? +--rw (time-scheduled-type)? +--:(time-scheduled-networking) +--rw provisioning-delay-profile-id? -> | /l3nm:l3vpn-ntw/vpn-profiles | /valid-provider-identifiers | /l3nm-ext:provisioning-delay-profile-identifier | /l3nm-ext: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 | +--:(recurrence) | +--rw 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 recurrence-description? | | string | +--rw frequency? identityref | +--rw interval? uint32 | +--rw period* [period-start] | | +--rw period-description? | | | string | | +--rw period-start | | | yang:date-and-time | | +--rw time-zone-identifier? | | | sys:timezone-name Huang & Xie Expires 2 May 2027 [Page 10] Internet-Draft L3NM Service Extensions November 2026 | | +--rw (period-type)? | | +--:(explicit) | | | +--rw period-end? | | | yang:date-and-time | | +--:(duration) | | +--rw duration? duration | +--rw byday* [weekday] | | +--rw weekday | | schedule:weekday | +--rw workweek-start? | schedule:weekday +--ro actual-start-time? | yang:date-and-time +--ro actual-stop-time? yang:date-and-time Figure 3: Augmentation Time-Scheduled Networking Subtree Structure A time-scheduled networking provisioning service has the following main data nodes: "time-scheduled-l3vpn": Provides the container to group all parameters associated with time-scheduled service provisioning. This parameter is configurable only when the "time-scheduled-l3vpn" feature is enabled. "time-scheduled-type": Indicates the type of time-scheduled L3VPN service. The time-scheduled-networking and time-scheduled-bandwidth-adjustment types are defined so far. The two types are mutually exclusive for a given VPN network access. "provisioning-delay-profile-id": References an operator-predefined provisioning-delay SLO template. The SLO quantifies the allowed time offset between the requested-start and actual-start timestamps of the VPN connection. This SLO applies only to connection activation; the latency for connection teardown is out of scope for this attribute. "networking-schedule": Specifies the exact time slots during which the VPN network access (and the associated VPN connectivity) shall be activated. The schedule concept is aligned with [RFC9922]. Two types of schedules are supported: period-based schedules ("period-of-time") and recurring cyclic schedules ("icalendar-recurrence"). If "period-start" is omitted, the activation takes effect immediately upon configuration commit and lasts for the specified "duration". Multiple periods MAY exist within a single schedule. Huang & Xie Expires 2 May 2027 [Page 11] Internet-Draft L3NM Service Extensions November 2026 "actual-start-time" and "actual-stop-time": Report the actual date and time when the VPN connectivity was activated/deactivated. They are read-only parameters populated by the network controller. The offset between the actual and requested timestamps represents the actual provisioning delay and is used to validate whether the service meets the provisioning-delay SLO. When a schedule becomes active, the network controller activates the configuration of the involved VPN nodes and VPN network accesses (e.g., VRF, routing protocols, QoS); when the schedule expires, the controller deactivates the configuration. The per-feature state transitions are implementation-specific. 5.3. Time-Scheduled Bandwidth Adjustment 5.3.1. Requirements Some customers require a persistent VPN connection with a baseline bandwidth for regular service use. When special requirements arise (e.g., large-data-transmission workloads), higher bandwidth needs to be provisioned temporarily on top of the existing persistent VPN. After the workload completes, the temporary bandwidth setting is revoked and the service reverts to its baseline bandwidth while keeping the persistent VPN connection intact. Customers may require the bandwidth adjustment provisioning latency to be exposed as an SLO attribute, quantifying the time offset between the requested-start and actual-start timestamps of the bandwidth increase operation. 5.3.2. Gaps in RFC 9182 The base L3NM specifies static bandwidth parameters ("pe-to-ce-bandwidth" and "ce-to-pe-bandwidth" under "service") without support for elastic bandwidth adjustment, scheduled temporary bandwidth, or bandwidth adjustment provisioning latency constraints. 5.3.3. Extensions This document defines the data structures to support time-scheduled bandwidth adjustment at the VPN network access level. Figure 4 illustrates the module augmentation subtree structure. augment /l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service /l3nm:vpn-nodes/l3nm:vpn-node /l3nm:vpn-network-accesses/l3nm:vpn-network-access: +--rw service +--rw pe-to-ce-bandwidth? uint64 +--rw ce-to-pe-bandwidth? uint64 +--rw time-scheduled-l3vpn {time-scheduled-l3vpn}? +--rw (time-scheduled-type)? +--:(time-scheduled-bandwidth-adjustment) +--rw bandwidth-adjustment-profile-id? -> Huang & Xie Expires 2 May 2027 [Page 12] Internet-Draft L3NM Service Extensions November 2026 | /l3nm:l3vpn-ntw/vpn-profiles | /valid-provider-identifiers | /l3nm-ext:bandwidth-adjustment-profile | -identifier/l3nm-ext:id +--rw temporary-pe-to-ce-bandwidth? uint64 +--rw temporary-ce-to-pe-bandwidth? uint64 +--rw bandwidth-adjustment-schedule +--rw schedule* [schedule-id] +--rw schedule-id string +--rw (schedule-type)? (as in Figure 3) +--ro actual-start-time? | yang:date-and-time +--ro actual-stop-time? yang:date-and-time Figure 4: Augmentation Time-Scheduled Bandwidth Subtree Structure A time-scheduled bandwidth adjustment service has the following main data nodes: "bandwidth-adjustment-profile-id": References an operator- predefined bandwidth adjustment profile, which indicates the maximum allowed bandwidth after adjustment. This parameter is a factor that operators need to consider when selecting the appropriate bearer solution for physical access links. For example, operators may deploy GE links between CE and PE when the maximum bandwidth is below 1 Gbps, while 50G/100G links are adopted when the required bandwidth exceeds 10 Gbps. The exact approach is implementation-specific. "temporary-pe-to-ce-bandwidth" and "temporary-ce-to-pe-bandwidth": Indicate the desired temporary PE-to-CE and CE-to-PE bandwidth after adjustment. These two parameters are absolute values, not delta offsets from the baseline bandwidth. The existing "pe-to-ce-bandwidth" and "ce-to-pe-bandwidth" of [RFC9182] represent the baseline bandwidth. "bandwidth-adjustment-schedule": Specifies the exact time slots for the time-scheduled bandwidth adjustment service. The data structure follows the same pattern as the "networking-schedule" described in Section 5.2.3; details are not repeated here. "actual-start-time" and "actual-stop-time": Report the actual timestamps when the bandwidth adjustment took effect and was revoked. They are used to validate the bandwidth adjustment provisioning latency SLO. 5.4. Extensions for "qos" 5.4.1. Requirements Huang & Xie Expires 2 May 2027 [Page 13] Internet-Draft L3NM Service Extensions November 2026 With the widespread deployment of SRv6 network slicing, the L3NM needs to support slicing-specific SLO/SLE parameters, including isolation, so that L3VPN services can be delivered over IETF network slices with differentiated treatment. In addition, QoS flow classification policies are expected to be reusable across other functional modules of the same VPN node or VPN network access, such as "security" and "perf-mon", to reduce the complexity of flow classification definitions. Furthermore, QoS requirements may vary over time: for example, a customer may require a stricter rate limit or a dedicated isolation level for a traffic class during peak hours, and a relaxed treatment otherwise. As motivated in Section 1.1, such time-varying QoS treatment needs to be scheduled in advance so that the network can confirm and reserve the resources (e.g., queue bandwidth on the involved links) required by each time slot. 5.4.2. Gaps in RFC 9182 The base L3NM provides QoS classification and action policies, but lacks integration with network slicing constructs and parameterized isolation specifications. Traffic classification policies reside under the "qos" container ("qos-classification-policy"), making them inconvenient to reuse by other functional modules. Finally, the QoS action rules of the base L3NM are static: they take effect when configured and provide no means to activate or deactivate a rule according to a time schedule. 5.4.3. Extensions This document defines three extensions for "qos". First, an "isolation" leaf-list is added to the QoS action rules, so that traffic classes bound by a QoS action can be associated with isolation requirements. The definition of "isolation" aligns with [I-D.ietf-teas-ietf-network-slice-nbi-yang], enabling consistent policy application across VPN and slice services. The controller maps the isolation requirement to the underlay transport (e.g., an SRv6 network slice instance selected via "underlay-transport"). augment .../l3nm:vpn-network-access/l3nm:service/l3nm:qos /l3nm:qos-action/l3nm:rule: +--rw rule-id +--rw target-class-id? +--rw rate-limit-by-type? +--rw isolation* identityref {qos-isolation}? +--rw qos-schedule {time-scheduled-l3vpn}? +--rw schedule* [schedule-id] +--rw schedule-id string +--rw (schedule-type)? (as in Figure 3) Huang & Xie Expires 2 May 2027 [Page 14] Internet-Draft L3NM Service Extensions November 2026 +--ro actual-start-time? | yang:date-and-time +--ro actual-stop-time? yang:date-and-time Figure 5: Augmentation QoS Subtree Structure Second, a "qos-schedule" container is added to each QoS action rule (also shown in Figure 5), reusing the "time-schedule" grouping, so that a rule -- including its rate limit and isolation binding -- can be activated and deactivated according to period-based or recurring time slots. When no schedule is present, the rule is active immediately upon configuration commit. Scheduling QoS rules in advance allows the controller to confirm and reserve the resources required by each time slot (Section 1.1). Third, a unified "classification-policy" list is added at both the "vpn-node" and "vpn-network-access" levels. It reuses the classification rule definition of [RFC8299], but places it outside "qos" so that the generated "class-id" values can be referenced by various service function modules, including "qos" (via "target-class-id") and "security" (Section 5.6.3). The inheritance mechanism of [RFC9182] applies: a "class-id" defined at the vpn-node level is visible to all VPN network accesses of that node unless overridden. +--rw classification-policy* [rule-id] +--rw rule-id string +--rw (match-type)? | +--:(match-flow) | | +--rw dscp? inet:dscp | | +--rw dot1p? uint8 | | +--rw protocol-field? uint8 | | +--rw ipv4-src-prefix? inet:ipv4-prefix | | +--rw ipv4-dst-prefix? inet:ipv4-prefix | | +--rw ipv6-src-prefix? inet:ipv6-prefix | | +--rw ipv6-dst-prefix? inet:ipv6-prefix | | +--rw l4-src-port? inet:port-number | | +--rw l4-dst-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-range | | +--rw lower-port? inet:port-number | | +--rw upper-port? inet:port-number | +--:(match-application) | +--rw match-application? identityref +--rw target-class-id? string Figure 6: Unified Classification-Policy Subtree Structure 5.5. Performance Monitoring Huang & Xie Expires 2 May 2027 [Page 15] Internet-Draft L3NM Service Extensions November 2026 5.5.1. Requirements Customers require end-to-end performance monitoring for fast fault detection and service quality observability. At the network layer, this translates into activating measurement sessions between VPN nodes and reporting the collected metrics. 5.5.2. Gaps in RFC 9182 The base L3NM provides OAM only at the access-circuit level (e.g., BFD for the CE-PE link) and lacks node-to-node performance monitoring configuration and service-level performance metrics. 5.5.3. Extensions This document defines a "perf-mon" container under "vpn-node". Figure 7 illustrates the module augmentation subtree structure. augment /l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service /l3nm:vpn-nodes/l3nm:vpn-node: +--rw perf-mon {perf-mon}? +--rw enable? boolean +--rw monitoring +--rw monitor* [target-vpn-node-id] +--rw target-vpn-node-id -> .../vpn-node-id +--rw measurement-profile | +--rw (profile-type)? | +--:(standard) | | +--rw profile-id? -> | | /l3nm:l3vpn-ntw/vpn-profiles | | /valid-provider-identifiers | | /l3nm-ext:perf-mon-profile-identifier | | /l3nm-ext: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 Figure 7: Augmentation Performance Monitoring Subtree Structure The perf-mon service has the following main data nodes: "enable": Enables performance monitoring for the VPN node (default false). Huang & Xie Expires 2 May 2027 [Page 16] Internet-Draft L3NM Service Extensions November 2026 "monitoring": Contains configuration and read-only state parameters for VPN service monitoring. Customer requirements are centered on end-to-end performance from a local site to specified target sites, rather than low-level per-access-circuit metrics. Therefore, performance parameters are reported using the target VPN node as the key and the reporting granularity. For a VPN node connected to a target through multiple paths (e.g., dual access), only one aggregated set of parameters is exposed; the aggregation method is determined by the operator and is out of scope of this document. The set of selectable target VPN nodes is governed by service logic. For a spoke VPN node, only hub VPN nodes may be selected as targets. For hub VPN nodes or any-to-any topologies, all other VPN nodes of the same VPN service may be selected. "measurement-profile": Defines two mutually exclusive options: the "standard" case references a pre-provisioned performance monitoring profile defined under "valid-provider-identifiers"; the "custom" case enables service-specific monitoring with an explicit "measurement-interval" (aligned with [RFC9375]). "status": Indicates the operational status of the monitoring session. "metrics": A set of operational state and service-level performance metrics, including delay, delay variation, and packet loss, to enrich operational state data and enhance end-to-end quality visibility. The metrics are aligned with [I-D.ietf-teas-ietf-network-slice-nbi-yang]. 5.6. Extensions for "security" 5.6.1. Requirements 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. 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. 5.6.2. Gaps in RFC 9182 The L3NM defines basic encryption enablement (e.g., the "encryption" container under "security") applied to full traffic on access circuits, which operates at a relatively coarse granularity. The L3NM lacks support for QKD and PQC integration. 5.6.3. Extensions Huang & Xie Expires 2 May 2027 [Page 17] Internet-Draft L3NM Service Extensions November 2026 This document augments the "security" container of the VPN network access with a "classes" list for fine-grained, per-class encryption, where each class is keyed by a "class-id" generated by the unified classification policy (Section 5.4.3). Each class may carry post-quantum encryption parameters. Figure 8 illustrates the module augmentation subtree structure. augment /l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service /l3nm:vpn-nodes/l3nm:vpn-node /l3nm:vpn-network-accesses/l3nm:vpn-network-access /l3nm:security: +--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 +--ro qkd-status? identityref +--rw qkd-key-pool-id? string +--rw key-refresh-interval? uint32 Figure 8: Augmentation Security Subtree Structure The extended security service has the following main data nodes: "class-id": Identifies the traffic class to which the encryption policy applies. The value MUST correspond to a "target-class-id" generated by a "classification-policy" applied to the same VPN network access or to the enclosing VPN node. "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. Huang & Xie Expires 2 May 2027 [Page 18] Internet-Draft L3NM Service Extensions November 2026 "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 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. "pqc-only-acceptable": Indicates whether post-quantum communication shall be maintained when QKD-derived keys are not used (i.e., when only PQC is available, QKD is unavailable, or QKD has not been ordered). If true, continue to use post-quantum encryption; if false, execute the "failure-action". "qkd-only-acceptable": Indicates whether post-quantum communication shall be maintained when PQC is not used (i.e., when only QKD is available and PQC is unavailable or has not been ordered). 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 encryption are not met. Typical actions include fallback to conventional cryptography and termination. "pqc": Aggregates all items associated with PQC: "enable", "algorithm", and the read-only "pqc-status". "qkd": Aggregates all items associated with QKD-based encryption: "enable", the read-only "qkd-status", "qkd-key-pool-id", and "key-refresh-interval". "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 the CE-to-PE, CE-to-CE, or PE-to-PE segment, the paired endpoints shall use the same "qkd-key-pool-id". "key-refresh-interval": Specifies the time interval for automatic refresh of quantum keys stored within the quantum key pool. Selection of encryption boundaries is recommended to depend on CE ownership. 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. Huang & Xie Expires 2 May 2027 [Page 19] Internet-Draft L3NM Service Extensions November 2026 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 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. 6. L3NM Augmentation YANG Module This module augments the L3NM defined in [RFC9182]. It imports groupings from [RFC9922] for schedule representation. file "ietf-l3vpn-ntw-ext@2026-11-02.yang" module ietf-l3vpn-ntw-ext { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw-ext"; prefix l3nm-ext; import ietf-l3vpn-ntw { prefix l3nm; reference "RFC 9182: A YANG Network Data Model for Layer 3 VPNs"; } 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"; } import ietf-schedule { prefix schedule; reference "RFC 9922: A Common YANG Data Model for Scheduling"; } organization "IETF ONSEN Working Group"; contact "WG Web: WG List: Editor: Cancan Huang Huang & Xie Expires 2 May 2027 [Page 20] Internet-Draft L3NM Service Extensions November 2026 Chongfeng Xie "; description "This YANG module defines extensions to the L3VPN Network Model (L3NM) to support enhanced service features: time-scheduled networking provisioning, time-scheduled bandwidth adjustment, QoS enhancements (isolation, unified traffic classification, and time-scheduled QoS action rules), performance monitoring, and quantum-safe encryption. 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2026-11-02 { description "Time-scheduled QoS action rules added; dynamic-* constructs renamed to time-scheduled-*; ietf-schedule grouping reference fixed to icalendar-recurrence; BCP 14 boilerplate added; period and recurrence schedule branches wrapped in containers to avoid a duplicate 'time-zone-identifier' leaf (validation feedback)."; reference "RFC XXXX: Extensions to the YANG Network Data Model for L3VPN"; } /* Features */ Huang & Xie Expires 2 May 2027 [Page 21] Internet-Draft L3NM Service Extensions November 2026 feature time-scheduled-l3vpn { description "Support for time-scheduled L3VPN service provisioning: dynamic service requirements realized as time-scheduled resource reservations."; } feature time-scheduled-networking { if-feature time-scheduled-l3vpn; description "Support for time-scheduled networking provisioning: scheduled activation and deactivation of VPN connectivity."; } feature time-scheduled-bandwidth-adjustment { if-feature time-scheduled-l3vpn; description "Support for time-scheduled bandwidth adjustment: temporary, scheduled bandwidth scaling on top of a persistent baseline bandwidth."; } feature unified-classification { description "Support for unified traffic classification policies defined outside the 'qos' container and reusable across functional modules."; } feature qos-isolation { description "Support for binding isolation requirements to QoS classes."; } feature perf-mon { description "Support for end-to-end performance monitoring between VPN nodes."; } feature perf-mon-custom { if-feature perf-mon; description "Support for custom (service-specific) performance monitoring configuration."; } feature post-quantum-encryption { description "Support for post-quantum encryption."; } Huang & Xie Expires 2 May 2027 [Page 22] Internet-Draft L3NM Service Extensions November 2026 feature pqc { if-feature post-quantum-encryption; description "Support for Post-Quantum Cryptography (PQC)."; } feature qkd { if-feature post-quantum-encryption; description "Support for Quantum Key Distribution (QKD)."; } /* Identities */ identity application-base { description "Base identity for application identification used in traffic classification."; } identity isolation-level-base { description "Base identity for isolation levels. Definitions are aligned with the IETF network slice NBI YANG data model."; } identity isolation-dedicated { base isolation-level-base; description "Dedicated isolation: the service is not impacted by the existence of other customers or services in the same network."; } identity isolation-shared { base isolation-level-base; description "Shared (logical) isolation."; } identity failure-action-base { description "Base identity for actions executed when the validity conditions for post-quantum encryption are not met."; } identity failure-fallback-conventional { base failure-action-base; description "Fall back to conventional cryptography."; } Huang & Xie Expires 2 May 2027 [Page 23] Internet-Draft L3NM Service Extensions November 2026 identity failure-terminate { base failure-action-base; description "Terminate the encryption service."; } identity pm-status-base { description "Base identity for performance monitoring session operational status."; } identity pm-up { base pm-status-base; description "The monitoring session is operating normally."; } identity pm-degraded { base pm-status-base; description "The monitoring session is partially operating."; } identity pm-down { base pm-status-base; description "The monitoring session is not operating."; } identity pqc-status-base { description "Base identity for PQC encryption operational status."; } identity pqc-active { base pqc-status-base; description "PQC encryption is active."; } identity pqc-inactive { base pqc-status-base; description "PQC encryption is not active."; } identity pqc-error { base pqc-status-base; description "PQC encryption is in an error state."; } Huang & Xie Expires 2 May 2027 [Page 24] Internet-Draft L3NM Service Extensions November 2026 identity qkd-status-base { description "Base identity for QKD encryption operational status."; } identity qkd-active { base qkd-status-base; description "QKD encryption is active."; } identity qkd-inactive { base qkd-status-base; description "QKD encryption is not active."; } identity qkd-error { base qkd-status-base; description "QKD encryption is in an error state."; } /* Groupings */ grouping classification-policy-grouping { description "A reusable, ordered set of traffic classification rules that generate 'class-id' values for cross-module reuse (e.g., by 'qos' and 'security')."; list classification-policy { key "rule-id"; description "List of classification rules."; leaf rule-id { type string; description "Unique identifier of the classification rule."; } choice match-type { description "Classification can be based on flow fields or on application identification."; case match-flow { description "Match on packet header fields."; leaf dscp { type inet:dscp; description "Match on the DSCP value."; } leaf dot1p { type uint8; description Huang & Xie Expires 2 May 2027 [Page 25] Internet-Draft L3NM Service Extensions November 2026 "Match on the IEEE 802.1 priority value."; } leaf protocol-field { type uint8; description "Match on the IP protocol field."; } leaf ipv4-src-prefix { type inet:ipv4-prefix; description "Match on the IPv4 source prefix."; } leaf ipv4-dst-prefix { type inet:ipv4-prefix; description "Match on the IPv4 destination prefix."; } leaf ipv6-src-prefix { type inet:ipv6-prefix; description "Match on the IPv6 source prefix."; } leaf ipv6-dst-prefix { type inet:ipv6-prefix; description "Match on the IPv6 destination prefix."; } leaf l4-src-port { type inet:port-number; description "Match on the Layer 4 source port."; } leaf l4-dst-port { type inet:port-number; description "Match on the Layer 4 destination port."; } container l4-src-port-range { description "Match on a Layer 4 source port range."; leaf lower-port { type inet:port-number; description "Lower boundary of the port range."; } leaf upper-port { type inet:port-number; description "Upper boundary of the port range."; } } container l4-dst-port-range { description "Match on a Layer 4 destination port range."; Huang & Xie Expires 2 May 2027 [Page 26] Internet-Draft L3NM Service Extensions November 2026 leaf lower-port { type inet:port-number; description "Lower boundary of the port range."; } leaf upper-port { type inet:port-number; description "Upper boundary of the port range."; } } } case match-application { description "Match on an identified application."; leaf match-application { type identityref { base application-base; } description "Identifies the application to match."; } } } leaf target-class-id { type string; description "The class identifier generated by this rule. Other functional modules (e.g., 'qos', 'security') reference this value to handle the classified traffic."; } } } grouping time-schedule { description "A set of schedules expressed as period-based or iCalendar-recurrence time slots, together with the actual activation timestamps reported by the network."; list schedule { key "schedule-id"; description "List of schedule entries."; leaf schedule-id { type string; description "Unique identifier of the schedule entry."; } choice schedule-type { description "The schedule can be a single period of time or a recurring schedule."; case period { Huang & Xie Expires 2 May 2027 [Page 27] Internet-Draft L3NM Service Extensions November 2026 description "A period-based schedule."; container period { description "A period-based schedule, as defined by the 'period-of-time' grouping of [RFC9922]."; uses schedule:period-of-time; } } case recurrence { description "A recurring schedule based on iCalendar recurrence rules."; container recurrence { description "A recurring schedule, as defined by the 'icalendar-recurrence' grouping of [RFC9922]."; uses schedule:icalendar-recurrence; } } } leaf actual-start-time { type yang:date-and-time; config false; description "Reports the actual date and time when the service was activated. The offset against the requested start time represents the actual provisioning delay."; } leaf actual-stop-time { type yang:date-and-time; config false; description "Reports the actual date and time when the service was deactivated."; } } } /* Augmentations */ augment "/l3nm:l3vpn-ntw/l3nm:vpn-profiles" + "/l3nm:valid-provider-identifiers" { description "Adds profile identifier lists for enhanced service features."; list bandwidth-adjustment-profile-identifier { key "id"; description "List of bandwidth adjustment profile identifiers, e.g., the maximum allowed bandwidth after adjustment."; Huang & Xie Expires 2 May 2027 [Page 28] Internet-Draft L3NM Service Extensions November 2026 leaf id { type string; description "Identifier of the bandwidth adjustment profile."; } } list provisioning-delay-profile-identifier { key "id"; description "List of provisioning-delay SLO profile identifiers."; leaf id { type string; description "Identifier of the provisioning-delay profile."; } } list perf-mon-profile-identifier { key "id"; description "List of performance monitoring profile identifiers."; leaf id { type string; description "Identifier of the performance monitoring profile."; } } } augment "/l3nm:l3vpn-ntw/l3nm:vpn-services" + "/l3nm:vpn-service/l3nm:vpn-nodes/l3nm:vpn-node" { description "Adds node-level unified traffic classification and performance monitoring."; uses classification-policy-grouping { if-feature unified-classification; } container perf-mon { if-feature perf-mon; description "End-to-end performance monitoring from this VPN node towards selected target VPN nodes."; leaf enable { type boolean; default "false"; description "Enables performance monitoring."; } container monitoring { description "Monitoring configuration and state."; list monitor { key "target-vpn-node-id"; description "One monitoring session per target VPN node. Huang & Xie Expires 2 May 2027 [Page 29] Internet-Draft L3NM Service Extensions November 2026 For a spoke VPN node, only hub VPN nodes may be selected as targets; for hub or any-to-any topologies, all other VPN nodes of the same VPN service may be selected."; leaf target-vpn-node-id { type leafref { path "/l3nm:l3vpn-ntw/l3nm:vpn-services" + "/l3nm:vpn-service/l3nm:vpn-nodes" + "/l3nm:vpn-node/l3nm:vpn-node-id"; } description "The target VPN node of the monitoring session."; } container measurement-profile { description "The measurement configuration."; choice profile-type { description "Standard (predefined) or custom configuration."; case standard { description "Reference to a pre-provisioned performance monitoring profile."; leaf profile-id { type leafref { path "/l3nm:l3vpn-ntw/l3nm:vpn-profiles" + "/l3nm:valid-provider-identifiers" + "/l3nm-ext:perf-mon-profile" + "-identifier/l3nm-ext:id"; } description "Reference to a performance monitoring profile."; } } case custom { description "Custom monitoring configuration."; leaf measurement-interval { if-feature perf-mon-custom; type uint32; units "seconds"; description "The performance measurement interval."; } } } } leaf status { type identityref { base pm-status-base; } Huang & Xie Expires 2 May 2027 [Page 30] Internet-Draft L3NM Service Extensions November 2026 config false; description "Operational status of the monitoring session."; } container metrics { config false; description "Service-level performance metrics for the monitoring session."; leaf one-way-min-delay { type yang:gauge64; units "microseconds"; description "Minimum one-way delay."; } leaf one-way-max-delay { type yang:gauge64; units "microseconds"; description "Maximum one-way delay."; } leaf one-way-delay-variation { type yang:gauge64; units "microseconds"; description "One-way delay variation."; } 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 "Minimum two-way delay."; } leaf two-way-max-delay { type yang:gauge64; units "microseconds"; description "Maximum two-way delay."; } leaf two-way-delay-variation { type yang:gauge64; units "microseconds"; description "Two-way delay variation."; } leaf two-way-packet-loss { Huang & Xie Expires 2 May 2027 [Page 31] Internet-Draft L3NM Service Extensions November 2026 type decimal64 { fraction-digits 4; } description "Two-way packet loss ratio."; } } } } } } augment "/l3nm:l3vpn-ntw/l3nm:vpn-services" + "/l3nm:vpn-service/l3nm:vpn-nodes/l3nm:vpn-node" + "/l3nm:vpn-network-accesses" + "/l3nm:vpn-network-access" { description "Adds access-level unified traffic classification."; uses classification-policy-grouping { if-feature unified-classification; } } augment "/l3nm:l3vpn-ntw/l3nm:vpn-services" + "/l3nm:vpn-service/l3nm:vpn-nodes/l3nm:vpn-node" + "/l3nm:vpn-network-accesses" + "/l3nm:vpn-network-access/l3nm:service" { description "Adds time-scheduled L3VPN service provisioning capabilities."; container time-scheduled-l3vpn { if-feature time-scheduled-l3vpn; description "Groups all parameters associated with time-scheduled service provisioning."; choice time-scheduled-type { description "The type of time-scheduled L3VPN service. The types are mutually exclusive for a given VPN network access."; case time-scheduled-networking { description "Scheduled activation and deactivation of VPN connectivity."; leaf provisioning-delay-profile-id { if-feature time-scheduled-networking; type leafref { path "/l3nm:l3vpn-ntw/l3nm:vpn-profiles" + "/l3nm:valid-provider-identifiers" + "/l3nm-ext:provisioning-delay-profile" + "-identifier/l3nm-ext:id"; } description "Reference to a provisioning-delay SLO Huang & Xie Expires 2 May 2027 [Page 32] Internet-Draft L3NM Service Extensions November 2026 profile. The SLO quantifies the allowed offset between the requested-start and actual-start timestamps of the VPN connection."; } container networking-schedule { description "The time slots during which the VPN connectivity shall be activated."; uses time-schedule; } } case time-scheduled-bandwidth-adjustment { description "Temporary bandwidth scaling on top of the baseline bandwidth."; leaf bandwidth-adjustment-profile-id { if-feature time-scheduled-bandwidth-adjustment; type leafref { path "/l3nm:l3vpn-ntw/l3nm:vpn-profiles" + "/l3nm:valid-provider-identifiers" + "/l3nm-ext:bandwidth-adjustment-profile" + "-identifier/l3nm-ext:id"; } description "Reference to a bandwidth adjustment profile, e.g., indicating the maximum allowed bandwidth after adjustment."; } leaf temporary-pe-to-ce-bandwidth { if-feature time-scheduled-bandwidth-adjustment; type uint64; units "bps"; description "The desired temporary PE-to-CE bandwidth after adjustment. This is an absolute value, not a delta offset from the baseline bandwidth."; } leaf temporary-ce-to-pe-bandwidth { if-feature time-scheduled-bandwidth-adjustment; type uint64; units "bps"; description "The desired temporary CE-to-PE bandwidth after adjustment. This is an absolute value, not a delta offset from the baseline bandwidth."; } container bandwidth-adjustment-schedule { description "The time slots during which the temporary bandwidth applies."; uses time-schedule; Huang & Xie Expires 2 May 2027 [Page 33] Internet-Draft L3NM Service Extensions November 2026 } } } } } augment "/l3nm:l3vpn-ntw/l3nm:vpn-services" + "/l3nm:vpn-service/l3nm:vpn-nodes/l3nm:vpn-node" + "/l3nm:vpn-network-accesses" + "/l3nm:vpn-network-access/l3nm:service" + "/l3nm:qos/l3nm:qos-action/l3nm:rule" { description "Adds isolation requirements and activation schedules to QoS action rules."; leaf-list isolation { if-feature qos-isolation; type identityref { base isolation-level-base; } description "Isolation requirements bound to the traffic class targeted by this QoS action rule, e.g., for delivery over IETF network slices."; } container qos-schedule { if-feature time-scheduled-l3vpn; description "The time slots during which this QoS action rule is active. When no schedule is present, the rule is active immediately upon configuration commit."; uses time-schedule; } } augment "/l3nm:l3vpn-ntw/l3nm:vpn-services" + "/l3nm:vpn-service/l3nm:vpn-nodes/l3nm:vpn-node" + "/l3nm:vpn-network-accesses" + "/l3nm:vpn-network-access/l3nm:security" { description "Adds fine-grained per-class encryption including post-quantum options."; container classes { description "Per-class encryption policies. Each class is keyed by a 'class-id' generated by a classification policy applied to this VPN network access or to the enclosing VPN node."; list class { key "class-id"; description "Encryption policy for one traffic class."; leaf class-id { type string; description Huang & Xie Expires 2 May 2027 [Page 34] Internet-Draft L3NM Service Extensions November 2026 "Identifies the traffic class. The value MUST correspond to a 'target-class-id' generated by a 'classification-policy'."; } leaf algorithm { type string; description "The encryption algorithm applied to this traffic class."; } choice key-type { description "The type of keying."; case psk { description "Use of a pre-shared key."; leaf pre-shared-key { type string; description "The pre-shared key."; } } } container post-quantum-encryption { if-feature post-quantum-encryption; description "Aggregates all configuration items associated with post-quantum encryption."; container post-quantum-policy { description "Availability and failover policy for post-quantum encryption."; leaf pqc-only-acceptable { type boolean; description "If true, post-quantum communication is maintained when only PQC is available. If false, execute the 'failure-action'."; } leaf qkd-only-acceptable { type boolean; description "If true, post-quantum communication is maintained when only QKD is available. If false, execute the 'failure-action'."; } leaf failure-action { type identityref { base failure-action-base; } description "The action executed when the validity conditions for post-quantum encryption are not met."; Huang & Xie Expires 2 May 2027 [Page 35] Internet-Draft L3NM Service Extensions November 2026 } } container pqc { if-feature pqc; description "Aggregates all items associated with PQC."; leaf enable { type boolean; default "false"; description "Enables PQC."; } leaf algorithm { type string; description "The PQC algorithm."; } leaf pqc-status { type identityref { base pqc-status-base; } config false; description "Operational status of PQC encryption."; } } container qkd { if-feature qkd; description "Aggregates all items associated with QKD-based encryption."; leaf enable { type boolean; default "false"; description "Enables QKD-based encryption."; } leaf qkd-status { type identityref { base qkd-status-base; } config false; description "Operational status of QKD encryption."; } leaf qkd-key-pool-id { type string; description "Identifier of a QKD key pool managed by the QKD key management entity (KME). Identical values shall be configured on both endpoints of any QKD link."; } leaf key-refresh-interval { Huang & Xie Expires 2 May 2027 [Page 36] Internet-Draft L3NM Service Extensions November 2026 type uint32; units "seconds"; description "Time interval for automatic refresh of quantum keys stored in the key pool."; } } } } } } } 7. IANA Considerations This document requests IANA to register the following URI in the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw-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 [RFC6020]: Name: ietf-l3vpn-ntw-ext Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw-ext Prefix: l3nm-ext Reference: RFC XXXX 8. Security Considerations The extensions defined in this document inherit the security considerations of [RFC9182]. The YANG module defined in this document is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Additional considerations specific to the extensions are: Huang & Xie Expires 2 May 2027 [Page 37] Internet-Draft L3NM Service Extensions November 2026 * Time-scheduled provisioning mechanisms MUST be secured using mutual authentication and integrity protection. * Schedule parameters drive automatic activation and deactivation of VPN connectivity and bandwidth. Write access to these nodes SHOULD be restricted to authorized entities; tampering with schedules could disrupt customer services or exhaust network resources. * Quantum encryption parameters (e.g., "pre-shared-key", "qkd-key-pool-id") are sensitive; access to these configuration nodes SHOULD be restricted to authorized administrators. * Communication between orchestrators and network controllers SHOULD use TLS 1.3 or equivalent encryption. * Time-scheduled networking capabilities require appropriate security mechanisms to prevent the establishment of L3VPN connectivity with untrusted peers. The specific implementation details of the mutual trust mechanisms are out of scope. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8299] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018, . Huang & Xie Expires 2 May 2027 [Page 38] Internet-Draft L3NM Service Extensions November 2026 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC9181] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., and Q. Wu, "A Common YANG Data Model for Layer 2 and Layer 3 VPNs", RFC 9181, DOI 10.17487/RFC9181, February 2022, . [RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182, February 2022, . [RFC9922] Ma, B., Yang, Y., Rahman, R., and J. Schoenwaelder, "A Common YANG Data Model for Scheduling", RFC 9922, DOI 10.17487/RFC9922, March 2026, . 9.2. Informative References [ETSI-GR-QKD-007] ETSI, "Quantum Key Distribution (QKD); Vocabulary", ETSI GR QKD 007, . [I-D.fu-onsen-update-l3sm-service-models] Fu, F., Huang, C., and B. Wu, "Extensions to the YANG Data Model for L3VPN Service Delivery", Work in Progress, Internet-Draft, draft-fu-onsen-update-l3sm-service- models-03, 15 October 2026. [I-D.ietf-teas-ietf-network-slice-nbi-yang] Wu, B., Dhody, D., Farrel, A., Saad, T., and J. Dong, "A YANG Data Model for the IETF Network Slice Service", Work in Progress, Internet-Draft, draft-ietf-teas-ietf- network-slice-nbi-yang. [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . Huang & Xie Expires 2 May 2027 [Page 39] Internet-Draft L3NM Service Extensions November 2026 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and L. Geng, "A Framework for Automating Service and Network Management with YANG", RFC 8969, DOI 10.17487/RFC8969, January 2021, . [RFC9375] Wu, B., Ed., Wu, Q., Ed., Boucadair, M., Gonzalez de Dios, O., and B. Wen, "A YANG Data Model for Network and VPN Service Performance Monitoring", RFC 9375, DOI 10.17487/RFC9375, April 2023, . [RFC9833] Boucadair, M., Ed., "A Common YANG Data Model for Attachment Circuits", RFC 9833, DOI 10.17487/RFC9833, September 2025, . [RFC9834] Boucadair, M., Ed., "A YANG Data Model for Ethernet Transport Bearer Services", RFC 9834, DOI 10.17487/RFC9834, October 2025, . [RFC9958] Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek, T., and M. Ounsworth, "Post-Quantum Cryptography for Engineers", RFC 9958, DOI 10.17487/RFC9958, June 2026, . Appendix A. Data Model Examples A.1. Configuration of Time-Scheduled Networking Service The following example configures a VPN network access to be activated every workday from 09:00 to 18:00 (UTC+8), with a reference to the provisioning-delay profile "delay-gold". Huang & Xie Expires 2 May 2027 [Page 40] Internet-Draft L3NM Service Extensions November 2026 { "ietf-l3vpn-ntw:l3vpn-ntw": { "vpn-services": { "vpn-service": [ { "vpn-id": "VRF-DATA-TRANSFER", "vpn-nodes": { "vpn-node": [ { "vpn-node-id": "PE1-SITE1", "vpn-network-accesses": { "vpn-network-access": [ { "id": "eth1", "service": { "ietf-l3vpn-ntw-ext:time-scheduled-l3vpn": { "provisioning-delay-profile-id": "delay-gold", "networking-schedule": { "schedule": [ { "schedule-id": "workday-9-18", "recurrence": { "frequency": "ietf-schedule:daily", "interval": 1 } } ] } } } } ] } } ] } } ] } } } A.2. Configuration of Time-Scheduled Bandwidth Adjustment The following example schedules a temporary CE-to-PE bandwidth increase to 10 Gbps (baseline 1 Gbps) for a data transmission window on 15 December 2026. Huang & Xie Expires 2 May 2027 [Page 41] Internet-Draft L3NM Service Extensions November 2026 { "ietf-l3vpn-ntw:l3vpn-ntw": { "vpn-services": { "vpn-service": [ { "vpn-id": "VRF-AI-TRAINING", "vpn-nodes": { "vpn-node": [ { "vpn-node-id": "PE1-SITE1", "vpn-network-accesses": { "vpn-network-access": [ { "id": "eth2", "service": { "pe-to-ce-bandwidth": 1000000000, "ce-to-pe-bandwidth": 1000000000, "ietf-l3vpn-ntw-ext:time-scheduled-l3vpn": { "bandwidth-adjustment-profile-id": "bw-max-10g", "temporary-pe-to-ce-bandwidth": 10000000000, "temporary-ce-to-pe-bandwidth": 10000000000, "bandwidth-adjustment-schedule": { "schedule": [ { "schedule-id": "ai-job-01", "period": { "period-start": "2026-12-15T02:00:00+08:00", "period-end": "2026-12-15T06:00:00+08:00" } } ] } } } } ] } } ] } } ] } } } A.3. Performance Monitoring Huang & Xie Expires 2 May 2027 [Page 42] Internet-Draft L3NM Service Extensions November 2026 The following example enables performance monitoring from a spoke VPN node towards the hub VPN node "PE-HUB" with a custom measurement interval of 60 seconds. { "ietf-l3vpn-ntw-ext:perf-mon": { "enable": true, "monitoring": { "monitor": [ { "target-vpn-node-id": "PE-HUB", "measurement-profile": { "measurement-interval": 60 } } ] } } } A.4. Configuration of Post-Quantum Security Service The following example encrypts the traffic class "gold" with PQC (algorithm "ML-KEM-1024") combined with QKD, falling back to conventional cryptography if both become unavailable. { "ietf-l3vpn-ntw-ext:classes": { "class": [ { "class-id": "gold", "post-quantum-encryption": { "post-quantum-policy": { "pqc-only-acceptable": true, "qkd-only-acceptable": true, "failure-action": "ietf-l3vpn-ntw-ext:failure-fallback-conventional" }, "pqc": { "enable": true, "algorithm": "ML-KEM-1024" }, "qkd": { "enable": true, "qkd-key-pool-id": "pool-pe1-pe2", "key-refresh-interval": 3600 } } } ] } } Huang & Xie Expires 2 May 2027 [Page 43] Internet-Draft L3NM Service Extensions November 2026 Acknowledgments The authors would like to thank Chongfeng Xie for his valuable comments. The extensions defined in this document mirror the service-layer capabilities defined in draft-fu-onsen-update-l3sm-service-models; thanks to the contributors of that document. Authors' Addresses Cancan Huang China Telecom Email: huangcanc@chinatelecom.cn Chongfeng Xie China Telecom Email: xiechf@chinatelecom.cn Huang & Xie Expires 2 May 2027 [Page 44]