RFC 9836
A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits
A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits ✨
RFC 9836, published in September 2025 🎀. The authors are M. Boucadair (editor, Orange), R. Roberts (Juniper), S. Barguil (Nokia), and O. Gonzalez de Dios (Telefonica). It's a Standards Track document, so it's an official Internet standard, not just an idea floating around 🔥. Its ISSN is 2070-1721. This RFC doesn't obsolete or update any earlier RFCs, since none are listed in its header 🌸.
Abstract
Okay, so the big idea here is a YANG data model nicknamed the "AC Glue" model 🧚. It adds references to attachment circuits (ACs) onto the LxVPN Service Model (LxSM) and the LxVPN Network Model (LxNM) 💜. Basically, it lets a provider link Layer 2/3 VPN (LxVPN) services to the AC infrastructure underneath them, so new or existing ACs can be provisioned and managed together with the VPN services that use them 💅. It's giving "one integrated approach" to AC and VPN management, which is how it supports Attachment Circuit as a Service (ACaaS) ✨. It also gives everyone a standard way to line up AC/VPN requests with the network configuration needed to deliver them 🦋.
Status of This Memo
This is an Internet Standards Track document 🎀.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 👑. If you want more info on Internet Standards, check out Section 2 of RFC 7841 📚.
For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9836 🌈.
Copyright Notice
Copyright (c) 2025 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) as they're in effect on the publication date 📜. Please read these carefully, because they spell out your rights and restrictions for 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. They're also provided without warranty, as described in the Revised BSD License ⭐.
Table of Contents
1. Introduction
2. Conventions and Definitions
3. Relationship to Other AC Data Models
4. Sample Uses of the Data Models
4.1. ACs Terminated by One or Multiple Customer Edges (CEs)
4.2. Separate AC Provisioning from Actual VPN Service
Provisioning
5. Module Tree Structure
6. The AC Glue ("ietf-ac-glue") YANG Module
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Examples
A.1. A Service AC Reference Within the VPN Network Access
A.2. Network and Service AC References
Acknowledgments
Authors' Addresses1. Introduction ✨
Okay, so to move data around inside the provider network, the setup has to be provisioned on the links connecting customer termination points to the provider network 🧚. Usually that's through a Provider Edge (PE) 🏠. Once that's in place, data can be exchanged successfully over those links 💖. This document calls the required setup an attachment circuit (AC), and the underlying link is called a "bearer" 🦋.
This document specifies a YANG module, "ietf-ac-glue" (Section 6), that updates existing service and network Virtual Private Network (VPN) modules 🌸. It adds the info needed to bind specific services to ACs created with the AC service model [RFC9834] 🎀. Specifically, these modules get augmented:
- The L2VPN Service Model (L2SM) [RFC8466]
- The L3VPN Service Model (L3SM) [RFC8299]
- The L2VPN Network Model (L2NM) [RFC9291]
- The L3VPN Network Model (L3NM) [RFC9182]
The L2NM and L3NM also get augmented with references to the ACs managed through the AC network model [RFC9835] 🫶.
This approach lets operators separate AC provisioning from actual VPN service provisioning 💅. Check out Section 4.2 for more on that 🌈.
The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in [RFC8342] 🔥. Examples showing how to use the "ietf-ac-glue" module are in Appendix A 🍓.
2. Conventions and Definitions 💜
The meanings of the symbols in the YANG tree diagrams are defined in [RFC8340] 📚.
This document uses terms defined in [RFC9834] 🧚.
LxSM refers to both the L2SM and the L3SM 🎀.
LxNM refers to both the L2NM and the L3NM 🎀.
The following terms are used in the module's prefixes 💖:
ac: Attachment circuitntw: Networkref: Referencesvc: Service
The names of data nodes are prefixed with the prefix associated with the corresponding imported YANG module, as shown in Table 1 🦋:
+===========+================+==========================+
| Prefix | Module | Reference |
+===========+================+==========================+
| ac-svc | ietf-ac-svc | Section 6.2 of [RFC9834] |
+-----------+----------------+--------------------------+
| ac-ntw | ietf-ac-ntw | [RFC9835] |
+-----------+----------------+--------------------------+
| l2nm | ietf-l2vpn-ntw | [RFC9291] |
+-----------+----------------+--------------------------+
| l2vpn-svc | ietf-l2vpn-svc | [RFC8466] |
+-----------+----------------+--------------------------+
| l3nm | ietf-l3vpn-ntw | [RFC9182] |
+-----------+----------------+--------------------------+
| l3vpn-svc | ietf-l3vpn-svc | [RFC8299] |
+-----------+----------------+--------------------------+
Table 1: Modules and Their Associated Prefixes3. Relationship to Other AC Data Models 🌸
Figure 1 shows how all the AC data models fit together 🎀. Here's the lineup 👑:
- "ietf-ac-common" [RFC9833]
- "ietf-bearer-svc" (Section 6.1 of [RFC9834])
- "ietf-ac-svc" (Section 6.2 of [RFC9834])
- "ietf-ac-ntw" [RFC9835]
- "ietf-ac-glue" (Section 6)
ietf-ac-common
^ ^ ^
| | |
.----------' | '----------.
| | |
| | |
ietf-ac-svc <--- ietf-bearer-svc |
^ ^ |
| | |
| '------------------------ ietf-ac-ntw
| ^
| |
| |
'------------ ietf-ac-glue ----------'
X --> Y: X imports Y
Figure 1: AC Data ModelsThe "ietf-ac-common" module is imported by the "ietf-bearer-svc", "ietf-ac-svc", and "ietf-ac-ntw" modules 🧚. Bearers managed with "ietf-bearer-svc" can be referenced by service ACs managed with "ietf-ac-svc" 💖. Similarly, a bearer managed with "ietf-bearer-svc" can list the set of ACs that use it 🦋. To help match an AC service request with the AC actually provisioned in the network, "ietf-ac-ntw" builds on the AC references exposed by "ietf-ac-svc" 💅. And to bind Layer 2 VPN (L2VPN) or Layer 3 VPN (L3VPN) services to ACs, "ietf-ac-glue" augments the LxSM and LxNM with AC service references from "ietf-ac-svc" and AC network references from "ietf-ac-ntw" 🫶. It's giving full-circle connection 🌈.
4. Sample Uses of the Data Models 🎀
4.1. ACs Terminated by One or Multiple Customer Edges (CEs) 💜
Figure 2 shows two target topology flavors that involve ACs 🔥. These topologies have the following characteristics ✨:
- A Customer Edge (CE) can be either a physical device or a logical entity 🧚. A logical entity is typically a software component, such as a virtual service function hosted within the provider's network or a third-party infrastructure 💖. The network sees a CE as a peer Service Attachment Point (SAP) [RFC9408] 🦋.
- CEs may be dedicated to one single connectivity service, or they may host multiple connectivity services (for example, CEs with roles of service functions [RFC7665]) 💅.
- A network provider may bind a single AC to one or multiple peer SAPs (for example, CE1 and CE2 are tagged as peer SAPs for the same AC) 🌸. As discussed in [RFC4364], multiple CEs can be attached to a PE over the same AC 🎀. This scenario is typically implemented when the Layer 2 infrastructure between the CE and the network is a multipoint service 🫶.
- A single CE may terminate multiple ACs, which can be associated with the same bearer or with distinct bearers (for example, CE4) 👑.
- Customers may request protection schemes in which the ACs associated with their endpoints are terminated by the same PE (for example, CE3), by distinct PEs (for example, CE4), and so on 🌈. The network provider uses this request to decide where to terminate the AC in the service provider network 🔥. It also uses it to decide whether to enable specific capabilities, such as Virtual Router Redundancy Protocol (VRRP) 🍓.
.--------------------.
| |
.------. | .--. (b1) .-----.
| +----. | | +---AC---+ |
| CE1 | | | |PE+---AC---+ CE3 |
'------' | .--. '--' (b2) '-----'
+---AC--+PE| Network |
.------. | '--' .--. (b3) .-----.
| | | | | +---AC---+ |
| CE2 +----' | |PE+---AC---+ CE4 |
'------' | '--' (b3) '---+-'
| .--. | |
'----------+PE+------' |
'--' |
| |
'-----------AC----------'
(bx) = bearer Id x
Figure 2: Examples of ACsThese ACs can be referenced when creating VPN services 💖. Check out the examples in Appendix A to see how VPN services get bound to ACs 🧚✨
4.2. Separate AC Provisioning from Actual VPN Service Provisioning ✨
okay so the way a service provider sets up a service in their network can depend on their own practices 💅 that includes the workflow they use to provision advanced network services and how those services get bound to an AC. for example, one single AC can host several connectivity services at once, like L2VPN ("ietf-l2vpn-svc"), L3VPN ("ietf-l3vpn-svc"), and Network Slice Service ("ietf-network-slice-service") 🦋. to avoid service interference and having the same info scattered all over the place (bestie, redundant info is a mess 😭), a service provider may expose an interface for managing ACs network-wide using the modules in [RFC9834]. customers can ask for an AC ("ietf-ac-svc") to be set up, and then point to that AC whenever they request VPN services bound to it ("ietf-ac-glue") 🎀.
also, internal references ("ietf-ac-ntw") that a service provider uses inside its network to implement ACs can be used by network controllers to glue the L2NM ("ietf-l2vpn-ntw") or the L3NM ("ietf-l3vpn-ntw") services to the relevant ACs 🧚.
Figure 3 shows where the AC models sit in the overall service delivery process 🌈.
.-------------.
| Customer |
'------+------'
Customer Service Models |
ietf-l2vpn-svc, ietf-l3vpn-svc, | ietf-network-slice-service,
ietf-ac-svc, ietf-ac-glue, | and ietf-bearer-svc
.------+------.
| Service |
| Orchestration |
'------+------'
Network Models |
ietf-l2vpn-ntw, ietf-l3vpn-ntw, | ietf-sap-ntw, ietf-ac-glue,
and ietf-ac-ntw |
.------+------.
| Network |
| Orchestration |
'------+------'
Network Configuration Model |
.-----------+-----------.
| |
.-------+-----. .-------+-----.
| Domain | | Domain |
| Orchestration | | Orchestration |
'--+--------+-' '-------+-----'
Device | | |
Configuration | | |
Models | | |
.---+---. | |
| Config | | |
| Manager | | |
'---+---' | |
| | |
NETCONF/CLI.......................
| | |
.--------------------------------.
.---. Bearer | | Bearer .---.
|CE1 +--------+ Network +--------+ CE2|
'---' | | '---'
'--------------------------------'
Site A Site B
Figure 3: An Example of AC Models Usage5. Module Tree Structure 🌸
okay now we're in module tree territory, so get ready 🤓. [RFC8299] says a 'site-network-access' is reached through a 'bearer' with an 'ip-connection' sitting on top of it. from that angle, a 'site-network-access' gets mapped to an AC that has both Layer 2 and Layer 3 properties, per [RFC9834]. [RFC8466] says a 'site-network-access' is a logical Layer 2 connection to a site, so a 'site-network-access' can also be mapped to an AC with Layer 2 properties [RFC9834]. similarly, 'vpn-network-access' (defined in both [RFC9182] and [RFC9291]) gets mapped to an AC per [RFC9834] or [RFC9835] 💜.
so, ACs created with the "ietf-ac-svc" module [RFC9834] can be referenced from other VPN-related modules (like LxSM and LxNM) ✨. ACs managed with the "ietf-ac-ntw" module [RFC9835] can be referenced from VPN-related network modules (mainly the LxNM) 💖. the augmentations needed to make that happen are shown in Figure 4 🫶.
module: ietf-ac-glue
augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site
/l2vpn-svc:site-network-accesses:
+--rw ac-svc-ref* ac-svc:attachment-circuit-reference
augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site
/l2vpn-svc:site-network-accesses
/l2vpn-svc:site-network-access:
+--rw ac-svc-ref? ac-svc:attachment-circuit-reference {ac-glue}?
augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
/l3vpn-svc:site-network-accesses:
+--rw ac-svc-ref* ac-svc:attachment-circuit-reference
augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
/l3vpn-svc:site-network-accesses
/l3vpn-svc:site-network-access:
+--rw ac-svc-ref? ac-svc:attachment-circuit-reference {ac-glue}?
augment /l2nm:l2vpn-ntw/l2nm:vpn-services/l2nm:vpn-service
/l2nm:vpn-nodes/l2nm:vpn-node/l2nm:vpn-network-accesses:
+--rw ac-svc-ref* ac-svc:attachment-circuit-reference
+--rw ac-ntw-ref* [ac-ref]
+--rw ac-ref leafref
+--rw node-ref? leafref
+--rw network-ref? -> /nw:networks/network/network-id
augment /l2nm:l2vpn-ntw/l2nm:vpn-services/l2nm:vpn-service
/l2nm:vpn-nodes/l2nm:vpn-node/l2nm:vpn-network-accesses
/l2nm:vpn-network-access:
+--rw ac-svc-ref? ac-svc:attachment-circuit-reference {ac-glue}?
+--rw ac-ntw-ref {ac-glue}?
+--rw ac-ref? leafref
+--rw node-ref? leafref
+--rw network-ref? -> /nw:networks/network/network-id
augment /l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service
/l3nm:vpn-nodes/l3nm:vpn-node/l3nm:vpn-network-accesses:
+--rw ac-svc-ref* ac-svc:attachment-circuit-reference
+--rw ac-ntw-ref* [ac-ref]
+--rw ac-ref leafref
+--rw node-ref? leafref
+--rw network-ref? -> /nw:networks/network/network-id
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 ac-svc-ref? ac-svc:attachment-circuit-reference {ac-glue}?
+--rw ac-ntw-ref {ac-glue}?
+--rw ac-ref? leafref
+--rw node-ref? leafref
+--rw network-ref? -> /nw:networks/network/network-id
Figure 4: AC Glue Tree Structurewhen an AC gets referenced inside a specific network access, that AC info wins over any overlapping info that's also included for that network access 👑.
This approach matches the design in [YANG-NSS], where an AC service reference, called 'ac-svc-ref', is used to indicate the names of AC services. As per [YANG-NSS], when both 'ac-svc-ref' and the attributes of 'attachment-circuits' are defined, the 'ac-svc-ref' takes precedence 🙈
the "ietf-ac-glue" module has provisions for referencing ACs both inside and outside a VPN network access 🧚♀️. that's because an AC reference might get created before or after a VPN instance exists, so both situations need to work. Appendix A.1 shows how an AC reference can be included as part of a specific VPN network access, and Appendix A.2 shows how AC references can be indicated outside individual VPN network access entries 🍓.
6. The AC Glue ("ietf-ac-glue") YANG Module ✨
okay bestie, this is the glue section 🫶 this module augments the L2SM [RFC8466], the L3SM [RFC8299], the L2NM [RFC9291], and the L3NM [RFC9182]. it's basically the thing that lets your VPN models point at your attachment circuits, and it's giving main character energy 💅
this module also uses references defined in [RFC9834] and [RFC9835] 📚
module ietf-ac-glue {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ac-glue";
prefix ac-glue;
import ietf-l3vpn-svc {
prefix l3vpn-svc;
reference
"RFC 8299: YANG Data Model for L3VPN Service Delivery";
}
import ietf-l2vpn-svc {
prefix l2vpn-svc;
reference
"RFC 8466: A YANG Data Model for Layer 2 Virtual Private
Network (L2VPN) Service Delivery";
}
import ietf-l3vpn-ntw {
prefix l3nm;
reference
"RFC 9182: A YANG Network Data Model for Layer 3 VPNs";
}
import ietf-l2vpn-ntw {
prefix l2nm;
reference
"RFC 9291: A YANG Network Data Model for Layer 2 VPNs";
}
import ietf-ac-svc {
prefix ac-svc;
reference
"RFC 9834: YANG Data Models for Bearers and Attachment
Circuits as a Service (ACaaS)";
}
import ietf-ac-ntw {
prefix ac-ntw;
reference
"RFC 9835: A Network YANG Data Model for Attachment Circuits";
}
organization
"IETF OPSAWG (Operations and Management Area Working Group)";
contact
"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org>
Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>
Author: Richard Roberts
<mailto:rroberts@juniper.net>
Author: Samier Barguil
<mailto:ssamier.barguil_giraldo@nokia.com>
Author: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com>";
description
"This YANG module defines a YANG data model for augmenting the
LxSM and the LxNM with AC references.
Copyright (c) 2025 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 9836; see the
RFC itself for full legal notices.";
revision 2025-09-29 {
description
"Initial revision.";
reference
"RFC 9836: A YANG Data Model for Augmenting VPN Service
and Network Models with Attachment Circuits";
}
feature ac-glue {
description
"The VPN implementation supports binding a specific VPN
network access or site access to an AC.";
}
grouping single-ac-svc-ref {
description
"A grouping with a single reference to a service AC.";
leaf ac-svc-ref {
type ac-svc:attachment-circuit-reference;
description
"A reference to the AC as exposed at the service that was
provisioned using the ACaaS module.";
}
}
grouping single-ac-svc-ntw-ref {
description
"A grouping with single AC references.";
leaf ac-svc-ref {
type ac-svc:attachment-circuit-reference;
description
"A reference to the AC as exposed at the service that was
provisioned using the ACaaS module.";
}
container ac-ntw-ref {
description
"A reference to the AC that was provisioned using the AC
network module.";
uses ac-ntw:attachment-circuit-reference;
}
}
grouping ac-svc-ref {
description
"A set of service-specific AC-related data.";
leaf-list ac-svc-ref {
type ac-svc:attachment-circuit-reference;
description
"A reference to the AC as exposed at the service that was
provisioned using the ACaaS module.";
}
}
grouping ac-svc-ntw-ref {
description
"A set of AC-related data.";
leaf-list ac-svc-ref {
type ac-svc:attachment-circuit-reference;
description
"A reference to the AC as exposed at the service that was
provisioned using the ACaaS module.";
}
list ac-ntw-ref {
key "ac-ref";
description
"A reference to the AC that was provisioned using the AC
network module.";
uses ac-ntw:attachment-circuit-reference;
}
}
augment "/l2vpn-svc:l2vpn-svc"
+ "/l2vpn-svc:sites/l2vpn-svc:site"
+ "/l2vpn-svc:site-network-accesses" {
description
"Augments VPN site network accesses with AC provisioning
details. Concretely, it binds a site to a set of ACs with
Layer 2 properties that were created using the ACaaS module.";
uses ac-svc-ref;
}
augment "/l2vpn-svc:l2vpn-svc"
+ "/l2vpn-svc:sites/l2vpn-svc:site"
+ "/l2vpn-svc:site-network-accesses"
+ "/l2vpn-svc:site-network-access" {
if-feature "ac-glue";
description
"Augments VPN site network access with AC provisioning
details. Concretely, it glues a 'site-network-access'
to an AC with Layer 2 properties that was created using the
ACaaS module.
The ACaaS information takes precedence over any overlapping
information that is also provided for a site network access.";
uses single-ac-svc-ref;
}
augment "/l3vpn-svc:l3vpn-svc"
+ "/l3vpn-svc:sites/l3vpn-svc:site"
+ "/l3vpn-svc:site-network-accesses" {
description
"Augments VPN site network accesses with AC provisioning
details. Concretely, it binds a site to a set of ACs with
both Layer 2 and Layer 3 properties that were created using
the ACaaS module.";
uses ac-svc-ref;
}
augment "/l3vpn-svc:l3vpn-svc"
+ "/l3vpn-svc:sites/l3vpn-svc:site"
+ "/l3vpn-svc:site-network-accesses"
+ "/l3vpn-svc:site-network-access" {
if-feature "ac-glue";
description
"Augments VPN site network access with AC provisioning
details. Concretely, it glues a 'site-network-access' to an
AC with both Layer 2 and Layer 3 properties that was created
using the ACaaS module.
The ACaaS information takes precedence over any overlapping
information that is also provided for a site network access.";
uses single-ac-svc-ref;
}
augment "/l2nm:l2vpn-ntw/l2nm:vpn-services/l2nm:vpn-service"
+ "/l2nm:vpn-nodes/l2nm:vpn-node"
+ "/l2nm:vpn-network-accesses" {
description
"Augments VPN network accesses with both service and network
AC provisioning details. Concretely, it binds a site to (1)
a set of ACs with Layer 2 properties that were created using
the ACaaS module and (2) a set of ACs with Layer 2 properties
that were provisioned using the AC network model.";
uses ac-svc-ntw-ref;
}
augment "/l2nm:l2vpn-ntw/l2nm:vpn-services/l2nm:vpn-service"
+ "/l2nm:vpn-nodes/l2nm:vpn-node"
+ "/l2nm:vpn-network-accesses"
+ "/l2nm:vpn-network-access" {
if-feature "ac-glue";
description
"Augments VPN network access with service and network
references to an AC. Concretely, it glues a VPN network
access to (1) an AC with Layer 2 properties
that was created using the ACaaS module and (2) an AC with
Layer 2 properties that was created using the AC network
module.
The AC service and network information takes precedence over
any overlapping information that is also provided for a VPN
network access.";
uses single-ac-svc-ntw-ref;
}
augment "/l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service"
+ "/l3nm:vpn-nodes/l3nm:vpn-node"
+ "/l3nm:vpn-network-accesses" {
description
"Augments VPN network accesses with both service and network
AC provisioning details. Concretely, it binds a site to (1)
a set of ACs with both Layer 2 and Layer 3 properties that
were created using the ACaaS module and (2) a set of ACs with
both Layer 2 and Layer 3 properties that were provisioned
using the AC network model.";
uses ac-svc-ntw-ref;
}
augment "/l3nm:l3vpn-ntw/l3nm:vpn-services/l3nm:vpn-service"
+ "/l3nm:vpn-nodes/l3nm:vpn-node"
+ "/l3nm:vpn-network-accesses"
+ "/l3nm:vpn-network-access" {
if-feature "ac-glue";
description
"Augments VPN network access with service and network
references to an AC. Concretely, it glues a VPN network
access to (1) an AC with both Layer 2 and Layer 3 properties
that was created using the ACaaS module and (2) an AC with
both Layer 2 and Layer 3 properties that was created using the
AC network module.
The AC service and network information takes precedence over
any overlapping information that is also provided for a VPN
network access.";
uses single-ac-svc-ntw-ref;
}
}7. Security Considerations 🔒✨
okay bestie, security time 🔐 this section is modeled after the template in Section 3.7 of [YANG-GUIDELINES], so we're doing it properly, no cap 💅
The "ietf-ac-common" YANG module is designed to be accessed through YANG-based management protocols, like NETCONF [RFC6241] and RESTCONF [RFC8040] 💖. These protocols have to use a secure transport layer (for example SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and have to use mutual authentication. Non-negotiable, periodt 🫶
The Network Configuration Access Control Model (NACM) [RFC8341] is the bouncer 🚪 that restricts particular NETCONF or RESTCONF users to a preconfigured subset of all the available protocol operations and content.
There are a bunch of data nodes in this module that are writable, creatable, and deletable (aka config true, which is the default) 🎀. All writable data nodes are likely to be reasonably sensitive or vulnerable in some network environments. Write operations (like edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations 💀. The following subtrees and data nodes have particular sensitivities/vulnerabilities:
ac-svc-ref and ac-ntw-ref: An attacker who is able to access network nodes can undertake various attacks, such as deleting a running VPN service or interrupting all the traffic of a client 😱. Specifically, an attacker may modify (including delete) the ACs that are bound to a running service, which leads to malfunctioning of the service and therefore to Service Level Agreement (SLA) violations. Such activity can be detected by adequately monitoring and tracking network configuration changes 👀
Some of the readable data nodes in this 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 🙈. Specifically, the following subtrees and data nodes have particular sensitivities/vulnerabilities:
ac-svc-ref and ac-ntw-ref: These references do not expose privacy-related information per se. However, ac-svc-ref may be used to track the set of VPN instances in which a given customer is involved 🕵️
Note that, unlike ac-svc-ref, ac-ntw-ref is unique within the scope of a node and may multiplex many peer CEs 🧠
8. IANA Considerations 🦋
IANA has registered the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-ac-glue
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.IANA has registered the following YANG module in the "YANG Module Names" registry [RFC6020] within the "YANG Parameters" registry group:
Name: ietf-ac-glue
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-ac-glue
Prefix: ac-glue
Reference: RFC 98369. References 📚
9.1. Normative References
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[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>.
[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>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.
[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>.
[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>.
[RFC9834] Boucadair, M., Ed., Roberts, R., Ed., Gonzalez de Dios, O., Barguil, S., and B. Wu, "YANG Data Models for Bearers and Attachment Circuits as a Service (ACaaS)", RFC 9834, DOI 10.17487/RFC9834, September 2025, <https://www.rfc-editor.org/info/rfc9834>.
[RFC9835] Boucadair, M., Ed., Roberts, R., Gonzalez de Dios, O., Barguil, S., and B. Wu, "A Network YANG Data Model for Attachment Circuits", RFC 9835, DOI 10.17487/RFC9835, September 2025, <https://www.rfc-editor.org/info/rfc9835>.
9.2. Informative References
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 10.17487/RFC4664, September 2006, <https://www.rfc-editor.org/info/rfc4664>.
[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, <https://www.rfc-editor.org/info/rfc6241>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.
[RFC9408] Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu, Q., and V. Lopez, "A YANG Network Data Model for Service Attachment Points (SAPs)", RFC 9408, DOI 10.17487/RFC9408, June 2023, <https://www.rfc-editor.org/info/rfc9408>.
[RFC9833] Boucadair, M., Ed., Roberts, R., Ed., Gonzalez de Dios, O., Barguil, S., and B. Wu, "A Common YANG Data Model for Attachment Circuits", RFC 9833, DOI 10.17487/RFC9833, September 2025, <https://www.rfc-editor.org/info/rfc9833>.
[YANG-GUIDELINES] Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", Work in Progress, Internet-Draft, draft-ietf-netmod-rfc8407bis-22, 14 January 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-22>.
[YANG-NSS] Wu, B., Dhody, D., Rokui, R., Saad, T., and J. Mullooly, "A YANG Data Model for the RFC 9543 Network Slice Service", Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slice-nbi-yang-25, 9 May 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-nbi-yang-25>.
Appendix A. Examples 🎀
A.1. A Service AC Reference Within the VPN Network Access
Okay, so let's look at Figure 5, which is kinda inspired by Section 2.1 of [RFC4664] 💖 Each PE is serving two CEs, and we're pretending the service references that identify the ACs with these CEs are the ones shown in the figure 🦋
.----. .----.
| | AC1 AC2 | |
| CE1 |--+ 2001:db8:100::1 2001:db8:200::1 +--| CE2 |
| | | .-----. .-----. .-----. | | |
'----' +----|---- | | P | | ----+----+ '----'
|VPWS\----|-----|-----|/VPWS|
| PE1 |===|=====|=====| PE2 |
| /|---|-----|-----|\\ |
.----. +----|---- | | | | ----|----+ .----.
| | | '-----' '-----' '-----' | | |
| CE3 |--+ +--| CE4 |
| | AC3 AC4 | |
'----' '----'
Figure 5: VPWS Topology ExampleFigure 6 shows that the service AC references can be written right into the L2NM query when you're setting up a Virtual Private Wire Service (VPWS) (Section 3.1.1 of [RFC4664]) 🎀 Main character energy, honestly ✨
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-l2vpn-ntw:l2vpn-ntw":{
"vpn-services":{
"vpn-service":[
{
"vpn-id":"vpws12345",
"vpn-description":"Sample VPWS with AC service \
references",
"customer-name":"customer-12345",
"vpn-type":"ietf-vpn-common:vpws",
"bgp-ad-enabled":true,
"signaling-type":"ietf-vpn-common:ldp-signaling",
"global-parameters-profiles":{
"global-parameters-profile":[
{
"profile-id":"simple-profile",
"local-autonomous-system":65550,
"rd-auto":{
"auto":[
null
]
},
"vpn-target":[
{
"id":1,
"route-targets":[
{
"route-target":"0:65535:1"
}
],
"route-target-type":"both"
}
]
}
]
},
"vpn-nodes":{
"vpn-node":[
{
"vpn-node-id":"pe1",
"ne-id":"2001:db8:100::1",
"active-global-parameters-profiles":{
"global-parameters-profile":[
{
"profile-id":"simple-profile"
}
]
},
"bgp-auto-discovery":{
"vpn-id":"587"
},
"signaling-option":{
"advertise-mtu":true,
"ldp-or-l2tp":{
"saii":1,
"remote-targets":[
{
"taii":2
}
],
"t-ldp-pw-type":"ethernet"
}
},
"vpn-network-accesses":{
"vpn-network-access":[
{
"id":"1/1/1.1",
"interface-id":"1/1/1",
"description":"Interface to CE1",
"active-vpn-node-profile":"simple-\
profile",
"status":{
"admin-status":{
"status":"ietf-vpn-common:\
admin-up"
},
"ietf-ac-glue:ac-svc-ref":"AC1"
}
},
{
"id":"1/1/3.1",
"interface-id":"1/1/3",
"description":"Interface to CE3",
"active-vpn-node-profile":"simple-\
profile",
"status":{
"admin-status":{
"status":"ietf-vpn-common:\
admin-up"
},
"ietf-ac-glue:ac-svc-ref":"AC3"
}
}
]
}
},
{
"vpn-node-id":"pe2",
"ne-id":"2001:db8:200::1",
"active-global-parameters-profiles":{
"global-parameters-profile":[
{
"profile-id":"simple-profile"
}
]
},
"bgp-auto-discovery":{
"vpn-id":"587"
},
"signaling-option":{
"advertise-mtu":true,
"ldp-or-l2tp":{
"saii":2,
"remote-targets":[
{
"taii":1
}
],
"t-ldp-pw-type":"ethernet"
}
},
"vpn-network-accesses":{
"vpn-network-access":[
{
"id":"2/1/2.1",
"interface-id":"2/1/2",
"description":"Interface to CE2",
"active-vpn-node-profile":"simple-\
profile",
"status":{
"admin-status":{
"status":"ietf-vpn-common:\
admin-up"
},
"ietf-ac-glue:ac-svc-ref":"AC2"
}
},
{
"id":"2/1/4.1",
"interface-id":"2/1/4",
"description":"Interface to CE4",
"active-vpn-node-profile":"simple-\
profile",
"status":{
"admin-status":{
"status":"ietf-vpn-common:\
admin-up"
},
"ietf-ac-glue:ac-svc-ref":"AC4"
}
}
]
}
}
]
}
}
]
}
}
}
Figure 6: Example of VPWS Creation with AC Service ReferencesA.2. Network and Service AC References ✨
Okay bestie, let's look at the example in Figure 7 with two customer termination points, CE1 and CE2. We're going to assume the bearers that attach these CEs to the service provider network are already in place. The references that identify those bearers are shown in Figure 7 too 🧚
.-----. .--------------. .-----.
.---. | PE1 +===+ +===+ PE2 | .---.
| CE1+------+"450"| | MPLS | |"451"+------+ CE2|
'---' ^ '-----' | | '-----' ^ '---'
| | Core | |
Bearer:1234 '--------------' Bearer:5678Figure 7: Topology Example
Next, the AC service model [RFC9834] is how the provider can manage and expose the ACs that run over those existing bearers, as you can see in Figure 8. It's giving organized 💅
{
"ietf-ac-svc:attachment-circuits": {
"ac-group-profile": [
{
"name": "an-ac-profile",
"l2-connection": {
"encapsulation": {
"type": "ietf-vpn-common:dot1q",
"dot1q": {
"tag-type": "ietf-vpn-common:c-vlan",
"cvlan-id": 550
}
}
},
"service": {
"mtu": 1550,
"svc-pe-to-ce-bandwidth": {
"bandwidth": [
{
"bw-type": "ietf-vpn-common:bw-per-port",
"cir": "20480000"
}
]
},
"svc-ce-to-pe-bandwidth": {
"bandwidth": [
{
"bw-type": "ietf-vpn-common:bw-per-port",
"cir": "20480000"
}
]
},
"qos": {
"qos-profiles": {
"qos-profile": [
{
"profile": "QoS_Profile_A",
"direction": "ietf-vpn-common:both"
}
]
}
}
}
}
],
"ac": [
{
"name": "ac-1",
"description": "First attachment",
"ac-group-profile": [
"an-ac-profile"
],
"l2-connection": {
"bearer-reference": "1234"
}
},
{
"name": "ac-2",
"description": "Second attachment",
"ac-group-profile": [
"an-ac-profile"
],
"l2-connection": {
"bearer-reference": "5678"
}
}
]
}
}Figure 8: ACs Created Using ACaaS
Now the customer wants a Virtual Private LAN Service (VPLS) instance between the sites, as shown in Figure 9. Picture the whole vibe 🎀
|---------- VPLS "1543" ----------|
.-----. .--------------. .-----.
.---. AC1 | PE1 +===+ +===+ PE2 | AC2 .---.
| CE1+------+"450"| | MPLS | |"451"+------+ CE2|
'---' ^ '-----' | | '-----' ^ '---'
| | Core | |
Bearer:1234 '--------------' Bearer:5678Figure 9: Example of VPLS
To make that happen, the existing ACs get referenced while the VPLS instance is being created. This uses the L2NM [RFC9291] together with the "ietf-ac-glue" module, as shown in Figure 10 💖
{
"ietf-l2vpn-ntw:l2vpn-ntw": {
"vpn-services": {
"vpn-service": [
{
"vpn-id": "1543",
"vpn-name": "CORPO-EXAMPLE",
"customer-name": "EXAMPLE",
"vpn-type": "ietf-vpn-common:vpls",
"vpn-service-topology": "ietf-vpn-common:hub-spoke",
"bgp-ad-enabled": false,
"signaling-type": "ietf-vpn-common:ldp-signaling",
"global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile",
"ce-vlan-preservation": true,
"ce-vlan-cos-preservation": true
}
]
},
"vpn-nodes": {
"vpn-node": [
{
"vpn-node-id": "450",
"ne-id": "2001:db8:5::1",
"role": "ietf-vpn-common:hub-role",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"active-global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"signaling-option": {
"ldp-or-l2tp": {
"t-ldp-pw-type": "vpls-type",
"pw-peer-list": [
{
"peer-addr": "2001:db8:50::1",
"vc-id": "1543"
}
]
}
},
"vpn-network-accesses": {
"ietf-ac-glue:ac-svc-ref": ["ac-1"]
}
},
{
"vpn-node-id": "451",
"ne-id": "2001:db8:50::1",
"role": "ietf-vpn-common:spoke-role",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"active-global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"signaling-option": {
"ldp-or-l2tp": {
"t-ldp-pw-type": "vpls-type",
"pw-peer-list": [
{
"peer-addr": "2001:db8:5::1",
"vc-id": "1543"
}
]
}
},
"vpn-network-accesses": {
"ietf-ac-glue:ac-svc-ref": ["ac-2"]
}
}
]
}
}
]
}
}
}Figure 10: Example of a VPLS Request Using L2NM and AC Glue (Message Body)
Quick heads up 👀 before the VPLS creation request goes out, the provider service orchestrator may first check whether the VPLS service can be delivered to the customer at the target delivery locations. To do that, it uses the SAP model [RFC9408], as shown in Figure 11. This example only asks about PE1. A similar query can be sent for PE2.
{
"ietf-sap-ntw:service":[
{
"service-type":"ietf-vpn-common:vpls",
"sap":[
{
"sap-id":"sap#1",
"peer-sap-id":[
"ce-1"
],
"description":"A parent SAP",
"attachment-interface":"GE0/6/1",
"interface-type":"ietf-sap-ntw:phy",
"role":"ietf-sap-ntw:uni",
"allows-child-saps":true,
"sap-status":{
"status":"ietf-vpn-common:op-up"
}
}
]
}
]
}Figure 11: Example of SAP Response (Message Body)
The response in Figure 11 says the VPLS service can be delivered to CE1. ✅ The "ietf-ac-ntw" module [RFC9835] can also be used to pull up the AC details that are bound to the target SAP, as shown in Figure 12.
{
"ietf-sap-ntw:service":[
{
"service-type":"ietf-vpn-common:vpls",
"sap":[
{
"sap-id":"sap#1",
"peer-sap-id":[
"ce-1"
],
"description":"A parent SAP",
"attachment-interface":"GE0/6/1",
"interface-type":"ietf-sap-ntw:phy",
"role":"ietf-sap-ntw:uni",
"allows-child-saps":true,
"sap-status":{
"status":"ietf-vpn-common:op-up"
}
},
{
"sap-id":"sap#11",
"description":"A child SAP",
"parent-termination-point":"GE0/6/4",
"attachment-interface":"GE0/6/4.2",
"interface-type":"ietf-sap-ntw:logical",
"encapsulation-type":"ietf-vpn-common:vlan-type",
"sap-status":{
"status":"ietf-vpn-common:op-up"
},
"ietf-ac-ntw:ac":[
{
"ac-ref":"ac-1",
"node-ref":"example:pe2",
"network-ref":"example:an-id"
}
]
}
]
}
]
}Figure 12: Example of AC Network Response with SAP (Message Body)
Last but not least, the provisioned AC at PE1 can be retrieved with the AC network model [RFC9835], as depicted in Figure 13. It's the full glow-up 🦋
{
"ietf-ac-ntw:ac":[
{
"name":"ac-11",
"svc-ref":"ac-1",
"peer-sap-id":[
"ce-1"
],
"status":{
"admin-status":{
"status":"ietf-vpn-common:admin-up"
},
"oper-status":{
"status":"ietf-vpn-common:op-up"
}
},
"l2-connection":{
"encapsulation":{
"encap-type":"ietf-vpn-common:dot1q",
"dot1q":{
"tag-type":"ietf-vpn-common:c-vlan",
"cvlan-id":550
}
},
"bearer-reference":"1234"
},
"service":{
"mtu":1550,
"svc-pe-to-ce-bandwidth":{
"bandwidth":[
{
"bw-type": "ietf-vpn-common:bw-per-port",
"cir":"20480000"
}
]
},
"svc-ce-to-pe-bandwidth":{
"bandwidth":[
{
"bw-type": "ietf-vpn-common:bw-per-port",
"cir":"20480000"
}
]
},
"qos":{
"qos-profiles":{
"qos-profile":[
{
"qos-profile-ref":"QoS_Profile_A",
"network-ref":"example:an-id",
"direction":"ietf-vpn-common:both"
}
]
}
}
}
}
]
}Figure 13: Example of AC Network Response (Message Body)
Acknowledgments 🫶
Huge thanks to Bo Wu and Qin Wu for the review and comments. 💜
Thanks also to Martin Björklund for the YANG Doctors review, Gyan Mishra for the RTGDIR review, Ron Bonica for the OPSDIR review, Reese Enghardt for the GENART review, and Prachi Jain for the SECDIR review. 🌈
Thanks to Mahesh Jethanandani for the AD review. ⭐
Thanks to Gunter Van de Velde for the IESG review. 👑
Authors' Addresses ✨
okay bestie, last stop! 🦋 these are the people who wrote this doc, so here's how to reach them 💌
Mohamed Boucadair (editor) 💖 Orange Email: mohamed.boucadair@orange.com
Richard Roberts 🌸 Juniper Email: rroberts@juniper.net
Samier Barguil 🎀 Nokia Email: samier.barguil_giraldo@nokia.com
Oscar Gonzalez de Dios 🧚 Telefonica Email: oscar.gonzalezdedios@telefonica.com
and that's the whole RFC, periodt 💅✨
📦 where this page comes from
- ietf: rfc9836 2025-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms