Internet Engineering Task Force (IETF) B. Wen
Request for Comments: 8466 Comcast
Category: Standards Track G. Fioccola, Ed.
ISSN: 2070-1721 Telecom Italia
C. Xie
China Telecom
L. Jalil
Verizon
October 2018
Internet Engineering Task Force (IETF) B. Wen
Request for Comments: 8466 Comcast
Category: Standards Track G. Fioccola, Ed.
ISSN: 2070-1721 Telecom Italia
C. Xie
China Telecom
L. Jalil
Verizon
October 2018
A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery
第二层虚拟专用网（L2VPN）服务交付的YANG数据模型
Abstract
摘要
This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document.
本文档定义了一个数据模型，可用于配置第2层提供商提供的VPN服务。由管理系统将其作为输入并生成特定的配置模型，以配置不同的网络元素来提供服务。如何配置网络元素超出了本文档的范围。
The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624.
本文档中定义的YANG数据模型包括对点对点虚拟专用线服务（VPWSs）和多点虚拟专用局域网服务（VPLSs）的支持，这些服务使用RFCs 4761和6624中所述的标签分发协议（LDP）和边界网关协议（BGP）发信号的伪线。
The YANG data model defined in this document conforms to the Network Management Datastore Architecture defined in RFC 8342.
本文件中定义的YANG数据模型符合RFC 8342中定义的网络管理数据存储体系结构。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8466.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8466.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. Requirements Language . . . . . . . . . . . . . . . . 5
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The Layer 2 VPN Service Model . . . . . . . . . . . . . . . . 7
3.1. Layer 2 VPN Service Types . . . . . . . . . . . . . . . . 7
3.2. Layer 2 VPN Physical Network Topology . . . . . . . . . . 7
4. Service Data Model Usage . . . . . . . . . . . . . . . . . . 9
5. Design of the Data Model . . . . . . . . . . . . . . . . . . 11
5.1. Features and Augmentation . . . . . . . . . . . . . . . . 20
5.2. VPN Service Overview . . . . . . . . . . . . . . . . . . 20
5.2.1. VPN Service Type . . . . . . . . . . . . . . . . . . 21
5.2.2. VPN Service Topologies . . . . . . . . . . . . . . . 22
5.2.2.1. Route Target Allocation . . . . . . . . . . . . . 22
5.2.2.2. Any-to-Any . . . . . . . . . . . . . . . . . . . 22
5.2.2.3. Hub-and-Spoke . . . . . . . . . . . . . . . . . . 22
5.2.2.4. Hub-and-Spoke Disjoint . . . . . . . . . . . . . 23
5.2.3. Cloud Access . . . . . . . . . . . . . . . . . . . . 24
5.2.4. Extranet VPNs . . . . . . . . . . . . . . . . . . . . 27
5.2.5. Frame Delivery Service . . . . . . . . . . . . . . . 28
5.3. Site Overview . . . . . . . . . . . . . . . . . . . . . . 30
5.3.1. Devices and Locations . . . . . . . . . . . . . . . . 31
5.3.2. Site Network Accesses . . . . . . . . . . . . . . . . 32
5.3.2.1. Bearer . . . . . . . . . . . . . . . . . . . . . 33
5.3.2.2. Connection . . . . . . . . . . . . . . . . . . . 33
5.4. Site Roles . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. Requirements Language . . . . . . . . . . . . . . . . 5
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The Layer 2 VPN Service Model . . . . . . . . . . . . . . . . 7
3.1. Layer 2 VPN Service Types . . . . . . . . . . . . . . . . 7
3.2. Layer 2 VPN Physical Network Topology . . . . . . . . . . 7
4. Service Data Model Usage . . . . . . . . . . . . . . . . . . 9
5. Design of the Data Model . . . . . . . . . . . . . . . . . . 11
5.1. Features and Augmentation . . . . . . . . . . . . . . . . 20
5.2. VPN Service Overview . . . . . . . . . . . . . . . . . . 20
5.2.1. VPN Service Type . . . . . . . . . . . . . . . . . . 21
5.2.2. VPN Service Topologies . . . . . . . . . . . . . . . 22
5.2.2.1. Route Target Allocation . . . . . . . . . . . . . 22
5.2.2.2. Any-to-Any . . . . . . . . . . . . . . . . . . . 22
5.2.2.3. Hub-and-Spoke . . . . . . . . . . . . . . . . . . 22
5.2.2.4. Hub-and-Spoke Disjoint . . . . . . . . . . . . . 23
5.2.3. Cloud Access . . . . . . . . . . . . . . . . . . . . 24
5.2.4. Extranet VPNs . . . . . . . . . . . . . . . . . . . . 27
5.2.5. Frame Delivery Service . . . . . . . . . . . . . . . 28
5.3. Site Overview . . . . . . . . . . . . . . . . . . . . . . 30
5.3.1. Devices and Locations . . . . . . . . . . . . . . . . 31
5.3.2. Site Network Accesses . . . . . . . . . . . . . . . . 32
5.3.2.1. Bearer . . . . . . . . . . . . . . . . . . . . . 33
5.3.2.2. Connection . . . . . . . . . . . . . . . . . . . 33
5.4. Site Roles . . . . . . . . . . . . . . . . . . . . . . . 38
5.5. Site Belonging to Multiple VPNs . . . . . . . . . . . . . 38
5.5.1. Site VPN Flavors . . . . . . . . . . . . . . . . . . 38
5.5.1.1. Single VPN Attachment: site-vpn-flavor-single . . 39
5.5.1.2. Multi-VPN Attachment: site-vpn-flavor-multi . . . 39
5.5.1.3. NNI: site-vpn-flavor-nni . . . . . . . . . . . . 40
5.5.1.4. E2E: site-vpn-flavor-e2e . . . . . . . . . . . . 41
5.5.2. Attaching a Site to a VPN . . . . . . . . . . . . . . 41
5.5.2.1. Referencing a VPN . . . . . . . . . . . . . . . . 41
5.5.2.2. VPN Policy . . . . . . . . . . . . . . . . . . . 43
5.6. Deciding Where to Connect the Site . . . . . . . . . . . 48
5.6.1. Constraint: Device . . . . . . . . . . . . . . . . . 49
5.6.2. Constraint/Parameter: Site Location . . . . . . . . . 50
5.6.3. Constraint/Parameter: Access Type . . . . . . . . . . 51
5.6.4. Constraint: Access Diversity . . . . . . . . . . . . 52
5.7. Route Distinguisher and Network Instance Allocation . . . 53
5.8. Site-Network-Access Availability . . . . . . . . . . . . 54
5.9. SVC MTU . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.10. Service . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.10.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . 56
5.10.2. QoS . . . . . . . . . . . . . . . . . . . . . . . . 57
5.10.2.1. QoS Classification . . . . . . . . . . . . . . . 57
5.10.2.2. QoS Profile . . . . . . . . . . . . . . . . . . 58
5.10.3. Support for BUM . . . . . . . . . . . . . . . . . . 59
5.11. Site Management . . . . . . . . . . . . . . . . . . . . . 60
5.12. MAC Loop Protection . . . . . . . . . . . . . . . . . . . 61
5.13. MAC Address Limit . . . . . . . . . . . . . . . . . . . . 61
5.14. Enhanced VPN Features . . . . . . . . . . . . . . . . . . 62
5.14.1. Carriers' Carriers . . . . . . . . . . . . . . . . . 62
5.15. External ID References . . . . . . . . . . . . . . . . . 63
5.16. Defining NNIs and Inter-AS Support . . . . . . . . . . . 64
5.16.1. Defining an NNI with the Option A Flavor . . . . . . 66
5.16.2. Defining an NNI with the Option B Flavor . . . . . . 70
5.16.3. Defining an NNI with the Option C Flavor . . . . . . 73
5.17. Applicability of L2SM in Inter-provider and Inter-domain
Orchestration . . . . . . . . . . . . . . . . . . . . . . 74
6. Interaction with Other YANG Modules . . . . . . . . . . . . . 76
7. Service Model Usage Example . . . . . . . . . . . . . . . . . 77
8. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 82
9. Security Considerations . . . . . . . . . . . . . . . . . . . 152
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 153
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 153
11.1. Normative References . . . . . . . . . . . . . . . . . . 153
11.2. Informative References . . . . . . . . . . . . . . . . . 155
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 157
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 158
5.5. Site Belonging to Multiple VPNs . . . . . . . . . . . . . 38
5.5.1. Site VPN Flavors . . . . . . . . . . . . . . . . . . 38
5.5.1.1. Single VPN Attachment: site-vpn-flavor-single . . 39
5.5.1.2. Multi-VPN Attachment: site-vpn-flavor-multi . . . 39
5.5.1.3. NNI: site-vpn-flavor-nni . . . . . . . . . . . . 40
5.5.1.4. E2E: site-vpn-flavor-e2e . . . . . . . . . . . . 41
5.5.2. Attaching a Site to a VPN . . . . . . . . . . . . . . 41
5.5.2.1. Referencing a VPN . . . . . . . . . . . . . . . . 41
5.5.2.2. VPN Policy . . . . . . . . . . . . . . . . . . . 43
5.6. Deciding Where to Connect the Site . . . . . . . . . . . 48
5.6.1. Constraint: Device . . . . . . . . . . . . . . . . . 49
5.6.2. Constraint/Parameter: Site Location . . . . . . . . . 50
5.6.3. Constraint/Parameter: Access Type . . . . . . . . . . 51
5.6.4. Constraint: Access Diversity . . . . . . . . . . . . 52
5.7. Route Distinguisher and Network Instance Allocation . . . 53
5.8. Site-Network-Access Availability . . . . . . . . . . . . 54
5.9. SVC MTU . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.10. Service . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.10.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . 56
5.10.2. QoS . . . . . . . . . . . . . . . . . . . . . . . . 57
5.10.2.1. QoS Classification . . . . . . . . . . . . . . . 57
5.10.2.2. QoS Profile . . . . . . . . . . . . . . . . . . 58
5.10.3. Support for BUM . . . . . . . . . . . . . . . . . . 59
5.11. Site Management . . . . . . . . . . . . . . . . . . . . . 60
5.12. MAC Loop Protection . . . . . . . . . . . . . . . . . . . 61
5.13. MAC Address Limit . . . . . . . . . . . . . . . . . . . . 61
5.14. Enhanced VPN Features . . . . . . . . . . . . . . . . . . 62
5.14.1. Carriers' Carriers . . . . . . . . . . . . . . . . . 62
5.15. External ID References . . . . . . . . . . . . . . . . . 63
5.16. Defining NNIs and Inter-AS Support . . . . . . . . . . . 64
5.16.1. Defining an NNI with the Option A Flavor . . . . . . 66
5.16.2. Defining an NNI with the Option B Flavor . . . . . . 70
5.16.3. Defining an NNI with the Option C Flavor . . . . . . 73
5.17. Applicability of L2SM in Inter-provider and Inter-domain
Orchestration . . . . . . . . . . . . . . . . . . . . . . 74
6. Interaction with Other YANG Modules . . . . . . . . . . . . . 76
7. Service Model Usage Example . . . . . . . . . . . . . . . . . 77
8. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 82
9. Security Considerations . . . . . . . . . . . . . . . . . . . 152
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 153
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 153
11.1. Normative References . . . . . . . . . . . . . . . . . . 153
11.2. Informative References . . . . . . . . . . . . . . . . . 155
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 157
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 158
This document defines a YANG data model for the Layer 2 VPN (L2VPN) service. This 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 and can generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document.
本文档定义了第2层VPN（L2VPN）服务的数据模型。该模型定义了可用于客户和网络运营商之间通信协议的服务配置元素。这些元素还可以用作自动控制和配置应用程序的输入，并可以生成特定的配置模型，以配置不同的网络元素以提供服务。如何配置网络元素超出了本文档的范围。
Further discussion of the way that services are modeled in YANG and the relationship between "customer service models" like the one described in this document and configuration models can be found in [RFC8309] and [RFC8199]. Sections 4 and 6 also provide more information on how this service model could be used and how it fits into the overall modeling architecture.
[RFC8309]和[RFC8199]中进一步讨论了YANG中的服务建模方式以及本文档中描述的“客户服务模型”与配置模型之间的关系。第4节和第6节还提供了有关如何使用此服务模型以及如何将其融入总体建模体系结构的更多信息。
The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in [RFC4761] and [RFC6624]. It also conforms to the Network Management Datastore Architecture (NMDA) [RFC8342].
本文件中定义的YANG数据模型包括对点对点虚拟专用线服务（VPWSs）和多点虚拟专用局域网服务（VPLSs）的支持，这些服务使用[RFC4761]和[RFC6624]中所述的标签分发协议（LDP）和边界网关协议（BGP）发信号的伪线。它还符合网络管理数据存储体系结构（NMDA）[RFC8342]。
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]。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Tree diagrams used in this document follow the notation defined in [RFC8340].
本文档中使用的树形图遵循[RFC8340]中定义的符号。
This document uses the following terms:
本文件使用以下术语：
Service Provider (SP): The organization (usually a commercial undertaking) responsible for operating the network that offers VPN services to clients and customers.
服务提供商（SP）：负责运营向客户和客户提供VPN服务的网络的组织（通常是商业企业）。
Customer Edge (CE) Device: Equipment that is dedicated to a particular customer and is directly connected to one or more PE devices via Attachment Circuits (ACs). 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 ACs. The CE devices can be routers, bridges, switches, or hosts.
客户边缘（CE）设备：专用于特定客户的设备，通过连接电路（ACs）直接连接到一个或多个PE设备。CE通常位于客户场所，通常专用于单个VPN，但如果每个VPN都有单独的ACs，则可能支持多个VPN。CE设备可以是路由器、网桥、交换机或主机。
Provider Edge (PE) Device: Equipment managed by the SP that can support multiple VPNs for different customers and is directly connected to one or more CE devices via ACs. A PE is usually located at an SP Point of Presence (POP) and is managed by the SP.
提供商边缘（PE）设备：由SP管理的设备，可支持不同客户的多个VPN，并通过ACs直接连接到一个或多个CE设备。PE通常位于SP存在点（POP），由SP管理。
Virtual Private LAN Service (VPLS): A VPLS is a provider service that emulates the full functionality of a traditional LAN. A VPLS makes it possible to interconnect several LAN segments over a packet switched network (PSN) and makes the remote LAN segments behave as one single LAN.
虚拟专用LAN服务（VPLS）：VPLS是一种模拟传统LAN全部功能的提供商服务。VPLS使通过分组交换网络（PSN）互连多个LAN段成为可能，并使远程LAN段表现为单个LAN。
Virtual Private Wire Service (VPWS): A VPWS is a point-to-point circuit (i.e., link) connecting two CE devices. The link is established as a logical Layer 2 circuit through a PSN. The CE in the customer network is connected to a PE in the provider network via an AC: the AC is either a physical or logical circuit. A VPWS
虚拟专用线服务（VPWS）：VPWS是连接两个CE设备的点对点电路（即链路）。链路通过PSN建立为逻辑第2层电路。客户网络中的CE通过AC连接到提供商网络中的PE：AC是物理或逻辑电路。VPWS
differs from a VPLS in that the VPLS is point-to-multipoint while the VPWS is point-to-point. In some implementations, a set of VPWSs is used to create a multi-site L2VPN network.
与VPLS的不同之处在于，VPLS是点对多点的，而VPWS是点对点的。在一些实现中，使用一组VPW创建多站点L2VPN网络。
Pseudowire (PW): A Pseudowire is an emulation of a native service over a PSN. The native service may be ATM, Frame Relay, Ethernet, low-rate Time-Division Multiplexing (TDM), or Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH), while the PSN may be MPLS, IP (either IPv4 or IPv6), or Layer 2 Tunneling Protocol version 3 (L2TPv3).
Pseudowire（PW）：Pseudowire是PSN上本机服务的模拟。本机服务可以是ATM、帧中继、以太网、低速率时分复用（TDM）或同步光网络/同步数字体系（SONET/SDH），而PSN可以是MPLS、IP（IPv4或IPv6）或第2层隧道协议版本3（L2TPv3）。
MAC-VRF: A Virtual Routing and Forwarding table for Media Access Control (MAC) addresses on a PE. It is sometimes also referred to as a Virtual Switching Instance (VSI).
MAC-VRF：PE上媒体访问控制（MAC）地址的虚拟路由和转发表。它有时也称为虚拟交换实例（VSI）。
UNI: User-to-Network Interface. The physical demarcation point between the customer's area of responsibility and the provider's area of responsibility.
UNI：用户到网络接口。客户责任区和供应商责任区之间的物理分界点。
NNI: Network-to-Network Interface. A reference point representing the boundary between two networks that are operated as separate administrative domains. The two networks may belong to the same provider or to two different providers.
NNI：网络到网络接口。表示作为独立管理域运行的两个网络之间边界的参考点。这两个网络可能属于同一个提供商，也可能属于两个不同的提供商。
This document uses the following abbreviations:
本文件使用以下缩写：
BSS: Business Support System
业务支持系统
BUM: Broadcast, Unknown Unicast, or Multicast
BUM：广播、未知单播或多播
CoS: Class of Service
服务类别
LAG: Link Aggregation Group
滞后：链路聚合组
LLDP: Link Layer Discovery Protocol
链路层发现协议
OAM: Operations, Administration, and Maintenance
OAM：运营、管理和维护
OSS: Operations Support System
操作支持系统
PDU: Protocol Data Unit
协议数据单元
QoS: Quality of Service
QoS：服务质量
A Layer 2 VPN (L2VPN) service is a collection of sites that are authorized to exchange traffic between each other over a shared infrastructure of a common technology. The L2VPN Service Model (L2SM) described in this document provides a common understanding of how the corresponding L2VPN service is to be deployed over the shared infrastructure.
第2层VPN（L2VPN）服务是一组站点，这些站点被授权通过一种通用技术的共享基础设施在彼此之间交换流量。本文档中描述的L2VPN服务模型（L2SM）提供了如何在共享基础设施上部署相应L2VPN服务的共识。
This document presents the L2SM using the YANG data modeling language [RFC7950] as a formal language that is both human readable and parsable by software for use with protocols such as the Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040].
本文档使用YANG数据建模语言[RFC7950]作为一种形式化语言介绍L2SM，该语言既可供人阅读，也可由软件解析，用于网络配置协议（NETCONF）[RFC6241]和RESTCONF[RFC8040]等协议。
This service model is limited to VPWS-based VPNs and VPLS-based VPNs as described in [RFC4761] and [RFC6624] and to Ethernet VPNs (EVPNs) as described in [RFC7432].
此服务模型仅限于[RFC4761]和[RFC6624]中所述的基于VPWS的VPN和基于VPLS的VPN，以及[RFC7432]中所述的以太网VPN（EVPN）。
From a technology perspective, a set of basic L2VPN service types include:
从技术角度来看，一组基本L2VPN服务类型包括：
o Point-to-point VPWSs that use LDP-signaled Pseudowires or L2TP-signaled Pseudowires [RFC6074].
o 使用LDP信号伪线或L2TP信号伪线的点对点VPW[RFC6074]。
o Multipoint VPLSs that use LDP-signaled Pseudowires or L2TP-signaled Pseudowires [RFC6074].
o 使用LDP信号伪线或L2TP信号伪线的多点VPLS[RFC6074]。
o Multipoint VPLSs that use a BGP control plane as described in [RFC4761] and [RFC6624].
o 使用[RFC4761]和[RFC6624]中所述BGP控制平面的多点VPL。
o IP-only LAN Services (IPLSs) that are a functional subset of VPLS services [RFC7436].
o 仅限IP的LAN服务（IPLSs），是VPLS服务的功能子集[RFC7436]。
o BGP MPLS-based EVPN services as described in [RFC7432] and [RFC7209].
o [RFC7432]和[RFC7209]中所述的基于BGP MPLS的EVPN服务。
o EVPN VPWSs as specified in [RFC8214].
o [RFC8214]中规定的EVPN VPWSs。
Figure 1 below depicts a typical SP's physical network topology. Most SPs have deployed an IP, MPLS, or Segment Routing (SR) multi-service core infrastructure. Ingress Layer 2 service frames will be mapped to either an Ethernet Pseudowire (e.g., Pseudowire Emulation Edge to Edge (PWE3)) or a Virtual Extensible Local Area
下图1描述了一个典型SP的物理网络拓扑。大多数SP都部署了IP、MPLS或段路由（SR）多服务核心基础设施。入口第2层服务帧将映射到以太网伪线（例如，伪线仿真边到边（PWE3））或虚拟可扩展局域网
Network (VXLAN) PE-to-PE tunnel. The details of these tunneling mechanisms are left to the provider's discretion and are not part of the L2SM.
网络（VXLAN）PE到PE隧道。这些隧道机制的细节由提供商自行决定，不属于L2SM的一部分。
An L2VPN provides end-to-end Layer 2 connectivity over this multi-service core infrastructure between two or more customer locations or a collection of sites. ACs are placed between CE devices and PE devices that backhaul Layer 2 service frames from the customer over the access network to the provider network or remote site. The demarcation point (i.e., UNI) between the customer and the SP can be placed between either (1) customer nodes and the CE device or (2) the CE device and the PE device. The actual bearer connection between the CE and the PE will be described in the L2SM.
L2VPN通过此多服务核心基础架构在两个或多个客户位置或站点集合之间提供端到端的第2层连接。AC放置在CE设备和PE设备之间，通过接入网络将第2层服务帧从客户回程到提供商网络或远程站点。客户和SP之间的分界点（即UNI）可以位于（1）客户节点和CE设备或（2）CE设备和PE设备之间。CE和PE之间的实际承载连接将在L2SM中描述。
The SP may also choose a "seamless MPLS" approach to expand the PWE3 or VXLAN tunnel between sites.
SP还可以选择“无缝MPLS”方法来扩展站点之间的PWE3或VXLAN隧道。
The SP may leverage Multiprotocol BGP (MP-BGP) to autodiscover and signal the PWE3 or VXLAN tunnel endpoints.
SP可利用多协议BGP（MP-BGP）自动发现PWE3或VXLAN隧道端点并向其发送信号。
Site A | |Site B
--- ---- | VXLAN/PW | ---
| | | | |<------------------------>| | |
| C +---+ CE | | | | C |
| | | | | --------- | | |
--- ----\ | ( ) | /---
\ -|-- ( ) -|-- ---- /
\| | ( ) | | | |/
| PE +---+ IP/MPLS/SR +---+ PE +---+ CE |
/| | ( Network ) | | | |\
/ ---- ( ) ---- ---- \
--- ----/ ( ) \---
| | | | ----+---- | |
| C +---+ CE | | | C |
| | | | --+-- | |
--- ---- | PE | ---
--+--
| Site C
--+--
| CE |
--+--
|
--+--
| C |
-----
Site A | |Site B
--- ---- | VXLAN/PW | ---
| | | | |<------------------------>| | |
| C +---+ CE | | | | C |
| | | | | --------- | | |
--- ----\ | ( ) | /---
\ -|-- ( ) -|-- ---- /
\| | ( ) | | | |/
| PE +---+ IP/MPLS/SR +---+ PE +---+ CE |
/| | ( Network ) | | | |\
/ ---- ( ) ---- ---- \
--- ----/ ( ) \---
| | | | ----+---- | |
| C +---+ CE | | | C |
| | | | --+-- | |
--- ---- | PE | ---
--+--
| Site C
--+--
| CE |
--+--
|
--+--
| C |
-----
Figure 1: Reference Network for the Use of the L2SM
图1：L2SM使用的参考网络
From the customer's perspective, however, all the CE devices are connected over a simulated LAN environment as shown in Figure 2. Broadcast and multicast packets are sent to all participants in the same bridge domain.
然而，从客户的角度来看，所有CE设备都是通过模拟LAN环境连接的，如图2所示。广播和多播数据包被发送到同一网桥域中的所有参与者。
CE---+----+-----+---CE
| | |
| | |
| | |
CE---+ CE +---CE
CE---+----+-----+---CE
| | |
| | |
| | |
CE---+ CE +---CE
Figure 2: Customer's View of the L2VPN
图2:L2VPN的客户视图
The L2SM provides an abstracted interface to request, configure, and manage the components of an L2VPN service. The model is used by a customer who purchases connectivity and other services from an SP to communicate with that SP.
L2SM提供了一个抽象接口来请求、配置和管理L2VPN服务的组件。从SP购买连接和其他服务的客户使用该模型与该SP通信。
A typical usage for this model is as an input to an orchestration layer that is responsible for translating it into configuration commands for the network elements that deliver/enable the service. The network elements may be routers, but also servers (like Authentication, Authorization, and Accounting (AAA)) that are necessary within the network.
此模型的典型用法是作为编排层的输入，编排层负责将其转换为用于交付/启用服务的网络元素的配置命令。网络元件可以是路由器，但也可以是网络内必需的服务器（例如认证、授权和记帐（AAA））。
The configuration of network elements may be done using the Command Line Interface (CLI) or any other configuration (or "southbound") interface such as NETCONF [RFC6241] in combination with device-specific and protocol-specific YANG data models.
可以使用命令行界面（CLI）或任何其他配置（或“南行”）界面（如NETCONF[RFC6241]）结合特定于设备和特定于协议的数据模型来完成网元的配置。
This way of using the service model is illustrated in Figure 3 and is described in more detail in [RFC8309] and [RFC8199]. The split of the orchestration function between a "service orchestrator" and a "network orchestrator" is clarified in [RFC8309]. 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.
这种使用服务模型的方式如图3所示，在[RFC8309]和[RFC8199]中有更详细的描述。[RFC8309]中阐明了“服务编排器”和“网络编排器”之间编排功能的划分。此服务模型的使用不限于此示例：它可以由管理系统的任何组件使用，但不能直接由网络元素使用。
The usage and structure of this model should be compared to the Layer 3 VPN service model defined in [RFC8299].
此模型的用法和结构应与[RFC8299]中定义的第3层VPN服务模型进行比较。
----------------------------
| Customer Service Requester |
----------------------------
|
|
L2SM |
|
|
-----------------------
| Service Orchestration |
-----------------------
|
| Service +-------------+
| Delivery +------>| Application |
| Model | | BSS/OSS |
| V +-------------+
-----------------------
| Network Orchestration |
-----------------------
| |
+----------------+ |
| Config manager | |
+----------------+ | Device
| | Models
| |
--------------------------------------------
Network
+++++++
+ AAA +
+++++++
----------------------------
| Customer Service Requester |
----------------------------
|
|
L2SM |
|
|
-----------------------
| Service Orchestration |
-----------------------
|
| Service +-------------+
| Delivery +------>| Application |
| Model | | BSS/OSS |
| V +-------------+
-----------------------
| Network Orchestration |
-----------------------
| |
+----------------+ |
| Config manager | |
+----------------+ | Device
| | Models
| |
--------------------------------------------
Network
+++++++
+ AAA +
+++++++
++++++++ Bearer ++++++++ ++++++++ ++++++++
+ CE A + ----------- + PE A + + PE B + ---- + CE B +
++++++++ Connection ++++++++ ++++++++ ++++++++
++++++++ Bearer ++++++++ ++++++++ ++++++++
+ CE A + ----------- + PE A + + PE B + ---- + CE B +
++++++++ Connection ++++++++ ++++++++ ++++++++
Site A Site B
场地A场地B
Figure 3: Reference Architecture for the Use of the L2SM
图3：L2SM使用的参考体系结构
The Metro Ethernet Forum (MEF) [MEF-6] has also developed an architecture for network management and operations, but the work of the MEF embraces all aspects of lifecycle service orchestration, including billing, Service Level Agreements (SLAs), order management, and lifecycle management. The IETF's work on service models is typically smaller and offers a simple, self-contained service YANG module. See [RFC8309] for more details.
Metro Ethernet Forum（MEF）[MEF-6]还开发了一种网络管理和运营架构，但MEF的工作涵盖了生命周期服务编排的所有方面，包括计费、服务水平协议（SLA）、订单管理和生命周期管理。IETF在服务模型方面的工作通常较小，并且提供了一个简单、自包含的服务模块。有关更多详细信息，请参阅[RFC8309]。
The L2SM is structured in a way that allows the provider to list multiple circuits of various service types for the same customer. A circuit represents an end-to-end connection between two or more customer locations.
L2SM的结构允许提供商为同一客户列出不同服务类型的多条线路。电路表示两个或多个客户位置之间的端到端连接。
The YANG module is divided into two main containers: "vpn-services" and "sites". The "vpn-svc" container under vpn-services defines global parameters for the VPN service for a specific customer.
YANG模块分为两个主要容器：“vpn服务”和“站点”。vpn服务下的“vpn svc”容器为特定客户的vpn服务定义全局参数。
A site contains at least one network access (i.e., site network accesses providing access to the sites, as defined in Section 5.3.2), and there may be multiple network accesses in the case of multihoming. Site-to-network-access attachment is done through a bearer with a Layer 2 connection on top. The bearer refers to properties of the attachment that are below Layer 2, while the connection refers to Layer 2 protocol-oriented properties. The bearer may be allocated dynamically by the SP, and the customer may provide some constraints or parameters to drive the placement.
一个站点至少包含一个网络访问（即，根据第5.3.2节的定义，提供对站点访问的站点网络访问），并且在多主的情况下可能有多个网络访问。站点到网络的访问连接是通过一个在顶部有第2层连接的承载来完成的。承载指的是第2层之下的附件属性，而连接指的是面向第2层协议的属性。承载可以由SP动态分配，并且客户可以提供一些约束或参数来驱动放置。
Authorization of traffic exchanges is done through what we call a VPN policy or VPN topology that defines routing exchange rules between sites.
流量交换的授权是通过定义站点间路由交换规则的VPN策略或VPN拓扑来完成的。
End-to-end multi-segment connectivity can be realized by using a combination of per-site connectivity and per-segment connectivity at different segments.
端到端多段连接可通过在不同段上使用每站点连接和每段连接的组合来实现。
Figure 4 shows the overall structure of the YANG module:
图4显示了YANG模块的总体结构：
module: ietf-l2vpn-svc
+--rw l2vpn-svc
+--rw vpn-profiles
| +--rw valid-provider-identifiers
| +--rw cloud-identifier* string{cloud-access}?
| +--rw qos-profile-identifier* string
| +--rw bfd-profile-identifier* string
| +--rw remote-carrier-identifier* string
+--rw vpn-services
| +--rw vpn-service* [vpn-id]
| +--rw vpn-id svc-id
| +--rw vpn-svc-type? identityref
| +--rw customer-name? string
| +--rw svc-topo? identityref
| +--rw cloud-accesses {cloud-access}?
| | +--rw cloud-access* [cloud-identifier]
| | +--rw cloud-identifier
module: ietf-l2vpn-svc
+--rw l2vpn-svc
+--rw vpn-profiles
| +--rw valid-provider-identifiers
| +--rw cloud-identifier* string{cloud-access}?
| +--rw qos-profile-identifier* string
| +--rw bfd-profile-identifier* string
| +--rw remote-carrier-identifier* string
+--rw vpn-services
| +--rw vpn-service* [vpn-id]
| +--rw vpn-id svc-id
| +--rw vpn-svc-type? identityref
| +--rw customer-name? string
| +--rw svc-topo? identityref
| +--rw cloud-accesses {cloud-access}?
| | +--rw cloud-access* [cloud-identifier]
| | +--rw cloud-identifier
| | | -> /l2vpn-svc/vpn-profiles/
| | | valid-provider-identifiers/cloud-identifier
| | +--rw (list-flavor)?
| | +--:(permit-any)
| | | +--rw permit-any? empty
| | +--:(deny-any-except)
| | | +--rw permit-site*
| | | : -> /l2vpn-svc/sites/site/site-id
| | +--:(permit-any-except)
| | +--rw deny-site*
| | -> /l2vpn-svc/sites/site/site-id
| +--rw frame-delivery {frame-delivery}?
| | +--rw customer-tree-flavors
| | | +--rw tree-flavor* identityref
| | +--rw bum-frame-delivery
| | | +--rw bum-frame-delivery* [frame-type]
| | | +--rw frame-type identityref
| | | +--rw delivery-mode? identityref
| | +--rw multicast-gp-port-mapping identityref
| +--rw extranet-vpns {extranet-vpn}?
| | +--rw extranet-vpn* [vpn-id]
| | +--rw vpn-id svc-id
| | +--rw local-sites-role? identityref
| +--rw ce-vlan-preservation boolean
| +--rw ce-vlan-cos-preservation boolean
| +--rw carrierscarrier? boolean {carrierscarrier}?
+--rw sites
+--rw site* [site-id]
+--rw site-id string
+--rw site-vpn-flavor? identityref
+--rw devices
| +--rw device* [device-id]
| +--rw device-id string
| +--rw location
| | -> ../../../locations/location/location-id
| +--rw management
| +--rw transport? identityref
| +--rw address? inet:ip-address
+--rw management
| +--rw type identityref
+--rw locations
| +--rw location* [location-id]
| +--rw location-id string
| +--rw address? string
| +--rw postal-code? string
| +--rw state? string
| +--rw city? string
| +--rw country-code? string
| | | -> /l2vpn-svc/vpn-profiles/
| | | valid-provider-identifiers/cloud-identifier
| | +--rw (list-flavor)?
| | +--:(permit-any)
| | | +--rw permit-any? empty
| | +--:(deny-any-except)
| | | +--rw permit-site*
| | | : -> /l2vpn-svc/sites/site/site-id
| | +--:(permit-any-except)
| | +--rw deny-site*
| | -> /l2vpn-svc/sites/site/site-id
| +--rw frame-delivery {frame-delivery}?
| | +--rw customer-tree-flavors
| | | +--rw tree-flavor* identityref
| | +--rw bum-frame-delivery
| | | +--rw bum-frame-delivery* [frame-type]
| | | +--rw frame-type identityref
| | | +--rw delivery-mode? identityref
| | +--rw multicast-gp-port-mapping identityref
| +--rw extranet-vpns {extranet-vpn}?
| | +--rw extranet-vpn* [vpn-id]
| | +--rw vpn-id svc-id
| | +--rw local-sites-role? identityref
| +--rw ce-vlan-preservation boolean
| +--rw ce-vlan-cos-preservation boolean
| +--rw carrierscarrier? boolean {carrierscarrier}?
+--rw sites
+--rw site* [site-id]
+--rw site-id string
+--rw site-vpn-flavor? identityref
+--rw devices
| +--rw device* [device-id]
| +--rw device-id string
| +--rw location
| | -> ../../../locations/location/location-id
| +--rw management
| +--rw transport? identityref
| +--rw address? inet:ip-address
+--rw management
| +--rw type identityref
+--rw locations
| +--rw location* [location-id]
| +--rw location-id string
| +--rw address? string
| +--rw postal-code? string
| +--rw state? string
| +--rw city? string
| +--rw country-code? string
+--rw site-diversity {site-diversity}?
| +--rw groups
| +--rw group* [group-id]
| +--rw group-id string
+--rw vpn-policies
| +--rw vpn-policy* [vpn-policy-id]
| +--rw vpn-policy-id string
| +--rw entries* [id]
| +--rw id string
| +--rw filters
| | +--rw filter* [type]
| | +--rw type identityref
| | +--rw lan-tag* uint32 {lan-tag}?
| +--rw vpn* [vpn-id]
| +--rw vpn-id
| | -> /l2vpn-svc/vpn-services/
| | vpn-service/vpn-id
| +--rw site-role? identityref
+--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 dot1q? uint16
| | | | | +--rw pcp? uint8
| | | | | +--rw src-mac? yang:mac-address
| | | | | +--rw dst-mac? yang:mac-address
| | | | | +--rw color-type? identityref
| | | | | +--rw target-sites*
| | | | | | svc-id {target-sites}?
| | | | | +--rw any? empty
| | | | | +--rw vpn-id? svc-id
| | | | +--:(match-application)
| | | | +--rw match-application? identityref
| | | +--rw target-class-id? string
| | +--rw qos-profile
| | +--rw (qos-profile)?
| | +--:(standard)
| | | +--rw profile?
| | | -> /l2vpn-svc/vpn-profiles/
| | | valid-provider-identifiers/
| | | qos-profile-identifier
| | +--:(custom)
| | +--rw classes {qos-custom}?
+--rw site-diversity {site-diversity}?
| +--rw groups
| +--rw group* [group-id]
| +--rw group-id string
+--rw vpn-policies
| +--rw vpn-policy* [vpn-policy-id]
| +--rw vpn-policy-id string
| +--rw entries* [id]
| +--rw id string
| +--rw filters
| | +--rw filter* [type]
| | +--rw type identityref
| | +--rw lan-tag* uint32 {lan-tag}?
| +--rw vpn* [vpn-id]
| +--rw vpn-id
| | -> /l2vpn-svc/vpn-services/
| | vpn-service/vpn-id
| +--rw site-role? identityref
+--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 dot1q? uint16
| | | | | +--rw pcp? uint8
| | | | | +--rw src-mac? yang:mac-address
| | | | | +--rw dst-mac? yang:mac-address
| | | | | +--rw color-type? identityref
| | | | | +--rw target-sites*
| | | | | | svc-id {target-sites}?
| | | | | +--rw any? empty
| | | | | +--rw vpn-id? svc-id
| | | | +--:(match-application)
| | | | +--rw match-application? identityref
| | | +--rw target-class-id? string
| | +--rw qos-profile
| | +--rw (qos-profile)?
| | +--:(standard)
| | | +--rw profile?
| | | -> /l2vpn-svc/vpn-profiles/
| | | valid-provider-identifiers/
| | | qos-profile-identifier
| | +--:(custom)
| | +--rw classes {qos-custom}?
| | +--rw class* [class-id]
| | +--rw class-id string
| | +--rw direction? identityref
| | +--rw policing? identityref
| | +--rw byte-offset? uint16
| | +--rw frame-delay
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-latency? empty
| | | +--:(boundary)
| | | +--rw delay-bound? uint16
| | +--rw frame-jitter
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-jitter? empty
| | | +--:(boundary)
| | | +--rw delay-bound? uint32
| | +--rw frame-loss
| | | +--rw rate? decimal64
| | +--rw bandwidth
| | +--rw guaranteed-bw-percent decimal64
| | +--rw end-to-end? empty
| +--rw carrierscarrier {carrierscarrier}?
| +--rw signaling-type? identityref
+--rw broadcast-unknown-unicast-multicast {bum}?
| +--rw multicast-site-type? enumeration
| +--rw multicast-gp-address-mapping* [id]
| | +--rw id uint16
| | +--rw vlan-id uint16
| | +--rw mac-gp-address yang:mac-address
| | +--rw port-lag-number? uint32
| +--rw bum-overall-rate? uint32
| +--rw bum-rate-per-type* [type]
| +--rw type identityref
| +--rw rate? uint32
+--rw mac-loop-prevention {mac-loop-prevention}?
| +--rw protection-type? identityref
| +--rw frequency? uint32
| +--rw retry-timer? uint32
+--rw access-control-list
| +--rw mac* [mac-address]
| +--rw mac-address yang:mac-address
+--ro actual-site-start? yang:date-and-time
+--ro actual-site-stop? yang:date-and-time
+--rw bundling-type? identityref
+--rw default-ce-vlan-id uint32
+--rw site-network-accesses
+--rw site-network-access* [network-access-id]
| | +--rw class* [class-id]
| | +--rw class-id string
| | +--rw direction? identityref
| | +--rw policing? identityref
| | +--rw byte-offset? uint16
| | +--rw frame-delay
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-latency? empty
| | | +--:(boundary)
| | | +--rw delay-bound? uint16
| | +--rw frame-jitter
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-jitter? empty
| | | +--:(boundary)
| | | +--rw delay-bound? uint32
| | +--rw frame-loss
| | | +--rw rate? decimal64
| | +--rw bandwidth
| | +--rw guaranteed-bw-percent decimal64
| | +--rw end-to-end? empty
| +--rw carrierscarrier {carrierscarrier}?
| +--rw signaling-type? identityref
+--rw broadcast-unknown-unicast-multicast {bum}?
| +--rw multicast-site-type? enumeration
| +--rw multicast-gp-address-mapping* [id]
| | +--rw id uint16
| | +--rw vlan-id uint16
| | +--rw mac-gp-address yang:mac-address
| | +--rw port-lag-number? uint32
| +--rw bum-overall-rate? uint32
| +--rw bum-rate-per-type* [type]
| +--rw type identityref
| +--rw rate? uint32
+--rw mac-loop-prevention {mac-loop-prevention}?
| +--rw protection-type? identityref
| +--rw frequency? uint32
| +--rw retry-timer? uint32
+--rw access-control-list
| +--rw mac* [mac-address]
| +--rw mac-address yang:mac-address
+--ro actual-site-start? yang:date-and-time
+--ro actual-site-stop? yang:date-and-time
+--rw bundling-type? identityref
+--rw default-ce-vlan-id uint32
+--rw site-network-accesses
+--rw site-network-access* [network-access-id]
+--rw network-access-id string
+--rw remote-carrier-name? string
+--rw type? identityref
+--rw (location-flavor)
| +--:(location)
| | +--rw location-reference?
| | -> ../../../locations/location/
| | location-id
| +--:(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 type? string
| | +--rw strict? boolean
| +--rw always-on? boolean {always-on}?
| +--rw bearer-reference? string {bearer-reference}?
+--rw connection
| +--rw encapsulation-type? identityref
| +--rw eth-inf-type? identityref
| +--rw tagged-interface
| | +--rw type? identityref
| | +--rw dot1q-vlan-tagged {dot1q}?
| | | +--rw tg-type? identityref
| | | +--rw cvlan-id uint16
| | +--rw priority-tagged
| | | +--rw tag-type? identityref
| | +--rw qinq {qinq}?
| | | +--rw tag-type? identityref
| | | +--rw svlan-id uint16
| | | +--rw cvlan-id uint16
| | +--rw qinany {qinany}?
+--rw network-access-id string
+--rw remote-carrier-name? string
+--rw type? identityref
+--rw (location-flavor)
| +--:(location)
| | +--rw location-reference?
| | -> ../../../locations/location/
| | location-id
| +--:(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 type? string
| | +--rw strict? boolean
| +--rw always-on? boolean {always-on}?
| +--rw bearer-reference? string {bearer-reference}?
+--rw connection
| +--rw encapsulation-type? identityref
| +--rw eth-inf-type? identityref
| +--rw tagged-interface
| | +--rw type? identityref
| | +--rw dot1q-vlan-tagged {dot1q}?
| | | +--rw tg-type? identityref
| | | +--rw cvlan-id uint16
| | +--rw priority-tagged
| | | +--rw tag-type? identityref
| | +--rw qinq {qinq}?
| | | +--rw tag-type? identityref
| | | +--rw svlan-id uint16
| | | +--rw cvlan-id uint16
| | +--rw qinany {qinany}?
| | | +--rw tag-type? identityref
| | | +--rw svlan-id uint16
| | +--rw vxlan {vxlan}?
| | +--rw vni-id uint32
| | +--rw peer-mode? identityref
| | +--rw peer-list* [peer-ip]
| | +--rw peer-ip inet:ip-address
| +--rw untagged-interface
| | +--rw speed? uint32
| | +--rw mode? neg-mode
| | +--rw phy-mtu? uint32
| | +--rw lldp? boolean
| | +--rw oam-802.3ah-link {oam-3ah}?
| | | +--rw enabled? boolean
| | +--rw uni-loop-prevention? boolean
| +--rw lag-interfaces {lag-interface}?
| | +--rw lag-interface* [index]
| | +--rw index string
| | +--rw lacp {lacp}?
| | +--rw enabled? boolean
| | +--rw mode? neg-mode
| | +--rw speed? uint32
| | +--rw mini-link-num? uint32
| | +--rw system-priority? uint16
| | +--rw micro-bfd {micro-bfd}?
| | | +--rw enabled? enumeration
| | | +--rw interval? uint32
| | | +--rw hold-timer? uint32
| | +--rw bfd {bfd}?
| | | +--rw enabled? boolean
| | | +--rw (holdtime)?
| | | +--:(profile)
| | | | +--rw profile-name?
| | | | -> /l2vpn-svc/
| | | | vpn-profiles/
| | | | valid-provider-identifiers/
| | | | bfd-profile-identifier
| | | +--:(fixed)
| | | +--rw fixed-value? uint32
| | +--rw member-links
| | | +--rw member-link* [name]
| | | +--rw name string
| | | +--rw speed? uint32
| | | +--rw mode? neg-mode
| | | +--rw link-mtu? uint32
| | | +--rw oam-802.3ah-link {oam-3ah}?
| | | +--rw enabled? boolean
| | +--rw flow-control? boolean
| | | +--rw tag-type? identityref
| | | +--rw svlan-id uint16
| | +--rw vxlan {vxlan}?
| | +--rw vni-id uint32
| | +--rw peer-mode? identityref
| | +--rw peer-list* [peer-ip]
| | +--rw peer-ip inet:ip-address
| +--rw untagged-interface
| | +--rw speed? uint32
| | +--rw mode? neg-mode
| | +--rw phy-mtu? uint32
| | +--rw lldp? boolean
| | +--rw oam-802.3ah-link {oam-3ah}?
| | | +--rw enabled? boolean
| | +--rw uni-loop-prevention? boolean
| +--rw lag-interfaces {lag-interface}?
| | +--rw lag-interface* [index]
| | +--rw index string
| | +--rw lacp {lacp}?
| | +--rw enabled? boolean
| | +--rw mode? neg-mode
| | +--rw speed? uint32
| | +--rw mini-link-num? uint32
| | +--rw system-priority? uint16
| | +--rw micro-bfd {micro-bfd}?
| | | +--rw enabled? enumeration
| | | +--rw interval? uint32
| | | +--rw hold-timer? uint32
| | +--rw bfd {bfd}?
| | | +--rw enabled? boolean
| | | +--rw (holdtime)?
| | | +--:(profile)
| | | | +--rw profile-name?
| | | | -> /l2vpn-svc/
| | | | vpn-profiles/
| | | | valid-provider-identifiers/
| | | | bfd-profile-identifier
| | | +--:(fixed)
| | | +--rw fixed-value? uint32
| | +--rw member-links
| | | +--rw member-link* [name]
| | | +--rw name string
| | | +--rw speed? uint32
| | | +--rw mode? neg-mode
| | | +--rw link-mtu? uint32
| | | +--rw oam-802.3ah-link {oam-3ah}?
| | | +--rw enabled? boolean
| | +--rw flow-control? boolean
| | +--rw lldp? boolean
| +--rw cvlan-id-to-svc-map* [svc-id]
| | +--rw svc-id
| | | -> /l2vpn-svc/vpn-services/vpn-service/
| | | vpn-id
| | +--rw cvlan-id* [vid]
| | +--rw vid uint16
| +--rw l2cp-control {l2cp-control}?
| | +--rw stp-rstp-mstp? control-mode
| | +--rw pause? control-mode
| | +--rw lacp-lamp? control-mode
| | +--rw link-oam? control-mode
| | +--rw esmc? control-mode
| | +--rw l2cp-802.1x? control-mode
| | +--rw e-lmi? control-mode
| | +--rw lldp? boolean
| | +--rw ptp-peer-delay? control-mode
| | +--rw garp-mrp? control-mode
| +--rw oam {oam}
| +--rw md-name string
| +--rw md-level uint16
| +--rw cfm-802.1-ag* [maid]
| | +--rw maid string
| | +--rw mep-id? uint32
| | +--rw mep-level? uint32
| | +--rw mep-up-down? enumeration
| | +--rw remote-mep-id? uint32
| | +--rw cos-for-cfm-pdus? uint32
| | +--rw ccm-interval? uint32
| | +--rw ccm-holdtime? uint32
| | +--rw alarm-priority-defect? identityref
| | +--rw ccm-p-bits-pri? ccm-priority-type
| +--rw y-1731* [maid]
| +--rw maid string
| +--rw mep-id? uint32
| +--rw type? identityref
| +--rw remote-mep-id? uint32
| +--rw message-period? uint32
| +--rw measurement-interval? uint32
| +--rw cos? uint32
| +--rw loss-measurement? boolean
| +--rw synthetic-loss-measurement? boolean
| +--rw delay-measurement
| | +--rw enable-dm? boolean
| | +--rw two-way? boolean
| +--rw frame-size? uint32
| +--rw session-type? enumeration
+--rw availability
| | +--rw lldp? boolean
| +--rw cvlan-id-to-svc-map* [svc-id]
| | +--rw svc-id
| | | -> /l2vpn-svc/vpn-services/vpn-service/
| | | vpn-id
| | +--rw cvlan-id* [vid]
| | +--rw vid uint16
| +--rw l2cp-control {l2cp-control}?
| | +--rw stp-rstp-mstp? control-mode
| | +--rw pause? control-mode
| | +--rw lacp-lamp? control-mode
| | +--rw link-oam? control-mode
| | +--rw esmc? control-mode
| | +--rw l2cp-802.1x? control-mode
| | +--rw e-lmi? control-mode
| | +--rw lldp? boolean
| | +--rw ptp-peer-delay? control-mode
| | +--rw garp-mrp? control-mode
| +--rw oam {oam}
| +--rw md-name string
| +--rw md-level uint16
| +--rw cfm-802.1-ag* [maid]
| | +--rw maid string
| | +--rw mep-id? uint32
| | +--rw mep-level? uint32
| | +--rw mep-up-down? enumeration
| | +--rw remote-mep-id? uint32
| | +--rw cos-for-cfm-pdus? uint32
| | +--rw ccm-interval? uint32
| | +--rw ccm-holdtime? uint32
| | +--rw alarm-priority-defect? identityref
| | +--rw ccm-p-bits-pri? ccm-priority-type
| +--rw y-1731* [maid]
| +--rw maid string
| +--rw mep-id? uint32
| +--rw type? identityref
| +--rw remote-mep-id? uint32
| +--rw message-period? uint32
| +--rw measurement-interval? uint32
| +--rw cos? uint32
| +--rw loss-measurement? boolean
| +--rw synthetic-loss-measurement? boolean
| +--rw delay-measurement
| | +--rw enable-dm? boolean
| | +--rw two-way? boolean
| +--rw frame-size? uint32
| +--rw session-type? enumeration
+--rw availability
| +--rw access-priority? uint32
| +--rw (redundancy-mode)?
| +--:(single-active)
| | +--rw single-active? empty
| +--:(all-active)
| +--rw all-active? empty
+--rw vpn-attachment
| +--rw (attachment-flavor)
| +--:(vpn-id)
| | +--rw vpn-id?
| | | -> /l2vpn-svc/vpn-services/
| | | vpn-service/vpn-id
| | +--rw site-role? identityref
| +--:(vpn-policy-id)
| +--rw vpn-policy-id?
| -> ../../../../vpn-policies/
| vpn-policy/vpn-policy-id
+--rw service
| +--rw svc-bandwidth {input-bw}?
| | +--rw bandwidth* [direction type]
| | +--rw direction identityref
| | +--rw type identityref
| | +--rw cos-id? uint8
| | +--rw vpn-id? svc-id
| | +--rw cir uint64
| | +--rw cbs uint64
| | +--rw eir? uint64
| | +--rw ebs? uint64
| | +--rw pir? uint64
| | +--rw pbs? 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 dot1q? uint16
| | | | | +--rw pcp? uint8
| | | | | +--rw src-mac? yang:mac-address
| | | | | +--rw dst-mac? yang:mac-address
| | | | | +--rw color-type? identityref
| | | | | +--rw target-sites*
| | | | | | svc-id {target-sites}?
| | | | | +--rw any? empty
| | | | | +--rw vpn-id? svc-id
| +--rw access-priority? uint32
| +--rw (redundancy-mode)?
| +--:(single-active)
| | +--rw single-active? empty
| +--:(all-active)
| +--rw all-active? empty
+--rw vpn-attachment
| +--rw (attachment-flavor)
| +--:(vpn-id)
| | +--rw vpn-id?
| | | -> /l2vpn-svc/vpn-services/
| | | vpn-service/vpn-id
| | +--rw site-role? identityref
| +--:(vpn-policy-id)
| +--rw vpn-policy-id?
| -> ../../../../vpn-policies/
| vpn-policy/vpn-policy-id
+--rw service
| +--rw svc-bandwidth {input-bw}?
| | +--rw bandwidth* [direction type]
| | +--rw direction identityref
| | +--rw type identityref
| | +--rw cos-id? uint8
| | +--rw vpn-id? svc-id
| | +--rw cir uint64
| | +--rw cbs uint64
| | +--rw eir? uint64
| | +--rw ebs? uint64
| | +--rw pir? uint64
| | +--rw pbs? 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 dot1q? uint16
| | | | | +--rw pcp? uint8
| | | | | +--rw src-mac? yang:mac-address
| | | | | +--rw dst-mac? yang:mac-address
| | | | | +--rw color-type? identityref
| | | | | +--rw target-sites*
| | | | | | svc-id {target-sites}?
| | | | | +--rw any? empty
| | | | | +--rw vpn-id? svc-id
| | | | +--:(match-application)
| | | | +--rw match-application? identityref
| | | +--rw target-class-id? string
| | +--rw qos-profile
| | +--rw (qos-profile)?
| | +--:(standard)
| | | +--rw profile?
| | | -> /l2vpn-svc/vpn-profiles/
| | | valid-provider-identifiers/
| | | qos-profile-identifier
| | +--:(custom)
| | +--rw classes {qos-custom}?
| | +--rw class* [class-id]
| | +--rw class-id string
| | +--rw direction? identityref
| | +--rw policing? identityref
| | +--rw byte-offset? uint16
| | +--rw frame-delay
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-latency?
| | | | empty
| | | +--:(boundary)
| | | +--rw delay-bound? uint16
| | +--rw frame-jitter
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-jitter?
| | | | empty
| | | +--:(boundary)
| | | +--rw delay-bound? uint32
| | +--rw frame-loss
| | | +--rw rate? decimal64
| | +--rw bandwidth
| | +--rw guaranteed-bw-percent
| | | decimal64
| | +--rw end-to-end? empty
| +--rw carrierscarrier {carrierscarrier}?
| +--rw signaling-type? identityref
+--rw broadcast-unknown-unicast-multicast {bum}?
| +--rw multicast-site-type? enumeration
| +--rw multicast-gp-address-mapping* [id]
| | +--rw id uint16
| | +--rw vlan-id uint16
| | +--rw mac-gp-address yang:mac-address
| | +--rw port-lag-number? uint32
| +--rw bum-overall-rate? uint32
| +--rw bum-rate-per-type* [type]
| | | | +--:(match-application)
| | | | +--rw match-application? identityref
| | | +--rw target-class-id? string
| | +--rw qos-profile
| | +--rw (qos-profile)?
| | +--:(standard)
| | | +--rw profile?
| | | -> /l2vpn-svc/vpn-profiles/
| | | valid-provider-identifiers/
| | | qos-profile-identifier
| | +--:(custom)
| | +--rw classes {qos-custom}?
| | +--rw class* [class-id]
| | +--rw class-id string
| | +--rw direction? identityref
| | +--rw policing? identityref
| | +--rw byte-offset? uint16
| | +--rw frame-delay
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-latency?
| | | | empty
| | | +--:(boundary)
| | | +--rw delay-bound? uint16
| | +--rw frame-jitter
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-jitter?
| | | | empty
| | | +--:(boundary)
| | | +--rw delay-bound? uint32
| | +--rw frame-loss
| | | +--rw rate? decimal64
| | +--rw bandwidth
| | +--rw guaranteed-bw-percent
| | | decimal64
| | +--rw end-to-end? empty
| +--rw carrierscarrier {carrierscarrier}?
| +--rw signaling-type? identityref
+--rw broadcast-unknown-unicast-multicast {bum}?
| +--rw multicast-site-type? enumeration
| +--rw multicast-gp-address-mapping* [id]
| | +--rw id uint16
| | +--rw vlan-id uint16
| | +--rw mac-gp-address yang:mac-address
| | +--rw port-lag-number? uint32
| +--rw bum-overall-rate? uint32
| +--rw bum-rate-per-type* [type]
| +--rw type identityref
| +--rw rate? uint32
+--rw mac-loop-prevention {mac-loop-prevention}?
| +--rw protection-type? identityref
| +--rw frequency? uint32
| +--rw retry-timer? uint32
+--rw access-control-list
| +--rw mac* [mac-address]
| +--rw mac-address yang:mac-address
+--rw mac-addr-limit
+--rw limit-number? uint16
+--rw time-interval? uint32
+--rw action? identityref
| +--rw type identityref
| +--rw rate? uint32
+--rw mac-loop-prevention {mac-loop-prevention}?
| +--rw protection-type? identityref
| +--rw frequency? uint32
| +--rw retry-timer? uint32
+--rw access-control-list
| +--rw mac* [mac-address]
| +--rw mac-address yang:mac-address
+--rw mac-addr-limit
+--rw limit-number? uint16
+--rw time-interval? uint32
+--rw action? identityref
Figure 4: Overall Structure of the YANG Module
图4:YANG模块的总体结构
The model defined in this document implements many features that allow implementations to be modular. As an example, the Layer 2 protocol parameters (Section 5.3.2.2) 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 5.2.4), site diversity (Section 5.3), and QoS (Section 5.10.2).
本文档中定义的模型实现了许多允许实现模块化的特性。例如，建议给客户的第2层协议参数（第5.3.2.2节）也可以通过功能启用。该模型还为更高级的选项定义了一些功能，例如支持外部网络VPN（第5.2.4节）、站点多样性（第5.3节）和QoS（第5.10.2节）。
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 defines VXLAN [RFC7348] for Ethernet packet encapsulation; if VXLAN encapsulation does not fulfill all requirements for describing the service, new options can be added through augmentation.
此外，对于任何数据模型，此服务模型都可以扩展以实现新的行为或特定功能。例如，该模型定义了用于以太网数据包封装的VXLAN[RFC7348]；如果VXLAN封装不能满足描述服务的所有要求，可以通过扩充添加新选项。
The vpn-service list item contains generic information about the VPN service. The vpn-id in the vpn-service list refers to an internal reference for this VPN service. This identifier is purely internal to the organization responsible for the VPN service.
vpn服务列表项包含有关vpn服务的常规信息。vpn服务列表中的vpn id引用此vpn服务的内部引用。此标识符纯粹是负责VPN服务的组织的内部标识符。
The vpn-service list is composed of the following characteristics:
vpn服务列表由以下特征组成：
Customer information (customer-name): Used to identify the customer.
客户信息（客户名称）：用于识别客户。
VPN service type (vpn-svc-type): Used to indicate the VPN service type. The identifier is an identity allowing any encoding for the local administration of the VPN service. Note that another identity can be an extension of the base identity.
VPN服务类型（VPN svc类型）：用于指示VPN服务类型。标识符是允许对VPN服务的本地管理进行任何编码的标识。请注意，另一个标识可以是基本标识的扩展。
Cloud access (cloud-access): All sites in the L2VPN SHOULD be permitted to access the cloud by default. The "cloud-access" container provides parameters for authorization rules. A cloud identifier is used to reference the target service. This identifier is local to each administration.
云访问（Cloud access）：默认情况下，L2VPN中的所有站点都应允许访问云。“云访问”容器为授权规则提供参数。云标识符用于引用目标服务。此标识符是每个管理的本地标识符。
Service topology (svc-topo): Used to identify the type of VPN service topology that is required.
服务拓扑（svc拓扑）：用于标识所需的VPN服务拓扑类型。
Frame delivery service (frame-delivery): Defines the frame delivery support required for the L2VPN, e.g., multicast delivery, unicast delivery, or broadcast delivery.
帧传送服务（帧传送）：定义L2VPN所需的帧传送支持，例如，多播传送、单播传送或广播传送。
Extranet VPN (extranet-vpns): Indicates that a particular VPN needs access to resources located in another VPN.
Extranet VPN（Extranet VPN）：表示特定VPN需要访问位于另一个VPN中的资源。
The "vpn-svc-type" parameter defines the service type for provider-provisioned L2VPNs. The current version of the model supports six flavors:
“vpn svc type”参数定义提供程序提供的L2VPN的服务类型。当前版本的模型支持六种风格：
o Point-to-point VPWSs connecting two customer sites.
o 连接两个客户站点的点对点VPWSs。
o Point-to-point or point-to-multipoint VPWSs connecting a set of customer sites [RFC8214].
o 连接一组客户站点的点对点或点对多点VPWSs[RFC8214]。
o Multipoint VPLSs connecting a set of customer sites.
o 连接一组客户站点的多点VPLS。
o Multipoint VPLSs connecting one or more root sites and a set of leaf sites but preventing inter-leaf-site communication.
o 连接一个或多个根站点和一组叶站点但阻止叶站点间通信的多点VPLS。
o EVPN services [RFC7432] connecting a set of customer sites.
o 连接一组客户站点的EVPN服务[RFC7432]。
o EVPN VPWSs between two customer sites or a set of customer sites as specified in [RFC8214].
o [RFC8214]中规定的两个客户站点或一组客户站点之间的EVPN VPWSs。
Other L2VPN service types could be included by augmentation. Note that an Ethernet Private Line (EPL) service or an Ethernet Virtual Private Line (EVPL) service is an Ethernet Line (E-Line) service [MEF-6]or a point-to-point Ethernet Virtual Circuit (EVC) service, while an Ethernet Private LAN (EP-LAN) service or an Ethernet Virtual Private LAN (EVP-LAN) service is an Ethernet LAN (E-LAN) service [MEF-6] or a multipoint-to-multipoint EVC service.
其他L2VPN服务类型可以通过扩展来包括。请注意，以太网专用线（EPL）服务或以太网虚拟专用线（EVPL）服务是以太网线路（E-Line）服务[MEF-6]或点对点以太网虚拟电路（EVC）服务，而以太网专用LAN（EP-LAN）服务或以太网虚拟专用LAN（EVP-LAN）服务是以太网LAN（E-LAN）服务[MEF-6]或多点对多点EVC服务。
The types of VPN service topologies discussed below can be used for configuration if needed. The module described in this document currently 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 by augmentation. By default, the any-to-any VPN service topology is used.
如果需要，下面讨论的VPN服务拓扑类型可用于配置。本文档中描述的模块目前支持任意对任意、集线器和分支（集线器可以交换流量）以及集线器和分支不相交（集线器不能交换流量）。可以通过扩充来添加新拓扑。默认情况下，使用任意到任意VPN服务拓扑。
A Layer 2 PE-based VPN (such as a VPLS-based VPN or an EVPN that uses BGP as its signaling protocol) can be built using Route Targets (RTs) as described in [RFC4364] and [RFC7432]. 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 in Section 6.2.1.1 of [RFC8299].
可以使用[RFC4364]和[RFC7432]中所述的路由目标（RTs）构建基于第2层PE的VPN（例如基于VPLS的VPN或使用BGP作为其信令协议的EVPN）。管理系统在收到VPN服务创建请求时，应自动分配一组RTs。管理系统如何分配RTs超出了本文件的范围，但可以设想多种方式，如[RFC8299]第6.2.1.1节所述。
+--------------------------------------------------------------+
| VPN1_Site 1 ------ PE1 PE2 ------ VPN1_Site 2 |
| |
| VPN1_Site 3 ------ PE3 PE4 ------ VPN1_Site 4 |
+--------------------------------------------------------------+
+--------------------------------------------------------------+
| VPN1_Site 1 ------ PE1 PE2 ------ VPN1_Site 2 |
| |
| VPN1_Site 3 ------ PE3 PE4 ------ VPN1_Site 4 |
+--------------------------------------------------------------+
Figure 5: Any-to-Any VPN Service Topology
图5：任意到任意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 L2VPN service request through this model is expected to assign and then configure the MAC-VRF and RTs on the appropriate PEs. In the any-to-any case, a single RT is generally required, and every MAC-VRF imports and exports this RT.
在任意对任意VPN服务拓扑中，所有VPN站点都可以不受任何限制地相互通信。通过该模型接收任意对任意L2VPN服务请求的管理系统应分配并在适当的PEs上配置MAC-VRF和RTs。在任意情况下，通常需要一个RT，每个MAC-VRF导入和导出此RT。
+---------------------------------------------------------------+
| Hub_Site 1 ------ PE1 PE2 ------ Spoke_Site 1 |
| +------------------------------------+
| |
| +------------------------------------+
| Hub_Site 2 ------ PE3 PE4 ------ Spoke_Site 2 |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| Hub_Site 1 ------ PE1 PE2 ------ Spoke_Site 1 |
| +------------------------------------+
| |
| +------------------------------------+
| Hub_Site 2 ------ PE3 PE4 ------ Spoke_Site 2 |
+---------------------------------------------------------------+
Figure 6: Hub-and-Spoke VPN Service Topology
图6：中心辐射式VPN服务拓扑
In the Hub-and-Spoke VPN service topology,
在中心辐射式VPN服务拓扑中，
o all Spoke sites can communicate only with Hub sites (i.e., Spoke sites cannot communicate with each other).
o 所有分支站点只能与中心站点通信（即分支站点不能相互通信）。
o Hubs can communicate with each other.
o 集线器可以相互通信。
The management system that receives a Hub-and-Spoke L2VPN service request through this model is expected to assign and then configure the MAC-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 MAC-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 MAC-VRF that connects Spoke sites will export Spoke routes with the Spoke RT and will import Hub routes through the Hub RT.
通过该模型接收集线器和分支L2VPN服务请求的管理系统预计将在适当的PEs上分配并配置MAC-VRF和RTs。在集线器和辐条的情况下，通常需要两个RT（一个RT用于集线器路由，一个RT用于辐条路由）。连接集线器站点的集线器MAC-VRF将使用集线器RT导出集线器路由，并通过分支RT导入分支路由。它还将导入集线器RT以允许集线器到集线器通信。连接分支站点的分支MAC-VRF将使用分支RT导出分支路由，并通过集线器RT导入集线器路由。
+---------------------------------------------------------------+
| Hub_Site 1 ------ PE1 PE2 ------ Spoke_Site 1 |
+--------------------------+ +---------------------------------+
| |
+--------------------------+ +---------------------------------+
| Hub_Site 2 ------ PE3 PE4 ------ Spoke_Site 2 |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| Hub_Site 1 ------ PE1 PE2 ------ Spoke_Site 1 |
+--------------------------+ +---------------------------------+
| |
+--------------------------+ +---------------------------------+
| Hub_Site 2 ------ PE3 PE4 ------ Spoke_Site 2 |
+---------------------------------------------------------------+
Figure 7: Hub-and-Spoke-Disjoint VPN Service Topology
图7：中心辐射不相交VPN服务拓扑
In the Hub-and-Spoke-Disjoint VPN service topology,
在中心辐射不相交的VPN服务拓扑中，
o all Spoke sites can communicate only with Hub sites (i.e., Spoke sites cannot communicate with each other).
o 所有分支站点只能与中心站点通信（即分支站点不能相互通信）。
o Hubs cannot communicate with each other.
o 集线器无法相互通信。
The management system that receives a Hub-and-Spoke-Disjoint L2VPN 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-Disjoint case, at least two RTs are required for Hubs and Spokes, respectively (at least one RT for Hub routes and at least 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.
通过该模型接收集线器和分支不相交L2VPN服务请求的管理系统预计将在适当的PEs上分配并配置VRF和RTs。在轮毂和轮辐不相交的情况下，轮毂和轮辐分别需要至少两个RT（至少一个RT用于轮毂路线，至少一个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（每个中心一个）。
This model provides cloud access configuration through the cloud-access container. The usage of cloud-access is targeted for public cloud access and Internet access. The cloud-access container provides parameters for authorization rules. Note that this model considers that public cloud and public Internet access share some commonality; therefore, it does not distinguish Internet access from cloud access. If needed, a different label for Internet access could be added by augmentation.
该模型通过云访问容器提供云访问配置。云访问的使用针对公共云访问和互联网访问。云访问容器为授权规则提供参数。注意，该模型认为公共云和公共互联网接入共享一些公共性；因此，它没有区分互联网接入和云接入。如果需要的话，可以通过扩充来添加一个不同的互联网接入标签。
Private cloud access may be addressed through the site container as described in Section 5.3, with usage consistent with sites of type "NNI".
私有云访问可通过第5.3节所述的站点容器解决，其使用与“NNI”类型的站点一致。
A cloud identifier is used to reference the target service. This identifier is local to each administration.
云标识符用于引用目标服务。此标识符是每个管理的本地标识符。
By default, all sites in the L2VPN SHOULD be permitted to access the cloud or the Internet. If restrictions are required, a user MAY configure some limitations for some sites or nodes by using policies, i.e., 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.
默认情况下，应允许L2VPN中的所有站点访问云或互联网。如果需要限制，用户可以使用策略（即“允许站点”或“拒绝站点”叶列表）为某些站点或节点配置一些限制。许可站点叶列表定义了授权云访问的站点列表。拒绝站点叶列表定义拒绝云访问的站点列表。该模型支持“拒绝任何例外”和“允许任何例外”授权。
How the restrictions will be configured on network elements is out of scope for this document.
如何在网络元素上配置限制超出了本文档的范围。
L2VPN
++++++++++++++++++++++++++++++++ ++++++++++++
+ Site 3 + --- + Cloud 1 +
+ Site 1 + ++++++++++++
+ +
+ Site 2 + --- ++++++++++++
+ + + Internet +
+ Site 4 + ++++++++++++
++++++++++++++++++++++++++++++++
|
+++++++++++
+ Cloud 2 +
+++++++++++
L2VPN
++++++++++++++++++++++++++++++++ ++++++++++++
+ Site 3 + --- + Cloud 1 +
+ Site 1 + ++++++++++++
+ +
+ Site 2 + --- ++++++++++++
+ + + Internet +
+ Site 4 + ++++++++++++
++++++++++++++++++++++++++++++++
|
+++++++++++
+ Cloud 2 +
+++++++++++
Figure 8: Example of Cloud Access Configuration
图8：云访问配置示例
As shown in Figure 8, we configure the global VPN to access the Internet by creating a cloud-access container pointing to the cloud identifier for the Internet service. (This is illustrated in the XML [W3C.REC-xml-20081126] below.) No authorized sites will be configured, as all sites are required to be able to access the Internet.
如图8所示，我们通过创建指向Internet服务的云标识符的云访问容器来配置全局VPN以访问Internet。（这在下面的XML[W3C.REC-XML-20081126]中有说明。）不会配置授权站点，因为所有站点都需要能够访问Internet。
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>123456487</vpn-id>
<cloud-accesses>
<cloud-access>
<cloud-identifier>INTERNET</cloud-identifier>
</cloud-access>
</cloud-accesses>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
</l2vpn-svc>
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>123456487</vpn-id>
<cloud-accesses>
<cloud-access>
<cloud-identifier>INTERNET</cloud-identifier>
</cloud-access>
</cloud-accesses>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
</l2vpn-svc>
If Site 1 and Site 2 require access to Cloud 1, a new cloud-access container 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"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-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>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
</l2vpn-svc>
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-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>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
</l2vpn-svc>
If all sites except Site 1 require access to Cloud 2, a new cloud-access container 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"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-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>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
</l2vpn-svc>
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-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>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
</l2vpn-svc>
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)
+-----------+ +-----------+
/ \ / \
Site A -- | VPN A | --- | VPN B | --- Site B
\ / \ / (Shared
+-----------+ +-----------+ resources)
Figure 9: Example of Shared VPN Resources
图9：共享VPN资源的示例
As illustrated in Figure 9, VPN B has some resources on Site B that need to be made available to some customers/partners. Specifically, VPN A must be able to access those VPN B resources.
如图9所示，VPN B在站点B上有一些资源需要提供给一些客户/合作伙伴。具体来说，VPN A必须能够访问这些VPN B资源。
Such a VPN connection scenario can be achieved via a VPN policy as defined in Section 5.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连接方案可以通过第5.5.2.2节中定义的VPN策略实现。但是，在一些简单的情况下，一个特定的VPN（VPN a）需要访问另一个VPN（VPN B）中的所有资源。该模型提供了一种使用“extranet VPN”容器设置此连接的简单方法。
The extranet-vpns container defines a list of VPNs a particular VPN wants to access. The extranet-vpns container is used on customer VPNs accessing extranet resources in another VPN. In Figure 9, 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 VPN容器定义特定VPN要访问的VPN列表。extranet VPN容器用于访问另一个VPN中的extranet资源的客户VPN。在图9中，为了向VPN A提供对VPN B的访问，需要在VPN A下配置extranet VPN容器，其中有一个与VPN B相对应的条目。VPN B上没有服务配置要求。
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 5.4.
“站点角色”叶定义目标外部网VPN服务拓扑中本地VPN站点的角色。第5.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 A中的站点不能通过外部网VPN连接相互通信。
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNB</vpn-id>
<svc-topo>hub-spoke</svc-topo>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
<vpn-service>
<vpn-id>VPNA</vpn-id>
<svc-topo>any-to-any</svc-topo>
<extranet-vpns>
<extranet-vpn>
<vpn-id>VPNB</vpn-id>
<local-sites-role>spoke-role</local-sites-role>
</extranet-vpn>
</extranet-vpns>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
</l2vpn-svc>
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNB</vpn-id>
<svc-topo>hub-spoke</svc-topo>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
<vpn-service>
<vpn-id>VPNA</vpn-id>
<svc-topo>any-to-any</svc-topo>
<extranet-vpns>
<extranet-vpn>
<vpn-id>VPNB</vpn-id>
<local-sites-role>spoke-role</local-sites-role>
</extranet-vpn>
</extranet-vpns>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
</l2vpn-svc>
This model does not define how the extranet configuration will be achieved within the network.
此模型未定义如何在网络中实现外联网配置。
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 5.5.2 and, in particular, a VPN policy as defined in Section 5.5.2.2.
任何更复杂的VPN互连场景（例如，仅VPN A上的某些站点部分访问VPN B上的某些站点部分）都需要使用第5.5.2节中定义的VPN附件，特别是第5.5.2.2节中定义的VPN策略来实现。
If a BUM (Broadcast, Unknown Unicast, or Multicast) frame delivery service is supported for an L2VPN, some global frame delivery parameters are required as input for the service request. When a CE sends BUM packets, replication occurs at the ingress PE and three frame types need to be supported.
如果L2VPN支持BUM（广播、未知单播或多播）帧传送服务，则需要一些全局帧传送参数作为服务请求的输入。当CE发送BUM数据包时，复制发生在入口PE，需要支持三种帧类型。
Users of this model will need to provide the flavors of trees that will be used by customers within the L2VPN (customer-tree-flavors). The model defined in this document supports bidirectional, shared, and source-based trees (and can be augmented to contain other tree types). Multiple flavors of trees can be supported simultaneously.
此模型的用户需要提供L2VPN内客户将使用的树的风格（客户树风格）。本文档中定义的模型支持双向、共享和基于源的树（并且可以扩展为包含其他树类型）。可以同时支持多种风格的树。
Operator network
______________
/ \
| |
| |
Recv -- Site 2 ------- PE2 |
| PE1 --- Site 1 --- Source 1
| | \
| | -- Source 2
| |
| |
Recv -- Site 3 ------- PE3 |
| |
| |
Recv -- Site 4 ------- PE4 |
/ | |
Recv -- Site 5 ------- | |
| |
| |
\______________/
Operator network
______________
/ \
| |
| |
Recv -- Site 2 ------- PE2 |
| PE1 --- Site 1 --- Source 1
| | \
| | -- Source 2
| |
| |
Recv -- Site 3 ------- PE3 |
| |
| |
Recv -- Site 4 ------- PE4 |
/ | |
Recv -- Site 5 ------- | |
| |
| |
\______________/
Figure 10: BUM Frame Delivery Service Example
图10:BUM框架交付服务示例
Multicast-group-to-port mappings can be created using the "rp-group-mappings" leaf. Two group-to-port mapping methods are supported:
可以使用“rp组映射”叶创建多播组到端口的映射。支持两种组到端口映射方法：
o Static configuration of multicast Ethernet addresses and ports/interfaces.
o 多播以太网地址和端口/接口的静态配置。
o A multicast control protocol based on Layer 2 technology that signals mappings of multicast addresses to ports/interfaces, such as the Generic Attribute Registration Protocol (GARP) / GARP Multicast Registration Protocol (GARP/GMRP) [IEEE-802-1D].
o 一种基于第2层技术的多播控制协议，它向端口/接口发送多播地址映射信号，例如通用属性注册协议（GARP）/GARP多播注册协议（GARP/GMRP）[IEEE-802-1D]。
A site represents a connection of a customer office to one or more VPN services. Each site is associated with one or more locations.
站点表示客户办公室与一个或多个VPN服务的连接。每个站点都与一个或多个位置关联。
+-------------+
/ \
+-----| VPN1 |
+------------------+ | \ /
| | | +-------------+
| New York Office |------ (site) -----+
| | | +-------------+
+------------------+ | / \
+-----| VPN2 |
\ /
+-------------+
+-------------+
/ \
+-----| VPN1 |
+------------------+ | \ /
| | | +-------------+
| New York Office |------ (site) -----+
| | | +-------------+
+------------------+ | / \
+-----| VPN2 |
\ /
+-------------+
Figure 11: Example: Customer Office and Two VPN Services
图11：示例：客户办公室和两个VPN服务
The provider uses the site container to store information regarding detailed implementation arrangements made with either the customer or peer operators at each interconnect location.
提供商使用站点容器来存储关于在每个互连位置与客户或对等运营商进行的详细实施安排的信息。
We restrict the L2SM to exterior interfaces (i.e., UNIs and NNIs) only, so all internal interfaces and the underlying topology are outside the scope of the L2SM.
我们将L2SM仅限于外部接口（即UNIs和NNI），因此所有内部接口和底层拓扑都不在L2SM的范围内。
Typically, the following characteristics of a site interface handoff need to be documented as part of the service design:
通常，作为服务设计的一部分，需要记录站点接口切换的以下特征：
Unique identifier (site-id): An arbitrary string to uniquely identify the site within the overall network infrastructure. The format of "site-id" is determined by the local administrator of the VPN service.
唯一标识符（站点id）：在整个网络基础结构中唯一标识站点的任意字符串。“站点id”的格式由VPN服务的本地管理员确定。
Device (device): The customer can request one or more customer premises equipment entities from the SP for a particular site.
设备（Device）：客户可以为特定站点从SP请求一个或多个客户场所设备实体。
Management (management): Defines the model of management for the site -- for example, type, management-transport, address. This parameter determines the boundary between the SP and the customer, i.e., who has ownership of the CE device.
管理（Management）：定义站点的管理模型——例如，类型、管理传输、地址。此参数确定SP和客户之间的边界，即谁拥有CE设备的所有权。
Location (location): The site location information. Allows easy retrieval of data about the nearest available resources.
位置（Location）：站点位置信息。允许轻松检索有关最近可用资源的数据。
Site diversity (site-diversity): Presents some parameters to support site diversity.
站点多样性（站点多样性）：提供一些支持站点多样性的参数。
Site network accesses (site-network-accesses): Defines the list of ports to the site and their properties -- in particular, bearer, connection, and service parameters.
站点网络访问（站点网络访问）：定义站点的端口列表及其属性，特别是承载、连接和服务参数。
A site-network-access represents an Ethernet logical connection to a site. A site may have multiple site-network-accesses.
站点网络访问表示到站点的以太网逻辑连接。一个站点可以有多个站点网络访问。
+------------------+ Site
| |-------------------------------------
| |****** (site-network-access#1) ******
| New York Office |
| |****** (site-network-access#2) ******
| |-------------------------------------
+------------------+
+------------------+ Site
| |-------------------------------------
| |****** (site-network-access#1) ******
| New York Office |
| |****** (site-network-access#2) ******
| |-------------------------------------
+------------------+
Figure 12: Two Site-Network-Accesses for a Site
图12：一个站点的两个站点网络访问
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 parameters between the PE configuration and the CE configuration.
站点配置被视为一个全局实体；我们假设，在网络中的不同元素之间分割参数主要是管理系统的角色。例如，在站点网络访问配置的情况下，管理系统需要在PE配置和CE配置之间拆分参数。
The site may support single-homed access or multihoming. In the case of multihoming, the site can support multiple site-network-accesses. Under each site-network-access, "vpn-attachment" is defined; vpn-attachment will describe the association between a given site-network-access and a given site, as well as the VPN to which that site will connect.
该站点可能支持单宿访问或多宿访问。在多主的情况下，站点可以支持多站点网络访问。在每个站点网络访问下定义“vpn附件”；vpn附件将描述给定站点网络访问和给定站点之间的关联，以及该站点将连接到的vpn。
The information in the "location" sub-container under a site container and in the "devices" container allows easy retrieval of data about the nearest available facilities and can be used for access topology planning. It may also be used by other network orchestration components to choose the targeted upstream PE and downstream CE. Location is expressed in terms of postal information. More detailed information or other location information can be added by augmentation.
站点容器下的“位置”子容器和“设备”容器中的信息允许轻松检索有关最近可用设施的数据，并可用于访问拓扑规划。其他网络编排组件也可以使用它来选择目标上游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, where the office is composed of multiple buildings. Those buildings may be located in different parts of the city and may be linked by intra-city fibers (a customer metropolitan area network). This model does not represent connectivity between multiple locations of a site, because that connectivity is controlled by the customer. In such a case, when connecting to a VPN service, the customer may ask for multihoming based on its distributed locations.
多地点站点的一个典型示例是城市中的总部办公室，该办公室由多个建筑物组成。这些建筑物可能位于城市的不同部分，并可通过城内光纤（客户城域网）连接。此模型不表示站点多个位置之间的连接，因为该连接由客户控制。在这种情况下，当连接到VPN服务时，客户可能会根据其分布的位置请求多归属。
New York Site
+------------------+ Site
| +--------------+ |-------------------------------------
| | Manhattan | |****** (site-network-access#1) ******
| +--------------+ |
| +--------------+ |
| | Brooklyn | |****** (site-network-access#2) ******
| +--------------+ |-------------------------------------
+------------------+
New York Site
+------------------+ Site
| +--------------+ |-------------------------------------
| | Manhattan | |****** (site-network-access#1) ******
| +--------------+ |
| +--------------+ |
| | Brooklyn | |****** (site-network-access#2) ******
| +--------------+ |-------------------------------------
+------------------+
Figure 13: Two Site-Network-Accesses, Two Sites
图13：两个站点网络访问，两个站点
A customer may also request the use of 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 requested for 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 Figure 13, one device may be requested for the Manhattan location and one other for the Brooklyn location.
客户还可以通过设备容器从SP请求使用某些场所设备实体（CE）。请求CE意味着提供程序管理或共同管理的模型。必须为已配置的特定位置请求特定设备。这将有助于SP将设备发送到相应的邮政地址。例如，在多位置站点中，客户可以为站点上必须实施多主的每个位置请求CE。在图13中，一个设备可能被请求用于曼哈顿位置，另一个设备被请求用于布鲁克林位置。
By using devices and locations, the user can influence the multihoming scenario they want to implement: single CE, dual CE, etc.
通过使用设备和位置，用户可以影响他们想要实现的多宿场景：单CE、双CE等。
The L2SM includes a set of essential physical interface properties and Ethernet-layer characteristics in the "site-network-accesses" container. Some of these are critical implementation arrangements that require consent from both the customer and the provider.
L2SM在“站点网络访问”容器中包含一组基本物理接口属性和以太网层特征。其中一些是关键的实施安排，需要得到客户和提供商的同意。
As mentioned earlier, a site may be multihomed. Each logical 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:
如前所述，站点可以是多址的。站点的每个逻辑网络访问都在站点网络访问容器中定义。站点网络访问参数定义站点在网络上的连接方式，并分为三类主要参数：
o bearer: defines requirements of the attachment (below Layer 2).
o 承载人：定义附件的要求（第2层以下）。
o connection: defines Layer 2 protocol parameters of the attachment.
o 连接：定义附件的第2层协议参数。
o availability: defines the site's availability policy. The availability parameters are defined in Section 5.8.
o 可用性：定义站点的可用性策略。第5.8节定义了可用性参数。
The site-network-access has a specific type (site-network-access type). This document defines two types:
站点网络访问具有特定类型（站点网络访问类型）。本文件定义了两种类型：
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 多点：描述SP和客户之间的多点连接。
This site-network-access type may have an impact on the parameters offered to the customer, e.g., an SP might not offer MAC loop protection for multipoint accesses. It is up to the provider to decide what parameters are supported for point-to-point and/or multipoint accesses. Multipoint accesses are out of scope for this document; some containers defined in the model may require extensions in order to work properly for multipoint accesses.
此站点网络访问类型可能会影响提供给客户的参数，例如，SP可能不会为多点访问提供MAC环路保护。由提供者决定点到点和/或多点访问支持哪些参数。多点访问超出了本文件的范围；模型中定义的某些容器可能需要扩展才能正常工作以进行多点访问。
The "bearer" container defines the requirements for the site attachment (below Layer 2) to the provider network.
“承载者”容器定义了站点连接（第2层以下）到提供商网络的要求。
The bearer parameters will help to determine the access media to be used.
承载参数将有助于确定要使用的接入媒体。
The "connection" container defines the Layer 2 protocol parameters of the attachment (e.g., vlan-id or circuit-id) and provides connectivity between customer Ethernet switches. Depending on the management mode, it refers to PE-CE-LAN segment addressing or to CE-to-customer-LAN segment 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-LAN segment connection. For a provider-managed site, it refers to the CE-to-customer-LAN segment connection.
“连接”容器定义附件的第2层协议参数（例如，vlan id或电路id），并提供客户以太网交换机之间的连接。根据管理模式，它指的是PE-CE-LAN段寻址或CE到客户LAN段寻址。无论如何，它描述了供应商和客户之间的责任边界。对于客户管理的站点，它指的是PE-CE-LAN段连接。对于提供商管理的站点，它指的是CE到客户LAN段的连接。
The "encapsulation-type" parameter allows the user to select between Ethernet encapsulation (port-based) or Ethernet VLAN encapsulation (VLAN-based). All of the allowed Ethernet interface types of service frames can be listed under "ether-inf-type", e.g., untagged interface, tagged interface, LAG interface.
“封装类型”参数允许用户在以太网封装（基于端口）或以太网VLAN封装（基于VLAN）之间进行选择。所有允许的服务帧以太网接口类型都可以在“以太网inf类型”下列出，例如，未标记接口、标记接口、滞后接口。
Corresponding to "ether-inf-type", the connection container also presents three sets of link attributes: untagged interface, tagged interface, and optional LAG interface attributes. These parameters are essential for the connection to be properly established between the CE devices and the PE devices. The connection container also defines a Layer 2 Control Protocol (L2CP) attribute that allows control-plane protocol interaction between the CE devices and the PE device.
与“ether inf type”相对应，连接容器还提供三组链接属性：未标记接口、标记接口和可选延迟接口属性。这些参数对于在CE设备和PE设备之间正确建立连接至关重要。连接容器还定义了第2层控制协议（L2CP）属性，该属性允许CE设备和PE设备之间的控制平面协议交互。
For each untagged interface (untagged-interface), there are basic configuration parameters like interface index and speed, interface MTU, auto-negotiation and flow-control settings, etc. In addition, and based on mutual agreement, the customer and provider may decide to enable advanced features, such as LLDP, IEEE 802.3ah [IEEE-802-3ah], or MAC loop detection/prevention at a UNI. If loop avoidance is required, the attribute "uni-loop-prevention" must be set to "true".
对于每个未标记接口（未标记接口），都有基本配置参数，如接口索引和速度、接口MTU、自动协商和流量控制设置等。此外，根据双方协议，客户和提供商可能决定启用高级功能，如LLDP、IEEE 802.3ah[IEEE-802-3ah]，或UNI处的MAC环路检测/预防。如果需要避免循环，则必须将属性“uni loop prevention”设置为“true”。
If the tagged service is enabled on a logical unit on the connection at the interface, "encapsulation-type" should be specified as the Ethernet VLAN encapsulation (if VLAN-based) or VXLAN encapsulation, and "eth-inf-type" should be set to indicate a tagged interface.
如果在接口连接的逻辑单元上启用了标记服务，“封装类型”应指定为以太网VLAN封装（如果基于VLAN）或VXLAN封装，并且“eth inf类型”应设置为指示标记接口。
In addition, "tagged-interface-type" should be specified in the "tagged-interface" container to determine how tagging needs to be done. The current model defines five ways to perform VLAN tagging:
此外，应在“标记接口”容器中指定“标记接口类型”，以确定需要如何进行标记。当前模型定义了五种执行VLAN标记的方法：
o priority-tagged: SPs encapsulate and tag packets between the CE and the PE with the frame priority level.
o 优先级标记：SP以帧优先级封装和标记CE和PE之间的数据包。
o dot1q-vlan-tagged: SPs encapsulate packets between the CE and the PE with one or a set of customer VLAN (CVLAN) IDs.
o dot1q vlan标记：SP使用一个或一组客户vlan（CVLAN）ID封装CE和PE之间的数据包。
o qinq: SPs encapsulate packets that enter their networks with multiple CVLAN IDs and a single VLAN tag with a single SP VLAN (SVLAN).
o qinq:SP使用多个CVLAN ID和一个带有单个SP VLAN（SVLAN）的VLAN标记封装进入其网络的数据包。
o qinany: SPs encapsulate packets that enter their networks with unknown CVLANs and a single VLAN tag with a single SVLAN.
o qinany:SP封装使用未知CVLAN和单个SVLAN的单个VLAN标记进入其网络的数据包。
o vxlan: SPs encapsulate packets that enter their networks with a VXLAN Network Identifier (VNI) and a peer list.
o vxlan:SP使用vxlan网络标识符（VNI）和对等列表封装进入其网络的数据包。
The overall S-tag for the Ethernet circuit and (if applicable) C-tag-to-SVC mapping (where "SVC" stands for "Switched Virtual Circuit") have been placed in the "service" container. For the qinq and qinany options, the S-tag under "qinq" and "qinany" should match the S-tag in the service container in most cases; however, VLAN translation is required for the S-tag in certain deployments at the external-facing interface or upstream PEs to "normalize" the outer VLAN tag to the service S-tag into the network and translate back to the site's S-tag in the opposite direction. One example of this is with a Layer 2 aggregation switch along the path: the S-tag for the SVC has been previously assigned to another service and thus cannot be used by this AC.
以太网电路的整体S标签和（如适用）C标签到SVC映射（其中“SVC”表示“交换虚拟电路”）已放置在“服务”容器中。对于qinq和qinany选项，“qinq”和“qinany”下的S标签在大多数情况下应与服务容器中的S标签匹配；但是，在面向外部的接口或上游PEs的某些部署中，需要对S-tag进行VLAN转换，以将外部VLAN标记“规范化”为网络中的服务S-tag，并以相反的方向转换回站点的S-tag。这方面的一个例子是路径上的第2层聚合交换机：SVC的S标记先前已分配给另一个服务，因此该AC无法使用。
Sometimes, the customer may require multiple physical links bundled together to form a single, logical, point-to-point LAG connection to the SP. Typically, the Link Aggregation Control Protocol (LACP) is used to dynamically manage adding or deleting member links of the aggregate group. In general, a LAG allows for increased service bandwidth beyond the speed of a single physical link while providing graceful degradation as failure occurs, thus increasing availability.
有时，客户可能需要将多个物理链路捆绑在一起，以形成与SP的单逻辑点对点延迟连接。通常，链路聚合控制协议（LACP）用于动态管理聚合组成员链路的添加或删除。一般来说，延迟允许增加超过单个物理链路速度的服务带宽，同时在发生故障时提供良好的降级，从而提高可用性。
In the L2SM, there is a set of attributes under "lag-interface" related to link aggregation functionality. The customer and provider first need to decide on whether LACP PDUs will be exchanged between the edge devices by specifying the "LACP-state" as "on" or "off". If LACP is to be enabled, then both parties need to further specify (1) whether LACP will be running in active or passive mode and (2) the time interval and priority level of the LACP PDU. The customer and provider can also determine the minimum aggregate bandwidth for a LAG to be considered as a valid path by specifying the optional "mini-link-num" attribute. To enable fast detection of faulty links, micro-BFD [RFC7130] ("BFD" stands for "Bidirectional Forwarding Detection") runs independent UDP sessions to monitor the status of each member link. The customer and provider should agree on the BFD hello interval and hold time.
在L2SM中，“滞后接口”下有一组与链路聚合功能相关的属性。客户和提供商首先需要通过将“LACP状态”指定为“开”或“关”来决定是否在边缘设备之间交换LACP PDU。如果要启用LACP，则双方需要进一步指定（1）LACP是以主动模式还是被动模式运行，以及（2）LACP PDU的时间间隔和优先级。客户和提供商还可以通过指定可选的“mini link num”属性来确定将滞后视为有效路径的最小聚合带宽。为了能够快速检测故障链路，micro BFD[RFC7130]（“BFD”代表“双向转发检测”）运行独立的UDP会话以监控每个成员链路的状态。客户和供应商应就BFD hello间隔和等待时间达成一致。
Each member link will be listed under the LAG interface with basic physical link properties. Certain attributes, such as flow control, encapsulation type, allowed ingress Ethertype, and LLDP settings, are at the LAG level.
每个成员链接将在LAG界面下列出，并具有基本的物理链接属性。某些属性（如流控制、封装类型、允许的入口类型和LLDP设置）处于滞后级别。
When more than one service is multiplexed onto the same interface, ingress service frames are conditionally transmitted through one of the L2VPN services based upon a pre-arranged customer-VLAN-to-SVC mapping. Multiple CVLANs can be bundled across the same SVC. The bundling type will determine how a group of CVLANs is bundled into one VPN service (i.e., VLAN-bundling).
当多个服务被多路复用到同一接口上时，入口服务帧基于预先安排的客户VLAN到SVC映射，有条件地通过L2VPN服务之一传输。多个CVLAN可以捆绑在同一个SVC上。绑定类型将决定如何将一组CVLAN绑定到一个VPN服务（即VLAN绑定）。
When applicable, "cvlan-id-to-svc-map" contains the list of CVLANs that are mapped to the same service. In most cases, this will be the VLAN access-list for the inner 802.1Q tag [IEEE-802-1Q] (the C-tag).
如果适用，“cvlan id到svc映射”包含映射到同一服务的cvlan列表。在大多数情况下，这将是内部802.1Q标签[IEEE-802-1Q]（C标签）的VLAN访问列表。
A VPN service can be set to preserve the CE-VLAN ID and CE-VLAN CoS from the source site to the destination site. This is required when the customer wants to use the VLAN header information between its two sites. CE-VLAN ID preservation and CE-VLAN CoS preservation are applied on each site-network-access within sites. "Preservation" means that the value of the CE-VLAN ID and/or CE-VLAN CoS at the source site must be equal to the value at a destination site belonging to the same L2VPN service.
VPN服务可以设置为保留从源站点到目标站点的CE-VLAN ID和CE-VLAN CoS。当客户希望在其两个站点之间使用VLAN头信息时，这是必需的。CE-VLAN ID保留和CE-VLAN CoS保留应用于站点内的每个站点网络访问。“保留”是指源站点的CE-VLAN ID和/或CE-VLAN CoS的值必须等于属于同一L2VPN服务的目标站点的值。
If all-to-one bundling is enabled (i.e., the bundling type is set to "all-to-one bundling"), then preservation applies to all ingress service frames. If all-to-one bundling is disabled, then preservation applies to tagged ingress service frames having the CE-VLAN ID.
如果启用了全对一绑定（即，绑定类型设置为“全对一绑定”），则保留适用于所有入口服务帧。如果禁用了“一对一”绑定，则保留适用于具有CE-VLAN ID的标记入口服务帧。
The customer and the SP should arrange in advance whether or not to allow control-plane protocol interaction between the CE devices and the PE device. To provide seamless operation with multicast data transport, the transparent operation of Ethernet control protocols (e.g., the Spanning Tree Protocol (STP) [IEEE-802-1D]) can be employed by customers.
客户和SP应提前安排是否允许CE设备和PE设备之间的控制平面协议交互。为了提供多播数据传输的无缝操作，客户可以采用以太网控制协议（例如，生成树协议（STP）[IEEE-802-1D]）的透明操作。
To support efficient dynamic transport, Ethernet multicast control frames (e.g., GARP/GMRP [IEEE-802-1D]) can be used between the CE and the PE. However, solutions MUST NOT assume that all CEs are always running such protocols (typically in the case where a CE is a router and is not aware of Layer 2 details).
为了支持高效的动态传输，可以在CE和PE之间使用以太网多播控制帧（例如，GARP/GMRP[IEEE-802-1D]）。但是，解决方案不得假设所有CE始终运行此类协议（通常在CE是路由器且不知道第2层细节的情况下）。
The destination MAC addresses of these L2CP PDUs fall within two reserved blocks specified by the IEEE 802.1 Working Group. Packets with destination MAC addresses in these multicast ranges have special forwarding rules.
这些L2CP PDU的目标MAC地址位于IEEE 802.1工作组指定的两个保留块内。目标MAC地址在这些多播范围内的数据包具有特殊的转发规则。
o Bridge block of protocols: 01-80-C2-00-00-00 through 01-80-C2-00-00-0F
o 协议桥接块：01-80-C2-00-00-00至01-80-C2-00-00-0F
o MRP block of protocols: 01-80-C2-00-00-20 through 01-80-C2-00-00-2F
o MRP协议块：01-80-C2-00-00-20至01-80-C2-00-00-2F
Layer 2 protocol tunneling allows SPs to pass subscriber Layer 2 control PDUs across the network without being interpreted and processed by intermediate network devices. These L2CP PDUs are transparently encapsulated across the MPLS-enabled core network in QinQ fashion.
第2层协议隧道允许SP通过网络传递订户第2层控制PDU，而无需中间网络设备进行解释和处理。这些L2CP PDU以QinQ方式透明地封装在支持MPLS的核心网络中。
The "L2CP-control" container contains the list of commonly used L2CP protocols and parameters. The SP can specify discard-mode, peer-mode, or tunnel-mode actions for each individual protocol.
“L2CP控制”容器包含常用L2CP协议和参数的列表。SP可以为每个协议指定放弃模式、对等模式或隧道模式操作。
The advent of Ethernet as a wide-area network technology brings the additional requirements of end-to-end service monitoring and fault management in the SP network, particularly in the area of service availability and Mean Time To Repair (MTTR). Ethernet Service OAM in the L2SM refers to the combined protocol suites of IEEE 802.1ag [IEEE-802-1ag] and ITU-T Y.1731 [ITU-T-Y-1731].
以太网作为一种广域网技术的出现，对SP网络中的端到端服务监控和故障管理提出了额外的要求，特别是在服务可用性和平均修复时间（MTTR）方面。L2SM中的以太网服务OAM是指IEEE 802.1ag[IEEE-802-1ag]和ITU-T Y.1731[ITU-T-Y-1731]的组合协议套件。
Generally speaking, Ethernet Service OAM enables SPs to perform service continuity checks, fault isolation, and packet delay/jitter measurement at per-customer and per-site-network-access granularity. The information collected from Ethernet Service OAM data sets is complementary to other higher-layer IP/MPLS OSS tools to ensure that the required SLAs can be met.
一般来说，以太网服务OAM使SP能够在每个客户和每个站点的网络访问粒度上执行服务连续性检查、故障隔离和数据包延迟/抖动测量。从以太网服务OAM数据集收集的信息是对其他更高层IP/MPLS OSS工具的补充，以确保满足所需的SLA。
The 802.1ag Connectivity Fault Management (CFM) functional model is structured with hierarchical Maintenance Domains (MDs), each assigned with a unique maintenance level. Higher-level MDs can be nested over lower-level MDs. However, the MDs cannot intersect. The scope of each MD can be solely within a customer network or solely within the SP network. An MD can interact between CEs and PEs (customer-to-provider) or between PEs (provider-to-provider), or it can tunnel over another SP network.
802.1ag连接故障管理（CFM）功能模型由分层维护域（MDs）构成，每个域分配有唯一的维护级别。较高级别的MDs可以嵌套在较低级别的MDs上。但是，MDs不能相交。每个MD的范围可以仅在客户网络内，也可以仅在SP网络内。MD可以在CEs和PEs（客户到提供商）或PEs（提供商到提供商）之间进行交互，也可以通过另一个SP网络进行隧道传输。
Depending on the use-case scenario, one or more Maintenance Entity Group End Points (MEPs) can be placed on the external-facing interface, sending CFM PDUs towards the core network ("Up MEP") or downstream link ("Down MEP").
根据用例场景，一个或多个维护实体组端点（MEP）可以放置在面向外部的接口上，将CFM PDU发送到核心网络（“上MEP”）或下游链路（“下MEP”）。
The "cfm-802.1-ag" sub-container under "site-network-access" presents the CFM Maintenance Association (MA), i.e., Down MEP for the UNI MA.
“站点网络访问”下的“cfm-802.1-ag”子容器显示cfm维护关联（MA），即UNI MA的Down MEP。
For each MA, the user can define the Maintenance Association Identifier (MAID), MEP level, MEP direction, Remote MEP ID, CoS level of the CFM PDUs, Continuity Check Message (CCM) interval and hold time, alarm-priority defect (i.e., the lowest-priority defect that is allowed to generate a fault alarm), CCM priority type, etc.
对于每个MA，用户可以定义维护关联标识符（MAID）、MEP级别、MEP方向、远程MEP ID、CFM PDU的CoS级别、连续性检查消息（CCM）间隔和保持时间、报警优先级缺陷（即允许生成故障报警的最低优先级缺陷）、CCM优先级类型等。
ITU-T Y.1731 Performance Monitoring (PM) provides essential network telemetry information that includes the measurement of Ethernet service frame delay, frame delay variation, frame loss, and frame throughput. The delay/jitter measurement can be either one-way or two-way. Typically, a Y.1731 PM probe sends a small amount of synthetic frames along with service frames to measure the SLA parameters.
ITU-T Y.1731性能监测（PM）提供基本的网络遥测信息，包括以太网服务帧延迟、帧延迟变化、帧丢失和帧吞吐量的测量。延迟/抖动测量可以是单向的，也可以是双向的。通常，Y.1731 PM探测器随服务帧一起发送少量合成帧，以测量SLA参数。
The "y-1731" sub-container under "site-network-access" contains a set of parameters to define the PM probe information, including MAID, local and Remote MEP ID, PM PDU type, message period and measurement interval, CoS level of the PM PDUs, loss measurement by synthetic or service frame options, one-way or two-way delay measurement, PM frame size, and session type.
“站点网络访问”下的“y-1731”子容器包含一组用于定义PM探测信息的参数，包括MAID、本地和远程MEP ID、PM PDU类型、消息周期和测量间隔、PM PDU的CoS级别、通过合成或服务帧选项进行的损耗测量、单向或双向延迟测量、PM帧大小、，和会话类型。
A VPN has a particular service topology, as described in Section 5.2.2. As a consequence, each site belonging to a VPN is assigned a particular role in this topology. The site-role leaf defines the role of the site in a particular VPN topology.
VPN具有特定的服务拓扑，如第5.2.2节所述。因此，属于VPN的每个站点在此拓扑中都分配了特定的角色。站点角色叶定义站点在特定VPN拓扑中的角色。
In the any-to-any VPN service topology, all sites MUST have the same role, which will be "any-to-any-role".
在任意对任意VPN服务拓扑中，所有站点必须具有相同的角色，即“任意对任意角色”。
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 more VPNs. The "site-vpn-flavor" defines the way that the VPN multiplexing is done. There are four possible types of external-facing connections associated with an EVPN service and a site. Therefore, the model supports four flavors:
一个站点可能是一个或多个VPN的一部分。“站点vpn风格”定义了vpn多路复用的方式。与EVPN服务和站点相关联的外部连接可能有四种类型。因此，该模型支持四种风格：
o site-vpn-flavor-single: The site belongs to only one VPN.
o 站点vpn：该站点只属于一个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-nni: The site represents an NNI where two administrative domains belonging to the same or different providers interconnect.
o 站点vpn风格nni：站点表示nni，其中属于相同或不同提供商的两个管理域相互连接。
o site-vpn-flavor-e2e: The site represents an end-to-end multi-segment connection.
o site-vpn-flavor-e2e：该站点表示端到端多段连接。
Figure 14 depicts a single VPN attachment. The site connects to only one VPN.
图14描述了单个VPN附件。该站点仅连接到一个VPN。
+--------+
+------------------+ Site / \
| |-----------------------------| |
| |***(site-network-access#1)***| VPN1 |
| New York Office | | |
| |***(site-network-access#2)***| |
| |-----------------------------| |
+------------------+ \ /
+--------+
+--------+
+------------------+ Site / \
| |-----------------------------| |
| |***(site-network-access#1)***| VPN1 |
| New York Office | | |
| |***(site-network-access#2)***| |
| |-----------------------------| |
+------------------+ \ /
+--------+
Figure 14: Single VPN Attachment
图14：单个VPN附件
Figure 15 shows a site connected to multiple VPNs.
图15显示了连接到多个VPN的站点。
+---------+
+---/----+ \
+------------------+ Site / | \ |
| |--------------------------------- | |VPN B|
| |***(site-network-access#1)******* | | |
| New York Office | | | | |
| |***(site-network-access#2)******* \ | /
| |-----------------------------| VPN A+-----|---+
+------------------+ \ /
+--------+
+---------+
+---/----+ \
+------------------+ Site / | \ |
| |--------------------------------- | |VPN B|
| |***(site-network-access#1)******* | | |
| New York Office | | | | |
| |***(site-network-access#2)******* \ | /
| |-----------------------------| VPN A+-----|---+
+------------------+ \ /
+--------+
Figure 15: Multi-VPN Attachment
图15：多VPN连接
In Figure 15, the New York office is multihomed. Both logical accesses are using the same VPN attachment rules, and both are connected to VPN A and to VPN B.
在图15中，纽约办事处是多址的。两个逻辑访问都使用相同的VPN连接规则，并且都连接到VPN A和VPN B。
Reaching VPN A or VPN B from the New York office will be done via MAC destination-based forwarding. Having the same destination reachable from the two VPNs may cause routing problems. The customer
从纽约办事处到达VPN A或VPN B将通过基于MAC目的地的转发完成。如果两个VPN可以到达相同的目的地，则可能会导致路由问题。顾客
administration's role in this case would be to ensure the appropriate mapping of its MAC addresses in each VPN. See Sections 5.5.2 and 5.10.2 for more details. See also Section 5.10.3 for details regarding support for BUM.
在这种情况下，管理部门的作用是确保其MAC地址在每个VPN中的适当映射。详见第5.5.2节和第5.10.2节。有关BUM支持的详细信息，请参见第5.10.3节。
A Network-to-Network Interface (NNI) scenario may be modeled using the sites container. 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., Access Control Lists (ACLs), routing policies).
可以使用站点容器对网络到网络接口（NNI）场景进行建模。SP指出请求的VPN连接不是常规站点，而是NNI是很有帮助的，因为特定的默认设备配置参数可以应用于NNI（例如访问控制列表（ACL）、路由策略）。
SP A SP B
------------------- -------------------
/ \ / \
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (MAC-VRF1)-(VPN1)-(MAC-VRF1)+ |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + (MAC-VRF2)-(VPN2)-(MAC-VRF2)+ |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (MAC-VRF1)-(VPN1)-(MAC-VRF1)+ |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + (MAC-VRF2)-(VPN2)-(MAC-VRF2)+ |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
SP A SP B
------------------- -------------------
/ \ / \
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (MAC-VRF1)-(VPN1)-(MAC-VRF1)+ |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + (MAC-VRF2)-(VPN2)-(MAC-VRF2)+ |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (MAC-VRF1)-(VPN1)-(MAC-VRF1)+ |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + (MAC-VRF2)-(VPN2)-(MAC-VRF2)+ |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
Figure 16: Option A NNI Scenario
图16：选项A NNI场景
Figure 16 illustrates 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 type will be used to inform SP B that this is an NNI and not a regular customer site.
图16展示了一个选项A NNI场景，该场景可以使用sites容器进行建模。为了连接SP B中的客户vpn（VPN1和VPN2），SP A可能会请求创建一些到SP B的站点网络访问。站点vpn类型将用于通知SP B这是一个nni，而不是一个常规客户站点。
An end-to-end (E2E) multi-segment VPN connection to be constructed out of several connectivity segments may be modeled. It is helpful for the SP to indicate that the requested VPN connection is not a regular site but rather is an end-to-end VPN connection, as specific default device configuration parameters may be applied in the case of site-vpn-flavor-e2e (e.g., QoS configuration). In order to establish a connection between Site 1 in SP A and Site 2 in SP B spanning multiple domains, SP A may request the creation of end-to-end connectivity to SP B. The site-vpn-flavor-e2e type will be used to indicate that this is an end-to-end connectivity setup and not a regular customer site.
可以对由多个连接段构成的端到端（E2E）多段VPN连接进行建模。SP指出请求的VPN连接不是常规站点，而是端到端VPN连接是有帮助的，因为在site-VPN-flavor-e2e（例如，QoS配置）的情况下可以应用特定的默认设备配置参数。为了在SP a中的站点1和SP B中的站点2之间建立跨多个域的连接，SP a可以请求创建到SP B的端到端连接。Site-vpn-flavor-e2e类型将用于指示这是端到端连接设置，而不是常规客户站点。
Due to the multiple site-vpn flavors, the attachment of a site to an L2VPN 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:
由于多站点vpn的特性，站点到L2VPN的连接是通过“vpn连接”容器在站点网络访问（逻辑访问）级别完成的。vpn附件容器是必需的。该模型提供了两种将站点连接到VPN的方法：
o By referencing the target VPN directly.
o 通过直接引用目标VPN。
o By referencing a VPN policy for attachments that are more complex.
o 通过为更复杂的附件引用VPN策略。
These options 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. 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 id时，必须添加站点角色设置，以表示站点在目标vpn服务拓扑中的角色。
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
<vpn-service>
<vpn-id>VPNB</vpn-id>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</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>
<network-access-id>LA1</network-access-id>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
<carrierscarrier>
<signaling-type>bgp</signaling-type>
</carrierscarrier>
<svc-mtu>1514</svc-mtu>
</service>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<network-access-id>LA2</network-access-id>
<service>
<svc-bandwidth>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
<vpn-service>
<vpn-id>VPNB</vpn-id>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</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>
<network-access-id>LA1</network-access-id>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
<carrierscarrier>
<signaling-type>bgp</signaling-type>
</carrierscarrier>
<svc-mtu>1514</svc-mtu>
</service>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<network-access-id>LA2</network-access-id>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
<carrierscarrier>
<signaling-type>bgp</signaling-type>
</carrierscarrier>
<svc-mtu>1514</svc-mtu>
</service>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l2vpn-svc>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
<carrierscarrier>
<signaling-type>bgp</signaling-type>
</carrierscarrier>
<svc-mtu>1514</svc-mtu>
</service>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l2vpn-svc>
The example above describes a multi-VPN case where a site (SITE 1) has two logical accesses (LA1 and LA2), attached to both VPNA and VPNB.
上面的示例描述了多VPN情况，其中站点（站点1）有两个逻辑访问（LA1和LA2），连接到VPNA和VPNB。
The "vpn-policy" list helps express a multi-VPN scenario where a logical access belongs to multiple VPNs.
“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 at the site should be part of a particular VPN. A site can be composed of multiple LAN segments, and each LAN segment can be connected to a different 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策略列表可能由多个条目组成。可以应用筛选器来指定只有站点上的某些LAN应该是特定VPN的一部分。一个站点可以由多个LAN段组成，每个LAN段可以连接到不同的VPN。每次站点（或LAN）连接到VPN时，用户必须准确描述其在目标VPN服务拓扑中的角色（站点角色）。
+---------------------------------------------------------------+
| Site 1 ------ PE7 |
+-------------------------+ [VPN2] |
| |
+-------------------------+ |
| Site 2 ------ PE3 PE4 ------ Site 3 |
+-----------------------------------+ |
| |
+-------------------------------------------------------------+ |
| Site 4 ------ PE5 | PE6 ------ Site 5 | |
| | |
| [VPN3] | |
+-------------------------------------------------------------+ |
| |
+----------------------------+
+---------------------------------------------------------------+
| Site 1 ------ PE7 |
+-------------------------+ [VPN2] |
| |
+-------------------------+ |
| Site 2 ------ PE3 PE4 ------ Site 3 |
+-----------------------------------+ |
| |
+-------------------------------------------------------------+ |
| Site 4 ------ PE5 | PE6 ------ Site 5 | |
| | |
| [VPN3] | |
+-------------------------------------------------------------+ |
| |
+----------------------------+
Figure 17: VPN Policy Example
图17:VPN策略示例
In Figure 17, Site 5 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 multi-VPN scenario as follows:
在图17中，站点5是两个VPN的一部分：VPN3和VPN2。它将在VPN2中扮演中心角色，在VPN3中扮演任意对任意角色。我们可以将这种多VPN场景表示为：
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPN2</vpn-id>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
<vpn-service>
<vpn-id>VPN3</vpn-id>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
<sites>
<site>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<site-id>Site5</site-id>
<vpn-policies>
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPN2</vpn-id>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
<vpn-service>
<vpn-id>VPN3</vpn-id>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
<sites>
<site>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<site-id>Site5</site-id>
<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>
<network-access-id>LA1</network-access-id>
<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>
<network-access-id>LA1</network-access-id>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
<carrierscarrier>
<signaling-type>bgp</signaling-type>
</carrierscarrier>
<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>
<network-access-id>LA1</network-access-id>
<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>
<network-access-id>LA1</network-access-id>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
<carrierscarrier>
<signaling-type>bgp</signaling-type>
</carrierscarrier>
<svc-mtu>1514</svc-mtu>
</service>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<network-access-id>LA2</network-access-id>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
<carrierscarrier>
<signaling-type>bgp</signaling-type>
</carrierscarrier>
<svc-mtu>1514</svc-mtu>
</service>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<vpn-attachment>
<vpn-policy-id>POLICY1</vpn-policy-id>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l2vpn-svc>
<svc-mtu>1514</svc-mtu>
</service>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<network-access-id>LA2</network-access-id>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
<carrierscarrier>
<signaling-type>bgp</signaling-type>
</carrierscarrier>
<svc-mtu>1514</svc-mtu>
</service>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<vpn-attachment>
<vpn-policy-id>POLICY1</vpn-policy-id>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l2vpn-svc>
Now, if a more granular VPN attachment is necessary, filtering can be used. For example, if LAN1 from Site 5 must be attached to VPN2 as a Hub and LAN2 must be attached to VPN3, the following configuration can be used:
现在，如果需要更细粒度的VPN附件，可以使用过滤。例如，如果站点5的LAN1必须作为集线器连接到VPN2，LAN2必须连接到VPN3，则可以使用以下配置：
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPN2</vpn-id>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
<vpn-service>
<vpn-id>VPN3</vpn-id>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
<sites>
<site>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<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>
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPN2</vpn-id>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
<vpn-service>
<vpn-id>VPN3</vpn-id>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
<sites>
<site>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<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>
<network-access-id>LA1</network-access-id>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
<carrierscarrier>
<signaling-type>bgp</signaling-type>
</carrierscarrier>
<svc-mtu>1514</svc-mtu>
</service>
<vpn-attachment>
<vpn-policy-id>POLICY1</vpn-policy-id>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l2vpn-svc>
<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>
<network-access-id>LA1</network-access-id>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
<carrierscarrier>
<signaling-type>bgp</signaling-type>
</carrierscarrier>
<svc-mtu>1514</svc-mtu>
</service>
<vpn-attachment>
<vpn-policy-id>POLICY1</vpn-policy-id>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l2vpn-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 or aggregation switch).
管理系统必须确定将特定站点的每个站点网络访问连接到提供商网络（例如PE或聚合交换机）的位置。
This 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 the user with information regarding any constraints that could not be fulfilled. How this 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 5.6.2) and access type (see Section 5.6.3) affect the service placement that the management system applies.
现场位置（见第5.6.2节）和通道类型（见第5.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, e.g., least load, distance.
除参数和约束外，管理系统的决策可能基于SP留下的任何其他内部约束，例如，最小负载、距离。
In the case of provider management or co-management, one or more devices have been ordered by the customer to a particular location that has already been configured. The customer may force a particular site-network-access to be connected on a particular device that it ordered.
在提供商管理或共同管理的情况下，客户已将一个或多个设备订购到已配置的特定位置。客户可以强制将特定站点网络访问连接到其订购的特定设备上。
New York Site
+------------------+ Site
| +--------------+ |-------------------------------------
| | Manhattan | |
| | CE1********* (site-network-access#1) ******
| +--------------+ |
| +--------------+ |
| | Brooklyn | |
| | CE2********* (site-network-access#2) ******
| +--------------+ |
| |-------------------------------------
+------------------+
New York Site
+------------------+ Site
| +--------------+ |-------------------------------------
| | Manhattan | |
| | CE1********* (site-network-access#1) ******
| +--------------+ |
| +--------------+ |
| | Brooklyn | |
| | CE2********* (site-network-access#2) ******
| +--------------+ |
| |-------------------------------------
+------------------+
Figure 18: Example of a Constraint Applied to a Device
图18：应用于设备的约束示例
In Figure 18, site-network-access#1 is associated with CE1 in the service request. The SP must ensure the provisioning of this connection.
在图18中，站点网络访问#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 3166 code and is similar to the "country" label defined in [RFC4119].
管理系统可以使用此模型中提供的位置信息来确定要与站点（SP侧）啮合的目标PE。配置时，特定位置必须与每个站点网络访问相关联。SP必须在与站点网络访问相关的位置（客户端）终止访问。现场位置中的“国家代码”应表示为ISO 3166代码，并与[RFC4119]中定义的“国家”标签类似。
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.
站点网络访问位置由“位置风格”决定。对于供应商管理或共同管理的站点，用户需要配置“设备参考”（设备案例），将站点网络访问绑定到客户订购的特定设备。由于每个设备已经与特定位置相关联，在这种情况下，从设备位置检索位置信息。对于客户管理的站点，用户需要配置“位置参考”（位置案例）；这将提供对现有配置位置的引用，并有助于放置。
POP#1 (New York)
+---------+
| PE1 |
Site 1 ---... | PE2 |
(Atlantic City) | PE3 |
+---------+
POP#1 (New York)
+---------+
| PE1 |
Site 1 ---... | PE2 |
(Atlantic City) | PE3 |
+---------+
POP#2 (Washington)
+---------+
| PE4 |
| PE5 |
| PE6 |
+---------+
POP#2 (Washington)
+---------+
| PE4 |
| PE5 |
| PE6 |
+---------+
POP#3 (Philadelphia)
+---------+
| PE7 |
Site 2 CE#1---... | PE8 |
(Reston) | PE9 |
+---------+
POP#3 (Philadelphia)
+---------+
| PE7 |
Site 2 CE#1---... | PE8 |
(Reston) | PE9 |
+---------+
Figure 19: Location Information for Sites
图19：站点的位置信息
In Figure 19, 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
在图19中，站点1是位置为“L1”的客户管理站点，而站点2是订购CE（CE#1）的供应商管理站点。站点2配置了“L2”作为其位置。什么时候
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，以便管理系统知道访问需要在该位置终止。然后，由于距离的原因，该管理系统可能会在费城POP的PE上与Site 1啮合。它还可以考虑PEs上可用的资源，以确定确切的目标PE（例如，负载最少）。对于站点2，用户需要使用对CE#1的设备引用来配置站点网络访问，以便管理系统知道访问必须在CE#1的位置终止，并且必须连接到CE#1。对于接入连接的SP侧的放置，如果使用的是最近的PE，则其可能与华盛顿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”，则必须将其视为严格约束，以便管理系统无法将站点连接到其他媒体类型。如果“strict”页等于“false”（默认值），并且如果无法满足请求的媒体类型，则管理系统可以选择其他媒体类型。支持的媒体类型应由SP通过本文档范围之外的机制传达给客户。
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-in access type).
o “始终打开”叶定义了一个严格的约束：如果设置为“真”，管理系统必须选择“始终打开”的媒体类型（例如，这意味着没有拨入访问类型）。
o The "bearer-reference" parameter is used in cases where the customer has already ordered a network connection to the SP apart from the L2VPN 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 an 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 如果客户已经订购了除L2VPN站点之外的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 "input svc-bandwidth" and "output svc-bandwidth", to help decide which access type to use.
也可以使用SP的任何其他内部参数。管理系统可以使用其他参数，例如请求的“输入svc带宽”和“输出svc带宽”，来帮助决定使用哪种接入类型。
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.
每个站点网络访问可能有一个或多个约束，这些约束将驱动访问的放置。默认情况下，该模型假设不存在约束，但预期每个站点网络访问分配唯一的承载。
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") 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 to which they belong. 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.
为了帮助不同的放置场景，可以使用一个或多个组标识符标记站点网络访问。组标识符是一个字符串，因此它可以同时容纳一组站点的显式命名（例如，“多址set1”）和编号标识符的使用（例如12345678）。每个组id的含义对于每个客户管理员都是本地的，管理系统必须确保不同的客户可以使用相同的组id。还可以在站点级别定义一个或多个组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 (i.e., the already-configured site-network-access) MUST never be taken into account in the targeted set of site-network-accesses -- 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 to which the current site-network-access does not belong.
对于已配置的站点网络访问，必须针对一组目标站点网络访问表达每个约束。此站点网络访问（即，已配置的站点网络访问）决不能在目标站点网络访问集中考虑在内，例如，“我的站点网络访问不得与属于组10的站点网络访问连接在同一POP上。”对约束进行评估的站点网络访问集可以表示为组列表、“所有其他访问”或“所有其他组”。“所有其他访问”选项意味着必须根据属于当前站点的所有其他站点网络访问来评估当前站点网络访问约束。“所有其他组”选项意味着必须针对当前站点网络访问不属于的所有组评估约束。
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多样化：当前站点网络访问不得连接到与目标站点网络访问相同的pe。
o pop-diverse: The current site-network-access MUST NOT be connected to the same POP as the targeted site-network-accesses.
o pop多样化：当前站点网络访问不得连接到与目标站点网络访问相同的pop。
o linecard-diverse: The current site-network-access MUST NOT be connected to the same linecard as the targeted site-network-accesses. Note that the customer can request linecard-diverse for site-network-accesses, but the specific linecard identifier used should not be exposed to the customer.
o 线路卡多样性：当前站点网络访问不得连接到与目标站点网络访问相同的线路卡。请注意，客户可以为站点网络访问请求不同的线路卡，但所使用的特定线路卡标识符不应向客户公开。
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 Digital Subscriber Line Access Multiplexer (DSLAM), Broadband Access Switch (BAS), or Layer 2 switch.
o 承载多样化：与目标站点网络访问使用的承载相比，当前站点网络访问不得使用公共承载组件。“承载多样性”在接入层提供一定程度的多样性。例如，两个不同承载站点网络接入不得使用相同的数字用户线接入多路复用器（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 相同pe：当前站点网络访问必须连接到与目标站点网络访问相同的pe。
o same-bearer: The current site-network-access MUST be connected using the same bearer as the targeted site-network-accesses.
o 相同承载：当前站点网络访问必须使用与目标站点网络访问相同的承载进行连接。
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>站点网络访问的<constraint type>（例如，pe多样化、pop多样化）。”
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.
用于针对某些站点网络访问的组id可能与当前站点网络访问使用的组id相同。这简化了一组站点网络接入点在组中的接入点之间具有约束的场景的配置。
The Route Distinguisher (RD) is a critical parameter of BGP-based L2VPNs 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 MAC-VRF on the target PE and an RD for that MAC-VRF; that RD MUST be unique across all MAC-VRFs on the target PE.
路由识别器（RD）是[RFC4364]中描述的基于BGP的L2VPN的一个关键参数，它提供了区分不同VPN中常见寻址计划的能力。对于路由目标（RTs），预期管理系统将在目标PE上分配MAC-VRF，并为该MAC-VRF分配RD；该RD在目标PE上的所有MAC VRF中必须是唯一的。
If a MAC-VRF already exists on the target PE and the MAC-VRF fulfills the connectivity constraints for the site, there is no need to recreate another MAC-VRF, and the site MAY be meshed within the existing MAC-VRF. How the management system checks to see if an existing MAC-VRF fulfills the connectivity constraints for a site is out of scope for this document.
如果目标PE上已经存在MAC-VRF，并且MAC-VRF满足站点的连接约束，则无需重新创建另一个MAC-VRF，并且站点可以在现有MAC-VRF内啮合。管理系统如何检查现有MAC-VRF是否满足站点的连接约束超出了本文档的范围。
If no such MAC-VRF exists on the target PE, the management system has to initiate the creation of a new MAC-VRF on the target PE and has to allocate a new RD for the new MAC-VRF.
如果目标PE上不存在此类MAC-VRF，则管理系统必须在目标PE上创建新的MAC-VRF，并且必须为新的MAC-VRF分配新的RD。
The management system MAY apply a per-VPN or per-MAC-VRF allocation policy for the RD, depending on the SP's policy. In a per-VPN allocation policy, all MAC-VRFs (dispatched on multiple PEs) within a VPN will share the same RD value. In a per-MAC-VRF model, all MAC-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或每MAC VRF分配策略。在每VPN分配策略中，VPN内的所有MAC VRF（在多个PE上调度）将共享相同的RD值。在每MAC VRF模型中，所有MAC VRF应始终具有唯一的RD值。也可以使用其他一些分配策略，本文档不限制要使用的分配策略。
The allocation of RDs MAY be done in the same way as RTs. The information provided in Section 5.2.2.1 could also be used in this scenario.
RDs的分配可采用与RTs相同的方式进行。第5.2.2.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可能会为RDs的自动分配配置目标PE。在这种情况下，任何后端系统都不需要分配RD值。
A site may be multihomed, meaning that it has multiple site-network-access points. The placement constraints defined in Section 5.6 will help ensure physical diversity.
一个站点可以是多址的，这意味着它有多个站点网络接入点。第5.6节中定义的布局约束将有助于确保物理多样性。
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. The "redundancy-mode" attribute is defined for a multihoming site and used to model single-active and active/active scenarios. It allows for multiple active paths in forwarding state and for load-balancing options.
当站点网络访问置于网络上时，客户可能希望在这些访问上使用特定的路由策略。“站点网络访问/可用性”容器定义站点冗余的参数。“访问优先级”叶定义特定访问的首选项。此首选项用于为负载平衡或主/备份场景建模。访问优先级值越高，首选项越高。“冗余模式”属性是为多主站点定义的，用于对单个活动和活动/活动场景建模。它允许多个处于转发状态的活动路径以及负载平衡选项。
Figure 20 illustrates how the access-priority attribute can be used.
图20说明了如何使用访问优先级属性。
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 |
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)
PE5
|
|
|
CE5
|
Spoke#1 site (Single-homed)
Figure 20: Example: Configuring Access Priority
图20：示例：配置访问优先级
In Figure 20, 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.
在图20中，Hub#2需要负载共享，因此所有站点网络访问必须使用相同的访问优先级值。另一方面，由于Hub#1需要主站点网络访问和备份站点网络访问，将在主站点网络访问上配置更高的访问优先级设置。
Scenarios that are more complex can also be modeled. Let's consider a Hub site with five accesses to the network (A1, A2, A3, A4, and A5). The customer wants to load-share its traffic on A1 and 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, A2, A3, and A4 are all down, the customer 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）。客户希望在正常情况下在A1和A2上加载共享流量。如果A1和A2失败，客户希望在A3和A4上加载共享其流量；最后，如果A1、A2、A3和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 only A1 or A2 (not both) is down is not achievable. But the access-priority attribute defined will cover most of the deployment use cases, and if necessary the model can be extended via augmentation to support additional use cases.
访问优先级场景有一些限制。与前一种具有五次访问的访问优先级场景类似，但在只有A1或A2（不是两者）停机的情况下，A3和A4之间共享流量负载的约束是不可能实现的。但是定义的访问优先级属性将覆盖大多数部署用例，如果需要，可以通过扩展扩展模型来支持其他用例。
The MTU of subscriber service frames can be derived from the physical interface MTU by default, or it can be specified under the "svc-mtu" leaf if it is different than the default number.
默认情况下，用户服务帧的MTU可以从物理接口MTU派生，或者如果它不同于默认编号，则可以在“svc MTU”叶下指定。
The service container defines service parameters associated with the site.
服务容器定义与站点关联的服务参数。
The service bandwidth refers to the bandwidth requirement between the CE and the PE and can be represented using the Committed Information Rate (CIR), the Excess Information Rate (EIR), or the Peak Information Rate (PIR). The requested bandwidth is expressed as ingress bandwidth and egress bandwidth. The ingress or egress direction uses the customer site as the point of reference: "ingress-direction bandwidth" refers to download bandwidth for the site, and "egress-direction bandwidth" refers to upload bandwidth for the site.
服务带宽是指CE和PE之间的带宽需求，可以使用提交信息速率（CIR）、超额信息速率（EIR）或峰值信息速率（PIR）来表示。请求的带宽表示为入口带宽和出口带宽。入口或出口方向使用客户站点作为参考点：“入口方向带宽”指站点的下载带宽，“出口方向带宽”指站点的上传带宽。
The service bandwidth is only configurable at the site-network-access level (i.e., for the site network access associated with the site).
服务带宽仅可在站点网络访问级别配置（即，对于与站点相关联的站点网络访问）。
Using a different ingress and egress bandwidth will allow an SP to know if a customer allows for asymmetric bandwidth access like ADSL. It can also be used to set the rate limit in a different way for uploads and downloads on symmetric bandwidth access.
使用不同的入口和出口带宽将允许SP知道客户是否允许像ADSL这样的非对称带宽访问。它还可以用于以不同的方式为对称带宽访问上的上载和下载设置速率限制。
The svc-bandwidth parameter has a specific type. This document defines four types:
svc带宽参数具有特定类型。本文件定义了四种类型：
o bw-per-access: bandwidth is per connection or site network access, providing rate enforcement for all service frames at the interface that are associated with a particular network access.
o bw per access：带宽是每个连接或站点网络访问的带宽，为接口上与特定网络访问相关联的所有服务帧提供速率强制。
o bw-per-cos: bandwidth is per CoS, providing rate enforcement for all service frames for a given CoS with a specific cos-id.
o bw per cos：带宽是per cos，为具有特定cos-id的给定cos的所有服务帧提供速率强制。
o bw-per-svc: bandwidth is per site, providing rate enforcement for all service frames that are associated with a particular VPN service.
o bw per svc：带宽是每个站点的带宽，为与特定VPN服务关联的所有服务帧提供速率强制。
o opaque bandwidth is the total bandwidth that is not associated with any particular cos-id, VPN service identified with the vpn-id, or site network access ID.
o 不透明带宽是与任何特定cos id、用VPN id标识的VPN服务或站点网络访问id不关联的总带宽。
The svc-bandwidth parameter must include a "cos-id" parameter if the "type" is set to "bw-per-cos". The cos-id can be assigned based on either (1) the IEEE 802.1p value [IEEE-802-1D] in the C-tag or (2) the Differentiated Services Code Point (DSCP) in the Ethernet frame header. Service frames are metered against the bandwidth profile based on the cos-id.
如果“类型”设置为“bw per cos”，则svc带宽参数必须包括“cos id”参数。cos id可以基于（1）C标签中的IEEE 802.1p值[IEEE-802-1D]或（2）以太网帧报头中的区分服务码点（DSCP）来分配。根据基于cos-id的带宽配置文件对服务帧进行计量。
The svc-bandwidth parameter must be associated with a specific "site-network-access-id" parameter if the "type" is set to "bw-per-access". Multiple bandwidths per cos-id can be associated with the same site network access.
如果“类型”设置为“每次访问bw”，则svc带宽参数必须与特定的“站点网络访问id”参数相关联。每个cos id的多个带宽可以与同一站点网络访问相关联。
The svc-bandwidth parameter must include a specific "vpn-id" parameter if the "type" is set to "bw-per-svc". Multiple bandwidths per cos-id can be associated with the same EVPN service.
如果“类型”设置为“每个svc的带宽”，则svc带宽参数必须包括特定的“vpn id”参数。每个cos id的多个带宽可以与同一EVPN服务相关联。
The model defines QoS parameters as an abstraction:
该模型将QoS参数定义为一种抽象：
o qos-classification-policy: Defines a set of ordered rules to classify customer traffic.
o qos分类策略：定义一组有序规则来对客户流量进行分类。
o qos-profile: Provides a QoS scheduling profile to be applied.
o qos配置文件：提供要应用的qos调度配置文件。
QoS classification rules are handled by "qos-classification-policy". qos-classification-policy is an ordered list of rules that match a flow or application and set the appropriate target CoS (target-class-id). The user can define the match using a more specific flow definition (based on Layer 2 source and destination MAC addresses, cos, dscp, cos-id, color-id, etc.). A "color-id" will be assigned to a service frame to identify its QoS profile conformance. A service frame is "green" if it is conformant with the "committed" rate of the bandwidth profile. A service frame is "yellow" if it exceeds the "committed" rate but is conformant with the "excess" rate of the bandwidth profile. Finally, a service frame is "red" if it is conformant with neither the "committed" rate nor the "excess" rate of the bandwidth profile.
QoS分类规则由“QoS分类策略”处理。qos分类策略是与流或应用程序匹配并设置适当目标CoS（目标类id）的规则的有序列表。用户可以使用更具体的流定义（基于第2层源和目标MAC地址、cos、dscp、cos id、color id等）定义匹配。“颜色id”将被分配给服务帧，以标识其QoS配置文件的一致性。若服务帧符合带宽配置文件的“提交”速率，则该服务帧为“绿色”。如果服务帧超过“提交”速率，但符合带宽配置文件的“超额”速率，则服务帧为“黄色”。最后，如果服务帧既不符合带宽配置文件的“提交”速率，也不符合带宽配置文件的“超额”速率，则服务帧为“红色”。
When a flow definition is used, the user can use a target-sites leaf-list to identify the destination of a flow rather than using destination addresses. In such a case, an association between the site abstraction and the MAC 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 L2VPN is done through the vpn-attachment container. Therefore, the user can also employ the
使用流定义时，用户可以使用目标站点叶列表来标识流的目的地，而不是使用目的地地址。在这种情况下，站点抽象和该站点使用的MAC地址之间的关联必须动态完成。如何进行关联超出了本文档的范围。站点与L2VPN的关联通过vpn附件容器完成。因此，用户还可以使用
"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. This 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.
“目标站点”叶列表和“vpn附件”，用于标识针对特定vpn服务的流的目标。没有“match”语句的规则被视为“match all”规则。如果客户未提供默认的终端分类规则，SP可以实施该规则。SP将决定其默认目标类。此模型定义了一些应用程序，但可以通过扩展添加新的应用程序标识。每个应用程序标识的确切含义由SP决定，因此SP有必要就应用程序匹配的使用向客户提供建议。
A user can choose between the standard profile provided by the operator or a custom profile. The QoS profile ("qos-profile") defines the traffic-scheduling policy to be used by the SP.
用户可以选择操作员提供的标准配置文件或自定义配置文件。QoS配置文件（“QoS配置文件”）定义SP要使用的流量调度策略。
A custom QoS profile is defined as a list of CoS entries and associated properties. The properties are as follows:
自定义QoS配置文件定义为CoS条目和相关属性的列表。其性质如下：
o direction: Used to specify the direction to which the qos-profile setting is applied. This model supports the site-to-WAN direction ("site-to-wan"), the WAN-to-site direction ("wan-to-site"), and both directions ("bidirectional"). By default, "bidirectional" is used. In the case of both directions, 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. In the case of the WAN-to-site direction, 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 方向：用于指定应用qos配置文件设置的方向。此模型支持站点到WAN方向（“站点到WAN”）、WAN到站点方向（“WAN到站点”）和双向（“双向”）。默认情况下，使用“双向”。在双向情况下，提供商应确保在两个流量方向（SP到客户和客户到SP）上根据请求的策略进行调度。例如，可以在WAN链路的PE侧和CE侧上实现设备调度策略。在WAN到站点的情况下，提供商应确保从SP网络到客户站点的调度。例如，设备调度策略可以仅在朝向客户的WAN链路的PE侧上实现。
o policing: Optional. Indicates whether policing should apply to one-rate, two-color or to two-rate, three-color.
o 警务：可选。指示是否应将策略应用于单速率双色或双速率三色。
o byte-offset: Optional. Indicates how many bytes in the service frame header are excluded from rate enforcement.
o 字节偏移量：可选。指示从速率强制中排除的服务帧标头中的字节数。
o frame-delay: Used to define the latency constraint of the class. The latency constraint can be expressed as the lowest possible latency or as a latency boundary expressed in milliseconds. How this latency constraint will be fulfilled is up to the SP implementation: a strict priority-queuing mechanism may be used on the access and in the core network, or a low-latency routing path may be created for this traffic class.
o 帧延迟：用于定义类的延迟约束。延迟约束可以表示为可能的最低延迟，也可以表示为以毫秒为单位的延迟边界。如何满足此延迟约束取决于SP实现：可以在访问和核心网络中使用严格的优先级排队机制，或者为此流量类别创建低延迟路由路径。
o frame-jitter: Used to define the jitter constraint of the class. The jitter constraint can be expressed as the lowest possible jitter or as a jitter boundary expressed in microseconds. How this jitter constraint will be fulfilled is up to the SP implementation: a strict priority-queuing mechanism may be used on the access and in the core network, or a jitter-aware routing path may be created for this traffic class.
o 帧抖动：用于定义类的抖动约束。抖动约束可以表示为可能的最低抖动或以微秒表示的抖动边界。如何满足这种抖动约束取决于SP实现：可以在接入和核心网络中使用严格的优先级排队机制，或者可以为此流量类别创建抖动感知路由路径。
o bandwidth: Used to define a guaranteed amount of bandwidth for the CoS. It is expressed as a percentage. The "guaranteed-bw-percent" parameter uses available bandwidth as a reference. The available bandwidth should not fall below the CIR value defined under the input svc-bandwidth or the output svc-bandwidth. When the "qos-profile" container is implemented on the CE side, the output svc-bandwidth is taken into account as a reference. When it is implemented on the PE side, the input svc-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-TE reservation, controller reservation) is out of scope for this document.
o 带宽：用于定义CoS的带宽保证量。它以百分比表示。“保证bw百分比”参数使用可用带宽作为参考。可用带宽不得低于输入svc带宽或输出svc带宽下定义的CIR值。当“qos配置文件”容器在CE端实现时，输出svc带宽将作为参考考虑。在PE端实现时，使用输入svc带宽。默认情况下，带宽保留仅在访问级别得到保证。用户可以使用“端到端”叶请求端到端带宽预留，包括通过MPLS传输网络。（换句话说，SP将激活MPLS核心中的某些内容，以确保来自客户的带宽请求也将由MPLS核心完成。）如何完成（例如，RSVP-TE保留、控制器保留）超出本文档的范围。
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.
此外，由于网络条件，SP可能无法完全满足某些约束条件；在这种情况下，SP应告知客户限制。如何进行沟通超出了本文件的范围。
The "broadcast-unknown-unicast-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.
“broadcast unknown unicast multicast”容器定义客户多播服务拓扑中的站点类型：源、接收器或两者。这些参数将帮助管理系统优化多播服务。
Multiple multicast group-to-port mappings can be created using the "multicast-gp-address-mapping" list. The "multicast-gp-address-mapping" list defines the multicast group address and port LAG number. Those parameters will help the SP select the appropriate association between an interface and a multicast group to fulfill the customer service requirement.
可以使用“多播gp地址映射”列表创建多个多播组到端口映射。“多播gp地址映射”列表定义了多播组地址和端口延迟号。这些参数将帮助SP选择接口和多播组之间的适当关联，以满足客户服务需求。
To ensure that a given frame is transparently transported, a whole Layer 2 multicast frame (whether for data or control) should not be altered from a CE to other CEs, except for the VLAN ID field. VLAN IDs assigned by the SP can also be altered.
为了确保透明地传输给定帧，不应将整个第2层多播帧（无论用于数据还是控制）从CE更改为其他CE，VLAN ID字段除外。SP分配的VLAN ID也可以更改。
For point-to-point services, the provider only needs to deliver a single copy of each service frame to the remote PE, regardless of whether the destination MAC address of the incoming frame is unicast, multicast, or broadcast. Therefore, all service frames should be delivered unconditionally.
对于点对点服务，提供商只需要向远程PE交付每个服务帧的单个副本，而不管传入帧的目标MAC地址是单播、多播还是广播。因此，应无条件交付所有服务帧。
BUM frame forwarding in multipoint-to-multipoint services, on the other hand, involves both local flooding to other ACs on the same PE and remote replication to all other PEs, thus consuming additional resources and core bandwidth. Special BUM frame disposition rules can be implemented at external-facing interfaces (UNIs or External NNIs (E-NNIs)) to rate-limit the BUM frames, in terms of the number of packets per second or bits per second.
另一方面，多点到多点服务中的BUM帧转发涉及到同一PE上的其他ACs的本地泛洪和到所有其他PE的远程复制，从而消耗额外的资源和核心带宽。可以在面向外部的接口（UNIs或外部NNI（E-NNI））上实现特殊的BUM帧配置规则，以每秒的数据包数或比特数对BUM帧进行速率限制。
The threshold can apply to all BUM traffic, or one threshold can be applied for each category of traffic.
该阈值可以应用于所有BUM流量，也可以对每类流量应用一个阈值。
The "management" sub-container is intended for site management options, depending on device ownership and security access control. Three common management models are as follows:
“管理”子容器用于站点管理选项，具体取决于设备所有权和安全访问控制。三种常见的管理模式如下：
Provider-managed CE: The provider has sole ownership of the CE device. Only the provider has access to the CE. The responsibility boundary between the SP and the customer is between the CE and the customer network. This is the most common use case.
提供商管理的CE：提供商拥有CE设备的唯一所有权。只有提供程序可以访问CE。SP和客户之间的责任边界是CE和客户网络之间的责任边界。这是最常见的用例。
Customer-managed CE: The customer has sole ownership of the CE device. Only the customer has access to the CE. In this model, the responsibility boundary between the SP and the customer is between the PE and the CE.
客户管理的CE：客户拥有CE设备的唯一所有权。只有客户可以访问CE。在此模型中，SP和客户之间的责任边界是PE和CE之间的。
Co-managed CE: The provider has ownership of the CE device and is responsible for managing the CE. However, the provider grants the customer access to the CE for some configuration/monitoring purposes. In this co-managed mode, the responsibility boundary is the same as for the provider-managed model.
共同管理CE：提供商拥有CE设备的所有权，并负责管理CE。但是，提供商出于某些配置/监控目的授予客户对CE的访问权。在此共同管理模式中，责任边界与提供者管理模型的责任边界相同。
The selected management mode is specified under the "type" leaf. The "address" leaf stores CE device management addressing information. The "management-transport" leaf is used to identify the transport protocol for management traffic: IPv4 or IPv6. Additional security options may be derived based on the particular management model selected.
选定的管理模式在“类型”页下指定。“地址”叶存储CE设备管理寻址信息。“管理传输”叶用于标识管理通信的传输协议：IPv4或IPv6。可以根据所选的特定管理模型导出其他安全选项。
MAC address flapping between different physical ports typically indicates a bridge loop condition in the customer network. Misleading entries in the MAC cache table can cause service frames to circulate around the network indefinitely and saturate the links throughout the provider's network, affecting other services in the same network. In the case of EVPNs, it also introduces massive BGP updates and control-plane instability.
不同物理端口之间的MAC地址摆动通常表示客户网络中的网桥环路状况。MAC缓存表中的误导性条目可能会导致服务帧在网络中无限循环，并使整个提供商网络中的链路饱和，从而影响同一网络中的其他服务。在EVPN的情况下，它还引入了大量BGP更新和控制平面不稳定。
The SP may opt to implement a switching loop-prevention mechanism at the external-facing interfaces for multipoint-to-multipoint services by imposing a MAC address move threshold.
SP可通过施加MAC地址移动阈值，选择在面向外部的接口处为多点到多点服务实施切换环路预防机制。
The MAC move rate and prevention-type options are listed in the "mac-loop-prevention" container.
MAC移动速率和预防类型选项列在“MAC环路预防”容器中。
The optional "mac-addr-limit" container contains the customer MAC address limit and information that describes the action taken when the limit is exceeded and the aging time for a MAC address.
可选的“mac addr limit”容器包含客户mac地址限制和描述超出限制时所采取的操作以及mac地址的老化时间的信息。
When multiple services are provided on the same network element, the MAC address table (and the Routing Information Base space for MAC routes in the case of EVPNs) is a shared common resource. SPs may impose a maximum number of MAC addresses learned from the customer for a single service instance by using the "mac-addr-limit" leaf and may use the "action" leaf to specify the action taken when the upper limit is exceeded: drop the packet, flood the packet, or simply send a warning log message.
当在同一网元上提供多个服务时，MAC地址表（以及在EVPN的情况下MAC路由的路由信息基空间）是共享的公共资源。SPs可通过使用“MAC地址限制”页为单个服务实例施加从客户处获悉的最大MAC地址数，并可使用“操作”页指定在超过上限时采取的操作：丢弃数据包、溢出数据包或仅发送警告日志消息。
For point-to-point services, if MAC learning is disabled, then the MAC address limit is not necessary.
对于点对点服务，如果禁用MAC学习，则不需要MAC地址限制。
In the case of Carriers' Carriers (CsC) [RFC8299], a customer may want to build an MPLS service using an L2VPN to carry its traffic.
在运营商的运营商（CsC）[RFC8299]的情况下，客户可能希望使用L2VPN构建MPLS服务来承载其流量。
LAN customer1
|
|
CE1
|
| -------------
(vrf_cust1)
CE1_ISP1
| ISP1 POP
| MPLS link
| -------------
|
(vrf ISP1)
PE1
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
PE2
(vrf ISP1)
|
| ------------
|
| MPLS link
| ISP1 POP
CE2_ISP1
(vrf_cust1)
| ------------
|
CE2
|
LAN customer1
Figure 21: MPLS Service Using an L2VPN to Carry Traffic
图21：使用L2VPN承载流量的MPLS服务
In Figure 21, ISP1 resells an L2VPN service but has no core network infrastructure between its POPs. ISP1 uses an L2VPN as the core network infrastructure (belonging to another provider) between its POPs.
在图21中，ISP1转售L2VPN服务，但其POP之间没有核心网络基础设施。ISP1使用L2VPN作为其POP之间的核心网络基础设施（属于另一个提供商）。
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 signaling protocol. This configuration is done at the site level.
为了支持CsC，VPN服务必须通过在VPN服务列表中将“CarrierCarrier”叶设置为“true”来指示MPLS支持。CE1_ISP1/PE1和CE2_ISP1/PE2之间的链路也必须运行MPLS信令协议。此配置在站点级别完成。
In this model, LDP or BGP can be used as the MPLS signaling protocol. In the case of LDP, an IGP routing protocol MUST also be activated. In the case of BGP signaling, 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 link MTU.
如果启用了CsC，则请求的“svc mtu”叶将引用MPLS mtu，而不是链接mtu。
The service model sometimes refers to external information through identifiers. As an example, to order 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 RESTCONF 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 qos-profile.
服务模型有时通过标识符引用外部信息。例如，为了向特定的云服务提供商（CSP）订购云访问，模型使用一个标识符来引用目标CSP。如果客户直接使用此服务模型作为API（例如通过RESTCONF或NETCONF）订购特定服务，则SP应提供授权标识符列表。在云访问的情况下，SP将为每个可用的CSP提供相关的标识符。这同样适用于其他标识符，例如qos配置文件。
As a usage example, the remote-carrier-name setting is used in the NNI case because it should be known by the current L2VPN SP to which it is connecting, while the cloud-identifier setting should be known by both the current L2VPN SP and the customer because it is applied to the public cloud or Internet access.
作为一个使用示例，在NNI案例中使用远程运营商名称设置是因为它所连接的当前L2VPN SP应该知道它，而云标识符设置应该由当前L2VPN SP和客户都知道，因为它应用于公共云或Internet访问。
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 are controlled by a common system administration group and that use a single, clearly defined routing protocol. In some cases, VPNs need to span different ASes in different geographical areas or span different SPs. The connection between ASes is established by the SPs and is seamless to the customer. Examples include:
自治系统（AS）是由公共系统管理组控制的单个网络或网络组，使用单个、明确定义的路由协议。在某些情况下，VPN需要跨越不同地理区域的不同ASE或跨越不同SP。ASes之间的连接由SPs建立，并与客户无缝连接。例子包括：
o A partnership between SPs (e.g., carrier, cloud) to extend their VPN services seamlessly.
o SP（如运营商、云）之间的合作关系，以无缝扩展其VPN服务。
o An internal administrative boundary within a single SP (e.g., backhaul versus core versus data center).
o 单个SP内的内部管理边界（例如，回程与核心与数据中心）。
NNIs have to be defined to extend the VPNs across multiple ASes. [RFC4761] defines multiple flavors of VPN NNI implementations (e.g., VPLSs). Each implementation has pros and cons; this topic is outside the scope of this document. For example, in an inter-AS option A (two ASes), AS 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 label blocks, they associate each interface with a MAC-VRF (VSI) (Section 2) and a BGP session. As a result, traffic between devices in the back-to-back VPLS is Ethernet. In this scenario, the VPNs are isolated from each other, and because the traffic is Ethernet, QoS mechanisms that operate on Ethernet traffic can be applied to achieve customer SLAs.
必须定义NNI以跨多个ASE扩展VPN。[RFC4761]定义了多种类型的VPN NNI实现（例如，VPLSs）。每种实施都有利弊；本主题不在本文档的范围内。例如，在inter-AS选项A（两个AS）中，AS边界路由器（ASBR）对等点通过多个接口连接，其中至少一个接口跨越两个AS，同时存在于同一VPN中。为了使这些ASBR向标签块发送信号，它们将每个接口与MAC-VRF（VSI）（第2节）和BGP会话相关联。因此，背对背VPLS中设备之间的通信量是以太网。在这种情况下，VPN彼此隔离，因为流量是以太网的，所以可以应用在以太网流量上运行的QoS机制来实现客户SLA。
-------- -------------- -----------
/ \ / \ / \
| Cloud | | | | |
| Provider |-----NNI-----| |----NNI---| Data Center |
| #1 | | | | |
\ / | | \ /
-------- | | -----------
| |
-------- | My network | -----------
/ \ | | / \
| Cloud | | | | |
| Provider |-----NNI-----| |---NNI---| L2VPN |
| #2 | | | | Partner |
\ / | | | |
-------- | | | |
\ / | |
-------------- \ /
| -----------
|
NNI
|
|
-------------------
/ \
| |
| |
| |
| L2VPN Partner |
| |
\ /
-------------------
-------- -------------- -----------
/ \ / \ / \
| Cloud | | | | |
| Provider |-----NNI-----| |----NNI---| Data Center |
| #1 | | | | |
\ / | | \ /
-------- | | -----------
| |
-------- | My network | -----------
/ \ | | / \
| Cloud | | | | |
| Provider |-----NNI-----| |---NNI---| L2VPN |
| #2 | | | | Partner |
\ / | | | |
-------- | | | |
\ / | |
-------------- \ /
| -----------
|
NNI
|
|
-------------------
/ \
| |
| |
| |
| L2VPN Partner |
| |
\ /
-------------------
Figure 22: SP Network with Several NNIs
图22：具有多个NNI的SP网络
Figure 22 illustrates an SP network called "My network" that has several NNIs. This network uses NNIs to:
图22显示了一个名为“我的网络”的SP网络，它有几个NNI。该网络使用NNI来：
o increase its footprint by relying on L2VPN partners.
o 通过依赖L2VPN合作伙伴来扩大其业务范围。
o connect its own data-center services to the customer L2VPN.
o 将其自己的数据中心服务连接到客户L2VPN。
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 +++++++++ |
| + +_______________+ + |
| +(MAC-VRF1)--(VPN1)--(MAC-VRF1)+ |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| +(MAC-VRF2)--(VPN2)--(MAC-VRF2)+ |
| + +_______________+ + |
| ++++++++ +++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link +++++++++ |
| + +_______________+ + |
| +(MAC-VRF1)--(VPN1)--(MAC-VRF1)+ |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| +(MAC-VRF2)--(VPN2)--(MAC-VRF2)+ |
| + +_______________+ + |
| ++++++++ +++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
AS A AS B
------------------- -------------------
/ \ / \
| | | |
| ++++++++ Inter-AS link +++++++++ |
| + +_______________+ + |
| +(MAC-VRF1)--(VPN1)--(MAC-VRF1)+ |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| +(MAC-VRF2)--(VPN2)--(MAC-VRF2)+ |
| + +_______________+ + |
| ++++++++ +++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link +++++++++ |
| + +_______________+ + |
| +(MAC-VRF1)--(VPN1)--(MAC-VRF1)+ |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| +(MAC-VRF2)--(VPN2)--(MAC-VRF2)+ |
| + +_______________+ + |
| ++++++++ +++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
Figure 23: NNI Defined with the Option A Flavor: Example 1
图23：使用选项A定义的NNI风味：示例1
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 VPLS model.
在选项A中，两个ASE通过ASBR上的物理链路相互连接。出于弹性目的，ASE之间可能存在多个物理连接。为每个需要跨越AS边界的VPN创建一个VPN连接——物理连接或逻辑连接（位于物理连接之上），从而提供一个背对背的VPLS模型。
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, Figure 23 shows two physical connections that have logical connections per VPN overlaid on them. This could be seen as a multi-VPN scenario. Also, the administrator of AS B will be able to
从服务模型的角度来看，此VPN连接可以看作是一个站点。假设AS B希望在AS A上扩展VPN C的一些VPN连接。AS B的管理员可以使用此服务模型在AS A上订购站点。所有连接场景都可以使用当前模型的功能实现。例如，图23显示了两个物理连接，每个VPN的逻辑连接都覆盖在它们上面。这可以看作是一个多VPN场景。此外，AS B的管理员将能够
choose the appropriate routing protocol (e.g., External BGP (EBGP)) to dynamically exchange routes between ASes.
选择适当的路由协议（例如，外部BGP（EBGP））在ASE之间动态交换路由。
This document assumes that the option A NNI flavor SHOULD reuse the existing VPN site modeling.
本文档假设选项A NNI风格应重用现有VPN站点建模。
Figure 24 illustrates an example where a customer wants its CSP A to attach its virtual network N to an existing L2VPN (VPN1) that it has from L2VPN SP B.
图24显示了一个示例，其中客户希望其CSP a将其虚拟网络N连接到其从L2VPN SP B获得的现有L2VPN（VPN1）。
CSP A L2VPN SP B
----------------- -----------
/ \ / \
| | | | |
| VM --| ++++++++ NNI ++++++++++ |--- VPN1
| | + +____________+ + | Site 1
| |-------+(MAC-VRF1)-(VPN1)-(MAC-VRF1)+ |
| | + + + + |
| | + ASBR + + ASBR + |
| | + +____________+ + |
| | ++++++++ ++++++++++ |
| VM --| | | |--- VPN1
| |Virtual | | | Site 2
| |Network | | |
| VM --| | | |--- VPN1
| | | | | Site 3
\ / \ /
----------------- -----------
|
|
VPN1
Site 4
CSP A L2VPN SP B
----------------- -----------
/ \ / \
| | | | |
| VM --| ++++++++ NNI ++++++++++ |--- VPN1
| | + +____________+ + | Site 1
| |-------+(MAC-VRF1)-(VPN1)-(MAC-VRF1)+ |
| | + + + + |
| | + ASBR + + ASBR + |
| | + +____________+ + |
| | ++++++++ ++++++++++ |
| VM --| | | |--- VPN1
| |Virtual | | | Site 2
| |Network | | |
| VM --| | | |--- VPN1
| | | | | Site 3
\ / \ /
----------------- -----------
|
|
VPN1
Site 4
VM = Virtual Machine
VM = Virtual Machine
Figure 24: NNI Defined with the Option A Flavor: Example 2
图24：使用选项A定义的NNI风味：示例2
To create the VPN connectivity, the CSP or the customer may use the L2SM 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 Figure 24). 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 below illustrates a possible configuration request to SP B:
要创建VPN连接，CSP或客户可以使用SP B公开的L2SM。我们可以认为，当NNI被共享时，CSP A和SP B之间的物理连接（承载）已经存在。CSP A可以通过服务模型请求创建一个具有单站点网络访问的新站点（图24中使用了单归宿）。作为放置约束，CSP a可以使用它从SP a获得的现有承载引用来强制在现有链路上放置VPN NNI。下面的XML说明了可能向SP B发出的配置请求：
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-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>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>CSP_A_attachment</site-id>
<locations>
<location>
<location-id>NY1</location-id>
<city>NY</city>
<country-code>US</country-code>
</location>
</locations>
<site-vpn-flavor>site-vpn-flavor-nni</site-vpn-flavor>
<site-network-accesses>
<site-network-access>
<network-access-id>CSP_A_VN1</network-access-id>
<connection>
<encapsulation-type>vlan</encapsulation-type>
<eth-inf-type>tagged</eth-inf-type>
<tagged-interface>
<tagged-inf-type>dot1q</tagged-inf-type>
<dot1q-vlan-tagged>
<cvlan-id>17</cvlan-id>
</dot1q-vlan-tagged>
</tagged-interface>
</connection>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-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>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>CSP_A_attachment</site-id>
<locations>
<location>
<location-id>NY1</location-id>
<city>NY</city>
<country-code>US</country-code>
</location>
</locations>
<site-vpn-flavor>site-vpn-flavor-nni</site-vpn-flavor>
<site-network-accesses>
<site-network-access>
<network-access-id>CSP_A_VN1</network-access-id>
<connection>
<encapsulation-type>vlan</encapsulation-type>
<eth-inf-type>tagged</eth-inf-type>
<tagged-interface>
<tagged-inf-type>dot1q</tagged-inf-type>
<dot1q-vlan-tagged>
<cvlan-id>17</cvlan-id>
</dot1q-vlan-tagged>
</tagged-interface>
</connection>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
<carrierscarrier>
<signaling-type>bgp</signaling-type>
</carrierscarrier>
</service>
<vpn-attachment>
<vpn-id>12456487</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
<management>
<type>customer-managed</type>
</management>
</site>
</sites>
</l2vpn-svc>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
<carrierscarrier>
<signaling-type>bgp</signaling-type>
</carrierscarrier>
</service>
<vpn-attachment>
<vpn-id>12456487</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
<management>
<type>customer-managed</type>
</management>
</site>
</sites>
</l2vpn-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.
上面描述的情况与使用云访问容器的场景不同，因为云访问提供公共云访问，而此示例允许访问位于CSP网络中的私有资源。
AS A AS B
------------------- -------------------
/ \ / \
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR +<---MP-BGP---->+ ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR +<---MP-BGP---->+ ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
AS A AS B
------------------- -------------------
/ \ / \
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR +<---MP-BGP---->+ ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR +<---MP-BGP---->+ ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
Figure 25: NNI Defined with the Option B Flavor: Example 1
图25：使用选项B定义的NNI风味：示例1
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 [RFC4761].
在选项B中，两个ASE通过ASBR上的物理链路相互连接。出于弹性目的，ASE之间可能存在多个物理连接。ASE之间的VPN“连接”通过MP-BGP[RFC4761]交换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用于同意仅为特定RTs交换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用于同意仅为特定RTs交换VPN路由的提供商之间。每个提供者都有自己的RT方案。因此，跨越两个网络的客户将在每个网络中为特定VPN设置不同的RTs。
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筛选策略。从服务建模的角度来看，有必要商定要授权的RTs列表。
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中，两个ASE都需要就要交换的VPN RT以及如何将VPN RT从as a映射到as B中的相应RT（反之亦然）达成一致。
Those modelings are currently out of scope for this document.
这些建模目前不在本文档的范围内。
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
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
VM = Virtual Machine
VM = Virtual Machine
Figure 26: NNI Defined with the Option B Flavor: Example 2
图26：使用选项B定义的NNI：示例2
Figure 26 shows an NNI connection between CSP A and SP network B. The SPs do not trust each other and use different RT allocation policies. 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's virtual network in CSP A to the customer's L2VPN (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.
图26显示了CSP A和SP网络B之间的NNI连接。SP彼此不信任，使用不同的RT分配策略。因此，就实现而言，客户VPN在每个网络中具有不同的RT（CSP a中的RT a和SP网络B中的RT B）。为了将CSP A中的客户虚拟网络连接到SP网络B中的客户L2VPN（VPN1），CSP A应请求SP网络B在NNI上打开客户VPN（接受适当的RT）。谁进行RT翻译取决于两个SP之间的协议：SP B可能允许CSP A请求VPN（RT）翻译。
AS A AS B
------------------- -------------------
/ \ / \
| | | |
| | | |
| | | |
| ++++++++ Multihop EBGP ++++++++ |
| + + + + |
| + + + + |
| + RGW +<----MP-BGP---->+ RGW + |
| + + + + |
| + + + + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
AS A AS B
------------------- -------------------
/ \ / \
| | | |
| | | |
| | | |
| ++++++++ Multihop EBGP ++++++++ |
| + + + + |
| + + + + |
| + RGW +<----MP-BGP---->+ RGW + |
| + + + + |
| + + + + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
Figure 27: NNI Defined with the Option C Flavor
图27：使用选项C定义的NNI
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. From a VPN service's point of view, modeling options B and C will be configured identically.
从VPN服务的角度来看，选项C NNI与选项B非常相似，因为MP-BGP会话用于在ASE之间交换VPN路由。区别在于转发平面和控制平面位于不同的节点上，因此MP-BGP会话是路由网关（RGW）节点之间的多跳会话。从VPN服务的角度来看，建模选项B和C的配置相同。
5.17. Applicability of L2SM in Inter-provider and Inter-domain Orchestration
5.17. L2SM在跨提供商和跨域编排中的适用性
In the case where the ASes belong to different providers, one might imagine that providers would like to have fewer signaling sessions crossing the AS boundary and that the entities that terminate the sessions could be restricted to a smaller set of devices. Two approaches can be taken:
在ase属于不同提供商的情况下，可以想象提供商希望具有较少的跨越AS边界的信令会话，并且终止会话的实体可以被限制为较小的设备集。可以采取两种方法：
a. Construct inter-provider control connections to run only between the two border routers.
a. 构造提供者间控制连接以仅在两个边界路由器之间运行。
b. Allow end-to-end, multi-segment connectivity to be constructed out of several connectivity segments, without maintaining an end-to-end control connection.
b. 允许使用多个连接段构建端到端、多段连接，而无需维护端到端控制连接。
Inter-provider control connections as described in approach (a) can be realized using the techniques provided in Section 5.16 (e.g., defining NNIs). Multi-segment connectivity as described in approach (b) can produce an inter-AS solution that more closely resembles scheme (b) in Section 10 of [RFC4364]. It may be realized using "stitching" of per-site connectivity and service segments at different domains, e.g., end-to-end connectivity between Site 1 and Site 3 spans multiple domains (e.g., metropolitan area networks) and can be constructed by stitching network access connectivity within Site 1 with SEG1, SEG3, and SEG4, and network access connectivity within Site 3 (as shown in Figure 28). The assumption is that the service orchestration component in Figure 3 should have visibility into the complete abstract topology and resource availability. This may rely on network planning.
方法（a）中所述的供应商间控制连接可以使用第5.16节中提供的技术实现（例如，定义NNI）。方法（b）中所述的多段连接可产生更类似于[RFC4364]第10节中方案（b）的as间解决方案。它可以使用不同域的每个站点连接和服务段的“缝合”来实现，例如，站点1和站点3之间的端到端连接跨越多个域（例如，城域网），并且可以通过将站点1内的网络接入连接与SEG1、SEG3和SEG4缝合来构建，以及站点3内的网络访问连接（如图28所示）。假设图3中的服务编排组件应该能够看到完整的抽象拓扑和资源可用性。这可能取决于网络规划。
---------- ---------- ----------
| | | | | |
+--+ +---+ +---+ +--+
Site 1|PE|==SEG1==| |==SEG3==| |==SEG4==|PE|Site 3
+--+ +---+ | | +--+
| | | | | | ----------
| | | | | | | |
+--+ +---+ | | +---+ +--+
Site 2|PE|==SEG2==| |==SEG5==| |==SEG6==| |==SEG7==|PE|Site 4
+--+ +---+ +---+ +---+ +--+
| | | | | | | |
---------- ---------- ---------- ----------
---------- ---------- ----------
| | | | | |
+--+ +---+ +---+ +--+
Site 1|PE|==SEG1==| |==SEG3==| |==SEG4==|PE|Site 3
+--+ +---+ | | +--+
| | | | | | ----------
| | | | | | | |
+--+ +---+ | | +---+ +--+
Site 2|PE|==SEG2==| |==SEG5==| |==SEG6==| |==SEG7==|PE|Site 4
+--+ +---+ +---+ +---+ +--+
| | | | | | | |
---------- ---------- ---------- ----------
Figure 28: Example: Inter-provider and Inter-domain Orchestration
图28：示例：跨提供者和跨域编排
Note that SEG1, SEG2, SEG3, SEG4, SEG5, and SEG6 can also be regarded as network access connectivity within a site and can be created as a normal site using the L2SM.
请注意，SEG1、SEG2、SEG3、SEG4、SEG5和SEG6也可以视为站点内的网络访问连接，并且可以使用L2SM创建为正常站点。
In Figure 28, we use BGP redistribution of L2VPN Network Layer Reachability Information (NLRI) instances from AS to neighboring AS. First, the PE routers use BGP to redistribute L2VPN NLRIs to either an ASBR or a route reflector of which an ASBR is a client. The ASBR then uses BGP to redistribute those L2VPN NLRIs to an ASBR in another AS, which in turn distributes them to the PE routers in that AS, or perhaps to another ASBR that in turn distributes them, and so on.
在图28中，我们使用了L2VPN网络层可达性信息（NLRI）实例从AS到相邻AS的BGP再分配。首先，PE路由器使用BGP将L2VPN NLRIs重新分配给ASBR或ASBR作为客户端的路由反射器。ASBR然后使用BGP将这些L2VPN NLRI重新分配给另一个AS中的ASBR，后者将其分配给该AS中的PE路由器，或者可能分配给另一个ASBR，后者将其依次分配，依此类推。
In this case, a PE can learn the address of an ASBR through which it could reach another PE to which it wishes to establish connectivity. That is, a local PE will receive a BGP advertisement containing an L2VPN NLRI corresponding to an L2VPN instance in which the local PE has some attached members. The BGP next hop for that L2VPN NLRI will be an ASBR of the local AS. Then, rather than building a control connection all the way to the remote PE, it builds one only to the ASBR. A connectivity segment can now be established from the PE to the ASBR. The ASBR in turn can establish connectivity to the ASBR of the next AS and then stitch that connectivity to the connectivity from the PE as described in [RFC6073]. Repeating the process at each ASBR leads to a sequence of connectivity segments that, when stitched together, connect the two PEs.
在这种情况下，PE可以了解ASBR的地址，通过该地址，它可以到达希望建立连接的另一个PE。也就是说，本地PE将接收包含L2VPN NLRI的BGP播发，该L2VPN NLRI对应于本地PE具有一些附加成员的L2VPN实例。该L2VPN NLRI的BGP下一跳将是本地AS的ASBR。然后，它不再构建到远程PE的控制连接，而是只构建到ASBR的控制连接。现在可以建立从PE到ASBR的连接段。ASBR可以依次建立到下一个AS的ASBR的连接，然后按照[RFC6073]中所述将该连接缝合到PE的连接。在每个ASBR上重复该过程会产生一系列连接段，当连接在一起时，连接两个PE。
Note that in the approach just described, the local PE may never learn the IP address of the remote PE. It learns the L2VPN NLRI advertised by the remote PE, which need not contain the remote PE address, and it learns the IP address of the ASBR that is the BGP next hop for that NLRI.
注意，在刚才描述的方法中，本地PE可能永远不会了解远程PE的IP地址。它学习远程PE播发的L2VPN NLRI，该NLRI不需要包含远程PE地址，并学习ASBR的IP地址，该ASBR是该NLRI的BGP下一跳。
When this approach is used for VPLS or for full-mesh VPWS, it leads to a full mesh of connectivity among the PEs, but it does not require a full mesh of control connections (LDP or L2TPv3 sessions). Instead, the control connections within a single AS run among all the PEs of that AS and the ASBRs of the AS. A single control connection between the ASBRs of adjacent ASes can be used to support as many AS-to-AS connectivity segments as may be needed.
当此方法用于VPL或全网格VPW时，它会导致PEs之间的连接达到全网格，但不需要控制连接的全网格（LDP或L2TPv3会话）。相反，单个AS中的控制连接在该AS的所有PE和AS的ASBR之间运行。相邻ASE的ASBR之间的单个控制连接可用于支持所需的任意多个连接段。
As explained in Section 4, this service model is not intended to configure network elements; rather, it is instantiated in a management system.
如第4节所述，此服务模型不用于配置网络元件；相反，它是在管理系统中实例化的。
The management system might follow modular design and comprise two different components:
管理系统可能遵循模块化设计，包括两个不同的组件：
a. The component instantiating the service model (let's call it the service component).
a. 实例化服务模型的组件（我们称之为服务组件）。
b. The component responsible for network element configuration (let's call it the configuration component).
b. 负责网元配置的组件（我们称之为配置组件）。
In some cases, when a split is needed between the behavior and functions that a customer requests and the technology that the network operator has available to deliver the service [RFC8309], a new component can be separated out of the service component (let's call it the control component). This component is responsible for network-centric operation and is aware of many features such as topology, technology, and operator policy. As an optional component, it can use the service model as input and is not required at all if the control component delegates its control operations to the configuration component.
在某些情况下，当需要在客户请求的行为和功能与网络运营商提供服务的可用技术之间进行分离[RFC8309]时，可以从服务组件中分离出一个新组件（我们称之为控制组件）。此组件负责以网络为中心的操作，并了解许多功能，如拓扑、技术和运营商策略。作为可选组件，它可以使用服务模型作为输入，如果控制组件将其控制操作委托给配置组件，则根本不需要它。
In Section 7, we provide an example of translation of service provisioning requests to router configuration lines as an illustration. In the YANG-based ecosystem, it is expected that NETCONF and YANG will be used between the configuration component and network elements to configure the requested service on those elements.
在第7节中，我们提供了一个将服务提供请求转换为路由器配置行的示例作为说明。在基于YANG的生态系统中，预计将在配置组件和网元之间使用NETCONF和YANG来配置这些元素上请求的服务。
In this framework, it is expected that YANG data models will be used to configure 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 such
在此框架中，预期将使用数据模型在网络元素上配置服务组件。此服务模型提供的抽象视图与特定配置模型为网络元素（如网络）提供的详细配置视图之间存在着密切的关系
as those defined in [MPLS-L2VPN-YANG] and [EVPN-YANG]. Service components that would need configuration of network elements in support of the service model defined in this document include:
如[MPLS-L2VPN-YANG]和[EVPN-YANG]中所定义。需要配置网络元素以支持本文档中定义的服务模型的服务组件包括：
o Network instance definitions that include defined VPN policies.
o 包含已定义VPN策略的网络实例定义。
o Physical interfaces.
o 物理接口。
o Ethernet-layer parameters (e.g., VLAN IDs).
o 以太网层参数（例如，VLAN ID）。
o QoS: classification, profiles, etc.
o QoS：分类、配置文件等。
o Support for Ethernet Service OAM.
o 支持以太网服务OAM。
As explained in Section 4, 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.
如第4节所述，此服务模型旨在在管理层实例化，而不是直接用于网络元素。管理系统是整个服务配置的中心点。
This section provides an example of how a management system can use this model to configure an L2VPN service on network elements.
本节提供了管理系统如何使用此模型在网元上配置L2VPN服务的示例。
This example provides a VPN service for three sites using point-to-point VPWS and a Hub-and-Spoke VPN service topology as shown in Figure 29. Load balancing is not considered in this case.
此示例为三个站点提供了一个VPN服务，使用点到点VPWS和一个集线器和辐射式VPN服务拓扑，如图29所示。在这种情况下，不考虑负载平衡。
Site 1
............
: : P2P VPWS
:Spoke Site:-----PE1--------------------------+
: : | Site 3
:..........: | ............
| : :
PE3-----: Hub Site :
Site 2 | : :
............ | :..........:
: : P2P VPWS |
:Spoke Site:-----PE2--------------------------+
: :
:..........:
Site 1
............
: : P2P VPWS
:Spoke Site:-----PE1--------------------------+
: : | Site 3
:..........: | ............
| : :
PE3-----: Hub Site :
Site 2 | : :
............ | :..........:
: : P2P VPWS |
:Spoke Site:-----PE2--------------------------+
: :
:..........:
Figure 29: Reference Network for Simple Example
图29：简单示例的参考网络
The following XML describes the overall simplified service configuration of this VPN.
以下XML描述了此VPN的整体简化服务配置。
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>12456487</vpn-id>
<vpn-svc-type>vpws</vpn-svc-type>
<svc-topo>hub-spoke</svc-topo>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
<vpn-service>
<vpn-id>12456488</vpn-id>
<vpn-svc-type>vpws</vpn-svc-type>
<svc-topo>hub-spoke</svc-topo>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
</l2vpn-svc>
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>12456487</vpn-id>
<vpn-svc-type>vpws</vpn-svc-type>
<svc-topo>hub-spoke</svc-topo>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
<vpn-service>
<vpn-id>12456488</vpn-id>
<vpn-svc-type>vpws</vpn-svc-type>
<svc-topo>hub-spoke</svc-topo>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
</l2vpn-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 Hubs and 100:2 for Spokes). The output below describes the configuration of Spoke Site 1.
当收到提供VPN服务的请求时，管理系统将在内部（或通过与另一个OSS组件通信）分配VPN RTs。在这种特定情况下，将分配两个RTs（集线器为100:1，辐条为100:2）。下面的输出描述了分支站点1的配置。
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>12456487</vpn-id>
<svc-topo>hub-spoke</svc-topo>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>Spoke_Site1</site-id>
<locations>
<location>
<location-id>NY1</location-id>
<city>NY</city>
<country-code>US</country-code>
</location>
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>12456487</vpn-id>
<svc-topo>hub-spoke</svc-topo>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>Spoke_Site1</site-id>
<locations>
<location>
<location-id>NY1</location-id>
<city>NY</city>
<country-code>US</country-code>
</location>
</locations>
<site-network-accesses>
<site-network-access>
<network-access-id>Spoke_UNI-Site1</network-access-id>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
</access-diversity>
<connection>
<encapsulation-type>vlan</encapsulation-type>
<tagged-interface>
<dot1q-vlan-tagged>
<cvlan-id>17</cvlan-id>
</dot1q-vlan-tagged>
</tagged-interface>
<l2cp-control>
<stp-rstp-mstp>tunnel</stp-rstp-mstp>
<lldp>true</lldp>
</l2cp-control>
</connection>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
<carrierscarrier>
<signaling-type>bgp</signaling-type>
</carrierscarrier>
</service>
<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>
</locations>
<site-network-accesses>
<site-network-access>
<network-access-id>Spoke_UNI-Site1</network-access-id>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
</access-diversity>
<connection>
<encapsulation-type>vlan</encapsulation-type>
<tagged-interface>
<dot1q-vlan-tagged>
<cvlan-id>17</cvlan-id>
</dot1q-vlan-tagged>
</tagged-interface>
<l2cp-control>
<stp-rstp-mstp>tunnel</stp-rstp-mstp>
<lldp>true</lldp>
</l2cp-control>
</connection>
<service>
<svc-bandwidth>
<bandwidth>
<direction>input-bw</direction>
<type>bw-per-cos</type>
<cir>450000000</cir>
<cbs>20000000</cbs>
<eir>1000000000</eir>
<ebs>200000000</ebs>
</bandwidth>
</svc-bandwidth>
<carrierscarrier>
<signaling-type>bgp</signaling-type>
</carrierscarrier>
</service>
<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>
</l2vpn-svc>
</sites>
</l2vpn-svc>
When receiving the request for provisioning Spoke Site 1, the management system MUST allocate network resources for this site. It MUST first determine the target network elements to provision the access and, in particular, the PE router (or possibly an aggregation switch). As described in Sections 5.3.1 and 5.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 Site 1 requires PE diversity with Hubs and that the management system will allocate PEs based on least distance. Based on the location information, the management system finds the available PEs in the area closest to the customer and picks one that fits the access-diversity constraint.
当接收到站点1的配置请求时，管理系统必须为此站点分配网络资源。它必须首先确定提供访问的目标网络元素，特别是PE路由器（或可能的聚合交换机）。如第5.3.1节和第5.6节所述，管理系统应使用位置信息，并且必须使用访问分集约束来找到适当的PE。在这种情况下，我们认为辐条站点1需要Hubs的PE多样性，并且管理系统将基于最小距离来分配PES。根据位置信息，管理系统在离客户最近的区域找到可用的PE，并选择一个符合访问多样性约束的PE。
When the PE is chosen, the management system needs to allocate interface resources on the node. One interface is selected from the PE's available pool of resources. The management system can start provisioning the PE node using any means it wishes (e.g., NETCONF, CLI). The management system will check to see if a VSI that fits its needs is already present. If not, it will provision the VSI: the RD will come from the internal allocation policy model, and the RTs will come from the vpn-policy configuration of the site (i.e., the management system will allocate 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的可用资源池中选择一个接口。管理系统可以使用其希望的任何方式（例如NETCONF、CLI）开始配置PE节点。管理系统将检查是否已经存在符合其需求的VSI。如果没有，它将提供VSI：RD将来自内部分配策略模型，RTs将来自站点的vpn策略配置（即，管理系统将为vpn分配一些RTs）。由于站点是辐射站点（站点角色），管理系统知道必须导入和导出哪些RTs。由于站点由提供商管理，因此还可以添加一些管理RTs（100:5000）。配置中还可以添加标准提供商VPN策略。
Example of a generated PE configuration:
生成的PE配置示例：
l2vpn vsi context one
vpn id 12456487
autodiscovery bgp signaling bgp
ve id 1001 <---- identify the PE routers within the VPLS domain
ve range 50 <---- VPLS Edge (VE) size
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
!
l2vpn vsi context one
vpn id 12456487
autodiscovery bgp signaling bgp
ve id 1001 <---- identify the PE routers within the VPLS domain
ve range 50 <---- VPLS Edge (VE) size
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 VSI has been provisioned, the management system can start configuring the access on the PE using the allocated interface information. The tag or VLAN (e.g., service instance tag) is chosen by the management system. One tag will be picked from an allocated subnet for the PE, and another will be used for the CE configuration.
配置VSI后，管理系统可以开始使用分配的接口信息在PE上配置访问。标签或VLAN（例如，服务实例标签）由管理系统选择。一个标签将从分配给PE的子网中选取，另一个标签将用于CE配置。
LACP protocols will also be configured between the PE and the CE; in the case of the provider-managed model, the choice is left to the SP. This choice is independent of the LACP protocol chosen by the customer.
还将在PE和CE之间配置LACP协议；对于提供商管理的模型，选择权留给SP。此选择独立于客户选择的LACP协议。
Example of a generated PE configuration:
生成的PE配置示例：
! bridge-domain 1 member Ethernet0/0 service-instance 100 member vsi one ! l2 router-id 198.51.100.1 ! l2 router-id 2001:db8::10:1/64 !
! 网桥域1成员Ethernet0/0服务实例100成员vsi one！l2路由器id 198.51.100.1！l2路由器id 2001:db8:：10:1/64！
interface Ethernet0/0 no ip address service instance 100 ethernet encapsulation dot1q 100 !
接口Ethernet0/0无ip地址服务实例100以太网封装dot1q 100！
! router bgp 1 bgp log-neighbor-changes neighbor 198.51.100.4 remote-as 1 neighbor 198.51.100.4 update-source Loopback0 ! address-family l2vpn vpls neighbor 198.51.100.4 activate neighbor 198.51.100.4 send-community extended neighbor 198.51.100.4 suppress-signaling-protocol ldp neighbor 2001:db8::0a10:4 activate neighbor 2001:db8::0a10:4 send-community extended exit-address-family
! 路由器bgp 1 bgp日志邻居将邻居198.51.100.4远程更改为1邻居198.51.100.4更新源环回0！地址族l2vpn vpls邻居198.51.100.4激活邻居198.51.100.4发送社区扩展邻居198.51.100.4抑制信令协议ldp邻居2001:db8:：0a10:4激活邻居2001:db8:：0a10:4发送社区扩展出口地址族
!
interface vlan 100 <---- Associating the AC with
no ip address the MAC-VRF at the PE
xconnect vsi PE1-VPLS-A
!
vlan 100
state active
!
interface vlan 100 <---- Associating the AC with
no ip address the MAC-VRF at the PE
xconnect vsi PE1-VPLS-A
!
vlan 100
state active
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 (e.g., before sending the CE to the customer premises at the appropriate postal address, as described in Section 5.3.1). The CE configuration will be built in the same way as the PE configuration is built. Based on (1) the CE type (vendor/model) allocated to the customer and (2) 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's OSS, as both resources are managed internally. CE-to-LAN interface parameters, such as dot1Q tags, are derived from the Ethernet connection, taking into account how the management system distributes dot1Q tags between the PE and the CE within the subnet. This will allow a plug'n'play configuration to be produced for the CE.
由于在此阶段无法访问CE路由器，管理系统可以生成一个完整的CE配置，该配置可以手动上传到节点（例如，在将CE发送到适当邮政地址的客户场所之前，如第5.3.1节所述）。CE配置的构建方式与PE配置的构建方式相同。根据（1）分配给客户的CE类型（供应商/型号）和（2）承载信息，管理系统知道必须在CE上配置哪个接口。PE-CE链路配置预计将使用SP的OSS自动处理，因为这两种资源都是内部管理的。CE到LAN接口参数（如dot1Q标记）源自以太网连接，考虑到管理系统如何在子网内的PE和CE之间分配dot1Q标记。这将允许为CE生成即插即用配置。
Example of a generated CE configuration:
生成的CE配置示例：
interface Ethernet0/1 switchport trunk allowed vlan none switchport mode trunk service instance 100 ethernet encapsulation default l2protocol forward cdp xconnect 203.0.113.1 100 encapsulation mpls !
接口以太网0/1交换机端口中继允许vlan无交换机端口模式中继服务实例100以太网封装默认l2protocol转发cdp xconnect 203.0.113.1 100封装mpls！
This YANG module imports typedefs from [RFC6991] and [RFC8341].
此模块从[RFC6991]和[RFC8341]导入typedefs。
<CODE BEGINS> file "ietf-l2vpn-svc@2018-10-09.yang"
module ietf-l2vpn-svc {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc";
prefix l2vpn-svc;
<CODE BEGINS> file "ietf-l2vpn-svc@2018-10-09.yang"
module ietf-l2vpn-svc {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc";
prefix l2vpn-svc;
import ietf-inet-types {
prefix inet;
}
import ietf-yang-types {
prefix yang;
}
import ietf-netconf-acm {
prefix nacm;
}
import ietf-inet-types {
prefix inet;
}
import ietf-yang-types {
prefix yang;
}
import ietf-netconf-acm {
prefix nacm;
}
organization
"IETF L2SM Working Group.";
contact
"WG Web: <https://datatracker.ietf.org/wg/l2sm/>
WG List: <mailto:l2sm@ietf.org>
Editor: Giuseppe Fioccola
<mailto:giuseppe.fioccola@tim.it>";
description
"This YANG module defines a generic service configuration model
for Layer 2 VPN services common across all vendor
implementations.
organization
"IETF L2SM Working Group.";
contact
"WG Web: <https://datatracker.ietf.org/wg/l2sm/>
WG List: <mailto:l2sm@ietf.org>
Editor: Giuseppe Fioccola
<mailto:giuseppe.fioccola@tim.it>";
description
"This YANG module defines a generic service configuration model
for Layer 2 VPN services common across all vendor
implementations.
Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权所有（c）2018 IETF信托基金和被确定为代码作者的人员。版权所有。
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节规定的简化BSD许可证中包含的许可条款，允许以源代码和二进制格式重新分发和使用，无论是否修改(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8466;
see the RFC itself for full legal notices.";
This version of this YANG module is part of RFC 8466;
see the RFC itself for full legal notices.";
revision 2018-10-09 {
description
"Initial revision.";
reference
"RFC 8466: A YANG Data Model for Layer 2 Virtual Private
Network (L2VPN) Service Delivery";
}
revision 2018-10-09 {
description
"Initial revision.";
reference
"RFC 8466: A YANG Data Model for Layer 2 Virtual Private
Network (L2VPN) Service Delivery";
}
feature carrierscarrier {
description
"Enables the support of carriers' carriers (CsC).";
}
feature carrierscarrier {
description
"Enables the support of carriers' carriers (CsC).";
}
feature ethernet-oam {
description
"Enables the support of Ethernet Service OAM.";
}
feature ethernet-oam {
description
"Enables the support of Ethernet Service OAM.";
}
feature extranet-vpn {
description
"Enables the support of extranet VPNs.";
}
feature extranet-vpn {
description
"Enables the support of extranet VPNs.";
}
feature l2cp-control {
description
"Enables the support of L2CP control.";
}
feature l2cp-control {
description
"Enables the support of L2CP control.";
}
feature input-bw {
description
"Enables the support of input bandwidth in a VPN.";
}
feature input-bw {
description
"Enables the support of input bandwidth in a VPN.";
}
feature output-bw {
description
"Enables the support of output bandwidth in a VPN.";
}
feature output-bw {
description
"Enables the support of output bandwidth in a VPN.";
}
feature uni-list {
description
"Enables the support of a list of UNIs in a VPN.";
}
feature uni-list {
description
"Enables the support of a list of UNIs in a VPN.";
}
feature cloud-access {
description
"Allows the VPN to connect to a Cloud Service Provider (CSP)
or an ISP.";
}
feature cloud-access {
description
"Allows the VPN to connect to a Cloud Service Provider (CSP)
or an ISP.";
}
feature oam-3ah {
description
"Enables the support of OAM 802.3ah.";
}
feature oam-3ah {
description
"Enables the support of OAM 802.3ah.";
}
feature micro-bfd {
description
"Enables the support of micro-BFD.";
}
feature micro-bfd {
description
"Enables the support of micro-BFD.";
}
feature bfd {
description
"Enables the support of BFD.";
}
feature bfd {
description
"Enables the support of BFD.";
}
feature signaling-options {
description
"Enables the support of signaling options.";
}
feature signaling-options {
description
"Enables the support of signaling options.";
}
feature site-diversity { description
功能站点多样性{描述
"Enables the support of site diversity constraints in a VPN.";
}
"Enables the support of site diversity constraints in a VPN.";
}
feature encryption {
description
"Enables the support of encryption.";
}
feature encryption {
description
"Enables the support of encryption.";
}
feature always-on {
description
"Enables support for the 'always-on' access constraint.";
}
feature always-on {
description
"Enables support for the 'always-on' access constraint.";
}
feature requested-type {
description
"Enables support for the 'requested-type' access constraint.";
}
feature requested-type {
description
"Enables support for the 'requested-type' access constraint.";
}
feature bearer-reference {
description
"Enables support for the 'bearer-reference' access
constraint.";
}
feature bearer-reference {
description
"Enables support for the 'bearer-reference' access
constraint.";
}
feature qos {
description
"Enables support for QoS.";
}
feature qos {
description
"Enables support for QoS.";
}
feature qos-custom {
description
"Enables the support of a custom QoS profile.";
}
feature qos-custom {
description
"Enables the support of a custom QoS profile.";
}
feature lag-interface {
description
"Enables LAG interfaces.";
}
feature lag-interface {
description
"Enables LAG interfaces.";
}
feature vlan {
description
"Enables the support of VLANs.";
}
feature vlan {
description
"Enables the support of VLANs.";
}
feature dot1q {
description
"Enables the support of dot1Q.";
}
feature dot1q {
description
"Enables the support of dot1Q.";
}
feature qinq {
description
"Enables the support of QinQ.";
}
feature qinq {
description
"Enables the support of QinQ.";
}
feature qinany {
description
"Enables the support of QinAny.";
}
feature qinany {
description
"Enables the support of QinAny.";
}
feature vxlan {
description
"Enables the support of VXLANs.";
}
feature vxlan {
description
"Enables the support of VXLANs.";
}
feature lan-tag {
description
"Enables LAN tag support in a VPN.";
}
feature lan-tag {
description
"Enables LAN tag support in a VPN.";
}
feature target-sites {
description
"Enables the support of the 'target-sites'
match-flow parameter.";
}
feature target-sites {
description
"Enables the support of the 'target-sites'
match-flow parameter.";
}
feature bum {
description
"Enables BUM capabilities in a VPN.";
}
feature bum {
description
"Enables BUM capabilities in a VPN.";
}
feature mac-loop-prevention {
description
"Enables the MAC loop-prevention capability in a VPN.";
}
feature mac-loop-prevention {
description
"Enables the MAC loop-prevention capability in a VPN.";
}
feature lacp {
description
"Enables the Link Aggregation Control Protocol (LACP)
capability in a VPN.";
}
feature lacp {
description
"Enables the Link Aggregation Control Protocol (LACP)
capability in a VPN.";
}
feature mac-addr-limit {
description
"Enables the MAC address limit capability in a VPN.";
}
feature mac-addr-limit {
description
"Enables the MAC address limit capability in a VPN.";
}
feature acl {
特征acl{
description
"Enables the ACL capability in a VPN.";
}
description
"Enables the ACL capability in a VPN.";
}
feature cfm {
description
"Enables the 802.1ag CFM capability in a VPN.";
}
feature cfm {
description
"Enables the 802.1ag CFM capability in a VPN.";
}
feature y-1731 {
description
"Enables the Y.1731 capability in a VPN.";
}
feature y-1731 {
description
"Enables the Y.1731 capability in a VPN.";
}
typedef svc-id {
type string;
description
"Defines the type of service component identifier.";
}
typedef svc-id {
type string;
description
"Defines the type of service component identifier.";
}
typedef ccm-priority-type {
type uint8 {
range "0..7";
}
description
"A 3-bit priority value to be used in the VLAN tag,
if present in the transmitted frame.";
}
typedef ccm-priority-type {
type uint8 {
range "0..7";
}
description
"A 3-bit priority value to be used in the VLAN tag,
if present in the transmitted frame.";
}
typedef control-mode {
type enumeration {
enum peer {
description
"'peer' mode, i.e., participate in the protocol towards
the CE. Peering is common for LACP and the Ethernet
Local Management Interface (E-LMI) and, occasionally,
for LLDP. For VPLSs and VPWSs, the subscriber can also
request that the SP peer enable spanning tree.";
}
enum tunnel {
description
"'tunnel' mode, i.e., pass to the egress or destination
site. For EPLs, the expectation is that L2CP frames are
tunneled.";
}
enum discard {
description
"'discard' mode, i.e., discard the frame.";
typedef control-mode {
type enumeration {
enum peer {
description
"'peer' mode, i.e., participate in the protocol towards
the CE. Peering is common for LACP and the Ethernet
Local Management Interface (E-LMI) and, occasionally,
for LLDP. For VPLSs and VPWSs, the subscriber can also
request that the SP peer enable spanning tree.";
}
enum tunnel {
description
"'tunnel' mode, i.e., pass to the egress or destination
site. For EPLs, the expectation is that L2CP frames are
tunneled.";
}
enum discard {
description
"'discard' mode, i.e., discard the frame.";
}
}
description
"Defines the type of control mode on L2CP protocols.";
}
}
}
description
"Defines the type of control mode on L2CP protocols.";
}
typedef neg-mode {
type enumeration {
enum full-duplex {
description
"Defines full-duplex mode.";
}
enum auto-neg {
description
"Defines auto-negotiation mode.";
}
}
description
"Defines the type of negotiation mode.";
}
typedef neg-mode {
type enumeration {
enum full-duplex {
description
"Defines full-duplex mode.";
}
enum auto-neg {
description
"Defines auto-negotiation mode.";
}
}
description
"Defines the type of negotiation mode.";
}
identity site-network-access-type {
description
"Base identity for the site-network-access type.";
}
identity site-network-access-type {
description
"Base identity for the site-network-access type.";
}
identity point-to-point {
base site-network-access-type;
description
"Identity for a point-to-point connection.";
}
identity point-to-point {
base site-network-access-type;
description
"Identity for a point-to-point connection.";
}
identity multipoint {
base site-network-access-type;
description
"Identity for a multipoint connection, e.g.,
an Ethernet broadcast segment.";
}
identity multipoint {
base site-network-access-type;
description
"Identity for a multipoint connection, e.g.,
an Ethernet broadcast segment.";
}
identity tag-type {
description
"Base identity from which all tag types are derived.";
}
identity tag-type {
description
"Base identity from which all tag types are derived.";
}
identity c-vlan {
base tag-type;
description
"A CVLAN tag, normally using the 0x8100 Ethertype.";
identity c-vlan {
base tag-type;
description
"A CVLAN tag, normally using the 0x8100 Ethertype.";
}
}
identity s-vlan {
base tag-type;
description
"An SVLAN tag.";
}
identity s-vlan {
base tag-type;
description
"An SVLAN tag.";
}
identity c-s-vlan {
base tag-type;
description
"Using both a CVLAN tag and an SVLAN tag.";
}
identity c-s-vlan {
base tag-type;
description
"Using both a CVLAN tag and an SVLAN tag.";
}
identity multicast-tree-type {
description
"Base identity for the multicast tree type.";
}
identity multicast-tree-type {
description
"Base identity for the multicast tree type.";
}
identity ssm-tree-type {
base multicast-tree-type;
description
"Identity for the Source-Specific Multicast (SSM) tree type.";
reference "RFC 8299: YANG Data Model for L3VPN Service Delivery";
}
identity ssm-tree-type {
base multicast-tree-type;
description
"Identity for the Source-Specific Multicast (SSM) tree type.";
reference "RFC 8299: YANG Data Model for L3VPN Service Delivery";
}
identity asm-tree-type {
base multicast-tree-type;
description
"Identity for the Any-Source Multicast (ASM) tree type.";
reference "RFC 8299: YANG Data Model for L3VPN Service Delivery";
}
identity asm-tree-type {
base multicast-tree-type;
description
"Identity for the Any-Source Multicast (ASM) tree type.";
reference "RFC 8299: YANG Data Model for L3VPN Service Delivery";
}
identity bidir-tree-type {
base multicast-tree-type;
description
"Identity for the bidirectional tree type.";
reference "RFC 8299: YANG Data Model for L3VPN Service Delivery";
}
identity bidir-tree-type {
base multicast-tree-type;
description
"Identity for the bidirectional tree type.";
reference "RFC 8299: YANG Data Model for L3VPN Service Delivery";
}
identity multicast-gp-address-mapping {
description
"Identity for mapping type.";
}
identity multicast-gp-address-mapping {
description
"Identity for mapping type.";
}
identity static-mapping {
base multicast-gp-address-mapping;
description
identity static-mapping {
base multicast-gp-address-mapping;
description
"Identity for static mapping, i.e., attach the interface
to the multicast group as a static member.";
}
"Identity for static mapping, i.e., attach the interface
to the multicast group as a static member.";
}
identity dynamic-mapping {
base multicast-gp-address-mapping;
description
"Identity for dynamic mapping, i.e., an interface was added
to the multicast group as a result of snooping.";
}
identity dynamic-mapping {
base multicast-gp-address-mapping;
description
"Identity for dynamic mapping, i.e., an interface was added
to the multicast group as a result of snooping.";
}
identity tf-type {
description
"Identity for the traffic type.";
}
identity tf-type {
description
"Identity for the traffic type.";
}
identity multicast-traffic {
base tf-type;
description
"Identity for multicast traffic.";
}
identity multicast-traffic {
base tf-type;
description
"Identity for multicast traffic.";
}
identity broadcast-traffic {
base tf-type;
description
"Identity for broadcast traffic.";
}
identity broadcast-traffic {
base tf-type;
description
"Identity for broadcast traffic.";
}
identity unknown-unicast-traffic {
base tf-type;
description
"Identity for unknown unicast traffic.";
}
identity unknown-unicast-traffic {
base tf-type;
description
"Identity for unknown unicast traffic.";
}
identity encapsulation-type {
description
"Identity for the encapsulation type.";
}
identity encapsulation-type {
description
"Identity for the encapsulation type.";
}
identity ethernet {
base encapsulation-type;
description
"Identity for Ethernet type.";
}
identity ethernet {
base encapsulation-type;
description
"Identity for Ethernet type.";
}
identity vlan {
base encapsulation-type;
description
identity vlan {
base encapsulation-type;
description
"Identity for the VLAN type.";
}
"Identity for the VLAN type.";
}
identity carrierscarrier-type {
description
"Identity of the CsC type.";
}
identity carrierscarrier-type {
description
"Identity of the CsC type.";
}
identity ldp {
base carrierscarrier-type;
description
"Use LDP as the signaling protocol
between the PE and the CE.";
}
identity ldp {
base carrierscarrier-type;
description
"Use LDP as the signaling protocol
between the PE and the CE.";
}
identity bgp {
base carrierscarrier-type;
description
"Use BGP (as per RFC 8277) as the signaling protocol
between the PE and the CE.
In this case, BGP must also be configured as
the routing protocol.";
}
identity bgp {
base carrierscarrier-type;
description
"Use BGP (as per RFC 8277) as the signaling protocol
between the PE and the CE.
In this case, BGP must also be configured as
the routing protocol.";
}
identity eth-inf-type {
description
"Identity of the Ethernet interface type.";
}
identity eth-inf-type {
description
"Identity of the Ethernet interface type.";
}
identity tagged {
base eth-inf-type;
description
"Identity of the tagged interface type.";
}
identity tagged {
base eth-inf-type;
description
"Identity of the tagged interface type.";
}
identity untagged {
base eth-inf-type;
description
"Identity of the untagged interface type.";
}
identity untagged {
base eth-inf-type;
description
"Identity of the untagged interface type.";
}
identity lag {
base eth-inf-type;
description
"Identity of the LAG interface type.";
}
identity lag {
base eth-inf-type;
description
"Identity of the LAG interface type.";
}
identity bw-type {
标识bw类型{
description
"Identity of the bandwidth type.";
}
description
"Identity of the bandwidth type.";
}
identity bw-per-cos {
base bw-type;
description
"Bandwidth is per CoS.";
}
identity bw-per-cos {
base bw-type;
description
"Bandwidth is per CoS.";
}
identity bw-per-port {
base bw-type;
description
"Bandwidth is per site network access.";
}
identity bw-per-port {
base bw-type;
description
"Bandwidth is per site network access.";
}
identity bw-per-site {
base bw-type;
description
"Bandwidth is per site. It is applicable to
all the site network accesses within the site.";
}
identity bw-per-site {
base bw-type;
description
"Bandwidth is per site. It is applicable to
all the site network accesses within the site.";
}
identity bw-per-svc {
base bw-type;
description
"Bandwidth is per VPN service.";
}
identity bw-per-svc {
base bw-type;
description
"Bandwidth is per VPN service.";
}
identity site-vpn-flavor {
description
"Base identity for the site VPN service flavor.";
}
identity site-vpn-flavor {
description
"Base identity for the site VPN service flavor.";
}
identity site-vpn-flavor-single {
base site-vpn-flavor;
description
"Identity for the site VPN service flavor.
Used when the site belongs to only one VPN.";
}
identity site-vpn-flavor-single {
base site-vpn-flavor;
description
"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
"Identity for the site VPN service flavor.
Used when a logical connection of a site
belongs to multiple VPNs.";
}
identity site-vpn-flavor-multi {
base site-vpn-flavor;
description
"Identity for the site VPN service flavor.
Used when a logical connection of a site
belongs to multiple VPNs.";
}
identity site-vpn-flavor-nni {
base site-vpn-flavor;
description
"Identity for the site VPN service flavor.
Used to describe an NNI option A connection.";
}
identity site-vpn-flavor-nni {
base site-vpn-flavor;
description
"Identity for the site VPN service flavor.
Used to describe an NNI option A connection.";
}
identity service-type {
description
"Base identity of the service type.";
}
identity service-type {
description
"Base identity of the service type.";
}
identity vpws {
base service-type;
description
"Point-to-point Virtual Private Wire Service (VPWS)
service type.";
}
identity vpws {
base service-type;
description
"Point-to-point Virtual Private Wire Service (VPWS)
service type.";
}
identity pwe3 {
base service-type;
description
"Pseudowire Emulation Edge to Edge (PWE3) service type.";
}
identity pwe3 {
base service-type;
description
"Pseudowire Emulation Edge to Edge (PWE3) service type.";
}
identity ldp-l2tp-vpls {
base service-type;
description
"LDP-based or L2TP-based multipoint Virtual Private LAN
Service (VPLS) service type. This VPLS uses LDP-signaled
Pseudowires or L2TP-signaled Pseudowires.";
}
identity ldp-l2tp-vpls {
base service-type;
description
"LDP-based or L2TP-based multipoint Virtual Private LAN
Service (VPLS) service type. This VPLS uses LDP-signaled
Pseudowires or L2TP-signaled Pseudowires.";
}
identity bgp-vpls {
base service-type;
description
"BGP-based multipoint VPLS service type. This VPLS uses a
BGP control plane as described in RFCs 4761 and 6624.";
}
identity bgp-vpls {
base service-type;
description
"BGP-based multipoint VPLS service type. This VPLS uses a
BGP control plane as described in RFCs 4761 and 6624.";
}
identity vpws-evpn {
base service-type;
description
"VPWS service type using Ethernet VPNs (EVPNs)
as specified in RFC 7432.";
}
identity vpws-evpn {
base service-type;
description
"VPWS service type using Ethernet VPNs (EVPNs)
as specified in RFC 7432.";
}
identity pbb-evpn {
身份pbb evpn{
base service-type;
description
"Provider Backbone Bridge (PBB) service type using
EVPNs as specified in RFC 7432.";
}
base service-type;
description
"Provider Backbone Bridge (PBB) service type using
EVPNs as specified in RFC 7432.";
}
identity bundling-type {
description
"The base identity for the bundling type. It supports
multiple CE-VLANs associated with an L2VPN service or
all CE-VLANs associated with an L2VPN service.";
}
identity bundling-type {
description
"The base identity for the bundling type. It supports
multiple CE-VLANs associated with an L2VPN service or
all CE-VLANs associated with an L2VPN service.";
}
identity multi-svc-bundling {
base bundling-type;
description
"Identity for multi-service bundling, i.e.,
multiple CE-VLAN IDs can be associated with an
L2VPN service at a site.";
}
identity multi-svc-bundling {
base bundling-type;
description
"Identity for multi-service bundling, i.e.,
multiple CE-VLAN IDs can be associated with an
L2VPN service at a site.";
}
identity one2one-bundling {
base bundling-type;
description
"Identity for one-to-one service bundling, i.e.,
each L2VPN can be associated with only one CE-VLAN ID
at a site.";
}
identity one2one-bundling {
base bundling-type;
description
"Identity for one-to-one service bundling, i.e.,
each L2VPN can be associated with only one CE-VLAN ID
at a site.";
}
identity all2one-bundling {
base bundling-type;
description
"Identity for all-to-one bundling, i.e., all CE-VLAN IDs
are mapped to one L2VPN service.";
}
identity all2one-bundling {
base bundling-type;
description
"Identity for all-to-one bundling, i.e., all CE-VLAN IDs
are mapped to one L2VPN service.";
}
identity color-id {
description
"Base identity of the color ID.";
}
identity color-id {
description
"Base identity of the color ID.";
}
identity color-id-cvlan {
base color-id;
description
"Identity of the color ID based on a CVLAN.";
}
identity color-id-cvlan {
base color-id;
description
"Identity of the color ID based on a CVLAN.";
}
identity cos-id {
身份识别码{
description
"Identity of the CoS ID.";
}
description
"Identity of the CoS ID.";
}
identity cos-id-pcp {
base cos-id;
description
"Identity of the CoS ID based on the
Port Control Protocol (PCP).";
}
identity cos-id-pcp {
base cos-id;
description
"Identity of the CoS ID based on the
Port Control Protocol (PCP).";
}
identity cos-id-dscp {
base cos-id;
description
"Identity of the CoS ID based on DSCP.";
}
identity cos-id-dscp {
base cos-id;
description
"Identity of the CoS ID based on DSCP.";
}
identity color-type {
description
"Identity of color types.";
}
identity color-type {
description
"Identity of color types.";
}
identity green {
base color-type;
description
"Identity of the 'green' color type.";
}
identity green {
base color-type;
description
"Identity of the 'green' color type.";
}
identity yellow {
base color-type;
description
"Identity of the 'yellow' color type.";
}
identity yellow {
base color-type;
description
"Identity of the 'yellow' color type.";
}
identity red {
base color-type;
description
"Identity of the 'red' color type.";
}
identity red {
base color-type;
description
"Identity of the 'red' color type.";
}
identity policing {
description
"Identity of the type of policing applied.";
}
identity policing {
description
"Identity of the type of policing applied.";
}
identity one-rate-two-color {
base policing;
description
identity one-rate-two-color {
base policing;
description
"Identity of one-rate, two-color (1R2C).";
}
"Identity of one-rate, two-color (1R2C).";
}
identity two-rate-three-color {
base policing;
description
"Identity of two-rate, three-color (2R3C).";
}
identity two-rate-three-color {
base policing;
description
"Identity of two-rate, three-color (2R3C).";
}
identity bum-type {
description
"Identity of the BUM type.";
}
identity bum-type {
description
"Identity of the BUM type.";
}
identity broadcast {
base bum-type;
description
"Identity of broadcast.";
}
identity broadcast {
base bum-type;
description
"Identity of broadcast.";
}
identity unicast {
base bum-type;
description
"Identity of unicast.";
}
identity unicast {
base bum-type;
description
"Identity of unicast.";
}
identity multicast {
base bum-type;
description
"Identity of multicast.";
}
identity multicast {
base bum-type;
description
"Identity of multicast.";
}
identity loop-prevention-type {
description
"Identity of loop prevention.";
}
identity loop-prevention-type {
description
"Identity of loop prevention.";
}
identity shut {
base loop-prevention-type;
description
"Identity of shut protection.";
}
identity shut {
base loop-prevention-type;
description
"Identity of shut protection.";
}
identity trap {
base loop-prevention-type;
description
"Identity of trap protection.";
}
identity trap {
base loop-prevention-type;
description
"Identity of trap protection.";
}
identity lacp-state {
description
"Identity of the LACP state.";
}
identity lacp-state {
description
"Identity of the LACP state.";
}
identity lacp-on {
base lacp-state;
description
"Identity of LACP on.";
}
identity lacp-on {
base lacp-state;
description
"Identity of LACP on.";
}
identity lacp-off {
base lacp-state;
description
"Identity of LACP off.";
}
identity lacp-off {
base lacp-state;
description
"Identity of LACP off.";
}
identity lacp-mode {
description
"Identity of the LACP mode.";
}
identity lacp-mode {
description
"Identity of the LACP mode.";
}
identity lacp-passive {
base lacp-mode;
description
"Identity of LACP passive.";
}
identity lacp-passive {
base lacp-mode;
description
"Identity of LACP passive.";
}
identity lacp-active {
base lacp-mode;
description
"Identity of LACP active.";
}
identity lacp-active {
base lacp-mode;
description
"Identity of LACP active.";
}
identity lacp-speed {
description
"Identity of the LACP speed.";
}
identity lacp-speed {
description
"Identity of the LACP speed.";
}
identity lacp-fast {
base lacp-speed;
description
"Identity of LACP fast.";
}
identity lacp-fast {
base lacp-speed;
description
"Identity of LACP fast.";
}
identity lacp-slow {
base lacp-speed;
description
identity lacp-slow {
base lacp-speed;
description
"Identity of LACP slow.";
}
"Identity of LACP slow.";
}
identity bw-direction {
description
"Identity for the bandwidth direction.";
}
identity bw-direction {
description
"Identity for the bandwidth direction.";
}
identity input-bw {
base bw-direction;
description
"Identity for the input bandwidth.";
}
identity input-bw {
base bw-direction;
description
"Identity for the input bandwidth.";
}
identity output-bw {
base bw-direction;
description
"Identity for the output bandwidth.";
}
identity output-bw {
base bw-direction;
description
"Identity for the output bandwidth.";
}
identity management {
description
"Base identity for the site management scheme.";
}
identity management {
description
"Base identity for the site management scheme.";
}
identity co-managed {
base management;
description
"Identity for a co-managed site.";
}
identity co-managed {
base management;
description
"Identity for a co-managed site.";
}
identity customer-managed {
base management;
description
"Identity for a customer-managed site.";
}
identity customer-managed {
base management;
description
"Identity for a customer-managed site.";
}
identity provider-managed {
base management;
description
"Identity for a provider-managed site.";
}
identity provider-managed {
base management;
description
"Identity for a provider-managed site.";
}
identity address-family {
description
"Identity for an address family.";
}
identity address-family {
description
"Identity for an address family.";
}
identity ipv4 {
base address-family;
description
"Identity for an IPv4 address family.";
}
identity ipv4 {
base address-family;
description
"Identity for an IPv4 address family.";
}
identity ipv6 {
base address-family;
description
"Identity for an IPv6 address family.";
}
identity ipv6 {
base address-family;
description
"Identity for an IPv6 address family.";
}
identity vpn-topology {
description
"Base identity for the VPN topology.";
}
identity vpn-topology {
description
"Base identity for the VPN topology.";
}
identity any-to-any {
base vpn-topology;
description
"Identity for the any-to-any VPN topology.";
}
identity any-to-any {
base vpn-topology;
description
"Identity for the any-to-any VPN topology.";
}
identity hub-spoke {
base vpn-topology;
description
"Identity for the Hub-and-Spoke VPN topology.";
}
identity hub-spoke {
base vpn-topology;
description
"Identity for the Hub-and-Spoke VPN topology.";
}
identity hub-spoke-disjoint {
base vpn-topology;
description
"Identity for the Hub-and-Spoke VPN topology,
where Hubs cannot communicate with each other.";
}
identity hub-spoke-disjoint {
base vpn-topology;
description
"Identity for the Hub-and-Spoke VPN topology,
where Hubs cannot communicate with each other.";
}
identity site-role {
description
"Base identity for a site type.";
}
identity site-role {
description
"Base identity for a site type.";
}
identity any-to-any-role {
base site-role;
description
"Site in an any-to-any L2VPN.";
}
identity any-to-any-role {
base site-role;
description
"Site in an any-to-any L2VPN.";
}
identity spoke-role {
身份代言角色{
base site-role;
description
"Spoke site in a Hub-and-Spoke L2VPN.";
}
base site-role;
description
"Spoke site in a Hub-and-Spoke L2VPN.";
}
identity hub-role {
base site-role;
description
"Hub site in a Hub-and-Spoke L2VPN.";
}
identity hub-role {
base site-role;
description
"Hub site in a Hub-and-Spoke L2VPN.";
}
identity pm-type {
description
"Performance-monitoring type.";
}
identity pm-type {
description
"Performance-monitoring type.";
}
identity loss {
base pm-type;
description
"Loss measurement.";
}
identity loss {
base pm-type;
description
"Loss measurement.";
}
identity delay {
base pm-type;
description
"Delay measurement.";
}
identity delay {
base pm-type;
description
"Delay measurement.";
}
identity fault-alarm-defect-type {
description
"Indicates the alarm-priority defect (i.e., the
lowest-priority defect that is allowed to
generate a fault alarm).";
}
identity fault-alarm-defect-type {
description
"Indicates the alarm-priority defect (i.e., the
lowest-priority defect that is allowed to
generate a fault alarm).";
}
identity remote-rdi {
base fault-alarm-defect-type;
description
"Indicates the aggregate health
of the Remote MEPs.";
}
identity remote-rdi {
base fault-alarm-defect-type;
description
"Indicates the aggregate health
of the Remote MEPs.";
}
identity remote-mac-error {
base fault-alarm-defect-type;
description
"Indicates that one or more of the Remote MEPs are
reporting a failure in their Port Status TLVs or
Interface Status TLVs.";
identity remote-mac-error {
base fault-alarm-defect-type;
description
"Indicates that one or more of the Remote MEPs are
reporting a failure in their Port Status TLVs or
Interface Status TLVs.";
}
}
identity remote-invalid-ccm {
base fault-alarm-defect-type;
description
"Indicates that at least one of the Remote MEP
state machines is not receiving valid
Continuity Check Messages (CCMs) from its Remote MEP.";
}
identity remote-invalid-ccm {
base fault-alarm-defect-type;
description
"Indicates that at least one of the Remote MEP
state machines is not receiving valid
Continuity Check Messages (CCMs) from its Remote MEP.";
}
identity invalid-ccm {
base fault-alarm-defect-type;
description
"Indicates that one or more invalid CCMs have been
received and that a period of time 3.5 times the length
of those CCMs' transmission intervals has not yet expired.";
}
identity invalid-ccm {
base fault-alarm-defect-type;
description
"Indicates that one or more invalid CCMs have been
received and that a period of time 3.5 times the length
of those CCMs' transmission intervals has not yet expired.";
}
identity cross-connect-ccm {
base fault-alarm-defect-type;
description
"Indicates that one or more cross-connect CCMs have been
received and that 3.5 times the period of at least one of
those CCMs' transmission intervals has not yet expired.";
}
identity cross-connect-ccm {
base fault-alarm-defect-type;
description
"Indicates that one or more cross-connect CCMs have been
received and that 3.5 times the period of at least one of
those CCMs' transmission intervals has not yet expired.";
}
identity frame-delivery-mode {
description
"Delivery types.";
}
identity frame-delivery-mode {
description
"Delivery types.";
}
identity discard {
base frame-delivery-mode;
description
"Service frames are discarded.";
}
identity discard {
base frame-delivery-mode;
description
"Service frames are discarded.";
}
identity unconditional {
base frame-delivery-mode;
description
"Service frames are unconditionally delivered to the
destination site.";
}
identity unconditional {
base frame-delivery-mode;
description
"Service frames are unconditionally delivered to the
destination site.";
}
identity unknown-discard {
base frame-delivery-mode;
description
"Service frames are conditionally delivered to the
identity unknown-discard {
base frame-delivery-mode;
description
"Service frames are conditionally delivered to the
destination site. Packets with unknown destination addresses
will be discarded.";
}
destination site. Packets with unknown destination addresses
will be discarded.";
}
identity placement-diversity {
description
"Base identity for site placement constraints.";
}
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 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 pe-diverse {
base placement-diversity;
description
"Identity for PE diversity.";
}
identity pop-diverse {
base placement-diversity;
description
"Identity for POP diversity.";
}
identity pop-diverse {
base placement-diversity;
description
"Identity for POP diversity.";
}
identity linecard-diverse {
base placement-diversity;
description
"Identity for linecard 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-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 same-bearer {
base placement-diversity;
description
"Identity for having sites connected using the same bearer.";
}
identity tagged-inf-type { description
标识标记的inf类型{说明
"Identity for the tagged interface type.";
}
"Identity for the tagged interface type.";
}
identity priority-tagged {
base tagged-inf-type;
description
"Identity for the priority-tagged interface.";
}
identity priority-tagged {
base tagged-inf-type;
description
"Identity for the priority-tagged interface.";
}
identity qinq {
base tagged-inf-type;
description
"Identity for the QinQ tagged interface.";
}
identity qinq {
base tagged-inf-type;
description
"Identity for the QinQ tagged interface.";
}
identity dot1q {
base tagged-inf-type;
description
"Identity for the dot1Q VLAN tagged interface.";
}
identity dot1q {
base tagged-inf-type;
description
"Identity for the dot1Q VLAN tagged interface.";
}
identity qinany {
base tagged-inf-type;
description
"Identity for the QinAny tagged interface.";
}
identity qinany {
base tagged-inf-type;
description
"Identity for the QinAny tagged interface.";
}
identity vxlan {
base tagged-inf-type;
description
"Identity for the VXLAN tagged interface.";
}
identity vxlan {
base tagged-inf-type;
description
"Identity for the VXLAN tagged interface.";
}
identity provision-model {
description
"Base identity for the provision model.";
}
identity provision-model {
description
"Base identity for the provision model.";
}
identity single-side-provision {
description
"Identity for single-sided provisioning with discovery.";
}
identity single-side-provision {
description
"Identity for single-sided provisioning with discovery.";
}
identity doubled-side-provision {
description
"Identity for double-sided provisioning.";
}
identity doubled-side-provision {
description
"Identity for double-sided provisioning.";
}
identity mac-learning-mode {
description
"MAC learning mode.";
}
identity mac-learning-mode {
description
"MAC learning mode.";
}
identity data-plane {
base mac-learning-mode;
description
"User MAC addresses are learned through ARP broadcast.";
}
identity data-plane {
base mac-learning-mode;
description
"User MAC addresses are learned through ARP broadcast.";
}
identity control-plane {
base mac-learning-mode;
description
"User MAC addresses are advertised through EVPN-BGP.";
}
identity control-plane {
base mac-learning-mode;
description
"User MAC addresses are advertised through EVPN-BGP.";
}
identity vpn-policy-filter-type {
description
"Base identity for the filter type.";
}
identity vpn-policy-filter-type {
description
"Base identity for the filter type.";
}
identity lan {
base vpn-policy-filter-type;
description
"Identity for a LAN tag filter type.";
}
identity lan {
base vpn-policy-filter-type;
description
"Identity for a LAN tag filter type.";
}
identity mac-action {
description
"Base identity for a MAC action.";
}
identity mac-action {
description
"Base identity for a MAC action.";
}
identity drop {
base mac-action;
description
"Identity for dropping a packet.";
}
identity drop {
base mac-action;
description
"Identity for dropping a packet.";
}
identity flood {
base mac-action;
description
"Identity for packet flooding.";
}
identity flood {
base mac-action;
description
"Identity for packet flooding.";
}
identity warning {
base mac-action;
description
identity warning {
base mac-action;
description
"Identity for sending a warning log message.";
}
"Identity for sending a warning log message.";
}
identity qos-profile-direction {
description
"Base identity for the QoS-profile direction.";
}
identity qos-profile-direction {
description
"Base identity for the QoS-profile direction.";
}
identity site-to-wan {
base qos-profile-direction;
description
"Identity for the site-to-WAN direction.";
}
identity site-to-wan {
base qos-profile-direction;
description
"Identity for the site-to-WAN direction.";
}
identity wan-to-site {
base qos-profile-direction;
description
"Identity for the WAN-to-site direction.";
}
identity wan-to-site {
base qos-profile-direction;
description
"Identity for the WAN-to-site direction.";
}
identity bidirectional {
base qos-profile-direction;
description
"Identity for both the WAN-to-site direction
and the site-to-WAN direction.";
}
identity bidirectional {
base qos-profile-direction;
description
"Identity for both the WAN-to-site direction
and the site-to-WAN direction.";
}
identity vxlan-peer-mode {
description
"Base identity for the VXLAN peer mode.";
}
identity vxlan-peer-mode {
description
"Base identity for the VXLAN peer mode.";
}
identity static-mode {
base vxlan-peer-mode;
description
"Identity for VXLAN access in the static mode.";
}
identity static-mode {
base vxlan-peer-mode;
description
"Identity for VXLAN access in the static mode.";
}
identity bgp-mode {
base vxlan-peer-mode;
description
"Identity for VXLAN access by BGP EVPN learning.";
}
identity bgp-mode {
base vxlan-peer-mode;
description
"Identity for VXLAN access by BGP EVPN learning.";
}
identity customer-application {
description
"Base identity for a customer application.";
}
identity customer-application {
description
"Base identity for a customer application.";
}
identity web {
base customer-application;
description
"Identity for a web application (e.g., HTTP, HTTPS).";
}
identity web {
base customer-application;
description
"Identity for a web application (e.g., HTTP, HTTPS).";
}
identity mail {
base customer-application;
description
"Identity for a mail application.";
}
identity mail {
base customer-application;
description
"Identity for a mail application.";
}
identity file-transfer {
base customer-application;
description
"Identity for a file-transfer application
(e.g., FTP, SFTP).";
}
identity file-transfer {
base customer-application;
description
"Identity for a file-transfer application
(e.g., FTP, SFTP).";
}
identity database {
base customer-application;
description
"Identity for a database application.";
}
identity database {
base customer-application;
description
"Identity for a database application.";
}
identity social {
base customer-application;
description
"Identity for a social-network application.";
}
identity social {
base customer-application;
description
"Identity for a social-network application.";
}
identity games {
base customer-application;
description
"Identity for a gaming application.";
}
identity games {
base customer-application;
description
"Identity for a gaming application.";
}
identity p2p {
base customer-application;
description
"Identity for a peer-to-peer application.";
}
identity p2p {
base customer-application;
description
"Identity for a peer-to-peer application.";
}
identity network-management {
base customer-application;
description
"Identity for a management application
(e.g., Telnet, syslog, SNMP).";
identity network-management {
base customer-application;
description
"Identity for a management application
(e.g., Telnet, syslog, SNMP).";
}
}
identity voice {
base customer-application;
description
"Identity for a voice application.";
}
identity voice {
base customer-application;
description
"Identity for a voice application.";
}
identity video {
base customer-application;
description
"Identity for a videoconference application.";
}
identity video {
base customer-application;
description
"Identity for a videoconference application.";
}
identity embb {
base customer-application;
description
"Identity for the enhanced Mobile Broadband (eMBB)
application. Note that the eMBB application
requires strict threshold values for a wide variety
of network performance parameters (e.g., data rate,
latency, loss rate, reliability).";
}
identity embb {
base customer-application;
description
"Identity for the enhanced Mobile Broadband (eMBB)
application. Note that the eMBB application
requires strict threshold values for a wide variety
of network performance parameters (e.g., data rate,
latency, loss rate, reliability).";
}
identity urllc {
base customer-application;
description
"Identity for the Ultra-Reliable and Low Latency
Communications (URLLC) application. Note that the
URLLC application requires strict threshold values for
a wide variety of network performance parameters
(e.g., latency, reliability).";
}
identity urllc {
base customer-application;
description
"Identity for the Ultra-Reliable and Low Latency
Communications (URLLC) application. Note that the
URLLC application requires strict threshold values for
a wide variety of network performance parameters
(e.g., latency, reliability).";
}
identity mmtc {
base customer-application;
description
"Identity for the massive Machine Type
Communications (mMTC) application. Note that the
mMTC application requires strict threshold values for
a wide variety of network performance parameters
(e.g., data rate, latency, loss rate, reliability).";
}
identity mmtc {
base customer-application;
description
"Identity for the massive Machine Type
Communications (mMTC) application. Note that the
mMTC application requires strict threshold values for
a wide variety of network performance parameters
(e.g., data rate, latency, loss rate, reliability).";
}
grouping site-acl {
container access-control-list {
if-feature "acl";
list mac {
grouping site-acl {
container access-control-list {
if-feature "acl";
list mac {
key "mac-address";
leaf mac-address {
type yang:mac-address;
description
"MAC addresses.";
}
description
"List of MAC addresses.";
}
description
"Container for the ACL.";
}
description
"Grouping that defines the ACL.";
}
key "mac-address";
leaf mac-address {
type yang:mac-address;
description
"MAC addresses.";
}
description
"List of MAC addresses.";
}
description
"Container for the ACL.";
}
description
"Grouping that defines the ACL.";
}
grouping site-bum {
container broadcast-unknown-unicast-multicast {
if-feature "bum";
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.";
}
list multicast-gp-address-mapping {
key "id";
leaf id {
type uint16;
description
"Unique identifier for the mapping.";
}
leaf vlan-id {
type uint16 {
range "0..1024";
grouping site-bum {
container broadcast-unknown-unicast-multicast {
if-feature "bum";
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.";
}
list multicast-gp-address-mapping {
key "id";
leaf id {
type uint16;
description
"Unique identifier for the mapping.";
}
leaf vlan-id {
type uint16 {
range "0..1024";
}
mandatory true;
description
"The VLAN ID of the multicast group.
The range of the 12-bit VLAN ID is 0 to 1024.";
}
leaf mac-gp-address {
type yang:mac-address;
mandatory true;
description
"The MAC address of the multicast group.";
}
leaf port-lag-number {
type uint32;
description
"The ports/LAGs belonging to the multicast group.";
}
description
"List of port-to-group mappings.";
}
leaf bum-overall-rate {
type uint64;
units "bps";
description
"Overall rate for BUM.";
}
list bum-rate-per-type {
key "type";
leaf type {
type identityref {
base bum-type;
}
description
"BUM type.";
}
leaf rate {
type uint64;
units "bps";
description
"Rate for BUM.";
}
description
"List of limit rates for the BUM type.";
}
description
"Container of BUM configurations.";
}
description
}
mandatory true;
description
"The VLAN ID of the multicast group.
The range of the 12-bit VLAN ID is 0 to 1024.";
}
leaf mac-gp-address {
type yang:mac-address;
mandatory true;
description
"The MAC address of the multicast group.";
}
leaf port-lag-number {
type uint32;
description
"The ports/LAGs belonging to the multicast group.";
}
description
"List of port-to-group mappings.";
}
leaf bum-overall-rate {
type uint64;
units "bps";
description
"Overall rate for BUM.";
}
list bum-rate-per-type {
key "type";
leaf type {
type identityref {
base bum-type;
}
description
"BUM type.";
}
leaf rate {
type uint64;
units "bps";
description
"Rate for BUM.";
}
description
"List of limit rates for the BUM type.";
}
description
"Container of BUM configurations.";
}
description
"Grouping for BUM.";
}
"Grouping for BUM.";
}
grouping site-mac-loop-prevention {
container mac-loop-prevention {
if-feature "mac-loop-prevention";
leaf protection-type {
type identityref {
base loop-prevention-type;
}
default "trap";
description
"Protection type. By default, the protection
type is 'trap'.";
}
leaf frequency {
type uint32;
default "5";
description
"The number of times to detect MAC duplication, where
a 'duplicate MAC address' situation has occurred and
the duplicate MAC address has been added to a list of
duplicate MAC addresses. By default, the number of
times is 5.";
}
leaf retry-timer {
type uint32;
units "seconds";
description
"The retry timer. When the retry timer expires,
the duplicate MAC address will be flushed from
the MAC-VRF.";
}
description
"Container of MAC loop-prevention parameters.";
}
description
"Grouping for MAC loop prevention.";
}
grouping site-mac-loop-prevention {
container mac-loop-prevention {
if-feature "mac-loop-prevention";
leaf protection-type {
type identityref {
base loop-prevention-type;
}
default "trap";
description
"Protection type. By default, the protection
type is 'trap'.";
}
leaf frequency {
type uint32;
default "5";
description
"The number of times to detect MAC duplication, where
a 'duplicate MAC address' situation has occurred and
the duplicate MAC address has been added to a list of
duplicate MAC addresses. By default, the number of
times is 5.";
}
leaf retry-timer {
type uint32;
units "seconds";
description
"The retry timer. When the retry timer expires,
the duplicate MAC address will be flushed from
the MAC-VRF.";
}
description
"Container of MAC loop-prevention parameters.";
}
description
"Grouping for MAC loop prevention.";
}
grouping site-service-qos-profile {
container qos {
if-feature "qos";
container qos-classification-policy {
list rule {
key "id";
ordered-by user;
leaf id {
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 {
container match-flow {
leaf dscp {
type inet:dscp;
description
"DSCP value.";
}
leaf dot1q {
type uint16;
description
"802.1Q matching. It is a VLAN tag added into
a frame.";
}
leaf pcp {
type uint8 {
range "0..7";
}
description
"PCP value.";
}
leaf src-mac {
type yang:mac-address;
description
"Source MAC.";
}
leaf dst-mac {
type yang:mac-address;
description
"Destination MAC.";
}
leaf color-type {
type identityref {
base color-type;
}
description
"Color types.";
}
leaf-list target-sites {
if-feature "target-sites";
type svc-id;
description
type string;
description
"A description identifying the QoS classification
policy rule.";
}
choice match-type {
default "match-flow";
case match-flow {
container match-flow {
leaf dscp {
type inet:dscp;
description
"DSCP value.";
}
leaf dot1q {
type uint16;
description
"802.1Q matching. It is a VLAN tag added into
a frame.";
}
leaf pcp {
type uint8 {
range "0..7";
}
description
"PCP value.";
}
leaf src-mac {
type yang:mac-address;
description
"Source MAC.";
}
leaf dst-mac {
type yang:mac-address;
description
"Destination MAC.";
}
leaf color-type {
type identityref {
base color-type;
}
description
"Color types.";
}
leaf-list target-sites {
if-feature "target-sites";
type svc-id;
description
"Identifies a site as a traffic destination.";
}
leaf any {
type empty;
description
"Allow all.";
}
leaf vpn-id {
type svc-id;
description
"Reference to the target VPN.";
}
description
"Describes flow-matching criteria.";
}
}
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 CoS.
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 the QoS profile.
Can be a standard profile or a customized profile.";
case standard {
description
"Identifies a site as a traffic destination.";
}
leaf any {
type empty;
description
"Allow all.";
}
leaf vpn-id {
type svc-id;
description
"Reference to the target VPN.";
}
description
"Describes flow-matching criteria.";
}
}
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 CoS.
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 the QoS profile.
Can be a standard profile or a customized profile.";
case standard {
description
"Standard QoS profile.";
leaf profile {
type leafref {
path "/l2vpn-svc/vpn-profiles/"
+ "valid-provider-identifiers/"
+ "qos-profile-identifier";
}
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 CoS. This identifier is
internal to the administration.";
}
leaf direction {
type identityref {
base qos-profile-direction;
}
default "bidirectional";
description
"The direction in which the QoS profile is
applied. By default, the direction is
bidirectional.";
}
leaf policing {
type identityref {
base policing;
}
default "one-rate-two-color";
description
"The policing type can be either one-rate,
two-color (1R2C) or two-rate, three-color
(2R3C). By default, the policing type is
'one-rate-two-color'.";
}
leaf byte-offset {
type uint16;
description
"Standard QoS profile.";
leaf profile {
type leafref {
path "/l2vpn-svc/vpn-profiles/"
+ "valid-provider-identifiers/"
+ "qos-profile-identifier";
}
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 CoS. This identifier is
internal to the administration.";
}
leaf direction {
type identityref {
base qos-profile-direction;
}
default "bidirectional";
description
"The direction in which the QoS profile is
applied. By default, the direction is
bidirectional.";
}
leaf policing {
type identityref {
base policing;
}
default "one-rate-two-color";
description
"The policing type can be either one-rate,
two-color (1R2C) or two-rate, three-color
(2R3C). By default, the policing type is
'one-rate-two-color'.";
}
leaf byte-offset {
type uint16;
description
"Number of bytes in the service frame header
that are excluded from the QoS calculation
(e.g., extra VLAN tags).";
}
container frame-delay {
choice flavor {
case lowest {
leaf use-lowest-latency {
type empty;
description
"The traffic class should use the path
with the lowest delay.";
}
}
case boundary {
leaf delay-bound {
type uint16;
units "milliseconds";
description
"The traffic class should use a path
with a defined maximum delay.";
}
}
description
"Delay constraint on the traffic class.";
}
description
"Delay constraint on the traffic class.";
}
container frame-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 delay-bound {
type uint32;
units "microseconds";
description
"The traffic class should use a path
with a defined maximum jitter.";
}
}
"Number of bytes in the service frame header
that are excluded from the QoS calculation
(e.g., extra VLAN tags).";
}
container frame-delay {
choice flavor {
case lowest {
leaf use-lowest-latency {
type empty;
description
"The traffic class should use the path
with the lowest delay.";
}
}
case boundary {
leaf delay-bound {
type uint16;
units "milliseconds";
description
"The traffic class should use a path
with a defined maximum delay.";
}
}
description
"Delay constraint on the traffic class.";
}
description
"Delay constraint on the traffic class.";
}
container frame-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 delay-bound {
type uint32;
units "microseconds";
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 frame-loss {
leaf rate {
type decimal64 {
fraction-digits 2;
range "0..100";
}
units "percent";
description
"Frame loss rate constraint on the traffic
class.";
}
description
"Container for frame loss rate.";
}
container bandwidth {
leaf guaranteed-bw-percent {
type decimal64 {
fraction-digits 5;
range "0..100";
}
units "percent";
mandatory true;
description
"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 CoS entries.";
}
description
"Container for list of CoS entries.";
}
description
"Jitter constraint on the traffic class.";
}
description
"Jitter constraint on the traffic class.";
}
container frame-loss {
leaf rate {
type decimal64 {
fraction-digits 2;
range "0..100";
}
units "percent";
description
"Frame loss rate constraint on the traffic
class.";
}
description
"Container for frame loss rate.";
}
container bandwidth {
leaf guaranteed-bw-percent {
type decimal64 {
fraction-digits 5;
range "0..100";
}
units "percent";
mandatory true;
description
"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 CoS entries.";
}
description
"Container for list of CoS entries.";
}
}
}
description
"Qos profile configuration.";
}
description
"QoS configuration.";
}
description
"Grouping that defines QoS parameters for a site.";
}
}
}
description
"Qos profile configuration.";
}
description
"QoS configuration.";
}
description
"Grouping that defines QoS parameters for a site.";
}
grouping site-service-mpls {
container carrierscarrier {
if-feature "carrierscarrier";
leaf signaling-type {
type identityref {
base carrierscarrier-type;
}
default "bgp";
description
"CsC. By default, the signaling type is 'bgp'.";
}
description
"Container for CsC.";
}
description
"Grouping for CsC.";
}
grouping site-service-mpls {
container carrierscarrier {
if-feature "carrierscarrier";
leaf signaling-type {
type identityref {
base carrierscarrier-type;
}
default "bgp";
description
"CsC. By default, the signaling type is 'bgp'.";
}
description
"Container for CsC.";
}
description
"Grouping for CsC.";
}
container l2vpn-svc {
container vpn-profiles {
container valid-provider-identifiers {
leaf-list cloud-identifier {
if-feature "cloud-access";
type string;
description
"Identification of the public cloud service or
Internet service. Local to each administration.";
}
leaf-list qos-profile-identifier {
type string;
description
"Identification of the QoS profile to be used.
Local to each administration.";
}
leaf-list bfd-profile-identifier {
type string;
container l2vpn-svc {
container vpn-profiles {
container valid-provider-identifiers {
leaf-list cloud-identifier {
if-feature "cloud-access";
type string;
description
"Identification of the public cloud service or
Internet service. Local to each administration.";
}
leaf-list qos-profile-identifier {
type string;
description
"Identification of the QoS profile to be used.
Local to each administration.";
}
leaf-list bfd-profile-identifier {
type string;
description
"Identification of the SP BFD profile to be used.
Local to each administration.";
}
leaf-list remote-carrier-identifier {
type string;
description
"Identification of the remote carrier name to be used.
It can be an L2VPN partner, data-center SP, or
private CSP. Local to each administration.";
}
nacm:default-deny-write;
description
"Container for valid provider identifiers.";
}
description
"Container for VPN profiles.";
}
container vpn-services {
list vpn-service {
key "vpn-id";
leaf vpn-id {
type svc-id;
description
"Defines a service identifier.";
}
leaf vpn-svc-type {
type identityref {
base service-type;
}
default "vpws";
description
"Service type. By default, the service type is 'vpws'.";
}
leaf customer-name {
type string;
description
"Customer name.";
}
leaf svc-topo {
type identityref {
base vpn-topology;
}
default "any-to-any";
description
"Defines the service topology, e.g.,
'any-to-any', 'hub-spoke'.";
}
description
"Identification of the SP BFD profile to be used.
Local to each administration.";
}
leaf-list remote-carrier-identifier {
type string;
description
"Identification of the remote carrier name to be used.
It can be an L2VPN partner, data-center SP, or
private CSP. Local to each administration.";
}
nacm:default-deny-write;
description
"Container for valid provider identifiers.";
}
description
"Container for VPN profiles.";
}
container vpn-services {
list vpn-service {
key "vpn-id";
leaf vpn-id {
type svc-id;
description
"Defines a service identifier.";
}
leaf vpn-svc-type {
type identityref {
base service-type;
}
default "vpws";
description
"Service type. By default, the service type is 'vpws'.";
}
leaf customer-name {
type string;
description
"Customer name.";
}
leaf svc-topo {
type identityref {
base vpn-topology;
}
default "any-to-any";
description
"Defines the service topology, e.g.,
'any-to-any', 'hub-spoke'.";
}
container cloud-accesses {
if-feature "cloud-access";
list cloud-access {
key "cloud-identifier";
leaf cloud-identifier {
type leafref {
path "/l2vpn-svc/vpn-profiles/"
+ "valid-provider-identifiers"
+ "/cloud-identifier";
}
description
"Identification of the cloud service.
Local to each administration.";
}
choice list-flavor {
case permit-any {
leaf permit-any {
type empty;
description
"Allow all sites.";
}
}
case deny-any-except {
leaf-list permit-site {
type leafref {
path "/l2vpn-svc/sites/site/site-id";
}
description
"Site ID to be authorized.";
}
}
case permit-any-except {
leaf-list deny-site {
type leafref {
path "/l2vpn-svc/sites/site/site-id";
}
description
"Site ID to be denied.";
}
}
description
"Choice for cloud access policy.
By default, all sites in the L2VPN
MUST be authorized to access the cloud.";
}
description
"Cloud access configuration.";
}
container cloud-accesses {
if-feature "cloud-access";
list cloud-access {
key "cloud-identifier";
leaf cloud-identifier {
type leafref {
path "/l2vpn-svc/vpn-profiles/"
+ "valid-provider-identifiers"
+ "/cloud-identifier";
}
description
"Identification of the cloud service.
Local to each administration.";
}
choice list-flavor {
case permit-any {
leaf permit-any {
type empty;
description
"Allow all sites.";
}
}
case deny-any-except {
leaf-list permit-site {
type leafref {
path "/l2vpn-svc/sites/site/site-id";
}
description
"Site ID to be authorized.";
}
}
case permit-any-except {
leaf-list deny-site {
type leafref {
path "/l2vpn-svc/sites/site/site-id";
}
description
"Site ID to be denied.";
}
}
description
"Choice for cloud access policy.
By default, all sites in the L2VPN
MUST be authorized to access the cloud.";
}
description
"Cloud access configuration.";
}
description
"Container for cloud access configurations.";
}
container frame-delivery {
if-feature "bum";
container customer-tree-flavors {
leaf-list tree-flavor {
type identityref {
base multicast-tree-type;
}
description
"Type of tree to be used.";
}
description
"Types of trees used by the customer.";
}
container bum-deliveries {
list bum-delivery {
key "frame-type";
leaf frame-type {
type identityref {
base tf-type;
}
description
"Type of frame delivery. It supports unicast
frame delivery, multicast frame delivery,
and broadcast frame delivery.";
}
leaf delivery-mode {
type identityref {
base frame-delivery-mode;
}
default "unconditional";
description
"Defines the frame delivery mode
('unconditional' (default), 'conditional',
or 'discard'). By default, service frames are
unconditionally delivered to the destination site.";
}
description
"List of frame delivery types and modes.";
}
description
"Defines the frame delivery types and modes.";
}
leaf multicast-gp-port-mapping {
type identityref {
base multicast-gp-address-mapping;
description
"Container for cloud access configurations.";
}
container frame-delivery {
if-feature "bum";
container customer-tree-flavors {
leaf-list tree-flavor {
type identityref {
base multicast-tree-type;
}
description
"Type of tree to be used.";
}
description
"Types of trees used by the customer.";
}
container bum-deliveries {
list bum-delivery {
key "frame-type";
leaf frame-type {
type identityref {
base tf-type;
}
description
"Type of frame delivery. It supports unicast
frame delivery, multicast frame delivery,
and broadcast frame delivery.";
}
leaf delivery-mode {
type identityref {
base frame-delivery-mode;
}
default "unconditional";
description
"Defines the frame delivery mode
('unconditional' (default), 'conditional',
or 'discard'). By default, service frames are
unconditionally delivered to the destination site.";
}
description
"List of frame delivery types and modes.";
}
description
"Defines the frame delivery types and modes.";
}
leaf multicast-gp-port-mapping {
type identityref {
base multicast-gp-address-mapping;
}
mandatory true;
description
"Describes the way in which each interface is
associated with the multicast group.";
}
description
"Multicast global parameters for the VPN service.";
}
container extranet-vpns {
if-feature "extranet-vpn";
list extranet-vpn {
key "vpn-id";
leaf vpn-id {
type svc-id;
description
"Identifies the target VPN that the local VPN wants to
access.";
}
leaf local-sites-role {
type identityref {
base site-role;
}
default "any-to-any-role";
description
"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 to which the local VPN
is attached.";
}
description
"Container for extranet VPN configurations.";
}
leaf ce-vlan-preservation {
type boolean;
mandatory true;
description
"Preserves the CE-VLAN ID from ingress to egress, i.e.,
the CE-VLAN tag of the egress frame is identical to
that of the ingress frame that yielded this
egress service frame. If all-to-one bundling within
}
mandatory true;
description
"Describes the way in which each interface is
associated with the multicast group.";
}
description
"Multicast global parameters for the VPN service.";
}
container extranet-vpns {
if-feature "extranet-vpn";
list extranet-vpn {
key "vpn-id";
leaf vpn-id {
type svc-id;
description
"Identifies the target VPN that the local VPN wants to
access.";
}
leaf local-sites-role {
type identityref {
base site-role;
}
default "any-to-any-role";
description
"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 to which the local VPN
is attached.";
}
description
"Container for extranet VPN configurations.";
}
leaf ce-vlan-preservation {
type boolean;
mandatory true;
description
"Preserves the CE-VLAN ID from ingress to egress, i.e.,
the CE-VLAN tag of the egress frame is identical to
that of the ingress frame that yielded this
egress service frame. If all-to-one bundling within
a site is enabled, then preservation applies to all
ingress service frames. If all-to-one bundling is
disabled, then preservation applies to tagged
ingress service frames having CE-VLAN IDs 1 through 4094.";
}
leaf ce-vlan-cos-preservation {
type boolean;
mandatory true;
description
"CE VLAN CoS preservation. The PCP bits in the CE-VLAN tag
of the egress frame are identical to those of the
ingress frame that yielded this egress service frame.";
}
leaf carrierscarrier {
if-feature "carrierscarrier";
type boolean;
default "false";
description
"The VPN is using CsC, and so MPLS is required.";
}
description
"List of VPN services.";
}
description
"Container for VPN services.";
}
container sites {
list site {
key "site-id";
leaf site-id {
type string;
description
"Identifier of the site.";
}
leaf site-vpn-flavor {
type identityref {
base site-vpn-flavor;
}
default "site-vpn-flavor-single";
description
"Defines the way that the VPN multiplexing is
done, e.g., whether the site belongs to
a single VPN site or a multi-VPN site. By
default, the site belongs to a single VPN.";
}
container devices {
when "derived-from-or-self(../management/type, "
+ "'l2vpn-svc:provider-managed') or "
a site is enabled, then preservation applies to all
ingress service frames. If all-to-one bundling is
disabled, then preservation applies to tagged
ingress service frames having CE-VLAN IDs 1 through 4094.";
}
leaf ce-vlan-cos-preservation {
type boolean;
mandatory true;
description
"CE VLAN CoS preservation. The PCP bits in the CE-VLAN tag
of the egress frame are identical to those of the
ingress frame that yielded this egress service frame.";
}
leaf carrierscarrier {
if-feature "carrierscarrier";
type boolean;
default "false";
description
"The VPN is using CsC, and so MPLS is required.";
}
description
"List of VPN services.";
}
description
"Container for VPN services.";
}
container sites {
list site {
key "site-id";
leaf site-id {
type string;
description
"Identifier of the site.";
}
leaf site-vpn-flavor {
type identityref {
base site-vpn-flavor;
}
default "site-vpn-flavor-single";
description
"Defines the way that the VPN multiplexing is
done, e.g., whether the site belongs to
a single VPN site or a multi-VPN site. By
default, the site belongs to a single VPN.";
}
container devices {
when "derived-from-or-self(../management/type, "
+ "'l2vpn-svc:provider-managed') or "
+ "derived-from-or-self(../management/type, "
+ "'l2vpn-svc:co-managed')" {
description
"Applicable only for a provider-managed or
co-managed device.";
}
list device {
key "device-id";
leaf device-id {
type string;
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, "
+ "'l2vpn-svc:co-managed')" {
description
"Applicable only for a co-managed device.";
}
leaf transport {
type identityref {
base address-family;
}
description
"Transport protocol or address family
used for management.";
}
leaf address {
when '(../ transport)' {
description
"If the address family is specified, then the
address should also be specified. If the
transport is not specified, then the address
should not be specified.";
}
type inet:ip-address;
description
"Management address.";
}
description
+ "derived-from-or-self(../management/type, "
+ "'l2vpn-svc:co-managed')" {
description
"Applicable only for a provider-managed or
co-managed device.";
}
list device {
key "device-id";
leaf device-id {
type string;
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, "
+ "'l2vpn-svc:co-managed')" {
description
"Applicable only for a co-managed device.";
}
leaf transport {
type identityref {
base address-family;
}
description
"Transport protocol or address family
used for management.";
}
leaf address {
when '(../ transport)' {
description
"If the address family is specified, then the
address should also be specified. If the
transport is not specified, then the address
should not be specified.";
}
type inet:ip-address;
description
"Management address.";
}
description
"Management configuration. Applicable only for a
co-managed device.";
}
description
"List of devices requested by the customer.";
}
description
"Device configurations.";
}
container management {
leaf type {
type identityref {
base management;
}
mandatory true;
description
"Management type of the connection.";
}
description
"Management configuration.";
}
container locations {
list location {
key "location-id";
leaf location-id {
type string;
description
"Location ID.";
}
leaf address {
type string;
description
"Address (number and street) of the site.";
}
leaf postal-code {
type string;
description
"Postal code of the site. The format of 'postal-code'
is similar to the 'PC' (postal code) label format
defined in RFC 4119.";
}
leaf state {
type string;
description
"State (region) of the site. This leaf can also be used
to describe a region of a country that does not have
states.";
}
"Management configuration. Applicable only for a
co-managed device.";
}
description
"List of devices requested by the customer.";
}
description
"Device configurations.";
}
container management {
leaf type {
type identityref {
base management;
}
mandatory true;
description
"Management type of the connection.";
}
description
"Management configuration.";
}
container locations {
list location {
key "location-id";
leaf location-id {
type string;
description
"Location ID.";
}
leaf address {
type string;
description
"Address (number and street) of the site.";
}
leaf postal-code {
type string;
description
"Postal code of the site. The format of 'postal-code'
is similar to the 'PC' (postal code) label format
defined in RFC 4119.";
}
leaf state {
type string;
description
"State (region) of the site. This leaf can also be used
to describe a region of a country that does not have
states.";
}
leaf city {
type string;
description
"City of the site.";
}
leaf country-code {
type string;
description
"Country of the site. The format of 'country-code' is
similar to the 'country' label defined in RFC 4119.";
}
description
"List of locations.";
}
description
"Location of the site.";
}
container site-diversity {
if-feature "site-diversity";
container groups {
list group {
key "group-id";
leaf group-id {
type string;
description
"The group-id to which the site belongs.";
}
description
"List of group-ids.";
}
description
"Groups to which the site belongs.
All site network accesses will inherit those group
values.";
}
description
"The type of diversity constraint.";
}
container vpn-policies {
list vpn-policy {
key "vpn-policy-id";
leaf vpn-policy-id {
type string;
description
"Unique identifier for the VPN policy.";
}
list entries {
key "id";
leaf city {
type string;
description
"City of the site.";
}
leaf country-code {
type string;
description
"Country of the site. The format of 'country-code' is
similar to the 'country' label defined in RFC 4119.";
}
description
"List of locations.";
}
description
"Location of the site.";
}
container site-diversity {
if-feature "site-diversity";
container groups {
list group {
key "group-id";
leaf group-id {
type string;
description
"The group-id to which the site belongs.";
}
description
"List of group-ids.";
}
description
"Groups to which the site belongs.
All site network accesses will inherit those group
values.";
}
description
"The type of diversity constraint.";
}
container vpn-policies {
list vpn-policy {
key "vpn-policy-id";
leaf vpn-policy-id {
type string;
description
"Unique identifier for the VPN policy.";
}
list entries {
key "id";
leaf id {
type string;
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, "
+ "'l2vpn-svc:lan')" {
description
"Only applies when the VPN policy filter is a
LAN tag filter.";
}
if-feature "lan-tag";
type uint32;
description
"List of Ethernet LAN tags to be matched. An
Ethernet LAN tag identifies a particular
broadcast domain in a VPN.";
}
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 the LAN tag or
the 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 "/l2vpn-svc/vpn-services/vpn-service/vpn-id";
}
leaf id {
type string;
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, "
+ "'l2vpn-svc:lan')" {
description
"Only applies when the VPN policy filter is a
LAN tag filter.";
}
if-feature "lan-tag";
type uint32;
description
"List of Ethernet LAN tags to be matched. An
Ethernet LAN tag identifies a particular
broadcast domain in a VPN.";
}
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 the LAN tag or
the 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 "/l2vpn-svc/vpn-services/vpn-service/vpn-id";
}
description
"Reference to an L2VPN.";
}
leaf site-role {
type identityref {
base site-role;
}
default "any-to-any-role";
description
"Role of the site in the L2VPN.";
}
description
"List of VPNs with which the LAN is associated.";
}
description
"List of entries for an export policy.";
}
description
"List of VPN policies.";
}
description
"VPN policy.";
}
container service {
uses site-service-qos-profile;
uses site-service-mpls;
description
"Service parameters on the attachment.";
}
uses site-bum;
uses site-mac-loop-prevention;
uses site-acl;
leaf actual-site-start {
type yang:date-and-time;
config false;
description
"This leaf is optional. It indicates the date and time
when the service at a particular site actually started.";
}
leaf actual-site-stop {
type yang:date-and-time;
config false;
description
"This leaf is optional. It indicates the date and time
when the service at a particular site actually stopped.";
}
leaf bundling-type {
type identityref {
description
"Reference to an L2VPN.";
}
leaf site-role {
type identityref {
base site-role;
}
default "any-to-any-role";
description
"Role of the site in the L2VPN.";
}
description
"List of VPNs with which the LAN is associated.";
}
description
"List of entries for an export policy.";
}
description
"List of VPN policies.";
}
description
"VPN policy.";
}
container service {
uses site-service-qos-profile;
uses site-service-mpls;
description
"Service parameters on the attachment.";
}
uses site-bum;
uses site-mac-loop-prevention;
uses site-acl;
leaf actual-site-start {
type yang:date-and-time;
config false;
description
"This leaf is optional. It indicates the date and time
when the service at a particular site actually started.";
}
leaf actual-site-stop {
type yang:date-and-time;
config false;
description
"This leaf is optional. It indicates the date and time
when the service at a particular site actually stopped.";
}
leaf bundling-type {
type identityref {
base bundling-type;
}
default "one2one-bundling";
description
"Bundling type. By default, each L2VPN
can be associated with only one
CE-VLAN, i.e., one-to-one bundling is used.";
}
leaf default-ce-vlan-id {
type uint32;
mandatory true;
description
"Default CE VLAN ID set at the site level.";
}
container site-network-accesses {
list site-network-access {
key "network-access-id";
leaf network-access-id {
type string;
description
"Identifier of network access.";
}
leaf remote-carrier-name {
when "derived-from-or-self(../../../site-vpn-flavor,"
+ "'l2vpn-svc:site-vpn-flavor-nni')" {
description
"Relevant when the site's VPN flavor is
'site-vpn-flavor-nni'.";
}
type leafref {
path "/l2vpn-svc/vpn-profiles/"
+ "valid-provider-identifiers"
+ "/remote-carrier-identifier";
}
description
"Remote carrier name. The 'remote-carrier-name'
parameter must be configured only when
'site-vpn-flavor' is set to 'site-vpn-flavor-nni'.
If it is not set, it indicates that the customer
does not know the remote carrier's name
beforehand.";
}
leaf type {
type identityref {
base site-network-access-type;
}
default "point-to-point";
description
base bundling-type;
}
default "one2one-bundling";
description
"Bundling type. By default, each L2VPN
can be associated with only one
CE-VLAN, i.e., one-to-one bundling is used.";
}
leaf default-ce-vlan-id {
type uint32;
mandatory true;
description
"Default CE VLAN ID set at the site level.";
}
container site-network-accesses {
list site-network-access {
key "network-access-id";
leaf network-access-id {
type string;
description
"Identifier of network access.";
}
leaf remote-carrier-name {
when "derived-from-or-self(../../../site-vpn-flavor,"
+ "'l2vpn-svc:site-vpn-flavor-nni')" {
description
"Relevant when the site's VPN flavor is
'site-vpn-flavor-nni'.";
}
type leafref {
path "/l2vpn-svc/vpn-profiles/"
+ "valid-provider-identifiers"
+ "/remote-carrier-identifier";
}
description
"Remote carrier name. The 'remote-carrier-name'
parameter must be configured only when
'site-vpn-flavor' is set to 'site-vpn-flavor-nni'.
If it is not set, it indicates that the customer
does not know the remote carrier's name
beforehand.";
}
leaf 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, "
+ "'l2vpn-svc:customer-managed')" {
description
"Applicable only for a 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, "
+ "'l2vpn-svc:provider-managed') or "
+ "derived-from-or-self(../../management/type, "
+ "'l2vpn-svc:co-managed')" {
description
"Applicable only for a provider-managed
or co-managed device.";
}
leaf device-reference {
type leafref {
path "../../../devices/device/device-id";
}
description
"Identifier of the CE to use.";
}
}
mandatory true;
description
"Choice of how to describe the site's location.";
}
container access-diversity {
if-feature "site-diversity";
container groups {
list group {
key "group-id";
leaf group-id {
type string;
description
"Group-id to which the site belongs.";
"Describes the type of connection, e.g.,
point-to-point or multipoint.";
}
choice location-flavor {
case location {
when "derived-from-or-self(../../management/type, "
+ "'l2vpn-svc:customer-managed')" {
description
"Applicable only for a 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, "
+ "'l2vpn-svc:provider-managed') or "
+ "derived-from-or-self(../../management/type, "
+ "'l2vpn-svc:co-managed')" {
description
"Applicable only for a provider-managed
or co-managed device.";
}
leaf device-reference {
type leafref {
path "../../../devices/device/device-id";
}
description
"Identifier of the CE to use.";
}
}
mandatory true;
description
"Choice of how to describe the site's location.";
}
container access-diversity {
if-feature "site-diversity";
container groups {
list group {
key "group-id";
leaf group-id {
type string;
description
"Group-id to which the site belongs.";
}
description
"List of group-ids.";
}
description
"Groups to which the site or site-network-access
belongs.";
}
container constraints {
list constraint {
key "constraint-type";
leaf constraint-type {
type identityref {
base placement-diversity;
}
description
"The type of diversity constraint.";
}
container target {
choice target-flavor {
default "id";
case id {
list group {
key "group-id";
leaf group-id {
type string;
description
"The constraint will apply against this
particular group-id.";
}
description
"List of groups.";
}
}
case all-accesses {
leaf all-other-accesses {
type empty;
description
"The constraint will apply against all other
site network accesses of this site.";
}
}
case all-groups {
leaf all-other-groups {
type empty;
description
"The constraint will apply against all other
groups the customer is managing.";
}
description
"List of group-ids.";
}
description
"Groups to which the site or site-network-access
belongs.";
}
container constraints {
list constraint {
key "constraint-type";
leaf constraint-type {
type identityref {
base placement-diversity;
}
description
"The type of diversity constraint.";
}
container target {
choice target-flavor {
default "id";
case id {
list group {
key "group-id";
leaf group-id {
type string;
description
"The constraint will apply against this
particular group-id.";
}
description
"List of groups.";
}
}
case all-accesses {
leaf all-other-accesses {
type empty;
description
"The constraint will apply against all other
site network accesses of this site.";
}
}
case all-groups {
leaf all-other-groups {
type empty;
description
"The constraint will apply against all other
groups the customer is managing.";
}
}
description
"Choice for the group definition.";
}
description
"The constraint will apply against
this list of groups.";
}
description
"List of constraints.";
}
description
"Constraints for placing this site network access.";
}
description
"Diversity parameters.";
}
container bearer {
container requested-type {
if-feature "requested-type";
leaf type {
type string;
description
"Type of requested bearer: Ethernet, ATM, Frame
Relay, IP Layer 2 transport, Frame Relay Data
Link Connection Identifier (DLCI), SONET/SDH,
PPP.";
}
leaf strict {
type boolean;
default "false";
description
"Defines whether the requested type is a preference
or a strict requirement.";
}
description
"Container for requested types.";
}
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-in access
type.";
}
}
}
description
"Choice for the group definition.";
}
description
"The constraint will apply against
this list of groups.";
}
description
"List of constraints.";
}
description
"Constraints for placing this site network access.";
}
description
"Diversity parameters.";
}
container bearer {
container requested-type {
if-feature "requested-type";
leaf type {
type string;
description
"Type of requested bearer: Ethernet, ATM, Frame
Relay, IP Layer 2 transport, Frame Relay Data
Link Connection Identifier (DLCI), SONET/SDH,
PPP.";
}
leaf strict {
type boolean;
default "false";
description
"Defines whether the requested type is a preference
or a strict requirement.";
}
description
"Container for requested types.";
}
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-in access
type.";
}
leaf bearer-reference {
if-feature "bearer-reference";
type string;
description
"An internal reference for the SP.";
}
description
"Bearer-specific parameters. To be augmented.";
}
container connection {
leaf encapsulation-type {
type identityref {
base encapsulation-type;
}
default "ethernet";
description
"Encapsulation type. By default, the
encapsulation type is set to 'ethernet'.";
}
leaf eth-inf-type {
type identityref {
base eth-inf-type;
}
default "untagged";
description
"Ethernet interface type. By default, the
Ethernet interface type is set to 'untagged'.";
}
container tagged-interface {
leaf type {
type identityref {
base tagged-inf-type;
}
default "priority-tagged";
description
"Tagged interface type. By default,
the type of the tagged interface is
'priority-tagged'.";
}
container dot1q-vlan-tagged {
when "derived-from-or-self(../type, "
+ "'l2vpn-svc:dot1q')" {
description
"Only applies when the type of the tagged
interface is 'dot1q'.";
}
if-feature "dot1q";
leaf tg-type {
leaf bearer-reference {
if-feature "bearer-reference";
type string;
description
"An internal reference for the SP.";
}
description
"Bearer-specific parameters. To be augmented.";
}
container connection {
leaf encapsulation-type {
type identityref {
base encapsulation-type;
}
default "ethernet";
description
"Encapsulation type. By default, the
encapsulation type is set to 'ethernet'.";
}
leaf eth-inf-type {
type identityref {
base eth-inf-type;
}
default "untagged";
description
"Ethernet interface type. By default, the
Ethernet interface type is set to 'untagged'.";
}
container tagged-interface {
leaf type {
type identityref {
base tagged-inf-type;
}
default "priority-tagged";
description
"Tagged interface type. By default,
the type of the tagged interface is
'priority-tagged'.";
}
container dot1q-vlan-tagged {
when "derived-from-or-self(../type, "
+ "'l2vpn-svc:dot1q')" {
description
"Only applies when the type of the tagged
interface is 'dot1q'.";
}
if-feature "dot1q";
leaf tg-type {
type identityref {
base tag-type;
}
default "c-vlan";
description
"Tag type. By default, the tag type is
'c-vlan'.";
}
leaf cvlan-id {
type uint16;
mandatory true;
description
"VLAN identifier.";
}
description
"Tagged interface.";
}
container priority-tagged {
when "derived-from-or-self(../type, "
+ "'l2vpn-svc:priority-tagged')" {
description
"Only applies when the type of the tagged
interface is 'priority-tagged'.";
}
leaf tag-type {
type identityref {
base tag-type;
}
default "c-vlan";
description
"Tag type. By default, the tag type is
'c-vlan'.";
}
description
"Priority tagged.";
}
container qinq {
when "derived-from-or-self(../type, "
+ "'l2vpn-svc:qinq')" {
description
"Only applies when the type of the tagged
interface is 'qinq'.";
}
if-feature "qinq";
leaf tag-type {
type identityref {
base tag-type;
}
type identityref {
base tag-type;
}
default "c-vlan";
description
"Tag type. By default, the tag type is
'c-vlan'.";
}
leaf cvlan-id {
type uint16;
mandatory true;
description
"VLAN identifier.";
}
description
"Tagged interface.";
}
container priority-tagged {
when "derived-from-or-self(../type, "
+ "'l2vpn-svc:priority-tagged')" {
description
"Only applies when the type of the tagged
interface is 'priority-tagged'.";
}
leaf tag-type {
type identityref {
base tag-type;
}
default "c-vlan";
description
"Tag type. By default, the tag type is
'c-vlan'.";
}
description
"Priority tagged.";
}
container qinq {
when "derived-from-or-self(../type, "
+ "'l2vpn-svc:qinq')" {
description
"Only applies when the type of the tagged
interface is 'qinq'.";
}
if-feature "qinq";
leaf tag-type {
type identityref {
base tag-type;
}
default "c-s-vlan";
description
"Tag type. By default, the tag type is
'c-s-vlan'.";
}
leaf svlan-id {
type uint16;
mandatory true;
description
"SVLAN identifier.";
}
leaf cvlan-id {
type uint16;
mandatory true;
description
"CVLAN identifier.";
}
description
"QinQ.";
}
container qinany {
when "derived-from-or-self(../type, "
+ "'l2vpn-svc:qinany')" {
description
"Only applies when the type of the tagged
interface is 'qinany'.";
}
if-feature "qinany";
leaf tag-type {
type identityref {
base tag-type;
}
default "s-vlan";
description
"Tag type. By default, the tag type is
's-vlan'.";
}
leaf svlan-id {
type uint16;
mandatory true;
description
"SVLAN ID.";
}
description
"Container for QinAny.";
}
container vxlan {
when "derived-from-or-self(../type, "
default "c-s-vlan";
description
"Tag type. By default, the tag type is
'c-s-vlan'.";
}
leaf svlan-id {
type uint16;
mandatory true;
description
"SVLAN identifier.";
}
leaf cvlan-id {
type uint16;
mandatory true;
description
"CVLAN identifier.";
}
description
"QinQ.";
}
container qinany {
when "derived-from-or-self(../type, "
+ "'l2vpn-svc:qinany')" {
description
"Only applies when the type of the tagged
interface is 'qinany'.";
}
if-feature "qinany";
leaf tag-type {
type identityref {
base tag-type;
}
default "s-vlan";
description
"Tag type. By default, the tag type is
's-vlan'.";
}
leaf svlan-id {
type uint16;
mandatory true;
description
"SVLAN ID.";
}
description
"Container for QinAny.";
}
container vxlan {
when "derived-from-or-self(../type, "
+ "'l2vpn-svc:vxlan')" {
description
"Only applies when the type of the tagged
interface is 'vxlan'.";
}
if-feature "vxlan";
leaf vni-id {
type uint32;
mandatory true;
description
"VXLAN Network Identifier (VNI).";
}
leaf peer-mode {
type identityref {
base vxlan-peer-mode;
}
default "static-mode";
description
"Specifies the VXLAN access mode. By default,
the peer mode is set to 'static-mode'.";
}
list peer-list {
key "peer-ip";
leaf peer-ip {
type inet:ip-address;
description
"Peer IP.";
}
description
"List of peer IP addresses.";
}
description
"QinQ.";
}
description
"Container for tagged interfaces.";
}
container untagged-interface {
leaf speed {
type uint32;
units "mbps";
default "10";
description
"Port speed.";
}
leaf mode {
type neg-mode;
default "auto-neg";
+ "'l2vpn-svc:vxlan')" {
description
"Only applies when the type of the tagged
interface is 'vxlan'.";
}
if-feature "vxlan";
leaf vni-id {
type uint32;
mandatory true;
description
"VXLAN Network Identifier (VNI).";
}
leaf peer-mode {
type identityref {
base vxlan-peer-mode;
}
default "static-mode";
description
"Specifies the VXLAN access mode. By default,
the peer mode is set to 'static-mode'.";
}
list peer-list {
key "peer-ip";
leaf peer-ip {
type inet:ip-address;
description
"Peer IP.";
}
description
"List of peer IP addresses.";
}
description
"QinQ.";
}
description
"Container for tagged interfaces.";
}
container untagged-interface {
leaf speed {
type uint32;
units "mbps";
default "10";
description
"Port speed.";
}
leaf mode {
type neg-mode;
default "auto-neg";
description
"Negotiation mode.";
}
leaf phy-mtu {
type uint32;
units "bytes";
description
"PHY MTU.";
}
leaf lldp {
type boolean;
default "false";
description
"LLDP. Indicates that LLDP is supported.";
}
container oam-802.3ah-link {
if-feature "oam-3ah";
leaf enabled {
type boolean;
default "false";
description
"Indicates whether or not to support
OAM 802.3ah links.";
}
description
"Container for OAM 802.3ah links.";
}
leaf uni-loop-prevention {
type boolean;
default "false";
description
"If this leaf is set to 'true', then the port
automatically goes down when a physical
loopback is detected.";
}
description
"Container of untagged interface attribute
configurations.";
}
container lag-interfaces {
if-feature "lag-interface";
list lag-interface {
key "index";
leaf index {
type string;
description
"LAG interface index.";
}
description
"Negotiation mode.";
}
leaf phy-mtu {
type uint32;
units "bytes";
description
"PHY MTU.";
}
leaf lldp {
type boolean;
default "false";
description
"LLDP. Indicates that LLDP is supported.";
}
container oam-802.3ah-link {
if-feature "oam-3ah";
leaf enabled {
type boolean;
default "false";
description
"Indicates whether or not to support
OAM 802.3ah links.";
}
description
"Container for OAM 802.3ah links.";
}
leaf uni-loop-prevention {
type boolean;
default "false";
description
"If this leaf is set to 'true', then the port
automatically goes down when a physical
loopback is detected.";
}
description
"Container of untagged interface attribute
configurations.";
}
container lag-interfaces {
if-feature "lag-interface";
list lag-interface {
key "index";
leaf index {
type string;
description
"LAG interface index.";
}
container lacp {
if-feature "lacp";
leaf enabled {
type boolean;
default "false";
description
"LACP on/off. By default, LACP is disabled.";
}
leaf mode {
type neg-mode;
description
"LACP mode. LACP modes have active mode and
passive mode ('false'). 'Active mode' means
initiating the auto-speed negotiation and
trying to form an Ethernet channel with the
other end. 'Passive mode' means not initiating
the negotiation but responding to LACP packets
initiated by the other end (e.g., full duplex
or half duplex).";
}
leaf speed {
type uint32;
units "mbps";
default "10";
description
"LACP speed. By default, the LACP speed is 10
Mbps.";
}
leaf mini-link-num {
type uint32;
description
"Defines the minimum number of links that must
be active before the aggregating link is put
into service.";
}
leaf system-priority {
type uint16;
default "32768";
description
"Indicates the LACP priority for the system.
The range is from 0 to 65535.
The default is 32768.";
}
container micro-bfd {
if-feature "micro-bfd";
leaf enabled {
type enumeration {
enum on {
container lacp {
if-feature "lacp";
leaf enabled {
type boolean;
default "false";
description
"LACP on/off. By default, LACP is disabled.";
}
leaf mode {
type neg-mode;
description
"LACP mode. LACP modes have active mode and
passive mode ('false'). 'Active mode' means
initiating the auto-speed negotiation and
trying to form an Ethernet channel with the
other end. 'Passive mode' means not initiating
the negotiation but responding to LACP packets
initiated by the other end (e.g., full duplex
or half duplex).";
}
leaf speed {
type uint32;
units "mbps";
default "10";
description
"LACP speed. By default, the LACP speed is 10
Mbps.";
}
leaf mini-link-num {
type uint32;
description
"Defines the minimum number of links that must
be active before the aggregating link is put
into service.";
}
leaf system-priority {
type uint16;
default "32768";
description
"Indicates the LACP priority for the system.
The range is from 0 to 65535.
The default is 32768.";
}
container micro-bfd {
if-feature "micro-bfd";
leaf enabled {
type enumeration {
enum on {
description
"Micro-bfd on.";
}
enum off {
description
"Micro-bfd off.";
}
}
default "off";
description
"Micro-BFD on/off. By default, micro-BFD
is set to 'off'.";
}
leaf interval {
type uint32;
units "milliseconds";
description
"BFD interval.";
}
leaf hold-timer {
type uint32;
units "milliseconds";
description
"BFD hold timer.";
}
description
"Container of micro-BFD configurations.";
}
container bfd {
if-feature "bfd";
leaf enabled {
type boolean;
default "false";
description
"BFD activation. By default, BFD is not
activated.";
}
choice holdtime {
default "fixed";
case profile {
leaf profile-name {
type leafref {
path "/l2vpn-svc/vpn-profiles/"
+ "valid-provider-identifiers"
+ "/bfd-profile-identifier";
}
description
"SP well-known profile.";
description
"Micro-bfd on.";
}
enum off {
description
"Micro-bfd off.";
}
}
default "off";
description
"Micro-BFD on/off. By default, micro-BFD
is set to 'off'.";
}
leaf interval {
type uint32;
units "milliseconds";
description
"BFD interval.";
}
leaf hold-timer {
type uint32;
units "milliseconds";
description
"BFD hold timer.";
}
description
"Container of micro-BFD configurations.";
}
container bfd {
if-feature "bfd";
leaf enabled {
type boolean;
default "false";
description
"BFD activation. By default, BFD is not
activated.";
}
choice holdtime {
default "fixed";
case profile {
leaf profile-name {
type leafref {
path "/l2vpn-svc/vpn-profiles/"
+ "valid-provider-identifiers"
+ "/bfd-profile-identifier";
}
description
"SP well-known profile.";
}
description
"SP well-known profile.";
}
case fixed {
leaf fixed-value {
type uint32;
units "milliseconds";
description
"Expected hold time expressed in
milliseconds.";
}
}
description
"Choice for the hold-time flavor.";
}
description
"Container for BFD.";
}
container member-links {
list member-link {
key "name";
leaf name {
type string;
description
"Member link name.";
}
leaf speed {
type uint32;
units "mbps";
default "10";
description
"Port speed.";
}
leaf mode {
type neg-mode;
default "auto-neg";
description
"Negotiation mode.";
}
leaf link-mtu {
type uint32;
units "bytes";
description
"Link MTU size.";
}
container oam-802.3ah-link {
if-feature "oam-3ah";
}
description
"SP well-known profile.";
}
case fixed {
leaf fixed-value {
type uint32;
units "milliseconds";
description
"Expected hold time expressed in
milliseconds.";
}
}
description
"Choice for the hold-time flavor.";
}
description
"Container for BFD.";
}
container member-links {
list member-link {
key "name";
leaf name {
type string;
description
"Member link name.";
}
leaf speed {
type uint32;
units "mbps";
default "10";
description
"Port speed.";
}
leaf mode {
type neg-mode;
default "auto-neg";
description
"Negotiation mode.";
}
leaf link-mtu {
type uint32;
units "bytes";
description
"Link MTU size.";
}
container oam-802.3ah-link {
if-feature "oam-3ah";
leaf enabled {
type boolean;
default "false";
description
"Indicates whether OAM 802.3ah links are
supported.";
}
description
"Container for OAM 802.3ah links.";
}
description
"Member link.";
}
description
"Container of the member link list.";
}
leaf flow-control {
type boolean;
default "false";
description
"Flow control. Indicates whether flow control
is supported.";
}
leaf lldp {
type boolean;
default "false";
description
"LLDP. Indicates whether LLDP is supported.";
}
description
"LACP.";
}
description
"List of LAG interfaces.";
}
description
"Container of LAG interface attribute
configurations.";
}
list cvlan-id-to-svc-map {
key "svc-id";
leaf svc-id {
type leafref {
path "/l2vpn-svc/vpn-services/vpn-service/vpn-id";
}
description
"VPN service identifier.";
}
leaf enabled {
type boolean;
default "false";
description
"Indicates whether OAM 802.3ah links are
supported.";
}
description
"Container for OAM 802.3ah links.";
}
description
"Member link.";
}
description
"Container of the member link list.";
}
leaf flow-control {
type boolean;
default "false";
description
"Flow control. Indicates whether flow control
is supported.";
}
leaf lldp {
type boolean;
default "false";
description
"LLDP. Indicates whether LLDP is supported.";
}
description
"LACP.";
}
description
"List of LAG interfaces.";
}
description
"Container of LAG interface attribute
configurations.";
}
list cvlan-id-to-svc-map {
key "svc-id";
leaf svc-id {
type leafref {
path "/l2vpn-svc/vpn-services/vpn-service/vpn-id";
}
description
"VPN service identifier.";
}
list cvlan-id {
key "vid";
leaf vid {
type uint16;
description
"CVLAN ID.";
}
description
"List of CVLAN-ID-to-SVC-map configurations.";
}
description
"List of CVLAN-ID-to-L2VPN-service-map
configurations.";
}
container l2cp-control {
if-feature "l2cp-control";
leaf stp-rstp-mstp {
type control-mode;
description
"STP / Rapid STP (RSTP) / Multiple STP (MSTP)
protocol type applicable to all sites.";
}
leaf pause {
type control-mode;
description
"Pause protocol type applicable to all sites.";
}
leaf lacp-lamp {
type control-mode;
description
"LACP / Link Aggregation Marker Protocol (LAMP).";
}
leaf link-oam {
type control-mode;
description
"Link OAM.";
}
leaf esmc {
type control-mode;
description
"Ethernet Synchronization Messaging Channel
(ESMC).";
}
leaf l2cp-802.1x {
type control-mode;
description
"IEEE 802.1x.";
}
list cvlan-id {
key "vid";
leaf vid {
type uint16;
description
"CVLAN ID.";
}
description
"List of CVLAN-ID-to-SVC-map configurations.";
}
description
"List of CVLAN-ID-to-L2VPN-service-map
configurations.";
}
container l2cp-control {
if-feature "l2cp-control";
leaf stp-rstp-mstp {
type control-mode;
description
"STP / Rapid STP (RSTP) / Multiple STP (MSTP)
protocol type applicable to all sites.";
}
leaf pause {
type control-mode;
description
"Pause protocol type applicable to all sites.";
}
leaf lacp-lamp {
type control-mode;
description
"LACP / Link Aggregation Marker Protocol (LAMP).";
}
leaf link-oam {
type control-mode;
description
"Link OAM.";
}
leaf esmc {
type control-mode;
description
"Ethernet Synchronization Messaging Channel
(ESMC).";
}
leaf l2cp-802.1x {
type control-mode;
description
"IEEE 802.1x.";
}
leaf e-lmi {
type control-mode;
description
"E-LMI.";
}
leaf lldp {
type boolean;
description
"LLDP protocol type applicable to all sites.";
}
leaf ptp-peer-delay {
type control-mode;
description
"Precision Time Protocol (PTP) peer delay.";
}
leaf garp-mrp {
type control-mode;
description
"GARP/MRP.";
}
description
"Container of L2CP control configurations.";
}
container oam {
if-feature "ethernet-oam";
leaf md-name {
type string;
mandatory true;
description
"Maintenance domain name.";
}
leaf md-level {
type uint16 {
range "0..255";
}
mandatory true;
description
"Maintenance domain level. The level may be
restricted in certain protocols (e.g.,
protocols in Layer 0 to Layer 7).";
}
list cfm-8021-ag {
if-feature "cfm";
key "maid";
leaf maid {
type string;
mandatory true;
description
leaf e-lmi {
type control-mode;
description
"E-LMI.";
}
leaf lldp {
type boolean;
description
"LLDP protocol type applicable to all sites.";
}
leaf ptp-peer-delay {
type control-mode;
description
"Precision Time Protocol (PTP) peer delay.";
}
leaf garp-mrp {
type control-mode;
description
"GARP/MRP.";
}
description
"Container of L2CP control configurations.";
}
container oam {
if-feature "ethernet-oam";
leaf md-name {
type string;
mandatory true;
description
"Maintenance domain name.";
}
leaf md-level {
type uint16 {
range "0..255";
}
mandatory true;
description
"Maintenance domain level. The level may be
restricted in certain protocols (e.g.,
protocols in Layer 0 to Layer 7).";
}
list cfm-8021-ag {
if-feature "cfm";
key "maid";
leaf maid {
type string;
mandatory true;
description
"Identifies a Maintenance Association (MA).";
}
leaf mep-id {
type uint32;
description
"Local Maintenance Entity Group End Point (MEP)
ID. The non-existence of this leaf means
that no defects are to be reported.";
}
leaf mep-level {
type uint32;
description
"Defines the MEP level. The non-existence of this
leaf means that no defects are to be reported.";
}
leaf mep-up-down {
type enumeration {
enum up {
description
"MEP up.";
}
enum down {
description
"MEP down.";
}
}
default "up";
description
"MEP up/down. By default, MEP up is used.
The non-existence of this leaf means that
no defects are to be reported.";
}
leaf remote-mep-id {
type uint32;
description
"Remote MEP ID. The non-existence of this leaf
means that no defects are to be reported.";
}
leaf cos-for-cfm-pdus {
type uint32;
description
"CoS for CFM PDUs. The non-existence of this leaf
means that no defects are to be reported.";
}
leaf ccm-interval {
type uint32;
units "milliseconds";
default "10000";
"Identifies a Maintenance Association (MA).";
}
leaf mep-id {
type uint32;
description
"Local Maintenance Entity Group End Point (MEP)
ID. The non-existence of this leaf means
that no defects are to be reported.";
}
leaf mep-level {
type uint32;
description
"Defines the MEP level. The non-existence of this
leaf means that no defects are to be reported.";
}
leaf mep-up-down {
type enumeration {
enum up {
description
"MEP up.";
}
enum down {
description
"MEP down.";
}
}
default "up";
description
"MEP up/down. By default, MEP up is used.
The non-existence of this leaf means that
no defects are to be reported.";
}
leaf remote-mep-id {
type uint32;
description
"Remote MEP ID. The non-existence of this leaf
means that no defects are to be reported.";
}
leaf cos-for-cfm-pdus {
type uint32;
description
"CoS for CFM PDUs. The non-existence of this leaf
means that no defects are to be reported.";
}
leaf ccm-interval {
type uint32;
units "milliseconds";
default "10000";
description
"CCM interval. By default, the CCM interval is
10,000 milliseconds (10 seconds).";
}
leaf ccm-holdtime {
type uint32;
units "milliseconds";
default "35000";
description
"CCM hold time. By default, the CCM hold time
is 3.5 times the CCM interval.";
}
leaf alarm-priority-defect {
type identityref {
base fault-alarm-defect-type;
}
default "remote-invalid-ccm";
description
"The lowest-priority defect that is
allowed to generate a fault alarm. By default,
'fault-alarm-defect-type' is set to
'remote-invalid-ccm'. The non-existence of
this leaf means that no defects are
to be reported.";
}
leaf ccm-p-bits-pri {
type ccm-priority-type;
description
"The priority parameter for CCMs transmitted by
the MEP. The non-existence of this leaf means
that no defects are to be reported.";
}
description
"List of 802.1ag CFM attributes.";
}
list y-1731 {
if-feature "y-1731";
key "maid";
leaf maid {
type string;
mandatory true;
description
"Identifies an MA.";
}
leaf mep-id {
type uint32;
description
"Local MEP ID. The non-existence of this leaf
description
"CCM interval. By default, the CCM interval is
10,000 milliseconds (10 seconds).";
}
leaf ccm-holdtime {
type uint32;
units "milliseconds";
default "35000";
description
"CCM hold time. By default, the CCM hold time
is 3.5 times the CCM interval.";
}
leaf alarm-priority-defect {
type identityref {
base fault-alarm-defect-type;
}
default "remote-invalid-ccm";
description
"The lowest-priority defect that is
allowed to generate a fault alarm. By default,
'fault-alarm-defect-type' is set to
'remote-invalid-ccm'. The non-existence of
this leaf means that no defects are
to be reported.";
}
leaf ccm-p-bits-pri {
type ccm-priority-type;
description
"The priority parameter for CCMs transmitted by
the MEP. The non-existence of this leaf means
that no defects are to be reported.";
}
description
"List of 802.1ag CFM attributes.";
}
list y-1731 {
if-feature "y-1731";
key "maid";
leaf maid {
type string;
mandatory true;
description
"Identifies an MA.";
}
leaf mep-id {
type uint32;
description
"Local MEP ID. The non-existence of this leaf
means that no measurements are to be reported.";
}
leaf type {
type identityref {
base pm-type;
}
default "delay";
description
"Performance-monitoring types. By default, the
performance-monitoring type is set to 'delay'.
The non-existence of this leaf means that no
measurements are to be reported.";
}
leaf remote-mep-id {
type uint32;
description
"Remote MEP ID. The non-existence of this
leaf means that no measurements are to be
reported.";
}
leaf message-period {
type uint32;
units "milliseconds";
default "10000";
description
"Defines the interval between Y.1731
performance-monitoring messages. The message
period is expressed in milliseconds.";
}
leaf measurement-interval {
type uint32;
units "seconds";
description
"Specifies the measurement interval for
statistics. The measurement interval is
expressed in seconds.";
}
leaf cos {
type uint32;
description
"CoS. The non-existence of this leaf means that
no measurements are to be reported.";
}
leaf loss-measurement {
type boolean;
default "false";
description
"Indicates whether or not to enable loss
means that no measurements are to be reported.";
}
leaf type {
type identityref {
base pm-type;
}
default "delay";
description
"Performance-monitoring types. By default, the
performance-monitoring type is set to 'delay'.
The non-existence of this leaf means that no
measurements are to be reported.";
}
leaf remote-mep-id {
type uint32;
description
"Remote MEP ID. The non-existence of this
leaf means that no measurements are to be
reported.";
}
leaf message-period {
type uint32;
units "milliseconds";
default "10000";
description
"Defines the interval between Y.1731
performance-monitoring messages. The message
period is expressed in milliseconds.";
}
leaf measurement-interval {
type uint32;
units "seconds";
description
"Specifies the measurement interval for
statistics. The measurement interval is
expressed in seconds.";
}
leaf cos {
type uint32;
description
"CoS. The non-existence of this leaf means that
no measurements are to be reported.";
}
leaf loss-measurement {
type boolean;
default "false";
description
"Indicates whether or not to enable loss
measurement. By default, loss
measurement is not enabled.";
}
leaf synthetic-loss-measurement {
type boolean;
default "false";
description
"Indicates whether or not to enable synthetic loss
measurement. By default, synthetic loss
measurement is not enabled.";
}
container delay-measurement {
leaf enable-dm {
type boolean;
default "false";
description
"Indicates whether or not to enable delay
measurement. By default, delay measurement
is not enabled.";
}
leaf two-way {
type boolean;
default "false";
description
"Indicates whether delay measurement is two-way
('true') or one-way ('false'). By default,
one-way measurement is enabled.";
}
description
"Container for delay measurement.";
}
leaf frame-size {
type uint32;
units "bytes";
description
"Frame size. The non-existence of this leaf
means that no measurements are to be reported.";
}
leaf session-type {
type enumeration {
enum proactive {
description
"Proactive mode.";
}
enum on-demand {
description
"On-demand mode.";
}
measurement. By default, loss
measurement is not enabled.";
}
leaf synthetic-loss-measurement {
type boolean;
default "false";
description
"Indicates whether or not to enable synthetic loss
measurement. By default, synthetic loss
measurement is not enabled.";
}
container delay-measurement {
leaf enable-dm {
type boolean;
default "false";
description
"Indicates whether or not to enable delay
measurement. By default, delay measurement
is not enabled.";
}
leaf two-way {
type boolean;
default "false";
description
"Indicates whether delay measurement is two-way
('true') or one-way ('false'). By default,
one-way measurement is enabled.";
}
description
"Container for delay measurement.";
}
leaf frame-size {
type uint32;
units "bytes";
description
"Frame size. The non-existence of this leaf
means that no measurements are to be reported.";
}
leaf session-type {
type enumeration {
enum proactive {
description
"Proactive mode.";
}
enum on-demand {
description
"On-demand mode.";
}
}
default "on-demand";
description
"Session type. By default, the session type
is 'on-demand'. The non-existence of this
leaf means that no measurements are to be
reported.";
}
description
"List of configured Y-1731 instances.";
}
description
"Container for Ethernet Service OAM.";
}
description
"Container for connection requirements.";
}
container availability {
leaf access-priority {
type uint32;
default "100";
description
"Access priority. The higher the access-priority
value, the higher the preference will be for the
access in question.";
}
choice redundancy-mode {
case single-active {
leaf single-active {
type empty;
description
"Single-active mode.";
}
description
"In single-active mode, only one node forwards
traffic to and from the Ethernet segment.";
}
case all-active {
leaf all-active {
type empty;
description
"All-active mode.";
}
description
"In all-active mode, all nodes can forward
traffic.";
}
description
}
default "on-demand";
description
"Session type. By default, the session type
is 'on-demand'. The non-existence of this
leaf means that no measurements are to be
reported.";
}
description
"List of configured Y-1731 instances.";
}
description
"Container for Ethernet Service OAM.";
}
description
"Container for connection requirements.";
}
container availability {
leaf access-priority {
type uint32;
default "100";
description
"Access priority. The higher the access-priority
value, the higher the preference will be for the
access in question.";
}
choice redundancy-mode {
case single-active {
leaf single-active {
type empty;
description
"Single-active mode.";
}
description
"In single-active mode, only one node forwards
traffic to and from the Ethernet segment.";
}
case all-active {
leaf all-active {
type empty;
description
"All-active mode.";
}
description
"In all-active mode, all nodes can forward
traffic.";
}
description
"Redundancy mode choice.";
}
description
"Container of available optional configurations.";
}
container vpn-attachment {
choice attachment-flavor {
case vpn-id {
leaf vpn-id {
type leafref {
path "/l2vpn-svc/vpn-services/vpn-service/vpn-id";
}
description
"Reference to an L2VPN. Referencing a vpn-id
provides an easy way to attach a particular
logical access to a VPN. In this case,
the 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 L2VPN. 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.";
}
}
case vpn-policy-id {
leaf vpn-policy-id {
type leafref {
path "../../../../vpn-policies/vpn-policy/"
+ "vpn-policy-id";
}
description
"Reference to a VPN policy.";
}
}
mandatory true;
description
"Choice for the VPN attachment flavor.";
}
description
"Defines the VPN attachment of a site.";
}
container service {
"Redundancy mode choice.";
}
description
"Container of available optional configurations.";
}
container vpn-attachment {
choice attachment-flavor {
case vpn-id {
leaf vpn-id {
type leafref {
path "/l2vpn-svc/vpn-services/vpn-service/vpn-id";
}
description
"Reference to an L2VPN. Referencing a vpn-id
provides an easy way to attach a particular
logical access to a VPN. In this case,
the 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 L2VPN. 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.";
}
}
case vpn-policy-id {
leaf vpn-policy-id {
type leafref {
path "../../../../vpn-policies/vpn-policy/"
+ "vpn-policy-id";
}
description
"Reference to a VPN policy.";
}
}
mandatory true;
description
"Choice for the VPN attachment flavor.";
}
description
"Defines the VPN attachment of a site.";
}
container service {
container svc-bandwidth {
if-feature "input-bw";
list bandwidth {
key "direction type";
leaf direction {
type identityref {
base bw-direction;
}
description
"Indicates the bandwidth direction. It can be
the bandwidth download direction from the SP to
the site or the bandwidth upload direction from
the site to the SP.";
}
leaf type {
type identityref {
base bw-type;
}
description
"Bandwidth type. By default, the bandwidth type
is set to 'bw-per-cos'.";
}
leaf cos-id {
when "derived-from-or-self(../type, "
+ "'l2vpn-svc:bw-per-cos')" {
description
"Relevant when the bandwidth type is set to
'bw-per-cos'.";
}
type uint8;
description
"Identifier of the CoS, indicated by DSCP or a
CE-VLAN CoS (802.1p) value in the service frame.
If the bandwidth type is set to 'bw-per-cos',
the CoS ID MUST also be specified.";
}
leaf vpn-id {
when "derived-from-or-self(../type, "
+ "'l2vpn-svc:bw-per-svc')" {
description
"Relevant when the bandwidth type is
set as bandwidth per VPN service.";
}
type svc-id;
description
"Identifies the target VPN. If the bandwidth
type is set as bandwidth per VPN service, the
vpn-id MUST be specified.";
container svc-bandwidth {
if-feature "input-bw";
list bandwidth {
key "direction type";
leaf direction {
type identityref {
base bw-direction;
}
description
"Indicates the bandwidth direction. It can be
the bandwidth download direction from the SP to
the site or the bandwidth upload direction from
the site to the SP.";
}
leaf type {
type identityref {
base bw-type;
}
description
"Bandwidth type. By default, the bandwidth type
is set to 'bw-per-cos'.";
}
leaf cos-id {
when "derived-from-or-self(../type, "
+ "'l2vpn-svc:bw-per-cos')" {
description
"Relevant when the bandwidth type is set to
'bw-per-cos'.";
}
type uint8;
description
"Identifier of the CoS, indicated by DSCP or a
CE-VLAN CoS (802.1p) value in the service frame.
If the bandwidth type is set to 'bw-per-cos',
the CoS ID MUST also be specified.";
}
leaf vpn-id {
when "derived-from-or-self(../type, "
+ "'l2vpn-svc:bw-per-svc')" {
description
"Relevant when the bandwidth type is
set as bandwidth per VPN service.";
}
type svc-id;
description
"Identifies the target VPN. If the bandwidth
type is set as bandwidth per VPN service, the
vpn-id MUST be specified.";
}
leaf cir {
type uint64;
units "bps";
mandatory true;
description
"Committed Information Rate. The maximum number
of bits that a port can receive or send over
an interface in one second.";
}
leaf cbs {
type uint64;
units "bps";
mandatory true;
description
"Committed Burst Size (CBS). Controls the bursty
nature of the traffic. Traffic that does not
use the configured Committed Information Rate
(CIR) accumulates credits until the credits
reach the configured CBS.";
}
leaf eir {
type uint64;
units "bps";
description
"Excess Information Rate (EIR), i.e., excess frame
delivery allowed that is not subject to an SLA.
The traffic rate can be limited by the EIR.";
}
leaf ebs {
type uint64;
units "bps";
description
"Excess Burst Size (EBS). The bandwidth available
for burst traffic from the EBS is subject to the
amount of bandwidth that is accumulated during
periods when traffic allocated by the EIR
policy is not used.";
}
leaf pir {
type uint64;
units "bps";
description
"Peak Information Rate, i.e., maximum frame
delivery allowed. It is equal to or less
than the sum of the CIR and the EIR.";
}
leaf pbs {
}
leaf cir {
type uint64;
units "bps";
mandatory true;
description
"Committed Information Rate. The maximum number
of bits that a port can receive or send over
an interface in one second.";
}
leaf cbs {
type uint64;
units "bps";
mandatory true;
description
"Committed Burst Size (CBS). Controls the bursty
nature of the traffic. Traffic that does not
use the configured Committed Information Rate
(CIR) accumulates credits until the credits
reach the configured CBS.";
}
leaf eir {
type uint64;
units "bps";
description
"Excess Information Rate (EIR), i.e., excess frame
delivery allowed that is not subject to an SLA.
The traffic rate can be limited by the EIR.";
}
leaf ebs {
type uint64;
units "bps";
description
"Excess Burst Size (EBS). The bandwidth available
for burst traffic from the EBS is subject to the
amount of bandwidth that is accumulated during
periods when traffic allocated by the EIR
policy is not used.";
}
leaf pir {
type uint64;
units "bps";
description
"Peak Information Rate, i.e., maximum frame
delivery allowed. It is equal to or less
than the sum of the CIR and the EIR.";
}
leaf pbs {
type uint64;
units "bps";
description
"Peak Burst Size. It is measured in bytes per
second.";
}
description
"List of bandwidth values (e.g., per CoS,
per vpn-id).";
}
description
"From the customer site's perspective, the service
input/output bandwidth of the connection or
download/upload bandwidth from the SP/site
to the site/SP.";
}
leaf svc-mtu {
type uint16;
units "bytes";
mandatory true;
description
"SVC MTU. It is also known as the maximum
transmission unit or maximum frame size. When
a frame is larger than the MTU, it is broken
down, or fragmented, into smaller pieces by
the network protocol to accommodate the MTU
of the network. If CsC is enabled,
the requested svc-mtu leaf will refer to the
MPLS MTU and not to the link MTU.";
}
uses site-service-qos-profile;
uses site-service-mpls;
description
"Container for services.";
}
uses site-bum;
uses site-mac-loop-prevention;
uses site-acl;
container mac-addr-limit {
if-feature "mac-addr-limit";
leaf limit-number {
type uint16;
default "2";
description
"Maximum number of MAC addresses learned from
the subscriber for a single service instance.
The default allowed maximum number of MAC
addresses is 2.";
type uint64;
units "bps";
description
"Peak Burst Size. It is measured in bytes per
second.";
}
description
"List of bandwidth values (e.g., per CoS,
per vpn-id).";
}
description
"From the customer site's perspective, the service
input/output bandwidth of the connection or
download/upload bandwidth from the SP/site
to the site/SP.";
}
leaf svc-mtu {
type uint16;
units "bytes";
mandatory true;
description
"SVC MTU. It is also known as the maximum
transmission unit or maximum frame size. When
a frame is larger than the MTU, it is broken
down, or fragmented, into smaller pieces by
the network protocol to accommodate the MTU
of the network. If CsC is enabled,
the requested svc-mtu leaf will refer to the
MPLS MTU and not to the link MTU.";
}
uses site-service-qos-profile;
uses site-service-mpls;
description
"Container for services.";
}
uses site-bum;
uses site-mac-loop-prevention;
uses site-acl;
container mac-addr-limit {
if-feature "mac-addr-limit";
leaf limit-number {
type uint16;
default "2";
description
"Maximum number of MAC addresses learned from
the subscriber for a single service instance.
The default allowed maximum number of MAC
addresses is 2.";
}
leaf time-interval {
type uint32;
units "seconds";
default "300";
description
"The aging time of the MAC address. By default,
the aging time is set to 300 seconds.";
}
leaf action {
type identityref {
base mac-action;
}
default "warning";
description
"Specifies the action taken when the upper limit is
exceeded: drop the packet, flood the packet, or
simply send a warning log message. By default,
the action is set to 'warning'.";
}
description
"Container of MAC address limit configurations.";
}
description
"List of site network accesses.";
}
description
"Container of port configurations.";
}
description
"List of sites.";
}
description
"Container of site configurations.";
}
description
"Container for L2VPN services.";
}
}
}
leaf time-interval {
type uint32;
units "seconds";
default "300";
description
"The aging time of the MAC address. By default,
the aging time is set to 300 seconds.";
}
leaf action {
type identityref {
base mac-action;
}
default "warning";
description
"Specifies the action taken when the upper limit is
exceeded: drop the packet, flood the packet, or
simply send a warning log message. By default,
the action is set to 'warning'.";
}
description
"Container of MAC address limit configurations.";
}
description
"List of site network accesses.";
}
description
"Container of port configurations.";
}
description
"List of sites.";
}
description
"Container of site configurations.";
}
description
"Container for L2VPN services.";
}
}
<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 [RFC8446].
本文档中指定的模块为数据定义了一个模式，该模式旨在通过网络管理协议（如NETCONF[RFC6241]或restcconf[RFC8040]）进行访问。最低的NETCONF层是安全传输层，实现安全传输的强制要求是安全Shell（SSH）[RFC6242]。最低的RESTCONF层是HTTPS，实现安全传输的强制层是TLS[RFC8446]。
The NETCONF access control model [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
NETCONF访问控制模型[RFC8341]提供了将特定NETCONF或RESTCONF用户的访问限制为所有可用NETCONF或RESTCONF协议操作和内容的预配置子集的方法。
There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). 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:
此模块中定义了许多可写/可创建/可删除的数据节点（即，默认为config true）。在某些网络环境中，这些数据节点可能被视为敏感或易受攻击。对这些数据节点的写入操作（如编辑配置）如果没有适当的保护，可能会对网络操作产生负面影响。这些是子树和数据节点及其敏感性/漏洞：
o /l2vpn-svc/vpn-services/vpn-service
o /l2vpn-svc/vpn-services/vpn-service
The entries in the list above include all of the VPN service configurations to which the customer subscribes and will use to indirectly create or modify the PE and CE device configurations. Unexpected changes to these entries could lead to service disruptions and/or network misbehavior.
上面列表中的条目包括客户订阅的所有VPN服务配置，并将用于间接创建或修改PE和CE设备配置。对这些条目的意外更改可能导致服务中断和/或网络错误行为。
o /l2vpn-svc/sites/site
o /l2vpn-svc/sites/site
The entries in the list above include the customer site configurations. As noted in the previous paragraph, unexpected changes to these entries could lead to service disruptions 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:
在某些网络环境中，此模块中的某些可读数据节点可能被视为敏感或易受攻击。因此，控制对这些数据节点的读取访问（例如，通过get、get config或通知）非常重要。这些是子树和数据节点及其敏感性/漏洞：
o /l2vpn-svc/vpn-services/vpn-service
o /l2vpn-svc/vpn-services/vpn-service
o /l2vpn-svc/sites/site
o /l2vpn-svc/sites/site
The entries in the lists above include customer-proprietary or confidential information, e.g., customer name, site location, services to which the customer subscribes.
上述列表中的条目包括客户专有或机密信息，例如客户名称、网站位置、客户订阅的服务。
When an SP collaborates with multiple customers, it has to ensure that a given customer can only view and modify its (the customer's) own service information.
当SP与多个客户协作时，它必须确保给定客户只能查看和修改其（客户）自己的服务信息。
The data model defines some security parameters that can be extended via augmentation as part of the customer service request; those parameters are described in Sections 5.12 and 5.13.
数据模型定义了一些安全参数，这些参数可以作为客户服务请求的一部分通过扩充进行扩展；第5.12节和第5.13节中描述了这些参数。
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-l2vpn-svc
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace
URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace
IANA has assigned a new YANG module name in the "YANG Module Names" registry [RFC6020].
IANA已在“YANG模块名称”注册表[RFC6020]中分配了一个新的YANG模块名称。
name: ietf-l2vpn-svc
namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc
prefix: l2vpn-svc
reference: RFC 8466
name: ietf-l2vpn-svc
namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc
prefix: l2vpn-svc
reference: RFC 8466
[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>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688]Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，DOI 10.17487/RFC3688，2004年1月<https://www.rfc-editor.org/info/rfc3688>.
[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虚拟专用网络（VPN）”，RFC 4364，DOI 10.17487/RFC4364，2006年2月<https://www.rfc-editor.org/info/rfc4364>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>.
[RFC4761]Kompella，K.，Ed.和Y.Rekhter，Ed.，“使用BGP进行自动发现和信令的虚拟专用LAN服务（VPLS）”，RFC 4761，DOI 10.17487/RFC4761，2007年1月<https://www.rfc-editor.org/info/rfc4761>.
[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-网络配置协议的数据建模语言（NETCONF）”，RFC 6020，DOI 10.17487/RFC6020，2010年10月<https://www.rfc-editor.org/info/rfc6020>.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, DOI 10.17487/RFC6073, January 2011, <https://www.rfc-editor.org/info/rfc6073>.
[RFC6073]Martini，L.，Metz，C.，Nadeau，T.，Bocci，M.和M.Aissaoui，“分段伪线”，RFC 6073，DOI 10.17487/RFC6073，2011年1月<https://www.rfc-editor.org/info/rfc6073>.
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011, <https://www.rfc-editor.org/info/rfc6074>.
[RFC6074]Rosen，E.，Davie，B.，Radoaca，V.，和W.Luo，“第二层虚拟专用网络（L2VPN）中的资源调配、自动发现和信令”，RFC 6074，DOI 10.17487/RFC6074，2011年1月<https://www.rfc-editor.org/info/rfc6074>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.
[RFC6242]Wasserman，M.“在安全外壳上使用NETCONF协议（SSH）”，RFC 6242，DOI 10.17487/RFC6242，2011年6月<https://www.rfc-editor.org/info/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC6991]Schoenwaeld，J.，Ed.，“常见杨数据类型”，RFC 6991，DOI 10.17487/RFC69911913年7月<https://www.rfc-editor.org/info/rfc6991>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7432]Sajassi，A.，Ed.，Aggarwal，R.，Bitar，N.，Isaac，A.，Uttaro，J.，Drake，J.，和W.Henderickx，“基于BGP MPLS的以太网VPN”，RFC 7432，DOI 10.17487/RFC7432，2015年2月<https://www.rfc-editor.org/info/rfc7432>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950]Bjorklund，M.，Ed.“YANG 1.1数据建模语言”，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>.
[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>.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. Rabadan, "Virtual Private Wire Service Support in Ethernet VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, <https://www.rfc-editor.org/info/rfc8214>.
[RFC8214]Boutros，S.，Sajassi，A.，Salam，S.，Drake，J.，和J.Rabadan，“以太网VPN中的虚拟专用线服务支持”，RFC 8214，DOI 10.17487/RFC8214，2017年8月<https://www.rfc-editor.org/info/rfc8214>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.
[RFC8341]Bierman，A.和M.Bjorklund，“网络配置访问控制模型”，STD 91，RFC 8341，DOI 10.17487/RFC8341，2018年3月<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.
[RFC8342]Bjorklund，M.，Schoenwaeld，J.，Shafer，P.，Watsen，K.，和R.Wilton，“网络管理数据存储体系结构（NMDA）”，RFC 8342，DOI 10.17487/RFC8342，2018年3月<https://www.rfc-editor.org/info/rfc8342>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446]Rescorla，E.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126>.
[W3C.REC-xml-20081126]Bray，T.，Paoli，J.，Sperberg McQueen，M.，Maler，E.，和F.Yergeau，“可扩展标记语言（xml）1.0（第五版）”，万维网联盟建议REC-xml-20081126，2008年11月<https://www.w3.org/TR/2008/REC-xml-20081126>.
[EVPN-YANG] Brissette, P., Ed., Shah, H., Ed., Chen, I., Ed., Hussain, I., Ed., Tiruveedhula, K., Ed., and J. Rabadan, Ed., "Yang Data Model for EVPN", Work in Progress, draft-ietf-bess-evpn-yang-05, February 2018.
[EVPN-YANG]Brissette，P.，Ed.，Shah，H.，Ed.，Chen，I.，Ed.，Hussain，I.，Ed.，Tiruveedhula，K.，Ed.，和J.Rabadan，Ed.，“EVPN的YANG数据模型”，正在进行的工作，草案-ietf-bess-EVPN-YANG-05，2018年2月。
[IEEE-802-1ag] IEEE, "802.1ag - 2007 - IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management", DOI 10.1109/IEEESTD.2007.4431836.
[IEEE-802-1ag]IEEE，“802.1ag-2007-局域网和城域网IEEE标准-虚拟桥接局域网修改件5：连接故障管理”，DOI 10.1109/IEEESTD.2007.4431836。
[IEEE-802-1D] IEEE, "802.1D-2004 - IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges", DOI 10.1109/IEEESTD.2004.94569.
[IEEE-802-1D]IEEE，“802.1D-2004-局域网和城域网IEEE标准：媒体访问控制（MAC）网桥”，DOI 10.1109/IEEESTD.2004.94569。
[IEEE-802-1Q] IEEE, "802.1Q - 2014 - IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks", DOI 10.1109/IEEESTD.2014.6991462.
[IEEE-802-1Q]IEEE，“802.1Q-2014-局域网和城域网IEEE标准——网桥和桥接网络”，DOI 10.1109/IEEESTD.2014.6991462。
[IEEE-802-3ah] IEEE, "802.3ah - 2004 - IEEE Standard for Information technology-- Local and metropolitan area networks-- Part 3: CSMA/CD Access Method and Physical Layer Specifications Amendment: Media Access Control Parameters, Physical Layers, and Management Parameters for Subscriber Access Networks", DOI 10.1109/IEEESTD.2004.94617.
[IEEE-802-3ah]IEEE，“802.3ah-2004-IEEE信息技术标准-局域网和城域网-第3部分：CSMA/CD访问方法和物理层规范修订：用户访问网络的媒体访问控制参数、物理层和管理参数”，DOI 10.1109/IEEESTD.2004.94617。
[ITU-T-Y-1731] International Telecommunication Union, "Operations, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks", ITU-T Recommendation Y.1731, August 2015, <https://www.itu.int/rec/T-REC-Y.1731/en>.
[ITU-T-Y-1731]国际电信联盟，“基于以太网的网络的操作、管理和维护（OAM）功能和机制”，ITU-T建议Y.17312015年8月<https://www.itu.int/rec/T-REC-Y.1731/en>.
[MEF-6] Metro Ethernet Forum, "Ethernet Services Definitions - Phase 2", April 2008, <https://mef.net/PDF_Documents/ technical-specifications/MEF6-1.pdf>.
[MEF-6]城域以太网论坛，“以太网服务定义-第2阶段”，2008年4月<https://mef.net/PDF_Documents/ 技术规范/MEF6-1.pdf>。
[MPLS-L2VPN-YANG] Shah, H., Ed., Brissette, P., Ed., Chen, I., Ed., Hussain, I., Ed., Wen, B., Ed., and K. Tiruveedhula, Ed., "YANG Data Model for MPLS-based L2VPN", Work in Progress, draft-ietf-bess-l2vpn-yang-08, February 2018.
[MPLS-L2VPN-YANG]Shah，H.，Ed.，Brissette，P.，Ed.，Chen，I.，Ed.，Hussain，I.，Ed.，Wen，B.，Ed.，和K.Tiruveedhula，Ed.，“基于MPLS的L2VPN的YANG数据模型”，正在进行的工作，草案-ietf-bess-L2VPN-YANG-082018年2月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, DOI 10.17487/RFC4119, December 2005, <https://www.rfc-editor.org/info/rfc4119>.
[RFC4119]Peterson，J.，“基于状态的GeoDriv定位对象格式”，RFC 4119，DOI 10.17487/RFC4119，2005年12月<https://www.rfc-editor.org/info/rfc4119>.
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, <https://www.rfc-editor.org/info/rfc6624>.
[RFC6624]Kompella，K.，Kothari，B.，和R.Cherukuri，“使用BGP进行自动发现和信令的第2层虚拟专用网络”，RFC 6624DOI 10.17487/RFC66242012年5月<https://www.rfc-editor.org/info/rfc6624>.
[RFC7130] Bhatia, M., Ed., Chen, M., Ed., Boutros, S., Ed., Binderberger, M., Ed., and J. Haas, Ed., "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces", RFC 7130, DOI 10.17487/RFC7130, February 2014, <https://www.rfc-editor.org/info/rfc7130>.
[RFC7130]Bhatia，M.，Ed.，Chen，M.，Ed.，Boutros，S.，Ed.，Binderberger，M.，Ed.，和J.Haas，Ed.，“链路聚合组（LAG）接口上的双向转发检测（BFD）”，RFC 7130，DOI 10.17487/RFC7130，2014年2月<https://www.rfc-editor.org/info/rfc7130>.
[RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., Henderickx, W., and A. Isaac, "Requirements for Ethernet VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014, <https://www.rfc-editor.org/info/rfc7209>.
[RFC7209]Sajassi，A.，Aggarwal，R.，Uttaro，J.，Bitar，N.，Henderickx，W.，和A.Isaac，“以太网VPN（EVPN）的要求”，RFC 7209，DOI 10.17487/RFC7209，2014年5月<https://www.rfc-editor.org/info/rfc7209>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>.
[RFC7348]Mahalingam，M.，Dutt，D.，Duda，K.，Agarwal，P.，Kreeger，L.，Sridhar，T.，Bursell，M.，和C.Wright，“虚拟可扩展局域网（VXLAN）：在第3层网络上覆盖虚拟化第2层网络的框架”，RFC 7348，DOI 10.17487/RFC7348，2014年8月<https://www.rfc-editor.org/info/rfc7348>.
[RFC7436] Shah, H., Rosen, E., Le Faucheur, F., and G. Heron, "IP-Only LAN Service (IPLS)", RFC 7436, DOI 10.17487/RFC7436, January 2015, <https://www.rfc-editor.org/info/rfc7436>.
[RFC7436]Shah，H.，Rosen，E.，Le Faucheur，F.，和G.Heron，“仅IP局域网服务（IPLS）”，RFC 7436，DOI 10.17487/RFC74362015年1月<https://www.rfc-editor.org/info/rfc7436>.
[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module Classification", RFC 8199, DOI 10.17487/RFC8199, July 2017, <https://www.rfc-editor.org/info/rfc8199>.
[RFC8199]Bogdanovic，D.，Claise，B.和C.Moberg，“阳模块分类”，RFC 8199，DOI 10.17487/RFC81992017年7月<https://www.rfc-editor.org/info/rfc8199>.
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018, <https://www.rfc-editor.org/info/rfc8299>.
[RFC8299]Wu，Q.，Ed.，Litkowski，S.，Tomotaki，L.，和K.Ogaki，“L3VPN服务交付的YANG数据模型”，RFC 8299，DOI 10.17487/RFC8299，2018年1月<https://www.rfc-editor.org/info/rfc8299>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, <https://www.rfc-editor.org/info/rfc8309>.
[RFC8309]Wu，Q.，Liu，W.，和A.Farrel，“解释服务模型”，RFC 8309，DOI 10.17487/RFC8309，2018年1月<https://www.rfc-editor.org/info/rfc8309>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.
[RFC8340]Bjorklund，M.和L.Berger，编辑，“杨树图”，BCP 215，RFC 8340，DOI 10.17487/RFC8340，2018年3月<https://www.rfc-editor.org/info/rfc8340>.
Acknowledgements
致谢
Thanks to Qin Wu and Adrian Farrel for facilitating work on the initial draft revisions of this document. Thanks to Zonghe Huang, Wei Deng, and Xiaoling Song for their review of this document.
感谢秦武和阿德里安·法雷尔为本文件初稿修订工作提供便利。感谢黄宗和、邓伟和宋晓玲对本文件的审阅。
Special thanks to Jan Lindblad for his careful review of the YANG.
特别感谢Jan Lindblad对杨的仔细回顾。
This document has drawn on the work of the L3SM Working Group as provided in [RFC8299].
本文件借鉴了[RFC8299]中规定的L3SM工作组的工作。
Authors' Addresses
作者地址
Bin Wen Comcast
文彬康卡斯特
Email: bin_wen@comcast.com
Email: bin_wen@comcast.com
Giuseppe Fioccola (editor) Telecom Italia
朱塞佩·菲奥科拉（编辑）意大利电信
Email: giuseppe.fioccola@tim.it
Email: giuseppe.fioccola@tim.it
Chongfeng Xie China Telecom
谢崇峰中国电信
Email: xiechf.bri@chinatelecom.cn
Email: xiechf.bri@chinatelecom.cn
Luay Jalil Verizon
威瑞森公司
Email: luay.jalil@verizon.com
Email: luay.jalil@verizon.com