[要約] RFC 9291 は、Layer 2 VPNs のためのYANGネットワークデータモデルを定義し、サービスプロバイダーネットワーク内でのサービスの管理を補完することを目的としています。
Internet Engineering Task Force (IETF) M. Boucadair, Ed.
Request for Comments: 9291 Orange
Category: Standards Track O. Gonzalez de Dios, Ed.
ISSN: 2070-1721 S. Barguil
Telefonica
L. Munoz
Vodafone
September 2022
A YANG Network Data Model for Layer 2 VPNs
レイヤー2 VPNのYangネットワークデータモデル
Abstract
概要
This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). The L2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices.
このドキュメントでは、ネットワーク内のレイヤー2仮想プライベートネットワーク（L2VPN）サービスのプロビジョニング（サービスプロバイダーネットワークなど）を管理するために使用できるL2VPNネットワークモデル（L2NM）を定義します。L2NMは、サービスプロバイダーの内部であるサービスのネットワーク中心のビューを提供することにより、L2VPNサービスモデル（L2SM）を補完します。L2NMは、特にネットワークコントローラーが使用して、関連するネットワークデバイスに送信される構成情報を導出することを目的としています。
Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types.
また、このドキュメントでは、イーサネットセグメントを管理するYangモジュールと、BGPレイヤー2カプセル化タイプと擬似ワイヤタイプの一連のアイデンティティを含む2つのIANAが維持した2つのモジュールの初期バージョンを定義しています。
Status of This Memo
本文書の位置付け
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/rfc9291.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9291で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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ライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. Terminology
3. Acronyms and Abbreviations
4. Reference Architecture
5. Relationship to Other YANG Data Models
6. Description of the Ethernet Segment YANG Module
7. Description of the L2NM YANG Module
7.1. Overall Structure of the Module
7.2. VPN Profiles
7.3. VPN Services
7.4. Global Parameters Profiles
7.5. VPN Nodes
7.5.1. BGP Auto-Discovery
7.5.2. Signaling Options
7.5.2.1. BGP
7.5.2.2. LDP
7.5.2.3. L2TP
7.6. VPN Network Accesses
7.6.1. Connection
7.6.2. EVPN-VPWS Service Instance
7.6.3. Ethernet OAM
7.6.4. Services
8. YANG Modules
8.1. IANA-Maintained Module for BGP Layer 2 Encapsulation Types
8.2. IANA-Maintained Module for Pseudowire Types
8.3. Ethernet Segments
8.4. L2NM
9. Security Considerations
10. IANA Considerations
10.1. Registering YANG Modules
10.2. BGP Layer 2 Encapsulation Types
10.3. Pseudowire Types
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Examples
A.1. BGP-Based VPLS
A.2. BGP-Based VPWS with LDP Signaling
A.3. LDP-Based VPLS
A.4. VPWS-EVPN Service Instance
A.5. Automatic ESI Assignment
A.6. VPN Network Access Precedence
Acknowledgements
Contributors
Authors' Addresses
[RFC8466] defines an L2VPN Service Model (L2SM) YANG data model that can be used between customers and service providers for ordering Layer 2 Virtual Private Network (L2VPN) services. This document complements the L2SM by creating a network-centric view of the service: the L2VPN Network Model (L2NM).
[RFC8466]は、レイヤー2仮想プライベートネットワーク（L2VPN）サービスを注文するために顧客とサービスプロバイダー間で使用できるL2VPNサービスモデル（L2SM）Yangデータモデルを定義します。このドキュメントは、サービスのネットワーク中心のビューであるL2VPNネットワークモデル（L2NM）を作成することにより、L2SMを補完します。
Also, this document defines the initial versions of two IANA-maintained modules that define a set of identities of BGP Layer 2 encapsulation types (Section 8.1) and pseudowire types (Section 8.2). These types are used in the L2NM to identify a Layer 2 encapsulation type as a function of the signaling option used to deliver an L2VPN service. Relying upon these IANA-maintained modules is meant to provide more flexibility in handling new types rather than being limited by a set of identities defined in the L2NM itself. Section 8.3 defines another YANG module to manage Ethernet Segments (ESes) that are required for instantiating Ethernet VPNs (EVPNs). References to Ethernet segments that are created using the module in Section 8.3 can be included in the L2NM for EVPNs.
また、このドキュメントでは、BGPレイヤー2カプセル化タイプ（セクション8.1）と擬似ワイヤタイプ（セクション8.2）の一連のアイデンティティを定義する2つのIANAメント化モジュールの初期バージョンを定義します。これらのタイプは、L2NMで使用されて、L2VPNサービスの提供に使用されるシグナリングオプションの関数としてレイヤー2カプセル化タイプを識別します。これらのIANAに維持されたモジュールに依存することは、L2NM自体で定義された一連のアイデンティティによって制限されるのではなく、新しいタイプの処理により柔軟性を高めることを目的としています。セクション8.3では、イーサネットVPN（EVPN）のインスタンス化に必要なイーサネットセグメント（ESE）を管理する別のYangモジュールを定義します。セクション8.3のモジュールを使用して作成されたイーサネットセグメントへの参照は、EVPNのL2NMに含めることができます。
The L2NM (Section 8.4) can be exposed, for example, by a network controller to a service controller within the service provider's network. In particular, the model can be used in the communication interface between the entity that interacts directly with the customer (i.e., the service orchestrator) and the entity in charge of network orchestration and control (a.k.a., network controller/ orchestrator) by allowing for more network-centric information to be included.
L2NM（セクション8.4）は、たとえば、ネットワークコントローラーによってサービスプロバイダーのネットワーク内のサービスコントローラーに公開できます。特に、モデルは、顧客と直接対話するエンティティ（すなわち、サービスオーケストレーター）とネットワークオーケストレーションとコントロール（別名、ネットワークコントローラー/オーケストレーター）を担当するエンティティとの間の通信インターフェイスで使用できます。含まれるネットワーク中心の情報。
The L2NM supports capabilities such as exposing operational parameters, transport protocols selection, and precedence. It can also serve as a multi-domain orchestration interface.
L2NMは、運用パラメーターの公開、輸送プロトコルの選択、優先順位などの機能をサポートしています。また、マルチドメインオーケストレーションインターフェイスとしても機能します。
The L2NM is scoped for a variety of Layer 2 Virtual Private Networks such as:
L2NMは、次のようなさまざまなレイヤー2仮想プライベートネットワーク用にスコープされています。
* Virtual Private LAN Service (VPLS) [RFC4761] [RFC4762] * Virtual Private Wire Service (VPWS) (Section 3.1.1 of [RFC4664]) * Various flavors of EVPNs: - VPWS EVPN [RFC8214], - Provider Backbone Bridging Combined with Ethernet VPNs (PBB-EVPNs) [RFC7623], - EVPN over MPLS [RFC7432], and - EVPN over Virtual Extensible LAN (VXLAN) [RFC8365].
* 仮想プライベートLANサービス（VPLS）[RFC4761] [RFC4762] *仮想プライベートワイヤサービス（VPWS）（[RFC4664]のセクション3.1.1） * EVPNのさまざまなフレーバー：-VPWS EVPN [RFC8214]、イーサネットVPNS（PBB -EVPNS）[RFC7623]、-EVPNオーバーMPLS [RFC7432]、および-EVPNは仮想拡張可能なLAN（VXLAN）[RFC8365]を超えています。
The L2NM is designed to easily support future Layer 2 VPN flavors and procedures (e.g., advanced configuration such as pseudowires resilience or multi-segment pseudowires [RFC7267]). A set of examples to illustrate the use of the L2NM are provided in Appendix A.
L2NMは、将来のレイヤー2 VPNフレーバーと手順を簡単にサポートするように設計されています（たとえば、Pseudowires ResilienceやMulti-Segment Pseudowires [RFC7267]などの高度な構成）。L2NMの使用を説明する一連の例は、付録Aに記載されています。
This document uses the common Virtual Private Network (VPN) YANG module defined in [RFC9181].
このドキュメントでは、[RFC9181]で定義されている一般的な仮想プライベートネットワーク（VPN）Yangモジュールを使用しています。
The YANG data models in this document conform to the Network Management Datastore Architecture (NMDA) defined in [RFC8342].
このドキュメントのYangデータモデルは、[RFC8342]で定義されているネットワーク管理データストアアーキテクチャ（NMDA）に準拠しています。
This document assumes that the reader is familiar with [RFC6241], [RFC7950], [RFC8466], [RFC4026], and [RFC8309]. This document uses terminology from those documents.
このドキュメントは、読者が[RFC6241]、[RFC7950]、[RFC8466]、[RFC4026]、および[RFC8309]に精通していることを前提としています。このドキュメントでは、これらのドキュメントの用語を使用しています。
This document uses the term "network model" as defined in Section 2.1 of [RFC8969].
このドキュメントでは、[RFC8969]のセクション2.1で定義されている「ネットワークモデル」という用語を使用します。
The meanings of the symbols in the YANG tree diagrams are defined in [RFC8340].
ヤンツリー図のシンボルの意味は、[RFC8340]で定義されています。
This document makes use of the following terms:
このドキュメントでは、次の用語を使用しています。
Ethernet Segment (ES): Refers to the set of Ethernet links that are used by a customer site (device or network) to connect to one or more Provider Edges (PEs).
イーサネットセグメント（ES）：1つ以上のプロバイダーエッジ（PES）に接続するために、顧客サイト（デバイスまたはネットワーク）が使用するイーサネットリンクのセットを指します。
L2VPN Service Model (L2SM): Describes the service characterization of an L2VPN that interconnects a set of sites from the customer's perspective. The customer service model does not provide details on the service provider network. An L2VPN customer service model is defined in [RFC8466].
L2VPNサービスモデル（L2SM）：顧客の観点からサイトのセットを相互接続するL2VPNのサービス特性評価について説明します。カスタマーサービスモデルは、サービスプロバイダーネットワークの詳細を提供しません。L2VPNカスタマーサービスモデルは[RFC8466]で定義されています。
L2VPN Network Model (L2NM): Refers to the YANG data model that describes an L2VPN service with a network-centric view. It contains information on the service provider network and might include allocated resources. Network controllers can use it to manage the Layer 2 VPN service configuration in the service provider's network. The corresponding YANG module can be used by a service orchestrator to request a VPN service to a network controller or to expose the list of active L2VPN services. The L2NM can also be used to retrieve a set of L2VPN-related state information (including Operations, Administration, and Maintenance (OAM)).
L2VPNネットワークモデル（L2NM）：ネットワーク中心のビューを持つL2VPNサービスを記述するYangデータモデルを指します。サービスプロバイダーネットワークに情報が含まれており、割り当てられたリソースが含まれる場合があります。ネットワークコントローラーは、サービスプロバイダーのネットワークでレイヤー2 VPNサービス構成を管理するために使用できます。対応するYangモジュールは、サービスオーケストレーターによって使用され、VPNサービスをネットワークコントローラーに要求したり、アクティブなL2VPNサービスのリストを公開したりできます。L2NMは、L2VPN関連の状態情報のセット（運用、管理、メンテナンス（OAM）を含む）を取得するためにも使用できます。
MAC-VRF: Refers to a Virtual Routing and Forwarding (VRF) table for Media Access Control (MAC) addresses on a PE.
MAC-VRF：PEのメディアアクセス制御（MAC）アドレスの仮想ルーティングと転送（VRF）テーブルを指します。
Network controller: Denotes a functional entity responsible for the management of the service provider network.
ネットワークコントローラー：サービスプロバイダーネットワークの管理を担当する機能エンティティを示します。
Service orchestrator: Refers to a functional entity that interacts with the customer of an L2VPN relying upon, e.g., the L2SM. The service orchestrator is responsible for the Customer Edge to Provider Edge (CE-PE) attachment circuits, the PE selection, and requesting the activation of the L2VPN service to a network controller.
サービスオーケストレーター：L2SMに依存しているL2VPNの顧客と対話する機能的エンティティを指します。サービスオーケストレーターは、カスタマーエッジからプロバイダーエッジ（CE-PE）アタッチメントサーキット、PE選択、およびネットワークコントローラーへのL2VPNサービスのアクティブ化を要求する責任があります。
Service provider network: A network that is able to provide L2VPN-related services.
サービスプロバイダーネットワーク：L2VPN関連サービスを提供できるネットワーク。
VPN node: An abstraction that represents a set of policies applied on a PE and belongs to a single VPN service. A VPN service involves one or more VPN nodes. The VPN node will identify the service providers' node on which the VPN is deployed.
VPNノード：PEに適用され、単一のVPNサービスに属する一連のポリシーを表す抽象化。VPNサービスには、1つ以上のVPNノードが含まれます。VPNノードは、VPNが展開されているサービスプロバイダーのノードを識別します。
VPN network access: An abstraction that represents the network interfaces that are associated with a given VPN node. Traffic coming from the VPN network access belongs to the VPN. The attachment circuits (bearers) between CEs and PEs are terminated in the VPN network access.
VPNネットワークアクセス：特定のVPNノードに関連付けられているネットワークインターフェイスを表す抽象化。VPNネットワークアクセスからのトラフィックは、VPNに属します。CESとPESの間のアタッチメント回路（ベアラー）は、VPNネットワークアクセスで終了します。
VPN service provider: A service provider that offers L2VPN-related services.
VPNサービスプロバイダー：L2VPN関連サービスを提供するサービスプロバイダー。
The following acronyms and abbreviations are used in this document:
このドキュメントでは、次の頭字語と略語が使用されています。
ACL Access Control List BGP Border Gateway Protocol BUM Broadcast, Unknown Unicast, or Multicast CE Customer Edge ES Ethernet Segment ESI Ethernet Segment Identifier EVPN Ethernet VPN L2VPN Layer 2 Virtual Private Network L2SM L2VPN Service Model L2NM L2VPN Network Model MAC Media Access Control PBB Provider Backbone Bridging PCP Priority Code Point PE Provider Edge QoS Quality of Service RD Route Distinguisher RT Route Target VPLS Virtual Private LAN Service VPN Virtual Private Network VPWS Virtual Private Wire Service VRF Virtual Routing and Forwarding
ACLアクセス制御リストBGPボーダーゲートウェイプロトコルバムブロードキャスト、不明なユニキャスト、またはマルチキャストCEカスタマーエッジES ESGENETセグメントESIイーサネットセグメント識別子EVPNイーサネットVPN L2VPNレイヤー2仮想プライベートネットワークL2SM L2VPNサービスモデルL2NM L2VPNネットワークモデルアクセスPBBプロビジャーバンブボーンブリッジングPCP優先コードポイントPEプロバイダーエッジQoS QOS QUSOLY of SERVICE RDルート違いRTルートターゲットVPLS仮想プライベートLANサービスVPN仮想プライベートネットワークVPWS仮想プライベートワイヤサービスVRF仮想ルーティングと転送
Figure 1 illustrates how the L2NM is used. As a reminder, this figure is an expansion of the architecture presented in Section 3 of [RFC8466] and decomposes the box marked "orchestration" in that figure into three separate functional components called "Service Orchestration", "Network Orchestration", and "Domain Orchestration".
図1は、L2NMの使用方法を示しています。リマインダーとして、この図は[RFC8466]のセクション3に示されているアーキテクチャの拡張であり、その図の「オーケストレーション」の「オーケストレーション」とマークされたボックスを「サービスオーケストレーション」、「ネットワークオーケストレーション」、および「ドメイン」と呼ばれる3つの別々の機能コンポーネントに分解します。オーケストレーション」。
Similar to Section 3 of [RFC8466], CE to PE attachment is achieved through a bearer with a Layer 2 connection on top. The bearer refers to properties of the attachment that are below Layer 2, while the connection refers to Layer 2 protocol-oriented properties.
[RFC8466]のセクション3と同様に、CEからPEへの付着は、レイヤー2接続が上にあるベアラーを通じて達成されます。ベアラーは、レイヤー2の下にあるアタッチメントのプロパティを指し、接続はレイヤー2プロトコル指向のプロパティを指します。
The reader may refer to [RFC8309] for the distinction between the "Customer Service Model", "Service Delivery Model", "Network Configuration Model", and "Device Configuration Model". The "Domain Orchestration" and "Config Manager" roles may be performed by "SDN Controllers".
読者は、「カスタマーサービスモデル」、「サービス配信モデル」、「ネットワーク構成モデル」、および「デバイス構成モデル」の区別について[RFC8309]を参照できます。「ドメインオーケストレーション」および「Config Manager」の役割は、「SDNコントローラー」によって実行される場合があります。
+---------------+
| Customer |
+-------+-------+
Customer Service Model |
e.g., l2vpn-svc |
+-------+-------+
| Service |
| Orchestration |
+-------+-------+
Network Model |
l2vpn-ntw + l2vpn-es |
+-------+-------+
| Network |
| Orchestration |
+-------+-------+
Network Configuration Model |
+-----------+-----------+
| |
+--------+------+ +--------+------+
| Domain | | Domain |
| Orchestration | | Orchestration |
+---+-----------+ +--------+------+
Device | | |
Configuration | | |
Model | | |
+----+----+ | |
| Config | | |
| Manager | | |
+----+----+ | |
| | |
| NETCONF/CLI..................
| | |
+--------------------------------+
\ Network /
\ /
+----+ Bearer +----+ +----+ +----+
|CE A+ ---------- +PE A+ +PE B+ ------- +CE B|
+----+ Connection +----+ +----+ +----+
Site A Site B
サイトAサイトb
NETCONF: Network Configuration Protocol CLI: Command-Line Interface
NetConf：ネットワーク構成プロトコルCLI：コマンドラインインターフェイス
Figure 1: L2SM and L2NM Interaction
図1：L2SMおよびL2NM相互作用
The customer may use various means to request a service that may trigger the instantiation of an L2NM. The customer may use the L2SM or may rely upon more abstract models to request a service that relies upon an L2VPN service. For example, the customer may supply an IP Connectivity Provisioning Profile (CPP) that characterizes the requested service [RFC7297], an enhanced VPN (VPN+) service [VPN+-FRAMEWORK], or an IETF network slice service [IETF-NET-SLICES].
顧客は、L2NMのインスタンス化をトリガーする可能性のあるサービスを要求するために、さまざまな手段を使用する場合があります。顧客はL2SMを使用するか、より抽象的なモデルに依存してL2VPNサービスに依存するサービスを要求する場合があります。たとえば、顧客は、要求されたサービス[RFC7297]、強化されたVPN（VPN）サービス[VPNフレームワーク]、またはIETFネットワークスライスサービス[IETF-Net-Slices]を特徴付けるIP接続プロビジョニングプロファイル（CPP）を提供する場合があります。。
Note also that both the L2SM and L2NM may be used in the context of the Abstraction and Control of TE Networks (ACTN) framework [RFC8453]. Figure 2 shows the Customer Network Controller (CNC), the Multi-Domain Service Coordinator (MDSC), and the Provisioning Network Controller (PNC).
また、L2SMとL2NMの両方が、TEネットワーク（ACTN）フレームワーク[RFC8453]の抽象化と制御のコンテキストで使用できることに注意してください。図2は、カスタマーネットワークコントローラー（CNC）、マルチドメインサービスコーディネーター（MDSC）、およびプロビジョニングネットワークコントローラー（PNC）を示しています。
+----------------------------------+
| Customer |
| +-----------------------------+ |
| | CNC | |
| +-----------------------------+ |
+----+-----------------------+-----+
| |
| L2SM | L2SM
| |
+---------+---------+ +---------+---------+
| MDSC | | MDSC |
| +---------------+ | | (parent) |
| | Service | | +---------+---------+
| | Orchestration | | |
| +-------+-------+ | | L2NM
| | | |
| | L2NM | +---------+---------+
| | | | MDSC |
| +-------+-------+ | | (child) |
| | Network | | +---------+---------+
| | Orchestration | | |
| +---------------+ | |
+---------+---------+ |
| |
| Network Configuration |
| |
+------------+-------+ +---------+------------+
| Domain | | Domain |
| Controller | | Controller |
| +---------+ | | +---------+ |
| | PNC | | | | PNC | |
| +---------+ | | +---------+ |
+------------+-------+ +---------+------------+
| |
| Device Configuration |
| |
+----+---+ +----+---+
| Device | | Device |
+--------+ +--------+
Figure 2: L2SM and L2NM in the Context of ACTN
図2：ACTNのコンテキストでのL2SMとL2NM
The "ietf-vpn-common" module [RFC9181] includes a set of identities, types, and groupings that are meant to be reused by VPN-related YANG modules independently of the layer (e.g., Layer 2 or Layer 3) and the type of the module (e.g., network model or service model) including future revisions of existing models (e.g., [RFC8466]). The L2NM reuses these common types and groupings.
「IETF-VPN-COMMON」モジュール[RFC9181]には、レイヤー（例えば、レイヤー2またはレイヤー3）とタイプのタイプとは、VPN関連のYangモジュールによって再利用されることを意図した一連のアイデンティティ、タイプ、およびグループ化が含まれています。既存のモデルの将来の改訂（[RFC8466]など）を含むモジュール（例：ネットワークモデルまたはサービスモデル）。L2NMは、これらの一般的なタイプとグループ化を再利用します。
Also, the L2NM uses the IANA-maintained modules "iana-bgp-l2-encaps" (Section 8.1) and "iana-pseudowire-types" (Section 8.2) to identify Layer 2 encapsulation and pseudowire types. More details are provided in Sections 7.5.2.1 and 7.5.2.3.
また、L2NMは、IANAが維持したモジュール「IANA-BGP-L2-ENCAPS」（セクション8.1）および「IANA-Pseudowire-Types」（セクション8.2）を使用して、レイヤー2カプセル化と擬似型タイプを識別します。詳細については、セクション7.5.2.1および7.5.2.3に記載されています。
For the particular case of EVPN, the L2NM includes a name that refers to an Ethernet segment that is created using the "ietf-ethernet-segment" module (Section 8.3). Some ES-related examples are provided in Appendices A.4 and A.5.
EVPNの特定の場合、L2NMには、「IETF-Ethernet-Segment」モジュール（セクション8.3）を使用して作成されたイーサネットセグメントを指す名前が含まれています。いくつかのES関連の例は、付録A.4およびA.5に記載されています。
As discussed in Section 4, the L2NM is used to manage L2VPN services within a service provider network. The module provides a network view of the L2VPN service. Such a view is only visible to the service provider and is not exposed outside (to customers, for example). The following discusses how the L2NM interfaces with other YANG modules:
セクション4で説明したように、L2NMはサービスプロバイダーネットワーク内のL2VPNサービスを管理するために使用されます。モジュールは、L2VPNサービスのネットワークビューを提供します。このようなビューは、サービスプロバイダーにのみ表示され、外部に露出されていません（たとえば、顧客に）。以下は、L2NMが他のYangモジュールとどのようにインターフェイスするかについて説明します。
L2SM: The L2NM is not a customer service model.
L2SM：L2NMはカスタマーサービスモデルではありません。
The internal view of the service (i.e., the L2NM) may be mapped to an external view that is visible to customers: L2VPN Service Model (L2SM) [RFC8466].
サービスの内部ビュー（つまり、L2NM）は、顧客に表示される外部ビュー：L2VPNサービスモデル（L2SM）[RFC8466]にマッピングできます。
The L2NM can be fed with inputs that are requested by customers and that typically rely on an L2SM template. Concretely, some parts of the L2SM module can be directly mapped into the L2NM while other parts are generated as a function of the requested service and local guidelines. Finally, there are parts local to the service provider, and they do not map directly to the L2SM.
L2NMには、顧客が要求し、通常はL2SMテンプレートに依存している入力を供給できます。具体的には、L2SMモジュールの一部をL2NMに直接マッピングすることができ、他の部品は要求されたサービスとローカルガイドラインの関数として生成されます。最後に、サービスプロバイダーにローカルな部品があり、L2SMに直接マッピングされません。
Note that using the L2NM within a service provider does not assume, nor does it preclude, exposing the VPN service via the L2SM. This is deployment specific. Nevertheless, the design of L2NM tries to align as much as possible with the features supported by the L2SM to ease the grafting of both the L2NM and the L2SM for the sake of highly automated VPN service provisioning and delivery.
サービスプロバイダー内でL2NMを使用しても、L2SMを介してVPNサービスを公開することも排除しないことも注意してください。これは展開固有です。それにもかかわらず、L2NMの設計は、高度に自動化されたVPNサービスの提供と配信のために、L2NMとL2SMの両方のグラフトを容易にするために、L2SMによってサポートされている機能と可能な限り整列しようとします。
Network Topology Modules: An L2VPN involves nodes that are part of a topology managed by the service provider network. Such a topology can be represented using the network topology module in [RFC8345] or its extension, such as a network YANG module for Service Attachment Points (SAPs) [YANG-SAPS].
ネットワークトポロジモジュール：L2VPNには、サービスプロバイダーネットワークが管理するトポロジの一部であるノードが含まれます。このようなトポロジーは、[RFC8345]のネットワークトポロジモジュールまたはその拡張機能（サービスアタッチメントポイント（SAPS）のネットワークYangモジュールなど）を使用して表現できます[Yang-Saps]。
Device Modules: The L2NM is not a device model.
デバイスモジュール：L2NMはデバイスモデルではありません。
Once a global VPN service is captured by means of the L2NM, the actual activation and provisioning of the VPN service will involve a variety of device modules to tweak the required functions for the delivery of the service. These functions are supported by the VPN nodes and can be managed using device YANG modules. A non-comprehensive list of such device YANG modules is provided below:
グローバルVPNサービスがL2NMによってキャプチャされると、VPNサービスの実際のアクティベーションとプロビジョニングには、サービスの提供に必要な関数を調整するためのさまざまなデバイスモジュールが含まれます。これらの機能はVPNノードによってサポートされており、デバイスYangモジュールを使用して管理できます。このようなデバイスYangモジュールの非包括的なリストを以下に示します。
* Interfaces [RFC8343]
* インターフェイス[RFC8343]
* BGP [BGP-YANG-MODEL]
* BGP [BGP-Yang-Model]
* MPLS [RFC8960]
* MPLS [RFC8960]
* Access Control Lists (ACLs) [RFC8519]
* アクセス制御リスト（ACLS）[RFC8519]
How the L2NM is used to derive device-specific actions is implementation specific.
L2NMがデバイス固有のアクションを導出するために使用する方法は、実装固有です。
The 'ietf-ethernet-segment' module (Figure 3) is used to manage a set of Ethernet segments in the context of an EVPN service.
「IETF-Ethernet-Segment」モジュール（図3）は、EVPNサービスのコンテキストで一連のイーサネットセグメントを管理するために使用されます。
module: ietf-ethernet-segment
+--rw ethernet-segments
+--rw ethernet-segment* [name]
+--rw name string
+--rw esi-type? identityref
+--rw (esi-choice)?
| +--:(directly-assigned)
| | +--rw ethernet-segment-identifier? yang:hex-string
| +--:(auto-assigned)
| +--rw esi-auto
| +--rw (auto-mode)?
| | +--:(from-pool)
| | | +--rw esi-pool-name? string
| | +--:(full-auto)
| | +--rw auto? empty
| +--ro auto-ethernet-segment-identifier?
| yang:hex-string
+--rw esi-redundancy-mode? identityref
+--rw df-election
| +--rw df-election-method? identityref
| +--rw revertive? boolean
| +--rw election-wait-time? uint32
+--rw split-horizon-filtering? boolean
+--rw pbb
| +--rw backbone-src-mac? yang:mac-address
+--rw member* [ne-id interface-id]
+--rw ne-id string
+--rw interface-id string
Figure 3: Ethernet Segments Tree Structure
図3：イーサネットセグメントツリー構造
The descriptions of the data nodes depicted in Figure 3 are as follows:
図3に示すデータノードの説明は次のとおりです。
'name': Sets a name to uniquely identify an ES within a service provider network. In order to ease referencing ESes by their name in other modules, "es-ref" typedef is defined.
「名前」：サービスプロバイダーネットワーク内のESを一意に識別するために名前を設定します。他のモジュールの名前でESEを参照するために、「ES-Ref」Typedefが定義されています。
This typedef is used in the VPN network access level of the L2NM to reference an ES (Section 7.6). An example to illustrate such a use in the L2NM is provided in Appendix A.4.
このtypedefは、L2NMのVPNネットワークアクセスレベルでESを参照するために使用されます（セクション7.6）。L2NMでのこのような使用を説明する例は、付録A.4に記載されています。
'esi-type': Indicates the Ethernet Segment Identifier (ESI) type as discussed in Section 5 of [RFC7432]. ESIs can be automatically assigned either with or without indicating a pool from which an ESI should be taken ('esi-pool-name'). The following types are supported:
「ESI-Type」：[RFC7432]のセクション5で説明したイーサネットセグメント識別子（ESI）タイプを示します。ESIは、ESIを取得する必要があるプール（「ESI-Pool-Name」）を示す場合と、またはそれを示すことなく自動的に割り当てることができます。次のタイプがサポートされています。
'esi-type-0-operator': The ESI is directly configured by the VPN service provider. The configured value is provided in 'ethernet-segment-identifier'.
「ESI-Type-0-Operator」：ESIはVPNサービスプロバイダーによって直接構成されます。構成された値は、「Ethernet-Segment-Identifier」で提供されます。
'esi-type-1-lacp': The ESI is auto-generated from the IEEE 802.1AX Link Aggregation Control Protocol (LACP) [IEEE802.1AX].
「ESI-Type-1-LACP」：ESIは、IEEE 802.1AXリンク集約制御プロトコル（LACP）[IEEE802.1AX]から自動生成されています。
'esi-type-2-bridge': The ESI is auto-generated and determined based on the Layer 2 bridge protocol.
'ESI-Type-2-Bridge'：ESIは自動生成され、レイヤー2ブリッジプロトコルに基づいて決定されます。
'esi-type-3-mac': The ESI is a MAC-based ESI value that can be auto-generated or configured by the VPN service provider.
「ESI-TYPE-3-MAC」：ESIは、VPNサービスプロバイダーによって自動生成または構成できるMacベースのESI値です。
'esi-type-4-router-id': The ESI is auto-generated or configured by the VPN service provider based on the Router ID. The 'router-id' supplied in Section 7.5 can be used to auto-derive an ESI when this type is used.
「ESI-Type-4-Router-ID」：ESIは、ルーターIDに基づいてVPNサービスプロバイダーによって自動生成または構成されています。セクション7.5で提供される「ルーター-ID」は、このタイプを使用するとESIを自動化するために使用できます。
'esi-type-5-asn': The ESI is auto-generated or configured by the VPN service provider based on the Autonomous System (AS) number. The 'local-autonomous-system' supplied in Section 7.4 can be used to auto-derive an ESI when this type is used.
'ESI-Type-5-ASN'：ESIは、自律システム（AS）番号に基づいてVPNサービスプロバイダーによって自動生成または構成されています。セクション7.4で提供される「ローカル自由システム」は、このタイプを使用したときにESIを自動化するために使用できます。
Auto-generated values can be retrieved using 'auto-ethernet-segment-identifier'.
自動生成値は、「自動エーテルネットセグメントIDENTIFIER」を使用して取得できます。
'esi-redundancy-mode': Specifies the EVPN redundancy mode for a given ES. The following modes are supported: Single-Active (Section 14.1.1 of [RFC7432]) or All-Active (Section 14.1.2 of [RFC7432]).
'esi-redundancy-mode'：指定されたESのEVPN冗長モードを指定します。次のモードがサポートされています：単一活性（[RFC7432]のセクション14.1.1）または全活性（[RFC7432]のセクション14.1.2）。
'df-election': Specifies a set of parameters related to the Designated Forwarder (DF) election (Section 8.5 of [RFC7432]). For example, this data node can be used to indicate an election method (e.g., [RFC8584] or [EVPN-PERF-DF]). If no election method is indicated, the default method defined in Section 8.5 of [RFC7432] is used.
「DF-Election」：指定されたフォワーダー（DF）選挙に関連する一連のパラメーターを指定します（[RFC7432]のセクション8.5）。たとえば、このデータノードを使用して、選挙方法（[RFC8584]または[EVPN-PERF-DF]）を示すことができます。選挙方法が示されていない場合、[RFC7432]のセクション8.5で定義されているデフォルトの方法が使用されます。
As discussed in Section 1.3.2 of [RFC8584], the default behavior is to trigger the DF election procedure when a DF fails (e.g., link failure). The former DF will take over when it is available again. Such a mode is called 'revertive'. The behavior can be overridden by setting the 'revertive' leaf to 'false'.
[RFC8584]のセクション1.3.2で説明したように、デフォルトの動作は、DFが失敗したときにDF選挙手続きをトリガーすることです（例：リンク障害）。前者のDFは、再び利用可能になると引き継ぎます。このようなモードは「復帰」と呼ばれます。動作は、「戻る」葉を「false」に設定することでオーバーライドできます。
Also, this data node can be used to configure a DF Wait timer ('election-wait-time') (Section 2.1 of [RFC8584]).
また、このデータノードを使用して、DF待機タイマー（「選挙 - 待機時間」）（[RFC8584]のセクション2.1）を構成することができます。
'split-horizon-filtering': Controls the activation of the split-horizon filtering for an ES (Section 8.3 of [RFC7432]).
「Split-Horizon-Filtering」：ESのスプリットホリゾンフィルタリングの活性化を制御します（[RFC7432]のセクション8.3）。
'pbb': Indicates data nodes that are specific to PBB [IEEE-802-1ah]:
'PBB'：PBBに固有のデータノードを示します[IEEE-802-1AH]：
'backbone-src-mac': Associates a Provider Backbone MAC (B-MAC) address with an ES. This is particularly useful for All-Active multihomed ESes (Section 9.1 of [RFC7623]).
'Backbone-SRC-MAC'：プロバイダーバックボーンMAC（B-MAC）アドレスをESに関連付けます。これは、オールアクティブなマルチホームESEに特に役立ちます（[RFC7623]のセクション9.1）。
'member': Lists the members of an ES in a service provider network.
「メンバー」：サービスプロバイダーネットワークのESのメンバーをリストします。
The L2NM ('ietf-l2vpn-ntw'; see Section 8.4) is used to manage L2VPNs within a service provider network. In particular, the 'ietf-l2vpn-ntw' module can be used to create, modify, delete, and retrieve L2VPN services in a network controller. The module is designed to minimize the amount of customer-related information.
L2NM（ 'IETF-L2VPN-NTW';セクション8.4を参照）は、サービスプロバイダーネットワーク内のL2VPNを管理するために使用されます。特に、「IETF-L2VPN-NTW」モジュールを使用して、ネットワークコントローラーでL2VPNサービスを作成、変更、削除、および取得できます。このモジュールは、顧客関連の情報の量を最小限に抑えるように設計されています。
The full tree diagram of the module can be generated using the "pyang" tool [PYANG]. That tree is not included here because it is too long (Section 3.3 of [RFC8340]). Instead, subtrees are provided for the reader's convenience.
モジュールのフルツリー図は、「Pyang」ツール[Pyang]を使用して生成できます。その木は長すぎるため、ここには含まれていません（[RFC8340]のセクション3.3）。代わりに、読者の利便性のためにサブツリーが提供されます。
Note that the following subsections introduce some data nodes that enclose textual descriptions (e.g., VPN service (Section 7.3), VPN node (Section 7.5), or VPN network access (Section 7.6)). Such descriptions are not intended for random end users but for network/system/software engineers that use their local context to provide and interpret such information. Therefore, no mechanism for language tagging is needed.
次のサブセクションでは、テキストの説明（VPNサービス（セクション7.3）、VPNノード（セクション7.5）、またはVPNネットワークアクセス（セクション7.6））を囲むいくつかのデータノードを導入することに注意してください。このような説明は、ランダムなエンドユーザー向けではなく、ローカルコンテキストを使用してそのような情報を提供および解釈するネットワーク/システム/ソフトウェアエンジニアを対象としています。したがって、言語タグ付けのメカニズムは必要ありません。
The 'ietf-l2vpn-ntw' module uses two main containers: 'vpn-profiles' and 'vpn-services' (see Figure 4).
「IETF-L2VPN-NTW」モジュールは、「VPNプロファイル」と「VPN-Services」の2つの主要なコンテナを使用します（図4を参照）。
The 'vpn-profiles' container is used by the provider to define and maintain a set of common VPN profiles that apply to VPN services (Section 7.2).
「VPNプロファイル」コンテナは、VPNサービスに適用される共通のVPNプロファイルのセットを定義および維持するためにプロバイダーによって使用されます（セクション7.2）。
The 'vpn-services' container maintains the set of L2VPN services managed in the service provider network. The module allows creating a new L2VPN service by adding a new instance of 'vpn-service'. The 'vpn-service' is the data structure that abstracts the VPN service (Section 7.3).
「VPN-Services」コンテナは、サービスプロバイダーネットワークで管理されているL2VPNサービスのセットを維持します。このモジュールにより、「VPN-Service」の新しいインスタンスを追加することにより、新しいL2VPNサービスを作成できます。「VPN-Service」は、VPNサービスを抽象化するデータ構造です（セクション7.3）。
module: ietf-l2vpn-ntw
+--rw l2vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
Figure 4: Overall L2NM Tree Structure
図4：L2NM全体の樹木構造
The 'vpn-profiles' container (Figure 5) is used by a VPN service provider to define and maintain a set of VPN profiles [RFC9181] that apply to one or several VPN services.
「VPNプロファイル」コンテナ（図5）は、VPNサービスプロバイダーによって使用され、1つまたは複数のVPNサービスに適用されるVPNプロファイル[RFC9181]のセットを定義および維持します。
+--rw l2vpn-ntw
+--rw vpn-profiles
| +--rw valid-provider-identifiers
| +--rw external-connectivity-identifier* [id]
| | {external-connectivity}?
| | +--rw id string
| +--rw encryption-profile-identifier* [id]
| | +--rw id string
| +--rw qos-profile-identifier* [id]
| | +--rw id string
| +--rw bfd-profile-identifier* [id]
| | +--rw id string
| +--rw forwarding-profile-identifier* [id]
| | +--rw id string
| +--rw routing-profile-identifier* [id]
| +--rw id string
+--rw vpn-services
...
Figure 5: VPN Profiles Subtree Structure
図5：VPNプロファイルサブツリー構造
The exact definition of these profiles is local to each VPN service provider. The model only includes an identifier for these profiles in order to ease identifying and binding local policies when building a VPN service. As shown in Figure 5, the following identifiers can be included:
これらのプロファイルの正確な定義は、各VPNサービスプロバイダーにローカルです。このモデルには、VPNサービスを構築する際にローカルポリシーの識別と拘束力を容易にするために、これらのプロファイルの識別子のみが含まれています。図5に示すように、次の識別子を含めることができます。
'external-connectivity-identifier': This identifier refers to a profile that defines the external connectivity provided to a VPN service (or a subset of VPN sites). External connectivity may be access to the Internet or restricted connectivity such as access to a public/private cloud.
「外部接続性識別子」：この識別子は、VPNサービス（またはVPNサイトのサブセット）に提供される外部接続性を定義するプロファイルを指します。外部接続は、インターネットへのアクセスまたはパブリック/プライベートクラウドへのアクセスなどの制限された接続性です。
'encryption-profile-identifier': An encryption profile refers to a set of policies related to the encryption schemes and setup that can be applied when building and offering a VPN service.
「暗号化プロファイル - アイデンティティ」：暗号化プロファイルとは、VPNサービスの構築と提供時に適用できる暗号化スキームとセットアップに関連する一連のポリシーを指します。
'qos-profile-identifier': A Quality of Service (QoS) profile refers to a set of policies such as classification, marking, and actions (e.g., [RFC3644]).
「QOS-Profile-Identifier」：サービス品質（QOS）プロファイルとは、分類、マーキング、アクションなどの一連のポリシーを指します（[RFC3644]など）。
'bfd-profile-identifier': A Bidirectional Forwarding Detection (BFD) profile refers to a set of BFD policies [RFC5880] that can be invoked when building a VPN service.
'BFD-Profile-Identifier'：双方向転送検出（BFD）プロファイルとは、VPNサービスを構築するときに呼び出すことができる一連のBFDポリシー[RFC5880]を指します。
'forwarding-profile-identifier': A forwarding profile refers to the policies that apply to the forwarding of packets conveyed within a VPN. Such policies may consist of, for example, applying ACLs.
「転送プロファイル識別子」：転送プロファイルとは、VPN内で伝えられるパケットの転送に適用されるポリシーを指します。このようなポリシーは、たとえばACLを適用することで構成されている場合があります。
'routing-profile-identifier': A routing profile refers to a set of routing policies that will be invoked (e.g., BGP policies) when delivering the VPN service.
'Routing-Profile-Identifier'：ルーティングプロファイルとは、VPNサービスを提供するときに呼び出される一連のルーティングポリシー（BGPポリシーなど）を指します。
The 'vpn-service' is the data structure that abstracts an L2VPN service in the service provider network. Each 'vpn-service' is uniquely identified by an identifier: 'vpn-id'. Such a 'vpn-id' is only meaningful locally within the network controller. The subtree of the 'vpn-services' is shown in Figure 6.
「VPN-Service」は、サービスプロバイダーネットワークでL2VPNサービスを抽象化するデータ構造です。各「VPNサービス」は、識別子「VPN-ID」によって一意に識別されます。このような「VPN-ID」は、ネットワークコントローラー内でローカルでのみ意味があります。「VPNサービス」のサブツリーを図6に示します。
+--rw vpn-services
+--rw vpn-service* [vpn-id]
+--rw vpn-id vpn-common:vpn-id
+--rw vpn-name? string
+--rw vpn-description? string
+--rw customer-name? string
+--rw parent-service-id? vpn-common:vpn-id
+--rw vpn-type? identityref
+--rw vpn-service-topology? identityref
+--rw bgp-ad-enabled? boolean
+--rw signaling-type? identityref
+--rw global-parameters-profiles
| ...
+--rw underlay-transport
| +--rw (type)?
| +--:(abstract)
| | +--rw transport-instance-id? string
| | +--rw instance-type? identityref
| +--:(protocol)
| +--rw protocol* identityref
+--rw status
| +--rw admin-status
| | +--rw status? identityref
| | +--rw last-change? yang:date-and-time
| +--ro oper-status
| +--ro status? identityref
| +--ro last-change? yang:date-and-time
+--rw vpn-nodes
...
Figure 6: VPN Services Subtree
図6：VPNサービスサブツリー
The descriptions of the VPN service data nodes that are depicted in Figure 6 are as follows:
図6に示されているVPNサービスデータノードの説明は次のとおりです。
'vpn-id': An identifier that is used to uniquely identify the L2VPN service within the L2NM scope.
'VPN-ID'：L2NMスコープ内のL2VPNサービスを一意に識別するために使用される識別子。
'vpn-name': Associates a name with the service in order to facilitate the identification of the service.
「VPN-Name」：サービスの識別を容易にするために、名前をサービスに関連付けます。
'vpn-description': Includes a textual description of the service.
'VPN-description'：サービスのテキスト説明が含まれています。
The internal structure of a VPN description is local to each VPN service provider.
VPN説明の内部構造は、各VPNサービスプロバイダーにローカルです。
'customer-name': Indicates the name of the customer who ordered the service.
「Customer-Name」：サービスを注文した顧客の名前を示します。
'parent-service-id': Refers to an identifier of the parent service (e.g., the L2SM, IETF network slice, and VPN+) that triggered the creation of the L2VPN service. This identifier is used to easily correlate the (network) service as built in the network with a service order. A controller can use that correlation to enrich or populate some fields (e.g., description fields) as a function of local deployments.
'parent-service-id'：L2VPNサービスの作成をトリガーした親サービスの識別子（L2SM、IETFネットワークスライス、VPN）を指します。この識別子は、ネットワーク内に構築された（ネットワーク）サービスをサービス注文と簡単に相関させるために使用されます。コントローラーは、その相関を使用して、ローカル展開の関数としていくつかのフィールド（説明フィールドなど）を濃縮または埋めることができます。
'vpn-type': Indicates the L2VPN type. The following types, defined in [RFC9181], can be used for the L2NM:
'VPN-Type'：L2VPNタイプを示します。[RFC9181]で定義されている次のタイプは、L2NMに使用できます。
'vpls': Virtual Private LAN Service (VPLS) as defined in [RFC4761] or [RFC4762]. This type is also used for hierarchical VPLS (H-VPLS) (Section 10 of [RFC4762]).
'VPLS'：[RFC4761]または[RFC4762]で定義されている仮想プライベートLANサービス（VPLS）。このタイプは、階層VPL（H-VPLS）にも使用されます（[RFC4762]のセクション10）。
'vpws': Virtual Private Wire Service (VPWS) as defined in Section 3.1.1 of [RFC4664].
「VPWS」：[RFC4664]のセクション3.1.1で定義されている仮想プライベートワイヤサービス（VPWS）。
'vpws-evpn': VPWS EVPNs as defined in [RFC8214].
'VPWS-EVPN'：[RFC8214]で定義されているVPWS EVPN。
'pbb-evpn': Provider Backbone Bridging (PBB) EVPNs as defined in [RFC7623].
'PBB-EVPN'：プロバイダーバックボーンブリッジング（PBB）EVPNS [RFC7623]で定義されています。
'mpls-evpn': MPLS-based EVPNs [RFC7432].
'MPLS-EVPN'：MPLSベースのEVPNS [RFC7432]。
'vxlan-evpn': VXLAN-based EVPNs [RFC8365].
'vxlan-evpn'：vxlanベースのevpns [rfc8365]。
The type is used as a condition for the presence of some data nodes in the L2NM.
このタイプは、L2NMにいくつかのデータノードが存在する条件として使用されます。
'vpn-service-topology': Indicates the network topology for the service: hub-spoke, any-to-any, or custom. These types are defined in [RFC9181].
「VPN-Service-Topology」：サービスのネットワークトポロジーを示します：Hub Spoke、Any-to-any、またはCustom。これらのタイプは[RFC9181]で定義されています。
'bgp-ad-enabled': Controls whether BGP auto-discovery is enabled. If so, additional data nodes are included (Section 7.5.1).
'BGP-AD-Exabled'：BGPの自動ディスコービリが有効かどうかを制御します。その場合、追加のデータノードが含まれています（セクション7.5.1）。
'signaling-type': Indicates the signaling that is used for setting up pseudowires. Signaling type values are taken from [RFC9181]. The following signaling options are supported:
「シグナリングタイプ」：擬似動物のセットアップに使用されるシグナリングを示します。シグナル伝達タイプの値は[RFC9181]から取得されます。次のシグナリングオプションがサポートされています。
'bgp-signaling': The L2NM supports two flavors of BGP-signaled L2VPNs:
'BGP-Signaling'：L2NMは、BGPシグナル付きL2VPNの2つのフレーバーをサポートしています。
'l2vpn-bgp': The service is a Multipoint VPLS that uses a BGP control plane as described in [RFC4761] and [RFC6624].
'L2VPN-BGP'：このサービスは、[RFC4761]および[RFC6624]に記載されているように、BGP制御プレーンを使用するマルチポイントVPLSです。
'evpn-bgp': The service is a Multipoint VPLS that uses a BGP control plane but also includes the additional EVPN features and related parameters as described in [RFC7432] and [RFC7209].
'EVPN-BGP'：このサービスは、BGPコントロールプレーンを使用するマルチポイントVPLSですが、[RFC7432]および[RFC7209]に記載されている追加のEVPN機能と関連パラメーターも含まれています。
'ldp-signaling': A Multipoint VPLS that uses a mesh of LDP-signaled pseudowires [RFC6074].
'LDP-Signaling'：LDPシグナル擬似擬似動物のメッシュを使用するマルチポイントVPL [RFC6074]。
'l2tp-signaling': The L2NM uses L2TP-signaled pseudowires as described in [RFC6074].
'L2TP-Signaling'：L2NMは、[RFC6074]に記載されているように、L2TPシグナル擬似擬似動物を使用します。
Table 1 summarizes the allowed signaling types for each VPN service type ('vpn-type'). See Section 7.5.2 for more details.
表1は、各VPNサービスタイプ（ 'VPN-Type'）の許可されたシグナリングタイプをまとめたものです。詳細については、セクション7.5.2を参照してください。
+============+================================+
| VPN Type | Signaling Options |
+============+================================+
| vpls | l2tp-signaling, ldp-signaling, |
| | bgp-signaling (l2vpn-bgp) |
+------------+--------------------------------+
| vpws | l2tp-signaling, ldp-signaling, |
| | bgp-signaling (l2vpn-bgp) |
+------------+--------------------------------+
| vpws-evpn | bgp-signaling (evpn-bgp) |
+------------+--------------------------------+
| pbb-evpn | bgp-signaling (evpn-bgp) |
+------------+--------------------------------+
| mpls-evpn | bgp-signaling (evpn-bgp) |
+------------+--------------------------------+
| vxlan-evpn | bgp-signaling (evpn-bgp) |
+------------+--------------------------------+
Table 1: Signaling Options per VPN Service Type
表1：VPNサービスタイプごとのシグナリングオプション
'global-parameters-profiles': Defines reusable parameters for the same L2VPN service.
「Global-Parameters-Profiles」：同じL2VPNサービスの再利用可能なパラメーターを定義します。
More details are provided in Section 7.4.
詳細については、セクション7.4に記載されています。
'underlay-transport': Describes the preference for the transport technology to carry the traffic of the VPN service. This preference is especially useful in networks with multiple domains and Network-to-Network Interface (NNI) types. The underlay transport can be expressed as an abstract transport instance (e.g., an identifier of a VPN+ instance, a virtual network identifier, or a network slice name) or as an ordered list of the actual protocols to be enabled in the network.
「Underlay-Transport」：VPNサービスのトラフィックを運ぶための輸送技術の好みを説明しています。この好みは、複数のドメインとネットワーク間インターフェイス（NNI）タイプを持つネットワークで特に役立ちます。アンダーレイトランスポートは、抽象輸送インスタンス（たとえば、VPNインスタンスの識別子、仮想ネットワーク識別子、またはネットワークスライス名）、またはネットワークで有効になる実際のプロトコルの順序付けられたリストとして表現できます。
A rich set of protocol identifiers that can be used to refer to an underlay transport (or how such an underlay is set up) are defined in [RFC9181].
アンダーレイトランスポート（またはそのようなアンダーレイの設定方法）を参照するために使用できるプロトコル識別子の豊富なセットは、[RFC9181]で定義されています。
The model defined in Section 6.3.2 of [TE-SERVICE-MAPPING] may be used if specific protection and availability requirements are needed between PEs.
[TE-Service-マッピング]のセクション6.3.2で定義されているモデルは、PES間に特定の保護と可用性の要件が必要な場合に使用できます。
'status': Used to track the overall status of a given VPN service. Both operational and administrative status are maintained together with a timestamp. For example, a service can be created but not put into effect.
「ステータス」：特定のVPNサービスの全体的なステータスを追跡するために使用されます。運用ステータスと管理ステータスの両方が、タイムスタンプとともに維持されます。たとえば、サービスを作成することはできますが、有効にしません。
Administrative and operational status can be used as a trigger to detect service anomalies. For example, a service that is declared at the service layer as being created but still inactive at the network layer is an indication that network provisioning actions are needed to align the observed service status with the expected service status.
管理および運用ステータスは、サービスの異常を検出するトリガーとして使用できます。たとえば、サービスレイヤーで作成されていると宣言されているが、ネットワークレイヤーではまだ非アクティブであるサービスは、観測されたサービスステータスを予想されるサービスステータスに合わせるためにネットワークプロビジョニングアクションが必要であることを示しています。
'vpn-node': An abstraction that represents a set of policies applied to a network node and belonging to a single 'vpn-service'. An L2VPN service is typically built by adding instances of 'vpn-node' to the 'vpn-nodes' container.
「VPNノード」：ネットワークノードに適用され、単一の「VPNサービス」に属する一連のポリシーを表す抽象化。L2VPNサービスは通常、「VPNノード」のインスタンスを「VPNノード」コンテナに追加することにより構築されます。
A 'vpn-node' contains 'vpn-network-accesses', which are the interfaces attached to the VPN by which the customer traffic is received. Therefore, the customer sites are connected to the 'vpn-network-accesses'.
「VPNノード」には、「VPN-Network-Accesses」が含まれています。これは、顧客トラフィックを受信するVPNに接続されているインターフェイスです。したがって、顧客サイトは「VPN-Network-Accesses」に接続されています。
Note that, as this is a network data model, the information about customers sites is not required in the model. Such information is rather relevant in the L2SM. Whether that information is included in the L2NM, e.g., to populate the various 'description' data nodes, is implementation specific.
これはネットワークデータモデルであるため、モデルでは顧客サイトに関する情報は必要ないことに注意してください。このような情報は、L2SMでかなり関連性があります。その情報がL2NMに含まれているかどうか、たとえば、さまざまな「説明」データノードを埋めるために、実装固有です。
More details are provided in Section 7.5.
詳細については、セクション7.5に記載されています。
The 'global-parameters-profile' defines reusable parameters for the same L2VPN service instance ('vpn-service'). Global parameters profiles are defined at the VPN service level, activated at the VPN node level, and then an activated VPN profile may be used at the VPN network access level. Each VPN instance profile is identified by 'profile-id'. Some of the data nodes can be adjusted at the VPN node or VPN network access levels. These adjusted values take precedence over the global values. The subtree of 'global-parameters-profile' is depicted in Figure 7.
「Global-Parameters-Profile」は、同じL2VPNサービスインスタンス（「VPN-Service」）の再利用可能なパラメーターを定義します。グローバルパラメータープロファイルは、VPNサービスレベルで定義され、VPNノードレベルでアクティブ化され、VPNネットワークアクセスレベルでアクティブ化されたVPNプロファイルを使用できます。各VPNインスタンスプロファイルは、「プロファイルID」によって識別されます。一部のデータノードは、VPNノードまたはVPNネットワークアクセスレベルで調整できます。これらの調整された値は、グローバル値よりも優先されます。「グローバルパラメータープロファイル」のサブツリーを図7に示します。
...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
+--rw global-parameters-profiles
| +--rw global-parameters-profile* [profile-id]
| +--rw profile-id string
| +--rw (rd-choice)?
| | +--:(directly-assigned)
| | | +--rw rd?
| | | rt-types:route-distinguisher
| | +--:(directly-assigned-suffix)
| | | +--rw rd-suffix? uint16
| | +--:(auto-assigned)
| | | +--rw rd-auto
| | | +--rw (auto-mode)?
| | | | +--:(from-pool)
| | | | | +--rw rd-pool-name? string
| | | | +--:(full-auto)
| | | | +--rw auto? empty
| | | +--ro auto-assigned-rd?
| | | rt-types:route-distinguisher
| | +--:(auto-assigned-suffix)
| | | +--rw rd-auto-suffix
| | | +--rw (auto-mode)?
| | | | +--:(from-pool)
| | | | | +--rw rd-pool-name? string
| | | | +--:(full-auto)
| | | | +--rw auto? empty
| | | +--ro auto-assigned-rd-suffix? uint16
| | +--:(no-rd)
| | +--rw no-rd? empty
| +--rw vpn-target* [id]
| | +--rw id uint8
| | +--rw route-targets* [route-target]
| | | +--rw route-target rt-types:route-target
| | +--rw route-target-type
| | rt-types:route-target-type
| +--rw vpn-policies
| | +--rw import-policy? string
| | +--rw export-policy? string
| +--rw local-autonomous-system? inet:as-number
| +--rw svc-mtu? uint32
| +--rw ce-vlan-preservation? boolean
| +--rw ce-vlan-cos-preservation? boolean
| +--rw control-word-negotiation? boolean
| +--rw mac-policies
| | +--rw mac-addr-limit
| | | +--rw limit-number? uint16
| | | +--rw time-interval? uint32
| | | +--rw action? identityref
| | +--rw mac-loop-prevention
| | +--rw window? uint32
| | +--rw frequency? uint32
| | +--rw retry-timer? uint32
| | +--rw protection-type? identityref
| +--rw multicast {vpn-common:multicast}?
| +--rw enabled? boolean
| +--rw customer-tree-flavors
| +--rw tree-flavor* identityref
...
Figure 7: Global Parameters Profiles Subtree
図7：グローバルパラメータープロファイルサブツリー
The description of the global parameters profile is as follows:
グローバルパラメータープロファイルの説明は次のとおりです。
'profile-id': Uniquely identifies a global parameter profile in the context of an L2VPN service.
'Profile-ID'：L2VPNサービスのコンテキストでグローバルパラメータープロファイルをユニークに識別します。
'rd': As defined in [RFC9181], these RD assignment modes are supported: direct assignment, automatic assignment from a given pool, full automatic assignment, and no assignment.
'RD'：[RFC9181]で定義されているように、これらのRD割り当てモードはサポートされています：直接割り当て、特定のプールからの自動割り当て、完全な自動割り当て、および割り当てなし。
Also, the module accommodates deployments where only the Assigned Number subfield of RDs is assigned from a pool while the Administrator subfield is set to, e.g., the Router ID that is assigned to a VPN node. The module supports these modes to manage the Assigned Number subfield: explicit assignment, auto-assignment from a pool, and full auto-assignment.
また、モジュールは、RDSの割り当てられた番号サブフィールドのみがプールから割り当てられ、管理者サブフィールドがVPNノードに割り当てられたルーターIDに設定されている展開に対応します。モジュールは、これらのモードをサポートして、割り当てられた番号サブフィールドを管理します。明示的な割り当て、プールからの自動割り当て、および完全な自動割り当てです。
'vpn-targets': Specifies RT import/export rules for the VPN service.
「VPNターゲット」：VPNサービスのRTインポート/エクスポートルールを指定します。
'local-autonomous-system': Indicates the Autonomous System Number (ASN) that is configured for the VPN node. The ASN can be used to auto-derive some other attributes such as RDs or Ethernet Segment Identifiers (ESIs).
「ローカル自動システム」：VPNノード用に構成されている自律システム数（ASN）を示します。ASNは、RDSまたはイーサネットセグメント識別子（ESIS）などの他の属性（ESIS）などのいくつかの属性を自動化するために使用できます。
'svc-mtu': Is the service MTU for an L2VPN service (i.e., a Layer 2 MTU including an L2 frame header/trailer). It is also known as the maximum transmission unit or maximum frame size. It is expressed in bytes.
「SVC-MTU」：L2VPNサービスのサービスMTU（つまり、L2フレームヘッダー/トレーラーを含むレイヤー2 MTU）です。また、最大送信ユニットまたは最大フレームサイズとしても知られています。バイトで表されます。
'ce-vlan-preservation': Is set to preserve the Customer Edge VLAN (CE VLAN) IDs from ingress to egress, i.e., CE VLAN tags of the egress frame are identical to those of the ingress frame that yielded this egress service frame. If all-to-one bundling within a site is enabled, then preservation applies to all ingress service frames. If all-to-one bundling is disabled, then preservation applies to tagged Ingress service frames having CE VLAN ID 1 through 4094.
「CE-VLAN保存」：顧客エッジVLAN（CE VLAN）IDをイングレスから出口まで保存するように設定されています。つまり、EgressフレームのCE VLANタグは、この出口サービスフレームを生成したイングレスフレームと同一です。サイト内のすべてのバンドルが有効になっている場合、保存はすべてのイングレスサービスフレームに適用されます。すべてのバンドルが無効になっている場合、CE VLAN ID 1から4094を持つタグ付きイングレスサービスフレームに保存が適用されます。
'ce-vlan-cos-preservation': Controls the CE VLAN Class of Service (CoS) preservation. When set, Priority Code Point (PCP) bits in the CE VLAN tag of the egress frame are identical to those of the ingress frame that yielded this egress service frame.
'Ce-Vlan-Cos-PreSative'：CE VLANサービスのサービス（COS）保存を制御します。設定すると、出口フレームのCE VLANタグの優先コードポイント（PCP）ビットは、この出口サービスフレームを生成した侵入フレームのビットと同じです。
'control-word-negotiation': Controls whether control-word negotiation is enabled (if set to true) or not (if set to false). Refer to Section 7 of [RFC8077] for more details.
「コントロールワードネゴシエーション」：コントロールワード交渉が有効になっているかどうか（TRUEに設定されている場合）（falseに設定されている場合）を制御します。詳細については、[RFC8077]のセクション7を参照してください。
'mac-policies': Includes a set of MAC policies that apply to the service:
「Mac-Policies」：サービスに適用される一連のMacポリシーが含まれています。
'mac-addr-limit': Is a container of MAC address limit configuration. It includes the following data nodes:
「Mac-Addr-Limit」：Macアドレス制限構成のコンテナです。次のデータノードが含まれています。
'limit-number': Maximum number of MAC addresses learned from the customer for a single service instance.
「Limit-Number」：単一のサービスインスタンスについて、顧客から学習したMacアドレスの最大数。
'time-interval': The aging time of the MAC address.
「時間間」：MACアドレスの老化時間。
'action': Specifies the action when the upper limit is exceeded: drop the packet, flood the packet, or simply send a warning message.
「アクション」：上限を超えたときにアクションを指定します。パケットをドロップしたり、パケットを殺したり、警告メッセージを送信したりします。
'mac-loop-prevention': Container for MAC loop prevention.
「Mac-Loop-Prevention」：Macループ予防用のコンテナ。
'window': The time interval over which a MAC mobility event is detected and checked.
「ウィンドウ」：MACモビリティイベントが検出されてチェックされる時間間隔。
'frequency': The number of times to detect MAC duplication, where a 'duplicate MAC address' situation has occurred within the 'window' time interval, and the duplicate MAC address has been added to a list of duplicate MAC addresses.
「頻度」：「ウィンドウ」時間間隔内で「重複したMACアドレス」状況が発生し、重複したMACアドレスのリストに追加されたMACの重複を検出する回数があります。
'retry-timer': The retry timer. When the retry timer expires, the duplicate MAC address will be flushed from the MAC-VRF.
'Retry-Timer'：The Retry Timer。再試行タイマーの有効期限が切れると、重複したMACアドレスがMAC-VRFからフラッシュされます。
'protection-type': It defines the loop prevention type (e.g., shut).
'Protection-Type'：ループ予防タイプ（シャット）を定義します。
'multicast': Controls whether multicast is allowed in the service.
「マルチキャスト」：マルチキャストがサービスで許可されているかどうかを制御します。
The 'vpn-node' (Figure 8) is an abstraction that represents a set of policies applied to a network node that belongs to a single 'vpn-service'. A 'vpn-node' contains 'vpn-network-accesses', which are the interfaces involved in the creation of the VPN. The customer sites are connected to the 'vpn-network-accesses'.
「VPNノード」（図8）は、単一の「VPNサービス」に属するネットワークノードに適用される一連のポリシーを表す抽象化です。「VPNノード」には、「VPN-Network-Accesses」が含まれます。これは、VPNの作成に関与するインターフェイスです。顧客サイトは「VPN-Network-Accesses」に接続されています。
+--rw l2vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
+--rw vpn-node-id vpn-common:vpn-id
+--rw description? string
+--rw ne-id? string
+--rw role? identityref
+--rw router-id? rt-types:router-id
+--rw active-global-parameters-profiles
| +--rw global-parameters-profile* [profile-id]
| +--rw profile-id leafref
| +--rw local-autonomous-system?
| | inet:as-number
| +--rw svc-mtu? uint32
| +--rw ce-vlan-preservation? boolean
| +--rw ce-vlan-cos-preservation? boolean
| +--rw control-word-negotiation? boolean
| +--rw mac-policies
| | +--rw mac-addr-limit
| | | +--rw limit-number? uint16
| | | +--rw time-interval? uint32
| | | +--rw action? identityref
| | +--rw mac-loop-prevention
| | +--rw window? uint32
| | +--rw frequency? uint32
| | +--rw retry-timer? uint32
| | +--rw protection-type? identityref
| +--rw multicast {vpn-common:multicast}?
| +--rw enabled? boolean
| +--rw customer-tree-flavors
| +--rw tree-flavor* identityref
+--rw status
| ...
+--rw bgp-auto-discovery
| ...
+--rw signaling-option
| ...
+--rw vpn-network-accesses
...
Figure 8: VPN Nodes Subtree
図8：VPNノードサブツリー
The descriptions of VPN node data nodes are as follows:
VPNノードデータノードの説明は次のとおりです。
'vpn-node-id': Used to uniquely identify a node that enables a VPN network access.
'vpn-node-id'：VPNネットワークアクセスを有効にするノードを一意に識別するために使用されます。
'description': Provides a textual description of the VPN node.
「説明」：VPNノードのテキスト説明を提供します。
'ne-id': Includes an identifier of the network element where the VPN node is deployed.
'ne-id'：VPNノードが展開されるネットワーク要素の識別子を含む。
'role': Indicates the role of the VPN instance profile in the VPN. Role values are defined in [RFC9181] (e.g., 'any-to-any-role', 'spoke-role', and 'hub-role').
「役割」：VPNにおけるVPNインスタンスプロファイルの役割を示します。ロール値は[RFC9181]（例えば、「任意のロール」、「スポークロール」、「ハブロール」）で定義されます。
'router-id': Indicates a 32-bit number that is used to uniquely identify a router within an AS.
「Router-ID」：AS内のルーターを一意に識別するために使用される32ビット番号を示します。
'active-global-parameters-profiles': Lists the set of active global VPN parameter profiles for this VPN node. Concretely, one or more global profiles that are defined at the VPN service level (i.e., under 'l2vpn-ntw/vpn-services/vpn-service' level) can be activated at the VPN node level; each of these profiles is uniquely identified by means of 'profile-id'. The structure of 'active-global-parameters-profiles' uses the same data nodes as Section 7.4 with the exception of the data nodes related to RD and RT.
'Active-Global-Parameters-Profiles'：このVPNノードのアクティブなグローバルVPNパラメータープロファイルのセットをリストします。具体的には、VPNサービスレベルで定義されている1つ以上のグローバルプロファイル（つまり、 'L2VPN-NTW/VPN-Services/VPN-Service'レベルの下）をVPNノードレベルでアクティブ化できます。これらの各プロファイルは、「プロファイルID」によって一意に識別されます。「Active-Global-Parameters-Profiles」の構造は、RDとRTに関連するデータノードを除き、セクション7.4と同じデータノードを使用します。
Values defined in 'active-global-parameters-profiles' override the values defined in the VPN service level.
「Active-Global-Parameters-Profiles」で定義されている値は、VPNサービスレベルで定義された値をオーバーライドします。
'status': Tracks the status of a node involved in a VPN service. Both operational and administrative status are maintained. A mismatch between the administrative status vs. the operational status can be used as a trigger to detect anomalies.
「ステータス」：VPNサービスに含まれるノードのステータスを追跡します。運用ステータスと管理ステータスの両方が維持されます。管理ステータスと運用ステータス間の不一致は、異常を検出するトリガーとして使用できます。
'bgp-auto-discovery': See Section 7.5.1.
'BGP-auto-discovery'：セクション7.5.1を参照してください。
'signaling-option': See Section 7.5.2.
「シグナリングオプション」：セクション7.5.2を参照してください。
'vpn-network-accesses': Represents the point to which sites are connected.
「VPN-Network-Accesses」：サイトが接続されているポイントを表します。
Note that, unlike the L2SM, the L2NM does not need to model the customer site; only the points that receive traffic from the site are covered (i.e., the PE side of Provider Edge to Customer Edge (PE-CE) connections). Hence, the VPN network access contains the connectivity information between the provider's network and the customer premises. The VPN profiles ('vpn-profiles') have a set of routing policies that can be applied during the service creation.
L2SMとは異なり、L2NMは顧客サイトをモデル化する必要がないことに注意してください。サイトからトラフィックを受け取るポイントのみがカバーされています（つまり、プロバイダーエッジのPE側から顧客エッジ（PE-CE）接続）。したがって、VPNネットワークアクセスには、プロバイダーのネットワークと顧客の施設間の接続情報が含まれています。VPNプロファイル（ 'VPNプロファイル'）には、サービスの作成中に適用できる一連のルーティングポリシーがあります。
See Section 7.6 for more details.
詳細については、セクション7.6を参照してください。
The 'bgp-auto-discovery' container (Figure 9) includes the required information for the activation of BGP auto-discovery [RFC4761][RFC6624].
「BGP-autoscovery」コンテナ（図9）には、BGP自動発見[RFC4761] [RFC6624]の活性化に必要な情報が含まれています。
+--rw l2vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw bgp-auto-discovery
| +--rw (bgp-type)?
| | +--:(l2vpn-bgp)
| | | +--rw vpn-id?
| | | vpn-common:vpn-id
| | +--:(evpn-bgp)
| | +--rw evpn-type? leafref
| | +--rw auto-rt-enable? boolean
| | +--ro auto-route-target?
| | rt-types:route-target
| +--rw (rd-choice)?
| | +--:(directly-assigned)
| | | +--rw rd?
| | | rt-types:route-distinguisher
| | +--:(directly-assigned-suffix)
| | | +--rw rd-suffix? uint16
| | +--:(auto-assigned)
| | | +--rw rd-auto
| | | +--rw (auto-mode)?
| | | | +--:(from-pool)
| | | | | +--rw rd-pool-name? string
| | | | +--:(full-auto)
| | | | +--rw auto? empty
| | | +--ro auto-assigned-rd?
| | | rt-types:route-distinguisher
| | +--:(auto-assigned-suffix)
| | | +--rw rd-auto-suffix
| | | +--rw (auto-mode)?
| | | | +--:(from-pool)
| | | | | +--rw rd-pool-name? string
| | | | +--:(full-auto)
| | | | +--rw auto? empty
| | | +--ro auto-assigned-rd-suffix? uint16
| | +--:(no-rd)
| | +--rw no-rd? empty
| +--rw vpn-target* [id]
| | +--rw id uint8
| | +--rw route-targets* [route-target]
| | | +--rw route-target rt-types:route-target
| | +--rw route-target-type
| | rt-types:route-target-type
| +--rw vpn-policies
| +--rw import-policy? string
| +--rw export-policy? string
+--rw signaling-option
| ...
+--rw vpn-network-accesses
...
Figure 9: BGP Auto-Discovery Subtree
図9：BGPオートディスコービリサブツリー
As discussed in Section 1 of [RFC6624], all BGP-based methods include the notion of a VPN identifier that serves to unify components of a given VPN and the concept of auto-discovery, hence the support of the data node 'vpn-id'.
[RFC6624]のセクション1で説明したように、すべてのBGPベースの方法には、特定のVPNのコンポーネントを統一するのに役立つVPN識別子の概念と自動指定の概念が含まれているため、データノード 'VPN-IDのサポートが含まれます。'。
For the particular case of EVPN, the L2NM supports RT auto-derivation based on the Ethernet Tag ID specified in Section 7.10.1 of [RFC7432]. A VPN service provider can enable/disable this functionality by means of 'auto-rt-enable'. The assigned RT can be retrieved using 'auto-route-target'.
EVPNの特定のケースでは、L2NMは[RFC7432]のセクション7.10.1で指定されたイーサネットタグIDに基づいたRT自動排除をサポートします。VPNサービスプロバイダーは、「Auto-RT-exenable」を使用してこの機能を有効/無効にすることができます。割り当てられたRTは、「Auto-Route-Target」を使用して取得できます。
For all BGP-based L2VPN flavors, other data nodes such as RD and RT are used. These data nodes have the same structure as the one discussed in Section 7.4.
すべてのBGPベースのL2VPNフレーバーについて、RDやRTなどの他のデータノードが使用されます。これらのデータノードは、セクション7.4で説明したものと同じ構造を持っています。
The 'signaling-option' container (Figure 10) defines a set of data nodes for a given signaling protocol that is used for an L2VPN service. As discussed in Section 7.3, several signaling options to exchange membership information between PEs of an L2VPN are supported. The signaling type to be used for an L2VPN service is controlled at the VPN service level by means of 'signaling-type'.
「シグナルオプション」コンテナ（図10）は、L2VPNサービスに使用される特定のシグナリングプロトコルのデータノードのセットを定義しています。セクション7.3で説明したように、L2VPNのPE間でメンバーシップ情報を交換するためのいくつかのシグナリングオプションがサポートされています。L2VPNサービスに使用されるシグナリングタイプは、「シグナリングタイプ」を使用してVPNサービスレベルで制御されます。
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw signaling-option
| +--rw advertise-mtu? boolean
| +--rw mtu-allow-mismatch? boolean
| +--rw signaling-type? leafref
| +--rw (signaling-option)?
| +--:(bgp)
| | ...
| +--:(ldp-or-l2tp)
| +--rw ldp-or-l2tp
| ...
| +--rw (ldp-or-l2tp)?
| +--:(ldp)
| | ...
| +--:(l2tp)
| ...
Figure 10: Signaling Option Overall Subtree
図10：シグナリングオプション全体サブツリー
The following signaling data nodes are supported:
次のシグナリングデータノードがサポートされています。
'advertise-mtu': Controls whether MTU is advertised when setting a pseudowire (e.g., Section 4.3 of [RFC4667], Section 5.1 of [RFC6624], or Section 6.1 of [RFC4762]).
'Advertise-Mtu'：擬似化時にMTUが宣伝されているかどうかを制御します（例：[RFC467]のセクション4.3、[RFC6624]のセクション5.1、または[RFC4762]のセクション6.1）。
'mtu-allow-mismatch': When set to true, it allows an MTU mismatch for a pseudowire (see, e.g., Section 4.3 of [RFC4667]).
「MTU-Allow-Mismatch」：Trueに設定すると、擬似具体のMTUの不一致が許可されます（たとえば、[RFC467]のセクション4.3を参照）。
'signaling-type': Indicates the signaling type. This type inherits the value of 'signaling-type' defined at the service level (Section 7.3).
「シグナリングタイプ」：シグナリングタイプを示します。このタイプは、サービスレベルで定義された「シグナルタイプ」の値を継承します（セクション7.3）。
'bgp': Is provided when BGP is used for L2VPN signaling. Refer to Section 7.5.2.1 for more details.
'BGP'：BGPがL2VPNシグナル伝達に使用されるときに提供されます。詳細については、セクション7.5.2.1を参照してください。
'ldp': The model supports the configuration of the parameters that are discussed in Section 6 of [RFC4762]. Refer to Section 7.5.2.2 for more details.
「LDP」：モデルは、[RFC4762]のセクション6で説明されているパラメーターの構成をサポートしています。詳細については、セクション7.5.2.2を参照してください。
'l2tp': The model supports the configuration of the parameters that are discussed in Section 4 of [RFC4667]. Refer to Section 7.5.2.3 for more details.
'L2TP'：モデルは、[RFC4667]のセクション4で説明されているパラメーターの構成をサポートしています。詳細については、セクション7.5.2.3を参照してください。
Note that LDP and L2TP choices are bundled ("ldp-or-l2tp") because they share a set of common parameters that are further detailed in Sections 7.5.2.2 and 7.5.2.3.
LDPおよびL2TPの選択肢は、セクション7.5.2.2および7.5.2.3でさらに詳述されている共通パラメーターのセットを共有しているため、バンドルされていることに注意してください（ "LDP-OR-L2TP"）。
The structure of the BGP-related data nodes is provided in Figure 11.
BGP関連のデータノードの構造を図11に示します。
...
| +--rw (signaling-option)?
| ...
| +--:(bgp)
| | +--rw (bgp-type)?
| | +--:(l2vpn-bgp)
| | | +--rw ce-range? uint16
| | | +--rw pw-encapsulation-type?
| | | | identityref
| | | +--rw vpls-instance
| | | +--rw vpls-edge-id? uint16
| | | +--rw vpls-edge-id-range? uint16
| | +--:(evpn-bgp)
| | +--rw evpn-type? leafref
| | +--rw service-interface-type?
| | | identityref
| | +--rw evpn-policies
| | +--rw mac-learning-mode?
| | | identityref
| | +--rw ingress-replication?
| | | boolean
| | +--rw p2mp-replication?
| | | boolean
| | +--rw arp-proxy {vpn-common:ipv4}?
| | | +--rw enable? boolean
| | | +--rw arp-suppression?
| | | | boolean
| | | +--rw ip-mobility-threshold?
| | | | uint16
| | | +--rw duplicate-ip-detection-interval?
| | | uint16
| | +--rw nd-proxy {vpn-common:ipv6}?
| | | +--rw enable? boolean
| | | +--rw nd-suppression?
| | | | boolean
| | | +--rw ip-mobility-threshold?
| | | | uint16
| | | +--rw duplicate-ip-detection-interval?
| | | uint16
| | +--rw underlay-multicast?
| | | boolean
| | +--rw flood-unknown-unicast-suppression?
| | | boolean
| | +--rw vpws-vlan-aware? boolean
| | +--rw bum-management
| | | +--rw discard-broadcast?
| | | | boolean
| | | +--rw discard-unknown-multicast?
| | | | boolean
| | | +--rw discard-unknown-unicast?
| | | boolean
| | +--rw pbb
| | +--rw backbone-src-mac?
| | yang:mac-address
| +--:(ldp-or-l2tp)
| ...
Figure 11: Signaling Option Subtree (BGP)
図11：シグナリングオプションサブツリー（BGP）
Remote CEs that are entitled to connect to the same VPN should fit with the CE range ('ce-range') as discussed in Section 2.2.3 of [RFC6624]. 'pw-encapsulation-type' is used to control the pseudowire encapsulation type (Section 3 of [RFC6624]). The value of the 'pw-encapsulation-type' is taken from the IANA-maintained "iana-bgp-l2-encaps" module (Section 8.1).
[RFC6624]のセクション2.2.3で説明するように、同じVPNに接続する権利があるリモートCEは、CE範囲（「CE-Range」）に適合する必要があります。「PW-Encapsulation-Type」は、擬似ワイヤーカプセル化タイプを制御するために使用されます（[RFC6624]のセクション3）。「PWエンカプセル化タイプ」の値は、IANAが維持した「IANA-BGP-L2-ENCAPS」モジュール（セクション8.1）から取得されます。
For the specific case of VPLS, the VPLS Edge Identifier (VE ID) ('vpls-edge-id') and a VE ID range ('vpls-edge-id-range') are provided as per Section 3.2 of [RFC4761]. If different VE IDs are required (e.g., multihoming as per Section 3.5 of [RFC4761]), these IDs are configured at the VPN network access level (under 'signaling-option' in Section 7.6).
VPLSの特定の場合、VPLSエッジ識別子（VE ID）（ 'VPLS-EDED-ID'）とVE ID範囲（ 'VPLS-EDED-ID-RANGE'）は[RFC4761]のセクション3.2に従って提供されます。。異なるVE IDが必要な場合（たとえば、[RFC4761]のセクション3.5に従ってマルチホーム）、これらのIDはVPNネットワークアクセスレベル（セクション7.6の「シグナルオプション」の下）で構成されます。
For EVPN-related L2VPNs, 'service-interface-type' indicates whether this is a VLAN-based, VLAN-aware, or VLAN bundle service interface (Section 6 of [RFC7432]). Moreover, a set of policies can be provided such as the MAC address learning mode (Section 9 of [RFC7432]), ingress replication (Section 12.1 of [RFC7432]), the Address Resolution Protocol (ARP) and Neighbor Discovery (ND) proxy (Section 10 of [RFC7432]), the processing of Broadcast, Unknown Unicast, or Multicast (BUM) (Section 12 of [RFC7432]), etc.
EVPN関連のL2VPNの場合、「サービスインターフェイスタイプ」は、これがVLANベース、VLAN-Aware、またはVLANバンドルサービスインターフェイスであるかどうかを示します（[RFC7432]のセクション6）。さらに、MACアドレス学習モード（[RFC7432]のセクション9）、イングレスレプリケーション（[RFC7432]のセクション12.1）、アドレス解像度プロトコル（ARP）、近隣発見（ND）プロキシなど、一連のポリシーを提供できます。（[RFC7432]のセクション10）、ブロードキャスト、不明なユニキャスト、またはマルチキャスト（BUM）（[RFC7432]のセクション12）などの処理。
The L2NM supports the configuration of the parameters that are discussed in Section 6 of [RFC4762]. Such parameters include an Attachment Group Identifier (AGI) (a.k.a., VPLS-id), a Source Attachment Individual Identifier (SAII), a list of peers that are associated with a Target Attachment Individual Identifier (TAII), a pseudowire type, and a pseudowire description (Figure 12). Unlike BGP, only Ethernet and Ethernet tagged mode are supported. The AGI, SAII, and TAII are encoded following the types defined in Section 3.4 of [RFC4446].
L2NMは、[RFC4762]のセクション6で説明されているパラメーターの構成をサポートしています。このようなパラメーターには、アタッチメントグループ識別子（AGI）（別名、VPLS-ID）、ソースアタッチメント個体識別子（SAII）、ターゲットアタッチメントの個別識別子（TAII）に関連付けられているピアのリスト、擬似型タイプ、および擬似動物の説明（図12）。BGPとは異なり、イーサネットとイーサネットのタグ付きモードのみがサポートされています。AGI、SAII、およびTAIIは、[RFC4446]のセクション3.4で定義されているタイプに従ってエンコードされています。
...
| +--rw (signaling-option)?
| ...
| +--:(bgp)
| | ...
| +--:(ldp-or-l2tp)
| +--rw ldp-or-l2tp
| +--rw agi?
| | rt-types:route-distinguisher
| +--rw saii? uint32
| +--rw remote-targets* [taii]
| | +--rw taii uint32
| | +--rw peer-addr inet:ip-address
| +--rw (ldp-or-l2tp)?
| +--:(ldp)
| | +--rw t-ldp-pw-type?
| | | identityref
| | +--rw pw-type? identityref
| | +--rw pw-description? string
| | +--rw mac-addr-withdraw? boolean
| | +--rw pw-peer-list*
| | | [peer-addr vc-id]
| | | +--rw peer-addr
| | | | inet:ip-address
| | | +--rw vc-id string
| | | +--rw pw-priority? uint32
| | +--rw qinq
| | +--rw s-tag dot1q-types:vlanid
| | +--rw c-tag dot1q-types:vlanid
| +--:(l2tp)
| ...
...
Figure 12: Signaling Option Subtree (LDP)
図12：シグナリングオプションサブツリー（LDP）
The L2NM supports the configuration of the parameters that are discussed in Section 4 of [RFC4667]. Such parameters include a Router ID that is used to uniquely identify a PE, a pseudowire type, an AGI, an SAII, and a list of peers that are associated with a TAII (Figure 13). The pseudowire type ('pseudowire-type') value is taken from the IANA-maintained "iana-pseudowire-types" module (Section 8.2).
L2NMは、[RFC4667]のセクション4で説明されているパラメーターの構成をサポートしています。このようなパラメーターには、PE、擬似ワイヤタイプ、AGI、SAII、およびTAIIに関連するピアのリストを一意に識別するために使用されるルーターIDが含まれます（図13）。擬似動物型（「擬似型」）値は、IANAに維持された「Iana-Pseudowire-Types」モジュール（セクション8.2）から取得されます。
...
| +--rw (signaling-option)?
| ...
| +--:(bgp)
| | ...
| +--:(ldp-or-l2tp)
| +--rw ldp-or-l2tp
| +--rw agi?
| | rt-types:route-distinguisher
| +--rw saii? uint32
| +--rw remote-targets* [taii]
| | +--rw taii uint32
| | +--rw peer-addr inet:ip-address
| +--rw (ldp-or-l2tp)?
| +--:(ldp)
| | ...
| +--:(l2tp)
| +--rw router-id?
| | rt-types:router-id
| +--rw pseudowire-type?
| identityref
...
Figure 13: Signaling Option Subtree (L2TP)
図13：シグナリングオプションサブツリー（L2TP）
A 'vpn-network-access' (Figure 14) represents an entry point to a VPN service. In other words, this container encloses the parameters that describe the access information for the traffic that belongs to a particular L2VPN.
'vpn-network-access'（図14）は、VPNサービスへのエントリポイントを表します。言い換えれば、このコンテナは、特定のL2VPNに属するトラフィックのアクセス情報を説明するパラメーターを囲みます。
A 'vpn-network-access' includes information such as the connection on which the access is defined, the specific Layer 2 service requirements, etc.
「VPN-Network-Access」には、アクセスが定義されている接続、特定のレイヤー2サービス要件などの情報が含まれます。
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
+--rw id vpn-common:vpn-id
+--rw description? string
+--rw interface-id? string
+--rw active-vpn-node-profile? leafref
+--rw status
| ...
+--rw connection
| ...
+--rw (signaling-option)?
| +--:(bgp)
| +--rw (bgp-type)?
| +--:(l2vpn-bgp)
| | +--rw ce-id? uint16
| | +--rw remote-ce-id? uint16
| | +--rw vpls-instance
| | +--rw vpls-edge-id? uint16
| +--:(evpn-bgp)
| +--rw df-preference? uint16
| +--rw vpws-service-instance
| ...
+--rw group* [group-id]
| +--rw group-id string
| +--rw precedence? identityref
| +--rw ethernet-segment-identifier?
| l2vpn-es:es-ref
+--rw ethernet-service-oam
| ...
+--rw service
...
Figure 14: VPN Network Access Subtree
図14：VPNネットワークアクセスサブツリー
The VPN network access is comprised of the following:
VPNネットワークアクセスは、以下で構成されています。
'id': Includes an identifier of the VPN network access.
「ID」：VPNネットワークアクセスの識別子が含まれています。
'description': Includes a textual description of the VPN network access.
「説明」：VPNネットワークアクセスのテキスト説明が含まれています。
'interface-id': Indicates the interface on which the VPN network access is bound.
'interface-id'：VPNネットワークアクセスがバインドされるインターフェイスを示します。
'active-vpn-node-profile': Provides a pointer to an active 'global-parameters-profile' at the VPN node level. Referencing an active 'global-parameters-profile' implies that all associated data nodes will be inherited by the VPN network access. However, some of the inherited data nodes (e.g., ACL policies) can be overridden at the VPN network access level. In such case, adjusted values take precedence over inherited values.
「Active-VPN-Node-Profile」：VPNノードレベルでのアクティブな「グローバルパラメータープロファイル」へのポインターを提供します。アクティブな「グローバルパラメータープロファイル」を参照することは、関連するすべてのデータノードがVPNネットワークアクセスによって継承されることを意味します。ただし、継承されたデータノードの一部（ACLポリシーなど）は、VPNネットワークアクセスレベルでオーバーライドできます。そのような場合、調整された値が継承された値よりも優先されます。
'status': Indicates the administrative and operational status of the VPN network access.
「ステータス」：VPNネットワークアクセスの管理および運用ステータスを示します。
'connection': Represents and groups the set of Layer 2 connectivity from where the traffic of the L2VPN in a particular VPN network access is coming. See Section 7.6.1.
「接続」：特定のVPNネットワークアクセスにおけるL2VPNのトラフィックが来るレイヤー2接続のセットを表し、グループ化します。セクション7.6.1を参照してください。
'signaling-option': Indicates a set of signaling options that are specific to a given VPN network access, e.g., a CE ID ('ce-id' identifying the CE within the VPN) and a remote CE ID as discussed in Section 2.2.2 of [RFC6624].
'Signaling-option'：特定のVPNネットワークアクセスに固有のシグナリングオプションのセット、たとえば、セクション2.2で説明したように、CE ID（ 'CE-ID' CEをVPN内のCEを識別する）およびリモートCE IDを示します。[RFC6624]の.2。
It can also include a set of data nodes that are required for the configuration of a VPWS-EVPN [RFC8214]. See Section 7.6.2.
また、VPWS-EVPN [RFC8214]の構成に必要なデータノードのセットも含めることができます。セクション7.6.2を参照してください。
'group': Is used for grouping VPN network accesses by assigning the same identifier to these accesses. The precedence attribute is used to differentiate the primary and secondary accesses for a service with multiple accesses. An example to illustrate the use of this container for redundancy purposes is provided in Appendix A.6. This container is also used to identify the link of an ES by allocating the same ESI. An example to illustrate this functionality is provided in Appendices A.4 and A.5.
「グループ」：これらのアクセスに同じ識別子を割り当てることにより、VPNネットワークアクセスのグループ化に使用されます。優先順位属性は、複数のアクセスを備えたサービスのプライマリアクセスとセカンダリアクセスを区別するために使用されます。冗長性の目的でこのコンテナの使用を説明する例は、付録A.6に記載されています。このコンテナは、同じESIを割り当てることにより、ESのリンクを識別するためにも使用されます。この機能を説明する例は、付録A.4およびA.5に記載されています。
'ethernet-service-oam': Carries information about the service OAM. See Section 7.6.3.
「Ethernet-Service-Oam」：サービスOAMに関する情報を伝えます。セクション7.6.3を参照してください。
'service': Specifies the service parameters (e.g., QoS and multicast) to apply for a given VPN network access. See Section 7.6.4.
「サービス」：特定のVPNネットワークアクセスを申請するためのサービスパラメーター（QoSやマルチキャストなど）を指定します。セクション7.6.4を参照してください。
The 'connection' container (Figure 15) is used to configure the relevant properties of the interface to which the L2VPN instance is attached to (e.g., encapsulation type, Link Aggregation Group (LAG) interfaces, and split-horizon). The L2NM supports tag manipulation operations (e.g., tag rewrite).
「接続」コンテナ（図15）を使用して、L2VPNインスタンスが接続されているインターフェイスの関連プロパティを構成するために（例：カプセル化タイプ、リンク集約グループ（LAG）インターフェイス、およびスプリットホリゾン）。L2NMは、タグ操作操作をサポートしています（タグ書き換えなど）。
Note that the 'connection' container does not include the physical-specific configuration as this is assumed to be directly handled using device modules (e.g., an interfaces module). Moreover, this design is also meant to avoid manipulated global parameters at the service level and lower the risk of impacting other services sharing the same physical interface.
「接続」コンテナには、デバイスモジュール（インターフェイスモジュールなど）を使用して直接処理されると想定されるため、物理固有の構成は含まれていないことに注意してください。さらに、この設計は、サービスレベルで操作されたグローバルパラメーターを避け、同じ物理インターフェイスを共有する他のサービスに影響を与えるリスクを低下させることも目的としています。
A reference to the bearer is maintained to allow keeping the link between the L2SM and the L2NM when both data models are used in a given deployment.
ベアラーへの参照は、特定の展開で両方のデータモデルが使用される場合、L2SMとL2NMの間のリンクを維持できるように維持されます。
Some consistency checks should be ensured by implementations (typically, network controllers) for LAG interfaces, as the same information (e.g., LACP system-id) should be provided to the involved nodes.
同じ情報（例：LACPシステムID）を関連するノードに提供する必要があるため、ラグインターフェイスの実装（通常はネットワークコントローラー）によっていくつかの一貫性チェックを保証する必要があります。
The L2NM inherits the 'member-link-list' structure from the L2SM (including indication of OAM 802.3ah support [IEEE-802-3ah]).
L2NMは、L2SMから「メンバーリンクリスト」構造を継承します（OAM 802.3AHサポート[IEEE-802-3AH]の表示を含む）。
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
+--rw connection
| +--rw l2-termination-point?
| | string
| +--rw local-bridge-reference?
| | string
| +--rw bearer-reference? string
| | {vpn-common:bearer-reference}?
| +--rw encapsulation
| | +--rw encap-type? identityref
| | +--rw dot1q
| | | +--rw tag-type? identityref
| | | +--rw cvlan-id?
| | | | dot1q-types:vlanid
| | | +--rw tag-operations
| | | +--rw (op-choice)?
| | | | +--:(pop)
| | | | | +--rw pop? empty
| | | | +--:(push)
| | | | | +--rw push? empty
| | | | +--:(translate)
| | | | +--rw translate? empty
| | | +--rw tag-1?
| | | | dot1q-types:vlanid
| | | +--rw tag-1-type?
| | | | dot1q-types:dot1q-tag-type
| | | +--rw tag-2?
| | | | dot1q-types:vlanid
| | | +--rw tag-2-type?
| | | dot1q-types:dot1q-tag-type
| | +--rw priority-tagged
| | | +--rw tag-type? identityref
| | +--rw qinq
| | +--rw tag-type? identityref
| | +--rw svlan-id
| | | dot1q-types:vlanid
| | +--rw cvlan-id
| | | dot1q-types:vlanid
| | +--rw tag-operations
| | +--rw (op-choice)?
| | | +--:(pop)
| | | | +--rw pop? uint8
| | | +--:(push)
| | | | +--rw push? empty
| | | +--:(translate)
| | | +--rw translate? empty
| | +--rw tag-1?
| | | dot1q-types:vlanid
| | +--rw tag-1-type?
| | | dot1q-types:dot1q-tag-type
| | +--rw tag-2?
| | | dot1q-types:vlanid
| | +--rw tag-2-type?
| | dot1q-types:dot1q-tag-type
| +--rw lag-interface
| | {vpn-common:lag-interface}?
| +--rw lag-interface-id? string
| +--rw lacp
| | +--rw lacp-state? boolean
| | +--rw mode? identityref
| | +--rw speed? uint32
| | +--rw mini-link-num? uint32
| | +--rw system-id?
| | | yang:mac-address
| | +--rw admin-key? uint16
| | +--rw system-priority? uint16
| | +--rw member-link-list
| | | +--rw member-link* [name]
| | | +--rw name string
| | | +--rw speed? uint32
| | | +--rw mode? identityref
| | | +--rw link-mtu? uint32
| | | +--rw oam-802.3ah-link
| | | | {oam-3ah}?
| | | +--rw enable? boolean
| | +--rw flow-control? boolean
| | +--rw lldp? boolean
| +--rw split-horizon
| +--rw group-name? string
...
Figure 15: Connection Subtree
図15：接続サブツリー
The 'vpws-service-instance' provides the local and remote VPWS Service Instance (VSI) [RFC8214]. This container is only present when the 'vpn-type' is VPWS-EVPN. As shown in Figure 16, the VSIs can be configured by a VPN service provider or auto-generated.
「VPWS-Service-Instance」は、ローカルおよびリモートVPWSサービスインスタンス（VSI）[RFC8214]を提供します。このコンテナは、「VPNタイプ」がVPWS-EVPNの場合にのみ存在します。図16に示すように、VSIはVPNサービスプロバイダーによって構成または自動生成されます。
An example to illustrate the use of the L2NM to configure VPWS-EVPN instances is provided in Appendix A.4.
VPWS-EVPNインスタンスを構成するためにL2NMの使用を説明する例を付録A.4に示します。
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
+--rw (signaling-option)?
| +--:(bgp)
| +--rw (bgp-type)?
| +--:(l2vpn-bgp)
| | ...
| +--:(evpn-bgp)
| +--rw df-preference? uint16
| +--rw vpws-service-instance
| +--rw (local-vsi-choice)?
| | +--:(directly-assigned)
| | | +--rw local-vpws-service-instance?
| | | uint32
| | +--:(auto-assigned)
| | +--rw local-vsi-auto
| | +--rw (auto-mode)?
| | | +--:(from-pool)
| | | | +--rw vsi-pool-name?
| | | | string
| | | +--:(full-auto)
| | | +--rw auto? empty
| | +--ro auto-local-vsi? uint32
| +--rw (remote-vsi-choice)?
| +--:(directly-assigned)
| | +--rw remote-vpws-service-instance?
| | uint32
| +--:(auto-assigned)
| +--rw remote-vsi-auto
| +--rw (auto-mode)?
| | +--:(from-pool)
| | | +--rw vsi-pool-name?
| | | string
| | +--:(full-auto)
| | +--rw auto? empty
| +--ro auto-remote-vsi? uint32
...
Figure 16: EVPN-VPWS Service Instance Subtree
図16：EVPN-VPWSサービスインスタンスサブツリー
Ethernet OAM refers to both [IEEE-802-1ag] and [ITU-T-Y-1731].
イーサネットOAMは、[IEEE-802-1AG]と[ITU-T-Y-1731]の両方を指します。
As shown in Figure 17, the L2NM inherits the same structure as in Section 5.3.2.2.6 of [RFC8466] for OAM matters.
図17に示すように、L2NMはOAMの問題について[RFC8466]のセクション5.3.2.2.6と同じ構造を継承しています。
+--rw l2vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
+--rw ethernet-service-oam
| +--rw md-name? string
| +--rw md-level? uint8
| +--rw cfm-802.1-ag
| | +--rw n2-uni-c* [maid]
| | | +--rw maid string
| | | +--rw mep-id? uint32
| | | +--rw mep-level? uint32
| | | +--rw mep-up-down?
| | | | enumeration
| | | +--rw remote-mep-id? uint32
| | | +--rw cos-for-cfm-pdus? uint32
| | | +--rw ccm-interval? uint32
| | | +--rw ccm-holdtime? uint32
| | | +--rw ccm-p-bits-pri?
| | | ccm-priority-type
| | +--rw n2-uni-n* [maid]
| | +--rw maid string
| | +--rw mep-id? uint32
| | +--rw mep-level? uint32
| | +--rw mep-up-down?
| | | enumeration
| | +--rw remote-mep-id? uint32
| | +--rw cos-for-cfm-pdus? uint32
| | +--rw ccm-interval? uint32
| | +--rw ccm-holdtime? uint32
| | +--rw ccm-p-bits-pri?
| | ccm-priority-type
| +--rw y-1731* [maid]
| +--rw maid string
| +--rw mep-id? uint32
| +--rw pm-type? identityref
| +--rw remote-mep-id? uint32
| +--rw message-period? uint32
| +--rw measurement-interval? uint32
| +--rw cos? uint32
| +--rw loss-measurement? boolean
| +--rw synthetic-loss-measurement?
| | boolean
| +--rw delay-measurement
| | +--rw enable-dm? boolean
| | +--rw two-way? boolean
| +--rw frame-size? uint32
| +--rw session-type? enumeration
...
Figure 17: OAM Subtree
図17：OAMサブツリー
The 'service' container (Figure 18) provides a set of service-specific configurations such as QoS.
「サービス」コンテナ（図18）は、QoSなどのサービス固有の構成のセットを提供します。
+--rw l2vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
...
+--rw vpn-nodes
+--rw vpn-node* [vpn-node-id]
...
+--rw vpn-network-accesses
+--rw vpn-network-access* [id]
...
+--rw service
+--rw mtu? uint32
+--rw svc-pe-to-ce-bandwidth
| {vpn-common:inbound-bw}?
| ...
+--rw svc-ce-to-pe-bandwidth
| {vpn-common:outbound-bw}?
| ...
+--rw qos {vpn-common:qos}?
| ...
+--rw mac-policies
| ...
+--rw broadcast-unknown-unicast-multicast
...
Figure 18: Service Overall Subtree
図18：サービス全体のサブツリー
The description of the service data nodes is as follows:
サービスデータノードの説明は次のとおりです。
'mtu': Specifies the Layer 2 MTU, in bytes, for the VPN network access.
'mtu'：VPNネットワークアクセス用のレイヤー2 mtuをバイト単位で指定します。
'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth': Specify the service bandwidth for the L2VPN service.
「SVC-PE-to-CE-BandWidth」および「SVC-CE-to-PE-BandWidth」：L2VPNサービスのサービス帯域幅を指定します。
'svc-pe-to-ce-bandwidth' indicates the inbound bandwidth of the connection (i.e., download bandwidth from the service provider to the site).
「SVC-PE-to-CE-BandWidth」は、接続のインバウンド帯域幅を示します（つまり、サービスプロバイダーからサイトへの帯域幅をダウンロードします）。
'svc-ce-to-pe-bandwidth' indicates the outbound bandwidth of the connection (i.e., upload bandwidth from the site to the service provider).
「SVC-CE-to-PE-BandWidth」は、接続のアウトバウンド帯域幅を示します（つまり、サイトからサービスプロバイダーへの帯域幅をアップロードします）。
'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth' can be represented using the Committed Information Rate (CIR), the Excess Information Rate (EIR), or the Peak Information Rate (PIR).
「SVC-PE-to-CE-BandWidth」および「SVC-CE-to-PE-BandWidth」は、コミットされた情報レート（CIR）、超過情報レート（EIR）、またはピーク情報レート（PIR）を使用して表現できます。）。
As shown in Figure 19, the structure of service bandwidth data nodes is inherited from the L2SM [RFC8466]. The following types, defined in [RFC9181], can be used to indicate the bandwidth type:
図19に示すように、サービス帯域幅データノードの構造はL2SM [RFC8466]から継承されています。[RFC9181]で定義されている次のタイプを使用して、帯域幅タイプを示すことができます。
'bw-per-cos': The bandwidth is per CoS.
「BW-Per-Cos」：帯域幅はCosごとです。
'bw-per-port': The bandwidth is per VPN network access.
「BW-Per-Port」：帯域幅はVPNネットワークアクセスごとです。
'bw-per-site': The bandwidth is to all VPN network accesses that belong to the same site.
'BW-Per-Site'：帯域幅は、同じサイトに属するすべてのVPNネットワークアクセスに対するものです。
'bw-per-service': The bandwidth is per L2VPN service.
「BW-Per-Service」：帯域幅はL2VPNサービスごとです。
+--rw service
...
+--rw svc-pe-to-ce-bandwidth
| {vpn-common:inbound-bw}?
| +--rw pe-to-ce-bandwidth* [bw-type]
| +--rw bw-type identityref
| +--rw (type)?
| +--:(per-cos)
| | +--rw cos* [cos-id]
| | +--rw cos-id uint8
| | +--rw cir? uint64
| | +--rw cbs? uint64
| | +--rw eir? uint64
| | +--rw ebs? uint64
| | +--rw pir? uint64
| | +--rw pbs? uint64
| +--:(other)
| +--rw cir? uint64
| +--rw cbs? uint64
| +--rw eir? uint64
| +--rw ebs? uint64
| +--rw pir? uint64
| +--rw pbs? uint64
+--rw svc-ce-to-pe-bandwidth
| {vpn-common:outbound-bw}?
| +--rw ce-to-pe-bandwidth* [bw-type]
| +--rw bw-type identityref
| +--rw (type)?
| +--:(per-cos)
| | +--rw cos* [cos-id]
| | +--rw cos-id uint8
| | +--rw cir? uint64
| | +--rw cbs? uint64
| | +--rw eir? uint64
| | +--rw ebs? uint64
| | +--rw pir? uint64
| | +--rw pbs? uint64
| +--:(other)
| +--rw cir? uint64
| +--rw cbs? uint64
| +--rw eir? uint64
| +--rw ebs? uint64
| +--rw pir? uint64
| +--rw pbs? uint64
...
Figure 19: Service Bandwidth Subtree
図19：サービス帯域幅サブツリー
'qos': Is used to define a set of QoS policies to apply on a given VPN network access (Figure 20). The QoS classification can be based on many criteria such as source MAC address, destination MAC address, etc. See also Section 5.10.2.1 of [RFC8466] for more discussion of QoS classification including the use of color types.
「QOS」：特定のVPNネットワークアクセスに適用する一連のQOSポリシーを定義するために使用されます（図20）。QoS分類は、ソースMACアドレス、宛先MACアドレスなどの多くの基準に基づいています。色タイプの使用を含むQoS分類の詳細については、[RFC8466]のセクション5.10.2.1も参照してください。
+--rw service
...
+--rw qos {vpn-common:qos}?
| +--rw qos-classification-policy
| | +--rw rule* [id]
| | +--rw id string
| | +--rw (match-type)?
| | | +--:(match-flow)
| | | | +--rw match-flow
| | | | +--rw dscp? inet:dscp
| | | | +--rw dot1q? uint16
| | | | +--rw pcp? uint8
| | | | +--rw src-mac-address?
| | | | | yang:mac-address
| | | | +--rw dst-mac-address?
| | | | | yang:mac-address
| | | | +--rw color-type?
| | | | | identityref
| | | | +--rw any? empty
| | | +--:(match-application)
| | | +--rw match-application?
| | | identityref
| | +--rw target-class-id? string
| +--rw qos-profile
| +--rw qos-profile* [profile]
| +--rw profile leafref
| +--rw direction? identityref
...
Figure 20: QoS Subtree
図20：QoSサブツリー
'mac-policies': Lists a set of MAC-related policies such as MAC ACLs. Similar to [RFC8519], an ACL match can be based upon source MAC address, source MAC address mask, destination MAC address, destination MAC address mask, or a combination thereof.
「Mac-Policies」：Mac ACLSなどのMac関連のポリシーのセットをリストしています。[RFC8519]と同様に、ACLマッチは、ソースMACアドレス、ソースMACアドレスマスク、宛先MACアドレス、宛先MACアドレスマスク、またはその組み合わせに基づいています。
A data frame that matches an ACL can be dropped, be flooded, or trigger an alarm. A rate-limit policy can be defined for handling frames that match an ACL entry with 'flood' action.
ACLに一致するデータフレームは、ドロップしたり、浸水したり、アラームをトリガーしたりできます。ACLエントリを「フラッド」アクションと一致させるフレームを処理するために、レート制限ポリシーを定義できます。
When 'mac-loop-prevention' or 'mac-addr-limit' data nodes are provided, they take precedence over the ones included in the 'global-parameters-profile' at the VPN service or VPN node levels.
「Mac-Loop-Prevention」または「Mac-Addr-Limit」データノードが提供されると、VPNサービスまたはVPNノードレベルの「グローバルパラメータープロファイル」に含まれるものよりも優先されます。
+--rw service
...
+--rw mac-policies
| +--rw access-control-list* [name]
| | +--rw name string
| | +--rw src-mac-address*
| | | yang:mac-address
| | +--rw src-mac-address-mask*
| | | yang:mac-address
| | +--rw dst-mac-address*
| | | yang:mac-address
| | +--rw dst-mac-address-mask*
| | | yang:mac-address
| | +--rw action? identityref
| | +--rw rate-limit? decimal64
| +--rw mac-loop-prevention
| | +--rw window? uint32
| | +--rw frequency? uint32
| | +--rw retry-timer? uint32
| | +--rw protection-type? identityref
| +--rw mac-addr-limit
| +--rw limit-number? uint16
| +--rw time-interval? uint32
| +--rw action? identityref
...
Figure 21: MAC Policies Subtree
図21：Macポリシーサブツリー
'broadcast-unknown-unicast-multicast': Defines the type of site in the customer multicast service topology: source, receiver, or both. It is also used to define multicast group-to-port mappings.
「Broadcast-Unknown-Unicast-Multicast」：顧客マルチキャストサービストポロジのサイトのタイプを定義します：ソース、レシーバー、またはその両方。また、マルチキャストのグループからポートマッピングを定義するためにも使用されます。
+--rw service
...
+--rw broadcast-unknown-unicast-multicast
+--rw multicast-site-type?
| enumeration
+--rw multicast-gp-address-mapping* [id]
| +--rw id uint16
| +--rw vlan-id uint32
| +--rw mac-gp-address
| | yang:mac-address
| +--rw port-lag-number? uint32
+--rw bum-overall-rate? uint64
Figure 22: BUM Subtree
図22：バムサブツリー
The "iana-bgp-l2-encaps" YANG module matches the "BGP Layer 2 Encapsulation Types" registry [IANA-BGP-L2].
「IANA-BGP-L2-ENCAPS」Yangモジュールは、「BGPレイヤー2カプセル化タイプ」レジストリ[IANA-BGP-L2]と一致します。
This module references [RFC3032], [RFC4446], [RFC4448], [RFC4553], [RFC4618], [RFC4619], [RFC4717], [RFC4761], [RFC4816], [RFC4842], and [RFC5086].
このモジュールは、[RFC3032]、[RFC4446]、[RFC4448]、[RFC4553]、[RFC4619]、[RFC4619]、[RFC4717]、[RFC4761]、[RFC48616]、[RFC4842]、[RFC4842]、
<CODE BEGINS> file "iana-bgp-l2-encaps@2022-09-20.yang"
module iana-bgp-l2-encaps {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps";
prefix iana-bgp-l2-encaps;
organization "IANA"; contact "Internet Assigned Numbers Authority
組織「IANA」;「インターネットが割り当てられた番号当局にお問い合わせください
Postal: ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 United States of America Tel: +1 310 301 5800 <mailto:iana@iana.org>"; description "This YANG module contains a collection of IANA-maintained YANG data types that are used for referring to BGP Layer 2 encapsulation types.
郵便：ICANN 12025ウォーターフロントドライブ、スイート300ロサンゼルス、CA 90094-2536アメリカ合衆国Tel：1 310 301 5800 <Mailto：iana@iana.org> ";説明"BGPレイヤー2カプセル化タイプを参照するために使用されるデータ型。
Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2022 IETF TrustおよびCodeの著者として特定された人。全著作権所有。
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).
変更とバイナリ形式での再配布と使用は、変更の有無にかかわらず、IETF Trustの法的規定（IETFドキュメントに関する法的規定）のセクション4.Cに記載されている修正されたBSDライセンスに基づいて許可されており、ライセンス条件に従います。https://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 9291; see the RFC itself for full legal notices.";
このYangモジュールのこのバージョンは、RFC 9291の一部です。完全な法的通知については、RFC自体を参照してください。」;
revision 2022-09-20 {
description
"First revision.";
reference
"RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
}
identity bgp-l2-encaps-type {
description
"Base BGP Layer 2 encapsulation type.";
reference
"RFC 6624: Layer 2 Virtual Private Networks Using BGP for
Auto-Discovery and Signaling";
}
identity frame-relay {
base bgp-l2-encaps-type;
description
"Frame Relay.";
reference
"RFC 4446: IANA Allocations for Pseudowire Edge
to Edge Emulation (PWE3)";
}
identity atm-aal5 {
base bgp-l2-encaps-type;
description
"ATM AAL5 SDU VCC transport.";
reference
"RFC 4446: IANA Allocations for Pseudowire Edge
to Edge Emulation (PWE3)";
}
identity atm-cell {
base bgp-l2-encaps-type;
description
"ATM transparent cell transport.";
reference
"RFC 4816: Pseudowire Emulation Edge-to-Edge (PWE3)
Asynchronous Transfer Mode (ATM) Transparent
Cell Transport Service";
}
identity ethernet-tagged-mode {
base bgp-l2-encaps-type;
description
"Ethernet (VLAN) Tagged Mode.";
reference
"RFC 4448: Encapsulation Methods for Transport of Ethernet
over MPLS Networks";
}
identity ethernet-raw-mode {
base bgp-l2-encaps-type;
description
"Ethernet Raw Mode.";
reference
"RFC 4448: Encapsulation Methods for Transport of Ethernet
over MPLS Networks";
}
identity hdlc {
base bgp-l2-encaps-type;
description
"Cisco HDLC.";
reference
"RFC 4618: Encapsulation Methods for Transport of
PPP/High-Level Data Link Control (HDLC)
over MPLS Networks";
}
identity ppp {
base bgp-l2-encaps-type;
description
"PPP.";
reference
"RFC 4618: Encapsulation Methods for Transport of
PPP/High-Level Data Link Control (HDLC)
over MPLS Networks";
}
identity circuit-emulation {
base bgp-l2-encaps-type;
description
"SONET/SDH Circuit Emulation Service.";
reference
"RFC 4842: Synchronous Optical Network/Synchronous Digital
Hierarchy (SONET/SDH) Circuit Emulation over Packet
(CEP)";
}
identity atm-to-vcc {
base bgp-l2-encaps-type;
description
"ATM n-to-one VCC cell transport.";
reference
"RFC 4717: Encapsulation Methods for Transport of
Asynchronous Transfer Mode (ATM) over MPLS
Networks";
}
identity atm-to-vpc {
base bgp-l2-encaps-type;
description
"ATM n-to-one VPC cell transport.";
reference
"RFC 4717: Encapsulation Methods for Transport of
Asynchronous Transfer Mode (ATM) over MPLS
Networks";
}
identity layer-2-transport {
base bgp-l2-encaps-type;
description
"IP Layer 2 Transport.";
reference
"RFC 3032: MPLS Label Stack Encoding";
}
identity fr-port-mode {
base bgp-l2-encaps-type;
description
"Frame Relay Port mode.";
reference
"RFC 4619: Encapsulation Methods for Transport of Frame Relay
over Multiprotocol Label Switching (MPLS)
Networks";
}
identity e1 {
base bgp-l2-encaps-type;
description
"Structure-agnostic E1 over packet.";
reference
"RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
over Packet (SAToP)";
}
identity t1 {
base bgp-l2-encaps-type;
description
"Structure-agnostic T1 (DS1) over packet.";
reference
"RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
over Packet (SAToP)";
}
identity vpls {
base bgp-l2-encaps-type;
description
"VPLS.";
reference
"RFC 4761: Virtual Private LAN Service (VPLS)
Using BGP for Auto-Discovery and Signaling";
}
identity t3 {
base bgp-l2-encaps-type;
description
"Structure-agnostic T3 (DS3) over packet.";
reference
"RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
over Packet (SAToP)";
}
identity structure-aware {
base bgp-l2-encaps-type;
description
"Nx64kbit/s Basic Service using Structure-aware.";
reference
"RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched
Network (CESoPSN)";
}
identity dlci {
base bgp-l2-encaps-type;
description
"Frame Relay DLCI.";
reference
"RFC 4619: Encapsulation Methods for Transport of Frame Relay
over Multiprotocol Label Switching (MPLS)
Networks";
}
identity e3 {
base bgp-l2-encaps-type;
description
"Structure-agnostic E3 over packet.";
reference
"RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
over Packet (SAToP)";
}
identity ds1 {
base bgp-l2-encaps-type;
description
"Octet-aligned payload for Structure-agnostic DS1 circuits.";
reference
"RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
over Packet (SAToP)";
}
identity cas {
base bgp-l2-encaps-type;
description
"E1 Nx64kbit/s with CAS using Structure-aware.";
reference
"RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched
Network (CESoPSN)";
}
identity esf {
base bgp-l2-encaps-type;
description
"DS1 (ESF) Nx64kbit/s with CAS using Structure-aware.";
reference
"RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched
Network (CESoPSN)";
}
identity sf {
base bgp-l2-encaps-type;
description
"DS1 (SF) Nx64kbit/s with CAS using Structure-aware.";
reference
"RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched
Network (CESoPSN)";
}
}
<CODE ENDS>
The initial version of the "iana-pseudowire-types" YANG module matches the "MPLS Pseudowire Types Registry" [IANA-PW-TYPES].
「Iana-Pseudowire-Types」Yangモジュールの初期バージョンは、「MPLS Pseudowire Typesレジストリ」[IANA-PW-Types]と一致します。
This module references [MFA], [RFC2507], [RFC2508], [RFC3032],
[RFC3545], [RFC4448], [RFC4553], [RFC4618], [RFC4619], [RFC4717],
[RFC4842], [RFC4863], [RFC4901], [RFC5086], [RFC5087], [RFC5143],
[RFC5795], and [RFC6307].
<CODE BEGINS> file "iana-pseudowire-types@2022-09-20.yang"
module iana-pseudowire-types {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-pseudowire-types";
prefix iana-pw-types;
organization "IANA"; contact "Internet Assigned Numbers Authority
組織「IANA」;「インターネットが割り当てられた番号当局にお問い合わせください
Postal: ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 United States of America Tel: +1 310 301 5800 <mailto:iana@iana.org>"; description "This module contains a collection of IANA-maintained YANG data types that are used for referring to Pseudowire Types.
郵便：ICANN 12025ウォーターフロントドライブ、スイート300ロサンゼルス、CA 90094-2536アメリカ合衆国Tel：1 310 301 5800 <Mailto：iana@iana.org> "; description"Pseudowireタイプを参照するために使用されるタイプ。
Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2022 IETF TrustおよびCodeの著者として特定された人。全著作権所有。
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).
変更とバイナリ形式での再配布と使用は、変更の有無にかかわらず、IETF Trustの法的規定（IETFドキュメントに関する法的規定）のセクション4.Cに記載されている修正されたBSDライセンスに基づいて許可されており、ライセンス条件に従います。https://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 9291; see the RFC itself for full legal notices.";
このYangモジュールのこのバージョンは、RFC 9291の一部です。完全な法的通知については、RFC自体を参照してください。」;
revision 2022-09-20 {
description
"First revision.";
reference
"RFC RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
}
identity iana-pw-types {
description
"Base Pseudowire Layer 2 encapsulation type.";
}
identity frame-relay {
base iana-pw-types;
description
"Frame Relay DLCI (Martini Mode).";
reference
"RFC 4619: Encapsulation Methods for Transport of Frame Relay
over Multiprotocol Label Switching (MPLS)
Networks";
}
identity atm-aal5 {
base iana-pw-types;
description
"ATM AAL5 SDU VCC transport.";
reference
"RFC 4717: Encapsulation Methods for Transport of
Asynchronous Transfer Mode (ATM) over MPLS
Networks";
}
identity atm-cell {
base iana-pw-types;
description
"ATM transparent cell transport.";
reference
"RFC 4717: Encapsulation Methods for Transport of
Asynchronous Transfer Mode (ATM) over MPLS
Networks";
}
identity ethernet-tagged-mode {
base iana-pw-types;
description
"Ethernet (VLAN) Tagged Mode.";
reference
"RFC 4448: Encapsulation Methods for Transport of Ethernet
over MPLS Networks";
}
identity ethernet {
base iana-pw-types;
description
"Ethernet.";
reference
"RFC 4448: Encapsulation Methods for Transport of Ethernet
over MPLS Networks";
}
identity hdlc {
base iana-pw-types;
description
"HDLC.";
reference
"RFC 4618: Encapsulation Methods for Transport of
PPP/High-Level Data Link Control (HDLC)
over MPLS Networks";
}
identity ppp {
base iana-pw-types;
description
"PPP.";
reference
"RFC 4618: Encapsulation Methods for Transport of
PPP/High-Level Data Link Control (HDLC)
over MPLS Networks";
}
identity circuit-emulation-mpls {
base iana-pw-types;
description
"SONET/SDH Circuit Emulation Service Over MPLS Encapsulation.";
reference
"RFC 5143: Synchronous Optical Network/Synchronous Digital
Hierarchy (SONET/SDH) Circuit Emulation Service over
MPLS (CEM) Encapsulation";
}
identity atm-to-vcc {
base iana-pw-types;
description
"ATM n-to-one VCC cell transport.";
reference
"RFC 4717: Encapsulation Methods for Transport of
Asynchronous Transfer Mode (ATM) over MPLS
Networks";
}
identity atm-to-vpc {
base iana-pw-types;
description
"ATM n-to-one VPC cell transport.";
reference
"RFC 4717: Encapsulation Methods for Transport of
Asynchronous Transfer Mode (ATM) over MPLS
Networks";
}
identity layer-2-transport {
base iana-pw-types;
description
"IP Layer2 Transport.";
reference
"RFC 3032: MPLS Label Stack Encoding";
}
identity atm-one-to-one-vcc {
base iana-pw-types;
description
"ATM one-to-one VCC Cell Mode.";
reference
"RFC 4717: Encapsulation Methods for Transport of
Asynchronous Transfer Mode (ATM) over MPLS
Networks";
}
identity atm-one-to-one-vpc {
base iana-pw-types;
description
"ATM one-to-one VPC Cell Mode.";
reference
"RFC 4717: Encapsulation Methods for Transport of
Asynchronous Transfer Mode (ATM) over MPLS
Networks";
}
identity atm-aal5-vcc {
base iana-pw-types;
description
"ATM AAL5 PDU VCC transport.";
reference
"RFC 4717: Encapsulation Methods for Transport of
Asynchronous Transfer Mode (ATM) over MPLS
Networks";
}
identity fr-port-mode {
base iana-pw-types;
description
"Frame-Relay Port mode.";
reference
"RFC 4619: Encapsulation Methods for Transport of Frame Relay
over Multiprotocol Label Switching (MPLS)
Networks";
}
identity circuit-emulation-packet {
base iana-pw-types;
description
"SONET/SDH Circuit Emulation over Packet.";
reference
"RFC 4842: Synchronous Optical Network/Synchronous Digital
Hierarchy (SONET/SDH) Circuit Emulation over Packet
(CEP)";
}
identity e1 {
base iana-pw-types;
description
"Structure-agnostic E1 over Packet.";
reference
"RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
over Packet (SAToP)";
}
identity t1 {
base iana-pw-types;
description
"Structure-agnostic T1 (DS1) over Packet.";
reference
"RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
over Packet (SAToP)";
}
identity e3 {
base iana-pw-types;
description
"Structure-agnostic E3 over Packet.";
reference
"RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
over Packet (SAToP)";
}
identity t3 {
base iana-pw-types;
description
"Structure-agnostic T3 (DS3) over Packet.";
reference
"RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM)
over Packet (SAToP)";
}
identity ces-over-psn {
base iana-pw-types;
description
"CESoPSN basic mode.";
reference
"RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched
Network (CESoPSN)";
}
identity tdm-over-ip-aal1 {
base iana-pw-types;
description
"TDMoIP AAL1 Mode.";
reference
"RFC 5087: Time Division Multiplexing over IP (TDMoIP)";
}
identity ces-over-psn-cas {
base iana-pw-types;
description
"CESoPSN TDM with CAS.";
reference
"RFC 5086: Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched
Network (CESoPSN)";
}
identity tdm-over-ip-aal2 {
base iana-pw-types;
description
"TDMoIP AAL2 Mode.";
reference
"RFC 5087: Time Division Multiplexing over IP (TDMoIP)";
}
identity dlci {
base iana-pw-types;
description
"Frame Relay DLCI.";
reference
"RFC 4619: Encapsulation Methods for Transport of Frame Relay
over Multiprotocol Label Switching (MPLS)
Networks";
}
identity rohc {
base iana-pw-types;
description
"ROHC Transport Header-compressed Packets.";
reference
"RFC 5795: The RObust Header Compression (ROHC) Framework
RFC 4901: Protocol Extensions for Header Compression over
MPLS";
}
identity ecrtp {
base iana-pw-types;
description
"ECRTP Transport Header-compressed Packets.";
reference
"RFC 3545: Enhanced Compressed RTP (CRTP) for Links with High
Delay, Packet Loss and Reordering
RFC 4901: Protocol Extensions for Header Compression over
MPLS";
}
identity iphc {
base iana-pw-types;
description
"IPHC Transport Header-compressed Packets.";
reference
"RFC 2507: IP Header Compression
RFC 4901: Protocol Extensions for Header Compression over
MPLS";
}
identity crtp {
base iana-pw-types;
description
"cRTP Transport Header-compressed Packets.";
reference
"RFC 2508: Compressing IP/UDP/RTP Headers for Low-Speed Serial
Links
RFC 4901: Protocol Extensions for Header Compression over
MPLS";
}
identity atm-vp-virtual-trunk {
base iana-pw-types;
description
"ATM VP Virtual Trunk.";
reference
"MFA Forum: The Use of Virtual Trunks for ATM/MPLS
Control Plane Interworking Specification";
}
identity fc-port-mode {
base iana-pw-types;
description
"FC Port Mode.";
reference
"RFC 6307: Encapsulation Methods for Transport of
Fibre Channel Traffic over MPLS Networks";
}
identity wildcard {
base iana-pw-types;
description
"Wildcard.";
reference
"RFC 4863: Wildcard Pseudowire Type";
}
}
<CODE ENDS>
The "ietf-ethernet-segment" YANG module uses types defined in [RFC6991].
「IETF-Ethernet-Segment」Yangモジュールは、[RFC6991]で定義されたタイプを使用します。
<CODE BEGINS> file "ietf-ethernet-segment@2022-09-20.yang"
module ietf-ethernet-segment {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ethernet-segment";
prefix l2vpn-es;
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types (see Section 3)";
}
organization
"IETF OPSA (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>
Editor: Samier Barguil
<mailto:samier.barguilgiraldo.ext@telefonica.com>
Author: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com>";
description "This YANG module defines a model for Ethernet Segments.
説明 "このYangモジュールは、イーサネットセグメントのモデルを定義します。
Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2022 IETF TrustおよびCodeの著者として特定された人。全著作権所有。
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).
変更とバイナリ形式での再配布と使用は、変更の有無にかかわらず、IETF Trustの法的規定（IETFドキュメントに関する法的規定）のセクション4.Cに記載されている修正されたBSDライセンスに基づいて許可されており、ライセンス条件に従います。https://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 9291; see the RFC itself for full legal notices.";
このYangモジュールのこのバージョンは、RFC 9291の一部です。完全な法的通知については、RFC自体を参照してください。」;
revision 2022-09-20 {
description
"Initial version.";
reference
"RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
}
/* Typedefs */
typedef es-ref {
type leafref {
path "/l2vpn-es:ethernet-segments/l2vpn-es:ethernet-segment"
+ "/l2vpn-es:name";
}
description
"Defines a type for referencing an Ethernet segment in
other modules.";
}
/* Identities */
identity esi-type {
description
"T (Ethernet Segment Identifier (ESI) Type) is a 1-octet field
(most significant octet) that specifies the format of the
remaining 9 octets (ESI Value).";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 5";
}
identity esi-type-0-operator {
base esi-type;
description
"This type indicates an arbitrary 9-octet ESI value,
which is managed and configured by the operator.";
}
identity esi-type-1-lacp {
base esi-type;
description
"When the IEEE 802.1AX Link Aggregation Control Protocol (LACP)
is used between the Provider Edge (PE) and Customer Edge (CE)
devices, this ESI type indicates an auto-generated ESI value
determined from LACP.";
reference
"IEEE Std 802.1AX: Link Aggregation";
}
identity esi-type-2-bridge {
base esi-type;
description
"The ESI value is auto-generated and determined based
on the Layer 2 bridge protocol.";
}
identity esi-type-3-mac {
base esi-type;
description
"This type indicates a MAC-based ESI value that can be
auto-generated or configured by the operator.";
}
identity esi-type-4-router-id {
base esi-type;
description
"This type indicates a Router ID ESI value that can be
auto-generated or configured by the operator.";
}
identity esi-type-5-asn {
base esi-type;
description
"This type indicates an Autonomous System (AS)-based ESI value
that can be auto-generated or configured by the operator.";
}
identity df-election-methods {
description
"Base Identity Designated Forwarder (DF) election method.";
}
identity default-7432 { base df-election-methods; description "The default DF election method.
ID default-7432 {base df-election-methods;説明 "デフォルトのDF選挙方法。
The default procedure for DF election at the granularity of
<ES,VLAN> for VLAN-based service or <ES, VLAN bundle> for
VLAN-(aware) bundle service is referred to as
'service carving'.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 8.5";
}
identity highest-random-weight {
base df-election-methods;
description
"The highest random weight (HRW) method.";
reference
"RFC 8584: Framework for Ethernet VPN Designated
Forwarder Election Extensibility, Section 3";
}
identity preference {
base df-election-methods;
description
"The preference-based method. PEs are assigned with
preferences to become the DF in the Ethernet Segment (ES).
The exact preference-based algorithm (e.g., lowest-preference
algorithm or highest-preference algorithm) to use is
signaled at the control plane.";
}
identity es-redundancy-mode {
description
"Base identity for ES redundancy modes.";
}
identity single-active {
base es-redundancy-mode;
description
"Indicates Single-Active redundancy mode for a given ES.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1.1";
}
identity all-active {
base es-redundancy-mode;
description
"Indicates All-Active redundancy mode for a given ES.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1.2";
}
/* Main Ethernet Segment Container */
container ethernet-segments {
description
"Top container for the Ethernet Segment Identifier (ESI).";
list ethernet-segment {
key "name";
description
"Top list for ESIs.";
leaf name {
type string;
description
"Includes the name of the Ethernet Segment (ES) that
is used to unambiguously identify an ES.";
}
leaf esi-type {
type identityref {
base esi-type;
}
default "esi-type-0-operator";
description
"T-(ESI Type) is a 1-octet field (most significant
octet) that specifies the format of the remaining
9 octets (ESI Value).";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 5";
}
choice esi-choice {
description
"Ethernet segment choice between several types.
For ESI Type 0: The esi is directly configured by the
operator.
For ESI Type 1: The auto-mode must be used.
For ESI Type 2: The auto-mode must be used.
For ESI Type 3: The directly-assigned or auto-mode must
be used.
For ESI Type 4: The directly-assigned or auto-mode must
be used.
For ESI Type 5: The directly-assigned or auto-mode must
be used.";
case directly-assigned {
description
"Explicitly assign an ESI value.";
leaf ethernet-segment-identifier {
type yang:hex-string {
length "29";
}
description
"10-octet ESI.";
}
}
case auto-assigned {
description
"The ESI is auto-assigned.";
container esi-auto {
description
"The ESI is auto-assigned.";
choice auto-mode {
description
"Indicates the auto-assignment mode. ESI can be
automatically assigned either with or without
indicating a pool from which the ESI should be
taken.
For both cases, the server will auto-assign an
ESI value 'auto-assigned-ESI' and use that value
operationally.";
case from-pool {
leaf esi-pool-name {
type string;
description
"The auto-assignment will be made from the
pool identified by the ESI-pool-name.";
}
}
case full-auto {
leaf auto {
type empty;
description
"Indicates an ESI is fully auto-assigned.";
}
}
}
leaf auto-ethernet-segment-identifier {
type yang:hex-string {
length "29";
}
config false;
description
"The value of the auto-assigned ESI.";
}
}
}
}
leaf esi-redundancy-mode {
type identityref {
base es-redundancy-mode;
}
description
"Indicates the ES redundancy mode.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1";
}
container df-election {
description
"Top container for the DF election method properties.";
leaf df-election-method {
type identityref {
base df-election-methods;
}
default "default-7432";
description
"Specifies the DF election method.";
reference
"RFC 8584: Framework for Ethernet VPN Designated
Forwarder Election Extensibility";
}
leaf revertive {
when "derived-from-or-self(../df-election-method, "
+ "'preference')" {
description
"The revertive value is only applicable
to the preference method.";
}
type boolean;
default "true";
description
"The default behavior is that the DF election
procedure is triggered upon PE failures following
configured preference values. Such a mode is called
the 'revertive' mode. This mode may not be suitable in
some scenarios where, e.g., an operator may want to
maintain the new DF even if the former DF recovers.
Such a mode is called the 'non-revertive' mode.
The non-revertive mode can be configured by
setting 'revertive' leaf to 'false'.";
reference
"RFC 8584: Framework for Ethernet VPN Designated
Forwarder Election Extensibility,
Section 1.3.2";
}
leaf election-wait-time {
type uint32;
units "seconds";
default "3";
description
"Designated Forwarder Wait timer.";
reference
"RFC 8584: Framework for Ethernet VPN Designated
Forwarder Election Extensibility";
}
}
leaf split-horizon-filtering {
type boolean;
description
"Controls split-horizon filtering. It is enabled
when set to 'true'.
In order to achieve split-horizon filtering, every
Broadcast, Unknown Unicast, or Multicast (BUM)
packet originating from a non-DF PE is encapsulated
with an MPLS label that identifies the origin ES.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 8.3";
}
container pbb {
description
"Provider Backbone Bridging (PBB) parameters .";
reference
"IEEE 802.1ah: Provider Backbone Bridges";
leaf backbone-src-mac {
type yang:mac-address;
description
"The PEs connected to the same CE must share the
same Provider Backbone (B-MAC) address in
All-Active mode.";
reference
"RFC 7623: Provider Backbone Bridging Combined with
Ethernet VPN (PBB-EVPN), Section 6.2.1.1";
}
}
list member {
key "ne-id interface-id";
description
"Includes a list of ES members.";
leaf ne-id {
type string;
description
"An identifier of the network element where the ES
is configured within a service provider network.";
}
leaf interface-id {
type string;
description
"Identifier of a node interface.";
}
}
}
}
}
<CODE ENDS>
The "ietf-l2vpn-ntw" YANG module uses types defined in [RFC6991], [RFC9181], [RFC8294], and [IEEE802.1Qcp].
「IETF-L2VPN-NTW」Yangモジュールは、[RFC6991]、[RFC9181]、[RFC8294]、および[IEEE802.1QCP]で定義されたタイプを使用します。
<CODE BEGINS> file "ietf-l2vpn-ntw@2022-09-20.yang"
module ietf-l2vpn-ntw {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw";
prefix l2vpn-ntw;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types, Section 4";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types, Section 3";
}
import ietf-vpn-common {
prefix vpn-common;
reference
"RFC 9181: A Common YANG for Data Model for Layer 2
and Layer 3 VPNs";
}
import iana-bgp-l2-encaps {
prefix iana-bgp-l2-encaps;
reference
"RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
}
import iana-pseudowire-types {
prefix iana-pw-types;
reference
"RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
}
import ietf-ethernet-segment {
prefix l2vpn-es;
reference
"RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
}
import ietf-routing-types {
prefix rt-types;
reference
"RFC 8294: Common YANG Data Types for the Routing Area";
}
import ieee802-dot1q-types {
prefix dot1q-types;
reference
"IEEE Std 802.1Qcp: Bridges and Bridged Networks--
Amendment 30: YANG Data Model";
}
organization
"IETF OPSA (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>
Editor: Samier Barguil
<mailto:samier.barguilgiraldo.ext@telefonica.com>
Author: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com>";
description "This YANG module defines a network model for Layer 2 VPN services.
説明 "このYangモジュールは、レイヤー2 VPNサービスのネットワークモデルを定義します。
Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2022 IETF TrustおよびCodeの著者として特定された人。全著作権所有。
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).
変更とバイナリ形式での再配布と使用は、変更の有無にかかわらず、IETF Trustの法的規定（IETFドキュメントに関する法的規定）のセクション4.Cに記載されている修正されたBSDライセンスに基づいて許可されており、ライセンス条件に従います。https://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 9291; see the RFC itself for full legal notices.";
このYangモジュールのこのバージョンは、RFC 9291の一部です。完全な法的通知については、RFC自体を参照してください。」;
revision 2022-09-20 {
description
"Initial version.";
reference
"RFC 9291: A YANG Network Data Model for Layer 2 VPNs.";
}
/* Features */
feature oam-3ah {
description
"Indicates the support of OAM 802.3ah.";
reference
"IEEE Std 802.3ah: Media Access Control Parameters, Physical
Layers, and Management Parameters for
Subscriber Access Networks";
}
/* Identities */
identity evpn-service-interface-type {
description
"Base identity for EVPN service interface type.";
}
identity vlan-based-service-interface {
base evpn-service-interface-type;
description
"VLAN-based service interface.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.1";
}
identity vlan-bundle-service-interface {
base evpn-service-interface-type;
description
"VLAN bundle service interface.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.2";
}
identity vlan-aware-bundle-service-interface {
base evpn-service-interface-type;
description
"VLAN-aware bundle service interface.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.3";
}
identity mapping-type {
base vpn-common:multicast-gp-address-mapping;
description
"Identity for multicast group mapping type.";
}
identity loop-prevention-type {
description
"Identity of loop prevention.";
}
identity shut {
base loop-prevention-type;
description
"Shut protection type.";
}
identity trap {
base loop-prevention-type;
description
"Trap protection type.";
}
identity color-type {
description
"Identity of color types. A type is assigned to a service
frame to identify its QoS profile conformance.";
}
identity green {
base color-type;
description
"'green' color type. A service frame is 'green' if it is
conformant with the committed rate of the bandwidth profile.";
}
identity yellow {
base color-type;
description
"'yellow' color type. A service frame is 'yellow' if it
exceeds the committed rate but is conformant with the excess
rate of the bandwidth profile.";
}
identity red {
base color-type;
description
"'red' color type. A service frame is 'red' if it is not
conformant with both the committed and excess rates of the
bandwidth profile.";
}
identity t-ldp-pw-type {
description
"Identity for T-LDP pseudowire (PW) type.";
}
identity vpws-type {
base t-ldp-pw-type;
description
"Virtual Private Wire Service (VPWS) t-ldp-pw-type.";
reference
"RFC 4664: Framework for Layer 2 Virtual Private Networks
(L2VPNs), Section 3.3";
}
identity vpls-type {
base t-ldp-pw-type;
description
"Virtual Private LAN Service (VPLS) t-ldp-pw-type.";
reference
"RFC 4762: Virtual Private LAN Service (VPLS) Using
Label Distribution Protocol (LDP)
Signaling, Section 6.1";
}
identity hvpls {
base t-ldp-pw-type;
description
"Identity for Hierarchical Virtual Private LAN Service (H-VPLS)
t-ldp-pw-type.";
reference
"RFC 4762: Virtual Private LAN Service (VPLS) Using
Label Distribution Protocol (LDP)
Signaling, Section 10";
}
identity lacp-mode {
description
"Identity of the LACP mode.";
}
identity lacp-active { base lacp-mode; description "LACP active mode.
ID lacp-active {base lacp-mode;説明 "LACPアクティブモード。
This mode refers to the mode where auto-speed negotiation is initiated followed by an establishment of an Ethernet channel with the other end."; }
このモードとは、自動速度交渉が開始されるモードを指し、その後、反対側のイーサネットチャネルの確立が続きます。 ";}
identity lacp-passive { base lacp-mode; description "LACP passive mode.
ID lacp-passive {base lacp-mode;説明 "LACPパッシブモード。
This mode refers to the LACP mode where an endpoint does not initiate the negotiation but only responds to LACP packets initiated by the other end (e.g., full duplex or half duplex)"; }
このモードとは、エンドポイントがネゴシエーションを開始するのではなく、反対側によって開始されたLACPパケットにのみ応答するLACPモードを指します（例：フルデュプレックスまたは半分デュプレックスなど） ";}
identity pm-type {
description
"Identity for performance monitoring type.";
}
identity loss {
base pm-type;
description
"Loss measurement is the performance monitoring type.";
}
identity delay {
base pm-type;
description
"Delay measurement is the performance monitoring type.";
}
identity mac-learning-mode {
description
"Media Access Control (MAC) learning mode.";
}
identity data-plane {
base mac-learning-mode;
description
"User MAC addresses are learned through ARP broadcast.";
}
identity control-plane {
base mac-learning-mode;
description
"User MAC addresses are advertised through EVPN-BGP.";
}
identity mac-action {
description
"Base identity for a MAC action.";
}
identity drop {
base mac-action;
description
"Dropping a packet as the MAC action.";
}
identity flood {
base mac-action;
description
"Packet flooding as the MAC action.";
}
identity warning {
base mac-action;
description
"Log a warning message as the MAC action.";
}
identity precedence-type {
description
"Redundancy type. The service can be created
with primary and secondary signalization.";
}
identity primary {
base precedence-type;
description
"Identifies the main VPN network access.";
}
identity secondary {
base precedence-type;
description
"Identifies the secondary VPN network access.";
}
identity ldp-pw-type {
description
"Identity for allowed LDP-based pseudowire (PW) type.";
reference
"RFC 4762: Virtual Private LAN Service (VPLS) Using
Label Distribution Protocol (LDP)
Signaling, Section 6.1.1";
}
identity ethernet {
base ldp-pw-type;
description
"PW Ethernet type.";
}
identity ethernet-tagged {
base ldp-pw-type;
description
"PW Ethernet tagged mode type.";
}
/* Typedefs */
typedef ccm-priority-type {
type uint8 {
range "0..7";
}
description
"A 3-bit priority value to be used in the VLAN tag
if present in the transmitted frame. A larger value
indicates a higher priority.";
}
/* Groupings */
grouping cfm-802 {
description
"Grouping for 802.1ag Connectivity Fault Management (CFM)
attributes.";
reference
"IEEE Std 802.1ag: Virtual Bridged Local Area Networks
Amendment 5: Connectivity Fault Management";
leaf maid {
type string;
description
"Maintenance Association Identifier (MAID).";
}
leaf mep-id {
type uint32;
description
"Local Maintenance Entity Group End Point (MEP) ID.";
}
leaf mep-level {
type uint32;
description
"MEP level.";
}
leaf mep-up-down {
type enumeration {
enum up {
description
"MEP is up.";
}
enum down {
description
"MEP is down.";
}
}
default "up";
description
"MEP up/down.";
}
leaf remote-mep-id {
type uint32;
description
"Remote MEP ID.";
}
leaf cos-for-cfm-pdus {
type uint32;
description
"Class of Service for CFM PDUs.";
}
leaf ccm-interval {
type uint32;
units "milliseconds";
default "10000";
description
"Continuity Check Message (CCM) interval.";
}
leaf ccm-holdtime {
type uint32;
units "milliseconds";
default "35000";
description
"CCM hold time.";
}
leaf ccm-p-bits-pri {
type ccm-priority-type;
description
"The priority parameter for CCMs
transmitted by the MEP.";
}
}
grouping y-1731 {
description
"Grouping for Y-1731";
reference
"ITU-T G.8013/Y.1731: Operations, administration and
maintenance (OAM) functions and
mechanisms for Ethernet-based
networks";
list y-1731 {
key "maid";
description
"List of configured Y-1731 instances.";
leaf maid {
type string;
description
"MAID.";
}
leaf mep-id {
type uint32;
description
"Local MEP ID.";
}
leaf pm-type {
type identityref {
base pm-type;
}
default "delay";
description
"Performance monitor types.";
}
leaf remote-mep-id {
type uint32;
description
"Remote MEP ID.";
}
leaf message-period {
type uint32;
units "milliseconds";
default "10000";
description
"Defines the interval between OAM messages.";
}
leaf measurement-interval {
type uint32;
units "seconds";
description
"Specifies the measurement interval for statistics.";
}
leaf cos {
type uint32;
description
"Identifies the Class of Service.";
}
leaf loss-measurement {
type boolean;
default "false";
description
"Controls whether loss measurement is ('true') or
disabled ('false').";
}
leaf synthetic-loss-measurement {
type boolean;
default "false";
description
"Indicates whether synthetic loss measurement is
enabled ('true') or disabled ('false').";
}
container delay-measurement {
description
"Container for delay measurement.";
leaf enable-dm {
type boolean;
default "false";
description
"Controls whether delay measurement is enabled
('true') or disabled ('false').";
}
leaf two-way {
type boolean;
default "false";
description
"Whether delay measurement is two-way ('true') of one-
way ('false').";
}
}
leaf frame-size {
type uint32;
units "bytes";
description
"Indicates the frame size.";
}
leaf session-type {
type enumeration {
enum proactive {
description
"Proactive mode.";
}
enum on-demand {
description
"On-demand mode.";
}
}
default "on-demand";
description
"Specifies the session type.";
}
}
}
grouping parameters-profile {
description
"Container for per-service parameters.";
leaf local-autonomous-system {
type inet:as-number;
description
"Indicates a local AS Number (ASN).";
}
leaf svc-mtu {
type uint32;
units "bytes";
description
"Layer 2 service MTU. It is also known
as the maximum transmission unit or
maximum frame size.";
}
leaf ce-vlan-preservation {
type boolean;
description
"Preserves the CE VLAN ID from ingress to egress, i.e.,
the CE VLAN tag of the egress frame is identical to
that of the ingress frame that yielded this egress
service frame. If all-to-one bundling within a site
is enabled, then preservation applies to all ingress
service frames. If all-to-one bundling is disabled,
then preservation applies to tagged ingress service
frames having CE VLAN ID 1 through 4094.";
}
leaf ce-vlan-cos-preservation {
type boolean;
description
"CE VLAN CoS preservation. Priority Code Point (PCP) bits
in the CE VLAN tag of the egress frame are identical to
those of the ingress frame that yielded this egress
service frame.";
}
leaf control-word-negotiation {
type boolean;
description
"Controls whether control-word negotiation is enabled
(if set to true) or not (if set to false).";
reference
"RFC 8077: Pseudowire Setup and Maintenance
Using the Label Distribution Protocol (LDP),
Section 7";
}
container mac-policies {
description
"Container of MAC policies.";
container mac-addr-limit {
description
"Container of MAC address limit configuration.";
leaf limit-number {
type uint16;
description
"Maximum number of MAC addresses learned from
the customer for a single service instance.
The default value is '2' when this grouping
is used at the service level.";
}
leaf time-interval {
type uint32;
units "milliseconds";
description
"The aging time of the MAC address.
The default value is '300' when this grouping
is used at the service level.";
}
leaf action {
type identityref {
base mac-action;
}
description
"Specifies the action when the upper limit is
exceeded: drop the packet, flood the packet,
or log a warning message (without dropping
the packet).
The default value is 'warning' when this
grouping is used at the service level.";
}
}
container mac-loop-prevention {
description
"Container for MAC loop prevention.";
leaf window {
type uint32;
units "seconds";
description
"The time interval over which a MAC mobility event
is detected and checked.
The default value is '180' when this grouping
is used at the service level.";
}
leaf frequency {
type uint32;
description
"The number of times to detect MAC duplication, where
a 'duplicate MAC address' situation has occurred
within the 'window' time interval and the duplicate
MAC address has been added to a list of duplicate
MAC addresses.
The default value is '5' when this grouping is
called at the service level.";
}
leaf retry-timer {
type uint32;
units "seconds";
description
"The retry timer. When the retry timer expires,
the duplicate MAC address will be flushed from
the MAC-VRF.";
}
leaf protection-type {
type identityref {
base loop-prevention-type;
}
description
"Protection type.
The default value is 'trap' when this grouping
is used at the service level.";
}
}
}
container multicast {
if-feature "vpn-common:multicast";
description
"Multicast container.";
leaf enabled {
type boolean;
default "false";
description
"Enables multicast.";
}
container customer-tree-flavors {
description
"Type of trees used by the customer.";
leaf-list tree-flavor {
type identityref {
base vpn-common:multicast-tree-type;
}
description
"Type of multicast tree to be used.";
}
}
}
}
grouping bandwidth-parameters {
description
"A grouping for bandwidth parameters.";
leaf cir {
type uint64;
units "bps";
description
"Committed Information Rate (CIR). The maximum
number of bits that a port can receive or
send during one second over an
interface.";
}
leaf cbs {
type uint64;
units "bytes";
description
"Committed Burst Size (CBS). CBS controls the
bursty nature of the traffic. Traffic
that does not use the configured CIR
accumulates credits until the credits
reach the configured CBS.";
}
leaf eir {
type uint64;
units "bps";
description
"Excess Information Rate (EIR), i.e., excess
frame delivery allowed not subject to
a Service Level Agreement (SLA). The
traffic rate can be limited by EIR.";
}
leaf ebs {
type uint64;
units "bytes";
description
"Excess Burst Size (EBS). The bandwidth
available for burst traffic from the
EBS is subject to the amount of
bandwidth that is accumulated during
periods when traffic allocated by the
EIR policy is not used.";
}
leaf pir {
type uint64;
units "bps";
description
"Peak Information Rate (PIR), i.e., maximum
frame delivery allowed. It is equal
to or less than sum of CIR and EIR.";
}
leaf pbs {
type uint64;
units "bytes";
description
"Peak Burst Size (PBS).";
}
}
/* Main L2NM Container */
container l2vpn-ntw {
description
"Container for the L2NM.";
container vpn-profiles {
description
"Container for VPN profiles.";
uses vpn-common:vpn-profile-cfg;
}
container vpn-services {
description
"Container for L2VPN services.";
list vpn-service {
key "vpn-id";
description
"Container of a VPN service.";
uses vpn-common:vpn-description;
leaf parent-service-id {
type vpn-common:vpn-id;
description
"Pointer to the parent service that
triggered the L2NM.";
}
leaf vpn-type {
type identityref {
base vpn-common:service-type;
}
must "not(derived-from-or-self(current(), "
+ "'vpn-common:l3vpn'))" {
error-message "L3VPN is only applicable in L3NM.";
}
description
"Service type.";
}
leaf vpn-service-topology {
type identityref {
base vpn-common:vpn-topology;
}
description
"Defines service topology such as
any-to-any, hub-spoke, etc.";
}
leaf bgp-ad-enabled {
type boolean;
description
"Indicates whether BGP auto-discovery is enabled
or disabled.";
}
leaf signaling-type {
type identityref {
base vpn-common:vpn-signaling-type;
}
description
"VPN signaling type.";
}
container global-parameters-profiles {
description
"Container for a list of global parameters
profiles.";
list global-parameters-profile {
key "profile-id";
description
"List of global parameters profiles.";
leaf profile-id {
type string;
description
"The identifier of the global parameters profile.";
}
uses vpn-common:route-distinguisher;
uses vpn-common:vpn-route-targets;
uses parameters-profile;
}
}
container underlay-transport {
description
"Container for the underlay transport.";
uses vpn-common:underlay-transport;
}
uses vpn-common:service-status;
container vpn-nodes {
description
"Set of VPN nodes that are involved in the L2NM.";
list vpn-node {
key "vpn-node-id";
description
"Container of the VPN nodes.";
leaf vpn-node-id {
type vpn-common:vpn-id;
description
"Sets the identifier of the VPN node.";
}
leaf description {
type string;
description
"Textual description of a VPN node.";
}
leaf ne-id {
type string;
description
"An identifier of the network element where
the VPN node is deployed. This identifier
uniquely identifies the network element within
an administrative domain.";
}
leaf role {
type identityref {
base vpn-common:role;
}
default "vpn-common:any-to-any-role";
description
"Role of the VPN node in the VPN.";
}
leaf router-id {
type rt-types:router-id;
description
"A 32-bit number in the dotted-quad format that is
used to uniquely identify a node within an
Autonomous System (AS).";
}
container active-global-parameters-profiles {
description
"Container for a list of global parameters
profiles.";
list global-parameters-profile {
key "profile-id";
description
"List of active global parameters profiles.";
leaf profile-id {
type leafref {
path "../../../../../global-parameters-profiles"
+ "/global-parameters-profile/profile-id";
}
description
"Points to a global profile defined at the
service level.";
}
uses parameters-profile;
}
}
uses vpn-common:service-status;
container bgp-auto-discovery {
when "../../../bgp-ad-enabled = 'true'" {
description
"Only applies when BGP auto-discovery is enabled.";
}
description
"BGP is used for auto-discovery.";
choice bgp-type {
description
"Choice for the BGP type.";
case l2vpn-bgp {
description
"Container for BGP L2VPN.";
leaf vpn-id {
type vpn-common:vpn-id;
description
"VPN Identifier. This identifier serves to
unify components of a given VPN for the
sake of auto-discovery.";
reference
"RFC 6624: Layer 2 Virtual Private Networks
Using BGP for Auto-Discovery and
Signaling";
}
}
case evpn-bgp {
description
"EVPN case.";
leaf evpn-type {
type leafref {
path "../../../../vpn-type";
}
description
"EVPN type.";
}
leaf auto-rt-enable {
type boolean;
default "false";
description
"Enables/disabled RT auto-derivation based on
the ASN and Ethernet Tag ID.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN,
Section 7.10.1";
}
leaf auto-route-target {
when "../auto-rt-enable = 'true'" {
description
"Can only be used when auto-RD is enabled.";
}
type rt-types:route-target;
config false;
description
"The value of the auto-assigned RT.";
}
}
}
uses vpn-common:route-distinguisher;
uses vpn-common:vpn-route-targets;
}
container signaling-option {
description
"Container for the L2VPN signaling.";
leaf advertise-mtu {
type boolean;
description
"Controls whether MTU is advertised.";
reference
"RFC 4667: Layer 2 Virtual Private Network (L2VPN)
Extensions for Layer 2 Tunneling
Protocol (L2TP), Section 4.3";
}
leaf mtu-allow-mismatch {
type boolean;
description
"When set to true, it allows MTU mismatch.";
reference
"RFC 4667: Layer 2 Virtual Private Network (L2VPN)
Extensions for Layer 2 Tunneling
Protocol (L2TP), Section 4.3";
}
leaf signaling-type {
type leafref {
path "../../../../signaling-type";
}
description
"VPN signaling type.";
}
choice signaling-option {
description
"Choice for the signaling-option.";
case bgp {
description
"BGP is used as the signaling protocol.";
choice bgp-type {
description
"Choice for the BGP type.";
case l2vpn-bgp {
description
"Container for BGP L2VPN.";
leaf ce-range {
type uint16;
description
"Determines the number of remote CEs with
which a given CE can communicate in the
context of a VPN.";
reference
"RFC 6624: Layer 2 Virtual Private Networks
Using BGP for Auto-Discovery and
Signaling";
}
leaf pw-encapsulation-type {
type identityref {
base iana-bgp-l2-encaps:bgp-l2-encaps-type;
}
description
"PW encapsulation type.";
}
container vpls-instance {
when "derived-from-or-self(../../../../"
+ "vpn-type, 'vpn-common:vpls')" {
description
"Only applies for VPLS.";
}
description
"VPLS instance.";
leaf vpls-edge-id {
type uint16;
description
"VPLS Edge Identifier (VE ID). This is
used when the same VE ID is configured
for the PE.";
reference
"RFC 4761: Virtual Private LAN Service
(VPLS) Using BGP for Auto-
Discovery and Signaling,
Section 3.5";
}
leaf vpls-edge-id-range {
type uint16;
description
"Specifies the size of the range of
VE ID in a VPLS service. The range
controls the size of the label
block advertised in the context of
a VPLS instance.";
reference
"RFC 4761: Virtual Private LAN Service
(VPLS) Using BGP for Auto-
Discovery and Signaling";
}
}
}
case evpn-bgp {
description
"Used for EVPN.";
leaf evpn-type {
type leafref {
path "../../bgp-auto-discovery/evpn-type";
}
description
"EVPN type.";
}
leaf service-interface-type {
type identityref {
base evpn-service-interface-type;
}
description
"EVPN service interface type.";
}
container evpn-policies {
description
"Includes a set of EVPN policies such
as those related to handling MAC
addresses.";
leaf mac-learning-mode {
type identityref {
base mac-learning-mode;
}
description
"Indicates through which plane MAC
addresses are advertised.";
}
leaf ingress-replication {
type boolean;
description
"Controls whether ingress replication is
enabled ('true') or disabled
('false').";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN,
Section 8.3.1.1";
}
leaf p2mp-replication {
type boolean;
description
"Controls whether Point-to-Multipoint
(P2MP) replication is enabled ('true')
or disabled ('false')";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN,
Section 8.3.1.2";
}
container arp-proxy {
if-feature "vpn-common:ipv4";
description
"Top container for the ARP proxy.";
leaf enable {
type boolean;
default "false";
description
"Enables (when set to 'true') or
disables (when set to 'false')
the ARP proxy.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN,
Section 10";
}
leaf arp-suppression {
type boolean;
default "false";
description
"Enables (when set to 'true') or
disables (when set to 'false') ARP
suppression.";
reference
"RFC 7432: BGP MPLS-Based Ethernet
VPN";
}
leaf ip-mobility-threshold {
type uint16;
description
"It is possible for a given host (as
defined by its IP address) to move
from one ES to another. The
IP mobility threshold specifies the
number of IP mobility events
that are detected for a given IP
address within the
detection-threshold before it
is identified as a duplicate IP
address. Once the detection threshold
is reached, updates for the IP address
are suppressed.";
}
leaf duplicate-ip-detection-interval {
type uint16;
units "seconds";
description
"The time interval used in detecting a
duplicate IP address. Duplicate IP
address detection number of host moves
are allowed within this interval
period.";
}
}
container nd-proxy {
if-feature "vpn-common:ipv6";
description
"Top container for the ND proxy.";
leaf enable {
type boolean;
default "false";
description
"Enables (when set to 'true') or
disables (when set to 'false') the
ND proxy.";
reference
"RFC 7432: BGP MPLS-Based Ethernet VPN,
Section 10";
}
leaf nd-suppression {
type boolean;
default "false";
description
"Enables (when set to 'true') or
disables (when set to 'false')
Neighbor Discovery (ND) message
suppression.
ND suppression is a technique that
is used to reduce the amount of ND
packets flooding within individual
segments between hosts
connected to the same logical
switch.";
}
leaf ip-mobility-threshold {
type uint16;
description
"It is possible for a given host (as
defined by its IP address) to move
from one ES to another. The
IP mobility threshold specifies the
number of IP mobility events
that are detected for a given IP
address within the
detection-threshold before it
is identified as a duplicate IP
address.
Once the detection threshold is
reached, updates for the IP address
are suppressed.";
}
leaf duplicate-ip-detection-interval {
type uint16;
units "seconds";
description
"The time interval used in detecting a
duplicate IP address. Duplicate IP
address detection number of host moves
are allowed within this interval
period.";
}
}
leaf underlay-multicast {
type boolean;
default "false";
description
"Enables (when set to 'true') or disables
(when set to 'false') underlay
multicast.";
}
leaf flood-unknown-unicast-suppression {
type boolean;
default "false";
description
"Enables (when set to 'true') or disables
(when set to 'false') unknown flood
unicast suppression.";
}
leaf vpws-vlan-aware {
type boolean;
default "false";
description
"Enables (when set to 'true') or disables
(when set to 'false') VPWS VLAN-aware
service for the EVPN instance.";
}
container bum-management {
description
"Broadcast-unknown-unicast-multicast
management.";
leaf discard-broadcast {
type boolean;
default "false";
description
"Discards broadcast, when enabled.";
}
leaf discard-unknown-multicast {
type boolean;
default "false";
description
"Discards unknown multicast, when
enabled.";
}
leaf discard-unknown-unicast {
type boolean;
default "false";
description
"Discards unknown unicast, when
enabled.";
}
}
container pbb {
when "derived-from-or-self("
+ "../../evpn-type, 'pbb-evpn')" {
description
"Only applies for PBB EVPN.";
}
description
"PBB parameters container.";
reference
"IEEE 802.1ah: Provider Backbone
Bridges";
leaf backbone-src-mac {
type yang:mac-address;
description
"Includes Provider Backbone MAC (B-MAC)
address.";
reference
"RFC 7623: Provider Backbone Bridging
Combined with Ethernet VPN
(PBB-EVPN), Section 8.1";
}
}
}
}
}
}
container ldp-or-l2tp {
description
"Container for LDP or L2TP-signaled PWs
choice.";
leaf agi {
type rt-types:route-distinguisher;
description
"Attachment Group Identifier. Also, called
VPLS-Id.";
reference
"RFC 4667: Layer 2 Virtual Private Network
(L2VPN) Extensions for Layer 2
Tunneling Protocol (L2TP),
Section 4.3
RFC 4762: Virtual Private LAN Service (VPLS)
Using Label Distribution Protocol
(LDP) Signaling, Section 6.1.1";
}
leaf saii {
type uint32;
description
"Source Attachment Individual Identifier
(SAII).";
reference
"RFC 4667: Layer 2 Virtual Private Network
(L2VPN) Extensions for Layer 2
Tunneling Protocol (L2TP),
Section 3";
}
list remote-targets {
key "taii";
description
"List of allowed target Attachment Individual
Identifiers (AIIs) and peers.";
reference
"RFC 4667: Layer 2 Virtual Private Network
(L2VPN) Extensions for Layer 2
Tunneling Protocol (L2TP),
Section 5";
leaf taii {
type uint32;
description
"Target Attachment Individual Identifier.";
reference
"RFC 4667: Layer 2 Virtual Private Network
(L2VPN) Extensions for Layer 2
Tunneling Protocol (L2TP),
Section 3";
}
leaf peer-addr {
type inet:ip-address;
description
"Indicates the peer forwarder's IP address.";
}
}
choice ldp-or-l2tp {
description
"Choice of LDP or L2TP-signaled PWs.";
case ldp {
description
"Container for T-LDP PW configurations.";
leaf t-ldp-pw-type {
type identityref {
base t-ldp-pw-type;
}
description
"T-LDP PW type.";
}
leaf pw-type {
type identityref {
base ldp-pw-type;
}
description
"PW encapsulation type.";
reference
"RFC 4762: Virtual Private LAN Service
(VPLS) Using Label Distribution
Protocol (LDP) Signaling,
Section 6.1.1";
}
leaf pw-description {
type string;
description
"Includes a human-readable description
of the interface. This may be used when
communicating with a remote peer.";
reference
"RFC 4762: Virtual Private LAN Service
(VPLS) Using Label Distribution
Protocol (LDP) Signaling,
Section 6.1.1";
}
leaf mac-addr-withdraw {
type boolean;
description
"If set to 'true', then MAC address
withdrawal is enabled. If 'false',
then MAC address withdrawal is
disabled.";
reference
"RFC 4762: Virtual Private LAN Service
(VPLS) Using Label Distribution
Protocol (LDP) Signaling,
Section 6.2";
}
list pw-peer-list {
key "peer-addr vc-id";
description
"List of attachment circuit (AC) and PW
bindings.";
leaf peer-addr {
type inet:ip-address;
description
"Indicates the peer's IP address.";
}
leaf vc-id {
type string;
description
"VC label used to identify a PW.";
}
leaf pw-priority {
type uint32;
description
"Defines the priority for the PW.
The higher the pw-priority value, the
higher the preference of the PW will
be.";
}
}
container qinq {
when "derived-from-or-self("
+ "../t-ldp-pw-type, 'hvpls')" {
description
"Only applies when T-LDP PW type
is H-VPLS.";
}
description
"Container for QinQ.";
leaf s-tag {
type dot1q-types:vlanid;
mandatory true;
description
"S-TAG.";
}
leaf c-tag {
type dot1q-types:vlanid;
mandatory true;
description
"C-TAG.";
}
}
}
case l2tp {
description
"Container for L2TP PWs.";
leaf router-id {
type rt-types:router-id;
description
"A 32-bit number in the dotted-quad format
that is used to uniquely identify a node
within a service provider network.";
reference
"RFC 4667: Layer 2 Virtual Private Network
(L2VPN) Extensions for Layer 2
Tunneling Protocol (L2TP),
Section 4.2";
}
leaf pseudowire-type {
type identityref {
base iana-pw-types:iana-pw-types;
}
description
"Encapsulation type.";
reference
"RFC 4667: Layer 2 Virtual Private Network
(L2VPN) Extensions for Layer 2
Tunneling Protocol (L2TP),
Section 4.2";
}
}
}
}
}
}
container vpn-network-accesses {
description
"Main container for VPN network accesses.";
list vpn-network-access {
key "id";
description
"List of VPN network accesses.";
leaf id {
type vpn-common:vpn-id;
description
"Identifier of the network access.";
}
leaf description {
type string;
description
"A textual description of the VPN network
access.";
}
leaf interface-id {
type string;
description
"Refers to a physical or logical interface.";
}
leaf active-vpn-node-profile {
type leafref {
path "../../.."
+ "/active-global-parameters-profiles"
+ "/global-parameters-profile/profile-id";
}
description
"An identifier of an active VPN instance
profile.";
}
uses vpn-common:service-status;
container connection {
description
"Container for the bearer and AC.";
leaf l2-termination-point {
type string;
description
"Specifies a reference to a local Layer 2
termination point such as a Layer 2
sub-interface.";
}
leaf local-bridge-reference {
type string;
description
"Specifies a local bridge reference to
accommodate, for example, implementations
that require internal bridging.
A reference may be a local bridge domain.";
}
leaf bearer-reference {
if-feature "vpn-common:bearer-reference";
type string;
description
"This is an internal reference for the service
provider to identify the bearer associated
with this VPN.";
}
container encapsulation {
description
"Container for Layer 2 encapsulation.";
leaf encap-type {
type identityref {
base vpn-common:encapsulation-type;
}
default "vpn-common:priority-tagged";
description
"Tagged interface type. By default, the
type of the tagged interface is
'priority-tagged'.";
}
container dot1q {
when "derived-from-or-self(../encap-type, "
+ "'vpn-common:dot1q')" {
description
"Only applies when the type of the
tagged interface is 'dot1q'.";
}
description
"Tagged interface.";
leaf tag-type {
type identityref {
base vpn-common:tag-type;
}
default "vpn-common:c-vlan";
description
"Tag type. By default, the tag type is
'c-vlan'.";
}
leaf cvlan-id {
type dot1q-types:vlanid;
description
"VLAN identifier.";
}
container tag-operations {
description
"Sets the tag manipulation policy for this
VPN network access. It defines a set of
tag manipulations that allow for the
insertion, removal, or rewriting
of 802.1Q VLAN tags. These operations are
indicated for the CE-PE direction.
By default, tag operations are symmetric.
As such, the reverse tag operation is
assumed on the PE-CE direction.";
choice op-choice {
description
"Selects the tag rewriting policy for a
VPN network access.";
leaf pop {
type empty;
description
"Pop the outer tag.";
}
leaf push {
type empty;
description
"Pushes one or two tags defined by the
tag-1 and tag-2 leaves. It is
assumed that, absent any policy, the
default value of 0 will be used for
the PCP setting.";
}
leaf translate {
type empty;
description
"Translates the outer tag to one or two
tags. PCP bits are preserved.";
}
}
leaf tag-1 {
when 'not(../pop)';
type dot1q-types:vlanid;
description
"A first tag to be used for push or
translate operations. This tag will be
used as the outermost tag as a result
of the tag operation.";
}
leaf tag-1-type {
type dot1q-types:dot1q-tag-type;
default "dot1q-types:s-vlan";
description
"Specifies a specific 802.1Q tag type
of tag-1.";
}
leaf tag-2 {
when '(../translate)';
type dot1q-types:vlanid;
description
"A second tag to be used for
translation.";
}
leaf tag-2-type {
type dot1q-types:dot1q-tag-type;
default "dot1q-types:c-vlan";
description
"Specifies a specific 802.1Q tag type
of tag-2.";
}
}
}
container priority-tagged {
when "derived-from-or-self(../encap-type, "
+ "'vpn-common:priority-tagged')" {
description
"Only applies when the type of the
tagged interface is 'priority-tagged'.";
}
description
"Priority tagged container.";
leaf tag-type {
type identityref {
base vpn-common:tag-type;
}
default "vpn-common:c-vlan";
description
"Tag type. By default, the tag type is
'c-vlan'.";
}
}
container qinq {
when "derived-from-or-self(../encap-type, "
+ "'vpn-common:qinq')" {
description
"Only applies when the type of the tagged
interface is 'QinQ'.";
}
description
"Includes QinQ parameters.";
leaf tag-type {
type identityref {
base vpn-common:tag-type;
}
default "vpn-common:s-c-vlan";
description
"Tag type. By default, the tag type is
's-c-vlan'.";
}
leaf svlan-id {
type dot1q-types:vlanid;
mandatory true;
description
"S-VLAN identifier.";
}
leaf cvlan-id {
type dot1q-types:vlanid;
mandatory true;
description
"C-VLAN identifier.";
}
container tag-operations {
description
"Sets the tag manipulation policy for this
VPN network access. It defines a set of
tag manipulations that allow for the
insertion, removal, or rewriting
of 802.1Q VLAN tags. These operations are
indicated for the CE-PE direction.
By default, tag operations are symmetric.
As such, the reverse tag operation is
assumed on the PE-CE direction.";
choice op-choice {
description
"Selects the tag rewriting policy for a
VPN network access.";
leaf pop {
type uint8 {
range "1|2";
}
description
"Pops one or two tags as a function
of the indicated pop value.";
}
leaf push {
type empty;
description
"Pushes one or two tags defined by the
tag-1 and tag-2 leaves. It is
assumed that, absent any policy, the
default value of 0 will be used for
PCP setting.";
}
leaf translate {
type uint8 {
range "1|2";
}
description
"Translates one or two outer tags. PCP
bits are preserved.
The following operations are supported:
次の操作がサポートされています。
- translate 1 with tag-1 leaf is provided: only the outermost tag is translated to the value in tag-1.
- TAG-1の葉で1つの翻訳が提供されます。最も外側のタグのみがTAG-1の値に変換されます。
- translate 2 with both tag-1 and tag-2 leaves are provided: both outer and inner tags are translated to the values in tag-1 and tag-2, respectively.
- TAG-1とTAG-2の両方の葉を翻訳する2が提供されます。外側と内側の両方のタグは、それぞれTAG-1とTAG-2の値に変換されます。
- translate 2 with tag-1 leaf is
provided: the outer tag is popped
while the inner tag is translated
to the value in tag-1.";
}
}
leaf tag-1 {
when 'not(../pop)';
type dot1q-types:vlanid;
description
"A first tag to be used for push or
translate operations. This tag will be
used as the outermost tag as a result
of the tag operation.";
}
leaf tag-1-type {
type dot1q-types:dot1q-tag-type;
default "dot1q-types:s-vlan";
description
"Specifies a specific 802.1Q tag type
of tag-1.";
}
leaf tag-2 {
when 'not(../pop)';
type dot1q-types:vlanid;
description
"A second tag to be used for push or
translate operations.";
}
leaf tag-2-type {
type dot1q-types:dot1q-tag-type;
default "dot1q-types:c-vlan";
description
"Specifies a specific 802.1Q tag type
of tag-2.";
}
}
}
}
container lag-interface {
if-feature "vpn-common:lag-interface";
description
"Container of LAG interface attributes
configuration.";
leaf lag-interface-id {
type string;
description
"LAG interface identifier.";
}
container lacp {
description
"Container for LACP.";
leaf lacp-state {
type boolean;
default "false";
description
"Controls whether LACP is enabled.";
}
leaf mode {
type identityref {
base lacp-mode;
}
description
"Indicates the LACP mode.";
}
leaf speed {
type uint32;
units "mbps";
default "10";
description
"LACP speed. This low default value
is inherited from the L2SM.";
}
leaf mini-link-num {
type uint32;
description
"Defines the minimum number of links that
must be active before the aggregating
link is put into service.";
}
leaf system-id {
type yang:mac-address;
description
"Indicates the System ID used by LACP.";
}
leaf admin-key {
type uint16;
description
"Indicates the value of the key used for
the aggregate interface.";
}
leaf system-priority {
type uint16 {
range "0..65535";
}
default "32768";
description
"Indicates the LACP priority for the
system.";
}
container member-link-list {
description
"Container of Member link list.";
list member-link {
key "name";
description
"Member link.";
leaf name {
type string;
description
"Member link name.";
}
leaf speed {
type uint32;
units "mbps";
default "10";
description
"Port speed.";
}
leaf mode {
type identityref {
base vpn-common:neg-mode;
}
description
"Negotiation mode.";
}
leaf link-mtu {
type uint32;
units "bytes";
description
"Link MTU size.";
}
container oam-802.3ah-link {
if-feature "oam-3ah";
description
"Container for the OAM 802.3ah
link.";
leaf enable {
type boolean;
default "false";
description
"Indicates support of the OAM
802.3ah link.";
}
}
}
}
leaf flow-control {
type boolean;
default "false";
description
"Indicates whether flow control is
supported.";
}
leaf lldp {
type boolean;
default "false";
description
"Indicates whether the Link Layer
Discovery Protocol (LLDP) is
supported.";
}
}
container split-horizon {
description
"Configuration with Split Horizon enabled.";
leaf group-name {
type string;
description
"Group name of the Split Horizon.";
}
}
}
}
choice signaling-option {
description
"Choice for the signaling-option.";
case bgp {
description
"BGP is used as the signaling protocol.";
choice bgp-type {
description
"Choice for the BGP type.";
case l2vpn-bgp {
description
"Container for BGP L2VPN.";
leaf ce-id {
type uint16;
description
"Identifies the CE within the VPN.";
reference
"RFC 6624: Layer 2 Virtual Private
Networks Using BGP for
Auto-Discovery and
Signaling";
}
leaf remote-ce-id {
type uint16;
description
"Indicates the identifier of the remote
CE.";
}
container vpls-instance {
when "derived-from-or-self(../../../../../"
+ "vpn-type, 'vpn-common:vpls')" {
description
"Only applies for VPLS.";
}
description
"VPLS instance.";
leaf vpls-edge-id {
type uint16;
description
"VPLS Edge Identifier (VE ID).";
reference
"RFC 4761: Virtual Private LAN Service
(VPLS) Using BGP for Auto-
Discovery and Signaling,
Section 3.2.1";
}
}
}
case evpn-bgp {
description
"Used for EVPN.";
leaf df-preference {
type uint16;
default "32767";
description
"Defines a 2-octet value that indicates
the PE preference to become the DF in
the ES.
The preference value is only applicable
to the preference-based method.";
reference
"RFC 8584: Framework for Ethernet VPN
Designated Forwarder Election
Extensibility";
}
container vpws-service-instance {
when "derived-from-or-self(../../../../../"
+ "vpn-type, 'vpn-common:vpws-evpn')" {
description
"Only applies for EVPN-VPWS.";
}
description
"Local and remote VPWS Service Instance
(VSI)";
reference
"RFC 8214: Virtual Private Wire Service
Support in Ethernet VPN";
choice local-vsi-choice {
description
"Choices for assigning local VSI.";
case directly-assigned {
description
"Explicitly assign a local VSI.";
leaf local-vpws-service-instance {
type uint32 {
range "1..16777215";
}
description
"Indicates the assigned local
VSI.";
}
}
case auto-assigned {
description
"The local VSI is auto-assigned.";
container local-vsi-auto {
description
"The local VSI is auto-assigned.";
choice auto-mode {
description
"Indicates the auto-assignment
mode of local VSI. VSI can be
automatically assigned either
with or without indicating a
pool from which the VSI
should be taken.
For both cases, the server
will auto-assign a local VSI
value and use that value.";
case from-pool {
leaf vsi-pool-name {
type string;
description
"The auto-assignment will be
made from this pool.";
}
}
case full-auto {
leaf auto {
type empty;
description
"Indicates that a local VSI
is fully auto-assigned.";
}
}
}
leaf auto-local-vsi {
type uint32 {
range "1..16777215";
}
config false;
description
"The value of the auto-assigned
local VSI.";
}
}
}
}
choice remote-vsi-choice {
description
"Choice for assigning the remote VSI.";
case directly-assigned {
description
"Explicitly assign a remote VSI.";
leaf remote-vpws-service-instance {
type uint32 {
range "1..16777215";
}
description
"Indicates the value of the remote
VSI.";
}
}
case auto-assigned {
description
"The remote VSI is auto-assigned.";
container remote-vsi-auto {
description
"The remote VSI is auto-assigned.";
choice auto-mode {
description
"Indicates the auto-assignment
mode of remote VSI. VSI can be
automatically assigned either
with or without indicating a
pool from which the VSI
should be taken.
For both cases, the server
will auto-assign a remote VSI
value and use that value.";
case from-pool {
leaf vsi-pool-name {
type string;
description
"The auto-assignment will be
made from this pool.";
}
}
case full-auto {
leaf auto {
type empty;
description
"Indicates that a remote VSI
is fully auto-assigned.";
}
}
}
leaf auto-remote-vsi {
type uint32 {
range "1..16777215";
}
config false;
description
"The value of the auto-assigned
remote VSI.";
}
}
}
}
}
}
}
}
}
list group {
key "group-id";
description
"List of group-ids.";
leaf group-id {
type string;
description
"Indicates the group-id to which the network
access belongs to.";
}
leaf precedence {
type identityref {
base precedence-type;
}
description
"Defines service redundancy in transport
network.";
}
leaf ethernet-segment-identifier {
type l2vpn-es:es-ref;
description
"Reference to the ESI associated with the VPN
network access.";
}
}
container ethernet-service-oam {
description
"Container for Ethernet service OAM.";
leaf md-name {
type string;
description
"Maintenance domain name.";
}
leaf md-level {
type uint8;
description
"Maintenance domain level.";
}
container cfm-802.1-ag {
description
"Container of 802.1ag CFM configurations.";
list n2-uni-c {
key "maid";
description
"List of UNI-N to UNI-C.";
uses cfm-802;
}
list n2-uni-n {
key "maid";
description
"List of UNI-N to UNI-N.";
uses cfm-802;
}
}
uses y-1731;
}
container service {
description
"Container for service";
leaf mtu {
type uint32;
units "bytes";
description
"Layer 2 MTU; it is also known as the maximum
transmission unit or maximum frame size.";
}
container svc-pe-to-ce-bandwidth {
if-feature "vpn-common:inbound-bw";
description
"From the customer site's perspective, the
service inbound bandwidth of the connection
or download bandwidth from the service
provider to the site. Note that the L2SM uses
'input-bandwidth' to refer to the same
concept.";
list pe-to-ce-bandwidth {
key "bw-type";
description
"List for PE-to-CE bandwidth data nodes.";
leaf bw-type {
type identityref {
base vpn-common:bw-type;
}
description
"Indicates the bandwidth type.";
}
choice type {
description
"Choice based upon bandwidth type.";
case per-cos {
description
"Bandwidth per CoS.";
list cos {
key "cos-id";
description
"List of Class of Services.";
leaf cos-id {
type uint8;
description
"Identifier of the CoS, indicated by
a Differentiated Services Code Point
(DSCP) or a CE-CLAN CoS (802.1p)
value in the service frame.";
reference
"IEEE Std 802.1Q: Bridges and Bridged
Networks";
}
uses bandwidth-parameters;
}
}
case other {
description
"Other bandwidth types.";
uses bandwidth-parameters;
}
}
}
}
container svc-ce-to-pe-bandwidth {
if-feature "vpn-common:outbound-bw";
description
"From the customer site's perspective,
the service outbound bandwidth of the
connection or upload bandwidth from
the CE to the PE. Note that the L2SM uses
'output-bandwidth' to refer to the same
concept.";
list ce-to-pe-bandwidth {
key "bw-type";
description
"List for CE-to-PE bandwidth.";
leaf bw-type {
type identityref {
base vpn-common:bw-type;
}
description
"Indicates the bandwidth type.";
}
choice type {
description
"Choice based upon bandwidth type.";
case per-cos {
description
"Bandwidth per CoS.";
list cos {
key "cos-id";
description
"List of Class of Services.";
leaf cos-id {
type uint8;
description
"Identifier of the CoS, indicated by
DSCP or a CE-CLAN CoS (802.1p) value
in the service frame.";
reference
"IEEE Std 802.1Q: Bridges and Bridged
Networks";
}
uses bandwidth-parameters;
}
}
case other {
description
"Other non CoS-aware bandwidth types.";
uses bandwidth-parameters;
}
}
}
}
container qos {
if-feature "vpn-common:qos";
description
"QoS configuration.";
container qos-classification-policy {
description
"Configuration of the traffic classification
policy.";
list rule {
key "id";
ordered-by user;
description
"List of classification rules.";
leaf id {
type string;
description
"A description identifying the QoS
classification policy rule.";
}
choice match-type {
default "match-flow";
description
"Choice for classification.";
case match-flow {
container match-flow {
description
"Describes flow-matching criteria.";
leaf dscp {
type inet:dscp;
description
"DSCP value.";
}
leaf dot1q {
type uint16;
description
"802.1Q matching. It is a VLAN tag
added into a frame.";
reference
"IEEE Std 802.1Q: Bridges and
Bridged
Networks";
}
leaf pcp {
type uint8 {
range "0..7";
}
description
"Priority Code Point (PCP) value.";
}
leaf src-mac-address {
type yang:mac-address;
description
"Source MAC address.";
}
leaf dst-mac-address {
type yang:mac-address;
description
"Destination MAC address.";
}
leaf color-type {
type identityref {
base color-type;
}
description
"Color type.";
}
leaf any {
type empty;
description
"Allows all.";
}
}
}
case match-application {
leaf match-application {
type identityref {
base vpn-common:customer-application;
}
description
"Defines the application to match.";
}
}
}
leaf target-class-id {
type string;
description
"Identification of the CoS.
This identifier is internal to the
administration.";
}
}
}
container qos-profile {
description
"QoS profile configuration.";
list qos-profile {
key "profile";
description
"QoS profile.
Can be a standard or customized
profile.";
leaf profile {
type leafref {
path "/l2vpn-ntw/vpn-profiles"
+ "/valid-provider-identifiers"
+ "/qos-profile-identifier/id";
}
description
"QoS profile to be used.";
}
leaf direction {
type identityref {
base vpn-common:qos-profile-direction;
}
default "vpn-common:both";
description
"The direction to which the QoS profile
is applied.";
}
}
}
}
container mac-policies {
description
"Container for MAC-related policies.";
list access-control-list {
key "name";
description
"Container for the Access Control List
(ACL).";
leaf name {
type string;
description
"Specifies the name of the ACL.";
}
leaf-list src-mac-address {
type yang:mac-address;
description
"Specifies the source MAC address.";
}
leaf-list src-mac-address-mask {
type yang:mac-address;
description
"Specifies the source MAC address mask.";
}
leaf-list dst-mac-address {
type yang:mac-address;
description
"Specifies the destination MAC address.";
}
leaf-list dst-mac-address-mask {
type yang:mac-address;
description
"Specifies the destination MAC address
mask.";
}
leaf action {
type identityref {
base mac-action;
}
default "drop";
description
"Specifies the filtering action.";
}
leaf rate-limit {
when "derived-from-or-self(../action, "
+ "'flood')" {
description
"Rate-limit is valid only when the action
is to accept the matching frame.";
}
type decimal64 {
fraction-digits 2;
}
units "bytes per second";
description
"Specifies how to rate-limit the traffic.";
}
}
container mac-loop-prevention {
description
"Container of MAC loop prevention.";
leaf window {
type uint32;
units "seconds";
default "180";
description
"The timer when a MAC mobility event is
detected.";
}
leaf frequency {
type uint32;
default "5";
description
"The number of times to detect MAC
duplication, where a 'duplicate MAC
address' situation has occurred and
the duplicate MAC address has been
added to a list of duplicate MAC
addresses.";
}
leaf retry-timer {
type uint32;
units "seconds";
description
"The retry timer. When the retry timer
expires, the duplicate MAC address will
be flushed from the MAC-VRF.";
}
leaf protection-type {
type identityref {
base loop-prevention-type;
}
default "trap";
description
"Protection type";
}
}
container mac-addr-limit {
description
"Container of MAC-Addr limit
configurations.";
leaf limit-number {
type uint16;
default "2";
description
"Maximum number of MAC addresses learned
from the subscriber for a single service
instance.";
}
leaf time-interval {
type uint32;
units "milliseconds";
default "300";
description
"The aging time of the MAC address.";
}
leaf action {
type identityref {
base mac-action;
}
default "warning";
description
"Specifies the action when the upper limit
is exceeded: drop the packet, flood the
packet, or log a warning message (without
dropping the packet).";
}
}
}
container broadcast-unknown-unicast-multicast {
description
"Container of broadcast, unknown unicast, or
multicast configurations.";
leaf multicast-site-type {
type enumeration {
enum receiver-only {
description
"The site only has receivers.";
}
enum source-only {
description
"The site only has sources.";
}
enum source-receiver {
description
"The site has both sources and
receivers.";
}
}
default "source-receiver";
description
"Type of the multicast site.";
}
list multicast-gp-address-mapping {
key "id";
description
"List of port-to-group mappings.";
leaf id {
type uint16;
description
"Unique identifier for the mapping.";
}
leaf vlan-id {
type uint32;
mandatory true;
description
"The VLAN ID of the multicast group.";
}
leaf mac-gp-address {
type yang:mac-address;
mandatory true;
description
"The MAC address of the multicast group.";
}
leaf port-lag-number {
type uint32;
description
"The port/LAG belonging to the multicast
group.";
}
}
leaf bum-overall-rate {
type uint64;
units "bps";
description
"Overall rate for BUM.";
}
}
}
}
}
}
}
}
}
}
}
<CODE ENDS>
The YANG modules specified in this document define schemas for data that are designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].
このドキュメントで指定されたYangモジュールは、NetConf [RFC6241]やRestConf [RFC8040]などのネットワーク管理プロトコルを介してアクセスできるように設計されたデータのスキーマを定義しています。最低のネットコン層は安全な輸送層であり、実装から実装の安全な輸送は安全なシェル（SSH）[RFC6242]です。最も低いRESTCONFレイヤーはHTTPSであり、実装対象の安全な輸送はTLS [RFC8446]です。
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
ネットワーク構成アクセス制御モデル（NACM）[RFC8341]は、利用可能なすべてのNetConfまたはRestConfプロトコル操作とコンテンツの事前に設定されたサブセットに特定のNetConfまたはRestConfユーザーのアクセスを制限する手段を提供します。
There are a number of data nodes defined in the "ietf-l2vpn-ntw" and "ietf-ethernet-segment" YANG modules that are writable/creatable/ deletable (i.e., config true, which is the default). These data nodes may be considered 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. These are the subtrees and data nodes and their sensitivity/ vulnerability in the "ietf-l2vpn-ntw" and "ietf-ethernet-segment" modules:
「IETF-L2VPN-NTW」および「IETF-Ethernet-Segment」Yangモジュールで定義されている多くのデータノードがあり、writable/ creatable/ deletable（つまり、デフォルトである構成）があります。これらのデータノードは、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。適切な保護や認証なしにこれらのデータノードの操作を書き込み（編集）、操作を削除すると、ネットワーク操作にマイナスの影響を与える可能性があります。これらは、「IETF-L2VPN-NTW」および「IETF-Ethernet-Segment」モジュールにおけるサブツリーとデータノード、およびそれらの感度/脆弱性です。
'vpn-profiles': This container includes a set of sensitive data that influences how the L3VPN service is delivered. For example, an attacker who has access to these data nodes may be able to manipulate routing policies, QoS policies, or encryption properties. These data nodes are defined with "nacm:default-deny-write" tagging [RFC9181].
「VPNプロファイル」：このコンテナには、L3VPNサービスがどのように配信されるかに影響を与える機密データのセットが含まれています。たとえば、これらのデータノードにアクセスできる攻撃者は、ルーティングポリシー、QoSポリシー、または暗号化プロパティを操作できる場合があります。これらのデータノードは、「NACM：Default-Deny-Write」タグ付け[RFC9181]で定義されます。
'ethernet-segments' and 'vpn-services': An attacker who is able to access network nodes can undertake various attacks, such as deleting a running L2VPN service, interrupting all the traffic of a client. In addition, an attacker may modify the attributes of a running service (e.g., QoS, bandwidth) or an ES, leading to malfunctioning of the service and therefore to SLA violations. In addition, an attacker could attempt to create an L2VPN service, add a new network access, or intercept/redirect the traffic to a non-authorized node. In addition to using NACM to prevent authorized access, such activity can be detected by adequately monitoring and tracking network configuration changes.
「Ethernet-Segments」および「VPN-Services」：ネットワークノードにアクセスできる攻撃者は、実行中のL2VPNサービスの削除、クライアントのすべてのトラフィックの中断など、さまざまな攻撃を行うことができます。さらに、攻撃者は、ランニングサービスの属性（QoS、帯域幅など）またはESを変更し、サービスの誤動作、したがってSLA違反につながる場合があります。さらに、攻撃者はL2VPNサービスの作成、新しいネットワークアクセスの追加、または不正なノードへのトラフィックをインターセプト/リダイレクトしようとすることができます。NACMを使用して許可されたアクセスを防ぐことに加えて、そのようなアクティビティは、ネットワーク構成の変更を適切に監視および追跡することで検出できます。
Some of the readable data nodes in the "ietf-l2vpn-ntw" 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. These are the subtrees and data nodes and their sensitivity/vulnerability:
「IETF-L2VPN-NTW」Yangモジュールの読み取り可能なデータノードの一部は、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。したがって、これらのデータノードへの読み取りアクセス（get、get config、または通知を介して）を制御することが重要です。これらは、サブツリーとデータノードとその感度/脆弱性です。
'customer-name' and 'ip-connection': An attacker can retrieve privacy-related information that can be used to track a customer. Disclosing such information may be considered a violation of the customer-provider trust relationship.
「Customer-Name」および「IP-Connection」：攻撃者は、顧客を追跡するために使用できるプライバシー関連の情報を取得できます。そのような情報の開示は、顧客プロバイダーの信頼関係の違反と見なされる場合があります。
Both "iana-bgp-l2-encaps" and "iana-pseudowire-types" modules define YANG identities for encapsulation/pseudowires types. These identities are intended to be referenced by other YANG modules and by themselves do not expose any nodes that are writable or contain read-only state or RPCs.
「IANA-BGP-L2-ENCAPS」と「IANA-PSEUDOWIRE-TYPES」モジュールの両方が、カプセル化/擬似ワイヤのタイプのYang IDを定義します。これらのアイデンティティは、他のYangモジュールによって参照されることを目的としており、それ自体では、書くことができる、または読み取り専用の状態またはRPCを含むノードを公開しません。
IANA has registered the following URIs in the "ns" subregistry within the "IETF XML Registry" [RFC3688]:
IANAは、「IETF XMLレジストリ」[RFC3688]内の「NS」サブレジストリに次のURIを登録しました。
URI: urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
uri：urn：ietf：params：xml：ns：yang：iana-bgp-l2-encaps登録者の連絡先：IESG。XML：n/a;要求されたURIはXMLネームスペースです。
URI: urn:ietf:params:xml:ns:yang:iana-pseudowire-types Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
uri：urn：ietf：params：xml：ns：yang：iana-pseudowire-types登録者の連絡先：iesg。XML：n/a;要求されたURIはXMLネームスペースです。
URI: urn:ietf:params:xml:ns:yang:ietf-ethernet-segment Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
uri：urn：ietf：params：xml：ns：yang：ietf-ethernet-segment登録者の連絡先：iesg。XML：n/a;要求されたURIはXMLネームスペースです。
URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
uri：urn：ietf：params：xml：ns：yang：ietf-l2vpn-ntw登録者の連絡先：iesg。XML：n/a;要求されたURIはXMLネームスペースです。
IANA has registered the following YANG modules in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry:
IANAは、「Yangパラメーター」レジストリ内で「Yangモジュール名」サブレジストリ[RFC6020]に次のYangモジュールを登録しました。
name: iana-bgp-l2-encaps
namespace: urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps
maintained by IANA: Y
prefix: iana-bgp-l2-encaps
reference: RFC 9291
name: iana-pseudowire-types
namespace: urn:ietf:params:xml:ns:yang:iana-pseudowire-types
maintained by IANA: Y
prefix: iana-pw-types
reference: RFC 9291
name: ietf-ethernet-segment
namespace: urn:ietf:params:xml:ns:yang:ietf-ethernet-segment
maintained by IANA: N
prefix: l2vpn-es
reference: RFC 9291
name: ietf-l2vpn-ntw
namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw
maintained by IANA: N
prefix: l2vpn-ntw
reference: RFC 9291
This document defines the initial version of the IANA-maintained "iana-bgp-l2-encaps" YANG module (Section 8.1). IANA has added this note to the "YANG Module Names" registry:
このドキュメントでは、IANAが維持した「IANA-BGP-L2-ENCAPS」Yangモジュール（セクション8.1）の初期バージョンを定義します。IANAはこのメモを「Yang Module Names」レジストリに追加しました。
BGP Layer 2 encapsulation types must not be directly added to the "iana-bgp-l2-encaps" YANG module. They must instead be added to the "BGP Layer 2 Encapsulation Types" registry at [IANA-BGP-L2].
BGPレイヤー2カプセル化タイプは、「IANA-BGP-L2-ENCAPS」Yangモジュールに直接追加してはなりません。代わりに、[IANA-BGP-L2]の「BGPレイヤー2カプセル化タイプ」レジストリに追加する必要があります。
When a Layer 2 encapsulation type is added to the "BGP Layer 2 Encapsulation Types" registry, a new "identity" statement must be added to the "iana-bgp-l2-encaps" YANG module. The name of the "identity" is a lower-case version of the encapsulation name provided in the description. The "identity" statement should have the following sub-statements defined:
レイヤー2カプセル化タイプが「BGPレイヤー2カプセル化タイプ」レジストリに追加される場合、「IANA-BGP-L2-ENCAPS」Yangモジュールに新しい「ID」ステートメントを追加する必要があります。「アイデンティティ」の名前は、説明に記載されているカプセル化名の低ケースバージョンです。「ID」ステートメントには、次のサブステートメントが定義されている必要があります。
"base": Contains 'bgp-l2-encaps-type'.
「ベース」：「BGP-L2-ENCAPS-TYPE」が含まれています。
"description": Replicates the description from the registry.
「説明」：レジストリからの説明を複製します。
"reference": Replicates the reference from the registry with the title of the document added.
「参照」：レジストリからの参照を追加して、ドキュメントのタイトルを追加します。
Unassigned or reserved values are not present in the module.
モジュールには割り当てられていない値または予約値は存在しません。
When the "iana-bgp-l2-encaps" YANG module is updated, a new "revision" statement with a unique revision date must be added in front of the existing revision statements.
「IANA-BGP-L2-ENCAPS」Yangモジュールが更新される場合、既存の改訂ステートメントの前に一意の改訂日を持つ新しい「改訂」ステートメントを追加する必要があります。
IANA has added this note to [IANA-BGP-L2]:
IANAはこのメモを[IANA-BGP-L2]に追加しました：
When this registry is modified, the YANG module "iana-bgp-l2-encaps" must be updated as defined in RFC 9291.
このレジストリが変更されると、Yangモジュール「IANA-BGP-L2-ENCAPS」は、RFC 9291で定義されているように更新する必要があります。
This document defines the initial version of the IANA-maintained "iana-pseudowire-types" YANG module (Section 8.2). IANA has added this note to the "YANG Module Names" registry:
このドキュメントでは、IANAが維持した「Iana-Pseudowire-Types」Yangモジュール（セクション8.2）の初期バージョンを定義します。IANAはこのメモを「Yang Module Names」レジストリに追加しました。
MPLS pseudowire types must not be directly added to the "iana-pseudowire-types" YANG module. They must instead be added to the "MPLS Pseudowire Types" registry at [IANA-PW-TYPES].
MPLS PSEUDOWIREタイプを「Iana-Pseudowire-Types」Yangモジュールに直接追加してはなりません。代わりに、[iana-pw-types]の「mpls pseudowireタイプ」レジストリに追加する必要があります。
When a pseudowire type is added to the "iana-pseudowire-types" registry, a new "identity" statement must be added to the "iana-pseudowire-types" YANG module. The name of the "identity" is a lower-case version of the encapsulation name provided in the description. The "identity" statement should have the following sub-statements defined:
「Iana-Pseudowire-Types」レジストリに擬似型タイプが追加される場合、「Iana-Pseudowire-Types」Yangモジュールに新しい「ID」ステートメントを追加する必要があります。「アイデンティティ」の名前は、説明に記載されているカプセル化名の低ケースバージョンです。「ID」ステートメントには、次のサブステートメントが定義されている必要があります。
"base": Contains 'iana-pw-types'.
「ベース」：「IANA-PWタイプ」が含まれています。
"description": Replicates the description from the registry.
「説明」：レジストリからの説明を複製します。
"reference": Replicates the reference from the registry with the title of the document added.
「参照」：レジストリからの参照を追加して、ドキュメントのタイトルを追加します。
Unassigned or reserved values are not present in the module.
モジュールには割り当てられていない値または予約値は存在しません。
When the "iana-pseudowire-types" YANG module is updated, a new "revision" statement with a unique revision date must be added in front of the existing revision statements.
「Iana-Pseudowire-Types」Yangモジュールが更新される場合、既存の改訂ステートメントの前に一意の改訂日を持つ新しい「改訂」ステートメントを追加する必要があります。
IANA has added this note to [IANA-PW-TYPES]:
IANAはこのメモを[iana-pw-types]に追加しました。
When this registry is modified, the YANG module "iana-pseudowire-types" must be updated as defined in RFC 9291.
このレジストリが変更されると、Yangモジュール「Iana-Pseudowire-Types」は、RFC 9291で定義されているように更新する必要があります。
[IANA-BGP-L2] IANA, "BGP Layer 2 Encapsulation Types", <https://www.iana.org/assignments/bgp-parameters>.
[IANA-BGP-L2] IANA、「BGPレイヤー2カプセル化タイプ」、<https://www.iana.org/assignments/bgp-parameters>。
[IANA-PW-TYPES] IANA, "MPLS Pseudowire Types Registry", <http://www.iana.org/assignments/pwe3-parameters/>.
[iana-pw-types] iana、 "mpls pseudowireタイプレジストリ"、<http://www.iana.org/assignments/pwe3-parameters/>。
[IEEE-802-1ag] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management", DOI 10.1109/IEEESTD.2007.4431836, IEEE Std 802.1ag-2007, December 2007, <https://doi.org/10.1109/IEEESTD.2007.4431836>.
[IEEE-802-1AG] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - 仮想ブリッジ型ローカルエリアネットワーク修正5：接続障害管理」、DOI 10.1109/IEEESTD.2007.4431836、IEEE STD 802.1AG-2007、<<<<<https://doi.org/10.1109/ieeestd.2007.4431836>。
[IEEE802.1Qcp] IEEE, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks--Amendment 30: YANG Data Model", DOI 10.1109/IEEESTD.2018.8467507, IEEE Std 802.1Qcp-2018, September 2018, <https://doi.org/10.1109/IEEESTD.2018.8467507>.
[IEEE802.1QCP] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - ブリッジおよびブリッジネットワーク - 修正30：ヤンデータモデル」、DOI 10.1109/IEESTD.2018.8467507、IEEE STD 802.1QCP-2018、<https://doi.org/10.1109/ieeestd.2018.8467507>。
[ITU-T-Y-1731] ITU-T, "Operation, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks", ITU-T Recommendation G.8013/Y.1731, August 2015, <https://www.itu.int/rec/T-REC-Y.1731/en>.
[ITU-T-Y-1731] ITU-T、「イーサネットベースのネットワークの操作、管理およびメンテナンス（OAM）機能とメカニズム」、ITU-T推奨G.8013/Y.1731、2015年8月、<https：//www.itu.int/rec/t-recy.1731/en>。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、DOI 10.17487/RFC3688、2004年1月、<https://www.rfc-editor.org/info/rfc3688>
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, <https://www.rfc-editor.org/info/rfc4026>.
[RFC4026] Andersson、L。およびT. Madsen、「プロバイダープロビジョニング仮想プライベートネットワーク（VPN）用語」、RFC 4026、DOI 10.17487/RFC4026、2005年3月、<https://www.rfc-editor.org/info/RFC4026>。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, DOI 10.17487/RFC4446, April 2006, <https://www.rfc-editor.org/info/rfc4446>.
[RFC4446] Martini、L。、「Pseudowire Edge to Edge Emulation（PWE3）（PWE3）へのIANAの割り当て」、BCP 116、RFC 4446、DOI 10.17487/RFC446、2006年4月、<https://www.rfc-editor.org/info/rfc4446>。
[RFC4667] Luo, W., "Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP)", RFC 4667, DOI 10.17487/RFC4667, September 2006, <https://www.rfc-editor.org/info/rfc4667>.
[RFC4667] Luo、W。、「レイヤー2トンネルプロトコル（L2TP）のレイヤー2仮想プライベートネットワーク（L2VPN）拡張 "、RFC 4667、DOI 10.17487/RFC4667、2006年9月、<https：//ww.rfc-editor。org/info/rfc4667>。
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>.
[RFC4761] Kompella、K.、ed。and Y. Rekhter、ed。、「自動配置とシグナリングにBGPを使用した仮想プライベートLANサービス（VPLS）」、RFC 4761、DOI 10.17487/RFC4761、2007年1月、<https://www.rfc-editor.org/情報/RFC4761>。
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>.
[RFC4762] Lasserre、M.、ed。およびV. Kompella編、「ラベル分布プロトコル（LDP）シグナル伝達を使用した仮想プライベートLANサービス（VPLS）、RFC 4762、DOI 10.17487/RFC4762、2007年1月、<https://www.rfc-editor.org/情報/RFC4762>。
[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>.
[RFC6020] Bjorklund、M.、ed。、 "Yang -Yang-ネットワーク構成プロトコル（NetConf）のデータモデリング言語、RFC 6020、DOI 10.17487/RFC6020、2010年10月、<https：//www.rfc -editor。org/info/rfc6020>。
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011, <https://www.rfc-editor.org/info/rfc6074>.
[RFC6074] Rosen、E.、E.、Davie、B.、Radoaca、V。、およびW. Luo、「プロビジョニング、自動ディスコーブリー、およびレイヤー2仮想プライベートネットワーク（L2VPNS）のシグナリング」、RFC 6074、DOI 10.17487/RFC6074074074074074074074074074074074074074074074074074074074074074074074074074074074074074074074074074、2011年1月、<https://www.rfc-editor.org/info/rfc6074>。
[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>.
[RFC6241] Enns、R.、ed。、ed。、Bjorklund、M.、ed。、Schoenwaelder、J.、ed。、およびA. Bierman、ed。、「ネットワーク構成プロトコル（NetConf）」、RFC 6241、DOI 10.17487/RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.
[RFC6242] Wasserman、M。、「セキュアシェル（SSH）を介してNetConfプロトコルを使用」、RFC 6242、DOI 10.17487/RFC6242、2011年6月、<https://www.rfc-editor.org/info/rfc6242>。
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, <https://www.rfc-editor.org/info/rfc6624>.
[RFC6624] Kompella、K.、Kothari、B。、およびR. Cherukuri、「自動配置とシグナル伝達のためにBGPを使用したレイヤー2仮想プライベートネットワーク」、RFC 6624、DOI 10.17487/RFC6624、2012年5月、<https：//www.rfc-editor.org/info/rfc6624>。
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC6991] Schoenwaelder、J.、ed。、 "Common Yang Data型"、RFC 6991、DOI 10.17487/RFC6991、2013年7月、<https://www.rfc-editor.org/info/rfc6991>。
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7432] Sajassi、A.、Ed。、Aggarwal、R.、Bitar、N.、Isaac、A.、Uttaro、J.、Drake、J.、およびW. Henderickx、「BGP MPLSベースのイーサネットVPN」、RFC 7432、DOI 10.17487/RFC7432、2015年2月、<https://www.rfc-editor.org/info/rfc7432>。
[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. Henderickx, "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, September 2015, <https://www.rfc-editor.org/info/rfc7623>.
[RFC7623] Sajassi、A.、Ed。、Salam、S.、Bitar、N.、Isaac、A.、およびW. Henderickx、「プロバイダーバックボーンブリッジングとイーサネットVPN（PBB-EVPN）と組み合わせた」、RFC 7623、doi10.17487/rfc7623、2015年9月、<https://www.rfc-editor.org/info/rfc7623>。
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950] Bjorklund、M.、ed。、「Yang 1.1 Data Modeling Language」、RFC 7950、DOI 10.17487/RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。
[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>.
[RFC8040] Bierman、A.、Bjorklund、M。、およびK. Watsen、「RestConf Protocol」、RFC 8040、DOI 10.17487/RFC8040、2017年1月、<https://www.rfc-editor.org/info/rfc8040>。
[RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, <https://www.rfc-editor.org/info/rfc8077>.
[RFC8077] Martini、L.、ed。and G. Heron、ed。、「ラベル分布プロトコル（LDP）を使用した擬似ワイヤーのセットアップとメンテナンス」、STD 84、RFC 8077、DOI 10.17487/RFC8077、2017年2月、<https://www.rfc-editor.org/情報/RFC8077>。
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. Rabadan, "Virtual Private Wire Service Support in Ethernet VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, <https://www.rfc-editor.org/info/rfc8214>.
[RFC8214] Boutros、S.、Sajassi、A.、Salam、S.、Drake、J。、およびJ. Rabadan、「イーサネットVPNの仮想プライベートワイヤサービスサポート」、RFC 8214、DOI 10.17487/RFC8214、2017年8月、<https://www.rfc-editor.org/info/rfc8214>。
[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10.17487/RFC8294, December 2017, <https://www.rfc-editor.org/info/rfc8294>.
[RFC8294] Liu、X.、Qu、Y.、Lindem、A.、Hopps、C。、およびL. Berger、「ルーティングエリアの一般的なYangデータ型」、RFC 8294、DOI 10.17487/RFC8294、2017年12月、RFC8294、<https://www.rfc-editor.org/info/rfc8294>。
[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>.
[RFC8341] Bierman、A。and M. Bjorklund、「ネットワーク構成アクセス制御モデル」、STD 91、RFC 8341、DOI 10.17487/RFC8341、2018年3月、<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>.
[RFC8342] Bjorklund、M.、Schoenwaelder、J.、Shafer、P.、Watsen、K。、およびR. Wilton、「ネットワーク管理データストアアーキテクチャ（NMDA）」、RFC 8342、DOI 10.17487/RFC8342、2018年3月、<<<<<https://www.rfc-editor.org/info/rfc8342>。
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 10.17487/RFC8365, March 2018, <https://www.rfc-editor.org/info/rfc8365>.
[RFC8365] Sajassi、A.、Ed。、Drake、J.、Ed。、Bitar、N.、Shekhar、R.、Uttaro、J.、およびW. Henderickx、「Ethernet VPNを使用したネットワーク仮想化オーバーレイソリューション（EVPN））」、RFC 8365、DOI 10.17487/RFC8365、2018年3月、<https://www.rfc-editor.org/info/rfc8365>。
[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>.
[RFC8446] Rescorla、E。、「輸送層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487/RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc846>
[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>.
[RFC8466] Wen、B.、Fioccola、G.、Ed。、Xie、C。、およびL. Jalil、「レイヤー2仮想プライベートネットワーク（L2VPN）サービス提供のYangデータモデル」、RFC 8466、DOI 10.17487/RFC8466、2018年10月、<https://www.rfc-editor.org/info/rfc8466>。
[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet VPN Designated Forwarder Election Extensibility", RFC 8584, DOI 10.17487/RFC8584, April 2019, <https://www.rfc-editor.org/info/rfc8584>.
[RFC8584] Rabadan、J.、Ed。、Mohanty、S.、Ed。、Sajassi、A.、Drake、J.、Nagaraj、K。、およびS. Sathappan、「イーサネットVPN指定フォワーダー選挙の拡張性のフレームワーク」RFC 8584、DOI 10.17487/RFC8584、2019年4月、<https://www.rfc-editor.org/info/rfc8584>。
[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>.
[RFC9181] Barguil、S.、Gonzalez de Dios、O.、Ed。、Boucadair、M.、ed。、and Q. Wu、「レイヤー2およびレイヤー3 VPNSの一般的なヤンデータモデル」、RFC 9181、doi10.17487/rfc9181、2022年2月、<https://www.rfc-editor.org/info/rfc9181>。
[BGP-YANG-MODEL] Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP YANG Model for Service Provider Networks", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-model-14, 3 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-14>.
[BGP-YANG-MODEL] Jethanandani、M.、Patel、K.、Hares、S。、およびJ. Haas、「サービスプロバイダーネットワークのBGP Yangモデル」、作業中、インターネットドラフト、Draft-Itf-Idr-bgp-model-14、2022年7月3日、<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-14>。
[EVPN-PERF-DF] Rabadan, J., Ed., Sathappan, S., Lin, W., Drake, J., and A. Sajassi, "Preference-based EVPN DF Election", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-pref-df-10, 2 September 2022, <https://datatracker.ietf.org/doc/html/ draft-ietf-bess-evpn-pref-df-10>.
[EVPN-PERF-DF] Rabadan、J.、Ed。、Sathappan、S.、Lin、W.、Drake、J。、およびA. Sajassi、「優先ベースのEVPN DF選挙」、進行中の仕事、インターネット - ドラフト、ドラフト-ITETF-BESS-EVPN-PREF-DF-10、2022年9月2日、<https://datatracker.ietf.org/doc/html/ draft-ietf-bess-evpn-pref-df-10>。
[EVPN-YANG] Brissette, P., Ed., Shah, H., Ed., Chen, I., Ed., Hussain, I., Ed., Tiruveedhula, K., Ed., and J. Rabadan, Ed., "Yang Data Model for EVPN", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-yang-07, 11 March 2019, <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-yang-07>.
[Evpn-Yang] Brissette、P.、Ed。、Shah、H.、Ed。、Chen、I.、Ed。、Hussain、I.、Ed。、Tiruveedhula、K.、ed。、およびJ. Rabadan、ed。、「EVPNのYang Data Model」、Work in Progress、Internet-Draft、Draft-ITEVPN-Yang-07、2019年3月11日、<https://datatracker.ietf.org/doc/html/ドラフト-ITETF-BESS-EVPN-YANG-07>。
[IEEE-802-1ah] IEEE, "IEEE Standard for Local and metropolitan area networks -- Virtual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges", IEEE Std 801.3AH-2008, August 2008, <https://standards.ieee.org/standard/802_1ah-2008.html>.
[IEEE-802-1AH] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - 仮想ブリッジ型ローカルエリアネットワーク修正7：プロバイダーバックボーンブリッジ」、IEEE STD 801.3AH-2008、2008年8月、<https：//標準。ieee.org/standard/802_1ah-2008.html>。
[IEEE-802-3ah] IEEE, "IEEE Standard for Information technology-- Local and metropolitan area networks-- Part 3: CSMA/CD Access Method and Physical Layer Specifications Amendment: Media Access Control Parameters, Physical Layers, and Management Parameters for Subscriber Access Networks", DOI 10.1109/IEEESTD.2004.94617, IEEE Std 802.3AH-2004, September 2004, <https://doi.org/10.1109/IEEESTD.2004.94617>.
[IEEE-802-3AH] IEEE、「情報技術のIEEE標準 - ローカルおよびメトロポリタンエリアネットワーク - パート3：CSMA/CDアクセス法と物理レイヤー仕様修正：メディアアクセス制御パラメーター、物理レイヤー、および管理パラメーターのパラメーターサブスクライバーアクセスネットワーク "、DOI 10.1109/IEEESTD.2004.94617、IEEE STD 802.3AH-2004、2004年9月、<https://doi.org/10.1109/ieeestd.2004.94617>。
[IEEE802.1AX] IEEE, "IEEE Standard for Local and Metropolitan Area Networks--Link Aggregation", DOI 10.1109/IEEESTD.2020.9105034, IEEE Std 802.1AX-2020, May 2020, <https://doi.org/10.1109/IEEESTD.2020.9105034>.
[IEEE802.1AX] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - リンク集約」、DOI 10.1109/IEEESTD.2020.9105034、IEEE STD 802.1AX-2020、5月2020年、<https://doi.org/10.1109/IEEESTD.2020.9105034>。
[IEEE802.1Q] IEEE, "IEEE Standard for Local and Metropolitan Area Network--Bridges and Bridged Networks", DOI 10.1109/IEEESTD.2018.8403927, IEEE Std 802.1Q-2018, July 2018, <https://doi.org/10.1109/IEEESTD.2018.8403927>.
[IEEE802.1Q] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - ブリッジおよびブリッジネットワーク」、DOI 10.1109/IEEESTD.2018.8403927、IEEE STD 802.1Q-2018、2018年7月、<https://doi.org/10.1109/IEEESTD.2018.8403927>。
[IETF-NET-SLICES] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, "Framework for IETF Network Slices", Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slices-14, 3 August 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-14>.
[IETF-NET-SLICES] Farrel、A.、Ed。、Drake、J.、Ed。、Rokui、R.、Homma、S.、Makhijani、K.、Contreras、L。M.、およびJ. Tantsura、 "Framework forIETFネットワークスライス "、作業中の作業、インターネットドラフト、ドラフト-ITEAS-IITF-NETWORK-SLICES-14、2022年8月3日、<https://datatracker.ietf.org/doc/html/draft-ietf--TEAS-IITF-NETWORK-SLICES-14>。
[MFA] MFA Forum Technical Committee, "The Use of Virtual Trunks for ATM/MPLS Control Plane Interworking Specification", MFA Forum 9.0.0, February 2006.
[MFA] MFAフォーラム技術委員会、「ATM/MPLSコントロールプレーンインターワーキング仕様のための仮想トランクの使用」、MFAフォーラム9.0.0、2006年2月。
[PYANG] "pyang", November 2020, <https://github.com/mbj4668/pyang>.
[Pyang] "Pyang"、2020年11月、<https://github.com/mbj4668/pyang>。
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, DOI 10.17487/RFC2507, February 1999, <https://www.rfc-editor.org/info/rfc2507>.
[RFC2507] Degermark、M.、Nordgren、B。、およびS. Pink、「IPヘッダー圧縮」、RFC 2507、DOI 10.17487/RFC2507、1999年2月、<https://www.rfc-editor.org/info/RFC2507>。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, DOI 10.17487/RFC2508, February 1999, <https://www.rfc-editor.org/info/rfc2508>.
[RFC2508] Casner、S。およびV. Jacobson、「低速シリアルリンクのIP/UDP/RTPヘッダーの圧縮」、RFC 2508、DOI 10.17487/RFC2508、1999年2月、<https：//www.rfc-editor。org/info/rfc2508>。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <https://www.rfc-editor.org/info/rfc3032>.
[RFC3032] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、 "Mpls Label Stack Encoding"、rfc 3032、doi 10.17487/RFC3032、2001年1月、<https://www.rfc-editor.org/info/rfc3032>。
[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, DOI 10.17487/RFC3545, July 2003, <https://www.rfc-editor.org/info/rfc3545>.
[RFC3545] Koren、T.、Casner、S.、Geevarghese、J.、Thompson、B。、およびP. Ruddy、「高度な遅延、パケット損失、再注文を伴うリンクのための圧縮RTP（CRTP）の強化」、RFC 3545、doi 10.17487/rfc3545、2003年7月、<https://www.rfc-editor.org/info/rfc3545>。
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. Moore, "Policy Quality of Service (QoS) Information Model", RFC 3644, DOI 10.17487/RFC3644, November 2003, <https://www.rfc-editor.org/info/rfc3644>.
[RFC3644] Snir、Y.、Ramberg、Y.、Strassner、J.、Cohen、R.、およびB. Moore、「Policy of Service（QoS）情報モデル」、RFC 3644、DOI 10.17487/RFC3644、2003年11月、<https://www.rfc-editor.org/info/rfc3644>。
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, <https://www.rfc-editor.org/info/rfc4448>.
[RFC4448] Martini、L.、Ed。、Rosen、E.、El-Aawar、N。、およびG. Heron、「MPLSネットワーク上のイーサネットの輸送のためのカプセル化方法」、RFC 4448、DOI 10.17487/RFC4448、2006年4月、<https://www.rfc-editor.org/info/rfc448>。
[RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006, <https://www.rfc-editor.org/info/rfc4553>.
[RFC4553] Vainshtein、A.、ed。とYJ。Stein、ed。、「Packet（SATOP）上の構造と存在時の時刻分割多重化（TDM）」、RFC 4553、DOI 10.17487/RFC4553、2006年6月、<https://www.rfc-editor.org/info/RFC4553>。
[RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, DOI 10.17487/RFC4618, September 2006, <https://www.rfc-editor.org/info/rfc4618>.
[RFC4618] Martini、L.、Rosen、E.、Heron、G。、およびA. Malis、「MPLSネットワーク上のPPP/高レベルデータリンク制御（HDLC）の輸送のためのカプセル化方法」、RFC 4618、DOI 10.17487/RFC4618、2006年9月、<https://www.rfc-editor.org/info/rfc4618>。
[RFC4619] Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed., "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", RFC 4619, DOI 10.17487/RFC4619, September 2006, <https://www.rfc-editor.org/info/rfc4619>.
[RFC4619] Martini、L.、Ed。、Kawa、C.、Ed。、およびA. Malis、ed。、「マルチプロトコルラベルスイッチング（MPLS）ネットワークを介したフレームリレーの輸送のためのカプセル化方法」、RFC 4619、DOI 10.17487/RFC4619、2006年9月、<https://www.rfc-editor.org/info/rfc4619>。
[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>.
[RFC4664] Andersson、L.、ed。and E. Rosen、ed。、「レイヤー2仮想プライベートネットワーク（L2VPNS）のフレームワーク」、RFC 4664、DOI 10.17487/RFC4664、2006年9月、<https://www.rfc-editor.org/info/rfc464>
[RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., Brayley, J., and G. Koleyni, "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", RFC 4717, DOI 10.17487/RFC4717, December 2006, <https://www.rfc-editor.org/info/rfc4717>.
[RFC4717] Martini、L.、Jayakumar、J.、Bocci、M.、El-Aawar、N.、Brayley、J。、およびG. Koleyni、「MPLSネットワーク上の非同期転送モード（ATM）の輸送のためのカプセル化方法」"、RFC 4717、doi 10.17487/rfc4717、2006年12月、<https://www.rfc-editor.org/info/rfc4717>。
[RFC4816] Malis, A., Martini, L., Brayley, J., and T. Walsh, "Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service", RFC 4816, DOI 10.17487/RFC4816, February 2007, <https://www.rfc-editor.org/info/rfc4816>.
[RFC4816] Malis、A.、Martini、L.、Brayley、J。、およびT. Walsh、「Pseudowire Emulation Edge-to-Edge（PWE3）非同期伝達モード（ATM）透明細胞輸送サービス」、RFC 4816、doi10.17487/rfc4816、2007年2月、<https://www.rfc-editor.org/info/rfc4816>。
[RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, "Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)", RFC 4842, DOI 10.17487/RFC4842, April 2007, <https://www.rfc-editor.org/info/rfc4842>.
[RFC4842] Malis、A.、Pate、P.、Cohen、R.、Ed。、およびD. Zelig、「同期光ネットワーク/同期デジタル階層（SONET/SDH）回路エミュレーション（CEP）（CEP）（CEP）（CEP）（CEP））、RFC 4842、doi 10.17487/rfc4842、2007年4月、<https://www.rfc-editor.org/info/rfc4842>。
[RFC4863] Martini, L. and G. Swallow, "Wildcard Pseudowire Type", RFC 4863, DOI 10.17487/RFC4863, May 2007, <https://www.rfc-editor.org/info/rfc4863>.
[RFC4863] Martini、L。およびG. Swallow、「WildCard Pseudowire Type」、RFC 4863、DOI 10.17487/RFC4863、2007年5月<https://www.rfc-editor.org/info/rfc4863>
[RFC4901] Ash, J., Ed., Hand, J., Ed., and A. Malis, Ed., "Protocol Extensions for Header Compression over MPLS", RFC 4901, DOI 10.17487/RFC4901, June 2007, <https://www.rfc-editor.org/info/rfc4901>.
[RFC4901] Ash、J.、Ed。、Hand、J.、Ed。、およびA. Malis、ed。、「MPLS上のヘッダー圧縮のプロトコル拡張」、RFC 4901、DOI 10.17487/RFC4901、2007年6月、<https：//www.rfc-editor.org/info/rfc4901>。
[RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007, <https://www.rfc-editor.org/info/rfc5086>.
[RFC5086] Vainshtein、A.、Ed。、Sasson、I.、Metz、E.、Frost、T.、およびP. Pate、「構造認識時分割多重化（TDM）回路エミュレーションサービス上のパケットスイッチネットワーク（CESOPSN））」、RFC 5086、DOI 10.17487/RFC5086、2007年12月、<https://www.rfc-editor.org/info/rfc5086>。
[RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, DOI 10.17487/RFC5087, December 2007, <https://www.rfc-editor.org/info/rfc5087>.
[RFC5087] Stein、Y（J）。、Shashoua、R.、Insler、R.、およびM. Anavi、「IP（TDMOIP）を多重化する時間分割」、RFC 5087、DOI 10.17487/RFC5087、2007年12月、<https：//www.rfc-editor.org/info/rfc5087>。
[RFC5143] Malis, A., Brayley, J., Shirron, J., Martini, L., and S. Vogelsang, "Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation", RFC 5143, DOI 10.17487/RFC5143, February 2008, <https://www.rfc-editor.org/info/rfc5143>.
[RFC5143] Malis、A.、Brayley、J.、Shirron、J.、Martini、L。、およびS. Vogelsang、「同期光ネットワーク/同期デジタル階層（SONET/SDH）回路エミュレーションサービス（CEM）カプセル化"、RFC 5143、doi 10.17487/rfc5143、2008年2月、<https://www.rfc-editor.org/info/rfc5143>。
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, DOI 10.17487/RFC5795, March 2010, <https://www.rfc-editor.org/info/rfc5795>.
[RFC5795] Sandlund、K.、Pelletier、G。、およびL-e。Jonsson、「堅牢なヘッダー圧縮（ROHC）フレームワーク」、RFC 5795、DOI 10.17487/RFC5795、2010年3月、<https://www.rfc-editor.org/info/rfc5795>。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <https://www.rfc-editor.org/info/rfc5880>.
[RFC5880] Katz、D。およびD. Ward、「双方向転送検出（BFD）」、RFC 5880、DOI 10.17487/RFC5880、2010年6月、<https://www.rfc-editor.org/info/rfc5880>
[RFC6307] Black, D., Ed., Dunbar, L., Ed., Roth, M., and R. Solomon, "Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks", RFC 6307, DOI 10.17487/RFC6307, April 2012, <https://www.rfc-editor.org/info/rfc6307>.
[RFC6307] Black、D.、Ed。、Dunbar、L.、Ed。、Roth、M.、およびR. Solomon、「MPLSネットワーク上の繊維チャネルトラフィックの輸送のためのカプセル化方法」、RFC 6307、DOI 10.17487/RFC6307/RFC6307、2012年4月、<https://www.rfc-editor.org/info/rfc6307>。
[RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., Henderickx, W., and A. Isaac, "Requirements for Ethernet VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014, <https://www.rfc-editor.org/info/rfc7209>.
[RFC7209] Sajassi、A.、Aggarwal、R.、Uttaro、J.、Bitar、N.、Henderickx、W。、およびA. Isaac、「イーサネットVPN（EVPN）の要件」、RFC 7209、DOI 10.17487/RFC72099、2014年5月、<https://www.rfc-editor.org/info/rfc7209>。
[RFC7267] Martini, L., Ed., Bocci, M., Ed., and F. Balus, Ed., "Dynamic Placement of Multi-Segment Pseudowires", RFC 7267, DOI 10.17487/RFC7267, June 2014, <https://www.rfc-editor.org/info/rfc7267>.
[RFC7267] Martini、L.、Ed。、Bocci、M.、Ed。、およびF. Balus、ed。、「マルチセグメントPseudowiresのダイナミックな配置」、RFC 7267、DOI 10.17487/RFC7267、2014年6月、<HTTPS <HTTPS：//www.rfc-editor.org/info/rfc7267>。
[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10.17487/RFC7297, July 2014, <https://www.rfc-editor.org/info/rfc7297>.
[RFC7297] Boucadair、M.、Jacquenet、C。、およびN. Wang、「IP接続プロビジョニングプロファイル（CPP）」、RFC 7297、DOI 10.17487/RFC7297、2014年7月、<https：//www.rfc-editor。org/info/rfc7297>。
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.
[RFC7951] Lhotka、L。、「Yangでモデル化されたデータのJSONエンコード」、RFC 7951、DOI 10.17487/RFC7951、2016年8月、<https://www.rfc-editor.org/info/rfc7951>。
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, <https://www.rfc-editor.org/info/rfc8309>.
[RFC8309] Wu、Q.、Liu、W。、およびA. Farrel、「サービスモデルの説明」、RFC 8309、DOI 10.17487/RFC8309、2018年1月、<https://www.rfc-editor.org/info/RFC8309>。
[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>.
[RFC8340] Bjorklund、M。and L. Berger、ed。、「Yang Tree Diagrams」、BCP 215、RFC 8340、DOI 10.17487/RFC8340、2018年3月、<https://www.rfc-editor.org/info/RFC8340>。
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.
[RFC8343] Bjorklund、M。、「インターフェイス管理のためのYangデータモデル」、RFC 8343、DOI 10.17487/RFC8343、2018年3月、<https://www.rfc-editor.org/info/rfc8343>。
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8345] Clemm、A.、Medved、J.、Varga、R.、Bahadur、N.、Ananthakrishnan、H。、およびX. Liu、「ネットワークトポロジーのヤンデータモデル」、RFC 8345、DOI 10.17487/RFC8345555555555555555、2018年3月、<https://www.rfc-editor.org/info/rfc8345>。
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/info/rfc8453>.
[RFC8453] Ceccarelli、D.、ed。Y. Lee、ed。、「TEネットワークの抽象化と制御のフレームワーク（ACTN）」、RFC 8453、DOI 10.17487/RFC8453、2018年8月、<https://www.rfc-editor.org/info/rfc8453>。
[RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, "YANG Data Model for Network Access Control Lists (ACLs)", RFC 8519, DOI 10.17487/RFC8519, March 2019, <https://www.rfc-editor.org/info/rfc8519>.
[RFC8519] Jethanandani、M.、Agarwal、S.、Huang、L.、およびD. Blair、「ネットワークアクセス制御リスト（ACLS）のYangデータモデル」、RFC 8519、DOI 10.17487/RFC8519、2019年3月、<HTTPS <HTTPS：//www.rfc-editor.org/info/rfc8519>。
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, <https://www.rfc-editor.org/info/rfc8792>.
[RFC8792] Watsen、K.、Auerswald、E.、Farrel、A。、およびQ. Wu、「インターネットドラフトとRFCのコンテンツの長いラインの扱い」、RFC 8792、DOI 10.17487/RFC8792、2020年6月、<HTTPSPSP：//www.rfc-editor.org/info/rfc8792>。
[RFC8960] Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A YANG Data Model for MPLS Base", RFC 8960, DOI 10.17487/RFC8960, December 2020, <https://www.rfc-editor.org/info/rfc8960>.
[RFC8960] Saad、T.、Raza、K.、Gandhi、R.、Liu、X。、およびV. Beeram、「MPLSベースのYangデータモデル」、RFC 8960、DOI 10.17487/RFC8960、2020年12月、<<https://www.rfc-editor.org/info/rfc8960>。
[RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and L. Geng, "A Framework for Automating Service and Network Management with YANG", RFC 8969, DOI 10.17487/RFC8969, January 2021, <https://www.rfc-editor.org/info/rfc8969>.
[RFC8969] Wu、Q.、ed。、Boucadair、M.、ed。、Lopez、D.、Xie、C。、およびL. Geng、「Yangとのサービスとネットワーク管理を自動化するためのフレームワーク」、RFC 8969、doi 10.17487/rfc8969、2021年1月、<https://www.rfc-editor.org/info/rfc8969>。
[TE-SERVICE-MAPPING] Lee, Y., Ed., Dhody, D., Ed., Fioccola, G., Wu, Q., Ed., Ceccarelli, D., and J. Tantsura, "Traffic Engineering (TE) and Service Mapping YANG Data Model", Work in Progress, Internet-Draft, draft-ietf-teas-te-service-mapping-yang-11, 11 July 2022, <https://datatracker.ietf.org/doc/html/ draft-ietf-teas-te-service-mapping-yang-11>.
[TE-Service-Mapping] Lee、Y.、ed。、Dhody、D.、ed。、Fioccola、G.、Wu、Q.、ed。、Ceccarelli、D。、およびJ. Tantsura、「Traffic Engineering（」TE）およびサービスマッピングYangデータモデル」、作業中の進行中、インターネットドラフト、ドラフト-ITES-TES-Service-Mapping-Yang-11、2022年7月11日、<https://datatracker.ietf.org/doc/ html/ draft-iitf-teas-te-service-mapping-yang-ang-11>。
[VPN+-FRAMEWORK] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Framework for Enhanced Virtual Private Network (VPN+)", Work in Progress, Internet-Draft, draft-ietf-teas-enhanced-vpn-11, 19 September 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-11>.
、ドラフト-ITES-TEAS-ENHANCE-VPN-11、2022年9月19日、<https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-11>。
[YANG-SAPS] Boucadair, M., Ed., Gonzalez de Dios, O., Barguil, S., Wu, Q., and V. Lopez, "A YANG Network Model for Service Attachment Points (SAPs)", Work in Progress, Internet-Draft, draft-ietf-opsawg-sap-09, 28 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sap-09>.
[Yang-Saps] Boucadair、M.、Ed。、Ed。、Gonzalez de Dios、O.、Barguil、S.、Wu、Q.、およびV. Lopez、「サービスアタッチメントポイントのヤンネットワークモデル（SAPS）」、作業進行中、インターネットドラフト、ドラフト-ITEF-OPSAWG-SAP-09、2022年7月28日、<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sap-09>。
This section includes a non-exhaustive list of examples to illustrate the use of the L2NM.
このセクションには、L2NMの使用を説明するための例の非網羅的なリストが含まれています。
In the following subsections, only the content of the message bodies is shown using JSON notations [RFC7951].
次のサブセクションでは、JSON表記[RFC7951]を使用してメッセージ本文の内容のみが表示されます。
The examples use folding as defined in [RFC8792] for long lines.
この例では、長い線の[RFC8792]で定義されている折り畳みを使用します。
This section provides an example to illustrate how the L2NM can be used to manage BGP-based VPLS. We consider the sample VPLS service delivered using the architecture depicted in Figure 23. In accordance with [RFC4761], we assume that a full mesh is established between all PEs. The details about such full mesh are not detailed here.
このセクションでは、L2NMを使用してBGPベースのVPLSを管理する方法を説明する例を示します。図23に示すアーキテクチャを使用して配信されるサンプルVPLSサービスを検討します。[RFC4761]に従って、すべてのPEの間に完全なメッシュが確立されると仮定します。このようなフルメッシュの詳細については、ここでは詳しく説明していません。
+-----+ +--------------+ +-----+
+----+ | PE1 |===| |===| PE3 | +----+
| CE1+-------+ | | | | +-------+ CE3|
+----+ +-----+ | | +-----+ +----+
| Core |
+----+ +-----+ | | +-----+ +----+
|CE2 +-------+ | | | | +-------+ CE4|
+----+ | PE2 |===| |===| PE4 | +----+
+-----+ +--------------+ +-----+
Figure 23: An Example of VPLS
図23：VPLSの例
Figure 24 shows an example of a message body used to configure a VPLS instance using the L2NM. In this example, BGP is used for both auto-discovery and signaling. The 'signaling-type' data node is set to 'vpn-common:bgp-signaling'.
図24は、L2NMを使用してVPLSインスタンスを構成するために使用されるメッセージ本文の例を示しています。この例では、BGPは自動発見とシグナル伝達の両方に使用されます。「シグナリングタイプ」データノードは、「VPN-Common：BGP-Signaling」に設定されています。
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-l2vpn-ntw:l2vpn-ntw": {
"vpn-services": {
"vpn-service": [
{
"vpn-id": "vpls7714825356",
"vpn-description": "Sample BGP-based VPLS",
"customer-name": "customer-7714825356",
"vpn-type": "ietf-vpn-common:vpls",
"bgp-ad-enabled": true,
"signaling-type": "ietf-vpn-common:bgp-signaling",
"global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile",
"local-autonomous-system": 65535,
"svc-mtu": 1518,
"rd-suffix": 1,
"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": "198.51.100.1",
"active-global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"bgp-auto-discovery": {
"vpn-id": "1"
},
"signaling-option": {
"pw-encapsulation-type": "iana-bgp-l2-encaps:\
ethernet-tagged-mode",
"vpls-instance": {
"vpls-edge-id": 1,
"vpls-edge-id-range": 100
}
},
"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"
}
},
"connection": {
"encapsulation": {
"encap-type": "ietf-vpn-common:dot1q",
"dot1q": {
"cvlan-id": 1
}
}
}
}
]
}
},
{
"vpn-node-id": "pe2",
"ne-id": "198.51.100.2",
"active-global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"bgp-auto-discovery": {
"vpn-id": "1"
},
"signaling-option": {
"pw-encapsulation-type": "iana-bgp-l2-encaps:\
ethernet-tagged-mode",
"vpls-instance": {
"vpls-edge-id": 2,
"vpls-edge-id-range": 100
}
},
"vpn-network-accesses": {
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE2",
"active-vpn-node-profile": "simple-profile",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "ietf-vpn-common:dot1q",
"dot1q": {
"cvlan-id": 1
}
}
}
}
]
}
},
{
"vpn-node-id": "pe3",
"ne-id": "198.51.100.3",
"active-global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"bgp-auto-discovery": {
"vpn-id": "1"
},
"signaling-option": {
"pw-encapsulation-type": "iana-bgp-l2-encaps:\
ethernet-tagged-mode",
"vpls-instance": {
"vpls-edge-id": 3,
"vpls-edge-id-range": 100
}
},
"vpn-network-accesses": {
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE3",
"active-vpn-node-profile": "simple-profile",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "ietf-vpn-common:dot1q",
"dot1q": {
"cvlan-id": 1
}
}
}
}
]
}
},
{
"vpn-node-id": "pe4",
"ne-id": "198.51.100.4",
"active-global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"bgp-auto-discovery": {
"vpn-id": "1"
},
"signaling-option": {
"pw-encapsulation-type": "iana-bgp-l2-encaps:\
ethernet-tagged-mode",
"vpls-instance": {
"vpls-edge-id": 4,
"vpls-edge-id-range": 100
}
},
"vpn-network-accesses": {
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE4",
"active-vpn-node-profile": "simple-profile",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "ietf-vpn-common:dot1q",
"dot1q": {
"cvlan-id": 1
}
}
}
}
]
}
}
]
}
}
]
}
}
}
Figure 24: An Example of an L2NM Message Body to Configure a BGP-Based VPLS
図24：BGPベースのVPLを構成するL2NMメッセージ本文の例
Let's consider the simple architecture depicted in Figure 25 to offer a VPWS between CE1 and CE2. The service uses BGP for auto-discovery and LDP for signaling.
図25に描かれている単純なアーキテクチャを考えて、CE1とCE2の間のVPWを提供します。このサービスは、自動指示にBGPを使用し、シグナリングにLDPを使用します。
+-----+ +--------------+ +-----+
+----+ | PE1 |===| |===| PE2 | +----+
| CE1+-------+ | | Core | | +-------+ CE2|
+----+ +-----+ +--------------+ +-----+ +----+
site1 site2
Figure 25: An Example of VPLS
図25：VPLSの例
{
"ietf-l2vpn-ntw:l2vpn-ntw": {
"vpn-services": {
"vpn-service": [
{
"vpn-id": "vpws12345",
"vpn-description": "Sample VPWS",
"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"
}
}
}
]
}
},
{
"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": "5/1/1.1",
"interface-id": "5/1/1",
"description": "Interface to CE2",
"active-vpn-node-profile": "simple-profile",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
}
}
]
}
}
]
}
}
]
}
}
}
Figure 26: An Example of an L2NM Message Body to Configure a BGP-Based VPWS with LDP Signaling
図26：LDPシグナリングを備えたBGPベースのVPWを構成するL2NMメッセージ本文の例
This section provides an example that illustrates how the L2NM can be used to manage a VPLS with LDP signaling. The connectivity between the CE and the PE is direct using Dot1q encapsulation [IEEE802.1Q]. We consider the sample service delivered using the architecture depicted in Figure 27.
このセクションでは、L2NMを使用してLDPシグナル伝達でVPLSを管理する方法を示す例を示します。CEとPEの間の接続性は、DOT1Qカプセル化[IEEE802.1Q]を使用して直接的です。図27に示すアーキテクチャを使用して提供されるサンプルサービスを検討します。
+---------- VPLS "1543" ----------+
+-----+ +--------------+ +-----+
+----+ | PE1 |===| |===| PE2 | +----+
| CE1 +-----+"450"| | MPLS | |"451"+-------+ CE2|
+----+ +-----+ | | +-----+ +----+
| Core |
+--------------+
Figure 27: An Example of VPLS Topology
図27：VPLSトポロジの例
Figure 28 shows how the L2NM is used to instruct both PE1 and PE2 to use the targeted LDP session between them to establish the VPLS "1543" between the ends. A single VPN service is created for this purpose. Additionally, two VPN Nodes that each have corresponding VPN network access are also created.
図28は、L2NMを使用してPE1とPE2の両方に指示する方法を示しており、それらの間のターゲットLDPセッションを使用して、端するVPLS「1543」を確立します。この目的のために、単一のVPNサービスが作成されます。さらに、それぞれに対応するVPNネットワークアクセスがある2つのVPNノードも作成されます。
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-l2vpn-ntw:l2vpn-ntw": {
"vpn-services": {
"vpn-service": [
{
"vpn-id": "450",
"vpn-name": "CORPO-EXAMPLE",
"vpn-description": "SEDE_CENTRO_450",
"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",
"description": "SEDE_CENTRO_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": {
"vpn-network-access": [
{
"id": "4508671287",
"description": "VPN_450_SNA",
"interface-id": "gigabithethernet0/0/1",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"connection": {
"l2-termination-point": "550",
"encapsulation": {
"encap-type": "ietf-vpn-common:dot1q",
"dot1q": {
"tag-type": "ietf-vpn-common:c-vlan",
"cvlan-id": 550
}
}
},
"service": {
"mtu": 1550,
"svc-pe-to-ce-bandwidth": {
"pe-to-ce-bandwidth": [
{
"bw-type": "ietf-vpn-common:\
bw-per-port",
"cir": "20480000"
}
]
},
"svc-ce-to-pe-bandwidth": {
"ce-to-pe-bandwidth": [
{
"bw-type": "ietf-vpn-common:\
bw-per-port",
"cir": "20480000"
}
]
},
"qos": {
"qos-profile": {
"qos-profile": [
{
"profile": "QoS_Profile_A",
"direction": "ietf-vpn-common:both"
}
]
}
}
}
}
]
}
},
{
"vpn-node-id": "451",
"description": "SEDE_CHAPINERO_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": {
"vpn-network-access": [
{
"id": "4508671288",
"description": "VPN_450_SNA",
"interface-id": "gigabithethernet0/0/1",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"connection": {
"l2-termination-point": "550",
"encapsulation": {
"encap-type": "ietf-vpn-common:dot1q",
"dot1q": {
"tag-type": "ietf-vpn-common:c-vlan",
"cvlan-id": 550
}
}
},
"service": {
"mtu": 1550,
"svc-pe-to-ce-bandwidth": {
"pe-to-ce-bandwidth": [
{
"bw-type": "ietf-vpn-common:\
bw-per-port",
"cir": "20480000"
}
]
},
"svc-ce-to-pe-bandwidth": {
"ce-to-pe-bandwidth": [
{
"bw-type": "ietf-vpn-common:\
bw-per-port",
"cir": "20480000"
}
]
},
"qos": {
"qos-profile": {
"qos-profile": [
{
"profile": "QoS_Profile_A",
"direction": "ietf-vpn-common:both"
}
]
}
}
}
}
]
}
}
]
}
}
]
}
}
}
Figure 28: An Example of an L2NM Message Body for LDP-Based VPLS
図28：LDPベースのVPLSのL2NMメッセージ本文の例
Figure 29 depicts a sample architecture to offer VPWS-EVPN service between CE1 and CE2. Both CEs are multihomed. BGP sessions are maintained between these PEs as per [RFC8214]. In this EVPN instance, an All-Active redundancy mode is used.
図29は、CE1とCE2の間でVPWS-EVPNサービスを提供するサンプルアーキテクチャを示しています。両方のCEはマルチホームです。[RFC8214]に従って、これらのPEの間でBGPセッションが維持されます。このEVPNインスタンスでは、オールアクティブな冗長性モードが使用されます。
|<-------- EVPN Instance --------->|
| |
ESI1 V V ESI2
| +-----+ +--------------+ +-----+ |
+----+ | | PE1 |===| |===| PE3 | | +----+
| +-------+ | | | | +-------+ |
| | | +-----+ | | +-----+ | | |
| CE1| | | Core | | |CE2 |
| | | +-----+ | | +-----+ | | |
| +-------+ | | | | +-------+ |
+----+ | | PE2 |===| |===| PE4 | | +----+
^ | +-----+ +--------------+ +-----+ | ^
| ESI1 ESI2 |
|<-------------- Emulated Service ---------------->|
Figure 29: An Example of VPWS-EVPN
図29：VPWS-EVPNの例
Let's first suppose that the following ES was created (Figure 30).
まず、次のESが作成されたと仮定しましょう（図30）。
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-ethernet-segment:ethernet-segments": {
"ethernet-segment": [
{
"name": "esi1",
"ethernet-segment-identifier": "00:11:11:11:11:11:11:\
11:11:11",
"esi-redundancy-mode": "all-active"
},
{
"name": "esi2",
"ethernet-segment-identifier": "00:22:22:22:22:22:22:\
22:22:22",
"esi-redundancy-mode": "all-active"
}
]
}
}
Figure 30: An Example of an L2NM Message Body to Configure an Ethernet Segment
図30：イーサネットセグメントを構成するL2NMメッセージ本文の例
Figure 31 shows a simplified configuration to illustrate the use of the L2NM to configure a VPWS-EVPN instance.
図31は、L2NMを使用してVPWS-EVPNインスタンスを構成することを示す単純化された構成を示しています。
{
"ietf-l2vpn-ntw:l2vpn-ntw": {
"vpn-services": {
"vpn-service": [
{
"vpn-id": "vpws15432855",
"vpn-description": "Sample VPWS-EVPN",
"customer-name": "customer_15432855",
"vpn-type": "ietf-vpn-common:vpws-evpn",
"bgp-ad-enabled": true,
"signaling-type": "ietf-vpn-common:bgp-signaling",
"global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile",
"local-autonomous-system": 65535,
"rd-suffix": 1,
"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": "198.51.100.1",
"active-global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"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"
}
},
"connection": {
"encapsulation": {
"encap-type": "ietf-vpn-common:dot1q",
"dot1q": {
"cvlan-id": 1
}
}
},
"vpws-service-instance": {
"local-vpws-service-instance": 1111,
"remote-vpws-service-instance": 1112
},
"group": [
{
"group-id": "gr1",
"ethernet-segment-identifier": "esi1"
}
]
}
]
}
},
{
"vpn-node-id": "pe2",
"ne-id": "198.51.100.2",
"active-global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"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"
}
},
"connection": {
"encapsulation": {
"encap-type": "ietf-vpn-common:dot1q",
"dot1q": {
"cvlan-id": 1
}
}
},
"vpws-service-instance": {
"local-vpws-service-instance": 1111,
"remote-vpws-service-instance": 1112
},
"group": [
{
"group-id": "gr1",
"ethernet-segment-identifier": "esi1"
}
]
}
]
}
},
{
"vpn-node-id": "pe3",
"ne-id": "198.51.100.3",
"active-global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"vpn-network-accesses": {
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE2",
"active-vpn-node-profile": "simple-profile",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "ietf-vpn-common:dot1q",
"dot1q": {
"cvlan-id": 1
}
}
},
"vpws-service-instance": {
"local-vpws-service-instance": 1112,
"remote-vpws-service-instance": 1111
},
"group": [
{
"group-id": "gr1",
"ethernet-segment-identifier": "esi2"
}
]
}
]
}
},
{
"vpn-node-id": "pe4",
"ne-id": "198.51.100.4",
"active-global-parameters-profiles": {
"global-parameters-profile": [
{
"profile-id": "simple-profile"
}
]
},
"vpn-network-accesses": {
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE2",
"active-vpn-node-profile": "simple-profile",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"connection": {
"encapsulation": {
"encap-type": "ietf-vpn-common:dot1q",
"dot1q": {
"cvlan-id": 1
}
}
},
"vpws-service-instance": {
"local-vpws-service-instance": 1112,
"remote-vpws-service-instance": 1111
},
"group": [
{
"group-id": "gr1",
"ethernet-segment-identifier": "esi2"
}
]
}
]
}
}
]
}
}
]
}
}
}
Figure 31: An Example of an L2NM Message Body to Configure a VPWS-EVPN Instance
図31：VPWS-EVPNインスタンスを構成するL2NMメッセージ本文の例
This section provides an example to illustrate how the L2NM can be used to manage ESI auto-assignment. We consider the sample EVPN service delivered using the architecture depicted in Figure 32.
このセクションでは、L2NMを使用してESIの自動割り当てを管理する方法を説明する例を示します。図32に示すアーキテクチャを使用して提供されるサンプルEVPNサービスを検討します。
ES
| +-----+ +--------------+ +-----+
+----+ | | PE1 |======| |===| PE3 | +----+
| +-------+ | | | | +-------+ CE3|
| | | +-----+ | | +-----+ +----+
| CE1| | | Core |
| | | +-----+ | | +-----+ +----+
| +-------+ | | | | +-------+ CE2|
+----+ | | PE2 |======| |===| PE4 | +----+
| +-----+ +--------------+ +-----+
LACP
Figure 32: An Example of Automatic ESI Assignment
図32：自動ESI割り当ての例
Figures 33 and 34 show how the L2NM is used to instruct both PE1 and PE2 to auto-assign the ESI to identify the ES used with CE1. In this example, we suppose that LACP is enabled and that a Type 1 (T=0x01) is used as per Section 5 of [RFC7432]. Note that this example does not include all the details to configure the EVPN service but focuses only on the ESI management part.
図33および34は、L2NMを使用してPE1とPE2の両方にESIを自動割り当てるように指示する方法を示しています。この例では、LACPが有効になり、[RFC7432]のセクション5に従ってタイプ1（t = 0x01）が使用されると仮定します。この例には、EVPNサービスを構成するためのすべての詳細が含まれているわけではなく、ESI管理部品のみに焦点を当てていることに注意してください。
{
"ietf-ethernet-segment:ethernet-segments": {
"ethernet-segment": [
{
"name": "esi1",
"esi-type": "esi-type-1-lacp",
"esi-redundancy-mode": "all-active"
}
]
}
}
Figure 33: An Example of an L2NM Message Body to Auto-Assign Ethernet Segment Identifiers
図33：自動回収イーサネットセグメント識別子へのL2NMメッセージ本文の例
{
"ietf-l2vpn-ntw:l2vpn-ntw": {
"ietf-l2vpn-ntw:vpn-services": {
"vpn-service": [
{
"vpn-id": "auto-esi-lacp",
"vpn-description": "Sample to illustrate auto-ESI",
"vpn-type": "ietf-vpn-common:vpws-evpn",
"vpn-nodes": {
"vpn-node": [
{
"vpn-node-id": "pe1",
"ne-id": "198.51.100.1",
"vpn-network-accesses": {
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface to CE1",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"connection": {
"lag-interface": {
"lag-interface-id": "1",
"lacp": {
"lacp-state": true,
"system-id": "11:00:11:00:11:11",
"admin-key": 154
}
}
},
"group": [
{
"group-id": "gr1",
"ethernet-segment-identifier": "esi1"
}
]
}
]
}
},
{
"vpn-node-id": "pe2",
"ne-id": "198.51.100.2",
"vpn-network-accesses": {
"vpn-network-access": [
{
"id": "2/2/2.5",
"interface-id": "2/2/2",
"description": "Interface to CE1",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"connection": {
"lag-interface": {
"lag-interface-id": "1",
"lacp": {
"lacp-state": true,
"system-id": "11:00:11:00:11:11",
"admin-key": 154
}
}
},
"group": [
{
"group-id": "gr1",
"ethernet-segment-identifier": "esi1"
}
]
}
]
}
}
]
}
}
]
}
}
}
Figure 34: An Example of an L2NM Message Body for ESI Auto-Assignment
図34：ESIオート割り当てのためのL2NMメッセージ本文の例
The auto-assigned ESI can be retrieved using, e.g., a GET RESTCONF method. The assigned value will then be returned as shown in the 'esi-auto' data node in Figure 35.
自動割り当てされたESIは、Get RestConfメソッドなどを使用して取得できます。図35の「ESI-auto」データノードに示されているように、割り当てられた値は返されます。
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"ietf-ethernet-segment:ethernet-segments": {
"ethernet-segment": [
{
"name": "esi1",
"ethernet-segment-identifier": "esi-type-1-lacp",
"esi-auto": {
"auto-ethernet-segment-identifier": "01:11:00:11:00:11:\
11:9a:00:00"
},
"esi-redundancy-mode": "all-active"
}
]
}
}
Figure 35: An Example of an L2NM Message Body to Retrieve the Assigned ESI
図35：割り当てられたESIを取得するためのL2NMメッセージ本文の例
In reference to the example depicted in Figure 36, an L2VPN service involves two VPN network accesses to sites that belong to the same customer.
図36に示す例を参照すると、L2VPNサービスには、同じ顧客に属するサイトへの2つのVPNネットワークアクセスが含まれます。
+--------------+
|VPN-NODE |
| +--+-------+
| | NET-ACC-1| Primary
| | +------------------
| +--+-------+
| |
| +--+-------+
| | NET-ACC-2| Secondary
| | +------------------
| +--+-------+
| |
+--------------+
Figure 36: An Example of Multiple VPN Network Accesses
図36：複数のVPNネットワークアクセスの例
In order to tag one of these VPN network accesses as "primary" and the other one as "secondary", Figure 37 shows an excerpt of the corresponding L2NM configuration. In such a configuration, both accesses are bound to the same "group-id", and the "precedence" data node is set as a function of the intended role of each access (primary or secondary).
これらのVPNネットワークアクセスの1つを「プライマリ」として、もう1つを「セカンダリ」としてタグ付けするために、図37は、対応するL2NM構成の抜粋を示しています。このような構成では、両方のアクセスが同じ「グループID」にバインドされ、「優先順位」データノードは、各アクセスの意図された役割（プライマリまたはセカンダリ）の関数として設定されます。
{
"ietf-l2vpn-ntw:l2vpn-ntw": {
"vpn-services": {
"vpn-service": [
{
"vpn-id": "Sample-Service",
"vpn-nodes": {
"vpn-node": [
{
"vpn-node-id": "VPN-NODE",
"vpn-network-accesses": {
"vpn-network-access": [
{
"id": "NET-ACC-1",
"connection": {
"bearer-reference": "br1"
},
"group": [
{
"group-id": "1",
"precedence": "primary"
}
]
},
{
"id": "NET-ACC-2",
"connection": {
"bearer-reference": "br2"
},
"group": [
{
"group-id": "1",
"precedence": "secondary"
}
]
}
]
}
}
]
}
}
]
}
}
}
Figure 37: An Example of a Message Body to Associate Priority Levels with VPN Network Accesses
図37：優先レベルをVPNネットワークアクセスに関連付けるメッセージ本文の例
Acknowledgements
謝辞
During the discussions of this work, helpful comments, suggestions, and reviews were received from: Sergio Belotti, Italo Busi, Miguel Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque Gagliano, Christian Jacquenet, Kireeti Kompella, Julian Lucek, Moti Morgenstern, Tom Petch, and Erez Segev. Many thanks to them.
この作業の議論の中で、セルジオ・ベロッティ、イタロ・ブシ、ミゲル・クロス・セシリア、ジョー・クラーク、ドリアフ・ドディ、エイドリアン・ファレル、ロケ・ガグリアーノ、クリスチャン・ジャクネット、キリエティ・クンペラ、ジュリアン・ラセク、ジュリアン・ラセク、ジュリアン・ラセク、役立つコメント、提案、レビューから受け取った。モーゲンスターン、トム・ペッチ、エレス・セゲフ。彼らに感謝します。
Zhang Guiyu, Luay Jalil, Daniel King, and Jichun Ma contributed to an early draft version of this document.
Zhang Guiyu、Luay Jalil、Daniel King、およびJichun Maは、この文書の初期草案版に貢献しました。
Thanks to Yingzhen Qu and Himanshu Shah for the rtgdir reviews, Ladislav Lhotka for the yangdoctors review, Chris Lonvick for the secdir review, and Dale Worley for the gen-art review. Special thanks to Adrian Farrel for the careful Shepherd review.
RTGDIRレビューについては、Yingzhen QUとHimanshu Shah、Yangdoctors ReviewのLadislav Lhotka、Secdir ReviewのChris Lonvick、Gen-ArtレビューのDale Worleyに感謝します。慎重な羊飼いのレビューをしてくれたAdrian Farrelに感謝します。
Thanks to Robert Wilton for the careful AD review and various suggestions to enhance the model.
慎重な広告レビューとモデルを強化するためのさまざまな提案をしてくれたRobert Wiltonに感謝します。
Thanks to Roman Danyliw, Lars Eggert, Erik Kline, Francesca Palombini, Zaheduzzaman Sarker, and Éric Vyncke for the IESG review.
Roman Danyliw、Lars Eggert、Erik Kline、Francesca Palombini、Zaheduzzzaman Sarker、Eric Vynckeに感謝します。
A YANG module for Ethernet segments was first defined in the context of the EVPN device module [EVPN-YANG].
イーサネットセグメント用のYangモジュールは、EVPNデバイスモジュール[EVPN-Yang]のコンテキストで最初に定義されました。
This work is partially supported by the European Commission under Horizon 2020 Secured autonomic traffic management for a Tera of SDN flows (Teraflow) project (grant agreement number 101015857).
この作業は、SDNフローのTERA（TERAFLOW）プロジェクト（助成金契約番号101015857）のために、Horizon 2020の自律的な交通管理の下で欧州委員会によって部分的にサポートされています。
Contributors
貢献者
Victor Lopez Nokia Email: victor.lopez@nokia.com
Victor Lopez Nokiaメール：Victor.Lopez@nokia.com
Qin Wu Huawei Email: bill.wu@huawei.com
Qin Wu Huaweiメール：bill.wu@huawei.com
Raul Arco Nokia Email: raul.arco@nokia.com
Raul Arco Nokiaメール：Raul.arco@nokia.com
Authors' Addresses
著者のアドレス
Mohamed Boucadair (editor) Orange Rennes France Email: mohamed.boucadair@orange.com
Mohamed Boucadair（編集者）Orange Rennes Franceメール：mohamed.boucadair@orange.com
Oscar Gonzalez de Dios (editor) Telefonica Madrid Spain Email: oscar.gonzalezdedios@telefonica.com
オスカーゴンザレスデディオス（編集者）テレフォニカマドリードスペインメールメール：oscar.gonzalezdedios@telefonica.com
Samier Barguil Telefonica Madrid Spain Email: samier.barguilgiraldo.ext@telefonica.com
Samier Barguil Telefonica Madrid Spainメール：Samier.Barguilgiraldo.ext@telefonica.com
Luis Angel Munoz Vodafone Spain Email: luis-angel.munoz@vodafone.com
Luis Angel Munoz Vodafone Spainメール：luis-angel.munoz@vodafone.com