An Extensible Architecture for Service Modeling
draft-lambrechts-onsen-svc-yang-00
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) | |
|---|---|---|---|
| Author | Kris Lambrechts | ||
| Last updated | 2026-02-22 | ||
| 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-lambrechts-onsen-svc-yang-00
Internet Engineering Task Force K. Lambrechts
Internet-Draft NetEdge
Intended status: Informational 22 February 2026
Expires: 26 August 2026
An Extensible Architecture for Service Modeling
draft-lambrechts-onsen-svc-yang-00
Abstract
This document describes problems with the currently published IETF
service modules and defines a modular service modeling structure that
extracts technology-agnostic constructs into a base ietf-svc module,
separates Ethernet-specific treatment into ietf-eth-svc, and layers
VPN-oriented intent in ietf-vpn-svc, with bis versions of the L2SM
and L3SM augmenting the shared foundation.
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 26 August 2026.
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.
Lambrechts Expires 26 August 2026 [Page 1]
Internet-Draft Extensible Service Model February 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Limitations of the Current Service Models . . . . . . . . . . 2
2.1. High Levels of Duplication between the Service Models . . 2
2.2. Limited Interoperability between Service Models . . . . . 3
2.3. Missing Support for Network Technology Layering . . . . . 3
2.4. Complexity in Creating a Single View of Services . . . . 3
3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3
4. Relationships to Other Work . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The Layer 2 VPN Service Model (L2SM) [RFC8466] and Layer 3 VPN
Service Model (L3SM) [RFC8299] YANG models provide a standardized
approach to modeling L2VPN and L3VPN services. However, these models
do not interact with each other, and are not designed to be
extensible so that additional services can be added.
This document describes a new, extensible architecture for services
modules and defines a YANG module that can be used as the base for
any customer service. The goals of this work are to reduce
duplication between existing L2SM and L3SM work, enable new service
types to reuse common abstractions, and let operators expose a
consistent customer-facing interface while retaining flexibility for
technology-specific extensions.
2. Limitations of the Current Service Models
The following sections describe problems with the approach taken by
the current L2SM and L3SM modules.
2.1. High Levels of Duplication between the Service Models
The L2SM and L3SM individually cover all the inputs to deliver either
L2VPN or L3VPN services, including an abstracted view of the
customer's site locations. This means that an operator that offers
both types of services must manage two separate models with a large
amount of duplicated information.
When additional service models are defined for new service types, the
current approach requires further duplication, making the problem
worse.
Lambrechts Expires 26 August 2026 [Page 2]
Internet-Draft Extensible Service Model February 2026
2.2. Limited Interoperability between Service Models
It is impossible to express certain relationships between the L2VPN
and L3VPN services being ordered, such as diversity or bandwidth
constraints. This is especially important in deployment scenarios
where common infrastructure hardware is used for providing both L2VPN
and L3VPN services.
2.3. Missing Support for Network Technology Layering
The current L2SM and L3SM models do not have a way to express the
relationships between the different technology layers that are used
to provision the overall service. For example, an operator may want
to specify that an L3VPN service should be delivered over a specific
underlying L2VPN service, or that an SD-WAN service should be
delivered over a specific Internet access service. The lack of
support for network layering makes it difficult to model and manage
complex service offerings that involve multiple layers of abstraction
and different technologies.
2.4. Complexity in Creating a Single View of Services
Currently, the L2SM and L3SM do not contain operational state. If
these modules are extended with state nodes, e.g., so it is possible
to retrieve information about the current health of a customer's
services, the separation of L2SM, L3SM, and other service models
makes correlating the service impact of underlying failures affecting
more than one service type more difficult.
3. Proposed Solution
This document revisits the existing L2SM and L3SM models, introducing
a new structure with a common base model. This removes the
duplication between service models, and enables much simpler
interworking between different service types. It also forms an
extensible basis for the definition of new service models in the
future.
The core of the module structure is defined in ietf-svc. This
provides a technology-agnostic service skeleton covering sites, site-
network-accesses, diversity constraints, and bearer references.
Additionally, Ethernet-centric constructs such as bandwidth profiles
and QoS classification are moved into a dedicated ietf-eth-svc module
so that Ethernet-based services can share the same primitives without
cluttering the core service skeleton.
Lambrechts Expires 26 August 2026 [Page 3]
Internet-Draft Extensible Service Model February 2026
The ietf-vpn-svc module builds on this core and defines VPN-oriented
attributes such as service type, topology, cloud, and extranet
reachability, carriers' carrier, and policy filters.
Finally, the technology specific parameters for L2VPN and L3VPN
services are augmented into the shared service framework. The L3VPN
module retains the routing, multicast, address-allocation, NAT, and
BFD constructs from [RFC8299]. The L2VPN module retains the
Ethernet- and OAM-specific behaviors from [RFC8466] (e.g., bundling,
CE-VLAN preservation, L2CP handling, CFM, and Y.1731) while
leveraging the shared service skeleton, the Ethernet treatment
constructs in ietf-eth-svc, and the VPN service identities from ietf-
vpn-svc.
The augment relationships across the modules are shown in Figure 1.
module: ietf-svc (Base service skeleton)
+-- augment: ietf-eth-svc (Ethernet attributes, e.g QoS)
+-- augment: ietf-vpn-svc (VPN service common attributes)
+-- augment: ietf-l2vpn-svc (L2VPN-specific attributes)
+-- augment: ietf-l3vpn-svc (L3VPN-specific attributes)
Figure 1: Service module augmentation relationships
By aligning the L2SM and L3SM models on a common foundation, this
work reduces duplication, improves consistency of service exposure to
customers and OSS/BSS systems, and simplifies the introduction of
future service types that can reuse the same base abstractions.
Examples of new services that could be modeled on top of the same
base include (business) internet access, cloud interconnect, or even
optical wavelength services.
4. Relationships to Other Work
The Layer 2 VPN Network Model (L2NM) [RFC9291] and Layer 3 VPN
Network Model (L3NM) [RFC9182] may benefit from being re-built on top
of a similarly abstracted foundation, but they are outside the scope
of this document.
Adoption of the Common YANG Data Model for Layer 2 and Layer 3 VPNs
[RFC9181] at the service model level may be beneficial and should be
considered as part of this work.
5. IANA Considerations
This memo includes no request to IANA.
Lambrechts Expires 26 August 2026 [Page 4]
Internet-Draft Extensible Service Model February 2026
6. Security Considerations
The security posture of this document follows the guidance in the
L3SM [RFC8299]. The NETCONF Access Control Model (NACM) [RFC8341]
should be used to restrict protocol operations and data nodes to
authorized principals.
New augments added to the base service skeleton must describe any
additional security-sensitive leaves and specify suitable NACM rules.
When encryption or authentication material is conveyed (e.g., keys or
credentials), operators must ensure secure transport and operational
processes (rotation, revocation, audit) consistent with their policy.
7. References
7.1. Normative References
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[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, <https://www.rfc-editor.org/info/rfc9181>.
[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, <https://www.rfc-editor.org/info/rfc9182>.
[RFC9291] Boucadair, M., Ed., Gonzalez de Dios, O., Ed., Barguil,
S., and L. Munoz, "A YANG Network Data Model for Layer 2
VPNs", RFC 9291, DOI 10.17487/RFC9291, September 2022,
<https://www.rfc-editor.org/info/rfc9291>.
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
"YANG Data Model for L3VPN Service Delivery", RFC 8299,
DOI 10.17487/RFC8299, January 2018,
<https://www.rfc-editor.org/info/rfc8299>.
[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
Data Model for Layer 2 Virtual Private Network (L2VPN)
Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
2018, <https://www.rfc-editor.org/info/rfc8466>.
Lambrechts Expires 26 August 2026 [Page 5]
Internet-Draft Extensible Service Model February 2026
Author's Address
Kris Lambrechts
NetEdge
Email: kris@netedge.plus
URI: https://www.netedge.plus
Lambrechts Expires 26 August 2026 [Page 6]