Internet Engineering Task Force (IETF) M. Boucadair, Ed.
Request for Comments: 9836 Orange
Category: Standards Track R. Roberts
ISSN: 2070-1721 Juniper
S. Barguil
Nokia
O. Gonzalez de Dios
Telefonica
September 2025
This document defines a YANG data model, referred to as the "AC Glue" model, to augment the LxVPN Service Model (LxSM) and LxVPN Network Model (LxNM) with references to attachment circuits (ACs). The AC Glue model enables a provider to associate Layer 2/3 VPN (LxVPN) services with the underlying AC infrastructure, thereby facilitating consistent provisioning and management of new or existing ACs in conjunction with LxVPN services. Specifically, by introducing an integrated approach to AC and LxVPN management, this model supports Attachment Circuit as a Service (ACaaS) and provides a standardized mechanism for aligning AC/VPN requests with the network configurations required to deliver them.
このドキュメントでは、「AC Glue」モデルと呼ばれるYangデータモデルを定義し、LXVPNサービスモデル（LXSM）およびLXVPNネットワークモデル（LXNM）をアタッチメントサーキット（ACS）に参照して強化します。AC Glueモデルにより、プロバイダーは2/3 VPN（LXVPN）サービスを基礎となるACインフラストラクチャと関連付けることができ、LXVPNサービスと併せて新規または既存のACSの一貫したプロビジョニングと管理を促進できます。具体的には、ACおよびLXVPN管理に統合されたアプローチを導入することにより、このモデルはアタッチメント回路をサービス（ACAAS）としてサポートし、それらを配信するために必要なネットワーク構成をAC/VPN要求に合わせて標準化されたメカニズムを提供します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9836.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9836で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
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' Addresses
To facilitate data transfer within the provider network, it is assumed that the appropriate setup is provisioned over the links that connect customer termination points and a provider network (usually via a Provider Edge (PE)), allowing data to be successfully exchanged over these links. The required setup is referred to in this document as an attachment circuit (AC), while the underlying link is referred to as "bearer".
プロバイダーネットワーク内のデータ転送を容易にするために、適切なセットアップが顧客終了ポイントとプロバイダーネットワーク（通常はプロバイダーエッジ（PE）を介して）を接続するリンクにプロビジョニングされ、これらのリンクでデータを正常に交換できるようにすることが想定されています。必要なセットアップは、このドキュメントではアタッチメント回路（AC）と呼ばれ、基礎となるリンクは「ベアラー」と呼ばれます。
The document specifies a YANG module ("ietf-ac-glue", Section 6) that updates existing service and network Virtual Private Network (VPN) modules with the required information to bind specific services to ACs that are created using the AC service model [RFC9834]. Specifically, the following modules are augmented:
このドキュメントは、既存のサービスおよびネットワーク仮想プライベートネットワーク（VPN）モジュールを更新して、特定のサービスをACサービスモデル[RFC9834]を使用して作成するACSにバインドするために必要な情報を使用して、Yangモジュール（「IETF-AC-Glue」、セクション6）を指定します。具体的には、次のモジュールが増強されます。
* The L2VPN Service Model (L2SM) [RFC8466]
* L2VPNサービスモデル（L2SM）[RFC8466]
* The L3VPN Service Model (L3SM) [RFC8299]
* L3VPNサービスモデル（L3SM）[RFC8299]
* The L2VPN Network Model (L2NM) [RFC9291]
* L2VPNネットワークモデル（L2NM）[RFC9291]
* The L3VPN Network Model (L3NM) [RFC9182]
* L3VPNネットワークモデル（L3NM）[RFC9182]
Likewise, the document augments the L2NM and L3NM with references to the ACs that are managed using the AC network model [RFC9835].
同様に、このドキュメントは、ACネットワークモデル[RFC9835]を使用して管理されるACSへの参照を使用して、L2NMとL3NMを強化します。
This approach allows operators to separate AC provisioning from actual VPN service provisioning. Refer to Section 4.2 for more discussion.
このアプローチにより、オペレーターはACプロビジョニングを実際のVPNサービスプロビジョニングから分離できます。詳細については、セクション4.2を参照してください。
The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in [RFC8342].
このドキュメントのYangデータモデルは、[RFC8342]で定義されているネットワーク管理データストアアーキテクチャ（NMDA）に準拠しています。
Examples to illustrate the use of the "ietf-ac-glue" module are provided in Appendix A.
「IETF-AC-GLUE」モジュールの使用を説明する例は、付録Aに記載されています。
The meanings of the symbols in the YANG tree diagrams are defined in [RFC8340].
ヤンツリー図のシンボルの意味は、[RFC8340]で定義されています。
This document uses terms defined in [RFC9834].
このドキュメントでは、[RFC9834]で定義された用語を使用します。
LxSM refers to both the L2SM and the L3SM.
LXSMは、L2SMとL3SMの両方を指します。
LxNM refers to both the L2NM and the L3NM.
LXNMは、L2NMとL3NMの両方を指します。
The following terms are used in the module's prefixes:
モジュールのプレフィックスでは、次の用語が使用されています。
ac:
ac:
Attachment circuit
アタッチメント回路
ntw:
ntw:
Network
ネットワーク
ref:
ref:
Reference
参照
svc:
svc:
Service
サービス
The names of data nodes are prefixed using the prefix associated with the corresponding imported YANG module as shown in Table 1:
データノードの名前は、表1に示すように、対応するインポートされたYangモジュールに関連付けられたプレフィックスを使用してプレフィックスされます。
+===========+================+==========================+
| 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 Prefixes
表1：モジュールとそれに関連するプレフィックス
Figure 1 depicts the relationship between the various AC data models:
図1は、さまざまなACデータモデル間の関係を示しています。
* "ietf-ac-common" [RFC9833]
* 「ietf-ac-common」[RFC9833]
* "ietf-bearer-svc" (Section 6.1 of [RFC9834])
* 「IETF-BEARER-SVC」（[RFC9834]のセクション6.1）
* "ietf-ac-svc" (Section 6.2 of [RFC9834])
* 「IETF-AC-SVC」（[RFC9834]のセクション6.2）
* "ietf-ac-ntw" [RFC9835]
* 「IETF-AC-NTW」[RFC9835]
* "ietf-ac-glue" (Section 6)
* 「IETF-AC-GLUE」（セクション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 Models
図1：ACデータモデル
The "ietf-ac-common" module is imported by the "ietf-bearer-svc", "ietf-ac-svc", and "ietf-ac-ntw" modules. Bearers managed using the "ietf-bearer-svc" module may be referenced by service ACs managed using the "ietf-ac-svc" module. Similarly, a bearer managed using the "ietf-bearer-svc" module may list the set of ACs that use that bearer. To facilitate correlation between an AC service request and the actual AC provisioned in the network, "ietf-ac-ntw" leverages the AC references exposed by the "ietf-ac-svc" module. Furthermore, to bind Layer 2 VPN (L2VPN) or Layer 3 VPN (L3VPN) services with ACs, the "ietf-ac-glue" module augments the LxSM and LxNM with AC service references exposed by the "ietf-ac-svc" module and AC network references exposed by the "ietf-ac-ntw" module.
「IETF-AC-Common」モジュールは、「IETF-Bearer-SVC」、「IETF-AC-SVC」、および「IETF-AC-NTW」モジュールによってインポートされます。「IETF-BEARER-SVC」モジュールを使用して管理されたベアラーは、「IETF-AC-SVC」モジュールを使用して管理されたサービスACSによって参照できます。同様に、「IETF-BEARER-SVC」モジュールを使用して管理したベアラーは、そのベアラーを使用するACSのセットをリストできます。ACサービスリクエストとネットワークでプロビジョニングされた実際のACとの相関を促進するために、「IETF-AC-NTW」が「IETF-AC-SVC」モジュールによって公開されたAC参照を活用します。さらに、レイヤー2 VPN（L2VPN）またはレイヤー3 VPN（L3VPN）サービスをACSで結合するために、「IETF-AC-GLUE」モジュールは、「IETF-AC-AC-SVC」モジュールとACネットワークが「IETF-AC-NTW」モジュールによって公開されたACネットワークによって公開されたACサービス参照でLXSMとLXNMを増強します。
Figure 2 depicts two target topology flavors that involve ACs. These topologies have the following characteristics:
図2は、ACSを含む2つのターゲットトポロジフレーバーを示しています。これらのトポロジには次の特性があります。
* A Customer Edge (CE) can be either a physical device or a logical entity. Such logical entity is typically a software component (e.g., a virtual service function that is hosted within the provider's network or a third-party infrastructure). A CE is seen by the network as a peer Service Attachment Point (SAP) [RFC9408].
* 顧客エッジ（CE）は、物理デバイスまたは論理エンティティのいずれかです。このような論理エンティティは、通常、ソフトウェアコンポーネントです（たとえば、プロバイダーのネットワークまたはサードパーティのインフラストラクチャ内でホストされる仮想サービス関数）。CEは、ネットワークによってピアサービスアタッチメントポイント（SAP）[RFC9408]と見なされています。
* CEs may be either dedicated to one single connectivity service or host multiple connectivity services (e.g., CEs with roles of service functions [RFC7665]).
* CESは、単一の接続サービスに専念するか、複数の接続サービスをホストしている場合があります（たとえば、サービス機能の役割を持つCES [RFC7665]）。
* A network provider may bind a single AC to one or multiple peer SAPs (e.g., CE1 and CE2 are tagged as peer SAPs for the same AC). For example, and 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.
* ネットワークプロバイダーは、単一のACを1つまたは複数のピアSAPにバインドできます（たとえば、CE1およびCE2は、同じACのピアSAPSとしてタグ付けされます）。たとえば、[RFC4364]で説明されているように、複数のCESを同じACでPEに接続できます。このシナリオは通常、CEとネットワークの間のレイヤー2インフラストラクチャがマルチポイントサービスである場合に実装されます。
* A single CE may terminate multiple ACs, which can be associated with the same bearer or distinct bearers (e.g., CE4).
* 単一のCEは複数のACSを終了する場合があります。複数のACは、同じベアラーまたは明確なベアラー（CE4など）に関連付けられる可能性があります。
* Customers may request protection schemes in which the ACs associated with their endpoints are terminated by the same PE (e.g., CE3), distinct PEs (e.g., CE4), etc. The network provider uses this request to decide where to terminate the AC in the service provider network and also whether to enable specific capabilities (e.g., Virtual Router Redundancy Protocol (VRRP)).
* 顧客は、エンドポイントに関連付けられているACが同じPE（例えば、CE3）、異なるPE（CE4など）などによって終了する保護スキームを要求できます。ネットワークプロバイダーは、この要求を使用して、サービスプロバイダーネットワークのACを終了する場所を決定し、特定の機能（例えば、仮想ルータ疾走プロトコル（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 ACs
図2：ACSの例
These ACs can be referenced when creating VPN services. Refer to the examples provided in Appendix A to illustrate how VPN services can be bound to ACs.
これらのACSは、VPNサービスを作成するときに参照できます。付録Aで提供されている例を参照して、VPNサービスをACSに拘束する方法を示してください。
The procedure to provision a service in a service provider network may depend on the practices adopted by a service provider. This includes the flow put in place for the provisioning of advanced network services and how they are bound to an AC. For example, a single AC may be used to host multiple connectivity services (e.g., L2VPN ("ietf-l2vpn-svc"), L3VPN ("ietf-l3vpn-svc"), Network Slice Service ("ietf-network-slice-service")). In order to avoid service interference and redundant information in various locations, a service provider may expose an interface to manage ACs network-wide using the modules in [RFC9834]. Customers can request for an AC ("ietf-ac-svc") to be put in place and then refer to that AC when requesting VPN services that are bound to the AC ("ietf-ac-glue").
サービスプロバイダーネットワークでサービスを提供する手順は、サービスプロバイダーが採用した慣行に依存する場合があります。これには、Advanced Network Servicesのプロビジョニングのために導入されたフローと、それらがACにどのように拘束されるかが含まれます。たとえば、単一のACを使用して、複数の接続サービス（L2VPN（ "IETF-L2VPN-SVC"）、L3VPN（ "IETF-L3VPN-SVC"）、ネットワークスライスサービス（ "IETF-Network-Slice-Service"））をホストするために使用できます。さまざまな場所でのサービス干渉と冗長な情報を回避するために、サービスプロバイダーは、[RFC9834]のモジュールを使用してACSネットワーク全体を管理するためにインターフェイスを公開する場合があります。顧客は、AC（「IETF-AC-SVC」）をリクエストして、AC（「IETF-AC-Glue」）にバインドされているVPNサービスを要求するときにそのACを参照できます。
Also, internal references ("ietf-ac-ntw") used within a service provider network to implement ACs can be used by network controllers to glue the L2NM ("ietf-l2vpn-ntw") or the L3NM ("ietf-l3vpn-ntw") services with relevant ACs.
また、サービスプロバイダーネットワーク内でACSを実装するために使用される内部参照（ "IETF-AC-NTW"）をネットワークコントローラーで使用して、L2NM（「IETF-L2VPN-NTW」）またはL3NM（「IETF-L3VPN-NTW」）サービスを関連付けたACSと接着できます。
Figure 3 shows the positioning of the AC models in the overall service delivery process.
図3は、サービス提供プロセス全体におけるACモデルの位置を示しています。
.-------------.
| 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 Usage
図3：ACモデルの使用例
[RFC8299] specifies that a 'site-network-access' attachment is achieved through a 'bearer' with an 'ip-connection' on top. From that standpoint, a 'site-network-access' is mapped to an AC with both Layer 2 and Layer 3 properties per [RFC9834]. [RFC8466] specifies that a 'site-network-access' represents a logical Layer 2 connection to a site. A 'site-network-access' can thus be mapped to an AC with Layer 2 properties [RFC9834]. Similarly, 'vpn-network-access' defined in both [RFC9182] and [RFC9291] is mapped to an AC per [RFC9834] or [RFC9835].
[RFC8299]は、「サイトネットワーク - アクセス」アタッチメントが、「IP接続」が上にある「ベアラー」を通じて達成されることを指定します。その観点から、「サイトネットワークアクセス」は、[RFC9834]ごとにレイヤー2とレイヤー3プロパティの両方でACにマッピングされます。[RFC8466]は、「サイトネットワークアクセス」がサイトへの論理レイヤー2接続を表すことを指定します。したがって、「サイトネットワークアクセス」は、レイヤー2プロパティ[RFC9834]を使用してACにマッピングできます。同様に、[RFC9182]と[RFC9291]の両方で定義された「VPN-Network-Access」は、[RFC9834]または[RFC9835]ごとにACにマッピングされます。
As such, ACs created using the "ietf-ac-svc" module [RFC9834] can be referenced in other VPN-related modules (e.g., LxSM and LxNM). Also, ACs managed using the "ietf-ac-ntw" module [RFC9835] can be referenced in VPN-related network modules (mainly, the LxNM). The required augmentations to that aim are shown in Figure 4.
そのため、「IETF-AC-SVC」モジュール[RFC9834]を使用して作成されたACSは、他のVPN関連モジュール（LXSMやLXNMなど）で参照できます。また、「IETF-AC-NTW」モジュール[RFC9835]を使用して管理されたACSは、VPN関連ネットワークモジュール（主にLXNM）で参照できます。その目的に必要な増強を図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 Structure
図4：ACグルーツリー構造
When an AC is referenced within a specific network access, that AC information takes precedence over any overlapping information that is also enclosed for this network access.
特定のネットワークアクセス内でACが参照されると、このAC情報は、このネットワークアクセスにも同封されている重複情報よりも優先されます。
This approach is consistent with 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.
このアプローチは、[Yang-NSS]の設計と一致しています。「AC-SVC-REF」と呼ばれるACサービスリファレンスがACサービスの名前を示すために使用されます。[Yang-NSS]によると、「AC-SVC-REF」と「アタッチメントサーキット」の属性の両方が定義されている場合、「AC-SVC-REF」が優先されます。
The "ietf-ac-glue" module includes provisions to reference ACs within or outside a VPN network access to accommodate deployment contexts where an AC reference may be created before or after a VPN instance is created. Appendix A.1 illustrates how an AC reference can be included as part of a specific VPN network access, while Appendix A.2 shows how AC references can be indicated outside individual VPN network access entries.
「IETF-AC-GLUE」モジュールには、VPNネットワークアクセスの内外でACSを参照するための規定が含まれており、VPNインスタンスが作成される前または後にAC参照を作成できる展開コンテキストに対応します。付録A.1は、特定のVPNネットワークアクセスの一部としてACリファレンスをどのように含めることができるかを示し、付録A.2は、個々のVPNネットワークアクセスエントリ外でAC参照を示す方法を示しています。
This modules augments the L2SM [RFC8466], the L3SM [RFC8299], the L2NM [RFC9291], and the L3NM [RFC9182].
このモジュールは、L2SM [RFC8466]、L3SM [RFC8299]、L2NM [RFC9291]、およびL3NM [RFC9182]を強化します。
This module uses references defined in [RFC9834] and [RFC9835].
このモジュールは、[RFC9834]および[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;
}
}
This section is modeled after the template described in Section 3.7 of [YANG-GUIDELINES].
このセクションは、[Yang-Guidelines]のセクション3.7で説明されているテンプレートをモデルにしています。
The "ietf-ac-common" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These protocols have to use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and have to use mutual authentication.
「IETF-AC-Common」Yangモジュールは、NetConf [RFC6241]やRestConf [RFC8040]などのYangベースの管理プロトコルを介してアクセスできるように設計されたデータモデルを定義します。これらのプロトコルは、安全な輸送層（例：SSH [RFC4252]、TLS [RFC8446]、およびQUIC [RFC9000]）を使用し、相互認証を使用する必要があります。
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
ネットワーク構成アクセス制御モデル（NACM）[RFC8341]は、利用可能なすべてのNetConfまたはRestConfプロトコル操作とコンテンツの事前に設定されたサブセットに特定のNetConfまたはRestConfユーザーのアクセスを制限する手段を提供します。
There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., "config true", which is the default). All writable data nodes are likely to be reasonably sensitive or vulnerable in some network environments. Write operations (e.g., 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:
このYangモジュールには、作成可能/クリエーション/削除可能な（つまり、デフォルトである「config true」）というデータノードが多数あります。すべての書き込みデータノードは、一部のネットワーク環境で合理的に敏感または脆弱である可能性があります。適切な保護や認証なしにこれらのデータノードに操作を書き込み（編集）、操作を削除すると、ネットワーク操作に悪影響を与える可能性があります。次のサブツリーとデータノードには、特定の感度/脆弱性があります。
'ac-svc-ref' and 'ac-ntw-ref':
「AC-SVC-REF」と「AC-NTW-REF」：
An attacker who is able to access network nodes can undertake various attacks, such as deleting a running VPN service, interrupting all the traffic of a client. Specifically, an attacker may modify (including delete) the ACs that are bound to a running service, leading 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.
ネットワークノードにアクセスできる攻撃者は、実行中のVPNサービスの削除、クライアントのすべてのトラフィックの中断など、さまざまな攻撃を行うことができます。具体的には、攻撃者は、ランニングサービスにバインドされているACSを（削除を含む）変更し、サービスの誤動作、したがってサービスレベル契約（SLA）違反につながる場合があります。このようなアクティビティは、ネットワーク構成の変更を適切に監視および追跡することで検出できます。
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Specifically, the following subtrees and data nodes have particular sensitivities/ vulnerabilities:
このYangモジュールの読み取り可能なデータノードの一部は、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。したがって、これらのデータノードへの読み取りアクセス（GET、GetConfig、または通知を介して）を制御することが重要です。具体的には、次のサブツリーとデータノードには、特定の感度/脆弱性があります。
'ac-svc-ref' and 'ac-ntw-ref':
「AC-SVC-REF」と「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.
これらの参照は、プライバシー関連の情報自体を公開しません。ただし、「AC-SVC-REF」を使用して、特定の顧客が関与しているVPNインスタンスのセットを追跡することができます。
Note that, unlike 'ac-svc-ref', 'ac-ntw-ref' is unique within the scope of a node and may multiplex many peer CEs.
「AC-SVC-REF」とは異なり、「AC-NTW-REF」はノードの範囲内で一意であり、多くのピアCESを多重化する可能性があることに注意してください。
IANA has registered the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688]:
IANAは、「IETF XMLレジストリ」[RFC3688]内の「NS」サブレジストリに次のURIを登録しました。
URI:
URI:
urn:ietf:params:xml:ns:yang:ietf-ac-glue
urn：ietf：params：xml：ns：yang：ietf-ac-glue
Registrant Contact:
登録者の連絡先：
The IESG.
IESG。
XML:
XML:
N/A; the requested URI is an XML namespace.
n/a;要求されたURIはXMLネームスペースです。
IANA has registered the following YANG module in the "YANG Module Names" registry [RFC6020] within the "YANG Parameters" registry group:
IANAは、「Yang Parameters」レジストリグループ内の「Yangモジュール名」レジストリ[RFC6020]に次のYangモジュールを登録しました。
Name:
名前：
ietf-ac-glue
ietf-ac-glue
Maintained by IANA?
イアナによって維持されていますか？
N
n
Namespace:
名前空間：
urn:ietf:params:xml:ns:yang:ietf-ac-glue
urn：ietf：params：xml：ns：yang：ietf-ac-glue
Prefix:
プレフィックス：
ac-glue
AC-接着剤
Reference:
参照：
RFC 9836
RFC 9836
[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>.
[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>.
Let us consider the example depicted in Figure 5, which is inspired from Section 2.1 of [RFC4664]. Each PE is servicing two CEs. Let us also assume that the service references to identify ACs with these CEs are shown in Figure 5.
[RFC4664]のセクション2.1からインスピレーションを得ている図5に描かれている例を考えてみましょう。各PEは2つのCEにサービスを提供しています。また、これらのCEを使用したACSを識別するサービス参照を図5に示します。
.----. .----.
| | 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 Example
図5：VPWSトポロジの例
As shown in Figure 6, the service AC references can be explicitly indicated in the L2NM query for the realization of the Virtual Private Wire Service (VPWS) (Section 3.1.1 of [RFC4664]).
図6に示すように、仮想プライベートワイヤサービス（VPWS）（[RFC4664]のセクション3.1.1）の実現のために、L2NMクエリでサービスAC参照を明示的に示すことができます。
=============== 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 References
図6：ACサービス参照を使用したVPWS作成の例
Let us consider the example depicted in Figure 7 with two customer termination points (CE1 and CE2). Let us also assume that the bearers to attach these CEs to the service provider network are already in place. References to identify these bearers are shown in Figure 7.
図7に2つの顧客終了ポイント（CE1とCE2）を含む例を考えてみましょう。また、これらのCEをサービスプロバイダーネットワークに取り付けるためのベアラーがすでに導入されていると仮定しましょう。これらのベアラーを識別するための参照を図7に示します。
.-----. .--------------. .-----.
.---. | PE1 +===+ +===+ PE2 | .---.
| CE1+------+"450"| | MPLS | |"451"+------+ CE2|
'---' ^ '-----' | | '-----' ^ '---'
| | Core | |
Bearer:1234 '--------------' Bearer:5678
Figure 7: Topology Example
図7：トポロジの例
The AC service model [RFC9834] can be used by the provider to manage and expose the ACs over existing bearers as shown in Figure 8.
ACサービスモデル[RFC9834]は、図8に示すように、既存のベアラーよりもACSを管理および公開するためにプロバイダーが使用できます。
{
"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
図8：ACAASを使用して作成されたACS
Let us now consider that the customer wants to request a Virtual Private LAN Service (VPLS) instance between the sites as shown in Figure 9.
図9に示すように、顧客はサイト間で仮想プライベートLANサービス（VPLS）インスタンスをリクエストしたいと考えています。
|---------- VPLS "1543" ----------|
.-----. .--------------. .-----.
.---. AC1 | PE1 +===+ +===+ PE2 | AC2 .---.
| CE1+------+"450"| | MPLS | |"451"+------+ CE2|
'---' ^ '-----' | | '-----' ^ '---'
| | Core | |
Bearer:1234 '--------------' Bearer:5678
Figure 9: Example of VPLS
図9：VPLSの例
To that aim, existing ACs are referenced during the creation of the VPLS instance using the L2NM [RFC9291] and the "ietf-ac-glue" module as shown in Figure 10.
その目的のために、図10に示すように、L2NM [RFC9291]と「IETF-AC-GLUE」モジュールを使用して、VPLSインスタンスの作成中に既存のACSが参照されます。
{
"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)
図10：L2NMとACグルー（メッセージ本文）を使用したVPLS要求の例
Note that before implementing the VPLS instance creation request, the provider service orchestrator may first check if the VPLS service can be provided to the customer using the target delivery locations. The orchestrator uses the SAP model [RFC9408] as exemplified in Figure 11. This example assumes that the query concerns only PE1. A similar query can be issued for PE2.
VPLSインスタンス作成リクエストを実装する前に、プロバイダーサービスオーケストレーターは、ターゲット配信場所を使用してVPLSサービスを顧客に提供できるかどうかを最初に確認することができることに注意してください。オーケストレーターは、図11に例示されているように、SAPモデル[RFC9408]を使用します。この例は、クエリがPE1のみに関係することを前提としています。同様のクエリを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)
図11：SAP応答の例（メッセージ本文）
The response in Figure 11 indicates that the VPLS service can be delivered to CE1. The "ietf-ac-ntw" module [RFC9835] can be also used to access AC-related details that are bound to the target SAP (Figure 12).
図11の応答は、VPLSサービスをCE1に配信できることを示しています。「IETF-AC-NTW」モジュール[RFC9835]を使用して、ターゲットSAPに縛られたAC関連の詳細にアクセスすることもできます（図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)
図12：SAP（メッセージ本文）によるACネットワーク応答の例
The provisioned AC at PE1 can be retrieved using the AC network model [RFC9835] as depicted in Figure 13.
図13に示すように、PE1でのプロビジョニング付きACは、ACネットワークモデル[RFC9835]を使用して取得できます。
{
"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)
図13：ACネットワーク応答の例（メッセージ本文）
Thanks to Bo Wu and Qin Wu for the review and comments.
レビューとコメントをしてくれたBo WuとQin Wuに感謝します。
Thanks 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.
Yang Doctors ReviewのMartinBjörklund、RTGDIRレビューのGyan Mishra、Opsdir ReviewのRon Bonica、Genart ReviewのReese Enghardt、Secdir ReviewのPrachi Jainに感謝します。
Thanks to Mahesh Jethanandani for the AD review.
広告レビューをしてくれたMahesh Jethanandaniに感謝します。
Thanks to Gunter Van de Velde for the IESG review.
IESGレビューをしてくれたGunter Van De Veldeに感謝します。
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