Extensions to the YANG Data Model for L3VPN Service Delivery
draft-fu-onsen-update-l3sm-service-models-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Fengchao Fu , Cancan Huang , Bo Wu | ||
| Last updated | 2026-07-05 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-fu-onsen-update-l3sm-service-models-02
ONSEN Working Group F. Fu
Internet-Draft C. Huang
Intended status: Informational China Telecom
Expires: 6 January 2027 B. Wu
Huawei
5 July 2026
Extensions to the YANG Data Model for L3VPN Service Delivery
draft-fu-onsen-update-l3sm-service-models-02
Abstract
RFC8299 defines a YANG data model for L3VPN service delivery. This
document defines a set of extensions that address the limitations of
the L3VPN Service Model (L3SM). The extensions enable (1)dynamic
network provisioning with temporary connectivity, (2) dynamic
bandwidth adjustment, (3) integration of isolation in Slice Service
Templates to enhance QoS provisioning, (4) performance monitoring for
enriching service quality visibility, (5)quantum-safe encryption
integrating both PQC and QKD.
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 6 January 2027.
Copyright Notice
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
Fu, et al. Expires 6 January 2027 [Page 1]
Internet-Draft Extensions to L3SM July 2026
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. Status of This Memo . . . . . . . . . . . . . . . . . . . . . 2
2. Copyright Notice . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Service Data Model Usage . . . . . . . . . . . . . . . . . . 5
6. Overall Structure of the Extended L3VPN Service Module . . . 6
6.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 6
6.2. L3SM Augmentations Description for extended-L3VPN
Requirements . . . . . . . . . . . . . . . . . . . . . . 9
6.2.1. Dynamic networking provisioning . . . . . . . . . . . 9
6.2.2. Dynamic bandwidth adjustment . . . . . . . . . . . . 12
6.2.3. Enhanced qos . . . . . . . . . . . . . . . . . . . . 15
6.2.4. Performance Monitoring . . . . . . . . . . . . . . . 18
6.2.5. Enhanced security . . . . . . . . . . . . . . . . . . 19
7. Extended L3SM YANG Module . . . . . . . . . . . . . . . . . . 22
8. Service Model Usage Example . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Dynamic-L3VPN service provisioning and lifecycle
procedure . . . . . . . . . . . . . . . . . . . . . . . . 24
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. 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. The list of
current Internet-Drafts is at https://datatracker.ietf.org/drafts/
current/. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 January 2027.
Fu, et al. Expires 6 January 2027 [Page 2]
Internet-Draft Extensions to L3SM July 2026
2. Copyright Notice
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.
3. Introduction
RFC 8299 defines the Layer 3 VPN Service Model (L3SM), which provides
a customer-facing abstraction for Layer 3 VPN services. L3SM assumes
relatively static service characteristics: persistent connectivity
between fixed sites with bandwidth parameters specified at service
creation time.
Operational experience with data-intensive workloads (e.g., large-
scale data transfer, temporary compute clusters) has identified
requirements not addressed by the base L3SM model:
* Dynamic network provisioning: The ability to establish and tear
down connectivity on demand, rather than maintaining persistent
connections. Conventional L3VPN services must perform frequent
network reconfigurations to support such dynamic networking.
Frequent reconfigurations for dynamic networking may introduce
potential risks to network stability and are generally
unacceptable for network operations.
* Dynamic bandwidth adjustment: The ability to modify bandwidth
allocations within specific provisioning delay.
These operational requirements create corresponding gaps in the
service model. Furthermore, large-scale SRv6 deployments expose
additional technical limitations in the original L3SM data model:
1. L3SM does not support temporary connectivity with explicit
activation/deactivation time windows.
2. L3SM does not provide parameters for bandwidth adjustment with
spefic bandwidth adjustment ranges and adjustment time
constraints.
Fu, et al. Expires 6 January 2027 [Page 3]
Internet-Draft Extensions to L3SM July 2026
3. L3SM lacks integration with network slicing constructs required
to deliver differentiated service tiers over SRv6 transport.
4. L3SM lacks support for performance monitoring, limiting end-to-
end service quality visibility.
5. L3SM does not provide parameters for quantum-safe encryption.
6. Most of the existing L3SM functional modules (eg., qos, security)
are configured under site and site-network-access nodes, without
unified global VPN-service settings. This results in extensive
duplicated configurations across individual sites and increases
overall operational complexity.
This document defines YANG augmentations to RFC 8299 to address these
gaps. The extensions are designed to be backward compatible:
implementations that do not require these capabilities can ignore the
new parameters.
The scope of this document is limited to service model extensions.
Implementation details of underlying mechanisms (e.g., signaling
protocols, encryption algorithms, security mechanisms ) are out of
scope.
4. Terminology
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 [RFC2119] and [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses the following terms:
AC: Attachment Circuit, as defined in [RFC9833].
CE: Customer Edge, as defined in [RFC4026].
COA: Change of Authorization, as defined in [RFC5176].
Dynamic-L3VPN: A Layer 3 VPN service supporting dynamic network
provisioning and/or dynamic bandwidth adjustment.
L3SM: Layer 3 VPN Service Model, as defined in [RFC8299].
L3VPN: Layer 3 Virtual Private Network, as defined in [RFC4026].
PE: Provider Edge, as defined in [RFC4026].
Fu, et al. Expires 6 January 2027 [Page 4]
Internet-Draft Extensions to L3SM July 2026
PQC:Post Quantum Cryptography.
QKD:Quantum key distribution.
Slice Service Template (SST): A reusable policy container defining
Service Level Objectives (SLOs) and Service Level Expectations (SLEs)
for network slices, as defined in [I-D.ietf-teas-ietf-network-slice-
nbi-yang].
5. Service Data Model Usage
The L3VPN service model defined in [RFC8299] provides a service-level
abstraction for L3VPN services, decoupling service intent from device
configuration. The extensions in this document follow the same
service data model usage as the base L3VPN Service Model (L3SM). A
typical scenario is also to use this model as input to an
orchestration layer responsible for translating service intent into
device configurations. An example of extended L3VPN service delivery
is shown in Figure 1.
The main difference is that these extensions introduce additional
service-level attributes and policy constructs to support newer, more
dynamic service delivery models.
The usage of this service model is not limited to this example. The
extended data model continues to be applicable for any component of
management systems and northbound consumers, but not directly by
network elements.
Fu, et al. Expires 6 January 2027 [Page 5]
Internet-Draft Extensions to L3SM July 2026
+----------+
| Customer |
+-----+----+
|
L3vpn-svc-ext |
Models |
+-------+-------+
| Service |
| Orchestrator |
+-------+-------+
|
Network Models |
|
+-------+-----+
| Network |
| Controller |
+-----+-+-+---+
Device | | |
Configuration | | |
Models | | |
+---------------+ | +-----------+
| +----------+-------+ | +---------+
+--+--+ | | | | |
| CE1 +---+ +-----+ +----+ | +--+--+-+ |
+-----+ | | PE1 | |PE2 | +--+ DC-GW | DC |
+-----+ | +-----+ +----+ | +-----+-+ |
| CE2 +---+ | | |
+-----+ +------------------+ +---------+
Figure 1: Extended L3VPN Service Delivery Example
6. Overall Structure of the Extended L3VPN Service Module
6.1. Tree Structure
The extensions are defined in the module ietf-l3vpn-svc-ext, which
augments the base L3SM module (ietf-l3vpn-svc) at the following
locations:
* /l3vpn-svc/vpn-profiles: Adds profiles for bandwidth adjustment
ranges, provisioning delay SLOs and performance monitoring
policies. All such profiles are predefined and standardized by
the provider and the provider can propose these profiles to the
customer.
Fu, et al. Expires 6 January 2027 [Page 6]
Internet-Draft Extensions to L3SM July 2026
* /l3vpn-svc/vpn-services/vpn-service: Adds four containers
(dynamic-attribute container, qos container, perf-mon container,
security container) for globle VPN service configuration that
apply across all sites.
* /l3vpn-svc/sites/site: Traffic classification policies defined in
[RFC8299] are nested solely under the QOS container and cannot be
reused by other functional modules, resulting in insufficient
flexibility. Adds a site-level unified classification-policy
container that defines a set of ordered rules to classify customer
traffic and generates a set of class-id values, which can be
reused accross various service functions modules including QoS,
security, and performance monitoring. When different modules
process identical traffic flows, they adopt the same class-id
values to match traffic. When different modules process distinct
traffic flows, they adopt different class-id values to match
traffic. Add site-level functional containers (dynamic-attribute
container, qos container, perf-mon container, security container).
When a site carries service requirements that cannot be fully
covered by the global vpn-service settings, relevant parameters
may be configured within the containers under the corresponding
site node.
* /l3vpn-svc/sites/site/site-network-accesses/site-network-access/
service: Add site-network-access-level functional containers
(dynamic-attribute container, qos container, perf-mon container,
security container) . When a site-network-access carries service
requirements that cannot be fully covered by the site-level vpn-
service settings, relevant parameters may be configured within the
containers under the corresponding site-network-access node.
The parameter inheritance mechanism defined in [RFC8299] for site-
level and site-network-access-level nodes also applies to this
document. Furthermore, this document additionally introduce an
inheritance mechanism at the global vpn-service level. Overall, this
document defines a three-level hierarchy for service configuration.
Some parameters can be configured at vpn-service level, the site
level and the site-network-access level, e.g., services, security.
Inheritance applies when parameters are defined at the vpn-service
level and site level. If a parameter is configured at the global
vpn-service level, the site-level parameter MUST override the global
vpn-service parameter. If a parameter is configured at the site-
level, and the access-level parameter MUST override the site-level
parameter. Those parameters will be described later in this
document.
Figure 2 illustrates the module augmentation tree structure.
Fu, et al. Expires 6 January 2027 [Page 7]
Internet-Draft Extensions to L3SM July 2026
module: ietf-l3vpn-svc-ext
augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-profiles
/l3vpn-svc:valid-provider-identifiers:
| ...
augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-service:
+--rw dynamic-attribute
| ...
+--rw qos {qos}?
| ....
+--rw perf-mon {perf-mon}?
| ...
+--rw security
| ...
augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site:
+--rw classification-policy* [rule-id]
| ...
+--rw dynamic-attribute
| ...
+--rw qos {qos}?
| ....
+--rw perf-mon {perf-mon}?
| ...
+--rw security
| ...
augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
/l3vpn-svc:site-network-accesses
/l3vpn-svc:site-network-access:
+--rw classification-policy* [rule-id]
| ...
+--rw dynamic-attribute
| ...
+--rw qos {qos}?
| ....
+--rw perf-mon {perf-mon}?
| ...
+--rw security
| ...
Figure 2: Augmentation Tree Structure
Fu, et al. Expires 6 January 2027 [Page 8]
Internet-Draft Extensions to L3SM July 2026
6.2. L3SM Augmentations Description for extended-L3VPN Requirements
6.2.1. Dynamic networking provisioning
Requirement:
* Customers with workloads including, but not limited to, data
computation offloaded to cloud DCs, periodic data circulation for
audit or other purpose and temporary event organization demand
task-based connectivity: VPN tunnels are set up only when data
transmission tasks start and torn down upon task completion. This
avoids the extra costs incurred by persistent long-term VPN
subscriptions from operators.
* Customers require connection provisioning latency to be provided
as an SLO attribute, which quantifies the time offset between the
requested-start and actual-start timestamps.
Gap in [RFC8299]: L3SM assumes persistent connectivity; it doesn't
provide parameters to specify the requested-start time and requested-
stop time of AC connections or activation time constraints.
Gap in [RFC9834]: The ietf-bearer-svc data yang model defined in
[RFC9834] provides the requested-start and requested-stop nodes to
specify the expected activation and deactivation date and time of a
bearer; but it lacks nodes to indicate whether the connection remains
always-on throughout the requested period. In certain scenarios, the
connection does not operate in always-on mode over the requested time
window; its activation is limited to specific time slots on
designated calendar days. A list-type node for L3VPN activation
times shall be provided to allow customers to specify multiple
connection periods in a single configuration.
Extensions:
In L3SM, a site refers to a physical location and associated customer
premises equipment. AC represents a logical VPN access channel
provided by the operator for customers. After configured by the
operator, an AC can be bound to a VPN instance to implement end-to-
end VPN networking services. From operational practice,sites are
typically static and seldom rebuilt or dismantled, while logic access
links may be established and bounded to VPN instanceon demand. As an
implementation example, dynamic networking mainly refers to the on-
demand establishment, association and teardown of ACs. This document
is not limited to any specific implementation approach.
Fu, et al. Expires 6 January 2027 [Page 9]
Internet-Draft Extensions to L3SM July 2026
This YANG data model defines support for on-demand establishment,
association and release of VPN connectivity , with specified
provisioning delay constraints. The detailed implementation
mechanisms for fast activation and deactivation of L3VPN connections
are implementation-specific and out of scope of this document.
Figure 3 illustrates the module augmentation subtree structure of
dynamic networking.
augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
/l3vpn-svc:site-network-accesses
/l3vpn-svc:site-network-access:
+--rw service
| +--rw requested-start? yang:date-and-time
| when "../dynamic-attribute/always-on = true";
| +--rw requested-stop? yang:date-and-time
| when "../dynamic-attribute/always-on = true";
| +--rw svc-input-bandwidth uint64
| +--rw svc-output-bandwidth uint64
| +--rw dynamic-attribute /
{dynamic networking and/or bandwidth adjustment}
| | +--rw always-on? boolean
| | +--rw active-networking-policy {not-always-on}?
| | +--rw connection-provisioning-delay-ref? leafref
| | +--rw (policy-mode)
| | +--:(immediate)
| | | +--rw duration-hours uint16
| | | +--ro actual-start-time yang:date-and-time
| | | +--ro actual-stop-time yang:date-and-time
| | +--:(scheduled)
| | +--rw time-period* [period-id]
| | +--rw period-id string
| | +--rw date-list* [date-id]
| | +--rw date-id string
| | +--rw target-date yang:date
| | +--rw time-slot* [slot-id]
| | +--rw slot-id string
| | +--rw start-time yang:time-of-day
| | +--rw stop-time yang:time-of-day
| | +--ro actual-start-time yang:date-and-time
| | +--ro actual-stop-time yang:date-and-time
Figure 3: Augmentation Dynamic Networking Subtree Structure
Fu, et al. Expires 6 January 2027 [Page 10]
Internet-Draft Extensions to L3SM July 2026
* dynamic-attribute: The dynamic-attribute container groups all
parameters associated with dynamic service provisioning. This
parameter is configurable only when the dynamic networking and/or
bandwidth adjustment feature is enabled. If this feature is not
enabled, the service shall adopt the conventional L3SM model which
assumes persistent connectivity.
* always-on: Boolean flag indicating whether the connection is
consistent (default true) . The requested-start and requested-stop
parameters are only configurable when always-on is enabled. If
always-on is false, the customer need to specify the exact time
slots.
* connection-provisioning-delay: Latency parameter specifying the
time offset between requested activation and actual activation of
the connection. Network operators may predefine a set of latency-
related templates, from which customers may select the one
matching their service requirements. The connection-provisioning-
delay attribute can reference a predefined latency template.
* active-networking-policy:The active-networking-policy container
groups parameters associated with dynamic networking service
capabilities, including connection-provisioning-delay and specify
exact time slots for networking service ,which is only valid when
the always-on attribute is set to false.
- policy-mode: There are two types of requirements for specifying
exact time slots: immediate activation and scheduled
activation. Upon reaching the scheduled active time, the
network controller should deploy relevant configurations to
bring up the specified connections, and when reaching the
scheduled tear-down time, the network controller should deploy
corresponding configurations to tear down this connection. In
addition to bring up or tearing down the target access link,
the controller should simultaneously add or remove all relevant
configurations associated with the VPN service that reference
this access link from other access links.
o Immediate activation means that service configurations are
deployed right after customer subscription. Under the
immediate activation mode, the start time does not need to
be specified, and the end time is derived from the reserved
duration.
Fu, et al. Expires 6 January 2027 [Page 11]
Internet-Draft Extensions to L3SM July 2026
o Scheduled activation means supports for explicit calendar
date-specific activation, allowing customers to suscribe a
list of exact valid dates(YYYY-MM-DD) and corresponding
intra-day time slots on which the dynamic networking service
takes effect.
- connection-provisioning-delay monitoring: The read-write start-
time and end-time are configured to express customers' expected
time to enable/ disable the connection, while the corresponding
read-only actual-start-time and actual-end-time reports the
actual date and time when the bearer was enable/ disable. The
difference between the actual timestamps and the expected
timestamps represents the actual service provisioning delay.
This value is used by customers to check whether the service
meets the connection-provisioning-delay SLO constraints.
6.2.2. Dynamic bandwidth adjustment
Requirement:
* Customers maintain a low-bandwidth persistent connection for
regular use. When special requirements arise (such as large data
transmission workloads), higher-bandwidth connections may be
provisioned temporarily.
* Customers require bandwidth adjustment provisioning latency to be
provided as an SLO attribute, which quantifies the adjustment time
offset between the requested-start/stop time and actual-start/end
timestamps.
Gap in [RFC8299]: L3SM specifies static bandwidth parameters (svc-
input-bandwidth, svc-output-bandwidth) without support for elastic
bandwidth adjustment and adjustment provisioning delay constraints.
Extensions:
This YANG data model defines support for adjustment of bandwidth
allocations. Figure 4 illustrates the module augmentation subtree
structure of dynamic bandwidth adjustment.
Fu, et al. Expires 6 January 2027 [Page 12]
Internet-Draft Extensions to L3SM July 2026
augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
/l3vpn-svc:site-network-accesses
/l3vpn-svc:site-network-access:
+--rw service
| +--rw requested-start? yang:date-and-time
| when "../dynamic-attribute/always-on = true";
| +--rw requested-stop? yang:date-and-time
| when "../dynamic-attribute/always-on = true";
| +--rw svc-input-bandwidth uint64
| +--rw svc-output-bandwidth uint64
| +--rw dynamic-attribute /
{dynamic networking and/or bandwidth adjustment}
| | +--rw always-on? boolean
| | +--rw active-networking-policy {not-always-on}?
| | ...
| | +--rw dynamic-bandwidth-attribute
| | +--rw dynamic-bandwidth-indicator? boolean
| | +--rw bandwidth-adjustment-provisioning-delay-ref leafref
| | +--rw max-adjustment-bandwidth-range? leafref
| | +--rw (policy-mode)
| | +--:(immediate)
| | | +--rw duration-hours uint16
| | | +--rw svc-input-bandwidth uint64
| | | +--rw svc-output-bandwidth uint64
| | | +--ro actual-start-time yang:date-and-time
| | | +--ro actual-stop-time yang:date-and-time
| | +--:(scheduled)
| | +--rw time-period* [period-id]
| | +--rw period-id string
| | +--rw date-list* [date-id]
| | +--rw date-id string
| | +--rw target-date yang:date
| | +--rw time-slot* [slot-id]
| | +--rw slot-id string
| | +--rw start-time yang:time-of-day
| | +--rw stop-time yang:time-of-day
| | +--ro actual-start-time yang:date-and-time
| | +--ro actual-stop-time yang:date-and-time
| | +--rw svc-input-bandwidth uint64
| | +--rw svc-output-bandwidth uint64
Figure 4: Augmentation Dynamic bandwidth Subtree Structure
* dynamic-bandwidth-attribute: The dynamic-bandwidth-attribute
container groups parameters associated with dynamic bandwidth
adjustment service including bandwidth-provisioning-delay, max-
adjustment-bandwidth-range and specify exact time slots for
Fu, et al. Expires 6 January 2027 [Page 13]
Internet-Draft Extensions to L3SM July 2026
bandwidth adjustment service. When alway-on is true, the svc-
input-bandwidth node and the svc-output-bandwidth node under
/site-network-access/service indicates the base bandwidth value
applicable to the access link.
- dynamic-bandwidth-enabled: Boolean flag indicating whether
bandwidth adjustment is enabledd (default false).
- maximum-bandwidth-adjustment-profile: Maximum range allowed for
a bandwidth modification. This parameter is a factor that
operators take into account when selecting appropriate bearer
solution for access links. As an illustration, operators may
deploy GE links between CE and PE when the maximum bandwidth is
less than 1 Gbps. If the required bandwidth exceeds 10 Gbps,
50G-PON or 100G interfaces can be adopted as the access medium
instead. The exact approach to be adopted is implementation-
specific and determined by the actual deployment.
- bandwidth-adjustment-provisioning-delay: Maximum allowed delay
to complete a bandwidth modification. Network operators may
predefine a set of latency-related templates, from which
customers may select the one matching their service
requirements.
- bandwidth-flex-policy:There are two types of requirements to
specify exact time slots: immediate activation and scheduled
activation. Immediate activation means that service
configurations are deployed right after customer subscription.
scheduled activation means supports for explicit calendar date-
specific activation, allowing customers to suscribe a list of
exact valid dates(YYYY-MM-DD) and corresponding intra-day time
slots on which the dynamic bandwidth service takes effect.
Upon reaching the scheduled adjustment time, the network
controller should deploy relevant configurations to adjust the
bandwidth to a new value, and when the scheduled bandwidth
restoration time arrives, the controller shall revert the
bandwidth of the access link to its baseline value. Operators
may adopt different bandwidth adjustment implementation
mechanisms according to distinct SLO requirements for
adjustment latency.
- bandwidth-adjustment-provisioning-delay monitoring: The read-
write start-time and stop-time are configured to express
customers' expected time to adjust the bandwidth of the
connection, while the corresponding read-only actual-start-time
and actual-end-time reports the actual date and time when the
bandwidth adjustment was completed. The offset between the
actual timestamps and the expected timestamps represents the
Fu, et al. Expires 6 January 2027 [Page 14]
Internet-Draft Extensions to L3SM July 2026
actual service provisioning delay. This value is used by
customers to check whether the service meets the bandwidth-
adjustment-provisioning-delay SLO constraints.
6.2.3. Enhanced qos
Requirement:
* With the widespread deployment of SRv6 network slicing, L3VPN
services require slicing-specific SLO/SLE parameters including
isolation. L3SM shall support binding L3VPN instances to
dedicated slicing SLO/SLE guarantees.
* Customers expect QoS flow classification policies to be reusable
across other functional modules in the same L3VPN service, such as
security and performance monitoring, to reduce the complexity of
flow classification definitions.
* The provisioning of QoS functionality consists of traffic
classification policies and QoS policies. As noted above,
reusable flow classification policies are required. For QoS
policies, customers require a globally applicable QoS policy to
eliminate the high complexity of separate configurations per site
and per link. Sites or links with special requirements may be
assigned customized settings individually.
Gap in [RFC8299]:
* L3SM provides basic QoS profiles but lacks integration with
network slicing constructs and parameterized SLO/SLE
specifications.
* Traffic classification policies reside under the QoS container,
making them inconvenient to be reused by other functional modules.
* [RFC8299] defines QoS policies at the site and site-network-access
levels, without support for the vpn-service level. This results
in extensive duplicated configurations across individual sites and
increases operational complexity.
Extensions:
This YANG data model defines support for enhanced qos. Figure 5
illustrates the module augmentation subtree structure of enhanced
qos.
Fu, et al. Expires 6 January 2027 [Page 15]
Internet-Draft Extensions to L3SM July 2026
| +--rw qos {qos}?
| +--rw (qos-profile)
| +--:(custom) {qos-custom}?
| +--rw classes {qos-custom}?
| +--rw class* [class-id]
| +--rw class-id string
| +--rw isolation* identityref
Figure 5: Augmentation Qos Subtree Structure
* isolation: Specify the requirement that the L3VPN Service is not
impacted by the existence of other customers or services in the
same network. The definition of isolation aligns with [I-D.ietf-
teas-ietf-network-slice-nbi-yang], enabling consistent policy
application across VPN and slice services.
As mentioned above, the provisioning of QoS functionality consists of
traffic classification policies and QoS policies. QoS profiles serve
as containers for QoS policies. QoS profiles can be supplied as
standardized templates by the operators, or customized independently
by customers. QoS policies are appropriate for global definition
under the vpn-service node and applicable accross all sites and
access links. Traffic classification policies ought to be tied to
specific sites and access links, and therefore should be defined at
the site level and access link level to enable reuse across different
functional modules.
Traffic-classification subtree structure is shown in Figure 6.
Fu, et al. Expires 6 January 2027 [Page 16]
Internet-Draft Extensions to L3SM July 2026
augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site:
+--rw classification-policy* [rule-id]
| +--rw rule-id yt:uint32
| +--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 target-sites* [svc-id] {target-sites}?
| +--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
+--rw security
| +--rw class* [class-id]
| ...
+--rw service
| +--rw (qos-profile)
| +--:(custom)
| +--rw classes {qos-custom}?
| +--rw class* [class-id]
| ...
Figure 6: Traffic-classification Subtree Structure
The global qos policy subtree structure is shown in Figure 7.
augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-service:
+--rw qos {qos}?
| ....
Figure 7: Global qos policy Subtree Structure
Fu, et al. Expires 6 January 2027 [Page 17]
Internet-Draft Extensions to L3SM July 2026
6.2.4. Performance Monitoring
Requirement: Provide end-to-end service quality visibility.
Gap in [RFC8299]:The base L3SM lacks native monitoring configuration
options and service-level performance metrics.
Extensions:
Figure 8 illustrates the module augmentation subtree structure of
perf-mon.
+--rw perf-mon {perf-mon}?
| +--rw enable? boolean
| +--rw perf-mon-profile
| +--rw (perf-mon-profile)
| +--:(standard)
| | +--rw profile?
| +--:(custom) {perf-mon-custom}?
| +--rw measurement-interval yt:uint32 units seconds
| +--rw pm-attributes
| +--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 8: Augmentation Performance Monitoring Subtree Structure
* monitoring-enabled: Boolean flag to enable performance monitoring
for the L3VPN service (default false).
* measurement-interval: Specifies the performance measurement
interval, in seconds.
* pm-attributes (read-only): A set of operational state and service-
level performance metrics, including delay, packet loss and
jitter, to enrich operational state data and enhance end-to-end
quality visibility.
Fu, et al. Expires 6 January 2027 [Page 18]
Internet-Draft Extensions to L3SM July 2026
6.2.5. Enhanced security
Requirement:
* Support quantum-safe encryption for high-security data
transmission scenarios, defending data against potential cracking
threats brought by future cryptographically relevant quantum
computers and providing long-term transmission confidentiality.
* Support ce-ce encryption to safeguard security throughout the full
data transmission process.
* Support fine-grained traffic encryption to encrypt designated
flows instead of full-traffic encryption. Driven by service
charges and forwarding performance constraints, customers demand
flow-granular encryption.
Gap in [RFC8299]:
* L3SM defines basic encryption enablement, including specifying the
encryption algorithm applied to ESP payloads and specifying PSK
applied for peer authentication during the IKE negotiation phase.
But L3SM lacks parameters for quantum key distribution (QKD) and
post-quantum cryptography (PQC) integration.
* The current specification only supports encryption across the CE-
to-PE segment. For scenarios where CEs are managed by the
operator, customers require encryption service across the whole
CE-to-CE path.
* The encryption mechanism defined in [RFC8299] only applies to full
traffic on access links and operates at a relatively coarse
granularity.
* Editor's Note: The ce-ce/PE-PE quantum-safe encryption service
type for quantum-safe security is TBD.
Extensions:
Figure 9 illustrates the module augmentation subtree structure of
enhanced security.
Fu, et al. Expires 6 January 2027 [Page 19]
Internet-Draft Extensions to L3SM July 2026
+--rw security
| +--rw authentication? string
| +--rw encryption {encryption}?
| | +--rw enabled? boolean
| | +--rw layer? enumeration
| | +--rw encryption-profile
| | +--rw (profile)?
| | +--:(provider-profile)
| | | +--rw profile-name?
| | +--:(customer-profile)* [class-id]
| | +--rw class-id string
| | +--rw algorithm? string
| | +--rw (key-type)?
| | | +--:(psk)
| | | +--rw pre-shared-key? string
| | +--rw post-quantum-encryption-config /
{post-quantum-encryption}
| | +--rw enable? boolean
| | +--rw quantum-failover-mode? identityref
| | +--ro quantum-encryption-status? identityref
| | +--rw pqc-config
| | | +--rw enable? boolean
| | +--rw qkd-config
| | +--rw enable? boolean
| | +--rw qkd-key-pool-id? string
| | +--rw key-refresh-interval? uint32
Figure 9: Augmentation security Subtree Structure
* fine-grained traffic matching: Class-id distinguishes different
traffic classification rules for customers. slist contains
traffic classification entries for customers, which .The customer-
profile container is defined as a list with class-id serving as
its list key. Each entry defines the mapping between a class-id
and its associated encryption policy.
* post-quantum-encryption-config: The post-quantum-encryption-config
container aggregates all configuration items associated with post-
quantum-encryption and it is gated by the post-quantum-encryption
feature.
- The post-quantum-encryption-config container unifies
configuration for the two primary categories of quantum-
resistant security services: Post-Quantum Cryptography (PQC)
and Quantum Key Distribution (QKD).
Fu, et al. Expires 6 January 2027 [Page 20]
Internet-Draft Extensions to L3SM July 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 IKE negotiation, and combines key material derived from
PQC with QKD keys to produce the final session symmetric key.
This document merely provides an illustrative example and
imposes no restrictions on operator-specific implementations.
The detailed deployment approach is left to operator.
* post-quantum-encryption-enable: Boolean flag for post-quantum-
encryption activation, including activation of PQC, QKD, or both.
The specific activation policy is left to the operators. For
instance, some operators may deploy only PQC, while others adopt
QKD or a combination of both.
* quantum-failover-mode:Failover behavior when quantum ike-key
generation fails (fallback to conventional crypto or terminate).
* quantum-encryption-status: a read-only parameter, reports the
current operational state of post-quantum encryption.
* PQC-config: The PQC-config container aggregates all configuration
items associated with PQC-based encryption. At present, only a
boolean enable leaf is specified to turn PQC encryption on or off.
The PQC-config container can easily be augmented with other
configuration parameters in future.
* qkd-config: The qkd-config container aggregates all configuration
items associated with QKD-based encryption, and can easily be
augmented with other configuration parameters.
- qkd-enable: Boolean flag for QKD-based encryption activation.
- key-refresh-interval: this leaf specifies the time interval,
measured in seconds, at which the quantum key pool shall
automatically refresh its stored quantum keys.
- qkd-key-pool-id: this leaf specify the identifier of a QKD key
pool managed by the QKD key management entity (KME). A QKD key
pool stores pre-generated symmetric quantum keys shared between
paired QKD endpoints. Identical qkd-key-pool-id values shall
be configured on both endpoints of any QKD link. For QKD-based
encryption deployed over either the CE-to-PE or CE-to-CE
segment, the paired endpoints (CE and PE, or CE and CE) shall
share the same qkd-key-pool-id.
Fu, et al. Expires 6 January 2027 [Page 21]
Internet-Draft Extensions to L3SM July 2026
7. Extended L3SM YANG Module
Editor's note: This modules augments the L3SM. The l3vpn-svc-ext is
TBD.
8. Service Model Usage Example
Editor's note:The Service Model Usage Example is TBD.
9. IANA Considerations
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
10. Security Considerations
The extensions defined in this document inherit the security
considerations of RFC 8299.
Additional considerations:
* Dynamic provisioning mechanisms (e.g., RADIUS COA) MUST be secured
using mutual authentication and integrity protection.
* Quantum encryption parameters are sensitive; access to these
configuration nodes SHOULD be restricted to authorized
administrators.
* Communication between customers and service orchestrators SHOULD
use TLS 1.3 or equivalent encryption.
* Dynamic networking capabilities require appropriate security
mechanisms to prevent customers from establishing L3VPNs with
untrusted peers. The specific implementation details of the
mutual trust mechanisms are out of scope.
11. References
11.1. Normative References
Fu, et al. Expires 6 January 2027 [Page 22]
Internet-Draft Extensions to L3SM July 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, DOI 10.17487/RFC2119, March
1997, <https://www.rfc-editor.org/rfc/rfc2119.txt>.
[RFC4026] Rosen, E., Ed. and Y. Rekhter, Ed., "BGP/MPLS VPN
Terminology", RFC 4026, June 2005,
<https://www.rfc-editor.org/rfc/rfc4026>.
[RFC4364] Rosen, E., Ed. and Y. Rekhter, Ed., "BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4364, February 2006,
<https://www.rfc-editor.org/rfc/rfc4364>.
[RFC5176] Zorn, G., Ed. and B. Aboba, Ed., "Dynamic Authorization
Extensions to RADIUS", RFC 5176, January 2008,
<https://www.rfc-editor.org/rfc/rfc5176>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174.txt>.
[RFC8299] Bjorklund, M., Ed., Medved, J., Ed., and S. Vissicchio,
Ed., "A YANG Data Model for Layer 3 VPN Services (L3SM)",
RFC 8299, November 2017,
<https://www.rfc-editor.org/rfc/rfc8299>.
[RFC9833] Boucadair, M., Ed., "A Common YANG Data Model for
Attachment Circuits", RFC 9833, September 2025,
<https://www.rfc-editor.org/rfc/rfc9833>.
[RFC9834] Boucadair, M., Ed., "A YANG Data Model for Ethernet
Transport Bearer Services", RFC 9834, October 2025,
<https://www.rfc-editor.org/rfc/rfc9834>.
11.2. Informative References
[RFC8986] Filsfils, C., Ed., Previdi, S., Ed., Dukes, D., Ed.,
Matsushima, S., Ed., and Z. Li, Ed., "Segment Routing over
IPv6 (SRv6) Network Programming", RFC 8986, March 2021,
<https://www.rfc-editor.org/rfc/rfc8986>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252, July
2022, <https://www.rfc-editor.org/rfc/rfc9252>.
Fu, et al. Expires 6 January 2027 [Page 23]
Internet-Draft Extensions to L3SM July 2026
Appendix A. Dynamic-L3VPN service provisioning and lifecycle procedure
The VPN instances on the PE devices may be pre-configured as defined
in [RFC4364], with the VPN instance bound to an AC only when
establishing end-to-end VPN connectivity. Alternatively, the VPN
instance may also be dynamically configured via configuration
commands based on customer requirements.
The dynamic-L3VPN service provisioning and lifecycle procedure is as
follows, and we take customer A ordering dynamic-L3VPN service as an
example.
Fu, et al. Expires 6 January 2027 [Page 24]
Internet-Draft Extensions to L3SM July 2026
+------------+ +---------+ +----+ +----+ +----------+
| Customer-A | | Ordering| | CE | | PE | | Network |
| | | System | | | | | |Controller|
+------------+ +---------+ +----+ +----+ +----+-----+
| | | | |
| 1. Register | | | |
+------------->| | | |
| | | | |
| 2. Submit VPN Service Info | | |
| (Peer, BW, Start, End) | | |
+------------->| | | |
| | | | |
| | 3. Configure CE | |
| +------------->| | |
| | | | |
| | | 4. Connect to PE |
| | +---------->| |
| | | | |
| | | 5. Bind AC to VPN
| | | |<-------------+
| | | | |
| 6. Submit Dynamic BW Request| | |
+------------->| | | |
| | | | |
| | 7. Update Bandwidth (PE) | |
| +------------------------->| |
| | | | |
| 8. Request Add User to VPN | | |
+------------->| | | |
| | | | |
| | 9. Config New CE & PE | |
| +------------------------->| |
| | | | |
| 10. Request Remove User | | |
+------------->| | | |
| | | | |
| | 11. Config: Remove AC | |
| +------------->| | |
| | | | |
| | 12. Config:Remove AC from PE |
| +------------------------->| |
| | | | |
Figure 10: Dynamic-L3VPN Service Orchestration Procedure
The procedure consists of 12 key steps covering the full lifecycle of
dynamic-L3VPN: registration, initial service provisioning, dynamic
bandwidth adjustment, peer addition/removal, and resource cleanup.
Fu, et al. Expires 6 January 2027 [Page 25]
Internet-Draft Extensions to L3SM July 2026
The Network Controller coordinates configuration across CEs and PEs
to ensure end-to-end service delivery, while the Ordering System acts
as the interface between customers and the network infrastructure.
SRv6 (defined in [RFC8986] and [RFC9252]) may be used for path
optimization in dynamic-L3VPN.
1. Customer A registers in the service ordering system.
2. Customer A enters VPN service parameters into the ordering
system, including peer VPN customers, bandwidth requirement,
start time, and end time, etc.
3. The Network controller provisions configuration to the CE
devices of the involved customers.
4. Each CE device establishes a connection to its attached PE
device.
5. The Network controller sends configuration or signaling to the
PE devices to bind the customer's AC to the VPN instance.
6. Customer A submits an elastic bandwidth adjustment request via
the ordering system.
7. The Network controller delivers configuration or signaling to
the PE devices to modify the bandwidth of the VPN service.
8. Customer A submits a request via the ordering system to add one
or more new customers to the VPN.
9. The Network controller provisions the new customers' CE device
and sends configuration or signaling to the corresponding PE
devices.
10. Customer A submits a request via the ordering system to remove
one or more existing customers from the VPN.
11. The Network controller updates the configuration of the removed
customers' CE devices.
12. The Network controller sends configuration or signaling to the
corresponding PE devices to delete the associated AC from the
VPN.
Fu, et al. Expires 6 January 2027 [Page 26]
Internet-Draft Extensions to L3SM July 2026
Acknowledgments
The authors wish to thank Mingjiang Fu, Zhenlin Tan, Wenkuan Qu of
China Telecom for their contributions to the dynamic L3VPN
operational requirements.
Contributors
The following authors contributed significantly to this document.
Chongfeng Xie
China Telecom
Email: xiechf@chinatelecom.cn
Authors' Addresses
Fengchao Fu
China Telecom
Email: fufengc@chinatelecom.cn
Cancan Huang
China Telecom
Email: huangcanc@chinatelecom.cn
Bo Wu
Huawei
Email: lana.wubo@huawei.com
Fu, et al. Expires 6 January 2027 [Page 27]