< draft-ietf-l2sm-l2vpn-service-model-09.txt | draft-ietf-l2sm-l2vpn-service-model-10.txt > | |||
---|---|---|---|---|
L2SM Working Group B. Wen | L2SM Working Group B. Wen | |||
Internet-Draft Comcast | Internet-Draft Comcast | |||
Intended status: Standards Track G. Fioccola, Ed. | Intended status: Standards Track G. Fioccola, Ed. | |||
Expires: October 5, 2018 Telecom Italia | Expires: October 13, 2018 Telecom Italia | |||
C. Xie | C. Xie | |||
China Telecom | China Telecom | |||
L. Jalil | L. Jalil | |||
Verizon | Verizon | |||
April 3, 2018 | April 11, 2018 | |||
A YANG Data Model for L2VPN Service Delivery | A YANG Data Model for L2VPN Service Delivery | |||
draft-ietf-l2sm-l2vpn-service-model-09 | draft-ietf-l2sm-l2vpn-service-model-10 | |||
Abstract | Abstract | |||
This document defines a YANG data model that can be used to configure | This document defines a YANG data model that can be used to configure | |||
a Layer 2 Provider Provisioned VPN service. | a Layer 2 Provider Provisioned VPN service. It is up to a management | |||
system to take this as an input and generate specific configurations | ||||
This model is intended to be instantiated at management system to | models to configure the different network elements to deliver the | |||
deliver the overall service. This model is not a configuration model | service. How configuration of network elements is done is out of | |||
to be used directly on network elements, but provides an abstracted | scope of the document. | |||
view of the Layer 2 VPN service configuration components. It is up | ||||
to a management system to take this as an input and generate specific | ||||
configurations models to configure the different network elements to | ||||
deliver the service. How configuration of network elements is done | ||||
is out of scope of the document. | ||||
The YANG model in this document includes support for point-to-point | The YANG model in this document includes support for point-to-point | |||
Virtual Private Wire Services (VPWS) and multipoint Virtual Private | Virtual Private Wire Services (VPWS) and multipoint Virtual Private | |||
LAN services (VPLS) that use Pseudowires signaled using the Label | LAN services (VPLS) that use Pseudowires signaled using the Label | |||
Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as | Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as | |||
described in RFC4761 and RFC6624. | described in RFC4761 and RFC6624. | |||
The YANG model in this document conforms to the Network Management | The YANG model in this document conforms to the Network Management | |||
Datastore Architecture defined in I-D.ietf-netmod-revised-datastores. | Datastore Architecture defined in RFC8342. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on October 5, 2018. | This Internet-Draft will expire on October 13, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.1.1. Requirements Language . . . . . . . . . . . . . . . . 5 | 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 5 | |||
1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 5 | 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. The Layer 2 VPN Service Model . . . . . . . . . . . . . . . . 7 | 3. The Layer 2 VPN Service Model . . . . . . . . . . . . . . . . 6 | |||
3.1. Layer 2 VPN Service Types . . . . . . . . . . . . . . . . 7 | 3.1. Layer 2 VPN Service Types . . . . . . . . . . . . . . . . 7 | |||
3.2. Layer 2 VPN Physical Network Topology . . . . . . . . . . 7 | 3.2. Layer 2 VPN Physical Network Topology . . . . . . . . . . 7 | |||
4. Service Data Model Usage . . . . . . . . . . . . . . . . . . 9 | 4. Service Data Model Usage . . . . . . . . . . . . . . . . . . 9 | |||
5. Design of the Data Model . . . . . . . . . . . . . . . . . . 10 | 5. Design of the Data Model . . . . . . . . . . . . . . . . . . 11 | |||
5.1. Features and Augmentation . . . . . . . . . . . . . . . . 20 | 5.1. Features and Augmentation . . . . . . . . . . . . . . . . 20 | |||
5.2. VPN Service Overview . . . . . . . . . . . . . . . . . . 20 | 5.2. VPN Service Overview . . . . . . . . . . . . . . . . . . 20 | |||
5.2.1. VPN Service Type . . . . . . . . . . . . . . . . . . 21 | 5.2.1. VPN Service Type . . . . . . . . . . . . . . . . . . 21 | |||
5.2.2. VPN Service Topology . . . . . . . . . . . . . . . . 21 | 5.2.2. VPN Service Topology . . . . . . . . . . . . . . . . 22 | |||
5.2.2.1. Route Target Allocation . . . . . . . . . . . . . 22 | 5.2.2.1. Route Target Allocation . . . . . . . . . . . . . 22 | |||
5.2.2.2. Any-to-Any . . . . . . . . . . . . . . . . . . . 22 | 5.2.2.2. Any-to-Any . . . . . . . . . . . . . . . . . . . 22 | |||
5.2.2.3. Hub-and-Spoke . . . . . . . . . . . . . . . . . . 22 | 5.2.2.3. Hub-and-Spoke . . . . . . . . . . . . . . . . . . 22 | |||
5.2.2.4. Hub-and-Spoke-Disjoint . . . . . . . . . . . . . 23 | 5.2.2.4. Hub-and-Spoke-Disjoint . . . . . . . . . . . . . 23 | |||
5.2.3. Cloud Access . . . . . . . . . . . . . . . . . . . . 23 | 5.2.3. Cloud Access . . . . . . . . . . . . . . . . . . . . 24 | |||
5.2.4. Extranet VPNs . . . . . . . . . . . . . . . . . . . . 26 | 5.2.4. Extranet VPNs . . . . . . . . . . . . . . . . . . . . 26 | |||
5.2.5. Frame Delivery Service . . . . . . . . . . . . . . . 27 | 5.2.5. Frame Delivery Service . . . . . . . . . . . . . . . 28 | |||
5.3. Site Overview . . . . . . . . . . . . . . . . . . . . . . 28 | 5.3. Site Overview . . . . . . . . . . . . . . . . . . . . . . 29 | |||
5.3.1. Devices and Locations . . . . . . . . . . . . . . . . 30 | 5.3.1. Devices and Locations . . . . . . . . . . . . . . . . 30 | |||
5.3.2. Site Network Accesses . . . . . . . . . . . . . . . . 31 | 5.3.2. Site Network Accesses . . . . . . . . . . . . . . . . 31 | |||
5.3.2.1. Bearer . . . . . . . . . . . . . . . . . . . . . 31 | 5.3.2.1. Bearer . . . . . . . . . . . . . . . . . . . . . 32 | |||
5.3.2.2. Connection . . . . . . . . . . . . . . . . . . . 32 | 5.3.2.2. Connection . . . . . . . . . . . . . . . . . . . 32 | |||
5.4. Site Role . . . . . . . . . . . . . . . . . . . . . . . . 36 | 5.4. Site Role . . . . . . . . . . . . . . . . . . . . . . . . 37 | |||
5.5. Site Belonging to Multiple VPNs . . . . . . . . . . . . . 37 | 5.5. Site Belonging to Multiple VPNs . . . . . . . . . . . . . 37 | |||
5.5.1. Site VPN Flavor . . . . . . . . . . . . . . . . . . . 37 | 5.5.1. Site VPN Flavor . . . . . . . . . . . . . . . . . . . 37 | |||
5.5.1.1. Single VPN Attachment: site-vpn-flavor-single . . 37 | 5.5.1.1. Single VPN Attachment: site-vpn-flavor-single . . 37 | |||
5.5.1.2. MultiVPN Attachment: site-vpn-flavor-multi . . . 37 | 5.5.1.2. MultiVPN Attachment: site-vpn-flavor-multi . . . 38 | |||
5.5.1.3. NNI: site-vpn-flavor-nni . . . . . . . . . . . . 38 | 5.5.1.3. NNI: site-vpn-flavor-nni . . . . . . . . . . . . 38 | |||
5.5.1.4. E2E: site-vpn-flavor-e2e . . . . . . . . . . . . 39 | 5.5.1.4. E2E: site-vpn-flavor-e2e . . . . . . . . . . . . 39 | |||
5.5.2. Attaching a Site to a VPN . . . . . . . . . . . . . . 40 | 5.5.2. Attaching a Site to a VPN . . . . . . . . . . . . . . 40 | |||
5.5.2.1. Referencing a VPN . . . . . . . . . . . . . . . . 40 | 5.5.2.1. Referencing a VPN . . . . . . . . . . . . . . . . 40 | |||
5.5.2.2. VPN Policy . . . . . . . . . . . . . . . . . . . 42 | 5.5.2.2. VPN Policy . . . . . . . . . . . . . . . . . . . 42 | |||
5.6. Deciding Where to Connect the Site . . . . . . . . . . . 47 | 5.6. Deciding Where to Connect the Site . . . . . . . . . . . 47 | |||
5.6.1. Constraint: Device . . . . . . . . . . . . . . . . . 47 | 5.6.1. Constraint: Device . . . . . . . . . . . . . . . . . 47 | |||
5.6.2. Constraint/Parameter: Site Location . . . . . . . . . 48 | 5.6.2. Constraint/Parameter: Site Location . . . . . . . . . 48 | |||
5.6.3. Constraint/Parameter: Access Type . . . . . . . . . . 49 | 5.6.3. Constraint/Parameter: Access Type . . . . . . . . . . 49 | |||
5.6.4. Constraint: Access Diversity . . . . . . . . . . . . 50 | 5.6.4. Constraint: Access Diversity . . . . . . . . . . . . 50 | |||
skipping to change at page 3, line 46 ¶ | skipping to change at page 3, line 39 ¶ | |||
5.16. Defining NNIs and Inter-AS support . . . . . . . . . . . 61 | 5.16. Defining NNIs and Inter-AS support . . . . . . . . . . . 61 | |||
5.16.1. Defining an NNI with the Option A Flavor . . . . . . 63 | 5.16.1. Defining an NNI with the Option A Flavor . . . . . . 63 | |||
5.16.2. Defining an NNI with the Option B Flavor . . . . . . 66 | 5.16.2. Defining an NNI with the Option B Flavor . . . . . . 66 | |||
5.16.3. Defining an NNI with the Option C Flavor . . . . . . 68 | 5.16.3. Defining an NNI with the Option C Flavor . . . . . . 68 | |||
5.17. Applicability of L2SM model in Inter-Provider and Inter- | 5.17. Applicability of L2SM model in Inter-Provider and Inter- | |||
Domain Orchestration . . . . . . . . . . . . . . . . . . 70 | Domain Orchestration . . . . . . . . . . . . . . . . . . 70 | |||
6. Interaction with Other YANG Modules . . . . . . . . . . . . . 71 | 6. Interaction with Other YANG Modules . . . . . . . . . . . . . 71 | |||
7. Service Model Usage Example . . . . . . . . . . . . . . . . . 72 | 7. Service Model Usage Example . . . . . . . . . . . . . . . . . 72 | |||
8. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 78 | 8. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 78 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 147 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 147 | |||
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 149 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 148 | |||
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 149 | 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 149 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 149 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 149 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 149 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 149 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 151 | 12.2. Informative References . . . . . . . . . . . . . . . . . 151 | |||
Appendix A. Changes Log . . . . . . . . . . . . . . . . . . . . 152 | Appendix A. Changes Log . . . . . . . . . . . . . . . . . . . . 153 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 156 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 156 | |||
1. Introduction | 1. Introduction | |||
This document defines a YANG data model for Layer 2 VPN (L2VPN) | This document defines a YANG data model for Layer 2 VPN (L2VPN) | |||
service. This model is intended to be instantiated at management | service. This model defines service configuration elements that can | |||
system to allow a user to request the service from a service | be used in communication protocols between customers and network | |||
provider. This model provides an abstracted view of the L2VPN | operators. Those elements can also be used as input to automated | |||
service configuration components. The management system can take | control and configuration applications and and generate specific | |||
this as an input and generate specific configurations models to | configurations models to configure the different network elements to | |||
configure the different network elements to deliver the service. The | deliver the service. How configuration of network elements is done | |||
model defines service configuration elements that can be used in | is out of scope of the document. | |||
communication protocols between customers and network operators.How | ||||
configuration of network elements is done is out of scope of the | ||||
document. | ||||
The YANG model in this document includes support for point-to-point | ||||
Virtual Private Wire Services (VPWS) and multipoint Virtual Private | ||||
LAN services (VPLS) that use Pseudowires signaled using the Label | ||||
Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as | ||||
described in [RFC4761] and [RFC6624]. | ||||
This version of L2VPN service model supports the Network Management | ||||
Datastore Architecture (NMDA) [I-D.ietf-netmod-revised-datastores]. | ||||
Further discussion of the way that services are modeled in YANG and | Further discussion of the way that services are modeled in YANG and | |||
the relationship between "customer service models" like the one | the relationship between "customer service models" like the one | |||
described in this document and configuration models can be found in | described in this document and configuration models can be found in | |||
[RFC8309] and [RFC8199]. Section 4 and Section 6 also provide more | [RFC8309] and [RFC8199]. Section 4 and Section 6 also provide more | |||
information of how this service model could be used and how it fits | information of how this service model could be used and how it fits | |||
into the overall modeling architecture. | into the overall modeling architecture. | |||
The YANG model in this document includes support for point-to-point | ||||
Virtual Private Wire Services (VPWS) and multipoint Virtual Private | ||||
LAN services (VPLS) 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]. | ||||
1.1. Terminology | 1.1. Terminology | |||
The following terms are defined in [RFC6241] and are not redefined | The following terms are defined in [RFC6241] and are not redefined | |||
here: | here: | |||
o client | o client | |||
o configuration data | o configuration data | |||
o server | o server | |||
skipping to change at page 5, line 25 ¶ | skipping to change at page 5, line 16 ¶ | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
1.2. Tree diagram | 1.2. Tree diagram | |||
Tree diagrams used in this document follow the notation defined in | Tree diagrams used in this document follow the notation defined in | |||
[I-D.ietf-netmod-yang-tree-diagrams]. | [RFC8340]. | |||
2. Definitions | 2. Definitions | |||
This document uses the following terms: | This document uses the following terms: | |||
Service Provider (SP): The organization (usually a commercial | Service Provider (SP): The organization (usually a commercial | |||
undertaking) responsible for operating the network that offers VPN | undertaking) responsible for operating the network that offers VPN | |||
services to clients and customers. | services to clients and customers. | |||
Customer Edge (CE) Device: Equipment that is dedicated to a | Customer Edge (CE) Device: Equipment that is dedicated to a | |||
skipping to change at page 6, line 9 ¶ | skipping to change at page 5, line 48 ¶ | |||
by the SP. | by the SP. | |||
Virtual Private LAN Service (VPLS): A VPLS is a provider service | Virtual Private LAN Service (VPLS): A VPLS is a provider service | |||
that emulates the full functionality of a traditional Local Area | that emulates the full functionality of a traditional Local Area | |||
Network (LAN). A VPLS makes it possible to interconnect several | Network (LAN). A VPLS makes it possible to interconnect several | |||
LAN segments over a packet switched network (PSN) and makes the | LAN segments over a packet switched network (PSN) and makes the | |||
remote LAN segments behave as one single LAN. | remote LAN segments behave as one single LAN. | |||
Virtual Private Wire Service (VPWS): A VPWS is a point-to-point | Virtual Private Wire Service (VPWS): A VPWS is a point-to-point | |||
circuit (i.e., link) connecting two CE devices. The link is | circuit (i.e., link) connecting two CE devices. The link is | |||
established as a logical through a packet switched network. The | established as a logical Layer 2 circuit through a packet switched | |||
CE in the customer network is connected to a PE in the provider | network. The CE in the customer network is connected to a PE in | |||
network via an Attachment Circuit (AC): the AC is either a | the provider network via an Attachment Circuit (AC): the AC is | |||
physical or a logical circuit. A VPWS differs from a VPLS in that | either a physical or a logical circuit. A VPWS differs from a | |||
the VPLS is point-to-multipoint, while the VPWS is point-to-point. | VPLS in that the VPLS is point-to-multipoint, while the VPWS is | |||
In some implementations, a set of VPWSs is used to create a multi- | point-to-point. In some implementations, a set of VPWSs is used | |||
site L2VPN network. | to create a multi-site L2VPN network. | |||
Pseudowire(PW): A pseudowire is an emulation of a native service | Pseudowire(PW): A pseudowire is an emulation of a native service | |||
over a packet switched network (PSN). The native service may be | over a packet switched network (PSN). The native service may be | |||
ATM, frame relay, Ethernet, low-rate TDM, or SONET/SDH, while the | ATM, frame relay, Ethernet, low-rate TDM, or SONET/SDH, while the | |||
PSN may be MPLS, IP (either IPv4 or IPv6), or L2TPv3. | PSN may be MPLS, IP (either IPv4 or IPv6), or L2TPv3. | |||
MAC-VRF: A Virtual Routing and Forwarding table for Media Access | MAC-VRF: A Virtual Routing and Forwarding table for Media Access | |||
Control (MAC) addresses on a PE. It is sometime also referred to | Control (MAC) addresses on a PE. It is sometime also referred to | |||
as a Virtual Switching Instance (VSI). | as a Virtual Switching Instance (VSI). | |||
skipping to change at page 6, line 39 ¶ | skipping to change at page 6, line 29 ¶ | |||
NNI: Network to Network Interface. A reference point representing | NNI: Network to Network Interface. A reference point representing | |||
the boundary between two Networks that are operated as separate | the boundary between two Networks that are operated as separate | |||
administrative domains. The two networks may belong to the same | administrative domains. The two networks may belong to the same | |||
provider or to two different providers. | provider or to two different providers. | |||
This document uses the following abbreviations: | This document uses the following abbreviations: | |||
BSS: Business Support System | BSS: Business Support System | |||
B-U-M: Broadcast-UnknownUnicast-Multicast | BUM: Broadcast-UnknownUnicast-Multicast | |||
CoS: Class of Service | CoS: Class of Service | |||
LAG: Link Aggregation Group | LAG: Link Aggregation Group | |||
LLDP: Link Level Discovery Protocol | LLDP: Link Level Discovery Protocol | |||
OAM: Operations, Administration, and Maintenance | OAM: Operations, Administration, and Maintenance | |||
OSS: Operations Support System | OSS: Operations Support System | |||
skipping to change at page 7, line 28 ¶ | skipping to change at page 7, line 19 ¶ | |||
This service model is limited to VPWS and VPLS based VPNs as | This service model is limited to VPWS and VPLS based VPNs as | |||
described in [RFC4761] and [RFC6624], EVPN as described in [RFC7432]. | described in [RFC4761] and [RFC6624], EVPN as described in [RFC7432]. | |||
3.1. Layer 2 VPN Service Types | 3.1. Layer 2 VPN Service Types | |||
From a technology perspective, a set of basic L2VPN service types | From a technology perspective, a set of basic L2VPN service types | |||
include: | include: | |||
o Point-to-point Virtual Private Wire Services (VPWSs) that use LDP- | o Point-to-point Virtual Private Wire Services (VPWSs) that use LDP- | |||
signaled Psedowires or L2TP-signaled Psedowires [RFC6074]; | signaled Pseudowires or L2TP-signaled Pseudowires [RFC6074]; | |||
o Multipoint Virtual Private LAN Services (VPLSs) that use LDP- | o Multipoint Virtual Private LAN Services (VPLSs) that use LDP- | |||
signaled Pseudowires or L2TP-signaled Psedowires [RFC6074]; | signaled Pseudowires or L2TP-signaled Pseudowires [RFC6074]; | |||
o Multipoint Virtual Private LAN Services (VPLSs) that use a Border | o Multipoint Virtual Private LAN Services (VPLSs) that use a Border | |||
Gateway Protocol (BGP) control plane as described in [RFC4761] and | Gateway Protocol (BGP) control plane as described in [RFC4761] and | |||
[RFC6624]; | [RFC6624]; | |||
o IP-Only LAN-Like Services (IPLSs) that are a functional subset of | o IP-Only LAN-Like Services (IPLSs) that are a functional subset of | |||
VPLS services [RFC4664]; | VPLS services [RFC7436]; | |||
o BGP MPLS-based Ethernet VPN Services as described in [RFC7432] and | o BGP MPLS-based Ethernet VPN Services as described in [RFC7432] and | |||
[RFC7209]; | [RFC7209]; | |||
o Ethernet VPN VPWS specified in [RFC8214] and [RFC7432]; | o Ethernet VPN VPWS specified in [RFC8214] and [RFC7432]; | |||
3.2. Layer 2 VPN Physical Network Topology | 3.2. Layer 2 VPN Physical Network Topology | |||
Figure 1 depicts a typical service provider's physical network | Figure 1 depicts a typical service provider's physical network | |||
topology. Most service providers have deployed an IP, MPLS, or | topology. Most service providers have deployed an IP, MPLS, or | |||
Segment Routing (SR) multi-service core infrastructure. Ingress | Segment Routing (SR) multi-service core infrastructure. Ingress | |||
Layer 2 service frames will be mapped to either an Ethernet | Layer 2 service frames will be mapped to either an Ethernet | |||
Pseudowire (PWE) or a VxLAN PE-to-PE tunnel. The details of these | Pseudowire (PWE) or a VXLAN PE-to-PE tunnel. The details of these | |||
tunneling mechanism are at the provider's discretion and not part of | tunneling mechanism are at the provider's discretion and not part of | |||
the L2SM. | the L2SM. | |||
An L2VPN provides end-to-end L2 connectivity over this multi-service | An L2VPN provides end-to-end L2 connectivity over this multi-service | |||
core infrastructure between two or more customer locations or a | core infrastructure between two or more customer locations or a | |||
collection of sites. Attachment Circuits are placed between CE | collection of sites. Attachment Circuits are placed between CE | |||
devices and PE Devices that backhaul layer 2 service frames from the | devices and PE Devices that backhaul layer 2 service frames from the | |||
customer over the access network to the Provider Network or remote | customer over the access network to the Provider Network or remote | |||
Site. The demarcation point (i.e., UNI) between the customer and | Site. The demarcation point (i.e., UNI) between the customer and | |||
service provider can be either placed between Customer nodes and the | service provider can be either placed between Customer nodes and the | |||
Customer Edge Device, or between the Customer Edge Device and the | Customer Edge Device, or between the Customer Edge Device and the | |||
Provider Edge Device. The actual bearer connection between CE and PE | Provider Edge Device. The actual bearer connection between CE and PE | |||
will be described in the L2SM model. | will be described in the L2SM model. | |||
The service provider may also choose a Seamless MPLS approach to | The service provider may also choose a Seamless MPLS approach to | |||
expand the PWE or VxLAN tunnel between sites. | expand the PWE or VXLAN tunnel between sites. | |||
The service provider may leverage multi-protocol BGP to auto-discover | The service provider may leverage multi-protocol BGP to auto-discover | |||
and signal the PWE or VxLAN tunnel end points. | and signal the PWE or VXLAN tunnel end points. | |||
Site A | |Site B | Site A | |Site B | |||
--- ---- | VXLAN/PW | --- | --- ---- | VXLAN/PW | --- | |||
| | | | |<------------------------>| | | | | | | | |<------------------------>| | | | |||
| C +---+ CE | | | | C | | | C +---+ CE | | | | C | | |||
| | | | | --------- | | | | | | | | | --------- | | | | |||
--- ----\ | ( ) | /--- | --- ----\ | ( ) | /--- | |||
\ -|-- ( ) -|-- ---- / | \ -|-- ( ) -|-- ---- / | |||
\| | ( ) | | | |/ | \| | ( ) | | | |/ | |||
| PE +---+ IP/MPLS/SR +---+ PE +---+ CE | | | PE +---+ IP/MPLS/SR +---+ PE +---+ CE | | |||
skipping to change at page 9, line 37 ¶ | skipping to change at page 9, line 32 ¶ | |||
commands for the network elements that deliver/enable the service. | commands for the network elements that deliver/enable the service. | |||
The network elements may be routers, but also servers (like AAA) that | The network elements may be routers, but also servers (like AAA) that | |||
are necessary within the network. | are necessary within the network. | |||
The configuration of network elements may be done using the Command | The configuration of network elements may be done using the Command | |||
Line Interface (CLI), or any other configuration (or "southbound") | Line Interface (CLI), or any other configuration (or "southbound") | |||
interface such as NETCONF [RFC6241] in combination with device- | interface such as NETCONF [RFC6241] in combination with device- | |||
specific and protocol-specific YANG models. | specific and protocol-specific YANG models. | |||
This way of using the service model is illustrated in Figure 3 and | This way of using the service model is illustrated in Figure 3 and | |||
described in more detail in [RFC8309] and [RFC8199]. The usage of | described in more detail in [RFC8309] and [RFC8199]. The split of | |||
this service model is not limited to this example: it can be used by | the orchestration function between a "Service Orchestrator" and a | |||
any component of the management system, but not directly by network | "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. | elements. | |||
The usage and structure of this model should be compared to the Layer | The usage and structure of this model should be compared to the Layer | |||
3 VPN service model defined in [RFC8299]. | 3 VPN service model defined in [RFC8299]. | |||
---------------------------- | ---------------------------- | |||
| Customer Service Requester | | | Customer Service Requester | | |||
---------------------------- | ---------------------------- | |||
| | | | |||
L2VPN | | L2VPN | | |||
skipping to change at page 10, line 45 ¶ | skipping to change at page 10, line 45 ¶ | |||
++++++++ Bearer ++++++++ ++++++++ ++++++++ | ++++++++ Bearer ++++++++ ++++++++ ++++++++ | |||
+ CE A + ----------- + PE A + + PE B + ---- + CE B + | + CE A + ----------- + PE A + + PE B + ---- + CE B + | |||
++++++++ Connection ++++++++ ++++++++ ++++++++ | ++++++++ Connection ++++++++ ++++++++ ++++++++ | |||
Site A Site B | Site A Site B | |||
Figure 3: Reference Architecture for the Use of the L2VPN Service | Figure 3: Reference Architecture for the Use of the L2VPN Service | |||
Model | Model | |||
The MEF Forum (MEF) has also developed an architecture for network | ||||
management and operation, but the work of the MEF embraces all | ||||
aspects of Lifecycle Service Orchestration, including billing, 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 more details in [RFC8309]. | ||||
5. Design of the Data Model | 5. Design of the Data Model | |||
The L2SM model is structured in a way that allows the provider to | The L2SM model is structured in a way that allows the provider to | |||
list multiple circuits of various service types for the same | list multiple circuits of various service types for the same | |||
customer. A circuit represents an end-to-end connection between two | customer. A circuit represents an end-to-end connection between two | |||
or more locations of Customers. | or more locations of Customers. | |||
The YANG module is divided into two main containers: vpn-services and | The YANG module is divided into two main containers: vpn-services and | |||
sites. The vpn-svc container under vpn-services defines global | sites. The vpn-svc container under vpn-services defines global | |||
parameters for the VPN service for a specific customer. | parameters for the VPN service for a specific customer. | |||
skipping to change at page 12, line 23 ¶ | skipping to change at page 12, line 30 ¶ | |||
| | | +--rw delivery-mode? identityref | | | | +--rw delivery-mode? identityref | |||
| | +--rw multicast-gp-port-mapping identityref | | | +--rw multicast-gp-port-mapping identityref | |||
| +--rw extranet-vpns {extranet-vpn}? | | +--rw extranet-vpns {extranet-vpn}? | |||
| | +--rw extranet-vpn* [vpn-id] | | | +--rw extranet-vpn* [vpn-id] | |||
| | +--rw vpn-id svc-id | | | +--rw vpn-id svc-id | |||
| | +--rw local-sites-role? identityref | | | +--rw local-sites-role? identityref | |||
| +--rw ce-vlan-preservation boolean | | +--rw ce-vlan-preservation boolean | |||
| +--rw ce-vlan-cos-preservation boolean | | +--rw ce-vlan-cos-preservation boolean | |||
| +--rw carrierscarrier? boolean {carrierscarrier}? | | +--rw carrierscarrier? boolean {carrierscarrier}? | |||
+--rw sites | +--rw sites | |||
+--rw site* [site-id] | +--rw site* [site-id] | |||
+--rw site-id string | +--rw site-id string | |||
+--rw site-vpn-flavor? identityref | +--rw site-vpn-flavor? identityref | |||
+--rw devices | +--rw devices | |||
| +--rw device* [device-id] | | +--rw device* [device-id] | |||
| +--rw device-id string | | +--rw device-id string | |||
| +--rw location | | +--rw location | |||
| | -> ../../../locations/location/location-id | | | -> ../../../locations/location/location-id | |||
| +--rw management | | +--rw management | |||
| +--rw transport? identityref | | +--rw transport? identityref | |||
| +--rw address? inet:ip-address | | +--rw address? inet:ip-address | |||
+--rw management | +--rw management | |||
| +--rw type identityref | | +--rw type identityref | |||
+--rw locations | +--rw locations | |||
| +--rw location* [location-id] | | +--rw location* [location-id] | |||
| +--rw location-id string | | +--rw location-id string | |||
| +--rw address? string | | +--rw address? string | |||
| +--rw zip-code? string | | +--rw postal-code? string | |||
| +--rw state? string | | +--rw state? string | |||
| +--rw city? string | | +--rw city? string | |||
| +--rw country-code? string | | +--rw country-code? string | |||
+--rw site-diversity {site-diversity}? | +--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 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 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 groups | |||
| | +--rw group* [group-id] | | +--rw group* [group-id] | |||
| | +--rw group-id string | | +--rw group-id string | |||
| +--rw constraints | +--rw vpn-policies | |||
| +--rw constraint* [constraint-type] | | +--rw vpn-policy* [vpn-policy-id] | |||
| +--rw constraint-type identityref | | +--rw vpn-policy-id string | |||
| +--rw target | | +--rw entries* [id] | |||
| +--rw (target-flavor)? | | +--rw id string | |||
| +--:(id) | | +--rw filters | |||
| | +--rw group* [group-id] | | | +--rw filter* [type] | |||
| | +--rw group-id string | | | +--rw type identityref | |||
| +--:(all-accesses) | | | +--rw lan-tag* uint32 {lan-tag}? | |||
| | +--rw all-other-accesses? empty | | +--rw vpn* [vpn-id] | |||
| +--:(all-groups) | | +--rw vpn-id | |||
| +--rw all-other-groups? empty | | | -> /l2vpn-svc/vpn-services/ | |||
+--rw bearer | | | vpn-service/vpn-id | |||
| +--rw requested-type {requested-type}? | | +--rw site-role? identityref | |||
| | +--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 enable? boolean | ||||
| | +--rw uni-loop-prevention? boolean | ||||
| +--rw lag-interfaces {lag-interface}? | ||||
| | +--rw lag-interface* [index] | ||||
| | +--rw index string | ||||
| | +--rw lacp {lacp}? | ||||
| | +--rw enable? boolean | ||||
| | +--rw mode? neg-mode | ||||
| | +--rw speed? uint32 | ||||
| | +--rw mini-link-num? uint32 | ||||
| | +--rw system-priority? uint16 | ||||
| | +--rw micro-bfd {micro-bfd}? | ||||
| | | +--rw enable? 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 enable? 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 synthethic-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 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 {qos}? | |||
| | +--rw classification-policy | | | +--rw classification-policy | |||
| | | +--rw rule* [id] | | | | +--rw rule* [id] | |||
| | | +--rw id string | | | | +--rw id string | |||
| | | +--rw (match-type)? | | | | +--rw (match-type)? | |||
| | | | +--:(match-flow) | | | | | +--:(match-flow) | |||
| | | | | +--rw match-flow | | | | | | +--rw match-flow | |||
| | | | | +--rw dscp? inet:dscp | | | | | | +--rw dscp? inet:dscp | |||
| | | | | +--rw dot1q? uint16 | | | | | | +--rw dot1q? uint16 | |||
| | | | | +--rw pcp? uint8 | | | | | | +--rw pcp? uint8 | |||
| | | | | +--rw src-mac? yang:mac-address | | | | | | +--rw src-mac? yang:mac-address | |||
| | | | | +--rw dst-mac? yang:mac-address | | | | | | +--rw dst-mac? yang:mac-address | |||
| | | | | +--rw color-type? identityref | | | | | | +--rw color-type? identityref | |||
| | | | | +--rw target-sites* | | | | | | +--rw target-sites* | |||
| | | | | | svc-id {target-sites}? | | | | | | | svc-id {target-sites}? | |||
| | | | | +--rw any? empty | | | | | | +--rw any? empty | |||
| | | | | +--rw vpn-id? svc-id | | | | | | +--rw vpn-id? svc-id | |||
| | | | +--:(match-application) | | | | | +--:(match-application) | |||
| | | | +--rw match-application? identityref | | | | | +--rw match-application? identityref | |||
| | | +--rw target-class-id? string | | | | +--rw target-class-id? string | |||
| | +--rw qos-profile | | | +--rw qos-profile | |||
| | +--rw (qos-profile)? | | | +--rw (qos-profile)? | |||
| | +--:(standard) | | | +--:(standard) | |||
| | | +--rw profile? | | | | +--rw profile? | |||
| | | -> /l2vpn-svc/vpn-profiles/ | | | | -> /l2vpn-svc/vpn-profiles/ | |||
| | | valid-provider-identifiers/ | | | | valid-provider-identifiers/ | |||
| | | qos-profile-identifier | | | | qos-profile-identifier | |||
| | +--:(custom) | | | +--:(custom) | |||
| | +--rw classes {qos-custom}? | | | +--rw classes {qos-custom}? | |||
| | +--rw class* [class-id] | | | +--rw class* [class-id] | |||
| | +--rw class-id string | | | +--rw class-id string | |||
| | +--rw direction? identityref | | | +--rw direction? identityref | |||
| | +--rw policing? identityref | | | +--rw policing? identityref | |||
| | +--rw byte-offset? uint16 | | | +--rw byte-offset? uint16 | |||
| | +--rw frame-delay | | | +--rw frame-delay | |||
| | | +--rw (flavor)? | | | | +--rw (flavor)? | |||
| | | +--:(lowest) | | | | +--:(lowest) | |||
| | | | +--rw use-lowest-latency? | | | | | +--rw use-lowest-latency? empty | |||
| | | | empty | ||||
| | | +--:(boundary) | | | | +--:(boundary) | |||
| | | +--rw delay-bound? uint16 | | | | +--rw delay-bound? uint16 | |||
| | +--rw frame-jitter | | | +--rw frame-jitter | |||
| | | +--rw (flavor)? | | | | +--rw (flavor)? | |||
| | | +--:(lowest) | | | | +--:(lowest) | |||
| | | | +--rw use-lowest-jitter? | | | | | +--rw use-lowest-jitter? empty | |||
| | | | empty | ||||
| | | +--:(boundary) | | | | +--:(boundary) | |||
| | | +--rw delay-bound? uint32 | | | | +--rw delay-bound? uint32 | |||
| | +--rw frame-loss | | | +--rw frame-loss | |||
| | | +--rw rate? decimal64 | | | | +--rw rate? decimal64 | |||
| | +--rw bandwidth | | | +--rw bandwidth | |||
| | +--rw guaranteed-bw-percent | | | +--rw guaranteed-bw-percent decimal64 | |||
| | | decimal64 | | | +--rw end-to-end? empty | |||
| | +--rw end-to-end? empty | ||||
| +--rw carrierscarrier {carrierscarrier}? | | +--rw carrierscarrier {carrierscarrier}? | |||
| +--rw signaling-type? identityref | | +--rw signaling-type? identityref | |||
+--rw broadcast-unknown-unicast-multicast {bum}? | +--rw broadcast-unknown-unicast-multicast {bum}? | |||
| +--rw multicast-site-type? enumeration | | +--rw multicast-site-type? enumeration | |||
| +--rw multicast-gp-address-mapping* [id] | | +--rw multicast-gp-address-mapping* [id] | |||
| | +--rw id uint16 | | | +--rw id uint16 | |||
| | +--rw vlan-id uint16 | | | +--rw vlan-id uint16 | |||
| | +--rw mac-gp-address yang:mac-address | | | +--rw mac-gp-address yang:mac-address | |||
| | +--rw port-lag-number? uint32 | | | +--rw port-lag-number? uint32 | |||
| +--rw bum-overall-rate? uint32 | | +--rw bum-overall-rate? uint32 | |||
| +--rw bum-rate-per-type* [type] | | +--rw bum-rate-per-type* [type] | |||
| +--rw type identityref | | +--rw type identityref | |||
| +--rw rate? uint32 | | +--rw rate? uint32 | |||
+--rw mac-loop-prevention {mac-loop-prevention}? | +--rw mac-loop-prevention {mac-loop-prevention}? | |||
| +--rw protection-type? identityref | | +--rw protection-type? identityref | |||
| +--rw frequency? uint32 | | +--rw frequency? uint32 | |||
| +--rw retry-timer? uint32 | | +--rw retry-timer? uint32 | |||
+--rw access-control-list | +--rw access-control-list | |||
| +--rw mac* [mac-address] | | +--rw mac* [mac-address] | |||
| +--rw mac-address yang:mac-address | | +--rw mac-address yang:mac-address | |||
+--rw mac-addr-limit | +--ro actual-site-start? yang:date-and-time | |||
+--rw limit-number? uint16 | +--ro actual-site-stop? yang:date-and-time | |||
+--rw time-interval? uint32 | +--rw bundling-type? identityref | |||
+--rw action? 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 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 enable? boolean | ||||
| | +--rw uni-loop-prevention? boolean | ||||
| +--rw lag-interfaces {lag-interface}? | ||||
| | +--rw lag-interface* [index] | ||||
| | +--rw index string | ||||
| | +--rw lacp {lacp}? | ||||
| | +--rw enable? boolean | ||||
| | +--rw mode? neg-mode | ||||
| | +--rw speed? uint32 | ||||
| | +--rw mini-link-num? uint32 | ||||
| | +--rw system-priority? uint16 | ||||
| | +--rw micro-bfd {micro-bfd}? | ||||
| | | +--rw enable? 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 enable? 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 synthethic-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 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 | ||||
+--rw mac-addr-limit | ||||
+--rw limit-number? uint16 | ||||
+--rw time-interval? uint32 | ||||
+--rw action? identityref | ||||
Figure 4 | Figure 4 | |||
5.1. Features and Augmentation | 5.1. Features and Augmentation | |||
The model defined in this document implements many features that | The model defined in this document implements many features that | |||
allow implementations to be modular. As an example, the layer 2 | allow implementations to be modular. As an example, the layer 2 | |||
protocols parameters (Section 5.3.2.2) proposed to the customer may | protocols parameters (Section 5.3.2.2) proposed to the customer may | |||
also be enabled through features. This model also defines some | also be enabled through features. This model also defines some | |||
features for options that are more advanced, such as support for | features for options that are more advanced, such as support for | |||
skipping to change at page 20, line 45 ¶ | skipping to change at page 21, line 5 ¶ | |||
A vpn-service is composed of some characteristics: | A vpn-service is composed of some characteristics: | |||
Customer information: Used to identify the customer. | Customer information: Used to identify the customer. | |||
VPN Service Type (svc-type): Used to indicate the VPN service Type. | VPN Service Type (svc-type): Used to indicate the VPN service Type. | |||
The identifier is an identity allowing any encoding for the local | The identifier is an identity allowing any encoding for the local | |||
administration of the VPN service. Note that other identity can | administration of the VPN service. Note that other identity can | |||
be an extension of the base identity. | be an extension of the base identity. | |||
Cloud Access (cloud-access): All sites in the L2VPN MUST be | Cloud Access (cloud-access): All sites in the L2VPN SHOULD be | |||
authorized to access to the cloud. The cloud-access container | permitted to access to the cloud by default. The cloud-access | |||
provides parameters for authorization rules. A cloud identifier | container provides parameters for authorization rules. A cloud | |||
is used to reference the target service. This identifier is local | identifier is used to reference the target service. This | |||
to each administration. | identifier is local to each administration. | |||
Service Topology (svc-topo): Used to identify the type of VPN | Service Topology (svc-topo): Used to identify the type of VPN | |||
service topology that is required. | service topology that is required. | |||
Frame Delivery Service (frame-delivery): Defines the frame delivery | Frame Delivery Service (frame-delivery): Defines the frame delivery | |||
support required for the L2VPN, e.g., multicast delivery, unicast | support required for the L2VPN, e.g., multicast delivery, unicast | |||
delivery, or broadcast delivery. | delivery, or broadcast delivery. | |||
Extranet VPN (extranet-vpns): Indicates that a particular VPN needs | Extranet VPN (extranet-vpns): Indicates that a particular VPN needs | |||
access to resources located in another VPN. | access to resources located in another VPN. | |||
skipping to change at page 21, line 30 ¶ | skipping to change at page 21, line 36 ¶ | |||
o Point-to-point Virtual Private Wire Services (VPWS) connecting two | o Point-to-point Virtual Private Wire Services (VPWS) connecting two | |||
customer Sites; | customer Sites; | |||
o Point-to-point or point-to-multipoint Virtual Private Wire | o Point-to-point or point-to-multipoint Virtual Private Wire | |||
Services (VPWS) connecting a set of customer sites [RFC8214]; | Services (VPWS) connecting a set of customer sites [RFC8214]; | |||
o Multipoint Virtual Private LAN services (VPLS) connecting a set of | o Multipoint Virtual Private LAN services (VPLS) connecting a set of | |||
customer sites; | customer sites; | |||
o Multipoint Virtual Private LAN services (VPLS) connecting one or | o Multipoint Virtual Private LAN services (VPLS) connecting one or | |||
more root sites and a set of leave sites, but preventing inter- | more root sites and a set of leaf sites, but preventing inter-leaf | |||
leaf sites communication. | sites communication. | |||
o EVPN Service connecting a set of customer sites. | o EVPN Service connecting a set of customer sites. | |||
o Ethernet VPN VPWS between two customer sites or a set of customer | o Ethernet VPN VPWS between two customer sites or a set of customer | |||
sites specified in [RFC8214] and [RFC7432]; | sites specified in [RFC8214] and [RFC7432]; | |||
Other L2VPN Service Types could be included by augmentation. Note | Other L2VPN Service Types could be included by augmentation. Note | |||
that an Ethernet Private Line (EPL) service or an Ethernet Virtual | that an Ethernet Private Line (EPL) service or an Ethernet Virtual | |||
Private Line (EVPL) service is an E-Line service or a point-to-point | Private Line (EVPL) service is an E-Line service [MEF-6]or a point- | |||
Ethernet Virtual Circuit (EVC) service, while an Ethernet Private LAN | to-point Ethernet Virtual Circuit (EVC) service, while an Ethernet | |||
(EP-LAN) service or an Ethernet Virtual Private LAN (EVP-LAN) service | Private LAN (EP-LAN) service or an Ethernet Virtual Private LAN (EVP- | |||
is an E-LAN service or a multipoint-to-multipoint EVC service. | LAN) service is an E-LAN service [MEF-6] or a multipoint-to- | |||
multipoint EVC service. | ||||
5.2.2. VPN Service Topology | 5.2.2. VPN Service Topology | |||
The type of VPN service topology can be used for configuration if | The type of VPN service topology can be used for configuration if | |||
needed. The module currently supports: any-to-any; hub-and-spoke | needed. The module currently supports: any-to-any; hub-and-spoke | |||
(where hubs can exchange traffic); and hub-and-spoke-disjoint (where | (where hubs can exchange traffic); and hub-and-spoke-disjoint (where | |||
hubs cannot exchange traffic). New topologies could be added by | hubs cannot exchange traffic). New topologies could be added by | |||
augmentation. By default, the any-to-any VPN service topology is | augmentation. By default, the any-to-any VPN service topology is | |||
used. | used. | |||
skipping to change at page 23, line 25 ¶ | skipping to change at page 23, line 35 ¶ | |||
| Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 | | | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 | | |||
+-------------------------------------------------------------+ | +-------------------------------------------------------------+ | |||
Hub-and-Spoke-Disjoint VPN Service Topology | Hub-and-Spoke-Disjoint VPN Service Topology | |||
In the Hub-and-Spoke-Disjoint VPN service topology, all Spoke sites | In the Hub-and-Spoke-Disjoint VPN service topology, all Spoke sites | |||
can communicate only with Hub sites, but not with each other. And | can communicate only with Hub sites, but not with each other. And | |||
Hubs cannot communicate with each other. The management system that | Hubs cannot communicate with each other. The management system that | |||
receives a Hub-and-Spoke-Disjoint L2VPN service request through this | 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 | model is expected to assign and then configure the VRF and RTs on the | |||
appropriate PEs. In the Hub-and-Spoke-Disjoint case, two RTs | appropriate PEs. In the Hub-and-Spoke-Disjoint case, at least two | |||
arerequired (one RT for Hub routes and one RT for Spoke routes). A | RTs are required for Hub and Spoke respectively(one RT for Hub routes | |||
Hub VRF that connects Hub sites will export Hub routes with the Hub | and one RT for Spoke routes). A Hub VRF that connects Hub sites will | |||
RT and will import Spoke routes through the Spoke RT. A Spoke VRF | export Hub routes with the Hub RT and will import Spoke routes | |||
that connects Spoke sites will export Spoke routes with the Spoke RT | through the Spoke RT. A Spoke VRF that connects Spoke sites will | |||
and will import Hub routes through the Hub RT. | export Spoke routes with the Spoke RT and will import Hub routes | |||
through the Hub RT. | ||||
The management system MUST take into account constraints on Hub-and- | The management system MUST take into account constraints on Hub-and- | |||
Spoke connections, as in the previous case. | Spoke connections, as in the previous case. | |||
Hub-and-Spoke-Disjoint can also be seen as multiple Hub-and-Spoke | 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. | VPNs (one per Hub) that share a common set of Spoke sites. | |||
5.2.3. Cloud Access | 5.2.3. Cloud Access | |||
This model provides cloud access configuration through the cloud- | This model provides cloud access configuration through the cloud- | |||
access container. The usage of cloud-access is targeted for public | access container. The usage of cloud-access is targeted for public | |||
cloud and for Internet access. The cloud-access container provides | cloud and for Internet access. The cloud-access container provides | |||
parameters for authorization rules. | 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. | ||||
Anyway, a different label for Internet access could be added by | ||||
augmentation. | ||||
Private cloud access may be addressed through the site container as | Private cloud access may be addressed through the site container as | |||
described in Section 5.3 with use consistent with sites of type NNI. | described in Section 5.3 with use consistent with sites of type NNI | |||
(Network to Network Interface). | ||||
A cloud identifier is used to reference the target service. This | A cloud identifier is used to reference the target service. This | |||
identifier is local to each administration. | identifier is local to each administration. | |||
By default, all sites in the L2VPN SHOULD be authorized to access the | By default, all sites in the L2VPN SHOULD be permitted to access the | |||
cloud. If restrictions are required, a user MAY configure the | cloud or internet. If restrictions are required, a user MAY | |||
"permit-site" or "deny-site" leaf-list. The permit-site leaf-list | configure some limitations for some sites or nodes by using policies, | |||
defines the list of sites authorized for cloud access. The deny-site | i.e. the "permit-site" or "deny-site" leaf-list. The permit-site | |||
leaf-list defines the list of sites denied for cloud access. The | leaf-list defines the list of sites authorized for cloud access. The | |||
model supports both "deny-any-except" and "permit-any-except" | deny-site leaf-list defines the list of sites denied for cloud | |||
authorization. | access. The model supports both "deny-any-except" and "permit-any- | |||
except" authorization. | ||||
How the restrictions will be configured on network elements is out of | How the restrictions will be configured on network elements is out of | |||
scope for this document. | scope for this document. | |||
L2VPN | L2VPN | |||
++++++++++++++++++++++++++++++++ ++++++++++++ | ++++++++++++++++++++++++++++++++ ++++++++++++ | |||
+ Site 3 + --- + Cloud 1 + | + Site 3 + --- + Cloud 1 + | |||
+ Site 1 + ++++++++++++ | + Site 1 + ++++++++++++ | |||
+ + | + + | |||
+ Site 2 + --- ++++++++++++ | + Site 2 + --- ++++++++++++ | |||
skipping to change at page 27, line 44 ¶ | skipping to change at page 28, line 11 ¶ | |||
on VPN B) needs to be achieved using a VPN attachment as defined in | on VPN B) needs to be achieved using a VPN attachment as defined in | |||
Section 5.5.2, and especially a VPN policy as defined in | Section 5.5.2, and especially a VPN policy as defined in | |||
Section 5.5.2.2. | Section 5.5.2.2. | |||
5.2.5. Frame Delivery Service | 5.2.5. Frame Delivery Service | |||
If BUM (Broadcast/Unknown/Multicast) Frame Delivery Service is | If BUM (Broadcast/Unknown/Multicast) Frame Delivery Service is | |||
supported for an L2VPN, some global frame delivery parameters are | supported for an L2VPN, some global frame delivery parameters are | |||
required as input for the service request. When a CE sends packets | required as input for the service request. When a CE sends packets | |||
that are Broadcast, Multicast, or Unknown-destination-unicast, | that are Broadcast, Multicast, or Unknown-destination-unicast, | |||
replication occurs at the ingress PE, therefore three frame types are | replication occurs at the ingress PE, three frame types need to be | |||
supported. | supported. | |||
Users of this model will need to provide the flavors of trees that | Users of this model will need to provide the flavors of trees that | |||
will be used by customers within the L2VPN (customer-tree-flavors). | will be used by customers within the L2VPN (customer-tree-flavors). | |||
The model defined in this document supports bidirectional, shared, | The model defined in this document supports bidirectional, shared, | |||
and source-based trees (and can be augmented to contain other tree | and source-based trees (and can be augmented to contain other tree | |||
types). Multiple flavors of trees can be supported simultaneously. | types). Multiple flavors of trees can be supported simultaneously. | |||
Operator network | Operator network | |||
______________ | ______________ | |||
skipping to change at page 29, line 9 ¶ | skipping to change at page 29, line 26 ¶ | |||
| | | +-------------+ | | | | +-------------+ | |||
+------------------+ | / \ | +------------------+ | / \ | |||
+-----| VPN2 | | +-----| VPN2 | | |||
\ / | \ / | |||
+-------------+ | +-------------+ | |||
The "site" container is used for the provider to store information of | The "site" container is used for the provider to store information of | |||
detailed implementation arrangements made with either the customer or | detailed implementation arrangements made with either the customer or | |||
with peer operators at each inter-connect location. | with peer operators at each inter-connect location. | |||
We restrict the L2SM to exterior interfaces only, so all internal | We restrict the L2SM to exterior interfaces (i.e.,UNI and NNI) only, | |||
interfaces and the underlying topology are outside the scope of L2SM. | so all internal interfaces and the underlying topology are outside | |||
the scope of L2SM. | ||||
Typically, the following characteristics of a site interface handoff | Typically, the following characteristics of a site interface handoff | |||
need to be documented as part of the service design: | need to be documented as part of the service design: | |||
Unique identifier (site-id): An arbitrary string to uniquely | Unique identifier (site-id): An arbitrary string to uniquely | |||
identify the site within the overall network infrastructure. The | identify the site within the overall network infrastructure. The | |||
format of site-id is determined by the local administration of the | format of site-id is determined by the local administration of the | |||
VPN service. | VPN service. | |||
Device (device): The customer can request one or more customer | Device (device): The customer can request one or more customer | |||
skipping to change at page 30, line 12 ¶ | skipping to change at page 30, line 31 ¶ | |||
multihoming. Some other meshing cases may also include multiple | multihoming. Some other meshing cases may also include multiple | |||
site-network-accesses. | site-network-accesses. | |||
The site configuration is viewed as a global entity; we assume that | The site configuration is viewed as a global entity; we assume that | |||
it is mostly the management system's role to split the parameters | it is mostly the management system's role to split the parameters | |||
between the different elements within the network. For example, in | between the different elements within the network. For example, in | |||
the case of the site-network-access configuration, the management | the case of the site-network-access configuration, the management | |||
system needs to split the parameters between the PE configuration and | system needs to split the parameters between the PE configuration and | |||
the CE configuration. | the CE configuration. | |||
The site may support single-homed or multi-homed. In case of multi- | The site may support single-homed acess or multihoming. In the case | |||
homed, the site can support multiple site-network-accesses, under | of multihoming, the site can support multiple site-network-accesses, | |||
each site-network-access, vpn-attachment is defined and it will | under each site-network-access, vpn-attachment is defined and it will | |||
describe which site-network-access associated with which site will | describe which site-network-access associated with which site will | |||
connect to which VPN. | connect to which VPN. | |||
5.3.1. Devices and Locations | 5.3.1. Devices and Locations | |||
The information in the "location" sub-container under a "site" and in | The information in the "location" sub-container under a "site" and in | |||
the "device" container allows easy retrieval of data about which are | the "device" container allows easy retrieval of data about which are | |||
the nearest available facilities and can be used for access topology | the nearest available facilities and can be used for access topology | |||
planning. It may also be used by other network orchestration | planning. It may also be used by other network orchestration | |||
components to choose the targeted upstream PE and downstream CE. | components to choose the targeted upstream PE and downstream CE. | |||
Location is expressed in terms of postal information. | Location is expressed in terms of postal information. More detailed | |||
or other location information can be added by augmentation. | ||||
A site may be composed of multiple locations. All the locations will | A site may be composed of multiple locations. All the locations will | |||
need to be configured as part of the "locations" container and list. | need to be configured as part of the "locations" container and list. | |||
A typical example of a multi-location site is a headquarters office | A typical example of a multi-location site is a headquarters office | |||
in a city composed of multiple buildings. Those buildings may be | in a city composed of multiple buildings. Those buildings may be | |||
located in different parts of the city and may be linked by intra- | located in different parts of the city and may be linked by intra- | |||
city fibers (a customer metropolitan area network). In such a case, | city fibers (a customer metropolitan area network). This model does | |||
when connecting to a VPN service, the customer may ask for | not represent the connectivity between the multiple locations of a | |||
multihoming based on its distributed locations. | 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. | ||||
New York Site | New York Site | |||
+------------------+ Site | +------------------+ Site | |||
| +--------------+ |----------------------------------- | | +--------------+ |----------------------------------- | |||
| | Manhattan | |****** (site-network-access#1) ****** | | | Manhattan | |****** (site-network-access#1) ****** | |||
| +--------------+ | | | +--------------+ | | |||
| +--------------+ | | | +--------------+ | | |||
| | Brooklyn | |****** (site-network-access#2) ****** | | | Brooklyn | |****** (site-network-access#2) ****** | |||
| +--------------+ |----------------------------------- | | +--------------+ |----------------------------------- | |||
+------------------+ | +------------------+ | |||
skipping to change at page 31, line 40 ¶ | skipping to change at page 32, line 15 ¶ | |||
The site-network-access has a specific type (site-network-access- | The site-network-access has a specific type (site-network-access- | |||
type). This document defines two types: | type). This document defines two types: | |||
o point-to-point: describes a point-to-point connection between the | o point-to-point: describes a point-to-point connection between the | |||
SP and the customer. | SP and the customer. | |||
o multipoint: describes a multipoint connection between the SP and | o multipoint: describes a multipoint connection between the SP and | |||
the customer. | the customer. | |||
This site-network-access type may have an impact on the parameters | This site-network-access type may have an impact on the parameters | |||
offered to the customer, e.g., an SP might not offer encryption for | offered to the customer, e.g., an SP might not offer MAC Loop | |||
multipoint accesses. It is up to the provider to decide what | Protection for multipoint accesses. It is up to the provider to | |||
parameters are supported for point-to-point and/or multipoint | decide what parameters are supported for point-to-point and/or | |||
accesses. Multipoint accesses are out of scope for this document and | multipoint accesses. Multipoint accesses are out of scope for this | |||
some containers defined in the model may require extensions in order | document and some containers defined in the model may require | |||
to work properly for multipoint accesses. | extensions in order to work properly for multipoint accesses. | |||
5.3.2.1. Bearer | 5.3.2.1. Bearer | |||
The "bearer" container defines the requirements for the site | The "bearer" container defines the requirements for the site | |||
attachment to the provider network that are below Layer 2. | attachment to the provider network that are below Layer 2. | |||
The bearer parameters will help to determine the access media to be | The bearer parameters will help to determine the access media to be | |||
used. | used. | |||
5.3.2.2. Connection | 5.3.2.2. Connection | |||
skipping to change at page 32, line 39 ¶ | skipping to change at page 33, line 13 ¶ | |||
customer and provider edge devices. The connection container also | customer and provider edge devices. The connection container also | |||
defines an L2CP attribute to allow control plane protocol interaction | defines an L2CP attribute to allow control plane protocol interaction | |||
between the CE devices and PE device. | between the CE devices and PE device. | |||
5.3.2.2.1. Untagged Interface | 5.3.2.2.1. Untagged Interface | |||
For each untagged interface (untagged-interface), there are basic | For each untagged interface (untagged-interface), there are basic | |||
configuration parameters like interface index and speed, interface | configuration parameters like interface index and speed, interface | |||
MTU, auto-negotiation and flow-control settings, etc. In addition | MTU, auto-negotiation and flow-control settings, etc. In addition | |||
and based on mutual agreement, the customer and provider may decide | and based on mutual agreement, the customer and provider may decide | |||
to enable advanced features, such as LLDP, 802.3AH link OAM, MAC loop | to enable advanced features, such as LLDP, IEEE 802.3ah, MAC loop | |||
detection/prevention at a UNI. If Loop avoidance is required, the | detection/prevention at a UNI. If Loop avoidance is required, the | |||
attribute "uni-loop-prevention" must be set to TRUE. | attribute "uni-loop-prevention" must be set to TRUE. | |||
5.3.2.2.2. Tagged Interface | 5.3.2.2.2. Tagged Interface | |||
If the tagged service is enabled on a logical unit on the connection | If the tagged service is enabled on a logical unit on the connection | |||
at the interface, "encapsulation-type" should be specified as the | at the interface, "encapsulation-type" should be specified as the | |||
Ethernet VLAN ecapsulation (if VLAN-based) or VXLAN encapsulation, | Ethernet VLAN ecapsulation (if VLAN-based) or VXLAN encapsulation, | |||
and "eth-inf-type" should be set to indicate a tagged interface. | and "eth-inf-type" should be set to indicate a tagged interface. | |||
skipping to change at page 34, line 6 ¶ | skipping to change at page 34, line 30 ¶ | |||
In the L2SM, there is a set of attributes under "LAG-interface" | In the L2SM, there is a set of attributes under "LAG-interface" | |||
related to link aggregation functionality. The customer and provider | related to link aggregation functionality. The customer and provider | |||
first need to decide on whether LACP PDUs will be exchanged between | first need to decide on whether LACP PDUs will be exchanged between | |||
the edge devices by specifying the "LACP-state" to "On" or "Off". If | the edge devices by specifying the "LACP-state" to "On" or "Off". If | |||
LACP is to be enabled, then both parties need to further specify | LACP is to be enabled, then both parties need to further specify | |||
whether it will be running in active or passive mode, plus the time | whether it will be running in active or passive mode, plus the time | |||
interval and priority level of the LACP PDU. The customer and | interval and priority level of the LACP PDU. The customer and | |||
provider can also determine the minimum aggregate bandwidth for a LAG | provider can also determine the minimum aggregate bandwidth for a LAG | |||
to be considered as a valid path by specifying the optional "mini- | to be considered as a valid path by specifying the optional "mini- | |||
link" attribute. To enable fast detection of faulty links, micro-bfd | link" attribute. To enable fast detection of faulty links, micro-BFD | |||
runs independent UDP sessions to monitor the status of each member | [RFC7130]runs independent UDP sessions to monitor the status of each | |||
link. Customer and provider should agree the BFD hello interval and | member link. Customer and provider should agree the BFD hello | |||
hold time. | interval and hold time. | |||
Each member link will be listed under the LAG interface with basic | Each member link will be listed under the LAG interface with basic | |||
physical link properties. Certain attributes like flow-control, | physical link properties. Certain attributes like flow-control, | |||
encapsulation type, allowed ingress Ethertype and LLDP settings are | encapsulation type, allowed ingress Ethertype and LLDP settings are | |||
at the LAG level. | at the LAG level. | |||
5.3.2.2.4. CVLAN ID To SVC MAP | 5.3.2.2.4. CVLAN ID To SVC MAP | |||
When more than one service is multiplexed onto the same interface, | When more than one service is multiplexed onto the same interface, | |||
ingress service frames are conditionally transmitted through one of | ingress service frames are conditionally transmitted through one of | |||
skipping to change at page 38, line 20 ¶ | skipping to change at page 38, line 34 ¶ | |||
| New York Office | | | | | | | New York Office | | | | | | |||
| |***(site-network-access#2)******* \ | / | | |***(site-network-access#2)******* \ | / | |||
| |-----------------------------| VPN A+-----|---+ | | |-----------------------------| VPN A+-----|---+ | |||
+------------------+ \ / | +------------------+ \ / | |||
+--------+ | +--------+ | |||
In the example above, the New York office is multihomed. Both | In the example above, the New York office is multihomed. Both | |||
logical accesses are using the same VPN attachment rules, and both | logical accesses are using the same VPN attachment rules, and both | |||
are connected to VPN A and to VPN B. | are connected to VPN A and to VPN B. | |||
Reaching VPN A or VPN B from the New York office will be done via | Reaching VPN A or VPN B from the New York office will be done via MAC | |||
destination-based routing. Having the same destination reachable | destination based forwarding. Having the same destination reachable | |||
from the two VPNs may cause routing problems. The customer | from the two VPNs may cause routing problems. The customer | |||
administration's role in this case would be to ensure the appropriate | administration's role in this case would be to ensure the appropriate | |||
mapping of its prefixes in each VPN. See Section 5.5.2 and | mapping of its MAC addresses in each VPN. See Section 5.5.2 and | |||
Section 5.10.2 for more details. | Section 5.10.2 for more details. See also Section 5.10.3 for BUM | |||
support. | ||||
5.5.1.3. NNI: site-vpn-flavor-nni | 5.5.1.3. NNI: site-vpn-flavor-nni | |||
A Network-to-Network Interface (NNI) scenario may be modeled using | A Network-to-Network Interface (NNI) scenario may be modeled using | |||
the sites container. It is helpful for the SP to indicate that the | 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, | requested VPN connection is not a regular site but rather is an NNI, | |||
as specific default device configuration parameters may be applied in | as specific default device configuration parameters may be applied in | |||
the case of NNIs (e.g., ACLs, routing policies). | the case of NNIs (e.g., ACLs, routing policies). | |||
SP A SP B | SP A SP B | |||
skipping to change at page 42, line 19 ¶ | skipping to change at page 42, line 19 ¶ | |||
two logical accesses (LA1 and LA2), attached to both VPNA and VPNB. | two logical accesses (LA1 and LA2), attached to both VPNA and VPNB. | |||
5.5.2.2. VPN Policy | 5.5.2.2. VPN Policy | |||
The "vpn-policy" list helps express a multi-VPN scenario where a | The "vpn-policy" list helps express a multi-VPN scenario where a | |||
logical access belongs to multiple VPNs. | logical access belongs to multiple VPNs. | |||
As a site can belong to multiple VPNs, the vpn-policy list may be | 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 | 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. | that only some LANs at the site should be part of a particular VPN. | |||
Each time a site (or LAN) is attached to a VPN, the user must | A site can be composed by multiple LAN segments and each LAN segment | |||
precisely describe its role (site-role) within the target VPN service | can be connected to different VPN. Each time a site (or LAN) is | |||
topology. | attached to a VPN, the user must precisely describe its role (site- | |||
role) within the target VPN service topology. | ||||
+--------------------------------------------------------------+ | +--------------------------------------------------------------+ | |||
| Site1 ------ PE7 | | | Site1 ------ PE7 | | |||
+-------------------------+ [VPN2] | | +-------------------------+ [VPN2] | | |||
| | | | | | |||
+-------------------------+ | | +-------------------------+ | | |||
| Site2 ------ PE3 PE4 ------ Site3 | | | Site2 ------ PE3 PE4 ------ Site3 | | |||
+----------------------------------+ | | +----------------------------------+ | | |||
| | | | | | |||
+------------------------------------------------------------+ | | +------------------------------------------------------------+ | | |||
skipping to change at page 45, line 51 ¶ | skipping to change at page 46, line 4 ¶ | |||
<site-id>Site5</site-id> | <site-id>Site5</site-id> | |||
<vpn-policies> | <vpn-policies> | |||
<vpn-policy> | <vpn-policy> | |||
<vpn-policy-id>POLICY1</vpn-policy-id> | <vpn-policy-id>POLICY1</vpn-policy-id> | |||
<entries> | <entries> | |||
<id>ENTRY1</id> | <id>ENTRY1</id> | |||
<filters> | <filters> | |||
<filter> | <filter> | |||
<type>lan</type> | <type>lan</type> | |||
<lan-tag>LAN1</lan-tag> | <lan-tag>LAN1</lan-tag> | |||
</filter> | ||||
</filter> | ||||
</filters> | </filters> | |||
<vpn> | <vpn> | |||
<vpn-id>VPN2</vpn-id> | <vpn-id>VPN2</vpn-id> | |||
<site-role>hub-role</site-role> | <site-role>hub-role</site-role> | |||
</vpn> | </vpn> | |||
</entries> | </entries> | |||
<entries> | <entries> | |||
<id>ENTRY2</id> | <id>ENTRY2</id> | |||
<filters> | <filters> | |||
<filter> | <filter> | |||
skipping to change at page 47, line 23 ¶ | skipping to change at page 47, line 25 ¶ | |||
The management system MUST honor all customer constraints, or if a | The management system MUST honor all customer constraints, or if a | |||
constraint is too strict and cannot be fulfilled, the management | constraint is too strict and cannot be fulfilled, the management | |||
system MUST NOT provision the site and MUST provide information to | system MUST NOT provision the site and MUST provide information to | |||
the user about which constraints that could not be fulfilled. How | the user about which constraints that could not be fulfilled. How | |||
the information is provided is out of scope for this document. | the information is provided is out of scope for this document. | |||
Whether or not to relax the constraint would then be left up to the | Whether or not to relax the constraint would then be left up to the | |||
user. | user. | |||
Parameters such as site location (see Section 5.6.2) and access type | Parameters such as site location (see Section 5.6.2) and access type | |||
as special contraints are just hints (see Section 5.6.3) for the | (see Section 5.6.3) affect the service placement that the management | |||
management system for service placement. | system applies. | |||
In addition to parameters and constraints, the management system's | In addition to parameters and constraints, the management system's | |||
decision MAY be based on any other internal constraints that are left | decision MAY be based on any other internal constraints that are left | |||
up to the SP, such as least load, distance, etc. | up to the SP, such as least load, distance, etc. | |||
5.6.1. Constraint: Device | 5.6.1. Constraint: Device | |||
In the case of provider management or co-management, one or more | In the case of provider management or co-management, one or more | |||
devices have been ordered by the customer to a particular location | devices have been ordered by the customer to a particular location | |||
that has already been configured. The customer may force a | that has already been configured. The customer may force a | |||
particular site- network-access to be connected on a particular | particular site-network-access to be connected on a particular device | |||
device that he ordered. | that he ordered. | |||
New York Site | New York Site | |||
+------------------+ Site | +------------------+ Site | |||
| +--------------+ |----------------------------------- | | +--------------+ |----------------------------------- | |||
| | Manhattan | | | | | Manhattan | | | |||
| | CE1********* (site-network-access#1) ****** | | | CE1********* (site-network-access#1) ****** | |||
| +--------------+ | | | +--------------+ | | |||
| +--------------+ | | | +--------------+ | | |||
| | Brooklyn | | | | | Brooklyn | | | |||
| | CE2********* (site-network-access#2) ****** | | | CE2********* (site-network-access#2) ****** | |||
skipping to change at page 48, line 17 ¶ | skipping to change at page 48, line 17 ¶ | |||
connection. | connection. | |||
5.6.2. Constraint/Parameter: Site Location | 5.6.2. Constraint/Parameter: Site Location | |||
The location information provided in this model MAY be used by a | The location information provided in this model MAY be used by a | |||
management system to determine the target PE to mesh the site (SP | management system to determine the target PE to mesh the site (SP | |||
side). A particular location must be associated with each site | side). A particular location must be associated with each site | |||
network access when configuring it. The SP MUST honor the | network access when configuring it. The SP MUST honor the | |||
termination of the access on the location associated with the site | termination of the access on the location associated with the site | |||
network access (customer side). The "country-code" in the site | network access (customer side). The "country-code" in the site | |||
location should be expressed as an ISO ALPHA-2 code. | location should be expressed as an ISO 3166 code and is similar to | |||
country label defined in [RFC4119]. | ||||
The site-network-access location is determined by the "location- | The site-network-access location is determined by the "location- | |||
flavor". In the case of a provider-managed or co-managed site, the | flavor". In the case of a provider-managed or co-managed site, the | |||
user is expected to configure a "device-reference" (device case) that | user is expected to configure a "device-reference" (device case) that | |||
will bind the site-network-access to a particular device that the | will bind the site-network-access to a particular device that the | |||
customer ordered. As each device is already associated with a | customer ordered. As each device is already associated with a | |||
particular location, in such a case the location information is | particular location, in such a case the location information is | |||
retrieved from the device location. In the case of a customer- | retrieved from the device location. In the case of a customer- | |||
managed site, the user is expected to configure a "location- | managed site, the user is expected to configure a "location- | |||
reference" (location case); this provides a reference to an existing | reference" (location case); this provides a reference to an existing | |||
skipping to change at page 50, line 34 ¶ | skipping to change at page 50, line 36 ¶ | |||
or more group-ids can also be defined at the site level; as a | or more group-ids can also be defined at the site level; as a | |||
consequence, all site-network-accesses under the site MUST inherit | consequence, all site-network-accesses under the site MUST inherit | |||
the group-ids of the site they belong to. When, in addition to the | the group-ids of the site they belong to. When, in addition to the | |||
site group-ids some group-ids are defined at the site-network-access | site group-ids some group-ids are defined at the site-network-access | |||
level, the management system MUST consider the union of all groups | level, the management system MUST consider the union of all groups | |||
(site level and site network access level) for this particular site- | (site level and site network access level) for this particular site- | |||
network-access. | network-access. | |||
For an already-configured site-network-access, each constraint MUST | For an already-configured site-network-access, each constraint MUST | |||
be expressed against a targeted set of site-network-accesses. This | be expressed against a targeted set of site-network-accesses. This | |||
site-network-access MUST never be taken into account in the targeted | site-network-access (i.e. the already-configured site-network-access) | |||
set -- for example, "My site-network-access S must not be connected | MUST never be taken into account in the targeted set of site-network- | |||
on the same POP as the site-network-accesses that are part of Group | accesses. For example, "My site-network-access S must not be | |||
10." The set of site-network-accesses against which the constraint | connected on the same POP as the site-network-accesses that are part | |||
is evaluated can be expressed as a list of groups, "all-other- | of Group 10." The set of site-network-accesses against which the | |||
accesses", or "all-other-groups". The all-other-accesses option | constraint is evaluated can be expressed as a list of groups, "all- | |||
means that the current site-network-access constraint MUST be | 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 | evaluated against all the other site-network-accesses belonging to | |||
the current site. The all-other-groups option means that the | the current site. The all-other-groups option means that the | |||
constraint MUST be evaluated against all groups that the current | constraint MUST be evaluated against all groups that the current | |||
site-network-access does not belong to. | site-network-access does not belong to. | |||
The current model defines multiple constraint-types: | The current model defines multiple constraint-types: | |||
o pe-diverse: The current site-network-access MUST NOT be connected | o pe-diverse: The current site-network-access MUST NOT be connected | |||
to the same PE as the targeted site-network-accesses. | to the same PE as the targeted site-network-accesses. | |||
skipping to change at page 54, line 49 ¶ | skipping to change at page 54, line 49 ¶ | |||
o bw-per-svc bandwidth is per site, providing rate enforcement for | o bw-per-svc bandwidth is per site, providing rate enforcement for | |||
all service frames that are associated with a particular VPN | all service frames that are associated with a particular VPN | |||
service. | service. | |||
o opaque bandwidth is the total bandwidth that is not associated | o opaque bandwidth is the total bandwidth that is not associated | |||
with any particular cos-id, vpn service identified with the vpn- | with any particular cos-id, vpn service identified with the vpn- | |||
id, or site network access id. | id, or site network access id. | |||
The svc-bandwidth must include a "cos-id" parameter if the 'type' is | The svc-bandwidth must include a "cos-id" parameter if the 'type' is | |||
set as 'bw-per-cos'. The cos-id can be assigned based on the dot1p | set as 'bw-per-cos'. The cos-id can be assigned based on the IEEE | |||
value in the C-tag, or on the DSCP in the Ethernet Frame header. | 802.1p value in the C-tag, or on the DSCP in the Ethernet Frame | |||
Service frames are metered against the bandwidth profile based on the | header. Service frames are metered against the bandwidth profile | |||
cos-identifier. | based on the cos-identifier. | |||
The svc-bandwidth must be associated with a specific "site-network- | The svc-bandwidth must be associated with a specific "site-network- | |||
access-id" parameter if the 'type' is set as 'bw-per-access'. | access-id" parameter if the 'type' is set as 'bw-per-access'. | |||
Multiple bandwidths per cos-id can be associated with the same Site | Multiple bandwidths per cos-id can be associated with the same Site | |||
Network access. | Network access. | |||
The svc-bandwidth must include a specific "vpn-id" parameter if the | The svc-bandwidth must include a specific "vpn-id" parameter if the | |||
'type' is set as 'bw-per-svc'. Multiple bandwidths per cos-id can be | 'type' is set as 'bw-per-svc'. Multiple bandwidths per cos-id can be | |||
associated with the same Ethernet VPN service. | associated with the same Ethernet VPN service. | |||
skipping to change at page 57, line 30 ¶ | skipping to change at page 57, line 30 ¶ | |||
RSVP-TE reservation, controller reservation) is out of scope for | RSVP-TE reservation, controller reservation) is out of scope for | |||
this document. | this document. | |||
In addition, due to network conditions, some constraints may not be | In addition, due to network conditions, some constraints may not be | |||
completely fulfilled by the SP; in this case, the SP should advise | completely fulfilled by the SP; in this case, the SP should advise | |||
the customer about the limitations. How this communication is done | the customer about the limitations. How this communication is done | |||
is out of scope for this document. | is out of scope for this document. | |||
5.10.3. Broadcast Multicast Unknow Unicast Support | 5.10.3. Broadcast Multicast Unknow Unicast Support | |||
The "broadcast-unknowunicast-multicast" container defines the type of | The "broadcast-unknown-unicast-multicast" container defines the type | |||
site in the customer multicast service topology: source, receiver, or | of site in the customer multicast service topology: source, receiver, | |||
both. These parameters will help the management system optimize the | or both. These parameters will help the management system optimize | |||
multicast service. | the multicast service. | |||
Multiple multicast group-to-port mappings can be created using the | Multiple multicast group-to-port mappings can be created using the | |||
"multicast-gp-address-mapping" list. The "multicast-gp-address- | "multicast-gp-address-mapping" list. The "multicast-gp-address- | |||
mapping" defines multicast group address and port LAG number. Those | mapping" defines multicast group address and port LAG number. Those | |||
parameters will help the SP select the appropriate association | parameters will help the SP select the appropriate association | |||
between interface and multicast group to fulfill the customer service | between interface and multicast group to fulfill the customer service | |||
requirement. | requirement. | |||
The whole Layer-2 multicast frame (whether for data or control) | A whole Layer-2 multicast frame (whether for data or control) should | |||
SHOULD NOT be altered from CE to CEs except that the VLAN ID field | not be altered from a CE to CEs except for the VLAN ID field, | |||
may be modified, ensuring that it is transparently transported. If | ensuring that it is transparently transported. If VLAN IDs are | |||
VLAN IDs are assigned by the SP, they can also be altered. | assigned by the SP, they can also be altered. | |||
For point-to-point services, the provider only needs to deliver a | For point-to-point services, the provider only needs to deliver a | |||
single copy of each service frame to the remote PE, regardless | single copy of each service frame to the remote PE, regardless | |||
whether the destination MAC address of the incoming frame is unicast, | whether the destination MAC address of the incoming frame is unicast, | |||
multicast or broadcast. Therefore, all service frames should be | multicast or broadcast. Therefore, all service frames should be | |||
delivered unconditionally. | delivered unconditionally. | |||
B-U-M (Broadcast-UnknownUnicast-Multicast) frame forwarding in | BUM (Broadcast-UnknownUnicast-Multicast) frame forwarding in | |||
multipoint-to-multipoint services, on the other hand, involves both | multipoint-to-multipoint services, on the other hand, involves both | |||
local flooding to other attachment circuits on the same PE and remote | local flooding to other attachment circuits on the same PE and remote | |||
replication to all other PEs, thus consumes additional resources and | replication to all other PEs, thus consumes additional resources and | |||
core bandwidth. Special B-U-M frame disposition rules can be | core bandwidth. Special BUM frame disposition rules can be | |||
implemented at external facing interfaces (UNI or E-NNI) to rate- | implemented at external facing interfaces (UNI or E-NNI) to rate- | |||
limit the B-U-M frames, in term of number of packets per second or | limit the BUM frames, in term of number of packets per second or bits | |||
bits per second. | per second. | |||
The threshold can apply to all B-U-M traffic, or one for each | The threshold can apply to all BUM traffic, or one for each category. | |||
category. | ||||
5.11. Site Management | 5.11. Site Management | |||
The "management" sub-container is intended for site management | The "management" sub-container is intended for site management | |||
options, depending on the device ownership and security access | options, depending on the device ownership and security access | |||
control. The followings are three common management models: | control. The followings are three common management models: | |||
CE Provider Managed: The provider has the sole ownership of the CE | CE Provider Managed: The provider has the sole ownership of the CE | |||
device. Only the provider has access to the CE. The | device. Only the provider has access to the CE. The | |||
responsibility boundary between SP and customer is between CE and | responsibility boundary between SP and customer is between CE and | |||
skipping to change at page 61, line 14 ¶ | skipping to change at page 61, line 14 ¶ | |||
If CsC is enabled, the requested "svc-mtu" leaf will refer to the | If CsC is enabled, the requested "svc-mtu" leaf will refer to the | |||
MPLS MTU and not to the link MTU. | MPLS MTU and not to the link MTU. | |||
5.15. External ID References | 5.15. External ID References | |||
The service model sometimes refers to external information through | The service model sometimes refers to external information through | |||
identifiers. As an example, to order cloud-access to a particular | identifiers. As an example, to order cloud-access to a particular | |||
cloud service provider (CSP), the model uses an identifier to refer | cloud service provider (CSP), the model uses an identifier to refer | |||
to the targeted CSP. If a customer is directly using this service | to the targeted CSP. If a customer is directly using this service | |||
model as an API (through REST or NETCONF, for example) to order a | model as an API (through RESTCONF or NETCONF, for example) to order a | |||
particular service, the SP should provide a list of authorized | particular service, the SP should provide a list of authorized | |||
identifiers. In the case of cloud-access, the SP will provide the | identifiers. In the case of cloud-access, the SP will provide the | |||
associated identifiers for each available CSP. The same applies to | associated identifiers for each available CSP. The same applies to | |||
other identifiers, such as std-qos-profile. | other identifiers, such as std-qos-profile. | |||
As an usage example, the remote-carrrier-name is used in the NNI case | As an usage example, the remote-carrier-name is used in the NNI case | |||
because it should be known by the current L2VPN Service Provider it | because it should be known by the current L2VPN Service Provider it | |||
is connecting. While cloud-identifier should be known by both the | is connecting. While cloud-identifier should be known by both the | |||
current L2VPN Service Provider and the customer because it is applied | current L2VPN Service Provider and the customer because it is applied | |||
to public cloud or internet access. | to public cloud or internet access. | |||
How an SP provides the meanings of those identifiers to the customer | How an SP provides the meanings of those identifiers to the customer | |||
is out of scope for this document. | is out of scope for this document. | |||
5.16. Defining NNIs and Inter-AS support | 5.16. Defining NNIs and Inter-AS support | |||
skipping to change at page 71, line 5 ¶ | skipping to change at page 71, line 5 ¶ | |||
Site_1|PE|==SEG1==| |==SEG3==| |==SEG4==|PE|Site_3 | Site_1|PE|==SEG1==| |==SEG3==| |==SEG4==|PE|Site_3 | |||
+--+ +---+ | | +--+ | +--+ +---+ | | +--+ | |||
| | | | | | ---------- | | | | | | | ---------- | |||
| | | | | | | | | | | | | | | | | | |||
+--+ +---+ | | +---+ +--+ | +--+ +---+ | | +---+ +--+ | |||
Site_2|PE|==SEG2==| |==SEG5==| |==SEG6==| |==SEG7==|PE|Site_4 | Site_2|PE|==SEG2==| |==SEG5==| |==SEG6==| |==SEG7==|PE|Site_4 | |||
+--+ +---+ +---+ +---+ +--+ | +--+ +---+ +---+ +---+ +--+ | |||
| | | | | | | | | | | | | | | | | | |||
---------- ---------- ---------- ---------- | ---------- ---------- ---------- ---------- | |||
In this figure, we use EBGP redistribution of L2VPN NLRIs from AS to | In this figure, we use BGP redistribution of L2VPN NLRIs from AS to | |||
neighboring AS. First, the PE routers use Internal BGP (IBGP) to | neighboring AS. First, the PE routers use BGP to redistribute L2VPN | |||
redistribute L2VPN NLRIs either to an ASBR, or to a route reflector | NLRIs either to an ASBR, or to a route reflector of which an ASBR is | |||
of which an ASBR is a client. The ASBR then uses EBGP to | a client. The ASBR then uses BGP to redistribute those L2VPN NLRI to | |||
redistribute those L2VPN NLRI to an ASBR in another AS, which in turn | an ASBR in another AS, which in turn distributes them to the PE | |||
distributes them to the PE routers in that AS, or perhaps to another | routers in that AS, or perhaps to another ASBR which in turn | |||
ASBR which in turn distributes them, and so on. | distributes them, and so on. | |||
In this case, a PE can learn the address of an ASBR through which it | 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 a | could reach another PE to which it wishes to establish a | |||
connectivity. That is, a local PE will receive a BGP advertisement | connectivity. That is, a local PE will receive a BGP advertisement | |||
containing L2VPN NLRI corresponding to an L2VPN instance in which the | containing L2VPN NLRI corresponding to an L2VPN instance in which the | |||
local PE has some attached members. The BGP next-hop for that L2VPN | 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 | 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 | 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 | to the ASBR. A connectivity segment can now be established from the | |||
PE to the ASBR. The ASBR in turn can establish a connectivity to the | PE to the ASBR. The ASBR in turn can establish a connectivity to the | |||
skipping to change at page 72, line 14 ¶ | skipping to change at page 72, line 14 ¶ | |||
b. The component responsible for network element configuration | b. The component responsible for network element configuration | |||
(let's call it the configuration component) | (let's call it the configuration component) | |||
In some cases, when a split is needed between the behavior and | In some cases, when a split is needed between the behavior and | |||
functions that a customer requests and the technology that the | functions that a customer requests and the technology that the | |||
network operator has available to deliver the service [RFC8309], a | network operator has available to deliver the service [RFC8309], a | |||
new component can be separated out of the service component (let's | new component can be separated out of the service component (let's | |||
call it the control component). This component is responsible for | call it the control component). This component is responsible for | |||
network-centric operation and is aware of many features such as | network-centric operation and is aware of many features such as | |||
topology, technology, and operatorpolicy. As an optional component, | topology, technology, and operator policy. As an optional component, | |||
it can use the service model as input and is not required at all if | it can use the service model as input and is not required at all if | |||
the control component delegates itscontrol operations to the | the control component delegates its control operations to the | |||
configuration component. | configuration component. | |||
In Section 7 we provide some example of translation of service | In Section 7 we provide some example of translation of service | |||
provisioning requests to router configuration lines as an | provisioning requests to router configuration lines as an | |||
illustration. In the NETCONF/YANG ecosystem, it is expected that | illustration. In the YANG based ecosystem, it is expected that | |||
NETCONF and YANG will be used between the configuration component and | NETCONF and YANG will be used between the configuration component and | |||
network elements to configure the requested service on those | network elements to configure the requested service on those | |||
elements. | elements. | |||
In this framework, it is expected that YANG models will be used for | In this framework, it is expected that YANG models will be used for | |||
configuring service components on network elements. There will be a | configuring service components on network elements. There will be a | |||
strong relationship between the abstracted view provided by this | strong relationship between the abstracted view provided by this | |||
service model and the detailed configuration view that will be | service model and the detailed configuration view that will be | |||
provided by specific configuration models for network elements such | provided by specific configuration models for network elements such | |||
as those defined in [I-D.ietf-bess-l2vpn-yang] and | as those defined in [I-D.ietf-bess-l2vpn-yang] and | |||
skipping to change at page 75, line 50 ¶ | skipping to change at page 75, line 50 ¶ | |||
constraint to find the appropriate PE. In this case, we consider | constraint to find the appropriate PE. In this case, we consider | |||
Spoke1 requires PE diversity with Hub and that management system | Spoke1 requires PE diversity with Hub and that management system | |||
allocate PEs based on lowest distance. Based on the location | allocate PEs based on lowest distance. Based on the location | |||
information, the management system finds the available PEs in the | information, the management system finds the available PEs in the | |||
nearest area of the customer and picks one that fits the access- | nearest area of the customer and picks one that fits the access- | |||
diversity constraint. | diversity constraint. | |||
When the PE is chosen, the management system needs to allocate | When the PE is chosen, the management system needs to allocate | |||
interface resources on the node. One interface is selected from the | interface resources on the node. One interface is selected from the | |||
PE available pool. The management system can start provisioning the | PE available pool. The management system can start provisioning the | |||
PE node by using any mean (Netconf, CLI, ...). The management system | PE node by using any mean (NETCONF, CLI, ...). The management system | |||
will check if a VSI is already present that fits the needs. If not, | will check if a VSI is already present that fits the needs. If not, | |||
it will provision the VSI: the Route Distinguisher will come from the | it will provision the VSI: the Route Distinguisher will come from the | |||
internal allocation policy model, and the route-targets come from the | internal allocation policy model, and the route-targets come from the | |||
vpn-policy configuration of the site (management system allocated | vpn-policy configuration of the site (management system allocated | |||
some RTs for the VPN). As the site is a Spoke site (site-role), the | some RTs for the VPN). As the site is a Spoke site (site-role), the | |||
management system knows which RT must be imported and exported. As | management system knows which RT must be imported and exported. As | |||
the site is provider managed, some management route-targets may also | the site is provider managed, some management route-targets may also | |||
be added (100:5000). Standard provider VPN policies MAY also be | be added (100:5000). Standard provider VPN policies MAY also be | |||
added in the configuration. | added in the configuration. | |||
skipping to change at page 77, line 9 ¶ | skipping to change at page 77, line 9 ¶ | |||
LACP protocols will also be configured between PE and CE and due to | LACP protocols will also be configured between PE and CE and due to | |||
provider managed model, the choice is up to service provider. This | provider managed model, the choice is up to service provider. This | |||
choice is independent of the LACP protocol chosen by customer. | choice is independent of the LACP protocol chosen by customer. | |||
Example of generated PE configuration: | Example of generated PE configuration: | |||
! | ! | |||
bridge-domain 1 | bridge-domain 1 | |||
member Ethernet0/0 service-instance 100 | member Ethernet0/0 service-instance 100 | |||
member vsi one | member vsi one | |||
! | ! | |||
l2 router-id 198.51.100.1 | l2 router-id 198.51.100.1 | |||
! | ! | |||
l2 router-id 2001:db8::10:1/64 | ||||
! | ||||
interface Ethernet0/0 | interface Ethernet0/0 | |||
no ip address | no ip address | |||
service instance 100 ethernet | service instance 100 ethernet | |||
encapsulation dot1q 100 | encapsulation dot1q 100 | |||
! | ! | |||
! | ! | |||
router bgp 1 | router bgp 1 | |||
bgp log-neighbor-changes | bgp log-neighbor-changes | |||
neighbor 198.51.100.4 remote-as 1 | neighbor 198.51.100.4 remote-as 1 | |||
neighbor 198.51.100.4 update-source Loopback0 | neighbor 198.51.100.4 update-source Loopback0 | |||
! | ! | |||
address-family l2vpn vpls | address-family l2vpn vpls | |||
neighbor 198.51.100.4 activate | neighbor 198.51.100.4 activate | |||
neighbor 198.51.100.4 send-community extended | neighbor 198.51.100.4 send-community extended | |||
neighbor 198.51.100.4 suppress-signaling-protocol ldp | 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 | exit-address-family | |||
! | ! | |||
interface vlan 100 <-- Associating the Attachment | interface vlan 100 <-- Associating the Attachment | |||
no ip address Circuit with the MAC-VRF at the PE | no ip address Circuit with the MAC-VRF at the PE | |||
xconnect vsi PE1-VPLS-A | xconnect vsi PE1-VPLS-A | |||
! | ! | |||
vlan 100 | vlan 100 | |||
state active | state active | |||
skipping to change at page 81, line 39 ¶ | skipping to change at page 81, line 42 ¶ | |||
"Enable the support of QinQ."; | "Enable the support of QinQ."; | |||
} | } | |||
feature qinany { | feature qinany { | |||
description | description | |||
"Enable the support of QinAny."; | "Enable the support of QinAny."; | |||
} | } | |||
feature vxlan { | feature vxlan { | |||
description | description | |||
"Enable the support of VxLAN."; | "Enable the support of VXLAN."; | |||
} | } | |||
feature lan-tag { | feature lan-tag { | |||
description | description | |||
"Enables LAN Tag support in a VPN."; | "Enables LAN Tag support in a VPN."; | |||
} | } | |||
feature target-sites { | feature target-sites { | |||
description | description | |||
"Enables support of the 'target-sites' match flow parameter."; | "Enables support of the 'target-sites' match flow parameter."; | |||
skipping to change at page 82, line 16 ¶ | skipping to change at page 82, line 21 ¶ | |||
capabilities in a VPN."; | capabilities in a VPN."; | |||
} | } | |||
feature mac-loop-prevention { | feature mac-loop-prevention { | |||
description | description | |||
"Enables MAC Loop prevention capability in a VPN."; | "Enables MAC Loop prevention capability in a VPN."; | |||
} | } | |||
feature lacp { | feature lacp { | |||
description | description | |||
" Enables LACP capability in a VPN. "; | "Enables LACP capability in a VPN."; | |||
} | } | |||
feature mac-addr-limit{ | feature mac-addr-limit{ | |||
description | description | |||
"Enables MAC Address Limit capability in a VPN."; | "Enables MAC Address Limit capability in a VPN."; | |||
} | } | |||
feature acl { | feature acl { | |||
description | description | |||
"Enables ACL capability in a VPN. "; | "Enables ACL capability in a VPN. "; | |||
skipping to change at page 88, line 46 ¶ | skipping to change at page 89, line 6 ¶ | |||
identity vpws { | identity vpws { | |||
base service-type; | base service-type; | |||
description | description | |||
"point-to-point Virtual Private Wire Services(VPWS) type."; | "point-to-point Virtual Private Wire Services(VPWS) type."; | |||
} | } | |||
identity pwe3 { | identity pwe3 { | |||
base service-type; | base service-type; | |||
description | description | |||
"Pseudo-Wire Emulation Edge to | "Pseudo-Wire Emulation Edge to | |||
Edge(PWE3)Service type. ."; | Edge (PWE3) Service type."; | |||
} | } | |||
identity ldp-l2tp-vpls { | identity ldp-l2tp-vpls { | |||
base service-type; | base service-type; | |||
description | description | |||
"LDP based or L2TP based multipoint Virtual Private LAN | "LDP based or L2TP based multipoint Virtual Private LAN | |||
services (VPLS) Service Type.This VPLS uses LDP-signaled | services (VPLS) Service Type.This VPLS uses LDP-signaled | |||
Pseudowires or L2TP signaled Pseudowires."; | Pseudowires or L2TP signaled Pseudowires."; | |||
} | } | |||
identity bgp-vpls { | identity bgp-vpls { | |||
base service-type; | base service-type; | |||
description | description | |||
"BGP based multipoint Virtual Private LAN services (VPLS) | "BGP based multipoint Virtual Private LAN services (VPLS) | |||
Service Type. This VPLS uses a Border Gateway Protocol | Service Type. This VPLS uses a Border Gateway Protocol | |||
skipping to change at page 100, line 27 ¶ | skipping to change at page 100, line 42 ¶ | |||
description | description | |||
"Identity for packet flooding."; | "Identity for packet flooding."; | |||
} | } | |||
identity warning { | identity warning { | |||
base mac-action; | base mac-action; | |||
description | description | |||
"Identity for sending a warning log message."; | "Identity for sending a warning log message."; | |||
} | } | |||
identity load-balance-method { | ||||
description | ||||
"Base identity for load balance method."; | ||||
} | ||||
identity fat-pw { | ||||
base load-balance-method; | ||||
description | ||||
"Identity for Fat PW. Fat label is | ||||
applied to Pseudowires across MPLS | ||||
network."; | ||||
} | ||||
identity entropy-label { | ||||
base load-balance-method; | ||||
description | ||||
"Identity for entropy label.Entropy label | ||||
is applied to IP forwarding, | ||||
L2VPN or L3VPN across MPLS network"; | ||||
} | ||||
identity vxlan-source-port { | ||||
base load-balance-method; | ||||
description | ||||
"Identity for vxlan source port.VxLAN | ||||
Source Port is one load balancing method."; | ||||
} | ||||
identity qos-profile-direction { | identity qos-profile-direction { | |||
description | description | |||
"Base identity for qos profile direction."; | "Base identity for qos profile direction."; | |||
} | } | |||
identity site-to-wan { | identity site-to-wan { | |||
base qos-profile-direction; | base qos-profile-direction; | |||
description | description | |||
"Identity for Site to WAN direction."; | "Identity for Site to WAN direction."; | |||
} | } | |||
skipping to change at page 105, line 27 ¶ | skipping to change at page 105, line 15 ¶ | |||
} | } | |||
leaf port-lag-number { | leaf port-lag-number { | |||
type uint32; | type uint32; | |||
description | description | |||
"the ports/LAGs belonging to the Multicast group."; | "the ports/LAGs belonging to the Multicast group."; | |||
} | } | |||
description | description | |||
"List of Port to group mappings."; | "List of Port to group mappings."; | |||
} | } | |||
leaf bum-overall-rate { | leaf bum-overall-rate { | |||
type uint32; | type uint64; | |||
units "bps"; | units "bps"; | |||
description | description | |||
"overall rate for BUM."; | "overall rate for BUM."; | |||
} | } | |||
list bum-rate-per-type { | list bum-rate-per-type { | |||
key "type"; | key "type"; | |||
leaf type { | leaf type { | |||
type identityref { | type identityref { | |||
base bum-type; | base bum-type; | |||
} | } | |||
description | description | |||
"BUM type."; | "BUM type."; | |||
} | } | |||
leaf rate { | leaf rate { | |||
type uint32; | type uint64; | |||
units "bps"; | units "bps"; | |||
description | description | |||
"rate for BUM."; | "rate for BUM."; | |||
} | } | |||
description | description | |||
"List of rate per type."; | "List of rate per type."; | |||
} | } | |||
description | description | |||
"Container of broadcast, unknown unicast, and multicast | "Container of broadcast, unknown unicast, and multicast | |||
configurations."; | configurations."; | |||
skipping to change at page 120, line 8 ¶ | skipping to change at page 119, line 44 ¶ | |||
leaf location-id { | leaf location-id { | |||
type string; | type string; | |||
description | description | |||
"Location ID"; | "Location ID"; | |||
} | } | |||
leaf address { | leaf address { | |||
type string; | type string; | |||
description | description | |||
"Address (number and street) of the site."; | "Address (number and street) of the site."; | |||
} | } | |||
leaf zip-code { | leaf postal-code { | |||
type string; | type string; | |||
description | description | |||
"ZIP code of the site."; | "postal code of the site. The format of postal-code is | |||
similar to postal code label format defined in | ||||
RFC4119."; | ||||
} | } | |||
leaf state { | leaf state { | |||
type string; | type string; | |||
description | description | |||
"State of the site. This leaf can also be used to | "State of the site. This leaf can also be used to | |||
describe a region for country who does not have | describe a region for country who does not have | |||
states."; | states."; | |||
} | } | |||
leaf city { | leaf city { | |||
type string; | type string; | |||
description | description | |||
"City of the site."; | "City of the site."; | |||
} | } | |||
leaf country-code { | leaf country-code { | |||
type string; | type string; | |||
description | description | |||
"Country of the site."; | "Country of the site. The format of country-code is similar | |||
to country label defined in RFC4119."; | ||||
} | } | |||
description | description | |||
"List for location"; | "List for location"; | |||
} | } | |||
description | description | |||
"Location of the site."; | "Location of the site."; | |||
} | } | |||
container site-diversity { | container site-diversity { | |||
if-feature site-diversity; | if-feature site-diversity; | |||
skipping to change at page 148, line 5 ¶ | skipping to change at page 147, line 45 ¶ | |||
9. Security Considerations | 9. Security Considerations | |||
The YANG module specified in this document defines a schema for data | The YANG module specified in this document defines a schema for data | |||
that is designed to be accessed via network management protocols such | that is designed to be accessed via network management protocols such | |||
as NETCONF[RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer | as NETCONF[RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer | |||
is the secure transport layer, and the mandatory-to-implement secure | is the secure transport layer, and the mandatory-to-implement secure | |||
transport is Secure Shell (SSH)[RFC6242] . The lowest RESTCONF layer | transport is Secure Shell (SSH)[RFC6242] . The lowest RESTCONF layer | |||
is HTTPS, and the mandatory-to-implement secure transport is TLS | is HTTPS, and the mandatory-to-implement secure transport is TLS | |||
[RFC5246]. | [RFC5246]. | |||
The NETCONF access control model [RFC6536] provides the means to | The NETCONF access control model [RFC8341] provides the means to | |||
restrict access for particular NETCONF or RESTCONF users to a | restrict access for particular NETCONF or RESTCONF users to a | |||
preconfigured subset of all available NETCONF or RESTCONF protocol | preconfigured subset of all available NETCONF or RESTCONF protocol | |||
operations and content. | operations and content. | |||
There are a number of data nodes defined in this YANG module that are | There are a number of data nodes defined in this YANG module that are | |||
writable/creatable/deletable (i.e., config true, which is the | writable/creatable/deletable (i.e., config true, which is the | |||
default). These data nodes may be considered sensitive or vulnerable | default). These data nodes may be considered sensitive or vulnerable | |||
in some network environments. Write operations (e.g., edit-config) | in some network environments. Write operations (e.g., edit-config) | |||
to these data nodes without proper protection can have a negative | to these data nodes without proper protection can have a negative | |||
effect on network operations. These are the subtrees and data nodes | effect on network operations. These are the subtrees and data nodes | |||
skipping to change at page 149, line 11 ¶ | skipping to change at page 149, line 6 ¶ | |||
The data model defines some security parameters that can be extended | The data model defines some security parameters that can be extended | |||
via augmentation as part of the customer service request; those | via augmentation as part of the customer service request; those | |||
parameters are described in Section 5.12 and Section 5.13. | parameters are described in Section 5.12 and Section 5.13. | |||
10. IANA Considerations | 10. IANA Considerations | |||
IANA is requested to assign a new URI from the IETF XML registry | IANA is requested to assign a new URI from the IETF XML registry | |||
([RFC3688]). The following URI is suggested: | ([RFC3688]). The following URI is suggested: | |||
URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc | URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc | |||
Registrant Contact: L2SM WG | Registrant Contact: The IESG | |||
XML: N/A, the requested URI is an XML namespace | XML: N/A, the requested URI is an XML namespace | |||
This document also requests a new YANG module name in the YANG Module | This document also requests a new YANG module name in the YANG Module | |||
Names registry ([RFC6020]) with the following suggestion: | Names registry ([RFC6020]) with the following suggestion: | |||
name: ietf-l2vpn-svc | name: ietf-l2vpn-svc | |||
namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc | namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc | |||
prefix: l2vpn-svc | prefix: l2vpn-svc | |||
reference: RFC XXXX | reference: RFC XXXX | |||
skipping to change at page 149, line 37 ¶ | skipping to change at page 149, line 32 ¶ | |||
Special thanks to Jan Lindblat for his careful review of the YANG. | Special thanks to Jan Lindblat for his careful review of the YANG. | |||
This document has drawn on the work of the L3SM Working Group | This document has drawn on the work of the L3SM Working Group | |||
expressed in [RFC8299]. | expressed in [RFC8299]. | |||
12. References | 12. References | |||
12.1. Normative References | 12.1. Normative References | |||
[I-D.ietf-netmod-revised-datastores] | ||||
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., | ||||
and R. Wilton, "Network Management Datastore | ||||
Architecture", draft-ietf-netmod-revised-datastores-10 | ||||
(work in progress), January 2018. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, | |||
DOI 10.17487/RFC3688, January 2004, | DOI 10.17487/RFC3688, January 2004, | |||
<https://www.rfc-editor.org/info/rfc3688>. | <https://www.rfc-editor.org/info/rfc3688>. | |||
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private | [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private | |||
skipping to change at page 150, line 48 ¶ | skipping to change at page 150, line 35 ¶ | |||
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | |||
and A. Bierman, Ed., "Network Configuration Protocol | and A. Bierman, Ed., "Network Configuration Protocol | |||
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | |||
<https://www.rfc-editor.org/info/rfc6241>. | <https://www.rfc-editor.org/info/rfc6241>. | |||
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure | [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure | |||
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, | Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, | |||
<https://www.rfc-editor.org/info/rfc6242>. | <https://www.rfc-editor.org/info/rfc6242>. | |||
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration | ||||
Protocol (NETCONF) Access Control Model", RFC 6536, | ||||
DOI 10.17487/RFC6536, March 2012, | ||||
<https://www.rfc-editor.org/info/rfc6536>. | ||||
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., | [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., | |||
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based | Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based | |||
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February | Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February | |||
2015, <https://www.rfc-editor.org/info/rfc7432>. | 2015, <https://www.rfc-editor.org/info/rfc7432>. | |||
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", | [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", | |||
RFC 7950, DOI 10.17487/RFC7950, August 2016, | RFC 7950, DOI 10.17487/RFC7950, August 2016, | |||
<https://www.rfc-editor.org/info/rfc7950>. | <https://www.rfc-editor.org/info/rfc7950>. | |||
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF | [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF | |||
skipping to change at page 151, line 27 ¶ | skipping to change at page 151, line 10 ¶ | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. | [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. | |||
Rabadan, "Virtual Private Wire Service Support in Ethernet | Rabadan, "Virtual Private Wire Service Support in Ethernet | |||
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, | VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, | |||
<https://www.rfc-editor.org/info/rfc8214>. | <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>. | ||||
[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>. | ||||
12.2. Informative References | 12.2. Informative References | |||
[I-D.ietf-bess-evpn-yang] | [I-D.ietf-bess-evpn-yang] | |||
Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., | Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., | |||
and J. Rabadan, "Yang Data Model for EVPN", draft-ietf- | and J. Rabadan, "Yang Data Model for EVPN", draft-ietf- | |||
bess-evpn-yang-05 (work in progress), February 2018. | bess-evpn-yang-05 (work in progress), February 2018. | |||
[I-D.ietf-bess-l2vpn-yang] | [I-D.ietf-bess-l2vpn-yang] | |||
Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., | Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., | |||
and K. Tiruveedhula, "YANG Data Model for MPLS-based | and K. Tiruveedhula, "YANG Data Model for MPLS-based | |||
L2VPN", draft-ietf-bess-l2vpn-yang-08 (work in progress), | L2VPN", draft-ietf-bess-l2vpn-yang-08 (work in progress), | |||
February 2018. | February 2018. | |||
[I-D.ietf-netmod-yang-tree-diagrams] | ||||
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- | ||||
ietf-netmod-yang-tree-diagrams-06 (work in progress), | ||||
February 2018. | ||||
[IEEE-802-1ag] | [IEEE-802-1ag] | |||
IEEE, "802.1ag - Connectivity Fault Management", December | IEEE, "802.1ag - Connectivity Fault Management", December | |||
2007. | 2007. | |||
[IEEE-802-1D] | [IEEE-802-1D] | |||
IEEE, "802.1D-2004 - MAC Bridges", June 2004. | IEEE, "802.1D-2004 - MAC Bridges", June 2004. | |||
[ITU-T-Y-1731] | [ITU-T-Y-1731] | |||
ITU-T, "Recommendation Y.1731 - OAM functions and | ITU-T, "Recommendation Y.1731 - OAM functions and | |||
mechanisms for Ethernet based networks", February 2008. | mechanisms for Ethernet based networks", February 2008. | |||
[MEF-6] MEF Forum, "Ethernet Services Definitions - Phase 2", | ||||
April 2008. | ||||
[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>. | ||||
[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer | [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer | |||
2 Virtual Private Networks (L2VPNs)", RFC 4664, | 2 Virtual Private Networks (L2VPNs)", RFC 4664, | |||
DOI 10.17487/RFC4664, September 2006, | DOI 10.17487/RFC4664, September 2006, | |||
<https://www.rfc-editor.org/info/rfc4664>. | <https://www.rfc-editor.org/info/rfc4664>. | |||
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 | [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 | |||
Virtual Private Networks Using BGP for Auto-Discovery and | Virtual Private Networks Using BGP for Auto-Discovery and | |||
Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, | Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, | |||
<https://www.rfc-editor.org/info/rfc6624>. | <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>. | ||||
[RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., | [RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., | |||
Henderickx, W., and A. Isaac, "Requirements for Ethernet | Henderickx, W., and A. Isaac, "Requirements for Ethernet | |||
VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014, | VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014, | |||
<https://www.rfc-editor.org/info/rfc7209>. | <https://www.rfc-editor.org/info/rfc7209>. | |||
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, | [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, | |||
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual | L., Sridhar, T., Bursell, M., and C. Wright, "Virtual | |||
eXtensible Local Area Network (VXLAN): A Framework for | eXtensible Local Area Network (VXLAN): A Framework for | |||
Overlaying Virtualized Layer 2 Networks over Layer 3 | Overlaying Virtualized Layer 2 Networks over Layer 3 | |||
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, | Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, | |||
<https://www.rfc-editor.org/info/rfc7348>. | <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>. | ||||
[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module | [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module | |||
Classification", RFC 8199, DOI 10.17487/RFC8199, July | Classification", RFC 8199, DOI 10.17487/RFC8199, July | |||
2017, <https://www.rfc-editor.org/info/rfc8199>. | 2017, <https://www.rfc-editor.org/info/rfc8199>. | |||
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, | [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, | |||
"YANG Data Model for L3VPN Service Delivery", RFC 8299, | "YANG Data Model for L3VPN Service Delivery", RFC 8299, | |||
DOI 10.17487/RFC8299, January 2018, | DOI 10.17487/RFC8299, January 2018, | |||
<https://www.rfc-editor.org/info/rfc8299>. | <https://www.rfc-editor.org/info/rfc8299>. | |||
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models | [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models | |||
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, | Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, | |||
<https://www.rfc-editor.org/info/rfc8309>. | <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>. | ||||
Appendix A. Changes Log | Appendix A. Changes Log | |||
Changes in v-(01) include: | Changes in v-(01) include: | |||
o Reference Update. | o Reference Update. | |||
o Fix figure in section 3.3 and section 3.4 | o Fix figure in section 3.3 and section 3.4 | |||
o Consider VPWS, VPLS, EVPN as basic service and view EVC related | o Consider VPWS, VPLS, EVPN as basic service and view EVC related | |||
service as additional service. | service as additional service. | |||
o Model structure change, move two customer information related | o Model structure change, move two customer information related | |||
parameter into VPN Services container, remove 'customer-info | parameter into VPN Services container, remove 'customer-info | |||
'container | 'container | |||
o Redefine vpn-type to cover VPWS, VPLS, EVPN service; | o Redefine vpn-type to cover VPWS, VPLS, EVPN service; | |||
o Consolidate EVC and OVC container, make them optional since for | o Consolidate EVC and OVC container, make them optional since for | |||
End of changes. 105 change blocks. | ||||
525 lines changed or deleted | 534 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://www.tools.ietf.org/tools/rfcdiff/ |