[要約] RFC 8299は、L3VPNサービスの提供に関するYANGデータモデルを定義しています。このRFCの目的は、L3VPNサービスの設定と管理を効率化し、ネットワークオペレーターにとってより簡単にすることです。
Internet Engineering Task Force (IETF) Q. Wu, Ed.
Request for Comments: 8299 Huawei
Obsoletes: 8049 S. Litkowski
Category: Standards Track Orange
ISSN: 2070-1721 L. Tomotaki
Verizon
K. Ogaki
KDDI Corporation
January 2018
YANG Data Model for L3VPN Service Delivery
L3VPNサービス配信のYANGデータモデル
Abstract
概要
This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.
このドキュメントでは、顧客とネットワークオペレーター間の通信、およびレイヤー3プロバイダーによってプロビジョニングされたVPNサービスの提供に使用できるYANGデータモデルを定義しています。このドキュメントは、RFC 4026、4110、および4364で説明されているBGP PEベースのVPNに限定されています。このモデルは、全体的なサービスを提供するために管理システムでインスタンス化されることを目的としています。ネットワーク要素で直接使用する構成モデルではありません。このモデルは、レイヤー3 IP VPNサービス構成コンポーネントの抽象ビューを提供します。このモデルを入力として受け取り、特定の構成モデルを使用してサービスを提供するためにさまざまなネットワーク要素を構成するのは、管理システム次第です。ネットワーク要素の設定方法は、このドキュメントの範囲外です。
This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to the YANG module and some clarifications to the text.
このドキュメントはRFC 8049を廃止しました。そのRFCの実装できないモジュールを、下位互換性のない同じ名前の新しいモジュールに置き換えます。変更は、YANGモジュールに対する一連の小さな修正と、テキストに対するいくつかの説明です。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc8299.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8299で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Requirements Language ......................................5
1.3. Tree Diagrams ..............................................5
1.4. Summary of Changes from RFC 8049 ...........................5
1.4.1. Implementation Issues with RFC 8049 .................7
1.4.2. Impact Assessment ...................................7
2. Acronyms ........................................................8
3. Definitions ....................................................10
4. Layer 3 IP VPN Service Model ...................................10
5. Service Data Model Usage .......................................11
6. Design of the Data Model .......................................12
6.1. Features and Augmentation .................................22
6.2. VPN Service Overview ......................................22
6.2.1. VPN Service Topology ...............................23
6.2.2. Cloud Access .......................................26
6.2.3. Multicast Service ..................................29
6.2.4. Extranet VPNs ......................................30
6.3. Site Overview .............................................32
6.3.1. Devices and Locations ..............................33
6.3.2. Site Network Accesses ..............................34
6.4. Site Role .................................................36
6.5. Site Belonging to Multiple VPNs ...........................37
6.5.1. Site VPN Flavor ....................................37
6.5.2. Attaching a Site to a VPN ..........................41
6.6. Deciding Where to Connect the Site ........................47
6.6.1. Constraint: Device .................................48
6.6.2. Constraint/Parameter: Site Location ................48
6.6.3. Constraint/Parameter: Access Type ..................49
6.6.4. Constraint: Access Diversity .......................50
6.6.5. Infeasible Access Placement ........................59
6.6.6. Examples of Access Placement .......................60
6.6.7. Route Distinguisher and VRF Allocation .............80
6.7. Site Network Access Availability ..........................81
6.8. Traffic Protection ........................................82
6.9. Security ..................................................83
6.9.1. Authentication .....................................83
6.9.2. Encryption .........................................84
6.10. Management ...............................................85
6.11. Routing Protocols ........................................86
6.11.1. Handling of Dual Stack ............................87
6.11.2. LAN Directly Connected to SP Network ..............88
6.11.3. LAN Directly Connected to SP Network with
Redundancy ........................................89
6.11.4. Static Routing ....................................89
6.11.5. RIP Routing .......................................89
6.11.6. OSPF Routing ......................................90
6.11.7. BGP Routing .......................................92
6.12. Service ..................................................93
6.12.1. Bandwidth .........................................94
6.12.2. MTU ...............................................94
6.12.3. QoS ...............................................94
6.12.4. Multicast ........................................103
6.13. Enhanced VPN Features ...................................104
6.13.1. Carriers' Carriers ...............................104
6.14. External ID References ..................................105
6.15. Defining NNIs ...........................................105
6.15.1. Defining an NNI with the Option A Flavor .........107
6.15.2. Defining an NNI with the Option B Flavor .........111
6.15.3. Defining an NNI with the Option C Flavor .........113
7. Service Model Usage Example ...................................114
8. Interaction with Other YANG Models ............................120
9. YANG Module ...................................................125
10. Security Considerations ......................................184
11. IANA Considerations ..........................................185
12. References ...................................................185
12.1. Normative References ....................................185
12.2. Informative References ..................................187
Acknowledgements .................................................188
Contributors .....................................................188
Authors' Addresses ...............................................188
This document defines a Layer 3 VPN service data model written in YANG. The model defines service configuration elements that can be used in communication protocols between customers and network operators. Those elements can also be used as input to automated control and configuration applications.
このドキュメントでは、YANGで記述されたレイヤ3 VPNサービスデータモデルを定義しています。このモデルは、顧客とネットワークオペレーター間の通信プロトコルで使用できるサービス構成要素を定義します。これらの要素は、自動制御および構成アプリケーションへの入力としても使用できます。
This document obsoletes [RFC8049]; it creates a new module with the same name as the module defined in [RFC8049]. The changes from [RFC8049] are listed in full in Section 1.4. They are small in scope, but include fixes to the module to make it possible to implement.
このドキュメントは廃止されました[RFC8049]。 [RFC8049]で定義されているモジュールと同じ名前の新しいモジュールを作成します。 [RFC8049]からの変更点は、セクション1.4に完全にリストされています。スコープは小さいですが、実装を可能にするモジュールの修正が含まれています。
The YANG module described in [RFC8049] cannot be implemented because of issues around the use of XPATH. These issues are explained in Section 1.4.1.
[RFC8049]で説明されているYANGモジュールは、XPATHの使用に関する問題のために実装できません。これらの問題については、セクション1.4.1で説明します。
Section 11 of [RFC7950] describes when it is permissible to reuse a module name. Section 1.4.2 provides an impact assessment in this context.
[RFC7950]のセクション11では、モジュール名の再利用がいつ許可されるかについて説明しています。セクション1.4.2は、このコンテキストにおける影響評価を提供します。
The following terms are defined in [RFC6241] and are not redefined here:
以下の用語は[RFC6241]で定義されており、ここでは再定義されません。
o client
o クライアント
o configuration data
o 設定データ
o server
o サーバ
o state data
o 状態データ
The following terms are defined in [RFC7950] and are not redefined here:
以下の用語は[RFC7950]で定義されており、ここでは再定義されません。
o augment
o 増強
o data model
o データ・モデル
o data node
o だた ので
The terminology for describing YANG data models is found in [RFC7950].
YANGデータモデルを記述するための用語は、[RFC7950]にあります。
This document presents some configuration examples using XML representation.
このドキュメントでは、XML表現を使用した構成例をいくつか紹介します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
A simplified graphical representation of the data model is presented in Section 6.
データモデルの簡略化されたグラフィック表現は、セクション6に示されています。
The meanings of the symbols in these diagrams are as follows:
これらの図の記号の意味は次のとおりです。
o Brackets "[" and "]" enclose list keys.
o 大括弧 "["と "]"はリストキーを囲みます。
o Curly braces "{" and "}" contain names of optional features that make the corresponding node conditional.
o 中括弧「{」および「}」には、対応するノードを条件付きにするオプション機能の名前が含まれています。
o Abbreviations before data node names: "rw" means configuration data (read-write), and "ro" means state data (read-only).
o データノード名の前の略語：「rw」は構成データ（読み取り/書き込み）を意味し、「ro」は状態データ（読み取り専用）を意味します。
o Symbols after data node names: "?" means an optional node, and "*" denotes a "list" or "leaf-list".
o データノード名の後の記号： "？"オプションのノードを意味し、「*」は「リスト」または「リーフリスト」を示します。
o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":").
o 括弧は選択ノードとケースノードを囲み、ケースノードもコロン（ "："）でマークされます。
o Ellipsis ("...") stands for contents of subtrees that are not shown.
o 省略記号（ "..."）は、表示されていないサブツリーのコンテンツを表します。
This document revises and obsoletes L3VPN Service Model [RFC8049], drawing on insights gained from L3VPN Service Model deployments and on feedback from the community. The major changes are as follows:
このドキュメントは、L3VPNサービスモデル[RFC8049]を改訂および廃止し、L3VPNサービスモデルの導入から得られた洞察とコミュニティからのフィードバックに基づいています。主な変更点は次のとおりです。
o Change type from 16-bit integer to string for the leaf id under "qos-classification-policy" container.
o 「qos-classification-policy」コンテナの下のリーフIDのタイプを16ビット整数から文字列に変更します。
o Stick to using ordered-by user and remove inefficiency to map service model sequence number to device model sequence number.
o ordered-byユーザーの使用に固執し、サービスモデルのシーケンス番号をデバイスモデルのシーケンス番号にマッピングするための非効率性を取り除きます。
o Remove mandating the use of deviations and add "if-feature target-sites" under the leaf-list target-sites in Section 6.12.2.1 of [RFC8049].
o [RFC8049]のセクション6.12.2.1のリーフリストターゲットサイトの下に、逸脱の使用を強制することを削除し、「if-featureターゲットサイト」を追加します。
o Change in keywords from [RFC2119] and [RFC8174] on operation of the management system in the third paragraph of Section 6.6, Section 6.6.5, and Section 7.
o セクション6.6、セクション6.6.5、およびセクション7の3番目の段落で、管理システムの運用に関する[RFC2119]および[RFC8174]からのキーワードの変更。
o Fix incomplete description statements.
o 不完全な説明文を修正します。
o Add YANG statement to check that Stateless Address Autoconfiguration (SLAAC) parameters are used only for IPv6.
o YANGステートメントを追加して、ステートレスアドレス自動構成（SLAAC）パラメーターがIPv6にのみ使用されることを確認します。
o Fix strange wording in Section 6.11.7.
o セクション6.11.7の奇妙な表現を修正します。
o Change the use of the absolute paths to the use of relative paths in the "must" statement or "path" statement for vpn-policy-id leaf node, management container, location leaf node, devices container, location case, location-reference leaf, device case, device-reference leaf to make configuration is only applicable to the current sites.
o vpn-policy-idリーフノード、管理コンテナ、ロケーションリーフノード、デバイスコンテナ、ロケーションケース、ロケーション参照リーフの「必須」ステートメントまたは「パス」ステートメントで、絶対パスの使用を相対パスの使用に変更します。 、デバイスケース、構成を行うためのデバイス参照リーフは、現在のサイトにのみ適用できます。
o Change "must" statement to "when" statement for management container device container.
o 管理コンテナデバイスコンテナの「必須」ステートメントを「いつ」ステートメントに変更します。
o Fix optional parameter issues by adding a default or description for others or make some of them mandatory.
o 他のユーザーにデフォルトまたは説明を追加するか、それらの一部を必須にすることで、オプションのパラメーターの問題を修正します。
o Define new grouping vpn-profile-cfg for all the identifiers provided by SP to the customer. The identifiers include cloud-identifier, std-qos-profile, OAM profile-name, and provider-profile for encryption.
o SPからお客様に提供されたすべての識別子に対して、新しいグループvpn-profile-cfgを定義します。識別子には、暗号化用のcloud-identifier、std-qos-profile、OAM profile-name、およびprovider-profileが含まれます。
o Add in the XPATH string representation of identityrefs and remove unqualified name. Change from YANG 1.0 Support to YANG 1.1 Support.
o identityrefsのXPATH文字列表現を追加し、非修飾名を削除します。 YANG 1.0サポートからYANG 1.1サポートに変更します。
o Remove "when" statement from leaf nat44-customer-address.
o リーフnat44-customer-addressから「when」ステートメントを削除します。
o Fixed broken example and Add mandatory element in the examples.
o 壊れた例を修正し、例に必須要素を追加しました。
o Remove redundant parameters in the cloud access.
o クラウドアクセスの冗長パラメーターを削除します。
o Specify provider address and a list of start-end addresses from provider address for DHCP case.
o DHCPの場合は、プロバイダーアドレスとプロバイダーアドレスからの開始-終了アドレスのリストを指定します。
o Add a few text to clarify what the site is in Section 6.3.
o セクション6.3でサイトが何であるかを明確にするためにいくつかのテキストを追加します。
o Add multi-filter and multiVPN per entry support for VPN policy.
o VPNポリシーのエントリごとのマルチフィルターおよびマルチVPNサポートを追加します。
o Modify description for svc-input-bandwidth leaf and svc-output-bandwidth leaf to make it consistent with the text in Section 6.12.1.
o svc-input-bandwidthリーフとsvc-output-bandwidthリーフの説明を変更して、6.12.1項のテキストと一致するようにします。
o Clarify the rational of the model in the Section 5.
o セクション5でモデルの合理性を明確にします。
o Add text to clarify the way to achieve Per-VPN QoS policy.
o VPNごとのQoSポリシーを実現する方法を明確にするテキストを追加します。
[RFC8049] made an initial attempt to define a YANG data model forL3VPN services. After it was published it was discovered that, while the YANG compiled it was broken from an implementation perspective. That is, it was impossible to build a functional implementation of the module.
[RFC8049]は、最初にL3VPNサービスのYANGデータモデルを定義しようとしました。それが公開された後、YANGがコンパイルされている間に実装の観点からそれが壊れていることが発見されました。つまり、モジュールの機能的な実装を構築することは不可能でした。
Section 1.4 provides a full list of the changes since [RFC8049]. Some of these changes remove ambiguities from the documented YANG, while other changes fix the implementation issues.
セクション1.4は、[RFC8049]以降の変更の完全なリストを提供します。これらの変更の中には、文書化されたYANGから曖昧さを取り除くものもあれば、実装の問題を修正するものもあります。
1. Several uses of 'must' expressions in the module were broken badly enough that the module was not usable in the form it was published. While some compilers and YANG checkers found no issues (most YANG tools do not attempt to parse these expressions), other tools that really understand the XPATH in the expressions refused to compile them.
1. モジュールでの「必須」式のいくつかの使用法は、モジュールが公開された形式で使用できないほどひどく壊れていました。一部のコンパイラとYANGチェッカーは問題を検出しませんでしたが（ほとんどのYANGツールはこれらの式を解析しようとしません）、式のXPATHを実際に理解する他のツールはそれらのコンパイルを拒否しました。
The changes needed to fix these expressions were small and local.
これらの表現を修正するために必要な変更は、小規模でローカルなものでした。
2. The second issue relates to how Access Control List (ACL) rules were sorted. In [RFC8049] the English language text and the text in the YANG definition contradicted each other. Furthermore, the model used classic ACL rule numbering notation for something that was semantically very different (ordered-by user) in the YANG thus creating the potential for misunderstanding.
2. 2番目の問題は、アクセス制御リスト（ACL）ルールの並べ替え方法に関するものです。 [RFC8049]では、英語のテキストとYANG定義のテキストは互いに矛盾していました。さらに、このモデルでは、YANGで意味的に非常に異なる（ユーザーによる順序付け）ものに対して、古典的なACLルールの番号付け表記を使用していたため、誤解が生じる可能性がありました。
3. Further to point 2, the ACL modeling in [RFC8049] was incompatible with work going on in other IETF documents such as [ACL-YANG].
3. さらにポイント2に、[RFC8049]のACLモデリングは、[ACL-YANG]などの他のIETFドキュメントで行われている作業と互換性がありませんでした。
When changing the content of a YANG module, care must be taken to ensure that there are no interoperability issues caused by a failure to enable backward compatibility.
YANGモジュールのコンテンツを変更するときは、下位互換性を有効にできなかったことによる相互運用性の問題がないことを確認する必要があります。
Section 11 of [RFC7950] clearly describes the circumstances under which it is not acceptable to maintain a module name.
[RFC7950]のセクション11は、モジュール名を維持することが受け入れられない状況を明確に説明しています。
...changes to published modules are not allowed if they have any potential to cause interoperability problems between a client using an original specification and a server using an updated specification.
...元の仕様を使用するクライアントと更新された仕様を使用するサーバーの間で相互運用性の問題を引き起こす可能性がある場合、公開されたモジュールへの変更は許可されません。
The module defined in this document is not backward compatible with that defined in [RFC8049], but it is important to understand that there is no possibility of an interoperability issue between the module defined in this document and that presented in [RFC8049] because that module could not be implemented for the reasons described in Section 1.4.1. Thus, noting the rules set out in [RFC7950], it was decided to retain the module name in this document.
このドキュメントで定義されているモジュールは、[RFC8049]で定義されているものとの下位互換性はありませんが、このドキュメントで定義されているモジュールと[RFC8049]で提示されているモジュールの間に相互運用性の問題が発生する可能性がないことを理解することが重要です。セクション1.4.1で説明されている理由により、実装できませんでした。したがって、[RFC7950]で規定されている規則に注意して、このドキュメントではモジュール名を保持することが決定されました。
AAA: Authentication, Authorization, and Accounting.
AAA：認証、承認、およびアカウンティング。
ACL: Access Control List.
ACL：アクセス制御リスト。
ADSL: Asymmetric DSL.
ADSL：非対称DSL。
AH: Authentication Header.
AH：認証ヘッダー。
AS: Autonomous System.
AS：自律システム。
ASBR: Autonomous System Border Router.
ASBR：Autonomous System Border Router。
ASM: Any-Source Multicast.
ASM：Any-Source Multicast。
BAS: Broadband Access Switch.
BAS：ブロードバンドアクセススイッチ。
BFD: Bidirectional Forwarding Detection.
BFD：双方向転送検出。
BGP: Border Gateway Protocol.
BGP：ボーダーゲートウェイプロトコル。
BSR: Bootstrap Router.
BSR：ブートストラップルーター。
CE: Customer Edge.
CE：カスタマーエッジ。
CLI: Command Line Interface.
CLI：コマンドラインインターフェース。
CsC: Carriers' Carriers.
CsC：運送業者の運送業者。
CSP: Cloud Service Provider.
CSP：クラウドサービスプロバイダー。
DHCP: Dynamic Host Configuration Protocol.
DHCP：動的ホスト構成プロトコル。
DSLAM: Digital Subscriber Line Access Multiplexer.
DSLAM：Digital Subscriber Line Access Multiplexer。
ESP: Encapsulating Security Payload.
ESP：セキュリティペイロードのカプセル化。
GRE: Generic Routing Encapsulation.
GRE：Generic Routing Encapsulation。
IGMP: Internet Group Management Protocol.
IGMP：インターネットグループ管理プロトコル。
LAN: Local Area Network.
LAN：ローカルエリアネットワーク。
MLD: Multicast Listener Discovery.
MLD：マルチキャストリスナーの発見。
MTU: Maximum Transmission Unit.
MTU：最大転送単位。
NAT: Network Address Translation.
NAT：ネットワークアドレス変換。
NETCONF: Network Configuration Protocol.
NETCONF：ネットワーク構成プロトコル。
NNI: Network-to-Network Interface.
NNI：ネットワーク間インターフェース。
OAM: Operations, Administration, and Maintenance.
OAM：運用、管理、およびメンテナンス。
OSPF: Open Shortest Path First.
OSPF：Open Shortest Path First。
OSS: Operations Support System.
OSS：運用支援システム。
PE: Provider Edge.
PE：プロバイダーエッジ。
PIM: Protocol Independent Multicast.
PIM：Protocol Independent Multicast。
POP: Point of Presence.
POP：Point of Presence。
QoS: Quality of Service.
QoS：サービスの品質。
RD: Route Distinguisher.
RD：Route Distinguisher。
RIP: Routing Information Protocol.
RIP：ルーティング情報プロトコル。
RP: Rendezvous Point.
RP：ランデブーポイント。
RT: Route Target.
RT：ルートターゲット。
SFTP: Secure FTP.
SFTP：セキュアFTP。
SLA: Service Level Agreement.
SLA：サービスレベルアグリーメント。
SLAAC: Stateless Address Autoconfiguration.
SLAAC：ステートレスアドレス自動構成。
SP: Service Provider.
SP：サービスプロバイダー。
SPT: Shortest Path Tree.
SPT：最短パスツリー。
SSM: Source-Specific Multicast.
SSM：ソース固有のマルチキャスト。
VM: Virtual Machine.
VM：仮想マシン。
VPN: Virtual Private Network.
VPN：仮想プライベートネットワーク。
VRF: VPN Routing and Forwarding.
VRF：VPNルーティングおよび転送。
VRRP: Virtual Router Redundancy Protocol.
VRRP：Virtual Router Redundancy Protocol。
Customer Edge (CE) Device: A CE is equipment dedicated to a particular customer; it is directly connected (at Layer 3) to one or more PE devices via attachment circuits. A CE is usually located at the customer premises and is usually dedicated to a single VPN, although it may support multiple VPNs if each one has separate attachment circuits.
Customer Edge（CE）デバイス：CEは、特定の顧客専用の機器です。接続回線を介して1つ以上のPEデバイスに（レイヤ3で）直接接続されています。 CEは通常、顧客の構内にあり、通常は単一のVPN専用ですが、それぞれに個別の接続回線がある場合、複数のVPNをサポートする場合があります。
Provider Edge (PE) Device: A PE is equipment managed by the SP; it can support multiple VPNs for different customers and is directly connected (at Layer 3) to one or more CE devices via attachment circuits. A PE is usually located at an SP point of presence (POP) and is managed by the SP.
プロバイダーエッジ（PE）デバイス：PEは、SPによって管理される機器です。異なる顧客の複数のVPNをサポートでき、接続回線を介して1つ以上のCEデバイスに（レイヤー3で）直接接続されます。 PEは通常、SPの存在場所（POP）に配置され、SPによって管理されます。
PE-Based VPNs: The PE devices know that certain traffic is VPN traffic. They forward the traffic (through tunnels) based on the destination IP address of the packet and, optionally, based on other information in the IP header of the packet. The PE devices are themselves the tunnel endpoints. The tunnels may make use of various encapsulations to send traffic over the SP network (such as, but not restricted to, GRE, IP-in-IP, IPsec, or MPLS tunnels).
PEベースのVPN：PEデバイスは、特定のトラフィックがVPNトラフィックであることを認識しています。それらは、パケットの宛先IPアドレスに基づいて（オプションで）パケットのIPヘッダー内の他の情報に基づいて（トンネルを介して）トラフィックを転送します。 PEデバイス自体がトンネルエンドポイントです。トンネルは、SPネットワークを介してトラフィックを送信するために、さまざまなカプセル化を利用する場合があります（GRE、IP-in-IP、IPsec、またはMPLSトンネルなど）。
A Layer 3 IP VPN service is a collection of sites that are authorized to exchange traffic between each other over a shared IP infrastructure. This Layer 3 VPN service model aims at providing a common understanding of how the corresponding IP VPN service is to be deployed over the shared infrastructure. This service model is limited to BGP PE-based VPNs as described in [RFC4026], [RFC4110], and [RFC4364].
レイヤー3 IP VPNサービスは、共有IPインフラストラクチャを介して相互にトラフィックを交換することを許可されたサイトの集まりです。このレイヤ3 VPNサービスモデルは、対応するIP VPNサービスを共有インフラストラクチャ上に展開する方法についての一般的な理解を提供することを目的としています。 [RFC4026]、[RFC4110]、および[RFC4364]で説明されているように、このサービスモデルはBGP PEベースのVPNに限定されています。
l3vpn-svc |
Model |
|
+------------------+ +-----+
| Orchestration | < --- > | OSS |
+------------------+ +-----+
| |
+----------------+ |
| Config manager | |
+----------------+ |
| |
| NETCONF/CLI ...
| |
+------------------------------------------------+
Network
+++++++
+ AAA +
+++++++
++++++++ Bearer ++++++++ ++++++++ ++++++++
+ CE A + ----------- + PE A + + PE B + ---- + CE B +
++++++++ Connection ++++++++ ++++++++ ++++++++
Site A Site B
サイトAサイトB
The idea of the L3 IP VPN service model is to propose an abstracted interface between customers and network operators to manage configuration of components of an L3VPN service. The model is intended to be used in a mode where the network operator's system is the server and the customer's system is the client. A typical scenario would be to use this model as an input for an orchestration layer that will be responsible for translating it to an orchestrated configuration of network elements that will be part of the service. The network elements can be routers but can also be servers (like AAA); the network's configuration is not limited to these examples. The configuration of network elements can be done via the CLI, NETCONF/RESTCONF [RFC6241] [RFC8040] coupled with YANG data models of a specific configuration (BGP, VRF, BFD, etc.), or some other technique, as preferred by the operator.
L3 IP VPNサービスモデルのアイデアは、L3VPNサービスのコンポーネントの構成を管理するために、顧客とネットワークオペレーターの間に抽象化されたインターフェイスを提案することです。このモデルは、ネットワークオペレーターのシステムがサーバーで、顧客のシステムがクライアントであるモードで使用することを目的としています。典型的なシナリオは、このモデルを、サービスの一部となるネットワーク要素のオーケストレーションされた構成に変換する責任があるオーケストレーションレイヤーの入力として使用することです。ネットワーク要素はルーターにすることもできますが、サーバー（AAAなど）にすることもできます。ネットワークの構成はこれらの例に限定されません。ネットワーク要素の構成は、CLI、NETCONF / RESTCONF [RFC6241] [RFC8040]を特定の構成（BGP、VRF、BFDなど）のYANGデータモデルと組み合わせて行うか、またはオペレーター。
The usage of this service model is not limited to this example; it can be used by any component of the management system but not directly by network elements.
このサービスモデルの使用はこの例に限定されません。管理システムの任意のコンポーネントで使用できますが、ネットワーク要素では直接使用できません。
The YANG module is divided into two main containers: "vpn-services" and "sites".
YANGモジュールは、「vpn-services」と「sites」の2つの主要なコンテナーに分かれています。
The "vpn-service" list under the vpn-services container defines global parameters for the VPN service for a specific customer.
vpn-servicesコンテナの下の「vpn-service」リストは、特定の顧客のVPNサービスのグローバルパラメータを定義します。
A "site" is composed of at least one "site-network-access" and, in the case of multihoming, may have multiple site-network-access points. The site-network-access attachment is done through a "bearer" with an "ip-connection" on top. The bearer refers to properties of the attachment that are below Layer 3, while the connection refers to properties oriented to the Layer 3 protocol. The bearer may be allocated dynamically by the SP, and the customer may provide some constraints or parameters to drive the placement of the access.
「サイト」は、少なくとも1つの「サイトネットワークアクセス」で構成され、マルチホーミングの場合、複数のサイトネットワークアクセスポイントを持つことができます。サイトネットワークアクセスアタッチメントは、「ベアラ」を介して行われ、「IP接続」が上部にあります。ベアラは、レイヤ3の下にあるアタッチメントのプロパティを参照しますが、接続は、レイヤ3プロトコル向けのプロパティを参照します。ベアラはSPによって動的に割り当てることができ、顧客はアクセスの配置を促進するためにいくつかの制約またはパラメータを提供できます。
Authorization of traffic exchange is done through what we call a VPN policy or VPN service topology defining routing exchange rules between sites.
トラフィック交換の承認は、サイト間のルーティング交換ルールを定義するVPNポリシーまたはVPNサービストポロジと呼ばれるものを通じて行われます。
The figure below describes the overall structure of the YANG module:
以下の図は、YANGモジュールの全体的な構造を示しています。
module: ietf-l3vpn-svc
+--rw l3vpn-svc
+--rw vpn-profiles
| +--rw valid-provider-identifiers
| +--rw cloud-identifier* [id] {cloud-access}?
| | +--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 vpn-services
| +--rw vpn-service* [vpn-id]
| +--rw vpn-id svc-id
| +--rw customer-name? string
| +--rw vpn-service-topology? identityref
| +--rw cloud-accesses {cloud-access}?
| | +--rw cloud-access* [cloud-identifier]
| | +--rw cloud-identifier leafref
| | +--rw (list-flavor)?
| | | +--:(permit-any)
| | | | +--rw permit-any? empty
| | | +--:(deny-any-except)
| | | | +--rw permit-site*
| | | | -> /l3vpn-svc/sites/site/site-id
| | | +--:(permit-any-except)
| | | +--rw deny-site*
| | | -> /l3vpn-svc/sites/site/site-id
| | +--rw address-translation
| | +--rw nat44
| | +--rw enabled? boolean
| | +--rw nat44-customer-address?
| | inet:ipv4-address
| +--rw multicast {multicast}?
| | +--rw enabled? boolean
| | +--rw customer-tree-flavors
| | | +--rw tree-flavor* identityref
| | +--rw rp
| | +--rw rp-group-mappings
| | | +--rw rp-group-mapping* [id]
| | | +--rw id uint16
| | | +--rw provider-managed
| | | | +--rw enabled? boolean
| | | | +--rw rp-redundancy? boolean
| | | | +--rw optimal-traffic-delivery? boolean
| | | +--rw rp-address inet:ip-address
| | | +--rw groups
| | | +--rw group* [id]
| | | +--rw id uint16
| | | +--rw (group-format)
| | | +--:(singleaddress)
| | | | +--rw group-address?
| | | | inet:ip-address
| | | +--:(startend)
| | | +--rw group-start?
| | | | inet:ip-address
| | | +--rw group-end?
| | | inet:ip-address
| | +--rw rp-discovery
| | +--rw rp-discovery-type? identityref
| | +--rw bsr-candidates
| | +--rw bsr-candidate-address* inet:ip-address
| +--rw carrierscarrier? boolean {carrierscarrier}?
| +--rw extranet-vpns {extranet-vpn}?
| +--rw extranet-vpn* [vpn-id]
| +--rw vpn-id svc-id
| +--rw local-sites-role? identityref
+--rw sites
+--rw site* [site-id]
+--rw site-id svc-id
+--rw requested-site-start? yang:date-and-time
+--rw requested-site-stop? yang:date-and-time
+--rw locations
| +--rw location* [location-id]
| +--rw location-id svc-id
| +--rw address? string
| +--rw postal-code? string
| +--rw state? string
| +--rw city? string
| +--rw country-code? string
+--rw devices
| +--rw device* [device-id]
| +--rw device-id svc-id
| +--rw location
| | -> ../../../locations/location/location-id
| +--rw management
| +--rw address-family? address-family
| +--rw address inet:ip-address
+--rw site-diversity {site-diversity}?
| +--rw groups
| +--rw group* [group-id]
| +--rw group-id string
+--rw management
| +--rw type identityref
+--rw vpn-policies
| +--rw vpn-policy* [vpn-policy-id]
| +--rw vpn-policy-id svc-id
| +--rw entries* [id]
| +--rw id svc-id
| +--rw filters
| | +--rw filter* [type]
| | +--rw type identityref
| | +--rw lan-tag* string
| | | {lan-tag}?
| | +--rw ipv4-lan-prefix* inet:ipv4-prefix
| | | {ipv4}?
| | +--rw ipv6-lan-prefix* inet:ipv6-prefix
| | {ipv6}?
| +--rw vpn* [vpn-id]
| +--rw vpn-id leafref
| +--rw site-role? identityref
+--rw site-vpn-flavor? identityref
+--rw maximum-routes
| +--rw address-family* [af]
| +--rw af address-family
| +--rw maximum-routes? uint32
+--rw security
| +--rw authentication
| +--rw encryption {encryption}?
| +--rw enabled? boolean
| +--rw layer? enumeration
| +--rw encryption-profile
| +--rw (profile)?
| +--:(provider-profile)
| | +--rw profile-name? leafref
| +--:(customer-profile)
| +--rw algorithm? string
| +--rw (key-type)?
| +--:(psk)
| +--rw preshared-key? string
+--rw service
| +--rw qos {qos}?
| | +--rw qos-classification-policy
| | | +--rw rule* [id]
| | | +--rw id string
| | | +--rw (match-type)?
| | | | +--:(match-flow)
| | | | | +--rw match-flow
| | | | | +--rw dscp? inet:dscp
| | | | | +--rw dot1p? uint8
| | | | | +--rw ipv4-src-prefix?
| | | | | | inet:ipv4-prefix
| | | | | +--rw ipv6-src-prefix?
| | | | | | inet:ipv6-prefix
| | | | | +--rw ipv4-dst-prefix?
| | | | | | inet:ipv4-prefix
| | | | | +--rw ipv6-dst-prefix?
| | | | | | inet:ipv6-prefix
| | | | | +--rw l4-src-port?
| | | | | | inet:port-number
| | | | | +--rw target-sites* svc-id
| | | | | | {target-sites}?
| | | | | +--rw l4-src-port-range
| | | | | | +--rw lower-port? inet:port-number
| | | | | | +--rw upper-port? inet:port-number
| | | | | +--rw l4-dst-port?
| | | | | | inet:port-number
| | | | | +--rw l4-dst-port-range
| | | | | | +--rw lower-port? inet:port-number
| | | | | | +--rw upper-port? inet:port-number
| | | | | +--rw protocol-field? union
| | | | +--:(match-application)
| | | | +--rw match-application? identityref
| | | +--rw target-class-id? string
| | +--rw qos-profile
| | +--rw (qos-profile)?
| | +--:(standard)
| | | +--rw profile? leafref
| | +--:(custom)
| | +--rw classes {qos-custom}?
| | +--rw class* [class-id]
| | +--rw class-id string
| | +--rw direction? identityref
| | +--rw rate-limit? decimal64
| | +--rw latency
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-latency?
| | | | empty
| | | +--:(boundary)
| | | +--rw latency-boundary?
| | | uint16
| | +--rw jitter
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-jitter?
| | | | empty
| | | +--:(boundary)
| | | +--rw latency-boundary?
| | | uint32
| | +--rw bandwidth
| | +--rw guaranteed-bw-percent
| | | decimal64
| | +--rw end-to-end? empty
| +--rw carrierscarrier {carrierscarrier}?
| | +--rw signalling-type? enumeration
| +--rw multicast {multicast}?
| +--rw multicast-site-type? enumeration
| +--rw multicast-address-family
| | +--rw ipv4? boolean {ipv4}?
| | +--rw ipv6? boolean {ipv6}?
| +--rw protocol-type? enumeration
+--rw traffic-protection {fast-reroute}?
| +--rw enabled? boolean
+--rw routing-protocols
| +--rw routing-protocol* [type]
| +--rw type identityref
| +--rw ospf {rtg-ospf}?
| | +--rw address-family* address-family
| | +--rw area-address yang:dotted-quad
| | +--rw metric? uint16
| | +--rw sham-links {rtg-ospf-sham-link}?
| | +--rw sham-link* [target-site]
| | +--rw target-site svc-id
| | +--rw metric? uint16
| +--rw bgp {rtg-bgp}?
| | +--rw autonomous-system uint32
| | +--rw address-family* address-family
| +--rw static
| | +--rw cascaded-lan-prefixes
| | +--rw ipv4-lan-prefixes* [lan next-hop]
| | | {ipv4}?
| | | +--rw lan inet:ipv4-prefix
| | | +--rw lan-tag? string
| | | +--rw next-hop inet:ipv4-address
| | +--rw ipv6-lan-prefixes* [lan next-hop]
| | {ipv6}?
| | +--rw lan inet:ipv6-prefix
| | +--rw lan-tag? string
| | +--rw next-hop inet:ipv6-address
| +--rw rip {rtg-rip}?
| | +--rw address-family* address-family
| +--rw vrrp {rtg-vrrp}?
| +--rw address-family* address-family
+--ro actual-site-start? yang:date-and-time
+--ro actual-site-stop? yang:date-and-time
+--rw site-network-accesses
+--rw site-network-access* [site-network-access-id]
+--rw site-network-access-id svc-id
+--rw site-network-access-type? identityref
+--rw (location-flavor)
| +--:(location)
| | +--rw location-reference? leafref
| +--:(device)
| +--rw device-reference?
| -> ../../../devices/device/device-id
+--rw access-diversity {site-diversity}?
| +--rw groups
| | +--rw group* [group-id]
| | +--rw group-id string
| +--rw constraints
| +--rw constraint* [constraint-type]
| +--rw constraint-type identityref
| +--rw target
| +--rw (target-flavor)?
| +--:(id)
| | +--rw group* [group-id]
| | +--rw group-id string
| +--:(all-accesses)
| | +--rw all-other-accesses? empty
| +--:(all-groups)
| +--rw all-other-groups? empty
+--rw bearer
| +--rw requested-type {requested-type}?
| | +--rw requested-type? string
| | +--rw strict? boolean
| +--rw always-on? boolean {always-on}?
| +--rw bearer-reference? string
| {bearer-reference}?
+--rw ip-connection
| +--rw ipv4 {ipv4}?
| | +--rw address-allocation-type? identityref
| | +--rw provider-dhcp
| | | +--rw provider-address?
| | | | inet:ipv4-address
| | | +--rw prefix-length? uint8
| | | +--rw (address-assign)?
| | | +--:(number)
| | | | +--rw number-of-dynamic-address?
| | | | uint16
| | | +--:(explicit)
| | | +--rw customer-addresses
| | | +--rw address-group* [group-id]
| | | +--rw group-id string
| | | +--rw start-address?
| | | | inet:ipv4-address
| | | +--rw end-address?
| | | inet:ipv4-address
| | +--rw dhcp-relay
| | | +--rw provider-address?
| | | | inet:ipv4-address
| | | +--rw prefix-length? uint8
| | | +--rw customer-dhcp-servers
| | | +--rw server-ip-address*
| | | inet:ipv4-address
| | +--rw addresses
| | +--rw provider-address? inet:ipv4-address
| | +--rw customer-address? inet:ipv4-address
| | +--rw prefix-length? uint8
| +--rw ipv6 {ipv6}?
| | +--rw address-allocation-type? identityref
| | +--rw provider-dhcp
| | | +--rw provider-address?
| | | | inet:ipv6-address
| | | +--rw prefix-length? uint8
| | | +--rw (address-assign)?
| | | +--:(number)
| | | | +--rw number-of-dynamic-address?
| | | | uint16
| | | +--:(explicit)
| | | +--rw customer-addresses
| | | +--rw address-group* [group-id]
| | | +--rw group-id string
| | | +--rw start-address?
| | | | inet:ipv6-address
| | | +--rw end-address?
| | | inet:ipv6-address
| | +--rw dhcp-relay
| | | +--rw provider-address?
| | | | inet:ipv6-address
| | | +--rw prefix-length? uint8
| | | +--rw customer-dhcp-servers
| | | +--rw server-ip-address*
| | | inet:ipv6-address
| | +--rw addresses
| | +--rw provider-address? inet:ipv6-address
| | +--rw customer-address? inet:ipv6-address
| | +--rw prefix-length? uint8
| +--rw oam
| +--rw bfd {bfd}?
| +--rw enabled? boolean
| +--rw (holdtime)?
| +--:(fixed)
| | +--rw fixed-value? uint32
| +--:(profile)
| +--rw profile-name? leafref
+--rw security
| +--rw authentication
| +--rw encryption {encryption}?
| +--rw enabled? boolean
| +--rw layer? enumeration
| +--rw encryption-profile
| +--rw (profile)?
| +--:(provider-profile)
| | +--rw profile-name? leafref
| +--:(customer-profile)
| +--rw algorithm? string
| +--rw (key-type)?
| +--:(psk)
| +--rw preshared-key? string
+--rw service
| +--rw svc-input-bandwidth uint64
| +--rw svc-output-bandwidth uint64
| +--rw svc-mtu uint16
| +--rw qos {qos}?
| | +--rw qos-classification-policy
| | | +--rw rule* [id]
| | | +--rw id string
| | | +--rw (match-type)?
| | | | +--:(match-flow)
| | | | | +--rw match-flow
| | | | | +--rw dscp?
| | | | | | inet:dscp
| | | | | +--rw dot1p? uint8
| | | | | +--rw ipv4-src-prefix?
| | | | | | inet:ipv4-prefix
| | | | | +--rw ipv6-src-prefix?
| | | | | | inet:ipv6-prefix
| | | | | +--rw ipv4-dst-prefix?
| | | | | | inet:ipv4-prefix
| | | | | +--rw ipv6-dst-prefix?
| | | | | | inet:ipv6-prefix
| | | | | +--rw l4-src-port?
| | | | | | inet:port-number
| | | | | +--rw target-sites* svc-id
| | | | | | {target-sites}?
| | | | | +--rw l4-src-port-range
| | | | | | +--rw lower-port?
| | | | | | | inet:port-number
| | | | | | +--rw upper-port?
| | | | | | inet:port-number
| | | | | +--rw l4-dst-port?
| | | | | | inet:port-number
| | | | | +--rw l4-dst-port-range
| | | | | | +--rw lower-port?
| | | | | | | inet:port-number
| | | | | | +--rw upper-port?
| | | | | | inet:port-number
| | | | | +--rw protocol-field? union
| | | | +--:(match-application)
| | | | +--rw match-application?
| | | | identityref
| | | +--rw target-class-id? string
| | +--rw qos-profile
| | +--rw (qos-profile)?
| | +--:(standard)
| | | +--rw profile? leafref
| | +--:(custom)
| | +--rw classes {qos-custom}?
| | +--rw class* [class-id]
| | +--rw class-id string
| | +--rw direction? identityref
| | +--rw rate-limit? decimal64
| | +--rw latency
| | | +-rw (flavor)?
| | | +--:(lowest)
| | | | +-rw use-lowest-latency?
| | | | empty
| | | +--:(boundary)
| | | +-rw latency-boundary?
| | | uint16
| | +--rw jitter
| | | +-rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-jitter?
| | | | empty
| | | +--:(boundary)
| | | +--rw latency-boundary?
| | | uint32
| | +--rw bandwidth
| | +--rw guaranteed-bw-percent
| | | decimal64
| | +--rw end-to-end?
| | empty
| +--rw carrierscarrier {carrierscarrier}?
| | +--rw signalling-type? enumeration
| +--rw multicast {multicast}?
| +--rw multicast-site-type? enumeration
| +--rw multicast-address-family
| | +--rw ipv4? boolean {ipv4}?
| | +--rw ipv6? boolean {ipv6}?
| +--rw protocol-type? enumeration
+--rw routing-protocols
| +--rw routing-protocol* [type]
| +--rw type identityref
| +--rw ospf {rtg-ospf}?
| | +--rw address-family* address-family
| | +--rw area-address yang:dotted-quad
| | +--rw metric? uint16
| | +--rw sham-links {rtg-ospf-sham-link}?
| | +--rw sham-link* [target-site]
| | +--rw target-site svc-id
| | +--rw metric? uint16
| +--rw bgp {rtg-bgp}?
| | +--rw autonomous-system uint32
| | +--rw address-family* address-family
| +--rw static
| | +--rw cascaded-lan-prefixes
| | +--rw ipv4-lan-prefixes*
| | | [lan next-hop] {ipv4}?
| | | +--rw lan inet:ipv4-prefix
| | | +--rw lan-tag? string
| | | +--rw next-hop inet:ipv4-address
| | +--rw ipv6-lan-prefixes*
| | [lan next-hop] {ipv6}?
| | +--rw lan inet:ipv6-prefix
| | +--rw lan-tag? string
| | +--rw next-hop inet:ipv6-address
| +--rw rip {rtg-rip}?
| | +--rw address-family* address-family
| +--rw vrrp {rtg-vrrp}?
| +--rw address-family* address-family
+--rw availability
| +--rw access-priority? uint32
+--rw vpn-attachment
+--rw (attachment-flavor)
+--:(vpn-policy-id)
| +--rw vpn-policy-id? leafref
+--:(vpn-id)
+--rw vpn-id? leafref
+--rw site-role? identityref
The model defined in this document implements many features that allow implementations to be modular. As an example, an implementation may support only IPv4 VPNs (IPv4 feature), IPv6 VPNs (IPv6 feature), or both (by advertising both features). The routing protocols proposed to the customer may also be enabled through features. This model also defines some features for options that are more advanced, such as support for extranet VPNs (Section 6.2.4), site diversity (Section 6.6), and QoS (Section 6.12.3).
このドキュメントで定義されているモデルは、実装をモジュール化できるようにする多くの機能を実装しています。例として、実装はIPv4 VPN（IPv4機能）、IPv6 VPN（IPv6機能）、または両方（両方の機能をアドバタイズすることにより）のみをサポートする場合があります。顧客に提案されたルーティングプロトコルは、機能を介して有効にすることもできます。このモデルは、エクストラネットVPN（セクション6.2.4）、サイトダイバーシティ（セクション6.6）、QoS（セクション6.12.3）のサポートなど、より高度なオプションのいくつかの機能も定義します。
In addition, as for any YANG data model, this service model can be augmented to implement new behaviors or specific features. For example, this model uses different options for IP address assignments; if those options do not fulfill all requirements, new options can be added through augmentation.
さらに、YANGデータモデルと同様に、このサービスモデルを拡張して、新しい動作や特定の機能を実装できます。たとえば、このモデルではIPアドレスの割り当てにさまざまなオプションを使用しています。これらのオプションがすべての要件を満たしていない場合は、拡張によって新しいオプションを追加できます。
A vpn-service list item contains generic information about the VPN service. The "vpn-id" provided in the vpn-service list refers to an internal reference for this VPN service, while the customer name refers to a more-explicit reference to the customer. This identifier is purely internal to the organization responsible for the VPN service.
vpn-serviceリストアイテムには、VPNサービスに関する一般的な情報が含まれています。 vpn-serviceリストで提供される「vpn-id」は、このVPNサービスの内部参照を指し、顧客名は顧客へのより明示的な参照を指します。この識別子は、VPNサービスを担当する組織の内部でのみ使用されます。
The type of VPN service topology is required for configuration. Our proposed model supports any-to-any, Hub and Spoke (where Hubs can exchange traffic), and "Hub and Spoke disjoint" (where Hubs cannot exchange traffic). New topologies could be added via augmentation. By default, the any-to-any VPN service topology is used.
設定には、VPNサービストポロジのタイプが必要です。私たちが提案するモデルは、any-to-any、ハブとスポーク（ハブはトラフィックを交換できる）、および「ハブとスポークの素」（ハブはトラフィックを交換できない）をサポートします。新しいトポロジーは、拡張によって追加できます。デフォルトでは、any-to-any VPNサービストポロジが使用されます。
A Layer 3 PE-based VPN is built using route targets (RTs) as described in [RFC4364]. The management system is expected to automatically allocate a set of RTs upon receiving a VPN service creation request. How the management system allocates RTs is out of scope for this document, but multiple ways could be envisaged, as described below.
[RFC4364]で説明されているように、レイヤー3 PEベースのVPNはルートターゲット（RT）を使用して構築されます。管理システムは、VPNサービスの作成要求を受信すると、RTのセットを自動的に割り当てることが期待されています。管理システムがRTを割り当てる方法はこのドキュメントの範囲外ですが、以下で説明するように、複数の方法を想定できます。
Management system
<------------------------------------------------->
Request RT
+-----------------------+ Topo a2a +----------+
RESTCONF | | -----> | |
User ------------- | Service Orchestration | | Network |
l3vpn-svc | | <----- | OSS |
Model +-----------------------+ Response +----------+
RT1, RT2
In the example above, a service orchestration, owning the instantiation of this service model, requests RTs to the network OSS. Based on the requested VPN service topology, the network OSS replies with one or multiple RTs. The interface between this service orchestration and the network OSS is out of scope for this document.
上記の例では、このサービスモデルのインスタンスを所有するサービスオーケストレーションが、ネットワークOSSにRTを要求します。要求されたVPNサービストポロジに基づいて、ネットワークOSSは1つまたは複数のRTで応答します。このサービスオーケストレーションとネットワークOSS間のインターフェイスは、このドキュメントの範囲外です。
+---------------------------+
RESTCONF | |
User ------------- | Service Orchestration |
l3vpn-svc | |
Model | |
| RT pool: 10:1->10:10000 |
| RT pool: 20:50->20:5000 |
+---------------------------+
In the example above, a service orchestration, owning the instantiation of this service model, owns one or more pools of RTs (specified by the SP) that can be allocated. Based on the requested VPN service topology, it will allocate one or multiple RTs from the pool.
上記の例では、このサービスモデルのインスタンスを所有するサービスオーケストレーションが、割り当て可能なRT（SPで指定）の1つ以上のプールを所有しています。要求されたVPNサービストポロジに基づいて、プールから1つまたは複数のRTを割り当てます。
The mechanisms shown above are just examples and should not be considered an exhaustive list of solutions.
上記のメカニズムは単なる例であり、ソリューションの完全なリストとは見なされません。
+------------------------------------------------------------+
| VPN1_Site1 ------ PE1 PE2 ------ VPN1_Site2 |
| |
| VPN1_Site3 ------ PE3 PE4 ------ VPN1_Site4 |
+------------------------------------------------------------+
Any-to-Any VPN Service Topology
Any-to-Any VPNサービストポロジ
In the any-to-any VPN service topology, all VPN sites can communicate with each other without any restrictions. The management system that receives an any-to-any IP VPN service request through this model is expected to assign and then configure the VRF and RTs on the appropriate PEs. In the any-to-any case, a single RT is generally required, and every VRF imports and exports this RT.
Any-to-Any VPNサービストポロジでは、すべてのVPNサイトが相互に制限なく通信できます。このモデルを通じてAny-to-Any IP VPNサービスリクエストを受信する管理システムは、適切なPEにVRFとRTを割り当てて設定することが期待されています。エニーツーエニーの場合、通常は単一のRTが必要であり、すべてのVRFがこのRTをインポートおよびエクスポートします。
+-------------------------------------------------------------+
| Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
| +----------------------------------+
| |
| +----------------------------------+
| Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+
Hub-and-Spoke VPN Service Topology
ハブアンドスポークVPNサービストポロジ
In the Hub-and-Spoke VPN service topology, all Spoke sites can communicate only with Hub sites but not with each other, and Hubs can also communicate with each other. The management system that owns an any-to-any IP VPN service request through this model is expected to assign and then configure the VRF and RTs on the appropriate PEs. In the Hub-and-Spoke case, two RTs are generally required (one RT for Hub routes and one RT for Spoke routes). A Hub VRF that connects Hub sites will export Hub routes with the Hub RT and will import Spoke routes through the Spoke RT. It will also import the Hub RT to allow Hub-to-Hub communication. A Spoke VRF that connects Spoke sites will export Spoke routes with the Spoke RT and will import Hub routes through the Hub RT.
ハブアンドスポークVPNサービストポロジでは、すべてのスポークサイトはハブサイトとのみ通信でき、相互には通信できません。また、ハブは相互に通信することもできます。このモデルを通じてAny-to-Any IP VPNサービスリクエストを所有する管理システムは、適切なPEにVRFとRTを割り当てて設定する必要があります。ハブアンドスポークの場合、通常2つのRTが必要です（ハブルート用に1つのRTとスポークルート用に1つのRT）。ハブサイトを接続するハブVRFは、ハブルートをハブRTでエクスポートし、スポークルートをスポークRT経由でインポートします。また、ハブ間の通信を可能にするためにハブRTをインポートします。スポークサイトを接続するスポークVRFは、スポークルートをスポークRTでエクスポートし、ハブルートをハブRT経由でインポートします。
The management system MUST take into account constraints on Hub-and-Spoke connections. For example, if a management system decides to mesh a Spoke site and a Hub site on the same PE, it needs to mesh connections in different VRFs, as shown in the figure below.
管理システムはハブアンドスポーク接続の制約を考慮しなければなりません。たとえば、管理システムが同じPE上のスポークサイトとハブサイトをメッシュ化することを決定した場合、次の図に示すように、異なるVRFの接続をメッシュ化する必要があります。
Hub_Site ------- (VRF_Hub) PE1
(VRF_Spoke)
/ |
Spoke_Site1 -------------------+ |
|
Spoke_Site2 -----------------------+
+-------------------------------------------------------------+
| Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
+--------------------------+ +-------------------------------+
| |
+--------------------------+ +-------------------------------+
| Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+
Hub and Spoke Disjoint VPN Service Topology
ハブアンドスポーク分離VPNサービストポロジ
In the Hub and Spoke disjoint VPN service topology, all Spoke sites can communicate only with Hub sites but not with each other, and Hubs cannot communicate with each other. The management system that owns an any-to-any IP VPN service request through this model is expected to assign and then configure the VRF and RTs on the appropriate PEs. In the Hub-and-Spoke case, two RTs are required (one RT for Hub routes and one RT for Spoke routes). A Hub VRF that connects Hub sites will export Hub routes with the Hub RT and will import Spoke routes through the Spoke RT. A Spoke VRF that connects Spoke sites will export Spoke routes with the Spoke RT and will import Hub routes through the Hub RT.
ハブとスポークの分離VPNサービストポロジでは、すべてのスポークサイトはハブサイトとのみ通信でき、相互には通信できません。また、ハブは相互に通信できません。このモデルを通じてAny-to-Any IP VPNサービスリクエストを所有する管理システムは、適切なPEにVRFとRTを割り当てて設定する必要があります。ハブアンドスポークの場合、2つのRTが必要です（ハブルート用に1つのRTとスポークルート用に1つのRT）。ハブサイトを接続するハブVRFは、ハブルートをハブRTでエクスポートし、スポークルートをスポークRT経由でインポートします。スポークサイトを接続するスポークVRFは、スポークルートをスポークRTでエクスポートし、ハブルートをハブRT経由でインポートします。
The management system MUST take into account constraints on Hub-and-Spoke connections, as in the previous case.
管理システムは、前のケースと同様に、ハブアンドスポーク接続の制約を考慮しなければなりません。
Hub and Spoke disjoint can also be seen as multiple Hub-and-Spoke VPNs (one per Hub) that share a common set of Spoke sites.
ハブとスポークの素性は、スポークサイトの共通セットを共有する複数のハブアンドスポークVPN（ハブごとに1つ）と見なすこともできます。
The proposed model provides cloud access configuration via the "cloud-accesses" container. The usage of cloud-access is targeted for the public cloud. An Internet access can also be considered a public cloud access service. The cloud-accesses container provides parameters for network address translation and authorization rules.
提案されたモデルは、「cloud-accesses」コンテナを介してクラウドアクセス構成を提供します。クラウドアクセスの使用は、パブリッククラウドを対象としています。インターネットアクセスは、パブリッククラウドアクセスサービスと見なすこともできます。 cloud-accessesコンテナーは、ネットワークアドレス変換および承認ルールのパラメーターを提供します。
A private cloud access may be addressed through NNIs, as described in Section 6.15.
プライベートクラウドアクセスは、セクション6.15で説明されているように、NNIを介して対処できます。
A cloud identifier is used to reference the target service. This identifier is local to each administration.
クラウド識別子は、ターゲットサービスを参照するために使用されます。この識別子は、各行政機関に対してローカルです。
The model allows for source address translation before accessing the cloud. IPv4-to-IPv4 address translation (NAT44) is the only supported option, but other options can be added through augmentation. If IP source address translation is required to access the cloud, the "enabled" leaf MUST be set to true in the "nat44" container. An IP address may be provided in the "customer-address" leaf if the customer is providing the IP address to be used for the cloud access. If the SP is providing this address, "customer-address" is not necessary, as it can be picked from a pool of SPs.
このモデルでは、クラウドにアクセスする前にソースアドレス変換を行うことができます。 IPv4-to-IPv4アドレス変換（NAT44）がサポートされている唯一のオプションですが、その他のオプションは拡張によって追加できます。クラウドにアクセスするためにIPソースアドレス変換が必要な場合、「nat44」コンテナで「有効」リーフをtrueに設定する必要があります。顧客がクラウドアクセスに使用するIPアドレスを提供している場合は、「顧客アドレス」リーフにIPアドレスを指定できます。 SPがこのアドレスを提供している場合、SPのプールから選択できるため、「customer-address」は不要です。
By default, all sites in the IP VPN MUST be authorized to access the cloud. If restrictions are required, a user MAY configure the "permit-site" or "deny-site" leaf-list. The permit-site leaf-list defines the list of sites authorized for cloud access. The deny-site leaf-list defines the list of sites denied for cloud access. The model supports both "deny-any-except" and "permit-any-except" authorization.
デフォルトでは、IP VPN内のすべてのサイトがクラウドへのアクセスを許可されている必要があります。制限が必要な場合、ユーザーは「許可サイト」または「拒否サイト」リーフリストを設定できます。許可サイトリーフリストは、クラウドアクセスを許可するサイトのリストを定義します。 deny-siteリーフリストは、クラウドアクセスが拒否されたサイトのリストを定義します。モデルは、「deny-any-except」と「permit-any-except」の両方の承認をサポートしています。
How the restrictions will be configured on network elements is out of scope for this document.
ネットワーク要素に制限を設定する方法は、このドキュメントの範囲外です。
IP VPN
++++++++++++++++++++++++++++++++ ++++++++++++
+ Site 3 + --- + Cloud 1 +
+ Site 1 + ++++++++++++
+ +
+ Site 2 + --- ++++++++++++
+ + + Internet +
+ Site 4 + ++++++++++++
++++++++++++++++++++++++++++++++
|
+++++++++++
+ Cloud 2 +
+++++++++++
In the example above, we configure the global VPN to access the Internet by creating a cloud-access pointing to the cloud identifier for the Internet service. No authorized sites will be configured, as all sites are required to access the Internet. The "address-translation/nat44/enabled" leaf will be set to true.
上記の例では、インターネットサービスのクラウド識別子を指すクラウドアクセスを作成することにより、インターネットにアクセスするようにグローバルVPNを構成しています。すべてのサイトがインターネットにアクセスする必要があるため、許可サイトは構成されません。 「address-translation / nat44 / enabled」リーフはtrueに設定されます。
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>123456487</vpn-id>
<cloud-accesses>
<cloud-access>
<cloud-identifier>INTERNET</cloud-identifier>
<address-translation>
<nat44>
<enabled>true</enabled>
</nat44>
</address-translation>
</cloud-access>
</cloud-accesses>
</vpn-service>
</vpn-services>
</l3vpn-svc>
If Site 1 and Site 2 require access to Cloud 1, a new cloud-access pointing to the cloud identifier of Cloud 1 will be created. The permit-site leaf-list will be filled with a reference to Site 1 and Site 2.
サイト1とサイト2がクラウド1へのアクセスを必要とする場合、クラウド1のクラウド識別子を指す新しいクラウドアクセスが作成されます。許可サイトのリーフリストには、サイト1とサイト2への参照が入力されます。
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>123456487</vpn-id>
<cloud-accesses>
<cloud-access>
<cloud-identifier>Cloud1</cloud-identifier>
<permit-site>site1</permit-site>
<permit-site>site2</permit-site>
</cloud-access>
</cloud-accesses>
</vpn-service>
</vpn-services>
</l3vpn-svc>
If all sites except Site 1 require access to Cloud 2, a new cloud-access pointing to the cloud identifier of Cloud 2 will be created. The deny-site leaf-list will be filled with a reference to Site 1.
サイト1を除くすべてのサイトがクラウド2へのアクセスを必要とする場合、クラウド2のクラウド識別子を指す新しいクラウドアクセスが作成されます。拒否サイトのリーフリストには、サイト1への参照が入力されます。
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>123456487</vpn-id>
<cloud-accesses>
<cloud-access>
<cloud-identifier>Cloud2</cloud-identifier>
<deny-site>site1</deny-site>
</cloud-access>
</cloud-accesses>
</vpn-service>
</vpn-services>
</l3vpn-svc>
A service with more than one cloud access is functionally identical to multiple services each with a single cloud access, where the sites that belong to each service in the latter case correspond with the authorized sites for each cloud access in the former case. However, defining a single service with multiple cloud accesses may be operationally simpler.
複数のクラウドアクセスを持つサービスは、機能的にはそれぞれ単一のクラウドアクセスを持つ複数のサービスと同じです。後者の場合、各サービスに属するサイトは、前者の場合、各クラウドアクセスの承認済みサイトに対応します。ただし、複数のクラウドアクセスを持つ単一のサービスを定義すると、操作が簡単になる場合があります。
Multicast in IP VPNs is described in [RFC6513].
IP VPNでのマルチキャストは、[RFC6513]で説明されています。
If multicast support is required for an IP VPN, some global multicast parameters are required as input for the service request.
IP VPNでマルチキャストサポートが必要な場合は、サービスリクエストの入力として、いくつかのグローバルマルチキャストパラメータが必要です。
Users of this model will need to provide the flavors of trees that will be used by customers within the IP VPN (customer tree). The proposed model supports bidirectional, shared, and source-based trees (and can be augmented). Multiple flavors of trees can be supported simultaneously.
このモデルのユーザーは、IP VPN内の顧客によって使用されるツリーのフレーバー（顧客ツリー）を提供する必要があります。提案されたモデルは、双方向、共有、およびソースベースのツリーをサポートします（拡張可能です）。複数のフレーバーツリーを同時にサポートできます。
Operator network
______________
/ \
| |
(SSM tree) |
Recv (IGMPv3) -- Site2 ------- PE2 |
| PE1 --- Site1 --- Source1
| | \
| | -- Source2
| |
(ASM tree) |
Recv (IGMPv2) -- Site3 ------- PE3 |
| |
(SSM tree) |
Recv (IGMPv3) -- Site4 ------- PE4 |
| / |
Recv (IGMPv2) -- Site5 -------- |
(ASM tree) |
| |
\_______________/
When an ASM flavor is requested, this model requires that the "rp" and "rp-discovery" parameters be filled. Multiple RP-to-group mappings can be created using the "rp-group-mappings" container. For each mapping, the SP can manage the RP service by setting the "provider-managed/enabled" leaf to true. In the case of a provider-managed RP, the user can request RP redundancy and/or optimal traffic delivery. Those parameters will help the SP select the appropriate technology or architecture to fulfill the customer service requirement: for instance, in the case of a request for optimal traffic delivery, an SP may use Anycast-RP or RP-tree-to-SPT switchover architectures.
ASMフレーバーが要求された場合、このモデルでは「rp」および「rp-discovery」パラメーターを入力する必要があります。 「rp-group-mappings」コンテナを使用して、複数のRPからグループへのマッピングを作成できます。各マッピングについて、SPは「プロバイダー管理/有効」リーフをtrueに設定することでRPサービスを管理できます。プロバイダーが管理するRPの場合、ユーザーはRPの冗長性や最適なトラフィック配信を要求できます。これらのパラメータは、SPが適切なテクノロジーまたはアーキテクチャを選択して顧客サービス要件を満たすのに役立ちます。たとえば、最適なトラフィック配信のリクエストの場合、SPはAnycast-RPまたはRPツリーからSPTへの切り替えアーキテクチャを使用できます。 。
In the case of a customer-managed RP, the RP address must be filled in the RP-to-group mappings using the "rp-address" leaf. This leaf is not needed for a provider-managed RP.
カスタマー管理のRPの場合、RPアドレスは、「rp-address」リーフを使用してRPからグループへのマッピングに入力する必要があります。このリーフは、プロバイダーが管理するRPには必要ありません。
Users can define a specific mechanism for RP discovery, such as the "auto-rp", "static-rp", or "bsr-rp" modes. By default, the model uses "static-rp" if ASM is requested. A single rp-discovery mechanism is allowed for the VPN. The "rp-discovery" container can be used for both provider-managed and customer-managed RPs. In the case of a provider-managed RP, if the user wants to use "bsr-rp" as a discovery protocol, an SP should consider the provider-managed "rp-group-mappings" for the "bsr-rp" configuration. The SP will then configure its selected RPs to be "bsr-rp-candidates". In the case of a customer-managed RP and a "bsr-rp" discovery mechanism, the "rp-address" provided will be the bsr-rp candidate.
ユーザーは、「auto-rp」、「static-rp」、「bsr-rp」モードなど、RPディスカバリーの特定のメカニズムを定義できます。デフォルトでは、ASMが要求された場合、モデルは「static-rp」を使用します。 VPNでは、単一のrp-discoveryメカニズムが許可されています。 「rp-discovery」コンテナは、プロバイダーが管理するRPと顧客が管理するRPの両方に使用できます。プロバイダー管理のRPの場合、ユーザーが「bsr-rp」を検出プロトコルとして使用したい場合、SPはプロバイダー管理の「rp-group-mappings」を「bsr-rp」構成と見なす必要があります。次に、SPは選択したRPを「bsr-rp-candidates」になるように構成します。カスタマー管理のRPおよび「bsr-rp」ディスカバリメカニズムの場合、提供される「rp-address」はbsr-rpの候補になります。
There are some cases where a particular VPN needs access to resources (servers, hosts, etc.) that are external. Those resources may be located in another VPN.
特定のVPNが外部のリソース（サーバー、ホストなど）にアクセスする必要がある場合があります。これらのリソースは別のVPNに配置されている場合があります。
+-----------+ +-----------+
/ \ / \
Site A -- | VPN A | --- | VPN B | --- Site B
\ / \ / (Shared
+-----------+ +-----------+ resources)
In the figure above, VPN B has some resources on Site B that need to be available to some customers/partners. VPN A must be able to access those VPN B resources.
上の図では、VPN BにはサイトBにいくつかのリソースがあり、一部の顧客/パートナーが利用できるようにする必要があります。 VPN Aは、これらのVPN Bリソースにアクセスできる必要があります。
Such a VPN connection scenario can be achieved via a VPN policy as defined in Section 6.5.2.2. But there are some simple cases where a particular VPN (VPN A) needs access to all resources in another VPN (VPN B). The model provides an easy way to set up this connection using the "extranet-vpns" container.
このようなVPN接続シナリオは、6.5.2.2項で定義されているVPNポリシーを介して実現できます。ただし、特定のVPN（VPN A）が別のVPN（VPN B）のすべてのリソースにアクセスする必要がある単純なケースがいくつかあります。このモデルは、「extranet-vpns」コンテナを使用してこの接続を設定する簡単な方法を提供します。
The extranet-vpns container defines a list of VPNs a particular VPN wants to access. The extranet-vpns container must be used on customer VPNs accessing extranet resources in another VPN. In the figure above, in order to provide VPN A with access to VPN B, the extranet-vpns container needs to be configured under VPN A with an entry corresponding to VPN B. There is no service configuration requirement on VPN B.
extranet-vpnsコンテナは、特定のVPNがアクセスしたいVPNのリストを定義します。 extranet-vpnsコンテナーは、別のVPNのエクストラネットリソースにアクセスするお客様のVPNで使用する必要があります。上の図で、VPN AにVPN Bへのアクセスを提供するには、VPN Aの下で、VPN Bに対応するエントリを使用して、extranet-vpnsコンテナーを構成する必要があります。VPNBにはサービス構成の要件はありません。
Readers should note that even if there is no configuration requirement on VPN B, if VPN A lists VPN B as an extranet, all sites in VPN B will gain access to all sites in VPN A.
読者は、VPN Bに構成要件がない場合でも、VPN AがVPN Bをエクストラネットとしてリストする場合、VPN B内のすべてのサイトがVPN A内のすべてのサイトにアクセスできることに注意する必要があります。
The "site-role" leaf defines the role of the local VPN sites in the target extranet VPN service topology. Site roles are defined in Section 6.4. Based on this, the requirements described in Section 6.4 regarding the site-role leaf are also applicable here.
「site-role」リーフは、ターゲットエクストラネットVPNサービストポロジでのローカルVPNサイトの役割を定義します。サイトの役割はセクション6.4で定義されています。これに基づいて、サイトロールリーフに関してセクション6.4で説明されている要件がここでも適用されます。
In the example below, VPN A accesses VPN B resources through an extranet connection. A Spoke role is required for VPN A sites, as sites from VPN A must not be able to communicate with each other through the extranet VPN connection.
次の例では、VPN Aはエクストラネット接続を介してVPN Bリソースにアクセスします。 VPN AのサイトはエクストラネットVPN接続を介して相互に通信できないため、VPN Aサイトにはスポークの役割が必要です。
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNB</vpn-id>
<vpn-service-topology>hub-spoke</vpn-service-topology>
</vpn-service>
<vpn-service>
<vpn-id>VPNA</vpn-id>
<vpn-service-topology>any-to-any</vpn-service-topology>
<extranet-vpns>
<extranet-vpn>
<vpn-id>VPNB</vpn-id>
<local-sites-role>spoke-role</local-sites-role>
</extranet-vpn>
</extranet-vpns>
</vpn-service>
</vpn-services>
</l3vpn-svc>
This model does not define how the extranet configuration will be achieved.
このモデルは、エクストラネット構成がどのように達成されるかを定義しません。
Any VPN interconnection scenario that is more complex (e.g., only certain parts of sites on VPN A accessing only certain parts of sites on VPN B) needs to be achieved using a VPN attachment as defined in Section 6.5.2, and especially a VPN policy as defined in Section 6.5.2.2.
より複雑なVPN相互接続シナリオ（たとえば、VPN Bのサイトの特定の部分のみにアクセスするVPN Aのサイトの特定の部分のみ）は、セクション6.5.2で定義されているVPNアタッチメント、特にVPNポリシーを使用して実現する必要があります。セクション6.5.2.2で定義されています。
A site represents a connection of a customer office to one or more VPN services. Each site is associated with one or more locations.
サイトは、1つ以上のVPNサービスへの顧客オフィスの接続を表します。各サイトは1つ以上の場所に関連付けられています。
+-------------+
/ \
+------------------+ +-----| VPN1 |
| | | \ /
| New York Office |------ (site) -----+ +-------------+
| | | +-------------+
+------------------+ | / \
+-----| VPN2 |
\ /
+-------------+
A site has several characteristics:
サイトにはいくつかの特徴があります。
o Unique identifier (site-id): uniquely identifies the site within the overall network infrastructure. The identifier is a string that allows any encoding for the local administration of the VPN service.
o 一意の識別子（サイトID）：ネットワークインフラストラクチャ全体でサイトを一意に識別します。識別子は、VPNサービスのローカル管理用のエンコーディングを許可する文字列です。
o Locations (locations): site location information that allows easy retrieval of information from the nearest available resources. A site may be composed of multiple locations. Alternatively, two or more sites can be associated with the same location, by referencing the same location ID.
o 場所（場所）：最も近い利用可能なリソースから情報を簡単に取得できるサイトの場所情報。サイトは複数の場所で構成される場合があります。あるいは、同じロケーションIDを参照することにより、2つ以上のサイトを同じロケーションに関連付けることができます。
o Devices (devices): allows the customer to request one or more customer premises equipment entities from the SP for a particular site.
o デバイス（デバイス）：特定のサイトのSPから1つ以上の顧客宅内機器エンティティを要求できます。
o Management (management): defines the type of management for the site -- for example, co-managed, customer-managed, or provider-managed. See Section 6.10.
o 管理（管理）：サイトの管理の種類を定義します（共同管理、顧客管理、プロバイダー管理など）。セクション6.10を参照してください。
o Site network accesses (site-network-accesses): defines the list of network accesses associated with the sites, and their properties -- especially bearer, connection, and service parameters.
o サイトネットワークアクセス（site-network-accesses）：サイトに関連付けられたネットワークアクセスのリストとそのプロパティ、特にベアラ、接続、サービスパラメータを定義します。
A site-network-access represents an IP logical connection of a site. A site may have multiple site-network-accesses.
site-network-accessは、サイトのIP論理接続を表します。サイトには複数のサイトネットワークアクセスがある場合があります。
+------------------+ Site
| |-----------------------------------
| |****** (site-network-access#1) ******
| New York Office |
| |****** (site-network-access#2) ******
| |-----------------------------------
+------------------+
Multiple site-network-accesses are used, for instance, in the case of multihoming. Some other meshing cases may also include multiple site-network-accesses.
たとえばマルチホーミングの場合、複数のサイトネットワークアクセスが使用されます。他のいくつかのメッシュケースには、複数のサイトネットワークアクセスが含まれる場合もあります。
The site configuration is viewed as a global entity; we assume that it is mostly the management system's role to split the parameters between the different elements within the network. For example, in the case of the site-network-access configuration, the management system needs to split the overall parameters between the PE configuration and the CE configuration.
サイト構成はグローバルエンティティとして表示されます。ネットワーク内の異なる要素間でパラメーターを分割することは、主に管理システムの役割であると想定しています。たとえば、サイトネットワークアクセス構成の場合、管理システムは全体的なパラメーターをPE構成とCE構成の間で分割する必要があります。
A site may be composed of multiple locations. All the locations will need to be configured as part of the "locations" container and list. A typical example of a multi-location site is a headquarters office in a city composed of multiple buildings. Those buildings may be located in different parts of the city and may be linked by intra-city fibers (customer metropolitan area network). In such a case, when connecting to a VPN service, the customer may ask for multihoming based on its distributed locations.
A site may be composed of multiple locations. All the locations will need to be configured as part of the "locations" container and list. A typical example of a multi-location site is a headquarters office in a city composed of multiple buildings. Those buildings may be located in different parts of the city and may be linked by intra-city fibers (customer metropolitan area network). In such a case, when connecting to a VPN service, the customer may ask for multihoming based on its distributed locations.
New York Site
ニューヨークサイト
+------------------+ Site
| +--------------+ |-----------------------------------
| | Manhattan | |****** (site-network-access#1) ******
| +--------------+ |
| +--------------+ |
| | Brooklyn | |****** (site-network-access#2) ******
| +--------------+ |
| |-----------------------------------
+------------------+
A customer may also request some premises equipment entities (CEs) from the SP via the "devices" container. Requesting a CE implies a provider-managed or co-managed model. A particular device must be ordered to a particular already-configured location. This would help the SP send the device to the appropriate postal address. In a multi-location site, a customer may, for example, request a CE for each location on the site where multihoming must be implemented. In the figure above, one device may be requested for the Manhattan location and one other for the Brooklyn location.
顧客は、「デバイス」コンテナを介してSPから一部の構内設備エンティティ（CE）を要求することもできます。 CEの要求は、プロバイダー管理モデルまたは共同管理モデルを意味します。特定のデバイスは、特定の構成済みの場所に注文する必要があります。これは、SPがデバイスを適切な住所に送信するのに役立ちます。マルチロケーションサイトでは、顧客は、たとえば、マルチホーミングを実装する必要があるサイトの各ロケーションのCEを要求できます。上の図では、マンハッタンの場所用に1つのデバイスが要求され、ブルックリンの場所用にもう1つのデバイスが要求される場合があります。
By using devices and locations, the user can influence the multihoming scenario he wants to implement: single CE, dual CE, etc.
ユーザーは、デバイスと場所を使用することで、実装したいマルチホーミングシナリオ（シングルCE、デュアルCEなど）に影響を与えることができます。
As mentioned earlier, a site may be multihomed. Each IP network access for a site is defined in the "site-network-accesses" container. The site-network-access parameter defines how the site is connected on the network and is split into three main classes of parameters:
前述のように、サイトはマルチホーム化されている場合があります。サイトの各IPネットワークアクセスは、「site-network-accesses」コンテナで定義されます。 site-network-accessパラメーターは、サイトがネットワークに接続される方法を定義し、パラメーターの3つの主要なクラスに分割されます。
o bearer: defines requirements of the attachment (below Layer 3).
o ベアラ：アタッチメントの要件を定義します（レイヤー3の下）。
o connection: defines Layer 3 protocol parameters of the attachment.
o 接続：アタッチメントのレイヤ3プロトコルパラメータを定義します。
o availability: defines the site's availability policy. The availability parameters are defined in Section 6.7.
o 可用性：サイトの可用性ポリシーを定義します。可用性パラメータはセクション6.7で定義されています。
The site-network-access has a specific type (site-network-access-type). This document defines two types:
site-network-accessには特定のタイプ（site-network-access-type）があります。このドキュメントでは、2つのタイプを定義しています。
o point-to-point: describes a point-to-point connection between the SP and the customer.
o ポイントツーポイント：SPとお客様の間のポイントツーポイント接続について説明します。
o multipoint: describes a multipoint connection between the SP and the customer.
o multipoint：SPとお客様の間のマルチポイント接続について説明します。
The type of site-network-access may have an impact on the parameters offered to the customer, e.g., an SP may not offer encryption for multipoint accesses. It is up to the provider to decide what parameter is supported for point-to-point and/or multipoint accesses; this topic is out of scope for this document. Some containers proposed in the model may require extensions in order to work properly for multipoint accesses.
サイトネットワークアクセスのタイプは、顧客に提供されるパラメーターに影響を与える可能性があります。たとえば、SPはマルチポイントアクセスの暗号化を提供しない場合があります。ポイントツーポイントおよび/またはマルチポイントアクセスでサポートされるパラメーターを決定するのはプロバイダーです。このトピックはこのドキュメントの範囲外です。モデルで提案されている一部のコンテナは、マルチポイントアクセスで適切に機能するために拡張が必要な場合があります。
The bearer container defines the requirements for the site attachment to the provider network that are below Layer 3.
ベアラーコンテナーは、レイヤー3の下にあるプロバイダーネットワークへのサイト接続の要件を定義します。
The bearer parameters will help determine the access media to be used. This is further described in Section 6.6.3.
ベアラパラメータは、使用するアクセスメディアの決定に役立ちます。これについては、6.6.3で詳しく説明します。
The "ip-connection" container defines the protocol parameters of the attachment (IPv4 and IPv6). Depending on the management mode, it refers to PE-CE addressing or CE-to-customer-LAN addressing. In any case, it describes the responsibility boundary between the provider and the customer. For a customer-managed site, it refers to the PE-CE connection. For a provider-managed site, it refers to the CE-to-LAN connection.
「ip-connection」コンテナは、アタッチメント（IPv4およびIPv6）のプロトコルパラメータを定義します。管理モードに応じて、PE-CEアドレッシングまたはCE-to-customer-LANアドレッシングを指します。いずれの場合も、プロバイダーと顧客の間の責任の境界を示します。顧客管理サイトの場合は、PE-CE接続を指します。プロバイダーが管理するサイトの場合は、CEからLANへの接続を指します。
An IP subnet can be configured for either IPv4 or IPv6 Layer 3 protocols. For a dual-stack connection, two subnets will be provided, one for each address family.
IPサブネットは、IPv4またはIPv6レイヤー3プロトコル用に構成できます。デュアルスタック接続の場合、アドレスファミリごとに1つずつ、2つのサブネットが提供されます。
The "address-allocation-type" determines how the address allocation needs to be done. The current model defines five ways to perform IP address allocation:
「address-allocation-type」は、アドレス割り当てを行う方法を決定します。現在のモデルは、IPアドレスの割り当てを実行する5つの方法を定義しています。
o provider-dhcp: The provider will provide DHCP service for customer equipment; this is applicable to either the "IPv4" container or the "IPv6" container.
o provider-dhcp：プロバイダーは顧客の機器にDHCPサービスを提供します。これは、「IPv4」コンテナまたは「IPv6」コンテナのいずれかに適用できます。
o provider-dhcp-relay: The provider will provide DHCP relay service for customer equipment; this is applicable to both IPv4 and IPv6 addressing. The customer needs to populate the DHCP server list to be used.
o provider-dhcp-relay：プロバイダーは、顧客の機器にDHCPリレーサービスを提供します。これは、IPv4とIPv6の両方のアドレス指定に適用されます。お客様は、使用するDHCPサーバーリストを入力する必要があります。
o static-address: Addresses will be assigned manually; this is applicable to both IPv4 and IPv6 addressing.
o static-address：アドレスは手動で割り当てられます。これは、IPv4とIPv6の両方のアドレス指定に適用されます。
o slaac: This parameter enables stateless address autoconfiguration [RFC4862]. This is applicable to IPv6 only.
o slaac：このパラメーターは、ステートレスアドレス自動構成を有効にします[RFC4862]。これはIPv6にのみ適用されます。
o provider-dhcp-slaac: The provider will provide DHCP service for customer equipment, as well as stateless address autoconfiguration. This is applicable to IPv6 only.
o provider-dhcp-slaac：プロバイダーは、顧客の機器にDHCPサービスを提供するとともに、ステートレスアドレス自動構成を提供します。これはIPv6にのみ適用されます。
In the dynamic addressing mechanism, the SP is expected to provide at least the IP address, prefix length, and default gateway information. In the case of multiple site-network-access points belonging to the same VPN, address space allocated for one site-network-access should not conflict with one allocated for other site-network-accesses.
動的アドレス指定メカニズムでは、SPは少なくともIPアドレス、プレフィックス長、およびデフォルトゲートウェイ情報を提供することが期待されています。同じVPNに属する複数のサイトネットワークアクセスポイントの場合、1つのサイトネットワークアクセスに割り当てられたアドレス空間は、他のサイトネットワークアクセスに割り当てられたアドレス空間と競合してはなりません。
A customer may require a specific IP connectivity fault detection mechanism on the IP connection. The model supports BFD as a fault detection mechanism. This can be extended with other mechanisms via augmentation. The provider can propose some profiles to the customer, depending on the service level the customer wants to achieve. Profile names must be communicated to the customer. This communication is out of scope for this document. Some fixed values for the holdtime period may also be imposed by the customer if the provider allows the customer this function.
お客様は、IP接続で特定のIP接続障害検出メカニズムを必要とする場合があります。モデルは、障害検出メカニズムとしてBFDをサポートしています。これは、拡張を介して他のメカニズムで拡張できます。プロバイダーは、顧客が達成したいサービスレベルに応じて、顧客にいくつかのプロファイルを提案できます。プロファイル名はお客様に伝える必要があります。この通信は、このドキュメントの範囲外です。プロバイダーが顧客にこの機能を許可する場合、ホールドタイム期間の一部の固定値も顧客によって課される場合があります。
The "oam" container can easily be augmented by other mechanisms; in particular, work done by the LIME Working Group (https://datatracker.ietf.org/wg/lime/charter/) may be reused in applicable scenarios.
「oam」コンテナは、他のメカニズムによって簡単に拡張できます。特に、LIMEワーキンググループ（https://datatracker.ietf.org/wg/lime/charter/）によって行われた作業は、該当するシナリオで再利用できます。
6.3.2.3. Inheritance of Parameters Defined at Site Level and Site Network Access Level
6.3.2.3. サイトレベルおよびサイトネットワークアクセスレベルで定義されたパラメーターの継承
Some parameters can be configured at both the site level and the site-network-access level, e.g., routing, services, security. Inheritance applies when parameters are defined at the site level. If a parameter is configured at both the site level and the access level, the access-level parameter MUST override the site-level parameter. Those parameters will be described later in this document.
一部のパラメータは、サイトレベルとサイトネットワークアクセスレベルの両方で構成できます（ルーティング、サービス、セキュリティなど）。継承は、パラメーターがサイトレベルで定義されている場合に適用されます。パラメーターがサイトレベルとアクセスレベルの両方で構成されている場合、アクセスレベルパラメーターはサイトレベルパラメーターをオーバーライドする必要があります。これらのパラメーターについては、このドキュメントの後半で説明します。
In terms of provisioning impact, it will be up to the implementation to decide on the appropriate behavior when modifying existing configurations. But the SP will need to communicate to the user about the impact of using inheritance. For example, if we consider that a site has already provisioned three site-network-accesses, what will happen if a customer changes a service parameter at the site level? An implementation of this model may update the service parameters of all already-provisioned site-network-accesses (with potential impact on live traffic), or it may take into account this new parameter only for the new sites.
プロビジョニングへの影響に関しては、既存の構成を変更するときに適切な動作を決定するのは実装次第です。ただし、SPは継承を使用することの影響についてユーザーに伝える必要があります。たとえば、サイトがすでに3つのサイトネットワークアクセスをプロビジョニングしていると考える場合、顧客がサイトレベルでサービスパラメータを変更するとどうなりますか？このモデルの実装は、すでにプロビジョニングされているすべてのサイトネットワークアクセスのサービスパラメータを更新する場合があります（ライブトラフィックに影響を与える可能性があります）。または、新しいサイトに対してのみこの新しいパラメータが考慮される場合があります。
A VPN has a particular service topology, as described in Section 6.2.1. As a consequence, each site belonging to a VPN is assigned with a particular role in this topology. The site-role leaf defines the role of the site in a particular VPN topology.
セクション6.2.1で説明されているように、VPNには特定のサービストポロジがあります。その結果、VPNに属する各サイトには、このトポロジで特定の役割が割り当てられます。サイトロールリーフは、特定のVPNトポロジにおけるサイトの役割を定義します。
In the any-to-any VPN service topology, all sites MUST have the same role, which will be "any-to-any-role".
In the any-to-any VPN service topology, all sites MUST have the same role, which will be "any-to-any-role".
In the Hub-and-Spoke VPN service topology or the Hub and Spoke disjoint VPN service topology, sites MUST have a Hub role or a Spoke role.
ハブアンドスポークVPNサービストポロジまたはハブアンドスポーク分離VPNサービストポロジでは、サイトにハブロールまたはスポークロールが必要です。
A site may be part of one or multiple VPNs. The "site-vpn-flavor" defines the way the VPN multiplexing is done. The current version of the model supports four flavors:
サイトは1つまたは複数のVPNの一部である場合があります。 「site-vpn-flavor」は、VPN多重化の方法を定義します。モデルの現在のバージョンは4つのフレーバーをサポートしています。
o site-vpn-flavor-single: The site belongs to only one VPN.
o site-vpn-flavor-single：サイトは1つのVPNにのみ属しています。
o site-vpn-flavor-multi: The site belongs to multiple VPNs, and all the logical accesses of the sites belong to the same set of VPNs.
o site-vpn-flavor-multi：サイトは複数のVPNに属し、サイトのすべての論理アクセスは同じVPNセットに属します。
o site-vpn-flavor-sub: The site belongs to multiple VPNs with multiple logical accesses. Each logical access may map to different VPNs (one or many).
o site-vpn-flavor-sub：サイトは、複数の論理アクセスを持つ複数のVPNに属しています。各論理アクセスは、異なるVPN（1つまたは複数）にマッピングできます。
o site-vpn-flavor-nni: The site represents an option A NNI.
o site-vpn-flavor-nni：サイトはオプションA NNIを表します。
The figure below describes a single VPN attachment. The site connects to only one VPN.
次の図は、単一のVPNアタッチメントを示しています。サイトは1つのVPNにのみ接続します。
+--------+
+------------------+ Site / \
| |-----------------------------| |
| |***(site-network-access#1)***| VPN1 |
| New York Office | | |
| |***(site-network-access#2)***| |
| |-----------------------------| |
+------------------+ \ /
+--------+
The figure below describes a site connected to multiple VPNs.
次の図は、複数のVPNに接続されたサイトを示しています。
+---------+
+---/----+ \
+------------------+ Site / | \ |
| |--------------------------------- | |VPN B|
| |***(site-network-access#1)******* | | |
| New York Office | | | | |
| |***(site-network-access#2)******* \ | /
| |-----------------------------| VPN A+-----|---+
+------------------+ \ /
+--------+
In the example above, the New York office is multihomed. Both logical accesses are using the same VPN attachment rules, and both are connected to VPN A and VPN B.
上記の例では、ニューヨークのオフィスはマルチホームです。両方の論理アクセスは同じVPN接続ルールを使用しており、どちらもVPN AとVPN Bに接続されています。
Reaching VPN A or VPN B from the New York office will be done via destination-based routing. Having the same destination reachable from the two VPNs may cause routing troubles. The customer administration's role in this case would be to ensure the appropriate mapping of its prefixes in each VPN.
ニューヨークオフィスからVPN AまたはVPN Bに到達するには、宛先ベースのルーティングを使用します。 2つのVPNから同じ宛先に到達できると、ルーティングの問題が発生する可能性があります。この場合の顧客管理の役割は、各VPNでのプレフィックスの適切なマッピングを確実にすることです。
The figure below describes a subVPN attachment. The site connects to multiple VPNs, but each logical access is attached to a particular set of VPNs. A typical use case for a subVPN is a customer site used by multiple affiliates with private resources for each affiliate that cannot be shared (communication between the affiliates is prevented). It is similar to having separate sites, but in the case of a SubVPN, the customer can share some physical components at a single location, while maintaining strong communication isolation between the affiliates. In this example, site-network-access#1 is attached to VPN B, while site-network-access#2 is attached to VPN A.
次の図は、subVPNアタッチメントを示しています。サイトは複数のVPNに接続しますが、各論理アクセスは特定のVPNセットに接続されます。サブVPNの一般的な使用例は、共有できないアフィリエイトごとにプライベートリソースを持つ複数のアフィリエイトが使用する顧客サイトです（アフィリエイト間の通信は禁止されています）。別個のサイトを持つことに似ていますが、SubVPNの場合、アフィリエイト間の強力な通信分離を維持しながら、顧客は1つの場所でいくつかの物理コンポーネントを共有できます。この例では、site-network-access＃1はVPN Bに接続されていますが、site-network-access＃2はVPN Aに接続されています。
+------------------+ Site +--------+
| |----------------------------------/ \
| |****(site-network-access#1)******| VPN B |
| New York Office | \ /
| | +--------+
| | +--------+
| | / \
| |****(site-network-access#2)******| VPN A |
| | \ /
| | +--------+
| |-----------------------------------
+------------------+
A multiVPN can be implemented in addition to a subVPN; as a consequence, each site-network-access can access multiple VPNs. In the example below, site-network-access#1 is mapped to VPN B and VPN C, while site-network-access#2 is mapped to VPN A and VPN D.
マルチVPNは、サブVPNに加えて実装できます。その結果、各サイトのネットワークアクセスは複数のVPNにアクセスできます。次の例では、site-network-access＃1がVPN BおよびVPN Cにマッピングされ、site-network-access＃2がVPN AおよびVPN Dにマッピングされています。
+-----------------+ Site +------+
| |--------------------------------/ +-----+
| |****(site-network-access#1)****| VPN B / \
| New York Office | \ | VPN C |
| | +-----\ /
| | +-----+
| |
| | +-------+
| | / +-----+
| |****(site-network-access#2)****| VPN A / \
| | \ | VPN D |
| | +------\ /
| |--------------------------------- +-----+
+-----------------+
Multihoming is also possible with subVPNs; in this case, site-network-accesses are grouped, and a particular group will have access to the same set of VPNs. In the example below, site-network-access#1 and site-network-access#2 are part of the same group (multihomed together) and are mapped to VPN B and VPN C; in addition, site-network-access#3 and site-network-access#4 are part of the same group (multihomed together) and are mapped to VPN A and VPN D.
サブホーミングではマルチホーミングも可能です。この場合、サイトネットワークアクセスはグループ化され、特定のグループが同じVPNセットにアクセスできます。以下の例では、site-network-access＃1とsite-network-access＃2は同じグループ（一緒にマルチホーム化）の一部であり、VPN BとVPN Cにマップされています。さらに、site-network-access＃3とsite-network-access＃4は、同じグループ（一緒にマルチホーム化）の一部であり、VPN AとVPN Dにマップされます。
+-----------------+ Site +------+
| |---------------------------------/ +-----+
| |****(site-network-access#1)*****| VPN B / \
| New York Office |****(site-network-access#2)***** \ | VPN C |
| | +-----\ /
| | +-----+
| |
| | +------+
| | / +-----+
| |****(site-network-access#3)*****| VPN A / \
| |****(site-network-access#4)***** \ | VPN D |
| | +-----\ /
| |---------------------------------- +-----+
+-----------------+
In terms of service configuration, a subVPN can be achieved by requesting that the site-network-access use the same bearer (see Section 6.6.4 for more details).
サービス構成の観点から、サブネットワークは、サイトネットワークアクセスが同じベアラを使用するように要求することで実現できます（詳細については、セクション6.6.4を参照してください）。
A Network-to-Network Interface (NNI) scenario may be modeled using the sites container (see Section 6.15.1). Using the sites container to model an NNI is only one possible option for NNIs (see Section 6.15). This option is called "option A" by reference to the option A NNI defined in [RFC4364]. It is helpful for the SP to indicate that the requested VPN connection is not a regular site but rather is an NNI, as specific default device configuration parameters may be applied in the case of NNIs (e.g., ACLs, routing policies).
ネットワーク間インターフェース（NNI）のシナリオは、サイトコンテナーを使用してモデル化できます（セクション6.15.1を参照）。サイトコンテナを使用してNNIをモデル化することは、NNIの唯一の可能なオプションです（セクション6.15を参照）。このオプションは、[RFC4364]で定義されているオプションA NNIを参照することにより、「オプションA」と呼ばれます。 NNIの場合は特定のデフォルトのデバイス構成パラメーター（ACL、ルーティングポリシーなど）が適用される可能性があるため、要求されたVPN接続が通常のサイトではなくNNIであることをSPが示すと役立ちます。
SP A SP B
------------------- -------------------
/ \ / \
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + |
| + (VRF2)---(VPN2)----(VRF2) + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + |
| + (VRF2)---(VPN2)----(VRF2) + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
The figure above describes an option A NNI scenario that can be modeled using the sites container. In order to connect its customer VPNs (VPN1 and VPN2) in SP B, SP A may request the creation of some site-network-accesses to SP B. The site-vpn-flavor-nni will be used to inform SP B that this is an NNI and not a regular customer site. The site-vpn-flavor-nni may be multihomed and multiVPN as well.
上の図は、サイトコンテナーを使用してモデル化できるオプションA NNIシナリオを示しています。 SP BでカスタマーVPN（VPN1およびVPN2）を接続するために、SP Aは、SP Bへのサイトネットワークアクセスの作成を要求する場合があります。site-vpn-flavor-nniを使用して、SP Bにこれを通知します。 NNIであり、通常の顧客サイトではありません。 site-vpn-flavor-nniは、マルチホームおよびマルチVPNの場合もあります。
Due to the multiple site-vpn flavors, the attachment of a site to an IP VPN is done at the site-network-access (logical access) level through the "vpn-attachment" container. The vpn-attachment container is mandatory. The model provides two ways to attach a site to a VPN:
複数のsite-vpnフレーバーにより、IP VPNへのサイトのアタッチは、「vpn-attachment」コンテナーを介してサイトネットワークアクセス（論理アクセス）レベルで行われます。 vpn-attachmentコンテナーは必須です。このモデルは、サイトをVPNに接続する2つの方法を提供します。
o By referencing the target VPN directly.
o ターゲットVPNを直接参照する。
o By referencing a VPN policy for attachments that are more complex.
o より複雑な添付ファイルのVPNポリシーを参照する。
A choice is implemented to allow the user to choose the flavor that provides the best fit.
選択肢は、ユーザーが最適なフレーバーを選択できるように実装されています。
Referencing a vpn-id provides an easy way to attach a particular logical access to a VPN. This is the best way in the case of a single VPN attachment or subVPN with a single VPN attachment per logical access. When referencing a vpn-id, the site-role setting must be added to express the role of the site in the target VPN service topology.
vpn-idを参照すると、特定の論理アクセスをVPNに簡単に接続できます。これは、論理アクセスごとに単一のVPNアタッチメントまたは単一のVPNアタッチメントを持つサブVPNの場合に最適な方法です。 vpn-idを参照する場合、ターゲットVPNサービストポロジでのサイトの役割を表すために、site-role設定を追加する必要があります。
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
<vpn-service>
<vpn-id>VPNB</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>LA1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>LA2</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>
The example of a corresponding XML snippet above describes a subVPN case where a site (SITE1) has two logical accesses (LA1 and LA2), with LA1 attached to VPNA and LA2 attached to VPNB.
上記の対応するXMLスニペットの例は、サイト（SITE1）に2つの論理アクセス（LA1およびLA2）があり、LA1がVPNAに接続され、LA2がVPNBに接続されているsubVPNケースを示しています。
The "vpn-policy" list helps express a multiVPN scenario where a logical access belongs to multiple VPNs. Multiple VPN policies can be created to handle the subVPN case where each logical access is part of a different set of VPNs.
「vpn-policy」リストは、論理アクセスが複数のVPNに属するmultiVPNシナリオを表現するのに役立ちます。複数のVPNポリシーを作成して、各論理アクセスが異なるVPNセットの一部であるサブVPNケースを処理できます。
As a site can belong to multiple VPNs, the vpn-policy list may be composed of multiple entries. A filter can be applied to specify that only some LANs of the site should be part of a particular VPN. Each time a site (or LAN) is attached to a VPN, the user must precisely describe its role (site-role) within the target VPN service topology.
サイトは複数のVPNに属することができるため、vpn-policyリストは複数のエントリで構成される場合があります。フィルターを適用して、サイトの一部のLANだけが特定のVPNの一部になるように指定できます。サイト（またはLAN）がVPNに接続されるたびに、ユーザーはターゲットVPNサービストポロジ内のその役割（サイトの役割）を正確に説明する必要があります。
+--------------------------------------------------------------+
| Site1 ------ PE7 |
+-------------------------+ (VPN2) |
| |
+-------------------------+ |
| Site2 ------ PE3 PE4 ------ Site3 |
+----------------------------------+ |
| |
+------------------------------------------------------------+ |
| Site4 ------ PE5 | PE6 ------ Site5 | |
| | |
| (VPN3) | |
+------------------------------------------------------------+ |
| |
+---------------------------+
In the example above, Site5 is part of two VPNs: VPN3 and VPN2. It will play a Hub role in VPN2 and an any-to-any role in VPN3. We can express such a multiVPN scenario with the following XML snippet:
上記の例では、Site5は2つのVPN、VPN3とVPN2の一部です。 VPN2でハブの役割を果たし、VPN3で多対多の役割を果たします。このようなマルチVPNシナリオは、次のXMLスニペットで表現できます。
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPN2</vpn-id>
</vpn-service>
<vpn-service>
<vpn-id>VPN3</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>Site5</site-id>
<devices>
<device>
<device-id>D1</device-id>
</device>
</devices>
<management>
<type>provider-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<vpn-policies>
<vpn-policy>
<vpn-policy-id>POLICY1</vpn-policy-id>
<entries>
<id>ENTRY1</id>
<vpn>
<vpn-id>VPN2</vpn-id>
<site-role>hub-role</site-role>
</vpn>
</entries>
<entries>
<id>ENTRY2</id>
<vpn>
<vpn-id>VPN3</vpn-id>
<site-role>any-to-any-role</site-role>
</vpn>
</entries>
</vpn-policy>
</vpn-policies>
<site-network-accesses>
<site-network-access>
<site-network-access-id>LA1</site-network-access-id>
<device-reference>D1</device-reference>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<vpn-attachment>
<vpn-policy-id>POLICY1</vpn-policy-id>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>
Now, if a more-granular VPN attachment is necessary, filtering can be used. For example, if only LAN1 from Site5 must be attached to VPN2 as a Hub and only LAN2 must be attached to VPN3, the following XML snippet can be used:
さらに詳細なVPNアタッチメントが必要な場合は、フィルタリングを使用できます。たとえば、Site5のLAN1のみをハブとしてVPN2に接続し、LAN2のみをVPN3に接続する必要がある場合、次のXMLスニペットを使用できます。
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPN2</vpn-id>
</vpn-service>
<vpn-service>
<vpn-id>VPN3</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>Site5</site-id>
<vpn-policies>
<vpn-policy>
<vpn-policy-id>POLICY1</vpn-policy-id>
<entries>
<id>ENTRY1</id>
<filters>
<filter>
<type>lan</type>
<lan-tag>LAN1</lan-tag>
</filter>
</filters>
<vpn>
<vpn-id>VPN2</vpn-id>
<site-role>hub-role</site-role>
</vpn>
</entries>
<entries>
<id>ENTRY2</id>
<filters>
<filter>
<type>lan</type>
<lan-tag>LAN2</lan-tag>
</filter>
</filters>
<vpn>
<vpn-id>VPN3</vpn-id>
<site-role>any-to-any-role</site-role>
</vpn>
</entries>
</vpn-policy>
</vpn-policies>
<site-network-accesses>
<site-network-access>
<site-network-access-id>LA1</site-network-access-id>
<vpn-attachment>
<vpn-policy-id>POLICY1</vpn-policy-id>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>
The management system will have to determine where to connect each site-network-access of a particular site to the provider network (e.g., PE, aggregation switch).
管理システムは、特定のサイトの各サイトネットワークアクセスをプロバイダーネットワーク（PE、集約スイッチなど）に接続する場所を決定する必要があります。
The current model defines parameters and constraints that can influence the meshing of the site-network-access.
現在のモデルは、サイトネットワークアクセスのメッシュに影響を与える可能性のあるパラメーターと制約を定義します。
The management system MUST honor all customer constraints, or if a constraint is too strict and cannot be fulfilled, the management system MUST NOT provision the site and MUST provide information to the user about which constraints could not be fulfilled. How the information is provided is out of scope for this document. Whether or not to relax the constraint would then be left up to the user.
The management system MUST honor all customer constraints, or if a constraint is too strict and cannot be fulfilled, the management system MUST NOT provision the site and MUST provide information to the user about which constraints could not be fulfilled. How the information is provided is out of scope for this document. Whether or not to relax the constraint would then be left up to the user.
Parameters such as site location (see Section 6.6.2) and access type are just hints (see Section 6.6.3) for the management system for service placement.
サイトの場所（セクション6.6.2を参照）やアクセスタイプなどのパラメーターは、サービス配置のための管理システムのヒント（セクション6.6.3を参照）にすぎません。
In addition to parameters and constraints, the management system's decision MAY be based on any other internal constraints that are left up to the SP: least load, distance, etc.
パラメータと制約に加えて、管理システムの決定は、SPに任されている他の内部制約（最小の負荷、距離など）に基づく場合があります。
In the case of provider management or co-management, one or more devices have been ordered by the customer to a particular already-configured location. The customer may force a particular site-network-access to be connected on a particular device that he ordered.
In the case of provider management or co-management, one or more devices have been ordered by the customer to a particular already-configured location. The customer may force a particular site-network-access to be connected on a particular device that he ordered.
New York Site
ニューヨークサイト
+------------------+ Site
| +--------------+ |-----------------------------------
| | Manhattan | |
| | CE1********* (site-network-access#1) ******
| +--------------+ |
| +--------------+ |
| | Brooklyn CE2********* (site-network-access#2) ******
| +--------------+ |
| |-----------------------------------
+------------------+
In the figure above, site-network-access#1 is associated with CE1 in the service request. The SP must ensure the provisioning of this connection.
上の図では、site-network-access＃1はサービスリクエストでCE1に関連付けられています。 SPは、この接続のプロビジョニングを保証する必要があります。
The location information provided in this model MAY be used by a management system to determine the target PE to mesh the site (SP side). A particular location must be associated with each site network access when configuring it. The SP MUST honor the termination of the access on the location associated with the site network access (customer side). The "country-code" in the site location SHOULD be expressed as an ISO ALPHA-2 code.
このモデルで提供される位置情報は、サイト（SP側）をメッシュするターゲットPEを決定するために管理システムによって使用される場合があります。特定の場所を構成するときは、各サイトのネットワークアクセスに関連付ける必要があります。 SPは、サイトネットワークアクセスに関連付けられた場所（顧客側）でのアクセスの終了を尊重する必要があります。サイトの場所の「国コード」は、ISO ALPHA-2コードとして表現する必要があります（SHOULD）。
The site-network-access location is determined by the "location-flavor". In the case of a provider-managed or co-managed site, the user is expected to configure a "device-reference" (device case) that will bind the site-network-access to a particular device that the customer ordered. As each device is already associated with a particular location, in such a case the location information is retrieved from the device location. In the case of a customer- managed site, the user is expected to configure a "location-reference" (location case); this provides a reference to an existing configured location and will help with placement.
サイトネットワークアクセスの場所は、 "location-flavor"によって決定されます。プロバイダー管理サイトまたは共同管理サイトの場合、ユーザーは、サイトネットワークアクセスを顧客が注文した特定のデバイスにバインドする「デバイス参照」（デバイスケース）を構成する必要があります。各デバイスはすでに特定の場所に関連付けられているため、このような場合、場所情報はデバイスの場所から取得されます。顧客管理サイトの場合、ユーザーは「場所の参照」（場所のケース）を構成する必要があります。これにより、既存の構成済みの場所への参照が提供され、配置に役立ちます。
POP#1 (New York)
+---------+
| PE1 |
Site #1 ---... | PE2 |
(Atlantic City) | PE3 |
+---------+
POP#2 (Washington)
+---------+
| PE4 |
| PE5 |
| PE6 |
+---------+
POP#3 (Philadelphia)
+---------+
| PE7 |
Site #2 CE#1---... | PE8 |
(Reston) | PE9 |
+---------+
In the example above, Site #1 is a customer-managed site with a location L1, while Site #2 is a provider-managed site for which a CE (CE#1) was ordered. Site #2 is configured with L2 as its location. When configuring a site-network-access for Site #1, the user will need to reference location L1 so that the management system will know that the access will need to terminate on this location. Then, for distance reasons, this management system may mesh Site #1 on a PE in the Philadelphia POP. It may also take into account resources available on PEs to determine the exact target PE (e.g., least loaded). For Site #2, the user is expected to configure the site-network-access with a device-reference to CE#1 so that the management system will know that the access must terminate on the location of CE#1 and must be connected to CE#1. For placement of the SP side of the access connection, in the case of the nearest PE used, it may mesh Site #2 on the Washington POP.
上記の例では、サイト＃1はロケーションL1の顧客管理サイトであり、サイト＃2はCE（CE＃1）が注文されたプロバイダー管理サイトです。サイト＃2は、場所としてL2を使用して構成されています。サイト＃1のサイトネットワークアクセスを構成する場合、ユーザーは場所L1を参照する必要があります。これにより、管理システムは、アクセスがこの場所で終了する必要があることを認識します。次に、距離の理由から、この管理システムはフィラデルフィアPOP内のPE上のサイト＃1をメッシュ化します。また、PEで利用可能なリソースを考慮して、正確なターゲットPE（たとえば、最小負荷）を決定する場合もあります。サイト＃2の場合、ユーザーはCE-1へのデバイス参照を使用してサイトネットワークアクセスを構成し、アクセスがCE＃1の場所で終了し、 CE＃1。アクセス接続のSP側の配置については、最も近いPEが使用されている場合、Washington POPのサイト＃2をメッシュする場合があります。
The management system needs to elect the access media to connect the site to the customer (for example, xDSL, leased line, Ethernet backhaul). The customer may provide some parameters/constraints that will provide hints to the management system.
管理システムは、サイトを顧客に接続するためのアクセスメディアを選択する必要があります（たとえば、xDSL、専用回線、イーサネットバックホール）。顧客は、管理システムにヒントを提供するいくつかのパラメーター/制約を提供する場合があります。
The bearer container information SHOULD be the first piece of information considered when making this decision:
ベアラーコンテナー情報は、この決定を行うときに考慮される最初の情報である必要があります。
o The "requested-type" parameter provides information about the media type that the customer would like to use. If the "strict" leaf is equal to "true", this MUST be considered a strict constraint so that the management system cannot connect the site with another media type. If the "strict" leaf is equal to "false" (default) and if the requested media type cannot be fulfilled, the management system can select another media type. The supported media types SHOULD be communicated by the SP to the customer via a mechanism that is out of scope for this document.
o 「requested-type」パラメータは、顧客が使用したいメディアタイプに関する情報を提供します。 「strict」リーフが「true」に等しい場合、管理システムがサイトを別のメディアタイプに接続できないように、これは厳密な制約と見なされる必要があります。 「厳密な」リーフが「false」（デフォルト）に等しく、要求されたメディアタイプを実行できない場合、管理システムは別のメディアタイプを選択できます。サポートされているメディアタイプは、このドキュメントの範囲外のメカニズムを介してSPからお客様に伝達される必要があります（SHOULD）。
o The "always-on" leaf defines a strict constraint: if set to true, the management system MUST elect a media type that is "always-on" (e.g., this means no dial access type).
o 「常にオン」のリーフは厳密な制約を定義します。trueに設定されている場合、管理システムは「常にオン」のメディアタイプを選択する必要があります（たとえば、これはダイヤルアクセスタイプがないことを意味します）。
o The "bearer-reference" parameter is used in cases where the customer has already ordered a network connection to the SP apart from the IP VPN site and wants to reuse this connection. The string used is an internal reference from the SP and describes the already-available connection. This is also a strict requirement that cannot be relaxed. How the reference is given to the customer is out of scope for this document, but as a pure example, when the customer ordered the bearer (through a process that is out of scope for this model), the SP may have provided the bearer reference that can be used for provisioning services on top.
o 「bearer-reference」パラメータは、顧客がIP VPNサイト以外にSPへのネットワーク接続をすでに注文しており、この接続を再利用したい場合に使用されます。使用される文字列は、SPからの内部参照であり、すでに利用可能な接続を記述しています。これも緩和できない厳格な要件です。顧客への参照の提供方法はこのドキュメントの範囲外ですが、純粋な例として、顧客がベアラーを注文したとき（このモデルの範囲外のプロセスを通じて）、SPはベアラー参照を提供した可能性があります上のサービスのプロビジョニングに使用できます。
Any other internal parameters from the SP can also be used. The management system MAY use other parameters, such as the requested "svc-input-bandwidth" and "svc-output-bandwidth", to help decide which access type to use.
SPの他の内部パラメータも使用できます。管理システムは、要求された「svc-input-bandwidth」や「svc-output-bandwidth」などの他のパラメーターを使用して、使用するアクセスタイプを決定する場合があります。
Each site-network-access may have one or more constraints that would drive the placement of the access. By default, the model assumes that there are no constraints, but allocation of a unique bearer per site-network-access is expected.
各サイトネットワークアクセスには、アクセスの配置を促進する1つ以上の制約があります。デフォルトでは、モデルは制約がないと想定していますが、サイトネットワークアクセスごとに一意のベアラーが割り当てられることが期待されています。
In order to help with the different placement scenarios, a site-network-access may be tagged using one or multiple group identifiers. The group identifier is a string, so it can accommodate both explicit naming of a group of sites (e.g., "multihomed-set1" or "subVPN") and the use of a numbered identifier (e.g., 12345678). The meaning of each group-id is local to each customer administrator, and the management system MUST ensure that different customers can use the same group-ids. One or more group-ids can also be defined at the site level; as a consequence, all site-network-accesses under the site MUST inherit the group-ids of the site they belong to. When, in addition to the site group-ids some group-ids are defined at the site-network-access level, the management system MUST consider the union of all groups (site level and site network access level) for this particular site-network-access.
さまざまな配置シナリオを支援するために、1つまたは複数のグループ識別子を使用して、サイトネットワークアクセスにタグを付けることができます。グループ識別子は文字列であるため、サイトのグループの明示的な名前（「multihomed-set1」や「subVPN」など）と番号付き識別子（12345678など）の使用の両方に対応できます。各グループIDの意味は、各顧客管理者にとってローカルであり、管理システムは、異なる顧客が同じグループIDを使用できるようにする必要があります。 1つ以上のグループIDをサイトレベルで定義することもできます。結果として、サイトの下のすべてのサイトネットワークアクセスは、それらが属するサイトのグループIDを継承する必要があります。サイトグループIDに加えて、一部のグループIDがサイトネットワークアクセスレベルで定義されている場合、管理システムは、この特定のサイトネットワークのすべてのグループ（サイトレベルとサイトネットワークアクセスレベル）の結合を考慮する必要があります。 -アクセス。
For an already-configured site-network-access, each constraint MUST be expressed against a targeted set of site-network-accesses. This site-network-access MUST never be taken into account in the targeted set -- for example, "My site-network-access S must not be connected on the same POP as the site-network-accesses that are part of Group 10." The set of site-network-accesses against which the constraint is evaluated can be expressed as a list of groups, "all-other-accesses", or "all-other-groups". The all-other-accesses option means that the current site-network-access constraint MUST be evaluated against all the other site-network-accesses belonging to the current site. The all-other-groups option means that the constraint MUST be evaluated against all groups that the current site-network-access does not belong to.
構成済みのサイトネットワークアクセスの場合、各制約は、サイトネットワークアクセスのターゲットセットに対して表現する必要があります。このサイトネットワークアクセスは、ターゲットセットで考慮に入れてはなりません。たとえば、「私のサイトネットワークアクセスSは、グループ10の一部であるサイトネットワークアクセスと同じPOPに接続してはなりません。 」制約が評価されるサイトネットワークアクセスのセットは、グループ、「その他すべてのアクセス」、または「その他すべてのグループ」のリストとして表すことができます。 all-other-accessesオプションは、現在のサイトネットワークアクセスの制約が、現在のサイトに属する他のすべてのサイトネットワークアクセスに対して評価されなければならないことを意味します。 all-other-groupsオプションは、現在のサイトのネットワークアクセスが属していないすべてのグループに対して制約を評価する必要があることを意味します。
The current model defines multiple constraint-types:
現在のモデルは複数の制約タイプを定義しています：
o pe-diverse: The current site-network-access MUST NOT be connected to the same PE as the targeted site-network-accesses.
o pe-diverse：現在のサイトネットワークアクセスは、ターゲットのサイトネットワークアクセスと同じPEに接続してはなりません（MUST NOT）。
o pop-diverse: The current site-network-access MUST NOT be connected to the same POP as the targeted site-network-accesses.
o pop-diverse：現在のサイトネットワークアクセスは、ターゲットサイトネットワークアクセスと同じPOPに接続してはなりません（MUST NOT）。
o linecard-diverse: The current site-network-access MUST NOT be connected to the same linecard as the targeted site-network-accesses.
o linecard-diverse：現在のsite-network-accessは、ターゲットのsite-network-accessesと同じラインカードに接続してはなりません（MUST NOT）。
o bearer-diverse: The current site-network-access MUST NOT use common bearer components compared to bearers used by the targeted site-network-accesses. "bearer-diverse" provides some level of diversity at the access level. As an example, two bearer-diverse site-network-accesses must not use the same DSLAM, BAS, or Layer 2 switch.
o bearer-diverse：現在のサイトネットワークアクセスでは、対象のサイトネットワークアクセスで使用されるベアラーと比較して、共通のベアラーコンポーネントを使用してはなりません（MUST NOT）。 「ベアラーダイバース」は、アクセスレベルである程度の多様性を提供します。例として、2つのベアラ多様なサイトネットワークアクセスで同じDSLAM、BAS、またはレイヤ2スイッチを使用しないでください。
o same-pe: The current site-network-access MUST be connected to the same PE as the targeted site-network-accesses.
o same-pe: The current site-network-access MUST be connected to the same PE as the targeted site-network-accesses.
o same-bearer: The current site-network-access MUST be connected using the same bearer as the targeted site-network-accesses.
o same-bearer：現在のサイトネットワークアクセスは、対象のサイトネットワークアクセスと同じベアラーを使用して接続する必要があります。
These constraint-types can be extended through augmentation.
これらの制約タイプは、拡張によって拡張できます。
Each constraint is expressed as "The site-network-access S must be <constraint-type> (e.g., pe-diverse, pop-diverse) from these <target> site-network-accesses."
各制約は、「これらの<target>サイトネットワークアクセスからのサイトネットワークアクセスSは<制約タイプ>（pe-diverse、pop-diverseなど）である必要があります。」として表されます。
The group-id used to target some site-network-accesses may be the same as the one used by the current site-network-access. This eases the configuration of scenarios where a group of site-network-access points has a constraint between the access points in the group. As an example, if we want a set of sites (Site#1 to Site#5) to be connected on different PEs, we can tag them with the same group-id and express a pe-diverse constraint for this group-id with the following XML snippet:
The group-id used to target some site-network-accesses may be the same as the one used by the current site-network-access. This eases the configuration of scenarios where a group of site-network-access points has a constraint between the access points in the group. As an example, if we want a set of sites (Site#1 to Site#5) to be connected on different PEs, we can tag them with the same group-id and express a pe-diverse constraint for this group-id with the following XML snippet:
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>SITE2</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
...
<site>
<site-id>SITE5</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>
The group-id used to target some site-network-accesses may also be different than the one used by the current site-network-access. This can be used to express that a group of sites has some constraints against another group of sites, but there is no constraint within the group. For example, we consider a set of six sites and two groups; we want to ensure that a site in the first group must be pop-diverse from a site in the second group. The example of a corresponding XML snippet is described as follows:
一部のサイトネットワークアクセスをターゲットにするために使用されるグループIDは、現在のサイトネットワークアクセスによって使用されるものとは異なる場合もあります。これは、サイトのグループが別のサイトのグループに対していくつかの制約を持っているが、グループ内には制約がないことを表すために使用できます。たとえば、6つのサイトと2つのグループのセットを考えます。最初のグループのサイトが2番目のグループのサイトとポップダイバースでなければならないことを確認します。対応するXMLスニペットの例は次のとおりです。
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>SITE2</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
...
<site>
<site-id>SITE5</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>SITE6</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>
Some infeasible access placement scenarios could be created via the proposed configuration framework. Such infeasible access placement scenarios could result from constraints that are too restrictive, leading to infeasible access placement in the network or conflicting constraints that would also lead to infeasible access placement. An example of conflicting rules would be to request that site-network-access#1 be pe-diverse from site-network-access#2 and to request at the same time that site-network-access#2 be on the same PE as site- network-access#1. When the management system cannot determine the placement of a site-network-access, it MUST return an error message indicating that placement was not possible.
一部の実行不可能なアクセス配置シナリオは、提案された構成フレームワークを介して作成できます。このような実行不可能なアクセス配置シナリオは、制約が厳しすぎるために、ネットワーク内の実行不可能なアクセス配置につながるか、または実行不可能なアクセス配置につながる制約と競合する可能性があります。競合するルールの例は、site-network-access＃1がsite-network-access＃2からpe-diverseであることを要求し、同時にsite-network-access＃2が同じPE上にあることを要求することです。サイトネットワークアクセス＃1。管理システムがサイトネットワークアクセスの配置を決定できない場合、配置が不可能であったことを示すエラーメッセージを返す必要があります。
The customer wants to create a multihomed site. The site will be composed of two site-network-accesses; for resiliency purposes, the customer wants the two site-network-accesses to be meshed on different POPs.
顧客はマルチホームサイトを作成したいと考えています。サイトは2つのサイトネットワークアクセスで構成されます。回復力の目的で、顧客は2つのサイトネットワークアクセスが異なるPOPでメッシュ化されることを望んでいます。
POP#1
+-------+ +---------+
| | | PE1 |
| |---site-network-access#1----| PE2 |
| | | PE3 |
| | +---------+
| Site#1|
| | POP#2
| | +---------+
| | | PE4 |
| |---site-network-access#2----| PE5 |
| | | PE6 |
| | +---------+
+-------+
This scenario can be expressed with the following XML snippet:
このシナリオは、次のXMLスニペットで表現できます。
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>2</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>
But it can also be expressed with the following XML snippet:
ただし、次のXMLスニペットで表すこともできます。
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<all-other-accesses/>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>2</site-network-access-id>
<access-diversity>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<all-other-accesses/>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>
The customer has six branch offices in a particular region, and he wants to prevent having all branch offices connected on the same PE.
特定の地域に6つの支社があり、すべての支社が同じPEに接続されないようにしたいと考えています。
He wants to express that three branch offices cannot be connected on the same linecard. Also, the other branch offices must be connected on a different POP. Those other branch offices cannot also be connected on the same linecard.
彼は、3つの支店が同じラインカードで接続できないことを表明したいと考えています。また、他の支社は別のPOPに接続する必要があります。これらの他のブランチオフィスを同じラインカードで接続することもできません。
POP#1
+---------+
| PE1 |
Office#1 ---... | PE2 |
Office#2 ---... | PE3 |
Office#3 ---... | PE4 |
+---------+
POP#2
+---------+
Office#4 ---... | PE5 |
Office#5 ---... | PE6 |
Office#6 ---... | PE7 |
+---------+
This scenario can be expressed as follows:
このシナリオは次のように表現できます。
o We need to create two groups of sites: Group#10, which is composed of Office#1, Office#2, and Office#3; and Group#20, which is composed of Office#4, Office#5, and Office#6.
o サイトの2つのグループを作成する必要があります。Group＃1は、Office＃1、Office＃2、Office＃3で構成されています。グループ＃20は、Office＃4、Office＃5、Office＃6で構成されています。
o Sites within Group#10 must be pop-diverse from sites within Group#20, and vice versa.
o Group＃10内のサイトはGroup＃20内のサイトからポップ多様である必要があり、その逆も同様です。
o Sites within Group#10 must be linecard-diverse from other sites in Group#10 (same for Group#20).
o Group＃10内のサイトは、Group＃10の他のサイトとはラインカードダイバースである必要があります（Group＃20と同じ）。
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>Office1</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office2</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office3</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office4</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office5</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office6</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>
To increase its site bandwidth at lower cost, a customer wants to order two parallel site-network-accesses that will be connected to the same PE.
低コストでサイトの帯域幅を増やすために、顧客は同じPEに接続される2つの並列サイトネットワークアクセスを注文したいと考えています。
*******site-network-access#1**********
Site 1 *******site-network-access#2********** PE1
This scenario can be expressed with the following XML snippet:
このシナリオは、次のXMLスニペットで表現できます。
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNB</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>PE-linkgrp-1</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>same-pe</constraint-type>
<target>
<group>
<group-id>PE-linkgrp-1</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>2</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>PE-linkgrp-1</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>same-pe</constraint-type>
<target>
<group>
<group-id>PE-linkgrp-1</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>
A customer has a site that is dual-homed. The dual-homing must be done on two different PEs. The customer also wants to implement two subVPNs on those multihomed accesses.
A customer has a site that is dual-homed. The dual-homing must be done on two different PEs. The customer also wants to implement two subVPNs on those multihomed accesses.
+-----------------+ Site +------+
| |---------------------------------/ +-----+
| |****(site-network-access#1)*****| VPN B / \
| New York Office |****(site-network-access#2)************| VPN C |
| | +-----\ /
| | +-----+
| |
| | +------+
| | / +-----+
| |****(site-network-access#3)*****| VPN B / \
| |****(site-network-access#4)************| VPN C |
| | +-----\ /
| |----------------------------------- +-----+
+-----------------+
This scenario can be expressed as follows:
このシナリオは次のように表現できます。
o The site will have four site network accesses (two subVPNs coupled via dual-homing).
o サイトには4つのサイトネットワークアクセスがあります（デュアルホーミングを介して結合された2つのサブVPN）。
o Site-network-access#1 and site-network-access#3 will correspond to the multihoming of subVPN B. A PE-diverse constraint is required between them.
o Site-network-access＃1とsite-network-access＃3は、subVPN Bのマルチホーミングに対応します。これらの間には、PEの多様な制約が必要です。
o Site-network-access#2 and site-network-access#4 will correspond to the multihoming of subVPN C. A PE-diverse constraint is required between them.
o Site-network-access＃2とsite-network-access＃4は、subVPN Cのマルチホーミングに対応します。それらの間には、PEの多様な制約が必要です。
o To ensure proper usage of the same bearer for the subVPN, site-network-access#1 and site-network-access#2 must share the same bearer as site-network-access#3 and site-network-access#4.
o To ensure proper usage of the same bearer for the subVPN, site-network-access#1 and site-network-access#2 must share the same bearer as site-network-access#3 and site-network-access#4.
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNB</vpn-id>
</vpn-service>
<vpn-service>
<vpn-id>VPNC</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>dualhomed-1</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>dualhomed-2</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>same-bearer</constraint-type>
<target>
<group>
<group-id>dualhomed-1</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>2</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>dualhomed-1</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>dualhomed-2</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>same-bearer</constraint-type>
<target>
<group>
<group-id>dualhomed-1</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNC</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>3</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>dualhomed-2</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>dualhomed-1</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>same-bearer</constraint-type>
<target>
<group>
<group-id>dualhomed-2</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>4</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>dualhomed-2</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>dualhomed-1</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>same-bearer</constraint-type>
<target>
<group>
<group-id>dualhomed-2</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNC</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>
The route distinguisher (RD) is a critical parameter of PE-based L3VPNs as described in [RFC4364] that provides the ability to distinguish common addressing plans in different VPNs. As for route targets (RTs), a management system is expected to allocate a VRF on the target PE and an RD for this VRF.
ルート識別子（RD）は、[RFC4364]で説明されているように、PEベースのL3VPNの重要なパラメーターであり、異なるVPNで共通のアドレス指定プランを区別する機能を提供します。ルートターゲット（RT）については、管理システムがターゲットPEにVRFを割り当て、このVRFにRDを割り当てることが期待されています。
If a VRF already exists on the target PE and the VRF fulfills the connectivity constraints for the site, there is no need to recreate another VRF, and the site MAY be meshed within this existing VRF. How the management system checks that an existing VRF fulfills the connectivity constraints for a site is out of scope for this document.
VRFがターゲットPEにすでに存在し、VRFがサイトの接続制約を満たす場合、別のVRFを再作成する必要はなく、サイトはこの既存のVRF内でメッシュ化される場合があります。既存のVRFがサイトの接続制約を満たすことを管理システムが確認する方法は、このドキュメントの範囲外です。
If no such VRF exists on the target PE, the management system has to initiate the creation of a new VRF on the target PE and has to allocate a new RD for this new VRF.
If no such VRF exists on the target PE, the management system has to initiate the creation of a new VRF on the target PE and has to allocate a new RD for this new VRF.
The management system MAY apply a per-VPN or per-VRF allocation policy for the RD, depending on the SP's policy. In a per-VPN allocation policy, all VRFs (dispatched on multiple PEs) within a VPN will share the same RD value. In a per-VRF model, all VRFs should always have a unique RD value. Some other allocation policies are also possible, and this document does not restrict the allocation policies to be used.
管理システムは、SPのポリシーに応じて、RDに対してVPNごとまたはVRFごとの割り当てポリシーを適用できます。 VPNごとの割り当てポリシーでは、VPN内のすべてのVRF（複数のPEでディスパッチされる）が同じRD値を共有します。 VRFごとのモデルでは、すべてのVRFに常に一意のRD値が必要です。他のいくつかの割り当てポリシーも可能であり、このドキュメントでは、使用する割り当てポリシーを制限していません。
The allocation of RDs MAY be done in the same way as RTs. The examples provided in Section 6.2.1.1 could be reused in this scenario.
RDの割り当ては、RTと同じ方法で行うことができます。セクション6.2.1.1で提供されている例は、このシナリオで再利用できます。
Note that an SP MAY configure a target PE for an automated allocation of RDs. In this case, there will be no need for any backend system to allocate an RD value.
SPは、RDの自動割り当て用にターゲットPEを構成する場合があることに注意してください。この場合、バックエンドシステムがRD値を割り当てる必要はありません。
A site may be multihomed, meaning that it has multiple site-network-access points. Placement constraints defined in previous sections will help ensure physical diversity.
サイトはマルチホームである場合があります。つまり、サイトには複数のサイトネットワークアクセスポイントがあります。前のセクションで定義した配置の制約は、物理的な多様性を確保するのに役立ちます。
When the site-network-accesses are placed on the network, a customer may want to use a particular routing policy on those accesses.
サイトネットワークアクセスがネットワーク上に配置されている場合、顧客はそれらのアクセスに特定のルーティングポリシーを使用することができます。
The "site-network-access/availability" container defines parameters for site redundancy. The "access-priority" leaf defines a preference for a particular access. This preference is used to model load-balancing or primary/backup scenarios. The higher the access-priority value, the higher the preference will be.
「site-network-access / availability」コンテナは、サイトの冗長性に関するパラメータを定義します。 「アクセス優先順位」リーフは、特定のアクセスの優先順位を定義します。この設定は、負荷分散またはプライマリ/バックアップのシナリオをモデル化するために使用されます。アクセス優先度の値が高いほど、優先度が高くなります。
The figure below describes how the access-priority attribute can be used.
次の図は、アクセス優先度属性の使用方法を示しています。
Hub#1 LAN (Primary/backup) Hub#2 LAN (Load-sharing)
| |
| access-priority 1 access-priority 1 |
|--- CE1 ------- PE1 PE3 --------- CE3 --- |
| |
| |
|--- CE2 ------- PE2 PE4 --------- CE4 --- |
| access-priority 2 access-priority 1 |
PE5
|
|
|
CE5
|
Spoke#1 site (Single-homed)
In the figure above, Hub#2 requires load-sharing, so all the site-network-accesses must use the same access-priority value. On the other hand, as Hub#1 requires a primary site-network-access and a backup site-network-access, a higher access-priority setting will be configured on the primary site-network-access.
上の図では、Hub＃2は負荷共有を必要とするため、すべてのサイトネットワークアクセスは同じアクセス優先度の値を使用する必要があります。一方、Hub＃1にはプライマリサイトネットワークアクセスとバックアップサイトネットワークアクセスが必要なため、プライマリサイトネットワークアクセスにはより高いアクセス優先順位設定が構成されます。
Scenarios that are more complex can be modeled. Let's consider a Hub site with five accesses to the network (A1,A2,A3,A4,A5). The customer wants to load-share its traffic on A1,A2 in the nominal situation. If A1 and A2 fail, the customer wants to load-share its traffic on A3 and A4; finally, if A1 to A4 are down, he wants to use A5. We can model this easily by configuring the following access-priority values: A1=100, A2=100, A3=50, A4=50, A5=10.
より複雑なシナリオをモデル化できます。ネットワーク（A1、A2、A3、A4、A5）への5つのアクセスを持つハブサイトについて考えてみましょう。顧客は、名目上の状況でA1、A2のトラフィックを負荷分散したいと考えています。 A1とA2に障害が発生した場合、顧客はA3とA4でトラフィックをロードシェアしたいと考えています。最後に、A1からA4がダウンしている場合、彼はA5を使用したいと考えています。これは、A1 = 100、A2 = 100、A3 = 50、A4 = 50、A5 = 10のアクセス優先度の値を設定することで簡単にモデル化できます。
The access-priority scenario has some limitations. An access-priority scenario like the previous one with five accesses but with the constraint of having traffic load-shared between A3 and A4 in the case where A1 OR A2 is down is not achievable. But the authors believe that using the access-priority attribute will cover most of the deployment use cases and that the model can still be extended via augmentation to support additional use cases.
アクセス優先シナリオにはいくつかの制限があります。前の5つのアクセスのようなアクセス優先度のシナリオですが、A1またはA2がダウンしている場合にA3とA4の間でトラフィックを負荷分散するという制約がありますが、実現できません。ただし、著者は、アクセス優先度属性を使用すると、ほとんどの展開ユースケースをカバーし、追加のユースケースをサポートするためにモデルを引き続き拡張できると考えています。
The service model supports the ability to protect the traffic for a site. Such protection provides a better level of availability in multihoming scenarios by, for example, using local-repair techniques in case of failures. The associated level of service guarantee would be based on an agreement between the customer and the SP and is out of scope for this document.
サービスモデルは、サイトのトラフィックを保護する機能をサポートします。このような保護は、たとえば、障害が発生した場合にローカル修復技術を使用することにより、マルチホーミングシナリオでより高いレベルの可用性を提供します。関連するサービス保証レベルは、お客様とSPの間の合意に基づくものであり、このドキュメントの範囲外です。
Site#1 Site#2
CE1 ----- PE1 -- P1 P3 -- PE3 ---- CE3
| | |
| | |
CE2 ----- PE2 -- P2 P4 -- PE4 ---- CE4
/
/
CE5 ----+
Site#3
In the figure above, we consider an IP VPN service with three sites, including two dual-homed sites (Site#1 and Site#2). For dual-homed sites, we consider PE1-CE1 and PE3-CE3 as primary and PE2-CE2,PE4-CE4 as backup for the example (even if protection also applies to load-sharing scenarios).
上の図では、2つのデュアルホームサイト（Site＃1とSite＃2）を含む3つのサイトを持つIP VPNサービスを検討しています。この例では、デュアルホームサイトの場合、PE1-CE1とPE3-CE3をプライマリ、PE2-CE2、PE4-CE4をバックアップと見なします（保護が負荷分散シナリオにも適用される場合でも）。
In order to protect Site#2 against a failure, a user may set the "traffic-protection/enabled" leaf to true for Site#2. How the traffic protection will be implemented is out of scope for this document. However, in such a case, we could consider traffic coming from a remote site (Site#1 or Site#3), where the primary path would use PE3 as the egress PE. PE3 may have preprogrammed a backup forwarding entry pointing to the backup path (through PE4-CE4) for all prefixes going through the PE3-CE3 link. How the backup path is computed is out of scope for this document. When the PE3-CE3 link fails, traffic is still received by PE3, but PE3 automatically switches traffic to the backup entry; the path will therefore be PE1-P1-(...)-P3-PE3-PE4-CE4 until the remote PEs reconverge and use PE4 as the egress PE.
Site＃2を障害から保護するために、ユーザーはSite＃2の「traffic-protection / enabled」リーフをtrueに設定できます。トラフィック保護の実装方法は、このドキュメントの範囲外です。ただし、そのような場合は、プライマリパスが出力PEとしてPE3を使用するリモートサイト（Site＃1またはSite＃3）からのトラフィックを考慮することができます。 PE3は、PE3-CE3リンクを通過するすべてのプレフィックスのバックアップパス（PE4-CE4を経由）を指すバックアップ転送エントリを事前にプログラムしている場合があります。バックアップパスの計算方法は、このドキュメントの範囲外です。 PE3-CE3リンクに障害が発生しても、トラフィックは引き続きPE3で受信されますが、PE3は自動的にトラフィックをバックアップエントリに切り替えます。したがって、リモートPEが再収束して出力PEとしてPE4を使用するまで、パスはPE1-P1-（...）-P3-PE3-PE4-CE4になります。
The "security" container defines customer-specific security parameters for the site. The security options supported in the model are limited but may be extended via augmentation.
「セキュリティ」コンテナは、サイトの顧客固有のセキュリティパラメータを定義します。モデルでサポートされているセキュリティオプションは制限されていますが、拡張によって拡張できます。
The current model does not support any authentication parameters for the site connection, but such parameters may be added in the "authentication" container through augmentation.
現在のモデルは、サイト接続の認証パラメーターをサポートしていませんが、そのようなパラメーターは、拡張により「認証」コンテナーに追加できます。
Traffic encryption can be requested on the connection. It may be performed at Layer 2 or Layer 3 by selecting the appropriate enumeration in the "layer" leaf. For example, an SP may use IPsec when a customer requests Layer 3 encryption. The encryption profile can be SP defined or customer specific.
接続でトラフィックの暗号化を要求できます。 「レイヤー」リーフで適切な列挙を選択することにより、レイヤー2またはレイヤー3で実行できます。たとえば、顧客がレイヤ3暗号化を要求した場合、SPはIPsecを使用できます。暗号化プロファイルは、SP定義または顧客固有にすることができます。
When an SP profile is used and a key (e.g., a pre-shared key) is allocated by the provider to be used by a customer, the SP should provide a way to communicate the key in a secured way to the customer.
SPプロファイルが使用され、キー（たとえば、事前共有キー）がプロバイダーによって顧客によって使用されるように割り当てられている場合、SPはキーを安全な方法で顧客に伝達する方法を提供する必要があります。
When a customer profile is used, the model supports only a pre-shared key for authentication of the site connection, with the pre-shared key provided through the NETCONF or RESTCONF request. A secure channel must be used to ensure that the pre-shared key cannot be intercepted.
顧客プロファイルを使用する場合、モデルはサイト接続の認証用の事前共有キーのみをサポートし、事前共有キーはNETCONFまたはRESTCONF要求を通じて提供されます。安全なチャネルを使用して、事前共有キーが傍受されないようにする必要があります。
For security reasons, it may be necessary for the customer to change the pre-shared key on a regular basis. To perform a key change, the user can ask the SP to change the pre-shared key by submitting a new pre-shared key for the site configuration (as shown below with a corresponding XML snippet). This mechanism might not be hitless.
セキュリティ上の理由から、事前共有キーを定期的に変更する必要がある場合があります。キーの変更を実行するために、ユーザーはSPにサイト構成の新しい事前共有キーを送信することで事前共有キーを変更するように要求できます（対応するXMLスニペットを使用して以下を参照）。このメカニズムはヒットレスではない可能性があります。
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<security>
<encryption>
<encryption-profile>
<preshared-key>MY_NEW_KEY</preshared-key>
</encryption-profile>
</encryption>
</security>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>
A hitless key change mechanism may be added through augmentation.
A hitless key change mechanism may be added through augmentation.
Other key-management methodologies (e.g., PKI) may be added through augmentation.
その他のキー管理方法（PKIなど）は、拡張によって追加できます。
The model defines three types of common management options:
モデルは、3つのタイプの一般的な管理オプションを定義します。
o provider-managed: The CE router is managed only by the provider. In this model, the responsibility boundary between the SP and the customer is between the CE and the customer network.
o プロバイダー管理：CEルーターはプロバイダーによってのみ管理されます。このモデルでは、SPと顧客の間の責任の境界は、CEと顧客ネットワークの間です。
o customer-managed: The CE router is managed only by the customer. In this model, the responsibility boundary between the SP and the customer is between the PE and the CE.
o 顧客管理：CEルーターは顧客のみが管理します。このモデルでは、SPと顧客の間の責任の境界は、PEとCEの間です。
o co-managed: The CE router is primarily managed by the provider; in addition, the SP allows customers to access the CE for configuration/monitoring purposes. In the co-managed mode, the responsibility boundary is the same as the responsibility boundary for the provider-managed model.
o 共同管理：CEルーターは主にプロバイダーによって管理されます。さらに、SPを使用すると、構成/監視の目的でCEにアクセスできます。共同管理モードでは、責任境界はプロバイダー管理モデルの責任境界と同じです。
Based on the management model, different security options MAY be derived.
管理モデルに基づいて、さまざまなセキュリティオプションが導出される場合があります。
In the co-managed case, the model defines options for the management address family (IPv4 or IPv6) and the associated management address.
共同管理の場合、モデルは管理アドレスファミリ（IPv4またはIPv6）および関連する管理アドレスのオプションを定義します。
"routing-protocol" defines which routing protocol must be activated between the provider and the customer router. The current model supports the following settings: bgp, rip, ospf, static, direct, and vrrp.
「routing-protocol」は、プロバイダーとカスタマールーター間でアクティブにする必要があるルーティングプロトコルを定義します。現在のモデルは、bgp、rip、ospf、static、direct、およびvrrpの設定をサポートしています。
The routing protocol defined applies at the provider-to-customer boundary. Depending on how the management model is administered, it may apply to the PE-CE boundary or the CE-to-customer boundary. In the case of a customer-managed site, the routing protocol defined will be activated between the PE and the CE router managed by the customer. In the case of a provider-managed site, the routing protocol defined will be activated between the CE managed by the SP and the router or LAN belonging to the customer. In this case, we expect the PE-CE routing to be configured based on the SP's rules, as both are managed by the same entity.
The routing protocol defined applies at the provider-to-customer boundary. Depending on how the management model is administered, it may apply to the PE-CE boundary or the CE-to-customer boundary. In the case of a customer-managed site, the routing protocol defined will be activated between the PE and the CE router managed by the customer. In the case of a provider-managed site, the routing protocol defined will be activated between the CE managed by the SP and the router or LAN belonging to the customer. In this case, we expect the PE-CE routing to be configured based on the SP's rules, as both are managed by the same entity.
Rtg protocol
192.0.2.0/24 ----- CE ----------------- PE1
Customer-managed site
顧客管理サイト
Rtg protocol
Customer router ----- CE ----------------- PE1
Provider-managed site
プロバイダーが管理するサイト
All the examples below will refer to a scenario for a customer-managed site.
以下のすべての例は、顧客管理サイトのシナリオを参照しています。
All routing protocol types support dual stack by using the "address-family" leaf-list.
すべてのルーティングプロトコルタイプは、「address-family」リーフリストを使用してデュアルスタックをサポートします。
Example of a corresponding XML snippet with dual stack using the same routing protocol:
同じルーティングプロトコルを使用するデュアルスタックを含む対応するXMLスニペットの例：
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<routing-protocols>
<routing-protocol>
<type>static</type>
<static>
<cascaded-lan-prefixes>
<ipv4-lan-prefixes>
<lan>192.0.2.0/24</lan>
<next-hop>203.0.113.1</next-hop>
</ipv4-lan-prefixes>
<ipv6-lan-prefixes>
<lan>2001:db8::1/64</lan>
<next-hop>2001:db8::2</next-hop>
</ipv6-lan-prefixes>
</cascaded-lan-prefixes>
</static>
</routing-protocol>
</routing-protocols>
</site>
</sites>
</l3vpn-svc>
Example of a corresponding XML snippet with dual stack using two different routing protocols:
2つの異なるルーティングプロトコルを使用するデュアルスタックを含む対応するXMLスニペットの例：
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<routing-protocols>
<routing-protocol>
<type>rip</type>
<rip>
<address-family>ipv4</address-family>
</rip>
</routing-protocol>
<routing-protocol>
<type>ospf</type>
<ospf>
<address-family>ipv6</address-family>
<area-address>4.4.4.4</area-address>
</ospf>
</routing-protocol>
</routing-protocols>
</site>
</sites>
</l3vpn-svc>
The routing protocol type "direct" SHOULD be used when a customer LAN is directly connected to the provider network and must be advertised in the IP VPN.
ルーティングプロトコルタイプ「direct」は、カスタマーLANがプロバイダーネットワークに直接接続されており、IP VPNでアドバタイズする必要がある場合に使用する必要があります。
LAN attached directly to provider network:
プロバイダーネットワークに直接接続されたLAN：
192.0.2.0/24 ----- PE1
In this case, the customer has a default route to the PE address.
この場合、顧客にはPEアドレスへのデフォルトルートがあります。
The routing protocol type "vrrp" SHOULD be used and advertised in the IP VPN when
ルーティングプロトコルタイプ「vrrp」は、次の場合にIP VPNで使用およびアドバタイズする必要があります（SHOULD）。
o the customer LAN is directly connected to the provider network, and
o カスタマーLANがプロバイダーネットワークに直接接続されている。
o LAN redundancy is expected.
o LANの冗長性が期待されます。
LAN attached directly to provider network with LAN redundancy:
LAN冗長性を備えたプロバイダーネットワークに直接接続されたLAN：
192.0.2.0/24 ------ PE1
|
+--- PE2
In this case, the customer has a default route to the SP network.
この場合、お客様にはSPネットワークへのデフォルトルートがあります。
The routing protocol type "static" MAY be used when a customer LAN is connected to the provider network through a CE router and must be advertised in the IP VPN. In this case, the static routes give next hops (nh) to the CE and to the PE. The customer has a default route to the SP network.
ルーティングプロトコルタイプ「静的」は、カスタマーLANがCEルーターを介してプロバイダーネットワークに接続され、IP VPNでアドバタイズされる必要がある場合に使用できます。この場合、スタティックルートは、CEとPEにネクストホップ（nh）を与えます。お客様には、SPネットワークへのデフォルトルートがあります。
Static rtg
192.0.2.0/24 ------ CE -------------- PE
| |
| Static route 192.0.2.0/24 nh CE
Static route 0.0.0.0/0 nh PE
The routing protocol type "rip" MAY be used when a customer LAN is connected to the provider network through a CE router and must be advertised in the IP VPN. For IPv4, the model assumes that RIP version 2 is used.
ルーティングプロトコルタイプ「rip」は、カスタマーLANがCEルータを介してプロバイダーネットワークに接続されており、IP VPNでアドバタイズする必要がある場合に使用できます。 IPv4の場合、モデルはRIPバージョン2が使用されることを前提としています。
In the case of dual-stack routing requested through this model, the management system will be responsible for configuring RIP (including the correct version number) and associated address families on network elements.
このモデルで要求されたデュアルスタックルーティングの場合、管理システムは、RIP（正しいバージョン番号を含む）および関連するネットワークエレメントのアドレスファミリを構成する必要があります。
RIP rtg
192.0.2.0/24 ------ CE -------------- PE
The routing protocol type "ospf" MAY be used when a customer LAN is connected to the provider network through a CE router and must be advertised in the IP VPN.
ルーティングプロトコルタイプ「ospf」は、カスタマーLANがCEルータを介してプロバイダーネットワークに接続され、IP VPNでアドバタイズされる必要がある場合に使用できます。
It can be used to extend an existing OSPF network and interconnect different areas. See [RFC4577] for more details.
既存のOSPFネットワークを拡張し、さまざまなエリアを相互接続するために使用できます。詳細については、[RFC4577]を参照してください。
+---------------------+
| |
OSPF | | OSPF
area 1 | | area 2
(OSPF | | (OSPF
area 1) --- CE ---------- PE PE ----- CE --- area 2)
| |
+---------------------+
The model also defines an option to create an OSPF sham link between two sites sharing the same area and having a backdoor link. The sham link is created by referencing the target site sharing the same OSPF area. The management system will be responsible for checking to see if there is already a sham link configured for this VPN and area between the same pair of PEs. If there is no existing sham link, the management system will provision one. This sham link MAY be reused by other sites.
このモデルは、同じエリアを共有し、バックドアリンクを持つ2つのサイト間にOSPF模造リンクを作成するオプションも定義します。模造リンクは、同じOSPFエリアを共有するターゲットサイトを参照することによって作成されます。管理システムは、このVPNと同じPEペア間のエリアに構成された模造リンクがあるかどうかを確認する責任があります。既存の模造リンクがない場合、管理システムはそれをプロビジョニングします。この偽のリンクは他のサイトで再利用できます。
+------------------------+
| |
| |
| PE (--sham link--)PE |
| | | |
+----|----------------|--+
| OSPF area 1 | OSPF area 1
| |
CE1 CE2
| |
(OSPF area 1) (OSPF area 1)
| |
+----------------+
Regarding dual-stack support, the user MAY specify both IPv4 and IPv6 address families, if both protocols should be routed through OSPF. As OSPF uses separate protocol instances for IPv4 and IPv6, the management system will need to configure both OSPF version 2 and OSPF version 3 on the PE-CE link.
デュアルスタックのサポートに関して、両方のプロトコルをOSPF経由でルーティングする必要がある場合、ユーザーはIPv4とIPv6の両方のアドレスファミリを指定できます（MAY）。 OSPFはIPv4とIPv6に個別のプロトコルインスタンスを使用するため、管理システムはPE-CEリンクでOSPFバージョン2とOSPFバージョン3の両方を構成する必要があります。
Other OSPF parameters, such as timers, are typically set by the SP and communicated to the customer outside the scope of this model.
タイマーなどの他のOSPFパラメータは通常、SPによって設定され、このモデルの範囲外の顧客に通知されます。
Example of a corresponding XML snippet with OSPF routing parameters in the service model:
Example of a corresponding XML snippet with OSPF routing parameters in the service model:
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<routing-protocols>
<routing-protocol>
<type>ospf</type>
<ospf>
<area-address>0.0.0.1</area-address>
<address-family>ipv4</address-family>
<address-family>ipv6</address-family>
</ospf>
</routing-protocol>
</routing-protocols>
</site>
</sites>
</l3vpn-svc>
Example of PE configuration done by the management system:
管理システムによって実行されるPE構成の例：
router ospf 10 area 0.0.0.1 interface Ethernet0/0 ! router ospfv3 10 area 0.0.0.1 interface Ethernet0/0 !
router ospf 10 area 0.0.0.1 interface Ethernet0 / 0！ router ospfv3 10 area 0.0.0.1 interface Ethernet0 / 0！
The routing protocol type "bgp" MAY be used when a customer LAN is connected to the provider network through a CE router and must be advertised in the IP VPN.
The routing protocol type "bgp" MAY be used when a customer LAN is connected to the provider network through a CE router and must be advertised in the IP VPN.
BGP rtg
192.0.2.0/24 ------ CE -------------- PE
The session addressing will be derived from connection parameters as well as the SP's knowledge of the addressing plan that is in use.
セッションのアドレス指定は、接続パラメーターと、使用中のアドレス指定計画に関するSPの知識から導出されます。
In the case of dual-stack access, the user MAY request BGP routing for both IPv4 and IPv6 by specifying both address families. It will be up to the SP and management system to determine how to describe the configuration (two BGP sessions, single, multi-session, etc.). This, along with other BGP parameters such as timers, is communicated to the customer outside the scope of this model.
デュアルスタックアクセスの場合、ユーザーは両方のアドレスファミリを指定することにより、IPv4とIPv6の両方のBGPルーティングを要求できます（MAY）。構成の記述方法（2つのBGPセッション、シングル、マルチセッションなど）を決定するのは、SPおよび管理システム次第です。これは、タイマーなどの他のBGPパラメータとともに、このモデルの範囲外で顧客に通知されます。
The service configuration below activates BGP on the PE-CE link for both IPv4 and IPv6.
The service configuration below activates BGP on the PE-CE link for both IPv4 and IPv6.
BGP activation requires the SP to know the address of the customer peer. If the site-network-access connection addresses are used for BGP peering, the "static-address" allocation type for the IP connection MUST be used. Other peering mechanisms are outside the scope of this model. An example of a corresponding XML snippet is described as follows:
BGPアクティベーションでは、SPがカスタマーピアのアドレスを認識している必要があります。サイトネットワークアクセス接続アドレスがBGPピアリングに使用される場合、IP接続の「静的アドレス」割り当てタイプを使用する必要があります。他のピアリングメカニズムは、このモデルの範囲外です。対応するXMLスニペットの例を以下に示します。
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<routing-protocols>
<routing-protocol>
<type>bgp</type>
<bgp>
<autonomous-system>65000</autonomous-system>
<address-family>ipv4</address-family>
<address-family>ipv6</address-family>
</bgp>
</routing-protocol>
</routing-protocols>
</site>
</sites>
</l3vpn-svc>
Depending on the SP flavor, a management system can divide this service configuration into different flavors, as shown by the following examples.
次の例に示すように、SPフレーバーに応じて、管理システムはこのサービス構成を異なるフレーバーに分割できます。
Example of PE configuration done by the management system (single IPv4 transport session):
管理システムによって行われるPE構成の例（単一のIPv4トランスポートセッション）：
router bgp 100 neighbor 203.0.113.2 remote-as 65000 address-family ipv4 vrf Cust1 neighbor 203.0.113.2 activate address-family ipv6 vrf Cust1 neighbor 203.0.113.2 activate neighbor 203.0.113.2 route-map SET-NH-IPV6 out
router bgp 100 neighbor 203.0.113.2 remote-as 65000 address-family ipv4 vrf Cust1 neighbor 203.0.113.2 activate address-family ipv6 vrf Cust1 neighbor 203.0.113.2 activate neighbor 203.0.113.2 route-map SET-NH-IPV6 out
Example of PE configuration done by the management system (two sessions):
管理システムによって行われるPE構成の例（2つのセッション）：
router bgp 100 neighbor 203.0.113.2 remote-as 65000 neighbor 2001::2 remote-as 65000 address-family ipv4 vrf Cust1 neighbor 203.0.113.2 activate address-family ipv6 vrf Cust1 neighbor 2001::2 activate
router bgp 100 neighbor 203.0.113.2 remote-as 65000 neighbor 2001 :: 2 remote-as 65000 address-family ipv4 vrf Cust1 neighbor 203.0.113.2 activate address-family ipv6 vrf Cust1 neighbor 2001 :: 2 activate
Example of PE configuration done by the management system (multi-session):
Example of PE configuration done by the management system (multi-session):
router bgp 100 neighbor 203.0.113.2 remote-as 65000 neighbor 203.0.113.2 multisession per-af address-family ipv4 vrf Cust1 neighbor 203.0.113.2 activate address-family ipv6 vrf Cust1 neighbor 203.0.113.2 activate neighbor 203.0.113.2 route-map SET-NH-IPV6 out
router bgp 100 neighbor 203.0.113.2 remote-as 65000 neighbor 203.0.113.2 multisession per-af address-family ipv4 vrf Cust1 neighbor 203.0.113.2 activate address-family ipv6 vrf Cust1 neighbor 203.0.113.2 activate neighbor 203.0.113.2 route-map SET- NH-IPV6アウト
The service defines service parameters associated with the site.
サービスは、サイトに関連付けられたサービスパラメータを定義します。
The service bandwidth refers to the bandwidth requirement between the PE and the CE (WAN link bandwidth). The requested bandwidth is expressed as svc-input-bandwidth and svc-output-bandwidth in bits per second. The input/output direction uses the customer site as a reference: "input bandwidth" means download bandwidth for the site, and "output bandwidth" means upload bandwidth for the site.
サービス帯域幅は、PEとCE間の帯域幅要件（WANリンク帯域幅）を指します。要求される帯域幅は、svc-input-bandwidthおよびsvc-output-bandwidthとしてビット/秒で表されます。入出力方向では、顧客サイトを基準として使用します。「入力帯域幅」はサイトのダウンロード帯域幅を意味し、「出力帯域幅」はサイトのアップロード帯域幅を意味します。
The service bandwidth is only configurable at the site-network-access level.
サービス帯域幅は、サイトネットワークアクセスレベルでのみ設定できます。
Using a different input and output bandwidth will allow the SP to determine if the customer allows for asymmetric bandwidth access, such as ADSL. It can also be used to set rate-limiting in a different way for uploading and downloading on a symmetric bandwidth access.
異なる入出力帯域幅を使用すると、SPは、顧客がADSLなどの非対称帯域幅アクセスを許可しているかどうかを判断できます。また、対称帯域幅アクセスでのアップロードとダウンロードの異なる方法でレート制限を設定するために使用することもできます。
The bandwidth is a service bandwidth expressed primarily as IP bandwidth, but if the customer enables MPLS for Carriers' Carriers (CsC), this becomes MPLS bandwidth.
帯域幅は、主にIP帯域幅として表現されるサービス帯域幅ですが、顧客がキャリアのキャリア（CsC）に対してMPLSを有効にすると、これがMPLS帯域幅になります。
The service MTU refers to the maximum PDU size that the customer may use. If the customer sends packets that are longer than the requested service MTU, the network may discard it (or for IPv4, fragment it).
サービスMTUは、お客様が使用できる最大PDUサイズを指します。お客様が要求されたサービスMTUよりも長いパケットを送信すると、ネットワークはそれを破棄する可能性があります（またはIPv4の場合はフラグメント化します）。
The model defines QoS parameters in an abstracted way:
モデルは、抽象化された方法でQoSパラメータを定義します。
o qos-classification-policy: policy that defines a set of ordered rules to classify customer traffic.
o qos-classification-policy：顧客のトラフィックを分類する一連の規則を定義するポリシー。
o qos-profile: QoS scheduling profile to be applied.
o qos-profile：適用されるQoSスケジューリングプロファイル。
QoS classification rules are handled by the "qos-classification-policy" container. The qos-classification-policy container is an ordered list of rules that match a flow or application and set the appropriate target class of service (target-class-id). The user can define the match using an application reference or a flow definition that is more specific (e.g., based on Layer 3 source and destination addresses, Layer 4 ports, and Layer 4 protocol). When a flow definition is used, the user can employ a "target-sites" leaf-list to identify the destination of a flow rather than using destination IP addresses. In such a case, an association between the site abstraction and the IP addresses used by this site must be done dynamically. How this association is done is out of scope for this document. The association of a site to an IP VPN is done through the "vpn-attachment" container. Therefore, the user can also employ "target-sites" leaf-list and "vpn-attachment" to identify the destination of a flow targeted to a specific VPN service. A rule that does not have a match statement is considered a match-all rule. An SP may implement a default terminal classification rule if the customer does not provide it. It will be up to the SP to determine its default target class. The current model defines some applications, but new application identities may be added through augmentation. The exact meaning of each application identity is up to the SP, so it will be necessary for the SP to advise the customer on the usage of application matching.
QoS分類ルールは、「qos-classification-policy」コンテナによって処理されます。 qos-classification-policyコンテナーは、フローまたはアプリケーションと一致し、適切なターゲットサービスクラス（target-class-id）を設定するルールの順序付きリストです。ユーザーは、アプリケーション参照またはより具体的なフロー定義（たとえば、レイヤー3の送信元アドレスと宛先アドレス、レイヤー4ポート、およびレイヤー4プロトコルに基づく）を使用して、一致を定義できます。フロー定義を使用する場合、ユーザーは「ターゲットサイト」リーフリストを使用して、宛先IPアドレスを使用するのではなく、フローの宛先を識別できます。このような場合、サイトの抽象化とこのサイトで使用されるIPアドレスとの関連付けは動的に行われる必要があります。この関連付けの方法は、このドキュメントの範囲外です。サイトとIP VPNの関連付けは、「vpn-attachment」コンテナを介して行われます。したがって、ユーザーは「target-sites」リーフリストと「vpn-attachment」を使用して、特定のVPNサービスをターゲットとするフローの宛先を特定することもできます。 matchステートメントがないルールは、全一致ルールと見なされます。 SPは、顧客が提供しない場合、デフォルトの端末分類ルールを実装できます。デフォルトのターゲットクラスを決定するのはSPです。現在のモデルではいくつかのアプリケーションが定義されていますが、拡張により新しいアプリケーションIDが追加される場合があります。各アプリケーションIDの正確な意味はSPによって異なるため、アプリケーションマッチングの使用法についてSPがお客様に通知する必要があります。
Where the classification is done depends on the SP's implementation of the service, but classification concerns the flow coming from the customer site and entering the network.
分類が行われる場所は、SPのサービスの実装によって異なりますが、分類は、顧客サイトからネットワークに入るフローに関係します。
Provider network
+-----------------------+
192.0.2.0/24
198.51.100.0/24 ---- CE --------- PE
Traffic flow
---------->
In the figure above, the management system should implement the classification rule:
In the figure above, the management system should implement the classification rule:
o in the ingress direction on the PE interface, if the CE is customer-managed.
o CEが顧客管理の場合、PEインターフェイスの入力方向。
o in the ingress direction on the CE interface connected to the customer LAN, if the CE is provider-managed.
o CEがプロバイダー管理の場合、カスタマーLANに接続されたCEインターフェイスの入力方向。
The figure below describes a sample service description of QoS classification for a site:
次の図は、サイトのQoS分類のサンプルサービスの説明です。
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<service>
<qos>
<qos-classification-policy>
<rule>
<id>SvrA-http</id>
<match-flow>
<ipv4-src-prefix>192.0.2.0/24</ipv4-src-prefix>
<ipv4-dst-prefix>203.0.113.1/32</ipv4-dst-prefix>
<l4-dst-port>80</l4-dst-port>
<protocol-type>tcp</protocol-type>
</match-flow>
<target-class-id>DATA2</target-class-id>
</rule>
<rule>
<id>SvrA-ftp</id>
<match-flow>
<ipv4-src-prefix>192.0.2.0/24</ipv4-src-prefix>
<ipv4-dst-prefix>203.0.113.1/32</ipv4-dst-prefix>
<l4-dst-port>21</l4-dst-port>
<protocol-field>tcp</protocol-field>
</match-flow>
<target-class-id>DATA2</target-class-id>
</rule>
<rule>
<id>p2p</id>
<match-application>p2p</match-application>
<target-class-id>DATA3</target-class-id>
</rule>
<rule>
<id>any</id>
<target-class-id>DATA1</target-class-id>
</rule>
</qos-classification-policy>
</qos>
</service>
</site>
</sites>
</l3vpn-svc>
In the example above:
In the example above:
o HTTP traffic from the 192.0.2.0/24 LAN destined for 203.0.113.1/32 will be classified in DATA2.
o 203.0.113.1/32宛ての192.0.2.0/24 LANからのHTTPトラフィックはDATA2に分類されます。
o FTP traffic from the 192.0.2.0/24 LAN destined for 203.0.113.1/32 will be classified in DATA2.
o 203.0.113.1/32宛ての192.0.2.0/24 LANからのFTPトラフィックはDATA2に分類されます。
o Peer-to-peer traffic will be classified in DATA3.
o ピアツーピアトラフィックはDATA3に分類されます。
o All other traffic will be classified in DATA1.
o 他のすべてのトラフィックはDATA1に分類されます。
The order of rule list entries is defined by the user. The management system responsible for translating those rules in network element configuration MUST keep the same processing order in network element configuration.
The order of rule list entries is defined by the user. The management system responsible for translating those rules in network element configuration MUST keep the same processing order in network element configuration.
The user can choose either a standard profile provided by the operator or a custom profile. The "qos-profile" container defines the traffic-scheduling policy to be used by the SP.
The user can choose either a standard profile provided by the operator or a custom profile. The "qos-profile" container defines the traffic-scheduling policy to be used by the SP.
Provider network
+-----------------------+
192.0.2.0/24
198.51.100.0/24 ---- CE --------- PE
\ /
qos-profile
A custom QoS profile is defined as a list of classes of services and associated properties. The properties are as follows:
カスタムQoSプロファイルは、サービスのクラスと関連するプロパティのリストとして定義されます。プロパティは次のとおりです。
o direction: used to specify the direction to which the QoS profile is applied. This model supports three direction settings: "Site-to-WAN", "WAN-to-Site", and "both". By default, the "both" direction value is used. If the direction is "both", the provider should ensure scheduling according to the requested policy in both traffic directions (SP to customer and customer to SP). As an example, a device-scheduling policy may be implemented on both the PE side and the CE side of the WAN link. If the direction is "WAN-to-Site", the provider should ensure scheduling from the SP network to the customer site. As an example, a device-scheduling policy may be implemented only on the PE side of the WAN link towards the customer.
o direction：QoSプロファイルが適用される方向を指定するために使用されます。このモデルは、「サイトからWAN」、「WANからサイト」、および「両方」の3つの方向設定をサポートしています。デフォルトでは、「両方」の方向の値が使用されます。方向が「両方」の場合、プロバイダーは、要求されたポリシーに従って両方のトラフィック方向（SPから顧客へ、および顧客からSP）でスケジューリングを確実にする必要があります。例として、WANリンクのPE側とCE側の両方にデバイススケジューリングポリシーを実装できます。方向が「WANからサイト」の場合、プロバイダーはSPネットワークから顧客サイトへのスケジューリングを確実にする必要があります。例として、デバイススケジューリングポリシーは、顧客に向かうWANリンクのPE側でのみ実装できます。
o rate-limit: used to rate-limit the class of service. The value is expressed as a percentage of the global service bandwidth. When the qos-profile container is implemented on the CE side, svc-output-bandwidth is taken into account as a reference. When it is implemented on the PE side, svc-input-bandwidth is used.
o レート制限：サービスクラスをレート制限するために使用されます。この値は、グローバルサービス帯域幅の割合として表されます。 qos-profileコンテナーがCE側に実装されている場合、svc-output-bandwidthが参照として考慮されます。 PE側で実装される場合、svc-input-bandwidthが使用されます。
o latency: used to define the latency constraint of the class. The latency constraint can be expressed as the lowest possible latency or a latency boundary expressed in milliseconds. How this latency constraint will be fulfilled is up to the SP's implementation of the service: a strict priority queuing may be used on the access and in the core network, and/or a low-latency routing configuration may be created for this traffic class.
o レイテンシ：クラスのレイテンシ制約を定義するために使用されます。レイテンシ制約は、最小のレイテンシまたはミリ秒で表されるレイテンシ境界として表すことができます。このレイテンシ制約がどのように満たされるかは、サービスのSPの実装次第です。アクセスとコアネットワークで完全優先キューイングを使用するか、このトラフィッククラスに低レイテンシルーティング構成を作成できます。
o jitter: used to define the jitter constraint of the class. The jitter constraint can be expressed as the lowest possible jitter or a jitter boundary expressed in microseconds. How this jitter constraint will be fulfilled is up to the SP's implementation of the service: a strict priority queuing may be used on the access and in the core network, and/or a jitter-aware routing configuration may be created for this traffic class.
o ジッタ：クラスのジッタ制約を定義するために使用されます。ジッタ制約は、可能な最小のジッタまたはマイクロ秒で表されるジッタ境界として表すことができます。このジッター制約がどのように満たされるかは、サービスのSPの実装次第です。アクセスとコアネットワークで完全優先キューイングを使用するか、ジッター対応ルーティング構成をこのトラフィッククラスに作成するか、あるいはその両方を行うことができます。
o bandwidth: used to define a guaranteed amount of bandwidth for the class of service. It is expressed as a percentage. The "guaranteed-bw-percent" parameter uses available bandwidth as a reference. When the qos-profile container is implemented on the CE side, svc-output-bandwidth is taken into account as a reference. When it is implemented on the PE side, svc-input-bandwidth is used. By default, the bandwidth reservation is only guaranteed at the access level. The user can use the "end-to-end" leaf to request an end-to-end bandwidth reservation, including across the MPLS transport network. (In other words, the SP will activate something in the MPLS core to ensure that the bandwidth request from the customer will be fulfilled by the MPLS core as well.) How this is done (e.g., RSVP reservation, controller reservation) is out of scope for this document.
o 帯域幅：サービスクラスの帯域幅の保証量を定義するために使用されます。パーセンテージで表されます。 「guaranteed-bw-percent」パラメータは、利用可能な帯域幅を参照として使用します。 qos-profileコンテナーがCE側に実装されている場合、svc-output-bandwidthが参照として考慮されます。 PE側で実装される場合、svc-input-bandwidthが使用されます。デフォルトでは、帯域幅予約はアクセスレベルでのみ保証されます。ユーザーは、「エンドツーエンド」リーフを使用して、MPLSトランスポートネットワーク全体を含むエンドツーエンドの帯域幅予約を要求できます。 （つまり、SPはMPLSコアの何かをアクティブ化して、顧客からの帯域幅要求がMPLSコアによっても確実に満たされるようにします。これを行う方法（RSVP予約、コントローラー予約など）はありませんこのドキュメントのスコープ。
In addition, due to network conditions, some constraints may not be completely fulfilled by the SP; in this case, the SP should advise the customer about the limitations. How this communication is done is out of scope for this document.
In addition, due to network conditions, some constraints may not be completely fulfilled by the SP; in this case, the SP should advise the customer about the limitations. How this communication is done is out of scope for this document.
Example of service configuration using a standard QoS profile with the following corresponding XML snippet:
次の対応するXMLスニペットで標準QoSプロファイルを使用したサービス構成の例：
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-profiles>
<valid-provider-identifiers>
<qos-profile-identifier>
<id>GOLD</id>
</qos-profile-identifier>
<qos-profile-identifier>
<id>PLATINUM</id>
</qos-profile-identifier>
</valid-provider-identifiers>
</vpn-profiles>
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1245HRTFGJGJ154654</site-network-access-id>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<service>
<svc-input-bandwidth>100000000</svc-input-bandwidth>
<svc-output-bandwidth>100000000</svc-output-bandwidth>
<svc-mtu>1514</svc-mtu>
<qos>
<qos-profile>
<profile>PLATINUM</profile>
</qos-profile>
</qos>
</service>
</site-network-access>
<site-network-access>
<site-network-access-id>555555AAAA2344</site-network-access-id>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<service>
<svc-input-bandwidth>2000000</svc-input-bandwidth>
<svc-output-bandwidth>2000000</svc-output-bandwidth>
<svc-mtu>1514</svc-mtu>
<qos>
<qos-profile>
<profile>GOLD</profile>
</qos-profile>
</qos>
</service>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>
Example of service configuration using a custom QoS profile with the following corresponding XML snippet:
次の対応するXMLスニペットでカスタムQoSプロファイルを使用したサービス構成の例：
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-profiles>
<valid-provider-identifiers>
<qos-profile-identifier>
<id>GOLD</id>
</qos-profile-identifier>
<qos-profile-identifier>
<id>PLATINUM</id>
</qos-profile-identifier>
</valid-provider-identifiers>
</vpn-profiles>
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<site-network-accesses>
<site-network-access>
<site-network-access-id>Site1</site-network-access-id>
<location-reference>L1</location-reference>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
<service>
<svc-input-bandwidth>100000000</svc-input-bandwidth>
<svc-output-bandwidth>100000000</svc-output-bandwidth>
<qos>
<qos-profile>
<classes>
<class>
<class-id>REAL_TIME</class-id>
<direction>both</direction>
<rate-limit>10</rate-limit>
<latency>
<use-lowest-latency/>
</latency>
<bandwidth>
<guaranteed-bw-percent>80</guaranteed-bw-percent>
</bandwidth>
</class>
<class>
<class-id>DATA1</class-id>
<latency>
<latency-boundary>70</latency-boundary>
</latency>
<bandwidth>
<guaranteed-bw-percent>80</guaranteed-bw-percent>
</bandwidth>
</class>
<class>
<class-id>DATA2</class-id>
<latency>
<latency-boundary>200</latency-boundary>
</latency>
<bandwidth>
<guaranteed-bw-percent>5</guaranteed-bw-percent>
<end-to-end/>
</bandwidth>
</class>
</classes>
</qos-profile>
</qos>
</service>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>
The custom QoS profile for Site1 defines a REAL_TIME class with a latency constraint expressed as the lowest possible latency. It also defines two data classes -- DATA1 and DATA2. The two classes express a latency boundary constraint as well as a bandwidth reservation, as the REAL_TIME class is rate-limited to 10% of the service bandwidth (10% of 100 Mbps = 10 Mbps). In cases where congestion occurs, the REAL_TIME traffic can go up to 10 Mbps (let's assume that only 5 Mbps are consumed). DATA1 and DATA2 will share the remaining bandwidth (95 Mbps) according to their percentage. So, the DATA1 class will be served with at least 76 Mbps of bandwidth, while the DATA2 class will be served with at least 4.75 Mbps. The latency boundary information of the data class may help the SP define a specific buffer tuning or a specific routing within the network. The maximum percentage to be used is not limited by this model but MUST be limited by the management system according to the policies authorized by the SP.
Site1のカスタムQoSプロファイルは、可能な限り低いレイテンシとして表現されたレイテンシ制約を持つREAL_TIMEクラスを定義します。また、DATA1とDATA2の2つのデータクラスも定義しています。 REAL_TIMEクラスはサービス帯域幅の10％（100 Mbpsの10％= 10 Mbps）にレート制限されているため、2つのクラスは遅延境界制約と帯域幅予約を表します。輻輳が発生した場合、REAL_TIMEトラフィックは最大10 Mbpsになる可能性があります（消費されるのは5 Mbpsだけであると想定しましょう）。 DATA1とDATA2は、残りの帯域幅（95 Mbps）を割合に応じて共有します。したがって、DATA1クラスは少なくとも76 Mbpsの帯域幅で提供され、DATA2クラスは少なくとも4.75 Mbpsで提供されます。データクラスのレイテンシ境界情報は、SPがネットワーク内の特定のバッファチューニングまたは特定のルーティングを定義するのに役立ちます。使用される最大パーセンテージはこのモデルによって制限されませんが、SPによって承認されたポリシーに従って管理システムによって制限されなければなりません（MUST）。
The "multicast" container defines the type of site in the customer multicast service topology: source, receiver, or both. These parameters will help the management system optimize the multicast service. Users can also define the type of multicast relationship with the customer: router (requires a protocol such as PIM), host (IGMP or MLD), or both. An address family (IPv4, IPv6, or both) can also be defined.
「マルチキャスト」コンテナは、顧客のマルチキャストサービストポロジ内のサイトのタイプ（ソース、レシーバ、またはその両方）を定義します。これらのパラメータは、管理システムがマルチキャストサービスを最適化するのに役立ちます。ユーザーは、顧客とのマルチキャスト関係のタイプを定義することもできます。ルーター（PIMなどのプロトコルが必要）、ホスト（IGMPまたはMLD）、あるいはその両方です。アドレスファミリ（IPv4、IPv6、またはその両方）も定義できます。
In the case of CsC [RFC4364], a customer may want to build an MPLS service using an IP VPN to carry its traffic.
CsC [RFC4364]の場合、顧客はIP VPNを使用してMPLSサービスを構築し、トラフィックを伝送することができます。
LAN customer1
|
|
CE1
|
| -------------
(vrf_cust1)
CE1_ISP1
| ISP1 POP
| MPLS link
| -------------
|
(vrf ISP1)
PE1
(...) Provider backbone
（...）プロバイダーバックボーン
PE2
(vrf ISP1)
|
| ------------
|
| MPLS link
| ISP1 POP
CE2_ISP1
(vrf_cust1)
| ------------
|
CE2
|
LAN customer1
In the figure above, ISP1 resells an IP VPN service but has no core network infrastructure between its POPs. ISP1 uses an IP VPN as the core network infrastructure (belonging to another provider) between its POPs.
上の図では、ISP1はIP VPNサービスを再販していますが、POP間にコアネットワークインフラストラクチャはありません。 ISP1は、POP間のコアネットワークインフラストラクチャ（別のプロバイダーに属する）としてIP VPNを使用します。
In order to support CsC, the VPN service must indicate MPLS support by setting the "carrierscarrier" leaf to true in the vpn-service list. The link between CE1_ISP1/PE1 and CE2_ISP1/PE2 must also run an MPLS signalling protocol. This configuration is done at the site level.
CsCをサポートするために、VPNサービスは、vpn-serviceリストで「carrierscarrier」リーフをtrueに設定して、MPLSサポートを示す必要があります。 CE1_ISP1 / PE1とCE2_ISP1 / PE2間のリンクも、MPLSシグナリングプロトコルを実行する必要があります。この構成はサイトレベルで行われます。
In the proposed model, LDP or BGP can be used as the MPLS signalling protocol. In the case of LDP, an IGP routing protocol MUST also be activated. In the case of BGP signalling, BGP MUST also be configured as the routing protocol.
提案されたモデルでは、LDPまたはBGPをMPLSシグナリングプロトコルとして使用できます。 LDPの場合、IGPルーティングプロトコルもアクティブ化する必要があります。 BGPシグナリングの場合、BGPもルーティングプロトコルとして設定する必要があります。
If CsC is enabled, the requested "svc-mtu" leaf will refer to the MPLS MTU and not to the IP MTU.
CsCが有効になっている場合、要求された「svc-mtu」リーフは、IP MTUではなくMPLS MTUを参照します。
The service model sometimes refers to external information through identifiers. As an example, to order a cloud-access to a particular cloud service provider (CSP), the model uses an identifier to refer to the targeted CSP. If a customer is directly using this service model as an API (through REST or NETCONF, for example) to order a particular service, the SP should provide a list of authorized identifiers. In the case of cloud-access, the SP will provide the associated identifiers for each available CSP. The same applies to other identifiers, such as std-qos-profile, OAM profile-name, and provider-profile for encryption.
サービスモデルは、識別子を通じて外部情報を参照する場合があります。例として、特定のクラウドサービスプロバイダー（CSP）へのクラウドアクセスを注文するために、モデルは識別子を使用して対象のCSPを参照します。顧客がこのサービスモデルをAPIとして直接（たとえばRESTまたはNETCONFを介して）使用して特定のサービスを注文する場合、SPは承認された識別子のリストを提供する必要があります。クラウドアクセスの場合、SPは、利用可能な各CSPに関連付けられた識別子を提供します。同じことが、暗号化のためのstd-qos-profile、OAMプロファイル名、プロバイダープロファイルなどの他の識別子にも当てはまります。
How an SP provides the meanings of those identifiers to the customer is out of scope for this document.
SPがこれらの識別子の意味を顧客に提供する方法は、このドキュメントの範囲外です。
An autonomous system (AS) is a single network or group of networks that is controlled by a common system administration group and that uses a single, clearly defined routing protocol. In some cases, VPNs need to span different ASes in different geographic areas or span different SPs. The connection between ASes is established by the SPs and is seamless to the customer. Examples include
自律システム（AS）は、共通のシステム管理グループによって制御され、明確に定義された単一のルーティングプロトコルを使用する単一のネットワークまたはネットワークのグループです。場合によっては、VPNは異なる地理的領域の異なるASにまたがったり、異なるSPにまたがったりする必要があります。 AS間の接続はSPによって確立され、顧客に対してシームレスです。例には、
o a partnership between SPs (e.g., carrier, cloud) to extend their VPN service seamlessly.
o VPNサービスをシームレスに拡張するためのSP（キャリア、クラウドなど）間のパートナーシップ。
o an internal administrative boundary within a single SP (e.g., backhaul versus core versus data center).
o 単一のSP内の内部管理境界（バックホールとコアとデータセンターなど）。
NNIs (network-to-network interfaces) have to be defined to extend the VPNs across multiple ASes.
VPNを複数のASに拡張するには、NNI（ネットワーク間インターフェース）を定義する必要があります。
[RFC4364] defines multiple flavors of VPN NNI implementations. Each implementation has pros and cons; this topic is outside the scope of this document. For example, in an Inter-AS option A, autonomous system border router (ASBR) peers are connected by multiple interfaces with at least one of those interfaces spanning the two ASes while being present in the same VPN. In order for these ASBRs to signal unlabeled IP prefixes, they associate each interface with a VPN routing and forwarding (VRF) instance and a Border Gateway Protocol (BGP) session. As a result, traffic between the back-to-back VRFs is IP. In this scenario, the VPNs are isolated from each other, and because the traffic is IP, QoS mechanisms that operate on IP traffic can be applied to achieve customer service level agreements (SLAs).
[RFC4364] defines multiple flavors of VPN NNI implementations. Each implementation has pros and cons; this topic is outside the scope of this document. For example, in an Inter-AS option A, autonomous system border router (ASBR) peers are connected by multiple interfaces with at least one of those interfaces spanning the two ASes while being present in the same VPN. In order for these ASBRs to signal unlabeled IP prefixes, they associate each interface with a VPN routing and forwarding (VRF) instance and a Border Gateway Protocol (BGP) session. As a result, traffic between the back-to-back VRFs is IP. In this scenario, the VPNs are isolated from each other, and because the traffic is IP, QoS mechanisms that operate on IP traffic can be applied to achieve customer service level agreements (SLAs).
-------- -------------- -----------
/ \ / \ / \
| Cloud | | | | |
| Provider |-----NNI-----| |----NNI---| Data Center |
| #1 | | | | |
\ / | | \ /
-------- | | -----------
| |
-------- | My network | -----------
/ \ | | / \
| Cloud | | | | |
| Provider |-----NNI-----| |---NNI---| L3VPN |
| #2 | | | | Partner |
\ / | | | |
-------- | | | |
\ / | |
-------------- \ /
| -----------
|
NNI
|
|
-------------------
/ \
| |
| |
| |
| L3VPN Partner |
| |
\ /
-------------------
The figure above describes an SP network called "My network" that has several NNIs. This network uses NNIs to:
上の図は、いくつかのNNIを持つ「My network」と呼ばれるSPネットワークを示しています。このネットワークはNNIを使用して次のことを行います。
o increase its footprint by relying on L3VPN partners.
o L3VPNパートナーに依存することにより、フットプリントを増やします。
o connect its own data center services to the customer IP VPN.
o 独自のデータセンターサービスをお客様のIP VPNに接続します。
o enable the customer to access its private resources located in a private cloud owned by some CSPs.
o お客様が一部のCSPが所有するプライベートクラウドにあるプライベートリソースにアクセスできるようにします。
AS A AS B
------------------- -------------------
/ \ / \
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + |
| + (VRF2)---(VPN2)----(VRF2) + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + |
| + (VRF2)---(VPN2)----(VRF2) + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
In option A, the two ASes are connected to each other with physical links on ASBRs. For resiliency purposes, there may be multiple physical connections between the ASes. A VPN connection -- physical or logical (on top of physical) -- is created for each VPN that needs to cross the AS boundary, thus providing a back-to-back VRF model.
オプションAでは、2つのASはASBR上の物理リンクで相互に接続されます。回復力の目的で、AS間に複数の物理接続がある場合があります。 VPN接続-物理的または論理的（物理的上に）-は、AS境界を越える必要がある各VPNに対して作成されるため、バックツーバックVRFモデルを提供します。
From a service model's perspective, this VPN connection can be seen as a site. Let's say that AS B wants to extend some VPN connections for VPN C on AS A. The administrator of AS B can use this service model to order a site on AS A. All connection scenarios could be realized using the features of the current model. As an example, the figure above shows two physical connections that have logical connections per VPN overlaid on them. This could be seen as a dual-homed subVPN scenario. Also, the administrator of AS B will be able to choose the appropriate routing protocol (e.g., E-BGP) to dynamically exchange routes between ASes.
サービスモデルの観点から見ると、このVPN接続はサイトと見なすことができます。 AS BがAS AのVPN Cの一部のVPN接続を拡張したいとします。ASBの管理者は、このサービスモデルを使用してAS Aのサイトを注文できます。すべての接続シナリオは、現在のモデルの機能を使用して実現できます。例として、上の図は、VPNごとの論理接続がオーバーレイされている2つの物理接続を示しています。これは、デュアルホームサブVPNシナリオと見なすことができます。また、AS Bの管理者は、適切なルーティングプロトコル（E-BGPなど）を選択して、AS間でルートを動的に交換できます。
This document assumes that the option A NNI flavor SHOULD reuse the existing VPN site modeling.
このドキュメントは、オプションA NNIフレーバーが既存のVPNサイトモデリングを再利用する必要があることを前提としています。
Example: a customer wants its CSP A to attach its virtual network N to an existing IP VPN (VPN1) that he has from L3VPN SP B.
例：お客様は、CSP Aが仮想ネットワークNをL3VPN SP Bから持っている既存のIP VPN（VPN1）に接続することを望んでいます。
CSP A L3VPN SP B
CSP A L3VPN SP B
----------------- -------------------
/ \ / \
| | | | |
| VM --| ++++++++ NNI ++++++++ |--- VPN1
| | + +_________+ + | Site#1
| |--------(VRF1)---(VPN1)--(VRF1)+ |
| | + ASBR + + ASBR + |
| | + +_________+ + |
| | ++++++++ ++++++++ |
| VM --| | | |--- VPN1
| |Virtual | | | Site#2
| |Network | | |
| VM --| | | |--- VPN1
| | | | | Site#3
\ / \ /
----------------- -------------------
|
|
VPN1
Site#4
To create the VPN connectivity, the CSP or the customer may use the L3VPN service model that SP B exposes. We could consider that, as the NNI is shared, the physical connection (bearer) between CSP A and SP B already exists. CSP A may request through a service model the creation of a new site with a single site-network-access (single-homing is used in the figure). As a placement constraint, CSP A may use the existing bearer reference it has from SP A to force the placement of the VPN NNI on the existing link. The XML snippet below illustrates a possible configuration request to SP B:
VPN接続を作成するために、CSPまたは顧客は、SP Bが公開するL3VPNサービスモデルを使用できます。 NNIが共有されているため、CSP AとSP Bの間に物理的な接続（ベアラ）が既に存在していると考えることができます。 CSP Aは、サービスモデルを通じて、単一のサイトネットワークアクセスを持つ新しいサイトの作成を要求できます（図ではシングルホーミングが使用されています）。配置の制約として、CSP AはSP Aから持っている既存のベアラ参照を使用して、既存のリンクにVPN NNIを強制的に配置できます。以下のXMLスニペットは、SP Bへの可能な構成リクエストを示しています。
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-profiles>
<valid-provider-identifiers>
<qos-profile-identifier>
<id>GOLD</id>
</qos-profile-identifier>
<qos-profile-identifier>
<id>PLATINUM</id>
</qos-profile-identifier>
</valid-provider-identifiers>
</vpn-profiles>
<vpn-services>
<vpn-service>
<vpn-id>VPN1</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>CSP_A_attachment</site-id>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<locations>
<location>
<location-id>1</location-id>
<city>NY</city>
<country-code>US</country-code>
</location>
</locations>
<site-vpn-flavor>site-vpn-flavor-nni</site-vpn-flavor>
<routing-protocols>
<routing-protocol>
<type>bgp</type>
<bgp>
<autonomous-system>500</autonomous-system>
<address-family>ipv4</address-family>
</bgp>
</routing-protocol>
</routing-protocols>
<site-network-accesses>
<site-network-access>
<site-network-access-id>CSP_A_VN1</site-network-access-id>
<location-reference>L1</location-reference>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<ip-connection>
<ipv4>
<address-allocation-type>static-address</address-allocation-type>
<addresses>
<provider-address>203.0.113.1</provider-address>
<customer-address>203.0.113.2</customer-address>
<prefix-length>30</prefix-length>
</addresses>
</ipv4>
</ip-connection>
<service>
<svc-input-bandwidth>450000000</svc-input-bandwidth>
<svc-output-bandwidth>450000000</svc-output-bandwidth>
<svc-mtu>1514</svc-mtu>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<vpn-attachment>
<vpn-id>VPN1</vpn-id>
<site-role>any-to-any-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
<management>
<type>customer-managed</type>
</management>
</site>
</sites>
</l3vpn-svc>
The case described above is different from a scenario using the cloud-accesses container, as the cloud-access provides a public cloud access while this example enables access to private resources located in a CSP network.
The case described above is different from a scenario using the cloud-accesses container, as the cloud-access provides a public cloud access while this example enables access to private resources located in a CSP network.
AS A AS B
------------------- -------------------
/ \ / \
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR +<---MP-BGP---->+ ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR +<---MP-BGP---->+ ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
In option B, the two ASes are connected to each other with physical links on ASBRs. For resiliency purposes, there may be multiple physical connections between the ASes. The VPN "connection" between ASes is done by exchanging VPN routes through MP-BGP [RFC4760].
オプションBでは、2つのASがASBR上の物理リンクで相互に接続されます。回復力の目的で、AS間に複数の物理接続がある場合があります。 AS間のVPNの「接続」は、MP-BGP [RFC4760]を介してVPNルートを交換することによって行われます。
There are multiple flavors of implementations of such an NNI. For example:
このようなNNIの実装には、さまざまな種類があります。例えば：
1. The NNI is internal to the provider and is situated between a backbone and a data center. There is enough trust between the domains to not filter the VPN routes. So, all the VPN routes are exchanged. RT filtering may be implemented to save some unnecessary route states.
1. NNIはプロバイダーの内部にあり、バックボーンとデータセンターの間にあります。ドメイン間に十分な信頼があり、VPNルートをフィルタリングしません。したがって、すべてのVPNルートが交換されます。 RTフィルタリングを実装して、いくつかの不要なルート状態を保存できます。
2. The NNI is used between providers that agreed to exchange VPN routes for specific RTs only. Each provider is authorized to use the RT values from the other provider.
2. NNIは、特定のRTのみのVPNルートを交換することに同意したプロバイダー間で使用されます。各プロバイダーは、他のプロバイダーからのRT値を使用することを許可されています。
3. The NNI is used between providers that agreed to exchange VPN routes for specific RTs only. Each provider has its own RT scheme. So, a customer spanning the two networks will have different RTs in each network for a particular VPN.
3. NNIは、特定のRTのみのVPNルートを交換することに同意したプロバイダー間で使用されます。各プロバイダーには独自のRTスキームがあります。したがって、2つのネットワークにまたがるお客様は、特定のVPNの各ネットワークで異なるRTを使用します。
Case 1 does not require any service modeling, as the protocol enables the dynamic exchange of necessary VPN routes.
ケース1では、プロトコルによって必要なVPNルートの動的な交換が可能になるため、サービスのモデリングは必要ありません。
Case 2 requires that an RT-filtering policy on ASBRs be maintained. From a service modeling point of view, it is necessary to agree on the list of RTs to authorize.
ケース2では、ASBRのRTフィルタリングポリシーを維持する必要があります。サービスモデリングの観点からは、認証するRTのリストについて合意する必要があります。
In Case 3, both ASes need to agree on the VPN RT to exchange, as well as how to map a VPN RT from AS A to the corresponding RT in AS B (and vice versa).
ケース3では、両方のASが、交換するVPN RTと、AS AからのVPN RTをAS Bの対応するRT（およびその逆）にマッピングする方法について合意する必要があります。
Those modelings are currently out of scope for this document.
それらのモデリングは現在、このドキュメントの範囲外です。
CSP A L3VPN SP B
CSP A L3VPN SP B
----------------- ------------------
/ \ / \
| | | | |
| VM --| ++++++++ NNI ++++++++ |--- VPN1
| | + +__________+ + | Site#1
| |-------+ + + + |
| | + ASBR +<-MP-BGP->+ ASBR + |
| | + +__________+ + |
| | ++++++++ ++++++++ |
| VM --| | | |--- VPN1
| |Virtual | | | Site#2
| |Network | | |
| VM --| | | |--- VPN1
| | | | | Site#3
\ / | |
----------------- | |
\ /
------------------
|
|
VPN1
Site#4
The example above describes an NNI connection between CSP A and SP network B. Both SPs do not trust themselves and use a different RT allocation policy. So, in terms of implementation, the customer VPN has a different RT in each network (RT A in CSP A and RT B in SP network B). In order to connect the customer virtual network in CSP A to the customer IP VPN (VPN1) in SP network B, CSP A should request that SP network B open the customer VPN on the NNI (accept the appropriate RT). Who does the RT translation depends on the agreement between the two SPs: SP B may permit CSP A to request VPN (RT) translation.
上記の例は、CSP AとSPネットワークB間のNNI接続を示しています。両方のSPは自分自身を信頼せず、異なるRT割り当てポリシーを使用します。したがって、実装の面では、カスタマーVPNには各ネットワークで異なるRTがあります（CSP AのRT AおよびSPネットワークBのRT B）。 CSP Aのカスタマー仮想ネットワークをSPネットワークBのカスタマーIP VPN（VPN1）に接続するには、CSPネットワークBがNNIでカスタマーVPNを開くようにCSP Aに要求する必要があります（適切なRTを受け入れます）。誰がRT変換を行うかは、2つのSP間の合意に依存します。SPBは、CSP AがVPN（RT）変換を要求することを許可する場合があります。
AS A AS B
------------------- -------------------
/ \ / \
| | | |
| | | |
| | | |
| ++++++++ Multihop E-BGP ++++++++ |
| + + + + |
| + + + + |
| + RGW +<----MP-BGP---->+ RGW + |
| + + + + |
| + + + + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
From a VPN service's perspective, the option C NNI is very similar to option B, as an MP-BGP session is used to exchange VPN routes between the ASes. The difference is that the forwarding plane and the control plane are on different nodes, so the MP-BGP session is multihop between routing gateway (RGW) nodes.
VPNサービスの観点から見ると、MP-BGPセッションがAS間でVPNルートを交換するために使用されるため、オプションC NNIはオプションBと非常に似ています。違いは、転送プレーンとコントロールプレーンが異なるノード上にあるため、MP-BGPセッションはルーティングゲートウェイ（RGW）ノード間のマルチホップであることです。
From a VPN service's point of view, modeling options B and C will be identical.
VPNサービスの観点からは、モデリングオプションBとCは同じになります。
As explained in Section 5, this service model is intended to be instantiated at a management layer and is not intended to be used directly on network elements. The management system serves as a central point of configuration of the overall service.
セクション5で説明したように、このサービスモデルは管理層でインスタンス化されることを意図しており、ネットワーク要素で直接使用することを意図していません。管理システムは、サービス全体の構成の中心点として機能します。
This section provides an example of how a management system can use this model to configure an IP VPN service on network elements.
このセクションでは、管理システムがこのモデルを使用してネットワーク要素にIP VPNサービスを構成する方法の例を示します。
In this example, we want to achieve the provisioning of a VPN service for three sites using a Hub-and-Spoke VPN service topology. One of the sites will be dual-homed, and load-sharing is expected.
この例では、ハブアンドスポークVPNサービストポロジを使用して、3つのサイトのVPNサービスのプロビジョニングを実現します。サイトの1つはデュアルホームになり、負荷分散が期待されます。
+-------------------------------------------------------------+
| Hub_Site ------ PE1 PE2 ------ Spoke_Site1 |
| | +----------------------------------+
| | |
| | +----------------------------------+
| Hub_Site ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+
The following XML snippet describes the overall simplified service configuration of this VPN.
次のXMLスニペットは、このVPNの全体的な簡略化されたサービス構成を示しています。
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-profiles>
<valid-provider-identifiers>
<qos-profile-identifier>
<id>GOLD</id>
</qos-profile-identifier>
<qos-profile-identifier>
<id>PLATINUM</id>
</qos-profile-identifier>
</valid-provider-identifiers>
</vpn-profiles>
<vpn-services>
<vpn-service>
<vpn-id>12456487</vpn-id>
<vpn-service-topology>hub-spoke</vpn-service-topology>
</vpn-service>
</vpn-services>
</l3vpn-svc>
When receiving the request for provisioning the VPN service, the management system will internally (or through communication with another OSS component) allocate VPN RTs. In this specific case, two RTs will be allocated (100:1 for Hub and 100:2 for Spoke). The output of corresponding XML snippet below describes the configuration of Spoke_Site1.
VPNサービスのプロビジョニング要求を受信すると、管理システムは内部で（または別のOSSコンポーネントとの通信を介して）VPN RTを割り当てます。この特定のケースでは、2つのRTが割り当てられます（ハブには100：1、スポークには100：2）。以下の対応するXMLスニペットの出力は、Spoke_Site1の構成を示しています。
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-profiles>
<valid-provider-identifiers>
<qos-profile-identifier>
<id>GOLD</id>
</qos-profile-identifier>
<qos-profile-identifier>
<id>PLATINUM</id>
</qos-profile-identifier>
</valid-provider-identifiers>
</vpn-profiles>
<vpn-services>
<vpn-service>
<vpn-id>12456487</vpn-id>
<vpn-service-topology>hub-spoke</vpn-service-topology>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>Spoke_Site1</site-id>
<devices>
<device>
<device-id>D1</device-id>
</device>
</devices>
<locations>
<location>
<location-id>1</location-id>
<city>NY</city>
<country-code>US</country-code>
</location>
</locations>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<routing-protocols>
<routing-protocol>
<type>bgp</type>
<bgp>
<autonomous-system>500</autonomous-system>
<address-family>ipv4</address-family>
<address-family>ipv6</address-family>
</bgp>
</routing-protocol>
</routing-protocols>
<site-network-accesses>
<site-network-access>
<site-network-access-id>Spoke_Site1</site-network-access-id>
<device-reference>D1</device-reference>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<ip-connection>
<ipv4>
<address-allocation-type>static-address</address-allocation-type>
<addresses>
<provider-address>203.0.113.254</provider-address>
<customer-address>203.0.113.2</customer-address>
<prefix-length>24</prefix-length>
</addresses>
</ipv4>
<ipv6>
<address-allocation-type>static-address</address-allocation-type>
<addresses>
<provider-address>2001:db8::1</provider-address>
<customer-address>2001:db8::2</customer-address>
<prefix-length>64</prefix-length>
</addresses>
</ipv6>
</ip-connection>
<service>
<svc-input-bandwidth>450000000</svc-input-bandwidth>
<svc-output-bandwidth>450000000</svc-output-bandwidth>
<svc-mtu>1514</svc-mtu>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<vpn-attachment>
<vpn-id>12456487</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
<management>
<type>provider-managed</type>
</management>
</site>
</sites>
</l3vpn-svc>
When receiving the request for provisioning Spoke_Site1, the management system MUST allocate network resources for this site. It MUST first determine the target network elements to provision the access, particularly the PE router (and perhaps also an aggregation switch). As described in Section 6.6, the management system SHOULD use the location information and MUST use the access-diversity constraint to find the appropriate PE. In this case, we consider that Spoke_Site1 requires PE diversity with the Hub and that the management system allocates PEs based on the least distance. Based on the location information, the management system finds the available PEs in the area nearest the customer and picks one that fits the access-diversity constraint.
Spoke_Site1のプロビジョニング要求を受信すると、管理システムはこのサイトにネットワークリソースを割り当てる必要があります。最初に、アクセスをプロビジョニングするターゲットネットワークエレメント、特にPEルータ（およびおそらく集約スイッチ）を決定する必要があります。セクション6.6で説明されているように、管理システムは位置情報を使用する必要があり（SHOULD）、適切なPEを見つけるためにアクセス多様性制約を使用しなければなりません（MUST）。この場合、Spoke_Site1にはハブでのPEダイバーシティが必要であり、管理システムは最小距離に基づいてPEを割り当てると考えます。管理システムは、ロケーション情報に基づいて、顧客に最も近いエリアで利用可能なPEを見つけ、アクセス多様性の制約に適合するものを選択します。
When the PE is chosen, the management system needs to allocate interface resources on the node. One interface is selected from the pool of available PEs. The management system can start provisioning the chosen PE node via whatever means the management system prefers (e.g., NETCONF, CLI). The management system will check to see if a VRF that fits its needs is already present. If not, it will provision the VRF: the RD will be derived from the internal allocation policy model, and the RTs will be derived from the VPN policy configuration of the site (the management system allocated some RTs for the VPN). As the site is a Spoke site (site-role), the management system knows which RTs must be imported and exported. As the site is provider-managed, some management RTs may also be added (100:5000). Standard provider VPN policies MAY also be added in the configuration.
PEを選択すると、管理システムはノードにインターフェースリソースを割り当てる必要があります。使用可能なPEのプールから1つのインターフェイスが選択されます。管理システムは、選択したPEノードのプロビジョニングを、管理システムが好む手段（NETCONF、CLIなど）を介して開始できます。管理システムは、ニーズに合ったVRFがすでに存在するかどうかを確認します。そうでない場合は、VRFをプロビジョニングします。RDは内部割り当てポリシーモデルから派生し、RTはサイトのVPNポリシー構成から派生します（管理システムはVPNにいくつかのRTを割り当てました）。サイトはスポークサイト（サイトロール）であるため、管理システムはどのRTをインポートおよびエクスポートする必要があるかを認識しています。サイトはプロバイダーによって管理されているため、一部の管理RTも追加できます（100：5000）。標準プロバイダーVPNポリシーも構成に追加される場合があります。
Example of generated PE configuration:
生成されたPE構成の例：
ip vrf Customer1
export-map STD-CUSTOMER-EXPORT <---- Standard SP configuration
route-distinguisher 100:3123234324
route-target import 100:1
route-target import 100:5000 <---- Standard SP configuration
route-target export 100:2 for provider-managed CE
!
When the VRF has been provisioned, the management system can start configuring the access on the PE using the allocated interface information. IP addressing is chosen by the management system. One address will be picked from an allocated subnet for the PE, and another will be used for the CE configuration. Routing protocols will also be configured between the PE and CE; because this model is provider-managed, the choices are left to the SP. BGP was chosen for this example. This choice is independent of the routing protocol chosen by the customer. BGP will be used to configure the CE-to-LAN connection as requested in the service model. Peering addresses will be derived from those of the connection. As the CE is provider-managed, the CE's AS number can be automatically allocated by the management system. Standard configuration templates provided by the SP may also be added.
VRFがプロビジョニングされると、管理システムは、割り当てられたインターフェイス情報を使用して、PEへのアクセスの設定を開始できます。 IPアドレッシングは、管理システムによって選択されます。 1つのアドレスはPEに割り当てられたサブネットから選択され、別のアドレスはCE構成に使用されます。ルーティングプロトコルは、PEとCEの間でも構成されます。このモデルはプロバイダーが管理するため、選択はSPに委ねられます。この例ではBGPが選択されています。この選択は、お客様が選択したルーティングプロトコルとは無関係です。 BGPは、サービスモデルで要求されたとおりにCE-to-LAN接続を構成するために使用されます。ピアリングアドレスは、接続のアドレスから取得されます。 CEはプロバイダーが管理するため、CEのAS番号は管理システムによって自動的に割り当てられます。 SPによって提供される標準構成テンプレートも追加できます。
Example of generated PE configuration:
生成されたPE構成の例：
interface Ethernet1/1/0.10
encapsulation dot1q 10
ip vrf forwarding Customer1
ip address 198.51.100.1 255.255.255.252 <---- Comes from
automated allocation
ipv6 address 2001:db8::10:1/64
ip access-group STD-PROTECT-IN <---- Standard SP config
!
router bgp 100
address-family ipv4 vrf Customer1
neighbor 198.51.100.2 remote-as 65000 <---- Comes from
automated allocation
neighbor 198.51.100.2 route-map STD in <---- Standard SP config
neighbor 198.51.100.2 filter-list 10 in <---- Standard SP config
!
address-family ipv6 vrf Customer1
neighbor 2001:db8::0a10:2 remote-as 65000 <---- Comes from
automated allocation
neighbor 2001:db8::0a10:2 route-map STD in <---- Standard SP
config
neighbor 2001:db8::0a10:2 filter-list 10 in <---- Standard SP
config
!
ip route vrf Customer1 192.0.2.1 255.255.255.255 198.51.100.2
! Static route for provider administration of CE
!
As the CE router is not reachable at this stage, the management system can produce a complete CE configuration that can be manually uploaded to the node before sending the CE configuration to the customer premises. The CE configuration will be built in the same way as the PE would be configured. Based on the CE type (vendor/ model) allocated to the customer as well as the bearer information, the management system knows which interface must be configured on the CE. PE-CE link configuration is expected to be handled automatically using the SP OSS, as both resources are managed internally. CE-to-LAN-interface parameters such as IP addressing are derived from the ip-connection container, taking into account how the management system distributes addresses between the PE and CE within the subnet. This will allow a plug-and-play configuration for the CE to be created.
この段階ではCEルーターに到達できないため、管理システムは完全なCE構成を生成でき、CE構成を顧客の構内に送信する前にノードに手動でアップロードできます。 CE構成は、PEの構成と同じ方法で構築されます。管理システムは、顧客に割り当てられたCEタイプ（ベンダー/モデル）とベアラ情報に基づいて、CEで構成する必要のあるインターフェースを認識します。 PE-CEリンク構成は、両方のリソースが内部で管理されるため、SP OSSを使用して自動的に処理されることが期待されています。管理システムがサブネット内のPEとCEの間でアドレスを分散する方法を考慮して、IPアドレッシングなどのCE-to-LANインターフェースパラメーターはip-connectionコンテナーから取得されます。これにより、CEのプラグアンドプレイ構成を作成できます。
Example of generated CE configuration:
生成されたCE構成の例：
interface Loopback10
description "Administration"
ip address 192.0.2.1 255.255.255.255
!
interface FastEthernet10
description "WAN"
ip address 198.51.100.2 255.255.255.252 <---- Comes from
automated allocation
ipv6 address 2001:db8::0a10:2/64
!
interface FastEthernet11
description "LAN"
ip address 203.0.113.254 255.255.255.0 <---- Comes from the
ip-connection container
ipv6 address 2001:db8::1/64
!
router bgp 65000
address-family ipv4
redistribute static route-map STATIC2BGP <---- Standard SP
configuration
neighbor 198.51.100.1 remote-as 100 <---- Comes from
automated allocation
neighbor 203.0.113.2 remote-as 500 <---- Comes from the
ip-connection container
address-family ipv6
redistribute static route-map STATIC2BGP <---- Standard SP
configuration
neighbor 2001:db8::0a10:1 remote-as 100 <---- Comes from
automated allocation
neighbor 2001:db8::2 remote-as 500 <---- Comes from the
ip-connection container
!
route-map STATIC2BGP permit 10
match tag 10
!
As expressed in Section 5, this service model is intended to be instantiated in a management system and not directly on network elements.
セクション5で説明されているように、このサービスモデルは、ネットワーク要素で直接ではなく、管理システムでインスタンス化されることを目的としています。
The management system's role will be to configure the network elements. The management system may be modular, so the component instantiating the service model (let's call it "service component") and the component responsible for network element configuration (let's call it "configuration component") may be different.
管理システムの役割は、ネットワーク要素を構成することです。管理システムはモジュール式であるため、サービスモデルをインスタンス化するコンポーネント（「サービスコンポーネント」と呼びましょう）とネットワーク要素の構成を担当するコンポーネント（「構成コンポーネント」と呼びましょう）は異なる場合があります。
l3vpn-svc |
Model |
|
+---------------------+
| Service component | Service datastore
+---------------------+
|
|
+---------------------+
+----| Config component |------+
/ +---------------------+ \ Network
/ / \ \ Configuration
/ / \ \ models
/ / \ \
++++++++ ++++++++ ++++++++ ++++++++
+ CE A + ------- + PE A + + PE B + ----- + CE B + Config
++++++++ ++++++++ ++++++++ ++++++++ datastore
Site A Site B
サイトAサイトB
In the previous sections, we provided some examples of the translation of service provisioning requests to router configuration lines. In the NETCONF/YANG ecosystem, we expect NETCONF/YANG to be used between the configuration component and network elements to configure the requested services on those elements.
前のセクションでは、サービスプロビジョニング要求をルーター構成行に変換する例をいくつか示しました。 NETCONF / YANGエコシステムでは、構成コンポーネントとネットワーク要素の間でNETCONF / YANGを使用して、これらの要素で要求されたサービスを構成する必要があります。
In this framework, specifications are expected to provide specific YANG modeling of service components on network elements. There will be a strong relationship between the abstracted view provided by this service model and the detailed configuration view that will be provided by specific configuration models for network elements.
このフレームワークでは、仕様はネットワーク要素上のサービスコンポーネントの特定のYANGモデリングを提供することが期待されています。このサービスモデルによって提供される抽象化されたビューと、ネットワーク要素の特定の構成モデルによって提供される詳細な構成ビューの間には、強い関係があります。
The authors of this document anticipate definitions of YANG modules for the network elements listed below. Note that this list is not exhaustive:
このドキュメントの作成者は、以下にリストされているネットワーク要素のYANGモジュールの定義を予想しています。このリストは完全なものではないことに注意してください。
o VRF definition, including VPN policy expression.
o VPNポリシー式を含むVRF定義。
o Physical interface.
o 物理インターフェイス。
o IP layer (IPv4, IPv6).
o IPレイヤー（IPv4、IPv6）。
o QoS: classification, profiles, etc.
o QoS：分類、プロファイルなど
o Routing protocols: support of configuration of all protocols listed in the document, as well as routing policies associated with those protocols.
o ルーティングプロトコル：ドキュメントに記載されているすべてのプロトコルの構成のサポート、およびそれらのプロトコルに関連付けられたルーティングポリシー。
o Multicast VPN.
o マルチキャストVPN。
o Network address translation.
o ネットワークアドレス変換。
Example of a corresponding XML snippet with a VPN site request at the service level, using this model:
このモデルを使用した、サービスレベルでのVPNサイト要求を含む対応するXMLスニペットの例：
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-profiles>
<valid-provider-identifiers>
<qos-profile-identifier>
<id>GOLD</id>
</qos-profile-identifier>
<qos-profile-identifier>
<id>PLATINUM</id>
</qos-profile-identifier>
</valid-provider-identifiers>
</vpn-profiles>
<vpn-services>
<vpn-service>
<vpn-id>VPN1</vpn-id>
<vpn-service-topology>hub-spoke</vpn-service-topology>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>Site A</site-id>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>static-address</address-allocation-type>
<addresses>
<provider-address>203.0.113.254</provider-address>
<customer-address>203.0.113.2</customer-address>
<prefix-length>24</prefix-length>
</addresses>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<location-reference>L1</location-reference>
<vpn-attachment>
<vpn-policy-id>VPNPOL1</vpn-policy-id>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
<routing-protocols>
<routing-protocol>
<type>static</type>
<static>
<cascaded-lan-prefixes>
<ipv4-lan-prefixes>
<lan>198.51.100.0/30</lan>
<next-hop>203.0.113.2</next-hop>
</ipv4-lan-prefixes>
</cascaded-lan-prefixes>
</static>
</routing-protocol>
</routing-protocols>
<management>
<type>customer-managed</type>
</management>
<vpn-policies>
<vpn-policy>
<vpn-policy-id>VPNPOL1</vpn-policy-id>
<entries>
<id>1</id>
<vpn>
<vpn-id>VPN1</vpn-id>
<site-role>any-to-any-role</site-role>
</vpn>
</entries>
</vpn-policy>
</vpn-policies>
</site>
</sites>
</l3vpn-svc>
In the service example above, the service component is expected to request that the configuration component of the management system provide the configuration of the service elements. If we consider that the service component selected a PE (PE A) as the target PE for the site, the configuration component will need to push the configuration to PE A. The configuration component will use several YANG data models to define the configuration to be applied to PE A. The XML snippet configuration of PE A might look like this:
上記のサービス例では、サービスコンポーネントは、管理システムの構成コンポーネントがサービス要素の構成を提供することを要求することが期待されています。サービスコンポーネントがサイトのターゲットPEとしてPE（PE A）を選択したと考える場合、構成コンポーネントは構成をPE Aにプッシュする必要があります。構成コンポーネントはいくつかのYANGデータモデルを使用して構成を定義しますPE Aに適用されます。PEAのXMLスニペット構成は次のようになります。
<if:interfaces>
<if:interface>
<if:name>eth0</if:name>
<if:type>ianaift:ethernetCsmacd</if:type>
<if:description>
Link to CE A.
</if:description>
<ip:ipv4>
<ip:address>
<ip:ip>203.0.113.254</ip:ip>
<ip:prefix-length>24</ip:prefix-length>
</ip:address>
<ip:forwarding>true</ip:forwarding>
</ip:ipv4>
</if:interface>
</if:interfaces>
<rt:routing>
<rt:routing-instance>
<rt:name>VRF_CustA</rt:name>
<rt:type>l3vpn-network:vrf</rt:type>
<rt:description>VRF for Customer A</rt:description>
<l3vpn-network:rd>100:1546542343</l3vpn-network:rd>
<l3vpn-network:import-rt>100:1</l3vpn-network:import-rt>
<l3vpn-network:export-rt>100:1</l3vpn-network:export-rt>
<rt:interfaces>
<rt:interface>
<rt:name>eth0</rt:name>
</rt:interface>
</rt:interfaces>
<rt:routing-protocols>
<rt:routing-protocol>
<rt:type>rt:static</rt:type>
<rt:name>st0</rt:name>
<rt:static-routes>
<v4ur:ipv4>
<v4ur:route>
<v4ur:destination-prefix>198.51.100.0/30</v4ur:destination-prefix>
<v4ur:next-hop>
<v4ur:next-hop-address>203.0.113.2</v4ur:next-hop-address>
</v4ur:next-hop>
</v4ur:route>
</v4ur:ipv4>
</rt:static-routes>
</rt:routing-protocol>
</rt:routing-protocols>
</rt:routing-instance>
</rt:routing>
<CODE BEGINS>file "ietf-l3vpn-svc@2018-01-19.yang"
module ietf-l3vpn-svc {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
prefix l3vpn-svc;
import ietf-inet-types {
prefix inet;
}
import ietf-yang-types {
prefix yang;
}
import ietf-netconf-acm {
prefix nacm;
}
organization
"IETF L3SM Working Group";
contact
"WG List: <mailto:l3sm@ietf.org>
Editor:
L3SM WG
Chairs:
Adrian Farrel, Qin Wu
";
description
"This YANG module defines a generic service configuration
model for Layer 3 VPNs. This model is common across all
vendor implementations.
Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2018 IETF Trustおよびコードの作成者として識別された人物。全著作権所有。
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 Simplified 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文書に関連するIETFトラストの法的規定のセクション4.cに記載されているSimplified BSD Licenseに従い、それに含まれるライセンス条項に従って許可されます（ https://trustee.ietf.org/license-info）。
This version of this YANG module is part of RFC 8299; see the RFC itself for full legal notices.";
このYANGモジュールのこのバージョンはRFC 8299の一部です。完全な法的通知については、RFC自体を参照してください。 ";
revision 2018-01-19 {
description
"Revision of RFC 8049 to fix implementation issues.";
reference
"RFC 8299";
}
revision 2017-01-27 {
description
"Initial document.";
reference
"RFC 8049.";
}
/* Features */
feature cloud-access {
description
"Allows the VPN to connect to a CSP.";
}
feature multicast {
description
"Enables multicast capabilities in a VPN.";
}
feature ipv4 {
description
"Enables IPv4 support in a VPN.";
}
feature ipv6 {
description
"Enables IPv6 support in a VPN.";
}
feature lan-tag {
description
"Enables LAN Tag support in a VPN Policy filter.";
}
feature carrierscarrier {
description
"Enables support of CsC.";
}
feature extranet-vpn {
description
"Enables support of extranet VPNs.";
}
feature site-diversity {
description
"Enables support of site diversity constraints.";
}
feature encryption {
description
"Enables support of encryption.";
}
feature qos {
description
"Enables support of classes of services.";
}
feature qos-custom {
description
"Enables support of the custom QoS profile.";
}
feature rtg-bgp {
description
"Enables support of the BGP routing protocol.";
}
feature rtg-rip {
description
"Enables support of the RIP routing protocol.";
}
feature rtg-ospf {
description
"Enables support of the OSPF routing protocol.";
}
feature rtg-ospf-sham-link {
description
"Enables support of OSPF sham links.";
}
feature rtg-vrrp {
description
"Enables support of the VRRP routing protocol.";
}
feature fast-reroute {
description
"Enables support of Fast Reroute.";
}
feature bfd {
description
"Enables support of BFD.";
}
feature always-on {
description
"Enables support of the 'always-on' access constraint.";
}
feature requested-type {
description
"Enables support of the 'requested-type' access constraint.";
}
feature bearer-reference {
description
"Enables support of the 'bearer-reference' access constraint.";
}
feature target-sites {
description
"Enables support of the 'target-sites' match flow parameter.";
}
/* Typedefs */
typedef svc-id {
type string;
description
"Defines a type of service component identifier.";
}
typedef template-id {
type string;
description
"Defines a type of service template identifier.";
}
typedef address-family {
type enumeration {
enum ipv4 {
description
"IPv4 address family.";
}
enum ipv6 {
description
"IPv6 address family.";
}
}
description
"Defines a type for the address family.";
}
/* Identities */
identity site-network-access-type {
description
"Base identity for site-network-access type.";
}
identity point-to-point {
base site-network-access-type;
description
"Identity for point-to-point connection.";
}
identity multipoint {
base site-network-access-type;
description
"Identity for multipoint connection.
Example: Ethernet broadcast segment.";
}
identity placement-diversity {
description
"Base identity for site placement constraints.";
}
identity bearer-diverse {
base placement-diversity;
description
"Identity for bearer diversity.
The bearers should not use common elements.";
}
identity pe-diverse {
base placement-diversity;
description
"Identity for PE diversity.";
}
identity pop-diverse {
base placement-diversity;
description
"Identity for POP diversity.";
}
identity linecard-diverse {
base placement-diversity;
description
"Identity for linecard diversity.";
}
identity same-pe {
base placement-diversity;
description
"Identity for having sites connected on the same PE.";
}
identity same-bearer {
base placement-diversity;
description
"Identity for having sites connected using the same bearer.";
}
identity customer-application {
description
"Base identity for customer application.";
}
identity web {
base customer-application;
description
"Identity for Web application (e.g., HTTP, HTTPS).";
}
identity mail {
base customer-application;
description
"Identity for mail application.";
}
identity file-transfer {
base customer-application;
description
"Identity for file transfer application (e.g., FTP, SFTP).";
}
identity database {
base customer-application;
description
"Identity for database application.";
}
identity social {
base customer-application;
description
"Identity for social-network application.";
}
identity games {
base customer-application;
description
"Identity for gaming application.";
}
identity p2p {
base customer-application;
description
"Identity for peer-to-peer application.";
}
identity network-management {
base customer-application;
description
"Identity for management application
(e.g., Telnet, syslog, SNMP).";
}
identity voice {
base customer-application;
description
"Identity for voice application.";
}
identity video {
base customer-application;
description
"Identity for video conference application.";
}
identity embb {
base customer-application;
description
"Identity for an enhanced Mobile Broadband (eMBB)
application. Note that an eMBB application demands
network performance with a wide variety of
characteristics, such as data rate, latency,
loss rate, reliability, and many other parameters.";
}
identity urllc {
base customer-application;
description
"Identity for an Ultra-Reliable and Low Latency
Communications (URLLC) application. Note that a
URLLC application demands network performance
with a wide variety of characteristics, such as latency,
reliability, and many other parameters.";
}
identity mmtc {
base customer-application;
description
"Identity for a massive Machine Type
Communications (mMTC) application. Note that an
mMTC application demands network performance
with a wide variety of characteristics, such as data
rate, latency, loss rate, reliability, and many
other parameters.";
}
identity site-vpn-flavor {
description
"Base identity for the site VPN service flavor.";
}
identity site-vpn-flavor-single {
base site-vpn-flavor;
description
"Base identity for the site VPN service flavor.
Used when the site belongs to only one VPN.";
}
identity site-vpn-flavor-multi {
base site-vpn-flavor;
description
"Base identity for the site VPN service flavor.
Used when a logical connection of a site
belongs to multiple VPNs.";
}
identity site-vpn-flavor-sub {
base site-vpn-flavor;
description
"Base identity for the site VPN service flavor.
Used when a site has multiple logical connections.
Each connection may belong to different multiple VPNs.";
}
identity site-vpn-flavor-nni {
base site-vpn-flavor;
description
"Base identity for the site VPN service flavor.
Used to describe an NNI option A connection.";
}
identity management {
description
"Base identity for site management scheme.";
}
identity co-managed {
base management;
description
"Base identity for co-managed site.";
}
identity customer-managed {
base management;
description
"Base identity for customer-managed site.";
}
identity provider-managed {
base management;
description
"Base identity for provider-managed site.";
}
identity address-allocation-type {
description
"Base identity for address-allocation-type for PE-CE link.";
}
identity provider-dhcp {
base address-allocation-type;
description
"Provider network provides DHCP service to customer.";
}
identity provider-dhcp-relay {
base address-allocation-type;
description
"Provider network provides DHCP relay service to customer.";
}
identity provider-dhcp-slaac {
base address-allocation-type;
description
"Provider network provides DHCP service to customer,
as well as SLAAC.";
}
identity static-address {
base address-allocation-type;
description
"Provider-to-customer addressing is static.";
}
identity slaac {
base address-allocation-type;
description
"Use IPv6 SLAAC.";
}
identity site-role {
description
"Base identity for site type.";
}
identity any-to-any-role {
base site-role;
description
"Site in an any-to-any IP VPN.";
}
identity spoke-role {
base site-role;
description
"Spoke site in a Hub-and-Spoke IP VPN.";
}
identity hub-role {
base site-role;
description
"Hub site in a Hub-and-Spoke IP VPN.";
}
identity vpn-topology {
description
"Base identity for VPN topology.";
}
identity any-to-any {
base vpn-topology;
description
"Identity for any-to-any VPN topology.";
}
identity hub-spoke {
base vpn-topology;
description
"Identity for Hub-and-Spoke VPN topology.";
}
identity hub-spoke-disjoint {
base vpn-topology;
description
"Identity for Hub-and-Spoke VPN topology
where Hubs cannot communicate with each other.";
}
identity multicast-tree-type {
description
"Base identity for multicast tree type.";
}
identity ssm-tree-type {
base multicast-tree-type;
description
"Identity for SSM tree type.";
}
identity asm-tree-type {
base multicast-tree-type;
description
"Identity for ASM tree type.";
}
identity bidir-tree-type {
base multicast-tree-type;
description
"Identity for bidirectional tree type.";
}
identity multicast-rp-discovery-type {
description
"Base identity for RP discovery type.";
}
identity auto-rp {
base multicast-rp-discovery-type;
description
"Base identity for Auto-RP discovery type.";
}
identity static-rp {
base multicast-rp-discovery-type;
description
"Base identity for static type.";
}
identity bsr-rp {
base multicast-rp-discovery-type;
description
"Base identity for BSR discovery type.";
}
identity routing-protocol-type {
description
"Base identity for routing protocol type.";
}
identity ospf {
base routing-protocol-type;
description
"Identity for OSPF protocol type.";
}
identity bgp {
base routing-protocol-type;
description
"Identity for BGP protocol type.";
}
identity static {
base routing-protocol-type;
description
"Identity for static routing protocol type.";
}
identity rip {
base routing-protocol-type;
description
"Identity for RIP protocol type.";
}
identity vrrp {
base routing-protocol-type;
description
"Identity for VRRP protocol type.
This is to be used when LANs are directly connected
to PE routers.";
}
identity direct {
base routing-protocol-type;
description
"Identity for direct protocol type.";
}
identity protocol-type {
description
"Base identity for protocol field type.";
}
identity tcp {
base protocol-type;
description
"TCP protocol type.";
}
identity udp {
base protocol-type;
description
"UDP protocol type.";
}
identity icmp {
base protocol-type;
description
"ICMP protocol type.";
}
identity icmp6 {
base protocol-type;
description
"ICMPv6 protocol type.";
}
identity gre {
base protocol-type;
description
"GRE protocol type.";
}
identity ipip {
base protocol-type;
description
"IP-in-IP protocol type.";
}
identity hop-by-hop {
base protocol-type;
description
"Hop-by-Hop IPv6 header type.";
}
identity routing {
base protocol-type;
description
"Routing IPv6 header type.";
}
identity esp {
base protocol-type;
description
"ESP header type.";
}
identity ah {
base protocol-type;
description
"AH header type.";
}
identity vpn-policy-filter-type {
description
"Base identity for VPN Policy filter type.";
}
identity ipv4 {
base vpn-policy-filter-type;
description
"Identity for IPv4 Prefix filter type.";
}
identity ipv6 {
base vpn-policy-filter-type;
description
"Identity for IPv6 Prefix filter type.";
}
identity lan {
base vpn-policy-filter-type;
description
"Identity for LAN Tag filter type.";
}
identity qos-profile-direction {
description
"Base identity for QoS profile direction.";
}
identity site-to-wan {
base qos-profile-direction;
description
"Identity for Site-to-WAN direction.";
}
identity wan-to-site {
base qos-profile-direction;
description
"Identity for WAN-to-Site direction.";
}
identity both {
base qos-profile-direction;
description
"Identity for both WAN-to-Site direction
and Site-to-WAN direction.";
}
/* Groupings */
grouping vpn-service-cloud-access {
container cloud-accesses {
if-feature cloud-access;
list cloud-access {
key cloud-identifier;
leaf cloud-identifier {
type leafref {
path "/l3vpn-svc/vpn-profiles/"+
"valid-provider-identifiers/cloud-identifier/id";
}
description
"Identification of cloud service.
Local administration meaning.";
}
choice list-flavor {
case permit-any {
leaf permit-any {
type empty;
description
"Allows all sites.";
}
}
case deny-any-except {
leaf-list permit-site {
type leafref {
path "/l3vpn-svc/sites/site/site-id";
}
description
"Site ID to be authorized.";
}
}
case permit-any-except {
leaf-list deny-site {
type leafref {
path "/l3vpn-svc/sites/site/site-id";
}
description
"Site ID to be denied.";
}
}
description
"Choice for cloud access policy. By
default, all sites in the IP VPN MUST
be authorized to access the cloud.";
}
container address-translation {
container nat44 {
leaf enabled {
type boolean;
default false;
description
"Controls whether or not Network address
translation from IPv4 to IPv4 (NAT44)
[RFC3022] is required.";
}
leaf nat44-customer-address {
type inet:ipv4-address;
description
"Address to be used for network address
translation from IPv4 to IPv4. This is
to be used if the customer is providing
the IPv4 address. If the customer address
is not set, the model assumes that the
provider will allocate the address.";
}
description
"IPv4-to-IPv4 translation.";
}
description
"Container for NAT.";
}
description
"Cloud access configuration.";
}
description
"Container for cloud access configurations.";
}
description
"Grouping for VPN cloud definition.";
}
grouping multicast-rp-group-cfg {
choice group-format {
mandatory true;
case singleaddress {
leaf group-address {
type inet:ip-address;
description
"A single multicast group address.";
}
}
case startend {
leaf group-start {
type inet:ip-address;
description
"The first multicast group address in
the multicast group address range.";
}
leaf group-end {
type inet:ip-address;
description
"The last multicast group address in
the multicast group address range.";
}
}
description
"Choice for multicast group format.";
}
description
"This grouping defines multicast group or
multicast groups for RP-to-group mapping.";
}
grouping vpn-service-multicast {
container multicast {
if-feature multicast;
leaf enabled {
type boolean;
default false;
description
"Enables multicast.";
}
container customer-tree-flavors {
leaf-list tree-flavor {
type identityref {
base multicast-tree-type;
}
description
"Type of tree to be used.";
}
description
"Type of trees used by customer.";
}
container rp {
container rp-group-mappings {
list rp-group-mapping {
key id;
leaf id {
type uint16;
description
"Unique identifier for the mapping.";
}
container provider-managed {
leaf enabled {
type boolean;
default false;
description
"Set to true if the Rendezvous Point (RP)
must be a provider-managed node. Set to false
if it is a customer-managed node.";
}
leaf rp-redundancy {
type boolean;
default false;
description
"If true, a redundancy mechanism for the RP
is required.";
}
leaf optimal-traffic-delivery {
type boolean;
default false;
description
"If true, the SP must ensure that
traffic uses an optimal path. An SP may use
Anycast RP or RP-tree-to-SPT switchover
architectures.";
}
description
"Parameters for a provider-managed RP.";
}
leaf rp-address {
when "../provider-managed/enabled = 'false'" {
description
"Relevant when the RP is not provider-managed.";
}
type inet:ip-address;
mandatory true;
description
"Defines the address of the RP.
Used if the RP is customer-managed.";
}
container groups {
list group {
key id;
leaf id {
type uint16;
description
"Identifier for the group.";
}
uses multicast-rp-group-cfg;
description
"List of multicast groups.";
}
description
"Multicast groups associated with the RP.";
}
description
"List of RP-to-group mappings.";
}
description
"RP-to-group mappings parameters.";
}
container rp-discovery {
leaf rp-discovery-type {
type identityref {
base multicast-rp-discovery-type;
}
default static-rp;
description
"Type of RP discovery used.";
}
container bsr-candidates {
when "derived-from-or-self(../rp-discovery-type, "+
"'l3vpn-svc:bsr-rp')" {
description
"Only applicable if discovery type
is BSR-RP.";
}
leaf-list bsr-candidate-address {
type inet:ip-address;
description
"Address of BSR candidate.";
}
description
"Container for List of Customer
BSR candidate's addresses.";
}
description
"RP discovery parameters.";
}
description
"RP parameters.";
}
description
"Multicast global parameters for the VPN service.";
}
description
"Grouping for multicast VPN definition.";
}
grouping vpn-service-mpls {
leaf carrierscarrier {
if-feature carrierscarrier;
type boolean;
default false;
description
"The VPN is using CsC, and so MPLS is required.";
}
description
"Grouping for MPLS CsC definition.";
}
grouping customer-location-info {
container locations {
list location {
key location-id;
leaf location-id {
type svc-id;
description
"Identifier for a particular location.";
}
leaf address {
type string;
description
"Address (number and street) of the site.";
}
leaf postal-code {
type string;
description
"Postal code of the site.";
}
leaf state {
type string;
description
"State of the site. This leaf can also be
used to describe a region for a country that
does not have states.";
}
leaf city {
type string;
description
"City of the site.";
}
leaf country-code {
type string {
pattern '[A-Z]{2}';
}
description
"Country of the site.
Expressed as ISO ALPHA-2 code.";
}
description
"Location of the site.";
}
description
"List of locations for the site.";
}
description
"This grouping defines customer location parameters.";
}
grouping site-group {
container groups {
list group {
key group-id;
leaf group-id {
type string;
description
"Group-id the site belongs to.";
}
description
"List of group-ids.";
}
description
"Groups the site or site-network-access belongs to.";
}
description
"Grouping definition to assign
group-ids to site or site-network-access.";
}
grouping site-diversity {
container site-diversity {
if-feature site-diversity;
uses site-group;
description
"Diversity constraint type. All
site-network-accesses will inherit
the group values defined here.";
}
description
"This grouping defines site
diversity parameters.";
}
grouping access-diversity {
container access-diversity {
if-feature site-diversity;
uses site-group;
container constraints {
list constraint {
key constraint-type;
leaf constraint-type {
type identityref {
base placement-diversity;
}
description
"Diversity constraint type.";
}
container target {
choice target-flavor {
default id;
case id {
list group {
key group-id;
leaf group-id {
type string;
description
"The constraint will be applied against
this particular group-id for this site
network access level.";
}
description
"List of group-ids associated with one specific
constraint for this site network access level.";
}
}
case all-accesses {
leaf all-other-accesses {
type empty;
description
"The constraint will be applied against
all other site network accesses of this site.";
}
}
case all-groups {
leaf all-other-groups {
type empty;
description
"The constraint will be applied against
all other groups managed by the customer.";
}
}
description
"Choice for the target flavor definition.";
}
description
"The constraint will be applied against a
Specific target, and the target can be a list
of group-ids,all other site network accesses of
this site, or all other groups managed by the
customer.";
}
description
"List of constraints.";
}
description
"Placement constraints for this site network access.";
}
description
"Diversity parameters.";
}
description
"This grouping defines access diversity parameters.";
}
grouping operational-requirements {
leaf requested-site-start {
type yang:date-and-time;
description
"Optional leaf indicating requested date and
time when the service at a particular site is
expected to start.";
}
leaf requested-site-stop {
type yang:date-and-time;
description
"Optional leaf indicating requested date and
time when the service at a particular site is
expected to stop.";
}
description
"This grouping defines some operational
parameters.";
}
grouping operational-requirements-ops {
leaf actual-site-start {
type yang:date-and-time;
config false;
description
"Optional leaf indicating actual date and
time when the service at a particular site
actually started.";
}
leaf actual-site-stop {
type yang:date-and-time;
config false;
description
"Optional leaf indicating actual date and
time when the service at a particular site
actually stopped.";
}
description
"This grouping defines some operational
parameters.";
}
grouping flow-definition {
container match-flow {
leaf dscp {
type inet:dscp;
description
"DSCP value.";
}
leaf dot1p {
type uint8 {
range "0..7";
}
description
"802.1p matching.";
}
leaf ipv4-src-prefix {
type inet:ipv4-prefix;
description
"Match on IPv4 src address.";
}
leaf ipv6-src-prefix {
type inet:ipv6-prefix;
description
"Match on IPv6 src address.";
}
leaf ipv4-dst-prefix {
type inet:ipv4-prefix;
description
"Match on IPv4 dst address.";
}
leaf ipv6-dst-prefix {
type inet:ipv6-prefix;
description
"Match on IPv6 dst address.";
}
leaf l4-src-port {
type inet:port-number;
must "current() < ../l4-src-port-range/lower-port or "+
"current() > ../l4-src-port-range/upper-port" {
description
"If l4-src-port and l4-src-port-range/lower-port and
upper-port are set at the same time, l4-src-port
should not overlap with l4-src-port-range.";
}
description
"Match on Layer 4 src port.";
}
leaf-list target-sites {
if-feature target-sites;
type svc-id;
description
"Identify a site as traffic destination.";
}
container l4-src-port-range {
leaf lower-port {
type inet:port-number;
description
"Lower boundary for port.";
}
leaf upper-port {
type inet:port-number;
must ". >= ../lower-port" {
description
"Upper boundary for port. If it
exists, the upper boundary must be
higher than the lower boundary.";
}
description
"Upper boundary for port.";
}
description
"Match on Layer 4 src port range. When
only the lower-port is present, it represents
a single port. When both the lower-port and
upper-port are specified, it implies
a range inclusive of both values.";
}
leaf l4-dst-port {
type inet:port-number;
must "current() < ../l4-dst-port-range/lower-port or "+
"current() > ../l4-dst-port-range/upper-port" {
description
"If l4-dst-port and l4-dst-port-range/lower-port
and upper-port are set at the same time,
l4-dst-port should not overlap with
l4-src-port-range.";
}
description
"Match on Layer 4 dst port.";
}
container l4-dst-port-range {
leaf lower-port {
type inet:port-number;
description
"Lower boundary for port.";
}
leaf upper-port {
type inet:port-number;
must ". >= ../lower-port" {
description
"Upper boundary must be
higher than lower boundary.";
}
description
"Upper boundary for port. If it exists,
upper boundary must be higher than lower
boundary.";
}
description
"Match on Layer 4 dst port range. When only
lower-port is present, it represents a single
port. When both lower-port and upper-port are
specified, it implies a range inclusive of both
values.";
}
leaf protocol-field {
type union {
type uint8;
type identityref {
base protocol-type;
}
}
description
"Match on IPv4 protocol or IPv6 Next Header field.";
}
description
"Describes flow-matching criteria.";
}
description
"Flow definition based on criteria.";
}
grouping site-service-basic {
leaf svc-input-bandwidth {
type uint64;
units bps;
mandatory true;
description
"From the customer site's perspective, the service
input bandwidth of the connection or download
bandwidth from the SP to the site.";
}
leaf svc-output-bandwidth {
type uint64;
units bps;
mandatory true;
description
"From the customer site's perspective, the service
output bandwidth of the connection or upload
bandwidth from the site to the SP.";
}
leaf svc-mtu {
type uint16;
units bytes;
mandatory true;
description
"MTU at service level. If the service is IP,
it refers to the IP MTU. If CsC is enabled,
the requested 'svc-mtu' leaf will refer to the
MPLS MTU and not to the IP MTU.";
}
description
"Defines basic service parameters for a site.";
}
grouping site-protection {
container traffic-protection {
if-feature fast-reroute;
leaf enabled {
type boolean;
default false;
description
"Enables traffic protection of access link.";
}
description
"Fast Reroute service parameters for the site.";
}
description
"Defines protection service parameters for a site.";
}
grouping site-service-mpls {
container carrierscarrier {
if-feature carrierscarrier;
leaf signalling-type {
type enumeration {
enum ldp {
description
"Use LDP as the signalling protocol
between the PE and the CE. In this case,
an IGP routing protocol must also be activated.";
}
enum bgp {
description
"Use BGP (as per RFC 8277) as the signalling protocol
between the PE and the CE.
In this case, BGP must also be configured as
the routing protocol.";
}
}
default bgp;
description
"MPLS signalling type.";
}
description
"This container is used when the customer provides
MPLS-based services. This is only used in the case
of CsC (i.e., a customer builds an MPLS service using
an IP VPN to carry its traffic).";
}
description
"Defines MPLS service parameters for a site.";
}
grouping site-service-qos-profile {
container qos {
if-feature qos;
container qos-classification-policy {
list rule {
key id;
ordered-by user;
leaf id {
type string;
description
"A description identifying the
qos-classification-policy rule.";
}
choice match-type {
default match-flow;
case match-flow {
uses flow-definition;
}
case match-application {
leaf match-application {
type identityref {
base customer-application;
}
description
"Defines the application to match.";
}
}
description
"Choice for classification.";
}
leaf target-class-id {
type string;
description
"Identification of the class of service.
This identifier is internal to the administration.";
}
description
"List of marking rules.";
}
description
"Configuration of the traffic classification policy.";
}
container qos-profile {
choice qos-profile {
description
"Choice for QoS profile.
Can be standard profile or customized profile.";
case standard {
description
"Standard QoS profile.";
leaf profile {
type leafref {
path "/l3vpn-svc/vpn-profiles/valid-provider-identifiers"+
"/qos-profile-identifier/id";
}
description
"QoS profile to be used.";
}
}
case custom {
description
"Customized QoS profile.";
container classes {
if-feature qos-custom;
list class {
key class-id;
leaf class-id {
type string;
description
"Identification of the class of service.
This identifier is internal to the
administration.";
}
leaf direction {
type identityref {
base qos-profile-direction;
}
default both;
description
"The direction to which the QoS profile
is applied.";
}
leaf rate-limit {
type decimal64 {
fraction-digits 5;
range "0..100";
}
units percent;
description
"To be used if the class must be rate-limited.
Expressed as percentage of the service
bandwidth.";
}
container latency {
choice flavor {
case lowest {
leaf use-lowest-latency {
type empty;
description
"The traffic class should use the path with the
lowest latency.";
}
}
case boundary {
leaf latency-boundary {
type uint16;
units msec;
default 400;
description
"The traffic class should use a path with a
defined maximum latency.";
}
}
description
"Latency constraint on the traffic class.";
}
description
"Latency constraint on the traffic class.";
}
container jitter {
choice flavor {
case lowest {
leaf use-lowest-jitter {
type empty;
description
"The traffic class should use the path with the
lowest jitter.";
}
}
case boundary {
leaf latency-boundary {
type uint32;
units usec;
default 40000;
description
"The traffic class should use a path with a
defined maximum jitter.";
}
}
description
"Jitter constraint on the traffic class.";
}
description
"Jitter constraint on the traffic class.";
}
container bandwidth {
leaf guaranteed-bw-percent {
type decimal64 {
fraction-digits 5;
range "0..100";
}
units percent;
mandatory true;
description
"To be used to define the guaranteed bandwidth
as a percentage of the available service bandwidth.";
}
leaf end-to-end {
type empty;
description
"Used if the bandwidth reservation
must be done on the MPLS network too.";
}
description
"Bandwidth constraint on the traffic class.";
}
description
"List of classes of services.";
}
description
"Container for list of classes of services.";
}
}
}
description
"QoS profile configuration.";
}
description
"QoS configuration.";
}
description
"This grouping defines QoS parameters for a site.";
}
grouping site-security-authentication {
container authentication {
description
"Authentication parameters.";
}
description
"This grouping defines authentication parameters for a site.";
}
grouping site-security-encryption {
container encryption {
if-feature encryption;
leaf enabled {
type boolean;
default false;
description
"If true, traffic encryption on the connection is required.";
}
leaf layer {
when "../enabled = 'true'" {
description
"Require a value for layer when enabled is true.";
}
type enumeration {
enum layer2 {
description
"Encryption will occur at Layer 2.";
}
enum layer3 {
description
"Encryption will occur at Layer 3.
For example, IPsec may be used when
a customer requests Layer 3 encryption.";
}
}
description
"Layer on which encryption is applied.";
}
container encryption-profile {
choice profile {
case provider-profile {
leaf profile-name {
type leafref {
path "/l3vpn-svc/vpn-profiles/valid-provider-identifiers"+
"/encryption-profile-identifier/id";
}
description
"Name of the SP profile to be applied.";
}
}
case customer-profile {
leaf algorithm {
type string;
description
"Encryption algorithm to be used.";
}
choice key-type {
default psk;
case psk {
leaf preshared-key {
type string;
description
"Pre-Shared Key (PSK) coming from the customer.";
}
}
description
"Type of keys to be used.";
}
}
description
"Choice of encryption profile. The encryption
profile can be the provider profile or customer profile.";
}
description
"Profile of encryption to be applied.";
}
description
"Encryption parameters.";
}
description
"This grouping defines encryption parameters for a site.";
}
grouping site-attachment-bearer {
container bearer {
container requested-type {
if-feature requested-type;
leaf requested-type {
type string;
description
"Type of requested bearer: Ethernet, DSL,
Wireless, etc. Operator specific.";
}
leaf strict {
type boolean;
default false;
description
"Defines whether requested-type is a preference
or a strict requirement.";
}
description
"Container for requested-type.";
}
leaf always-on {
if-feature always-on;
type boolean;
default true;
description
"Request for an always-on access type.
For example, this could mean no dial access type.";
}
leaf bearer-reference {
if-feature bearer-reference;
type string;
description
"This is an internal reference for the SP.";
}
description
"Bearer-specific parameters.
To be augmented.";
}
description
"Defines physical properties of a site attachment.";
}
grouping site-routing {
container routing-protocols {
list routing-protocol {
key type;
leaf type {
type identityref {
base routing-protocol-type;
}
description
"Type of routing protocol.";
}
container ospf {
when "derived-from-or-self(../type, 'l3vpn-svc:ospf')" {
description
"Only applies when protocol is OSPF.";
}
if-feature rtg-ospf;
leaf-list address-family {
type address-family;
min-elements "1";
description
"If OSPF is used on this site, this node
contains a configured value. This node
contains at least one address family
to be activated.";
}
leaf area-address {
type yang:dotted-quad;
mandatory true;
description
"Area address.";
}
leaf metric {
type uint16;
default 1;
description
"Metric of the PE-CE link. It is used
in the routing state calculation and
path selection.";
}
container sham-links {
if-feature rtg-ospf-sham-link;
list sham-link {
key target-site;
leaf target-site {
type svc-id;
description
"Target site for the sham link connection.
The site is referred to by its ID.";
}
leaf metric {
type uint16;
default 1;
description
"Metric of the sham link. It is used in
the routing state calculation and path
selection. The default value is set
to 1.";
}
description
"Creates a sham link with another site.";
}
description
"List of sham links.";
}
description
"OSPF-specific configuration.";
}
container bgp {
when "derived-from-or-self(../type, 'l3vpn-svc:bgp')" {
description
"Only applies when protocol is BGP.";
}
if-feature rtg-bgp;
leaf autonomous-system {
type uint32;
mandatory true;
description
"Customer AS number in case the customer
requests BGP routing.";
}
leaf-list address-family {
type address-family;
min-elements "1";
description
"If BGP is used on this site, this node
contains a configured value. This node
contains at least one address family
to be activated.";
}
description
"BGP-specific configuration.";
}
container static {
when "derived-from-or-self(../type, 'l3vpn-svc:static')" {
description
"Only applies when protocol is static.
BGP activation requires the SP to know
the address of the customer peer. When
BGP is enabled, the 'static-address'
allocation type for the IP connection
MUST be used.";
}
container cascaded-lan-prefixes {
list ipv4-lan-prefixes {
if-feature ipv4;
key "lan next-hop";
leaf lan {
type inet:ipv4-prefix;
description
"LAN prefixes.";
}
leaf lan-tag {
type string;
description
"Internal tag to be used in VPN policies.";
}
leaf next-hop {
type inet:ipv4-address;
description
"Next-hop address to use on the customer side.";
}
description
"List of LAN prefixes for the site.";
}
list ipv6-lan-prefixes {
if-feature ipv6;
key "lan next-hop";
leaf lan {
type inet:ipv6-prefix;
description
"LAN prefixes.";
}
leaf lan-tag {
type string;
description
"Internal tag to be used in VPN policies.";
}
leaf next-hop {
type inet:ipv6-address;
description
"Next-hop address to use on the customer side.";
}
description
"List of LAN prefixes for the site.";
}
description
"LAN prefixes from the customer.";
}
description
"Configuration specific to static routing.";
}
container rip {
when "derived-from-or-self(../type, 'l3vpn-svc:rip')" {
description
"Only applies when the protocol is RIP. For IPv4,
the model assumes that RIP version 2 is used.";
}
if-feature rtg-rip;
leaf-list address-family {
type address-family;
min-elements "1";
description
"If RIP is used on this site, this node
contains a configured value. This node
contains at least one address family
to be activated.";
}
description
"Configuration specific to RIP routing.";
}
container vrrp {
when "derived-from-or-self(../type, 'l3vpn-svc:vrrp')" {
description
"Only applies when protocol is VRRP.";
}
if-feature rtg-vrrp;
leaf-list address-family {
type address-family;
min-elements "1";
description
"If VRRP is used on this site, this node
contains a configured value. This node contains
at least one address family to be activated.";
}
description
"Configuration specific to VRRP routing.";
}
description
"List of routing protocols used on
the site. This list can be augmented.";
}
description
"Defines routing protocols.";
}
description
"Grouping for routing protocols.";
}
grouping site-attachment-ip-connection {
container ip-connection {
container ipv4 {
if-feature ipv4;
leaf address-allocation-type {
type identityref {
base address-allocation-type;
}
must "not(derived-from-or-self(current(), 'l3vpn-svc:slaac') or "+
"derived-from-or-self(current(), "+
"'l3vpn-svc:provider-dhcp-slaac'))" {
error-message "SLAAC is only applicable to IPv6";
}
description
"Defines how addresses are allocated.
If there is no value for the address
allocation type, then IPv4 is not enabled.";
}
container provider-dhcp {
when "derived-from-or-self(../address-allocation-type, "+
"'l3vpn-svc:provider-dhcp')" {
description
"Only applies when addresses are allocated by DHCP.";
}
leaf provider-address {
type inet:ipv4-address;
description
"Address of provider side. If provider-address is not
specified, then prefix length should not be specified
either. It also implies provider-dhcp allocation is
not enabled. If provider-address is specified, then
the prefix length may or may not be specified.";
}
leaf prefix-length {
type uint8 {
range "0..32";
}
must "(../provider-address)" {
error-message
"If the prefix length is specified, provider-address
must also be specified.";
description
"If the prefix length is specified, provider-address
must also be specified.";
}
description
"Subnet prefix length expressed in bits.
If not specified, or specified as zero,
this means the customer leaves the actual
prefix length value to the provider.";
}
choice address-assign {
default number;
case number {
leaf number-of-dynamic-address {
type uint16;
default 1;
description
"Describes the number of IP addresses
the customer requires.";
}
}
case explicit {
container customer-addresses {
list address-group {
key "group-id";
leaf group-id {
type string;
description
"Group-id for the address range from
start-address to end-address.";
}
leaf start-address {
type inet:ipv4-address;
description
"First address.";
}
leaf end-address {
type inet:ipv4-address;
description
"Last address.";
}
description
"Describes IP addresses allocated by DHCP.
When only start-address or only end-address
is present, it represents a single address.
When both start-address and end-address are
specified, it implies a range inclusive of both
addresses. If no address is specified, it implies
customer addresses group is not supported.";
}
description
"Container for customer addresses is allocated by DHCP.";
}
}
description
"Choice for the way to assign addresses.";
}
description
"DHCP allocated addresses related parameters.";
}
container dhcp-relay {
when "derived-from-or-self(../address-allocation-type, "+
"'l3vpn-svc:provider-dhcp-relay')" {
description
"Only applies when provider is required to implement
DHCP relay function.";
}
leaf provider-address {
type inet:ipv4-address;
description
"Address of provider side. If provider-address is not
specified, then prefix length should not be specified
either. It also implies provider-dhcp allocation is
not enabled. If provider-address is specified, then
prefix length may or may not be specified.";
}
leaf prefix-length {
type uint8 {
range "0..32";
}
must "(../provider-address)" {
error-message
"If prefix length is specified, provider-address
must also be specified.";
description
"If prefix length is specified, provider-address
must also be specified.";
}
description
"Subnet prefix length expressed in bits. If not
specified, or specified as zero, this means the
customer leaves the actual prefix length value
to the provider.";
}
container customer-dhcp-servers {
leaf-list server-ip-address {
type inet:ipv4-address;
description
"IP address of customer DHCP server.";
}
description
"Container for list of customer DHCP servers.";
}
description
"DHCP relay provided by operator.";
}
container addresses {
when "derived-from-or-self(../address-allocation-type, "+
"'l3vpn-svc:static-address')" {
description
"Only applies when protocol allocation type is static.";
}
leaf provider-address {
type inet:ipv4-address;
description
"IPv4 Address List of the provider side.
When the protocol allocation type is static,
the provider address must be configured.";
}
leaf customer-address {
type inet:ipv4-address;
description
"IPv4 Address of customer side.";
}
leaf prefix-length {
type uint8 {
range "0..32";
}
description
"Subnet prefix length expressed in bits.
It is applied to both provider-address
and customer-address.";
}
description
"Describes IPv4 addresses used.";
}
description
"IPv4-specific parameters.";
}
container ipv6 {
if-feature ipv6;
leaf address-allocation-type {
type identityref {
base address-allocation-type;
}
description
"Defines how addresses are allocated.
If there is no value for the address
allocation type, then IPv6 is
not enabled.";
}
container provider-dhcp {
when "derived-from-or-self(../address-allocation-type, "+
"'l3vpn-svc:provider-dhcp') "+
"or derived-from-or-self(../address-allocation-type, "+
"'l3vpn-svc:provider-dhcp-slaac')" {
description
"Only applies when addresses are allocated by DHCP.";
}
leaf provider-address {
type inet:ipv6-address;
description
"Address of the provider side. If provider-address
is not specified, then prefix length should not be
specified either. It also implies provider-dhcp
allocation is not enabled. If provider-address is
specified, then prefix length may or may
not be specified.";
}
leaf prefix-length {
type uint8 {
range "0..128";
}
must "(../provider-address)" {
error-message
"If prefix length is specified, provider-address
must also be specified.";
description
"If prefix length is specified, provider-address
must also be specified.";
}
description
"Subnet prefix length expressed in bits. If not
specified, or specified as zero, this means the
customer leaves the actual prefix length value
to the provider.";
}
choice address-assign {
default number;
case number {
leaf number-of-dynamic-address {
type uint16;
default 1;
description
"Describes the number of IP addresses the customer
requires.";
}
}
case explicit {
container customer-addresses {
list address-group {
key "group-id";
leaf group-id {
type string;
description
"Group-id for the address range from
start-address to end-address.";
}
leaf start-address {
type inet:ipv6-address;
description
"First address.";
}
leaf end-address {
type inet:ipv6-address;
description
"Last address.";
}
description
"Describes IP addresses allocated by DHCP. When only
start-address or only end-address is present, it
represents a single address. When both start-address
and end-address are specified, it implies a range
inclusive of both addresses. If no address is
specified, it implies customer addresses group is
not supported.";
}
description
"Container for customer addresses allocated by DHCP.";
}
}
description
"Choice for the way to assign addresses.";
}
description
"DHCP allocated addresses related parameters.";
}
container dhcp-relay {
when "derived-from-or-self(../address-allocation-type, "+
"'l3vpn-svc:provider-dhcp-relay')" {
description
"Only applies when the provider is required
to implement DHCP relay function.";
}
leaf provider-address {
type inet:ipv6-address;
description
"Address of the provider side. If provider-address is
not specified, then prefix length should not be
specified either. It also implies provider-dhcp
allocation is not enabled. If provider address
is specified, then prefix length may or may
not be specified.";
}
leaf prefix-length {
type uint8 {
range "0..128";
}
must "(../provider-address)" {
error-message
"If prefix length is specified, provider-address
must also be specified.";
description
"If prefix length is specified, provider-address
must also be specified.";
}
description
"Subnet prefix length expressed in bits. If not
specified, or specified as zero, this means the
customer leaves the actual prefix length value
to the provider.";
}
container customer-dhcp-servers {
leaf-list server-ip-address {
type inet:ipv6-address;
description
"This node contains the IP address of
the customer DHCP server. If the DHCP relay
function is implemented by the
provider, this node contains the
configured value.";
}
description
"Container for list of customer DHCP servers.";
}
description
"DHCP relay provided by operator.";
}
container addresses {
when "derived-from-or-self(../address-allocation-type, "+
"'l3vpn-svc:static-address')" {
description
"Only applies when protocol allocation type is static.";
}
leaf provider-address {
type inet:ipv6-address;
description
"IPv6 Address of the provider side. When the protocol
allocation type is static, the provider address
must be configured.";
}
leaf customer-address {
type inet:ipv6-address;
description
"The IPv6 Address of the customer side.";
}
leaf prefix-length {
type uint8 {
range "0..128";
}
description
"Subnet prefix length expressed in bits.
It is applied to both provider-address and
customer-address.";
}
description
"Describes IPv6 addresses used.";
}
description
"IPv6-specific parameters.";
}
container oam {
container bfd {
if-feature bfd;
leaf enabled {
type boolean;
default false;
description
"If true, BFD activation is required.";
}
choice holdtime {
default fixed;
case fixed {
leaf fixed-value {
type uint32;
units msec;
description
"Expected BFD holdtime expressed in msec. The customer
may impose some fixed values for the holdtime period
if the provider allows the customer use this function.
If the provider doesn't allow the customer to use this
function, the fixed-value will not be set.";
}
}
case profile {
leaf profile-name {
type leafref {
path "/l3vpn-svc/vpn-profiles/valid-provider-identifiers/"+
"bfd-profile-identifier/id";
}
description
"Well-known SP profile name. The provider can propose
some profiles to the customer, depending on the service
level the customer wants to achieve. Profile names
must be communicated to the customer.";
}
description
"Well-known SP profile.";
}
description
"Choice for holdtime flavor.";
}
description
"Container for BFD.";
}
description
"Defines the Operations, Administration, and Maintenance (OAM)
mechanisms used on the connection. BFD is set as a fault
detection mechanism, but the 'oam' container can easily
be augmented by other mechanisms";
}
description
"Defines connection parameters.";
}
description
"This grouping defines IP connection parameters.";
}
grouping site-service-multicast {
container multicast {
if-feature multicast;
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 multicast site.";
}
container multicast-address-family {
leaf ipv4 {
if-feature ipv4;
type boolean;
default false;
description
"Enables IPv4 multicast.";
}
leaf ipv6 {
if-feature ipv6;
type boolean;
default false;
description
"Enables IPv6 multicast.";
}
description
"Defines protocol to carry multicast.";
}
leaf protocol-type {
type enumeration {
enum host {
description
"Hosts are directly connected to the provider network.
Host protocols such as IGMP or MLD are required.";
}
enum router {
description
"Hosts are behind a customer router.
PIM will be implemented.";
}
enum both {
description
"Some hosts are behind a customer router, and
some others are directly connected to the
provider network. Both host and routing protocols
must be used. Typically, IGMP and PIM will be
implemented.";
}
}
default "both";
description
"Multicast protocol type to be used with the customer site.";
}
description
"Multicast parameters for the site.";
}
description
"Multicast parameters for the site.";
}
grouping site-management {
container management {
leaf type {
type identityref {
base management;
}
mandatory true;
description
"Management type of the connection.";
}
description
"Management configuration.";
}
description
"Management parameters for the site.";
}
grouping site-devices {
container devices {
when "derived-from-or-self(../management/type, "+
"'l3vpn-svc:provider-managed') or "+
"derived-from-or-self(../management/type, 'l3vpn-svc:co-managed')" {
description
"Applicable only for provider-managed or
co-managed device.";
}
list device {
key device-id;
leaf device-id {
type svc-id;
description
"Identifier for the device.";
}
leaf location {
type leafref {
path "../../../locations/"+
"location/location-id";
}
mandatory true;
description
"Location of the device.";
}
container management {
when "derived-from-or-self(../../../management/type,"+
"'l3vpn-svc:co-managed')" {
description
"Applicable only for co-managed device.";
}
leaf address-family {
type address-family;
description
"Address family used for management.";
}
leaf address {
when "(../address-family)" {
description
"If address-family is specified, then address should
also be specified. If address-family is not specified,
then address should also not be specified.";
}
type inet:ip-address;
mandatory true;
description
"Management address.";
}
description
"Management configuration. Applicable only for
co-managed device.";
}
description
"List of devices requested by customer.";
}
description
"Device configuration.";
}
description
"Grouping for device allocation.";
}
grouping site-vpn-flavor {
leaf site-vpn-flavor {
type identityref {
base site-vpn-flavor;
}
default site-vpn-flavor-single;
description
"Defines the way the VPN multiplexing is done, e.g., whether
the site belongs to a single VPN site or a multiVPN; or, in the case
of a multiVPN, whether the logical accesses of the sites belong
to the same set of VPNs or each logical access maps to
different VPNs.";
}
description
"Grouping for site VPN flavor.";
}
grouping site-vpn-policy {
container vpn-policies {
list vpn-policy {
key vpn-policy-id;
leaf vpn-policy-id {
type svc-id;
description
"Unique identifier for the VPN policy.";
}
list entries {
key id;
leaf id {
type svc-id;
description
"Unique identifier for the policy entry.";
}
container filters {
list filter {
key type;
ordered-by user;
leaf type {
type identityref {
base vpn-policy-filter-type;
}
description
"Type of VPN Policy filter.";
}
leaf-list lan-tag {
when "derived-from-or-self(../type, 'l3vpn-svc:lan')" {
description
"Only applies when the VPN Policy filter is a
LAN Tag filter.";
}
if-feature lan-tag;
type string;
description
"List of 'lan-tag' items to be matched. LAN Tag
is an Internal tag to be used in VPN policies ";
}
leaf-list ipv4-lan-prefix {
when "derived-from-or-self(../type, 'l3vpn-svc:ipv4')" {
description
"Only applies when VPN Policy filter is IPv4 Prefix filter.";
}
if-feature ipv4;
type inet:ipv4-prefix;
description
"List of IPv4 prefixes as LAN Prefixes to be matched.";
}
leaf-list ipv6-lan-prefix {
when "derived-from-or-self(../type, 'l3vpn-svc:ipv6')" {
description
"Only applies when VPN Policy filter is IPv6 Prefix filter.";
}
if-feature ipv6;
type inet:ipv6-prefix;
description
"List of IPv6 prefixes as LAN prefixes to be matched.";
}
description
"List of filters used on the site. This list can
be augmented.";
}
description
"If a more-granular VPN attachment is necessary, filtering can
be used. If used, it permits the splitting of site LANs among
multiple VPNs. The Site LAN can be split based on either LAN
Tag or LAN prefix. If no filter is used, all the LANs will be
part of the same VPNs with the same role.";
}
list vpn {
key vpn-id;
leaf vpn-id {
type leafref {
path "/l3vpn-svc/vpn-services/"+
"vpn-service/vpn-id";
}
mandatory true;
description
"Reference to an IP VPN.";
}
leaf site-role {
type identityref {
base site-role;
}
default any-to-any-role;
description
"Role of the site in the IP VPN.";
}
description
"List of VPNs the LAN is associated with.";
}
description
"List of entries for export policy.";
}
description
"List of VPN policies.";
}
description
"VPN policy.";
}
description
"VPN policy parameters for the site.";
}
grouping site-maximum-routes {
container maximum-routes {
list address-family {
key af;
leaf af {
type address-family;
description
"Address family.";
}
leaf maximum-routes {
type uint32;
description
"Maximum prefixes the VRF can accept
for this address family.";
}
description
"List of address families.";
}
description
"Defines 'maximum-routes' for the VRF.";
}
description
"Defines 'maximum-routes' for the site.";
}
grouping site-security {
container security {
uses site-security-authentication;
uses site-security-encryption;
description
"Site-specific security parameters.";
}
description
"Grouping for security parameters.";
}
grouping site-service {
container service {
uses site-service-qos-profile;
uses site-service-mpls;
uses site-service-multicast;
description
"Service parameters on the attachment.";
}
description
"Grouping for service parameters.";
}
grouping site-network-access-service {
container service {
uses site-service-basic;
uses site-service-qos-profile;
uses site-service-mpls;
uses site-service-multicast;
description
"Service parameters on the attachment.";
}
description
"Grouping for service parameters.";
}
grouping vpn-extranet {
container extranet-vpns {
if-feature extranet-vpn;
list extranet-vpn {
key vpn-id;
leaf vpn-id {
type svc-id;
description
"Identifies the target VPN the local VPN want to access.";
}
leaf local-sites-role {
type identityref {
base site-role;
}
default any-to-any-role;
description
"This describes the role of the
local sites in the target VPN topology. In the any-to-any VPN
service topology, the local sites must have the same role, which
will be 'any-to-any-role'. In the Hub-and-Spoke VPN service
topology or the Hub-and-Spoke disjoint VPN service topology,
the local sites must have a Hub role or a Spoke role.";
}
description
"List of extranet VPNs or target VPNs the local VPN is
attached to.";
}
description
"Container for extranet VPN configuration.";
}
description
"Grouping for extranet VPN configuration.
This provides an easy way to interconnect
all sites from two VPNs.";
}
grouping site-attachment-availability {
container availability {
leaf access-priority {
type uint32;
default 100;
description
"Defines the priority for the access.
The higher the access-priority value,
the higher the preference of the
access will be.";
}
description
"Availability parameters (used for multihoming).";
}
description
"Defines availability parameters for a site.";
}
grouping access-vpn-policy {
container vpn-attachment {
choice attachment-flavor {
case vpn-policy-id {
leaf vpn-policy-id {
type leafref {
path "../../../../"+
"vpn-policies/vpn-policy/"+
"vpn-policy-id";
}
description
"Reference to a VPN policy. When referencing VPN
policy for attachment, the vpn-policy-id must be
configured.";
}
}
case vpn-id {
leaf vpn-id {
type leafref {
path "/l3vpn-svc/vpn-services"+
"/vpn-service/vpn-id";
}
description
"Reference to an IP VPN. Referencing a vpn-id provides
an easy way to attach a particular logical access to
a VPN. In this case, vpn-id must be configured.";
}
leaf site-role {
type identityref {
base site-role;
}
default any-to-any-role;
description
"Role of the site in the IP VPN. When referencing a vpn-id,
the site-role setting must be added to express the role of
the site in the target VPN service topology.";
}
}
mandatory true;
description
"Choice for VPN attachment flavor. A choice is implemented
to allow the user to choose the flavor that provides the
best fit.";
}
description
"Defines VPN attachment of a site.";
}
description
"Defines the VPN attachment rules for
a site's logical access.";
}
grouping vpn-profile-cfg {
container valid-provider-identifiers {
list cloud-identifier {
if-feature cloud-access;
key id;
leaf id {
type string;
description
"Identification of cloud service.
Local administration meaning.";
}
description
"List for Cloud Identifiers.";
}
list encryption-profile-identifier {
key id;
leaf id {
type string;
description
"Identification of the SP encryption profile
to be used. Local administration meaning.";
}
description
"List for encryption profile identifiers.";
}
list qos-profile-identifier {
key id;
leaf id {
type string;
description
"Identification of the QoS Profile to be used.
Local administration meaning.";
}
description
"List for QoS Profile Identifiers.";
}
list bfd-profile-identifier {
key id;
leaf id {
type string;
description
"Identification of the SP BFD Profile to be used.
Local administration meaning.";
}
description
"List for BFD Profile identifiers.";
}
nacm:default-deny-write;
description
"Container for Valid Provider Identifies.";
}
description
"Grouping for VPN Profile configuration.";
}
grouping vpn-svc-cfg {
leaf vpn-id {
type svc-id;
description
"VPN identifier. Local administration meaning.";
}
leaf customer-name {
type string;
description
"Name of the customer that actually uses the VPN service.
In the case that any intermediary (e.g., Tier-2 provider
or partner) sells the VPN service to their end user
on behalf of the original service provider (e.g., Tier-1
provider), the original service provider may require the
customer name to provide smooth activation/commissioning
and operation for the service.";
}
leaf vpn-service-topology {
type identityref {
base vpn-topology;
}
default any-to-any;
description
"VPN service topology.";
}
uses vpn-service-cloud-access;
uses vpn-service-multicast;
uses vpn-service-mpls;
uses vpn-extranet;
description
"Grouping for VPN service configuration.";
}
grouping site-top-level-cfg {
uses operational-requirements;
uses customer-location-info;
uses site-devices;
uses site-diversity;
uses site-management;
uses site-vpn-policy;
uses site-vpn-flavor;
uses site-maximum-routes;
uses site-security;
uses site-service;
uses site-protection;
uses site-routing;
description
"Grouping for site top-level configuration.";
}
grouping site-network-access-top-level-cfg {
leaf site-network-access-type {
type identityref {
base site-network-access-type;
}
default point-to-point;
description
"Describes the type of connection, e.g.,
point-to-point or multipoint.";
}
choice location-flavor {
case location {
when "derived-from-or-self(../../management/type, "+
"'l3vpn-svc:customer-managed')" {
description
"Applicable only for customer-managed device.";
}
leaf location-reference {
type leafref {
path "../../../locations/location/location-id";
}
description
"Location of the site-network-access.";
}
}
case device {
when "derived-from-or-self(../../management/type, "+
"'l3vpn-svc:provider-managed') or "+
"derived-from-or-self(../../management/type, "+
"'l3vpn-svc:co-managed')" {
description
"Applicable only for provider-managed or co-managed device.";
}
leaf device-reference {
type leafref {
path "../../../devices/device/device-id";
}
description
"Identifier of CE to use.";
}
}
mandatory true;
description
"Choice of how to describe the site's location.";
}
uses access-diversity;
uses site-attachment-bearer;
uses site-attachment-ip-connection;
uses site-security;
uses site-network-access-service;
uses site-routing;
uses site-attachment-availability;
uses access-vpn-policy;
description
"Grouping for site network access top-level configuration.";
}
/* Main blocks */
container l3vpn-svc {
container vpn-profiles {
uses vpn-profile-cfg;
description
"Container for VPN Profiles.";
}
container vpn-services {
list vpn-service {
key vpn-id;
uses vpn-svc-cfg;
description
"List of VPN services.";
}
description
"Top-level container for the VPN services.";
}
container sites {
list site {
key site-id;
leaf site-id {
type svc-id;
description
"Identifier of the site.";
}
uses site-top-level-cfg;
uses operational-requirements-ops;
container site-network-accesses {
list site-network-access {
key site-network-access-id;
leaf site-network-access-id {
type svc-id;
description
"Identifier for the access.";
}
uses site-network-access-top-level-cfg;
description
"List of accesses for a site.";
}
description
"List of accesses for a site.";
}
description
"List of sites.";
}
description
"Container for sites.";
}
description
"Main container for L3VPN service configuration.";
}
}
<CODE ENDS>
The YANG module specified in this document defines a schema for data that is 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 [RFC5246].
The YANG module specified in this document defines a schema for data that is 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 [RFC5246].
The NETCONF access control model [RFC6536]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.
NETCONFアクセス制御モデル[RFC6536]は、特定のNETCONFまたはRESTCONFユーザーのアクセスを、利用可能なすべてのNETCONFまたはRESTCONFプロトコル操作およびコンテンツの事前構成されたサブセットに制限する手段を提供します。
There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:
このYANGモジュールには、書き込み可能/作成可能/削除可能なデータノードが多数定義されています（つまり、config true、デフォルトです）。これらのデータノードは、一部のネットワーク環境では機密または脆弱であると見なされる場合があります。適切な保護なしにこれらのデータノードに書き込み操作（edit-configなど）を行うと、ネットワーク操作に悪影響を与える可能性があります。これらは、サブツリーとデータノード、およびそれらの機密性/脆弱性です。
o /l3vpn-svc/vpn-services/vpn-service
The entries in the list above include the whole vpn service configurations which the customer subscribes, and indirectly create or modify the PE and CE device configurations. Unexpected changes to these entries could lead to service disruption and/or network misbehavior.
上記のリストのエントリには、顧客がサブスクライブするvpnサービス構成全体が含まれており、PEおよびCEデバイス構成を間接的に作成または変更します。これらのエントリへの予期しない変更により、サービスの中断やネットワークの誤動作が発生する可能性があります。
o /l3vpn-svc/sites/site
The entries in the list above include the customer site configurations. As above, unexpected changes to these entries could lead to service disruption and/or network misbehavior.
上記のリストのエントリには、お客様のサイト構成が含まれています。上記のように、これらのエントリへの予期しない変更は、サービスの中断やネットワークの誤動作につながる可能性があります。
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:
このYANGモジュールの一部の読み取り可能なデータノードは、一部のネットワーク環境では機密または脆弱であると見なされる場合があります。したがって、これらのデータノードへの読み取りアクセスを制御することが重要です（たとえば、get、get-config、または通知を介して）。これらは、サブツリーとデータノード、およびそれらの機密性/脆弱性です。
o /l3vpn-svc/vpn-services/vpn-service
o /l3vpn-svc/sites/site The entries in the lists above include customer-proprietary or confidential information, e.g., customer-name, site location, what service the customer subscribes.
o / l3vpn-svc / sites / site上記のリストのエントリには、顧客名、サイトの場所、顧客が加入しているサービスなど、顧客独自の情報または機密情報が含まれます。
The data model defines some security parameters than can be extended via augmentation as part of the customer service request; those parameters are described in Section 6.9.
データモデルは、カスタマーサービスリクエストの一部として拡張によって拡張できるセキュリティパラメータをいくつか定義しています。これらのパラメーターについては、セクション6.9で説明します。
IANA has assigned a new URI from the "IETF XML Registry" [RFC3688].
IANAは、「IETF XMLレジストリ」[RFC3688]から新しいURIを割り当てました。
URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc Registrant Contact: The IESG XML: N/A; the requested URI is an XML namespace.
URI：urn：ietf：params：xml：ns：yang：ietf-l3vpn-svc登録者の連絡先：IESG XML：N / A;要求されたURIはXML名前空間です。
IANA has recorded a YANG module name in the "YANG Module Names" registry [RFC6020] as follows:
IANAは、YANGモジュール名を「YANG Module Names」レジストリ[RFC6020]に次のように記録しています。
Name: ietf-l3vpn-svc
Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
Prefix: l3vpn-svc
Reference: RFC 8299
IANA previously assigned the URI and YANG module as described in [RFC8049]. IANA has updated the references for these entries to refer to this document.
[RFC8049]で説明されているように、IANAは以前にURIおよびYANGモジュールを割り当てていました。 IANAは、このドキュメントを参照するために、これらのエントリの参照を更新しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <https://www.rfc-editor.org/info/rfc3022>.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、DOI 10.17487 / RFC3022、2001年1月、<https://www.rfc-editor.org/info/ rfc3022>。
[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。、「The IETF XML Registry」、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<https://www.rfc-editor.org/info/rfc3688>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP / MPLS IP Virtual Private Networks（VPNs）」、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<https://www.rfc-editor.org/info / rfc4364>。
[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, June 2006, <https://www.rfc-editor.org/info/rfc4577>.
[RFC4577] Rosen、E.、Psenak、P。、およびP. Pillay-Esault、「BGP / MPLS IP仮想プライベートネットワーク（VPN）のプロバイダー/カスタマーエッジプロトコルとしてのOSPF」、RFC 4577、DOI 10.17487 / RFC4577、 2006年6月、<https://www.rfc-editor.org/info/rfc4577>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<https://www.rfc-editor.org/info / rfc4862>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https://www.rfc-editor.org/info / rfc5246>。
[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 - 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>.
[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。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（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。、「Using the NETCONF Protocol over Secure Shell（SSH）」、RFC 6242、DOI 10.17487 / RFC6242、2011年6月、<https://www.rfc-editor.org/info/rfc6242>。
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6513]ローゼン、E、エド。およびR. Aggarwal編、「MPLS / BGP IP VPNでのマルチキャスト」、RFC 6513、DOI 10.17487 / RFC6513、2012年2月、<https://www.rfc-editor.org/info/rfc6513>。
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, <https://www.rfc-editor.org/info/rfc6536>.
[RFC6536] Bierman、A。およびM. Bjorklund、「Network Configuration Protocol（NETCONF）Access Control Model」、RFC 6536、DOI 10.17487 / RFC6536、2012年3月、<https://www.rfc-editor.org/info/ rfc6536>。
[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。、編、「The 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プロトコル」、RFC 8040、DOI 10.17487 / RFC8040、2017年1月、<https://www.rfc-editor.org/info/rfc8040 >。
[RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8049, DOI 10.17487/RFC8049, February 2017, <https://www.rfc-editor.org/info/rfc8049>.
[RFC8049] Litkowski、S.、Tomotaki、L.、K。Ogaki、「YANG Data Model for L3VPN Service Delivery」、RFC 8049、DOI 10.17487 / RFC8049、2017年2月、<https：//www.rfc-editor。 org / info / rfc8049>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[ACL-YANG] Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, "Network Access Control List (ACL) YANG Data Model", Work in Progress, draft-ietf-netmod-acl-model-14, October 2017.
[ACL-YANG] Jethanandani、M.、Huang、L.、Agarwal、S。、およびD. Blair、「Network Access Control List（ACL）YANG Data Model」、Work in Progress、draft-ietf-netmod-acl-モデル-14、2017年10月。
[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、「Provider Provisioned Virtual Private Network（VPN）Terminology」、RFC 4026、DOI 10.17487 / RFC4026、2005年3月、<https://www.rfc-editor.org/info/ rfc4026>。
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, DOI 10.17487/RFC4110, July 2005, <https://www.rfc-editor.org/info/rfc4110>.
[RFC4110] Callon、R。、およびM. Suzuki、「A Framework for Layer 3 Provider-Provisioned Virtual Private Networks（PPVPNs）」、RFC 4110、DOI 10.17487 / RFC4110、2005年7月、<https：//www.rfc-editor .org / info / rfc4110>。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.
[RFC4760]ベイツ、T。、チャンドラ、R。、カッツ、D。、およびY.レクター、「BGP-4のマルチプロトコル拡張機能」、RFC 4760、DOI 10.17487 / RFC4760、2007年1月、<https：// www。 rfc-editor.org/info/rfc4760>。
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, <https://www.rfc-editor.org/info/rfc8277>.
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, <https://www.rfc-editor.org/info/rfc8277>.
Acknowledgements
謝辞
Maxim Klyus, Luis Miguel Contreras, Gregory Mirsky, Zitao Wang, Jing Zhao, Kireeti Kompella, Eric Rosen, Aijun Wang, Michael Scharf, Xufeng Liu, David Ball, Lucy Yong, Jean-Philippe Landry, and Andrew Leu provided useful review to this document.
Maxim Klyus、Luis Miguel Contreras、Gregory Mirsky、Zitao Wang、Jing Zhao、Kireeti Kompella、Eric Rosen、Aijun Wang、Michael Scharf、Xufeng Liu、David Ball、Lucy Yong、Jean-Philippe Landry、Andrew Leuは、これに役立つレビューを提供しました資料。
Jan Lindblad reviewed RFC 8049 and found some bugs, and his thorough YANG Doctor review on the YANG Module is valuable input. David Ball also provided a second review on RFC 8049.
Jan LindbladはRFC 8049をレビューし、いくつかのバグを発見しました。YANGモジュールに関する彼の徹底的なYANG Doctorレビューは貴重なインプットです。 David Ballは、RFC 8049に関する2番目のレビューも提供しました。
Many thanks to these people.
Many thanks to these people.
Contributors
貢献者
The authors would like to thank Rob Shakir for his major contributions to the initial modeling and use cases.
著者は、初期のモデリングとユースケースへの多大な貢献に対してRob Shakirに感謝します。
Adrian Farrel prepared the editorial revisions for this document.
Adrian Farrelがこのドキュメントの編集改訂を準備しました。
Authors' Addresses
著者のアドレス
Qin Wu (editor) Huawei Technologies
Q in W U（編集者）hu Aはテクノロジー
Email: bill.wu@huawei.com
Stephane Litkowski Orange Business Services
ステファンリトコウスキーオレンジビジネスサービス
Email: stephane.litkowski@orange.com
Luis Tomotaki Verizon
ぅいｓ ともたき ゔぇりぞん
Email: luis.tomotaki@verizon.com
Kenichi Ogaki KDDI Corporation
けにち おがき Ｋっぢ こｒぽらちおん
Email: ke-oogaki@kddi.com