< 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/