idnits 2.17.1
draft-ietf-l2sm-l2vpn-service-model-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 31 instances of too long lines in the document, the longest
one being 40 characters in excess of 72.
== There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 709 has weird spacing: '...site-id str...'
== Line 725 has weird spacing: '...ntifier str...'
== Line 736 has weird spacing: '...-mkt-id uin...'
== Line 755 has weird spacing: '...-rw vid ide...'
== Line 790 has weird spacing: '...roup-id str...'
== (11 more instances...)
-- The document date (July 3, 2017) is 2481 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'RFC4664' is mentioned on line 342, but not defined
== Missing Reference: 'RFC4364' is mentioned on line 3453, but not defined
== Missing Reference: 'RFC5501' is mentioned on line 1704, but not defined
== Missing Reference: 'RFC7117' is mentioned on line 1704, but not defined
== Missing Reference: 'VPN2' is mentioned on line 2367, but not defined
== Missing Reference: 'VPN3' is mentioned on line 2376, but not defined
== Unused Reference: 'RFC6991' is defined on line 7371, but no explicit
reference was found in the text
== Unused Reference: 'RFC7224' is defined on line 7375, but no explicit
reference was found in the text
== Unused Reference: 'MEF-23-2' is defined on line 7420, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341)
** Obsolete normative reference: RFC 8049 (Obsoleted by RFC 8299)
== Outdated reference: A later version (-07) exists of
draft-ietf-bess-evpn-yang-02
== Outdated reference: A later version (-10) exists of
draft-ietf-bess-l2vpn-yang-06
== Outdated reference: A later version (-05) exists of
draft-ietf-opsawg-service-model-explained-01
Summary: 3 errors (**), 0 flaws (~~), 20 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 L2SM Working Group B. Wen
3 Internet-Draft Comcast
4 Intended status: Standards Track G. Fioccola, Ed.
5 Expires: January 4, 2018 Telecom Italia
6 C. Xie
7 China Telecom
8 L. Jalil
9 Verizon
10 July 3, 2017
12 A YANG Data Model for L2VPN Service Delivery
13 draft-ietf-l2sm-l2vpn-service-model-02
15 Abstract
17 This document defines a YANG data model that can be used to configure
18 a Layer 2 Provider Provisioned VPN service.
20 This model is intended to be instantiated at management system to
21 deliver the overall service. This model is not a configuration model
22 to be used directly on network elements, but provides an abstracted
23 view of the Layer 2 VPN service configuration components. It is up
24 to a management system to take this as an input and generate specific
25 configurations models to configure the different network elements to
26 deliver the service. How configuration of network elements is done
27 is out of scope of the document.
29 The data model in this document includes support for point-to-point
30 Virtual Private Wire Services (VPWS) and multipoint Virtual Private
31 LAN services (VPLS) that use Pseudowires signaled using the Label
32 Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as
33 described in RFC4761 and RFC6624.
35 Requirements Language
37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
39 document are to be interpreted as described in [RFC2119].
41 Status of This Memo
43 This Internet-Draft is submitted in full conformance with the
44 provisions of BCP 78 and BCP 79.
46 Internet-Drafts are working documents of the Internet Engineering
47 Task Force (IETF). Note that other groups may also distribute
48 working documents as Internet-Drafts. The list of current Internet-
49 Drafts is at http://datatracker.ietf.org/drafts/current/.
51 Internet-Drafts are draft documents valid for a maximum of six months
52 and may be updated, replaced, or obsoleted by other documents at any
53 time. It is inappropriate to use Internet-Drafts as reference
54 material or to cite them other than as "work in progress."
56 This Internet-Draft will expire on January 4, 2018.
58 Copyright Notice
60 Copyright (c) 2017 IETF Trust and the persons identified as the
61 document authors. All rights reserved.
63 This document is subject to BCP 78 and the IETF Trust's Legal
64 Provisions Relating to IETF Documents
65 (http://trustee.ietf.org/license-info) in effect on the date of
66 publication of this document. Please review these documents
67 carefully, as they describe your rights and restrictions with respect
68 to this document. Code Components extracted from this document must
69 include Simplified BSD License text as described in Section 4.e of
70 the Trust Legal Provisions and are provided without warranty as
71 described in the Simplified BSD License.
73 Table of Contents
75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
76 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
77 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 5
78 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
79 3. The Layer 2 VPN Service Model . . . . . . . . . . . . . . . . 7
80 3.1. Applicability of the Layer 2 VPN Service Model . . . . . 7
81 3.2. Layer 2 VPN Service Types . . . . . . . . . . . . . . . . 8
82 3.3. Layer 2 VPN Physical Network Topology . . . . . . . . . . 9
83 3.4. Layer 2 VPN Ethernet Virtual Circuit Construct . . . . . 11
84 4. Service Data Model Usage . . . . . . . . . . . . . . . . . . 13
85 5. Design of the Data Model . . . . . . . . . . . . . . . . . . 15
86 5.1. Features and Augmentation . . . . . . . . . . . . . . . . 25
87 5.2. VPN Service Overview . . . . . . . . . . . . . . . . . . 26
88 5.2.1. Customer Information . . . . . . . . . . . . . . . . 27
89 5.2.2. VPN Service Type . . . . . . . . . . . . . . . . . . 27
90 5.2.2.1. EVC . . . . . . . . . . . . . . . . . . . . . . . 28
91 5.2.2.2. OVC . . . . . . . . . . . . . . . . . . . . . . . 28
92 5.2.3. VPN Service Topology . . . . . . . . . . . . . . . . 28
93 5.2.3.1. Route Target Allocation . . . . . . . . . . . . . 29
94 5.2.3.2. Any-to-Any . . . . . . . . . . . . . . . . . . . 29
95 5.2.3.3. Hub and Spoke . . . . . . . . . . . . . . . . . . 29
97 5.2.4. Cloud Access . . . . . . . . . . . . . . . . . . . . 30
98 5.2.5. Metro Ethernet Network Partition . . . . . . . . . . 31
99 5.2.6. Extranet VPNs . . . . . . . . . . . . . . . . . . . . 32
100 5.2.7. SVLAN ID Ethernet Tag . . . . . . . . . . . . . . . . 33
101 5.2.8. CVLAN ID Ethernet Tag . . . . . . . . . . . . . . . . 34
102 5.2.9. CVLAN ID To SVC MAP . . . . . . . . . . . . . . . . . 34
103 5.2.10. Service Level MAC Limit . . . . . . . . . . . . . . . 35
104 5.2.11. Load Balance Option . . . . . . . . . . . . . . . . . 35
105 5.2.12. Service Protection . . . . . . . . . . . . . . . . . 36
106 5.2.13. Multicast Service . . . . . . . . . . . . . . . . . . 36
107 5.3. Site Overview . . . . . . . . . . . . . . . . . . . . . . 37
108 5.3.1. Devices and Locations . . . . . . . . . . . . . . . . 39
109 5.3.2. Signaling Option . . . . . . . . . . . . . . . . . . 40
110 5.3.2.1. BGP L2VPN . . . . . . . . . . . . . . . . . . . . 41
111 5.3.2.2. BGP EVPN . . . . . . . . . . . . . . . . . . . . 41
112 5.3.2.3. LDP Pseudowires . . . . . . . . . . . . . . . . . 41
113 5.3.2.4. PWE Encapsulation Type . . . . . . . . . . . . . 42
114 5.3.2.5. PWE MTU . . . . . . . . . . . . . . . . . . . . . 42
115 5.3.2.6. Control Word . . . . . . . . . . . . . . . . . . 42
116 5.3.2.7. L2TP Pseudowires . . . . . . . . . . . . . . . . 43
117 5.3.3. Site Network Accesses . . . . . . . . . . . . . . . . 43
118 5.3.3.1. Bearer . . . . . . . . . . . . . . . . . . . . . 44
119 5.3.3.2. Connection . . . . . . . . . . . . . . . . . . . 44
120 5.4. Site Role . . . . . . . . . . . . . . . . . . . . . . . . 47
121 5.5. Site Belonging to Multiple VPNs . . . . . . . . . . . . . 47
122 5.5.1. Site VPN Flavor . . . . . . . . . . . . . . . . . . . 47
123 5.5.1.1. Single VPN Attachment: site-vpn-flavor-single . . 47
124 5.5.1.2. MultiVPN Attachment: site-vpn-flavor-multi . . . 48
125 5.5.1.3. ENNI: site-vpn-flavor-enni . . . . . . . . . . . 48
126 5.5.2. Attaching a Site to a VPN . . . . . . . . . . . . . . 49
127 5.5.2.1. Referencing a VPN . . . . . . . . . . . . . . . . 50
128 5.5.2.2. VPN Policy . . . . . . . . . . . . . . . . . . . 50
129 5.6. Deciding Where to Connect the Site . . . . . . . . . . . 53
130 5.6.1. Constraint: Device . . . . . . . . . . . . . . . . . 54
131 5.6.2. Constraint/Parameter: Site Location . . . . . . . . . 54
132 5.6.3. Constraint/Parameter: Access Type . . . . . . . . . . 56
133 5.6.4. Constraint: Access Diversity . . . . . . . . . . . . 56
134 5.7. Route Distinguisher and Network Instance Allocation . . . 58
135 5.8. Site Network Access Availability . . . . . . . . . . . . 59
136 5.9. SVC MTU . . . . . . . . . . . . . . . . . . . . . . . . . 60
137 5.10. Service . . . . . . . . . . . . . . . . . . . . . . . . . 60
138 5.10.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . 60
139 5.10.2. QoS . . . . . . . . . . . . . . . . . . . . . . . . 61
140 5.10.2.1. QoS Classification . . . . . . . . . . . . . . . 61
141 5.10.2.2. QoS Profile . . . . . . . . . . . . . . . . . . 62
142 5.10.3. Multicast . . . . . . . . . . . . . . . . . . . . . 63
143 5.11. Site Management . . . . . . . . . . . . . . . . . . . . . 64
144 5.12. Security Filtering . . . . . . . . . . . . . . . . . . . 64
145 5.12.1. MAC Loop Protection . . . . . . . . . . . . . . . . 64
146 5.12.2. MAC Address Limit . . . . . . . . . . . . . . . . . 65
147 5.13. Ethernet Service OAM . . . . . . . . . . . . . . . . . . 65
148 5.14. External ID References . . . . . . . . . . . . . . . . . 66
149 5.15. Defining NNIs and Inter-AS support . . . . . . . . . . . 66
150 5.15.1. Defining an NNI with the Option A Flavor . . . . . . 68
151 5.15.2. Defining an NNI with the Option B Flavor . . . . . . 71
152 5.15.3. Defining an NNI with the Option C Flavor . . . . . . 73
153 5.16. Inter-Provider support with EVC and OVC or NNI . . . . . 75
154 6. Interaction with Other YANG Modules . . . . . . . . . . . . . 76
155 7. Service Model Usage Example . . . . . . . . . . . . . . . . . 78
156 8. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 83
157 9. Security Considerations . . . . . . . . . . . . . . . . . . . 155
158 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 155
159 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 155
160 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 156
161 12.1. Normative References . . . . . . . . . . . . . . . . . . 156
162 12.2. Informative References . . . . . . . . . . . . . . . . . 157
163 Appendix A. Changes Log . . . . . . . . . . . . . . . . . . . . 158
164 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 160
165 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 160
167 1. Introduction
169 This document defines a YANG data model for Layer 2 VPN (L2VPN)
170 service configuration. This model is intended to be instantiated at
171 management system to allow a user (a customer or an application) to
172 request the service from a service provider. This model is not a
173 configuration model to be used directly on network elements, but
174 provides an abstracted view of the L2VPN service configuration
175 components. It is up to a management system to take this as an input
176 and generate specific configurations models to configure the
177 different network elements to deliver the service. How configuration
178 of network elements is done is out of scope of the document.
180 The data model in this document includes support for point-to-point
181 Virtual Private Wire Services (VPWS) and multipoint Virtual Private
182 LAN services (VPLS) that use Pseudowires signaled using the Label
183 Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as
184 described in [RFC4761] and [RFC6624].
186 Further discussion of the way that services are modeled in YANG and
187 of the relationship between "customer service models" like the one
188 described in this document and configuration models can be found in
189 [I-D.ietf-opsawg-service-model-explained]. Section 4 and Section 6
190 also provide more information of how this service model could be used
191 and how it fits into the overall modeling architecture.
193 1.1. Terminology
195 The following terms are defined in [RFC6241] and are not redefined
196 here:
198 o client
200 o configuration data
202 o server
204 o state data
206 The following terms are defined in [RFC6020] and are not redefined
207 here:
209 o augment
211 o data model
213 o data node
215 The terminology for describing YANG data models is found in
216 [RFC6020].
218 1.2. Tree diagram
220 A simplified graphical representation of the data model is presented
221 in Section 5.
223 The meaning of the symbols in these diagrams is as follows:
225 o Brackets "[" and "]" enclose list keys.
227 o Curly braces "{" and "}" contain names of optional features that
228 make the corresponding node conditional.
230 o Abbreviations before data node names: "rw" means configuration
231 (read-write), and "ro" state data (read-only).
233 o Symbols after data node names: "?" means an optional node and "*"
234 denotes a "list" or "leaf-list".
236 o Parentheses enclose choice and case nodes, and case nodes are also
237 marked with a colon (":").
239 o Ellipsis ("...") stands for contents of subtrees that are not
240 shown.
242 2. Definitions
244 This document uses the following terms:
246 Service Provider (SP): The organization (usually a commercial
247 undertaking) responsible for operating the network that offers VPN
248 services to clients and customers.
250 Customer Edge (CE) Device: Equipment that is dedicated to a
251 particular customer and is directly connected to one or more PE
252 devices via attachment circuits. A CE is usually located at the
253 customer premises, and is usually dedicated to a single VPN,
254 although it may support multiple VPNs if each one has separate
255 attachment circuits. The CE devices can be routers, bridges,
256 switches, or hosts.
258 Provider Edge (PE) Device: Equipment managed by the SP that can
259 support multiple VPNs for different customers, and is directly
260 connected to one or more CE devices via attachment circuits. A PE
261 is usually located at an SP point of presence (PoP) and is managed
262 by the SP.
264 Virtual Private LAN Service (VPLS): A VPLS is a provider service
265 that emulates the full functionality of a traditional Local Area
266 Network (LAN). A VPLS makes it possible to interconnect several
267 LAN segments over a packet switched network (PSN) and makes the
268 remote LAN segments behave as one single LAN.
270 Virtual Private Wire Service (VPWS): A VPWS is a point-to-point
271 circuit (i.e., link) connecting two CE devices. The link is
272 established as a logical through a packet switched network. The
273 CE in the customer network is connected to a PE in the provider
274 network via an Attachment Circuit (AC): the AC is either a
275 physical or a logical circuit. A VPWS differs from a VPLS in that
276 the VPLS is point-to-multipoint, while the VPWS is point-to-point.
277 In some implementations, a set of VPWSs is used to create a multi-
278 site L2VPN network.
280 Pseudowire(PW): A pseudowire is an emulation of a native service
281 over a packet switched network (PSN). The native service may be
282 ATM, frame relay, Ethernet, low-rate TDM, or SONET/SDH, while the
283 PSN may be MPLS, IP (either IPv4 or IPv6), or L2TPv3.
285 Ethernet Virtual Connection(EVC): An EVC is an association of two or
286 more UNIs that limits the exchange of Service Frames to UNIs in
287 the Ethernet Virtual Connection (EVC).
289 Operator Virtual Connection(OVC): An OVC is the association of UNIs
290 and ENNIs or two ENNIs within one administrative domain.
292 This document uses the following abbreviations:
294 BSS: Business Support System
296 B-U-M: Broadcast-UnknownUnicast-Multicast
298 CoS: Class of Service
300 LAG: Link Aggregation Group
302 LLDP: Link Level Discovery Protocol
304 OAM: Operations, Administration, and Maintenance
306 OSS: Operations Support System
308 PDU: Protocol Data Unit
310 QoS: Quality of Service
312 UNI: User to Network Interface
314 3. The Layer 2 VPN Service Model
316 A Layer 2 VPN service is a collection of sites that are authorized to
317 exchange traffic between each other over a shared infrastructure of a
318 common technology. This Layer 2 VPN service model (L2SM) provides a
319 common understanding of how the corresponding Layer 2 VPN service is
320 to be deployed over the shared infrastructure.
322 This document presents the L2SM using the YANG data modeling language
323 [RFC6020] as a formal language that is both human-readable and
324 parsable by software for use with protocols such as NETCONF [RFC6241]
325 and RESTCONF [RFC8040].
327 This service model is limited to VPWS and VPLS based VPNs as
328 described in [RFC4761] and [RFC6624] and EVPN as described in
329 [RFC7432].
331 3.1. Applicability of the Layer 2 VPN Service Model
333 The L2SM defined in this document applies to VPW Service, VPLS
334 service,EVPN service and Ethernet virtual circuit Services(e.g.,
335 E-Line and E-LAN service).
337 Over the past decade, The MEF Forum (MEF) has published a series of
338 technical specifications of Ethernet virtual circuit service
339 attributes and implementation agreements between providers. Many
340 Ethernet VPN service providers worldwide have adopted these MEF
341 standards and developed backoffice tools accordingly. IETF also
342 works on extending L2VPN Framework [RFC4664] to support those
343 services in the MPLS network.
345 Rather than introducing a new set of terminologies, the L2SM will
346 align with existing MEF attributes when it's applicable to Ethernet
347 Virtual Circuit Service. Therefore, service providers can easily
348 integrate any new application that leverages the L2SM data using(for
349 example, a Service Orchestrator), with existing BSS/OSS toolsets.
350 Service providers also have the option to generate L2SM data for
351 current L2VPN customer circuits already deployed in the network.
353 3.2. Layer 2 VPN Service Types
355 From technology perspective, a set of basic L2VPN service types
356 include:
358 o Point-to-point Virtual Private Wire Services (VPWS);
360 o PWE3 (Pseudo-Wire Emulation Edge to Edge) Services that use LDP-
361 signaled Pseudowires;
363 o Multipoint Virtual Private LAN services (VPLS) that use LDP-
364 signaled Pseudowires;
366 o Multipoint Virtual Private LAN services (VPLS) that use a Border
367 Gateway Protocol (BGP) control plane as described in RFC4761 and
368 RFC6624;
370 o Ethernet VPNs specified in RFC 7432;
372 o EVC Service
374 An EVC circuit can also be port-based, in which case any service
375 frames received from a subscriber within the contractual bandwidth
376 will be delivered to the corresponding remote site, regardless of the
377 customer VLAN value (C-tag) of the incoming frame. When multiple
378 service frames are received from a subscriber and each service frame
379 has different C-tag, all C-tags have to be mapped to one Ethernet
380 Service(i.e., All to One bundling). The service frames can also be
381 native Ethernet frames without a C-tag. In this scenario, only one
382 Ethernet Virtual Circuit (EVC) is allowed on a single provider to
383 subscriber link.
385 Contrary to the above use case, incoming customer service frames may
386 be split into multiple EVCs based on pre-arrangement between the
387 service provider and customer. Typically, C-tag of the incoming
388 frames will serve as the service delimiter for EVC multiplexing over
389 the same provider to subscriber interconnection.
391 Combining the port based attribute and service-multiplexing attribute
392 with the connection type (point-to-point or multipoint-to-
393 multipoint), an Ethernet Virtual Circuit may fall into one of the
394 following service types:
396 o E-Line services: Point-to-Point Layer 2 connections.
398 EPL: In its simplest form, a port-based Ethernet Private Line
399 (EPL) service provides a high degree of transparency delivering
400 all customer service frames between local and remote UNIs using
401 multiple C-tags to one EVC bundling or All-to-One Bundling [MEF
402 6.1]. All unicast/broadcast/multicast packets are delivered
403 unconditionally over the EVC. No service multiplexing is
404 allowed on an EPL UNI. Note that The UNI interface connecting
405 provider edge and customer edge devices is called an Attachment
406 Circuit (AC) and can be a physical or virtual link.
408 EVPL: On the other hand, a VLAN based Ethernet Virtual Private
409 Line (EVPL) service supports multiplexing more than one point-
410 to-point, or even other virtual private services, on the same
411 UNI. Ingress service frames are conditionally transmitted
412 through one of the EVCs based upon pre-agreed C-tag to EVC
413 mapping. EVPL supports multiple C-tags to one EVC bundling.
415 o E-LAN services: Multipoint-to-Multipoint Layer 2 connections.
417 EP-LAN: An Ethernet Private LAN Service (EP-LAN) transparently
418 connects multiple subscriber sites together with All-to-One
419 Bundling. No service multiplexing is allowed on an EP-LAN UNI.
421 EVP-LAN: Some subscribers may desire more sophisticated control
422 of data access between multiple sites. An Ethernet Virtual
423 Private LAN Service (EVP-LAN) allows multiple EVCs to be
424 connected to from one or more of the UNIs. Services frame
425 disposition is based on C-tag to EVC mapping. EVP-LAN supports
426 multiple C-tags bundled to one EVC.
428 3.3. Layer 2 VPN Physical Network Topology
430 Figure 1 depicts a typical service provider's physical network
431 topology. Most service providers have deployed an IP, MPLS, or
432 Segment Routing (SR) multi-service core infrastructure. A L2VPN
433 provides end-to-end L2 connectivity over this multi-service core
434 infrastructure between two or more locations of Customers or a
435 collection of sites. Attachment Circuit are placed between CE
436 devices and PE Devices that backhaul service frames from the customer
437 over the access network to the Provider Network or remote Site. The
438 demarcation point (i.e.,UNI) between customer and service provider
439 can be either placed between C and Customer Edge Device or between
440 Customer Edge Device and Provider Edge Device. The actual bearer,
441 connection, network access type between CE and PE will be discussed
442 in the L2SM model.
444 Site A Site B
445 --- ---- ---
446 | | | | | |
447 | C +---+ CE | | C |
448 | | | | --------- | |
449 --- ----\ ( ) /---
450 \ ---- ( ) ---- ---- /
451 \| | ( ) | | | |/
452 | PE +---+ IP/MPLS/SR +---+ PE +---+ CE |
453 /| | ( Network ) | | | |\
454 / ---- ( ) ---- ---- \
455 --- ----/ ( ) \---
456 | | | | ----+---- | |
457 | C +---+ CE | | | C |
458 | | | | --+-- | |
459 --- ---- | PE | ---
460 --+--
461 | Site C
462 --+--
463 | CE |
464 --+--
465 |
466 --+--
467 | C |
468 -----
470 Figure 1: Reference Network for the Use of the L2VPN Service Model
472 From the customer perspective, however, all the customer edge devices
473 are connected over a simulated LAN environment as shown in Figure 2.
474 Broadcast and multicast packets are sent to all participants in the
475 same bridge domain.
477 CE---+----+---+---CE
478 | | |
479 | | |
480 | | |
481 CE---+ CE +---CE
483 Figure 2: Customer View of the L2VPN
485 3.4. Layer 2 VPN Ethernet Virtual Circuit Construct
487 The base model of L2VPN EVC is shown in Figure 3.
489 Customer edge network device (CE) connects to the service provider's
490 PE equipment. The demarcation point between customer and service
491 provider devices is referred as the User Network Interface (UNI).
492 The UNI interface connecting PE and CE devices can be a physical or
493 virtual port. For clarification, this is called the UNI-C on the
494 customer side and UNI-N on the provider side.
496 The service provider is obligated to deliver the original service
497 frame from local UNI-C across the network to the remote UNI-C. All
498 Ethernet and IP header information, include (but not limit to) source
499 and destination MAC addresses, EtherType, VLAN (C-tag), Class-of-
500 Service marking (802.1p or DSCP), etc.
502 Incoming service frames are first examined at UNI-C based on C-tag,
503 Class-of-Services identifier, EtherType value. Conforming packets
504 are then metered against the contractual service bandwidth.
505 Conforming packets will be delivered to the remote UNI via the
506 Ethernet Virtual Circuit (EVC), which spans between UNI-C and UNI-C.
508 When both CEs are located in the same provider's network, a single
509 operator maintains the EVC. In this case, the EVC consists of only
510 one Operator Virtual Circuit (OVC).
512 Typically, the CE device at customer premises is a layer 2 Ethernet
513 switch. A service provider may choose to impose an outer VLAN tag
514 (S-tag) into the received subscriber traffic following 802.1ad Q-in-Q
515 standard, especially when Layer 2 aggregation devices exist between
516 CE and PE.
518 The uplink from PE to PE is referred as an Internal Network-to-
519 Network Interface (I-NNI). When 802.1ad Q-in-Q is implemented,
520 Ethernet frames from CE to PE are double tagged with both provider
521 and subscriber VLANs (S-tag, C-tag).
523 Most service providers have deployed MPLS or SR multi-service core
524 infrastructure. Ingress service frames will be mapped to either
525 Ethernet Pseudowire (PWE) or VxLAN tunnel PE-to-PE. The details of
526 these tunneling mechanism are at the provider's discretion and not
527 part of the L2SM.
529 The service provider may also choose a Seamless MPLS approach to
530 expand the PWE or VxLAN tunnel between UNI-N to UNI-N.
532 The service provider may leverage multi-protocol BGP to auto-discover
533 and signal the PWE or VxLAN tunnel end points.
535 EVC
536 :<---------------------------------->:
537 : :
538 : :
539 : OVC (Optional) :
540 :<---------------------------------->:
541 : :
542 : :
543 : PW / VXLAN :
544 : :<-------------------------->: :
545 : : : :
546 : : : :
547 : : -------- : :
548 : : ( ) : :
549 --- ---- ---- ( ) ---- ---- ---
550 | | | | | | ( ) | | | | | |
551 | C +---+ CE +---+ PE +---+ IP/MPLS/SR +---+ PE +---+ CE +---+ C |
552 | | | | | | ( Network ) | | | | | |
553 --- ---- ---- ( ) ---- ---- ---
554 ^ ^ : ( ) : :
555 : : : -------- : :
556 UNI-C UNI-N : :
557 : : : :
558 :<----->:<------>:<-------------------------->:<------>:<---->:
559 802.3 802.1Q IP/MPLS/SR Domain 802.1Q 802.3
560 q-in-q q-in-q
562 Figure 3: Architectural Model for EVC over a Single Network
564 Nevertheless, the remote site may be outside of the provider's
565 service territory. In this case, the provider may partner with the
566 operator of another metro network to provide service to the off-net
567 location as shown in Figure 4.
569 The first provider owns the customer relationship, thus the end-to-
570 end EVC. The EVC is comprised of two or more OVCs. The EVC is
571 partially composed of an OVC from local UNI-C to the inter- provider
572 interface. The provider will purchase an Ethernet Access (E-Access)
573 OVC from the second operator to deliver packet to the remote UNI-C.
575 The inter-connect between the two operators edge gateway (EG) devices
576 is defined as the External Network-to-Network Interface (E-NNI).
578 EVC
579 :<----------------------------------------------->:
580 : :
581 : :
582 : OVC (Optional) :
583 :<--------------------->: :
584 : : :
585 : : :
586 : PW / VXLAN : :
587 : :<------------------>: :
588 : : : :
589 : : : :
590 : : ----- : ----- :
591 : : ( ) : ( ) :
592 - -- -- ( IP/ ) ---- ---- ( IP/ ) -- -- -
593 |C+-+CE+-+PE+--+ MPLS/ +--+Edge+--+Edge+--+ MPLS/ +--+PE+-+CE+-+C|
594 - -- -- ( SR ) |G/W | |G/W | ( SR ) -- -- -
595 ^ ^ : ( ) ---- ---- ( ) ^
596 : : : ----- ^ ^ ----- :
597 UNI-C UNI-N
598 : ENNI :
599 : : :
600 : : : Remote
601 :<--->:<->:<------------------>: <->: Customer
602 802.3 802.1Q IP/MPLS/SR 802.1ah Site
603 q-in-q Domain q-in-q
605 Figure 4: Architectural Model for EVC over Multiple Networks
607 4. Service Data Model Usage
609 The L2VPN service model provides an abstracted interface to request,
610 configure, and manage the components of a L2VPN service. The model
611 is used by a customer who purchases connectivity and other services
612 from an SP to communicate with that SP.
614 A typical usage for this model is to be an input to an orchestration
615 layer that is responsible for translating it into configuration
616 commands for the network elements that deliver/enable the service.
617 The network elements may be routers, but also servers (like AAA) that
618 are necessary within the network.
620 The configuration of network elements may be done using the Command
621 Line Interface (CLI), or any other configuration (or "southbound")
622 interface such as NETCONF [RFC6241] in combination with device-
623 specific and protocol-specific YANG models.
625 This way of using the service model is illustrated in Figure 5 and
626 described in more detail in
627 [I-D.ietf-opsawg-service-model-explained]. The usage of this service
628 model is not limited to this example: it can be used by any component
629 of the management system, but not directly by network elements.
631 The usage and structure of this model should be compared to the Layer
632 3 VPN service model defined in [RFC8049].
634 ----------------------------
635 | Customer Service Requester |
636 ----------------------------
637 |
638 L2VPN |
639 Service |
640 Model |
641 |
642 -----------------------
643 | Service Orchestration |
644 -----------------------
645 |
646 | Service +-------------+
647 | Delivery +------>| Application |
648 | Model | | BSS/OSS |
649 | V +-------------+
650 -----------------------
651 | Network Orchestration |
652 -----------------------
653 | |
654 +----------------+ |
655 | Config manager | |
656 +----------------+ | Device
657 | | Models
658 | |
659 --------------------------------------------
660 Network
662 Figure 5: Reference Architecture for the Use of the L2VPN Service
663 Model
665 Additionally, this data model can be compared with the service
666 delivery models described in [I-D.ietf-bess-l2vpn-yang] and
667 [I-D.ietf-bess-evpn-yang] as discussed in Section 6.
669 5. Design of the Data Model
671 The L2SM model is structured in a way that allows the provider to
672 list multiple circuits of various service types for the same
673 subscriber.
675 The YANG module is divided in two main containers: vpn-services, and
676 sites. The vpn-svc container under vpn-services defines global
677 parameters for the VPN service for a specific customer.
679 A site contains at least one network access (i.e., site network
680 accesses providing access to the sites defined in Section 5.3.3) and
681 there may be multiple ports in case of multihoming. The site to
682 network access attachment is done through a bearer with a Layer 2
683 connection on top. The bearer refers to properties of the attachment
684 that are below layer 2 while the connection refers to layer 2
685 protocol oriented properties. The bearer may be allocated
686 dynamically by the service provider and the customer may provide some
687 constraints or parameters to drive the placement.
689 Authorization of traffic exchange is done through what we call a VPN
690 policy or VPN topology defining routing exchange rules between sites.
692 The figure below describe the overall structure of the YANG module:
694 module: ietf-l2vpn-svc
695 +--rw l2vpn-svc
696 +--rw vpn-services
697 | +--rw vpn-svc* [vpn-id]
698 | +--rw vpn-id svc-id
699 | +--rw vpn-type? identityref
700 | +--rw customer-account-number? uint32
701 | +--rw customer-name? string
702 | +--rw evc
703 | | +--rw enabled? boolean
704 | | +--rw evc-type? identityref
705 | | +--ro number-of-pe? uint32
706 | | +--ro number-of-site? uint32
707 | | +--rw uni-list {uni-list}?
708 | | | +--rw uni-list* [uni-site-id]
709 | | | +--rw uni-site-id string
710 | | | +--rw off-net? boolean
711 | | +--rw ce-vlan-preservation? boolean
712 | | +--rw ce-vlan-cos-perservation? boolean
713 | | +--rw service-multiplexing? boolean
714 | +--rw ovc {ovc-type}?
715 | | +--rw ovc-list* [ovc-id]
716 | | +--rw ovc-id svc-id
717 | | +--rw off-net? boolean
718 | | +--rw svlan-cos-preservation? boolean
719 | | +--rw svlan-id-preservation? boolean
720 | | +--rw svlan-id-ethernet-tag? string
721 | | +--rw ovc-endpoint? string
722 | +--rw svc-topo? identityref
723 | +--rw cloud-accesses {cloud-access}?
724 | | +--rw cloud-access* [cloud-identifier]
725 | | +--rw cloud-identifier string
726 | | +--rw (list-flavor)?
727 | | +--:(permit-any)
728 | | | +--rw permit-any? empty
729 | | +--:(deny-any-except)
730 | | | +--rw permit-site* -> /l2vpn-svc/sites/site/site-id
731 | | +--:(permit-any-except)
732 | | +--rw deny-site* -> /l2vpn-svc/sites/site/site-id
733 | +--rw metro-network-id
734 | | +--rw inter-mkt-service? boolean
735 | | +--rw intra-mkt* [metro-mkt-id mkt-name]
736 | | +--rw metro-mkt-id uint32
737 | | +--rw mkt-name string
738 | | +--rw ovc-id? -> /l2vpn-svc/vpn-services/vpn-svc/ovc/ovc-list/ovc-id
739 | | +--rw site-id? -> /l2vpn-svc/sites/site/site-id
740 | +--rw global-l2cp-control {L2CP-control}?
741 | | +--rw stp-rstp-mstp? control-mode
742 | | +--rw pause? control-mode
743 | | +--rw lldp? boolean
744 | +--rw load-balance-options
745 | | +--rw fat-pw? boolean
746 | | +--rw entropy-label? boolean
747 | | +--rw vxlan-source-port? string
748 | +--rw service-level-mac-limit? string
749 | +--rw service-protection
750 | | +--rw protection-model? identityref
751 | +--rw cvlan-id-to-svc-map* [svc-id type]
752 | | +--rw svc-id -> /l2vpn-svc/vpn-services/vpn-svc/vpn-id
753 | | +--rw type identityref
754 | | +--rw cvlan-id* [vid]
755 | | +--rw vid identityref
756 | +--rw multicast {multicast}?
757 | | +--rw enabled? boolean
758 | | +--rw customer-tree-flavors
759 | | | +--rw tree-flavor* identityref
760 | | +--rw traffic-type? identityref
761 | | +--rw group-port-mapping? identityref
762 | +--rw extranet-vpns {extranet-vpn}?
763 | +--rw extranet-vpn* [vpn-id]
764 | +--rw vpn-id svc-id
765 | +--rw local-sites-role? identityref
766 +--rw sites
767 +--rw site* [site-id site-type]
768 +--rw site-id string
769 +--rw site-type identityref
770 +--rw device
771 | +--rw devices* [device-id]
772 | +--rw device-id string
773 | +--rw location? -> /l2vpn-svc/sites/site/locations/location/location-id
774 | +--rw management
775 | +--rw address? inet:ip-address
776 | +--rw management-transport? identityref
777 +--rw locations
778 | +--rw location* [location-id]
779 | +--rw location-id string
780 | +--rw address? string
781 | +--rw zip-code? string
782 | +--rw state? string
783 | +--rw city? string
784 | +--rw country-code? string
785 +--rw management
786 | +--rw type? identityref
787 +--rw site-diversity {site-diversity}?
788 | +--rw groups
789 | +--rw group* [group-id]
790 | +--rw group-id string
791 +--rw vpn-policies
792 | +--rw vpn-policy* [vpn-policy-id]
793 | +--rw vpn-policy-id string
794 | +--rw entries* [id]
795 | +--rw id string
796 | +--rw filter
797 | | +--rw (lan)?
798 | | +--:(lan-tag)
799 | | +--rw lan-tag* string
800 | +--rw vpn
801 | +--rw vpn-id -> /l2vpn-svc/vpn-services/vpn-svc/vpn-id
802 | +--rw site-role? identityref
803 +--rw signaling-options {signaling-options}?
804 | +--rw signaling-options* [type]
805 | +--rw type identityref
806 | +--rw bgp-l2vpn
807 | | +--rw vpn-id? -> /l2vpn-svc/vpn-services/vpn-svc/vpn-id
808 | | +--rw type? identityref
809 | | +--rw address-family? identityref
810 | +--rw mp-bgp-evpn
811 | | +--rw vpn-id? -> /l2vpn-svc/vpn-services/vpn-svc/vpn-id
812 | | +--rw type? identityref
813 | | +--rw address-family? identityref
814 | | +--rw pwe-encapsulation-type? identityref
815 | | +--rw pwe-mtu
816 | | | +--rw allow-mtu-mismatch? boolean
817 | | +--rw mac-learning-mode? identityref
818 | | +--rw arp-suppress? boolean
819 | +--rw t-ldp-pwe
820 | | +--rw type? identityref
821 | | +--rw pe-eg-list* [service-ip-addr vc-id]
822 | | | +--rw service-ip-addr inet:ip-address
823 | | | +--rw vc-id string
824 | | +--rw control-word? boolean
825 | | +--rw qinq
826 | | +--rw s-tag? uint32
827 | | +--rw c-tag? uint32
828 | +--rw l2tp-pw
829 | +--rw encapsulation-type? identityref
830 | +--rw control-word
831 +--rw load-balance-options
832 | +--rw fat-pw? boolean
833 | +--rw entropy-label? boolean
834 | +--rw vxlan-source-port? string
835 +--rw service
836 | +--rw qos {qos}?
837 | +--rw qos-classification-policy
838 | | +--rw rule* [id]
839 | | +--rw id uint16
840 | | +--rw (match-type)?
841 | | | +--:(match-flow)
842 | | | | +--rw match-flow
843 | | | | +--rw dscp? inet:dscp
844 | | | | +--rw dot1p? uint8
845 | | | | +--rw pcp? uint8
846 | | | | +--rw src-mac? yang:mac-address
847 | | | | +--rw dst-mac? yang:mac-address
848 | | | | +--rw composite-id
849 | | | | | +--rw endpoint-id? string
850 | | | | | +--rw cos-label? identityref
851 | | | | | +--rw pcp? uint8
852 | | | | | +--rw dscp? inet:dscp
853 | | | | +--rw color-type? identityref
854 | | | | +--rw target-sites* svc-id
855 | | | +--:(match-phy-port)
856 | | | +--rw match-phy-port? uint16
857 | | +--rw target-class-id? string
858 | +--rw qos-profile
859 | +--rw (qos-profile)?
860 | +--:(standard)
861 | | +--rw ingress-profile? string
862 | | +--rw egress-profile? string
863 | +--:(custom)
864 | +--rw classes {qos-custom}?
865 | +--rw class* [class-id]
866 | +--rw class-id string
867 | +--rw direction? direction-type
868 | +--rw policing? identityref
869 | +--rw byte-offset? uint16
870 | +--rw rate-limit? uint8
871 | +--rw discard-percentage? uint8
872 | +--rw frame-delay
873 | | +--rw (flavor)?
874 | | +--:(lowest)
875 | | | +--rw use-low-del? empty
876 | | +--:(boundary)
877 | | +--rw delay-bound? uint16
878 | +--rw frame-jitter
879 | | +--rw (flavor)?
880 | | +--:(lowest)
881 | | | +--rw use-low-jit? empty
882 | | +--:(boundary)
883 | | +--rw delay-bound? uint32
884 | +--rw frame-loss
885 | | +--rw fr-loss-rate? decimal64
886 | +--rw bandwidth
887 | +--rw guaranteed-bw-percent? uint8
888 | +--rw end-to-end? empty
889 +--rw broadcast-unknown-unicast-multicast
890 | +--rw multicast-site-type? enumeration
891 | +--rw multicast-gp-address-mapping* [id]
892 | | +--rw id uint16
893 | | +--rw vlan-id? uint32
894 | | +--rw mac-gp-address? yang:mac-address
895 | | +--rw port-lag-number? uint32
896 | +--rw bum-overall-rate? uint32
897 | +--rw bum-rate-per-type* [type]
898 | +--rw type identityref
899 | +--rw rate? uint32
900 +--rw security-filtering
901 | +--rw mac-loop-prevention
902 | | +--rw frequency? uint32
903 | | +--rw protection-type? identityref
904 | | +--rw number-retries? uint32
905 | +--rw access-control-list
906 | | +--rw mac* [mac-address]
907 | | +--rw mac-address yang:mac-address
908 | +--rw mac-addr-limit
909 | +--rw exceeding-option? uint32
910 +--ro actual-site-start? yang:date-and-time
911 +--ro actual-site-stop? yang:date-and-time
912 +--rw site-network-accesses
913 +--rw site-network-accesse* [network-access-id]
914 +--rw network-access-id string
915 +--rw remote-carrier-name? string
916 +--rw access-diversity {site-diversity}?
917 | +--rw groups
918 | | +--rw fate-sharing-group-size? uint16
919 | | +--rw group* [group-id]
920 | | +--rw group-id string
921 | +--rw constraints
922 | +--rw constraint* [constraint-type]
923 | +--rw constraint-type identityref
924 | +--rw target
925 | +--rw (target-flavor)?
926 | +--:(id)
927 | | +--rw group* [group-id]
928 | | +--rw group-id string
929 | +--:(all-accesses)
930 | | +--rw all-other-accesses? empty
931 | +--:(all-groups)
932 | +--rw all-other-groups? empty
933 +--rw bearer
934 | +--rw requested-type {requested-type}?
935 | | +--rw requested-type? string
936 | | +--rw strict? boolean
937 | | +--rw request-type-profile
938 | | +--rw (request-type-choice)?
939 | | +--:(dot1q-case)
940 | | | +--rw dot1q
941 | | | +--rw physical-if? string
942 | | | +--rw vlan-id? uint16
943 | | +--:(physical-case)
944 | | +--rw physical-if? string
945 | | +--rw circuit-id? string
946 | +--rw always-on? boolean {always-on}?
947 | +--rw bearer-reference? string {bearer-reference}?
948 +--rw connection
949 | +--rw encapsulation-type
950 | | +--rw encapsulation-type? identityref
951 | | +--rw eth-type? identityref
952 | +--rw esi? string
953 | +--rw interface-description? string
954 | +--rw sub-if-id? uint32
955 | +--rw vlan {vlan}?
956 | | +--rw vlan-id? uint32
957 | +--rw dot1q {dot1q}?
958 | | +--rw physical-inf? string
959 | | +--rw c-vlan-id? uint32
960 | +--rw qinq {qinq}?
961 | | +--rw s-vlan-id? uint32
962 | | +--rw c-vlan-id? uint32
963 | +--rw qinany {qinany}?
964 | | +--rw s-vlan-id? uint32
965 | +--rw vxlan {vxlan}?
966 | | +--rw vni-id? uint32
967 | | +--rw peer-list* [peer-ip]
968 | | +--rw peer-ip inet:ip-address
969 | +--rw phy-interface
970 | | +--rw port-number? uint32
971 | | +--rw port-speed? uint32
972 | | +--rw mode? neg-mode
973 | | +--rw phy-mtu? uint32
974 | | +--rw flow-control? string
975 | | +--rw encapsulation-type? identityref
976 | | +--rw ethertype? identityref
977 | | +--rw lldp? boolean
978 | | +--rw oam-802.3ah-link {oam-3ah}?
979 | | | +--rw enable? boolean
980 | | +--rw uni-loop-prevention? boolean
981 | +--rw lag-interface {lag-interface}?
982 | | +--rw lag-interface* [lag-interface-number]
983 | | +--rw lag-interface-number uint32
984 | | +--rw lacp
985 | | +--rw lacp-state? boolean
986 | | +--rw lacp-mode? boolean
987 | | +--rw lacp-speed? boolean
988 | | +--rw mini-link? uint32
989 | | +--rw system-priority? uint16
990 | | +--rw micro-bfd {micro-bfd}?
991 | | | +--rw micro-bfd-on-off? enumeration
992 | | | +--rw bfd-interval? uint32
993 | | | +--rw bfd-hold-timer? uint32
994 | | +--rw bfd {bfd}?
995 | | | +--rw bfd-enabled? boolean
996 | | | +--rw (holdtime)?
997 | | | +--:(profile)
998 | | | | +--rw profile-name? string
999 | | | +--:(fixed)
1000 | | | +--rw fixed-value? uint32
1001 | | +--rw member-link-list
1002 | | | +--rw member-link* [name]
1003 | | | +--rw name string
1004 | | | +--rw port-speed? uint32
1005 | | | +--rw mode? neg-mode
1006 | | | +--rw mtu? uint32
1007 | | | +--rw oam-802.3ah-link {oam-3ah}?
1008 | | | +--rw enable? boolean
1009 | | +--rw flow-control? string
1010 | | +--rw encapsulation-type? identityref
1011 | | +--rw ethertype? identityref
1012 | | +--rw lldp? boolean
1013 | +--rw l2cp-control {L2CP-control}?
1014 | +--rw stp-rstp-mstp? control-mode
1015 | +--rw pause? control-mode
1016 | +--rw lacp-lamp? control-mode
1017 | +--rw link-oam? control-mode
1018 | +--rw esmc? control-mode
1019 | +--rw l2cp-802.1x? control-mode
1020 | +--rw e-lmi? control-mode
1021 | +--rw lldp? boolean
1022 | +--rw ptp-peer-delay? control-mode
1023 | +--rw garp-mrp? control-mode
1024 | +--rw provider-bridge-group? control-mode
1025 | +--rw provider-bridge-mvrp? control-mode
1026 +--rw svc-mtu? uint32
1027 +--rw availability
1028 | +--rw access-priority? uint32
1029 | +--rw (redundancy-mode)?
1030 | +--:(single-active)
1031 | | +--rw single-active? boolean
1032 | +--:(all-active)
1033 | +--rw all-active? boolean
1034 +--rw vpn-attachment
1035 | +--rw device-id? string
1036 | +--rw management
1037 | | +--rw address-family? identityref
1038 | | +--rw address? inet:ip-address
1039 | +--rw (attachment-flavor)
1040 | +--:(vpn-flavor)
1041 | | +--rw vpn-flavor* [vpn-id]
1042 | | +--rw vpn-id -> /l2vpn-svc/vpn-services/vpn-svc/vpn-id
1043 | | +--rw site-role? identityref
1044 | +--:(vpn-policy-id)
1045 | +--rw vpn-policy-id? -> /l2vpn-svc/sites/site/vpn-policies/vpn-policy/vpn-policy-id
1046 +--rw service
1047 | +--rw svc-input-bandwidth {input-bw}?
1048 | | +--rw input-bandwidth* [type]
1049 | | +--rw type identityref
1050 | | +--rw cos-id? uint8
1051 | | +--rw vpn-id? svc-id
1052 | | +--rw CIR? uint64
1053 | | +--rw CBS? uint64
1054 | | +--rw EIR? uint64
1055 | | +--rw EBS? uint64
1056 | | +--rw CM? uint8
1057 | +--rw svc-output-bandwidth {output-bw}?
1058 | | +--rw output-bandwidth* [type]
1059 | | +--rw type identityref
1060 | | +--rw cos-id? uint8
1061 | | +--rw vpn-id? svc-id
1062 | | +--rw CIR? uint64
1063 | | +--rw CBS? uint64
1064 | | +--rw EIR? uint64
1065 | | +--rw EBS? uint64
1066 | | +--rw CM? uint8
1067 | +--rw qos {qos}?
1068 | +--rw qos-classification-policy
1069 | | +--rw rule* [id]
1070 | | +--rw id uint16
1071 | | +--rw (match-type)?
1072 | | | +--:(match-flow)
1073 | | | | +--rw match-flow
1074 | | | | +--rw dscp? inet:dscp
1075 | | | | +--rw dot1p? uint8
1076 | | | | +--rw pcp? uint8
1077 | | | | +--rw src-mac? yang:mac-address
1078 | | | | +--rw dst-mac? yang:mac-address
1079 | | | | +--rw composite-id
1080 | | | | | +--rw endpoint-id? string
1081 | | | | | +--rw cos-label? identityref
1082 | | | | | +--rw pcp? uint8
1083 | | | | | +--rw dscp? inet:dscp
1084 | | | | +--rw color-type? identityref
1085 | | | | +--rw target-sites* svc-id
1086 | | | +--:(match-phy-port)
1087 | | | +--rw match-phy-port? uint16
1088 | | +--rw target-class-id? string
1089 | +--rw qos-profile
1090 | +--rw (qos-profile)?
1091 | +--:(standard)
1092 | | +--rw ingress-profile? string
1093 | | +--rw egress-profile? string
1094 | +--:(custom)
1095 | +--rw classes {qos-custom}?
1096 | +--rw class* [class-id]
1097 | +--rw class-id string
1098 | +--rw direction? direction-type
1099 | +--rw policing? identityref
1100 | +--rw byte-offset? uint16
1101 | +--rw rate-limit? uint8
1102 | +--rw discard-percentage? uint8
1103 | +--rw frame-delay
1104 | | +--rw (flavor)?
1105 | | +--:(lowest)
1106 | | | +--rw use-low-del? empty
1107 | | +--:(boundary)
1108 | | +--rw delay-bound? uint16
1109 | +--rw frame-jitter
1110 | | +--rw (flavor)?
1111 | | +--:(lowest)
1112 | | | +--rw use-low-jit? empty
1113 | | +--:(boundary)
1114 | | +--rw delay-bound? uint32
1115 | +--rw frame-loss
1116 | | +--rw fr-loss-rate? decimal64
1117 | +--rw bandwidth
1118 | +--rw guaranteed-bw-percent? uint8
1119 | +--rw end-to-end? empty
1120 +--rw broadcast-unknown-unicast-multicast
1121 | +--rw multicast-site-type? enumeration
1122 | +--rw multicast-gp-address-mapping* [id]
1123 | | +--rw id uint16
1124 | | +--rw vlan-id? uint32
1125 | | +--rw mac-gp-address? yang:mac-address
1126 | | +--rw port-lag-number? uint32
1127 | +--rw bum-overall-rate? uint32
1128 | +--rw bum-rate-per-type* [type]
1129 | +--rw type identityref
1130 | +--rw rate? uint32
1131 +--rw ethernet-service-oam
1132 | +--rw md-name? string
1133 | +--rw md-level? uint8
1134 | +--rw cfm-802.1-ag
1135 | | +--rw n2-uni-c* [maid]
1136 | | | +--rw maid string
1137 | | | +--rw mep-id? uint32
1138 | | | +--rw mep-level? uint32
1139 | | | +--rw mep-up-down? enumeration
1140 | | | +--rw remote-mep-id? uint32
1141 | | | +--rw cos-for-cfm-pdus? uint32
1142 | | | +--rw ccm-interval? uint32
1143 | | | +--rw ccm-holdtime? uint32
1144 | | | +--rw alarm-priority-defect? identityref
1145 | | | +--rw ccm-p-bits-pri? ccm-priority-type
1146 | | +--rw n2-uni-n* [maid]
1147 | | +--rw maid string
1148 | | +--rw mep-id? uint32
1149 | | +--rw mep-level? uint32
1150 | | +--rw mep-up-down? enumeration
1151 | | +--rw remote-mep-id? uint32
1152 | | +--rw cos-for-cfm-pdus? uint32
1153 | | +--rw ccm-interval? uint32
1154 | | +--rw ccm-holdtime? uint32
1155 | | +--rw alarm-priority-defect? identityref
1156 | | +--rw ccm-p-bits-pri? ccm-priority-type
1157 | +--rw y-1731* [maid]
1158 | +--rw maid string
1159 | +--rw mep-id? uint32
1160 | +--rw type? identityref
1161 | +--rw remote-mep-id? uint32
1162 | +--rw message-period? uint32
1163 | +--rw measurement-interval? uint32
1164 | +--rw cos? uint32
1165 | +--rw loss-measurement? boolean
1166 | +--rw synthethic-loss-measurement? boolean
1167 | +--rw delay-measurement
1168 | | +--rw enable-dm? boolean
1169 | | +--rw two-way? boolean
1170 | +--rw frame-size? uint32
1171 | +--rw session-type? enumeration
1172 +--rw security-filtering
1173 +--rw mac-loop-prevention
1174 | +--rw frequency? uint32
1175 | +--rw protection-type? identityref
1176 | +--rw number-retries? uint32
1177 +--rw access-control-list
1178 | +--rw mac* [mac-address]
1179 | +--rw mac-address yang:mac-address
1180 +--rw mac-addr-limit
1181 +--rw exceeding-option? uint32
1183 Figure 6
1185 5.1. Features and Augmentation
1187 The model defined in this document implements many features that
1188 allow implementations to be modular. As an example, the layer 2
1189 protocols parameters proposed to the customer may also be enabled
1190 through features. This model also proposes some features for options
1191 that are more advanced, such as support for extranet VPNs
1192 (Section 5.2.6), site diversity (Section 5.6), and QoS
1193 (Section 5.10.2).
1195 In addition, as for any YANG model, this service model can be
1196 augmented to implement new behaviors or specific features.
1198 5.2. VPN Service Overview
1200 A vpn-service list item contains generic informations about the VPN
1201 service. The vpn-id of the vpn-service refers to an internal
1202 reference for this VPN service. This identifier is purely internal
1203 to the organization responsible for the VPN service.
1205 A vpn-service is composed of some characteristics:
1207 Customer information: Used to identify the subscriber.
1209 VPN Type (vpn-type): Used to indicate VPN service Type. The
1210 identifier is a string allowing to any encoding for the local
1211 administration of the VPN service.
1213 Ethernet Connection Service Type (evc-type): used to identify
1214 supported Ethernet Connection Service Types.
1216 Cloud Access (cloud-access): All sites in the L2VPN MUST be
1217 authorized to access to the cloud.The cloud-access container
1218 provides parameters for authorization rules. A cloud identifier
1219 is used to reference the target service. This identifier is local
1220 to each administration.
1222 Service Topology (svc-topo): Used to identify the type of VPN
1223 service topology is required for configuration.
1225 Metro Network Partition: Used by service provide to divide the
1226 network into several administrative domains.
1228 VPN Signaling (vpn-signaling-option): Defines which protocol or
1229 signaling must be activated between the subscriber and the
1230 provider.
1232 Load Balance (load-balance-option): Intended to capture the load-
1233 balance agreement between the subscriber and provider.
1235 SVLAN ID Ethernet Tag: Used to identify the service-wide "normalized
1236 S-tag".
1238 CVLAN ID To EVC MAP: Contains the list of customer vlans to the
1239 service mapping in a free-form format. In most cases, this will
1240 be the VLAN access-list for the inner 802.1q tags.
1242 Service Level MAC Limit: Contains the subscriber MAC address limit
1243 and exceeding action information.
1245 Service Protection (svc-protection): Capture the desired service
1246 protection agreement between subscriber and provider.
1248 5.2.1. Customer Information
1250 The customer information contains two essential information to
1251 identify the subscriber.
1253 "customer-account-number" is an internal alphanumerical number
1254 assigned by the service provider to identify the subscriber. It MUST
1255 be unique within the service provider's OSS/BSS system. The actual
1256 format depends on the system tool the provider uses. "customer-name"
1257 is in a more readable form and refers to a more-explicit reference to
1258 the customer. Both identifiers are purely internal to the
1259 organization responsible for the VPN service.
1261 5.2.2. VPN Service Type
1263 The "svc-type" defines service type for provider provisioned L2VPNs.
1264 The current version of the model supports ten flavors:
1266 o Point-to-point Virtual Private Wire Services (VPWS);
1268 o PWE3 (Pseudo-Wire Emulation Edge to Edge) that use LDP-signaled
1269 Pseudowires;
1271 o Multipoint Virtual Private LAN services (VPLS) that use LDP-
1272 signaled Pseudowires;
1274 o Multipoint Virtual Private LAN services (VPLS) that use a Border
1275 Gateway Protocol (BGP) control plane as described in RFC4761 and
1276 RFC6624;
1278 o Ethernet VPNs specified in RFC 7432;
1280 o Ethernet Private Line (EPL) Service with PW core;
1282 o Ethernet Virtual Private Line (EVPL) Service with PW core;
1284 o Ethernet Private LAN (EP-LAN)Service with VPLS core;
1285 o Ethernet Virtual Private LAN (EVP-LAN)Service with VPLS core
1287 Other L2VPN Service Type could be included by augmentation. Note
1288 that EPL service and EVPL service are E-Line service or point to
1289 point EVC service while EP-LAN service and EVP-LAN service are E-LAN
1290 service or multiple point to multipoint EVC service.
1292 5.2.2.1. EVC
1294 The "evc" container contains "enable" leafand "uni-list" container.
1295 If EVC service for Provider provision L2VPN is required, the
1296 "enabled" leaf MUST be set to true in the "evc" container. "uni-list"
1297 will specify the UNI list associated with this EVC service.
1299 In addition, "evc-type","number of PEs" and "number of sites" can be
1300 specified under the "evc" container.The "evc-type" defines three EVC
1301 service types: Point-to-Point,Multipoint-to-Multipoint, Rooted-
1302 Multipoint. New Ethernet Connection service types can be added by
1303 augmentation in the future.
1305 E-Line and E-LAN providers shall have an EVC-ID assigned to the UNI-
1306 to-UNI circuit.EVC-ID value will be set to the same VPN-id value
1307 under vpn-service list.
1309 5.2.2.2. OVC
1311 The "ovc-list" under "ovc" container defines a list of "ovc-id"
1312 parameter associated with "evc" and a "off-net" leaf. The "off-net"
1313 leaf MUST be set to true if one of external interface of "ovc" is UNI
1314 and this UNI can not be reachable by the subscriber or local site.
1316 For E-Access service as an OVC-based service, the "on-net" leaf MUST
1317 be marked TRUE, and The E-Access service provider will assign an OVC-
1318 ID for the circuit between UNI and E-NNI.
1320 If the service is E-Line or E-LAN with remote UNIs, there will be
1321 one, and only one, on-net "ovc-id" and a list of off-net "ovc-id"
1322 objects for the remote UNIs.
1324 5.2.3. VPN Service Topology
1326 The type of VPN service topology can be used for configuration if
1327 needed. The module currently supports: any-to-any, hub and spoke
1328 (where hubs can exchange traffic), and hub and spoke disjoint (where
1329 hubs cannot exchange traffic). New topologies could be added by
1330 augmentation. By default, the any-to-any VPN service topology is
1331 used.
1333 5.2.3.1. Route Target Allocation
1335 A Layer 2 PE-based VPN (such as VPLS based VPN that uses BGP as
1336 signaling protocol or EVPN) can be built using route targets (RTs) as
1337 described in [RFC4364]. The management system is expected to
1338 automatically allocate a set of RTs upon receiving a VPN service
1339 creation request. How the management system allocates RTs is out of
1340 scope for this document, but multiple ways could be envisaged, as
1341 described in the section 6.2.1.1 of [RFC8049].
1343 5.2.3.2. Any-to-Any
1345 +------------------------------------------------------------+
1346 | VPN1_Site1 ------ PE1 PE2 ------ VPN1_Site2 |
1347 | |
1348 | VPN1_Site3 ------ PE3 PE4 ------ VPN1_Site4 |
1349 +------------------------------------------------------------+
1351 Any-to-Any VPN Service Topology
1353 In the any-to-any VPN service topology, all VPN sites can communicate
1354 with each other without any restrictions. The management system that
1355 receives an any-to-any L2VPN service request through this model is
1356 expected to assign and then configure the VFI/VSI/EVI and RTs on the
1357 appropriate PEs. In the any-to-any case, a single RT is generally
1358 required, and every VFI/VSI/EVI imports and exports this RT.
1360 5.2.3.3. Hub and Spoke
1362 +-------------------------------------------------------------+
1363 | Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
1364 | +----------------------------------+
1365 | |
1366 | +----------------------------------+
1367 | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
1368 +-------------------------------------------------------------+
1370 Hub-and-Spoke VPN Service Topology
1372 In the Hub-and-Spoke VPN service topology, all Spoke sites can
1373 communicate only with Hub sites but not with each other, and Hubs can
1374 also communicate with each other. The management system that owns an
1375 any-to-any L2 VPN service request through this model is expected to
1376 assign and then configure the VFI/VSI/EVI and RTs on the appropriate
1377 PEs. In the Hub-and-Spoke case, two RTs are generally required (one
1378 RT for Hub routes and one RT for Spoke routes). A Hub VFI/VSI/EVI
1379 that connects Hub sites will export Hub routes with the Hub RT and
1380 will import Spoke routes through the Spoke RT. It will also import
1381 the Hub RT to allow Hub-to-Hub communication. A Spoke VFI/VSI/EVI
1382 that connects Spoke sites will export Spoke routes with the Spoke RT
1383 and will import Hub routes through the Hub RT.
1385 5.2.4. Cloud Access
1387 This model provides cloud access configuration through the cloud-
1388 access container. The usage of cloud-access is targeted for public
1389 cloud and Internet Access. The cloud-access container provides
1390 parameters for authorization rules.
1392 Private cloud access may be addressed through the site contianer as
1393 described in Section 5.3 with the use consistent with sites of type
1394 E-NNI.
1396 A cloud identifier is used to reference the target service. This
1397 identifier is local to each administration.
1399 By default, all sites in the IP VPN MUST be authorized to access the
1400 cloud. If restrictions are required, a user MAY configure the
1401 "permit-site" or "deny-site" leaf-list. The permit-site leaf-list
1402 defines the list of sites authorized for cloud access. The deny-site
1403 leaf-list defines the list of sites denied for cloud access. The
1404 model supports both "deny-any-except" and "permit-any-except"
1405 authorization.
1407 How the restrictions will be configured on network elements is out of
1408 scope for this document.
1410 L2VPN
1411 ++++++++++++++++++++++++++++++++ ++++++++++++
1412 + Site 3 + --- + Cloud 1 +
1413 + Site 1 + ++++++++++++
1414 + +
1415 + Site 2 + --- ++++++++++++
1416 + + + Internet +
1417 + Site 4 + ++++++++++++
1418 ++++++++++++++++++++++++++++++++
1419 |
1420 +++++++++++
1421 + Cloud 2 +
1422 +++++++++++
1424 In the example above, we configure the global VPN to access the
1425 Internet by creating a cloud-access pointing to the cloud identifier
1426 for the Internet service. No authorized sites will be configured, as
1427 all sites are required to access the Internet.
1429
1430 123456487
1431
1432
1433 INTERNET
1434
1435
1436
1438 If Site 1 and Site 2 require access to Cloud 1, a new cloud-access
1439 pointing to the cloud identifier of Cloud 1 will be created. The
1440 permit-site leaf-list will be filled with a reference to Site 1 and
1441 Site 2.
1443
1444 123456487
1445
1446
1447 Cloud1
1448 site1
1449 site2
1450
1451
1452
1454 If all sites except Site 1 require access to Cloud 2, a new cloud-
1455 access pointing to the cloud identifier of Cloud 2 will be created.
1456 The deny-site leaf-list will be filled with a reference to Site 1.
1458
1459 123456487
1460
1461
1462 Cloud2
1463 site1
1464
1465
1466
1468 5.2.5. Metro Ethernet Network Partition
1470 Some service providers may divide their Metro Ethernet network into
1471 multiple administrative domains. And a EVC service may span across
1472 multiple such administrative domains belonging to the same service
1473 provider and be concatenated by one or multiple OVC segments. Each
1474 administrative domain has corresponding OVC segment. The optional
1475 "metro-networks" container is intended be used by these multi-domain
1476 providers to differentiate intra-market versus inter-market services.
1478 When the "inter-mkt-service" leaf is marked TRUE, multiple associated
1479 "metro-mkt-id"s will be listed. Otherwise, the service is intra-
1480 domain and only one "metro-mkt-id" is allowed.
1482 | |
1483 UNI | ENNI ENNI UNI|
1484 +-----------+ | -------- | -------- | -------- |+-----------+
1485 | | | / \ | / \ | / \ || |
1486 | New York | || Acccess |||Transport ||| Service ||| Paris |
1487 | Site | || Provider ||| Provider ||| Provider ||| Site |
1488 | | || #1 ||| #2 ||| #3 ||| |
1489 +-----------+ | \ / | \ / | \ / |+-----------+
1490 | -------- | -------- | -------- |
1491 | | EVC | |
1492 |<------------------------------------>|
1493 | | | |
1494 | OVC1 | OVC2 | OVC3 |
1495 |<---------->|<---------->|<---------->|
1496 | | | |
1498 5.2.6. Extranet VPNs
1500 There are some cases where a particular VPN needs access to resources
1501 (servers, hosts, etc.) that are external. Those resources may be
1502 located in another VPN.
1504 +-----------+ +-----------+
1505 / \ / \
1506 Site A -- | VPN A | --- | VPN B | --- Site B
1507 \ / \ / (Shared
1508 +-----------+ +-----------+ resources)
1510 In the figure above, VPN B has some resources on Site B that need to
1511 be available to some customers/partners. VPN A must be able to
1512 access those VPN B resources.
1514 Such a VPN connection scenario can be achieved via a VPN policy as
1515 defined in Section 5.5.2.2. But there are some simple cases where a
1516 particular VPN (VPN A) needs access to all resources in another VPN
1517 (VPN B). The model provides an easy way to set up this connection
1518 using the "extranet-vpns" container.
1520 The extranet-vpns container defines a list of VPNs a particular VPN
1521 wants to access. The extranet-vpns container must be used on
1522 customer VPNs accessing extranet resources in another VPN. In the
1523 figure above, in order to provide VPN A with access to VPN B, the
1524 extranet-vpns container needs to be configured under VPN A with an
1525 entry corresponding to VPN B. There is no service configuration
1526 requirement on VPN B.
1528 Readers should note that even if there is no configuration
1529 requirement on VPN B, if VPN A lists VPN B as an extranet, all sites
1530 in VPN B will gain access to all sites in VPN A.
1532 The "site-role" leaf defines the role of the local VPN sites in the
1533 target extranet VPN service topology. Site roles are defined in
1534 Section 5.4.
1536 In the example below, VPN A accesses VPN B resources through an
1537 extranet connection. A Spoke role is required for VPN A sites, as
1538 sites from VPN A must not be able to communicate with each other
1539 through the extranet VPN connection.
1541
1542 VPNB
1543 hub-spoke
1544
1545
1546 VPNA
1547 any-to-any
1548
1549
1550 VPNB
1551 spoke-role
1552
1553
1554
1556 This model does not define how the extranet configuration will be
1557 achieved.
1559 Any VPN interconnection scenario that is more complex (e.g., only
1560 certain parts of sites on VPN A accessing only certain parts of sites
1561 on VPN B) needs to be achieved using a VPN attachment as defined in
1562 Section 5.5.2, and especially a VPN policy as defined in
1563 Section 5.5.2.2.
1565 5.2.7. SVLAN ID Ethernet Tag
1567 Service providers have the option of inserting an outer VLAN tag (the
1568 S-tag) into the service frames from the subscriber to improve service
1569 scalability and customer VLAN transparency.
1571 The "svlan-id-ethernet-tag" is either the S-tag inserted at a UNI or
1572 the outer tag of ingress packets at an E-NNI. These parameters are
1573 included in the L2SM to facilitate other management system to
1574 generate proper configuration for the network elements.
1576 Ideally, all external interfaces (UNI and E-NNI) associated with a
1577 given service will have the same S-tag assigned. However, this may
1578 not always be the case. Traffic with all attachments using different
1579 S-tags will need to be "normalized" to a single service S-tag. (One
1580 example of this is a multipoint service that involves multiple off-
1581 net OVCs terminating on the same E-NNI. Each of these off-net OVCs
1582 will have a distinct S-tag which can be different from the S-tag used
1583 in the on-net part of the service.)
1585 S-VLAN ID Preservation and S-VLAN CoS Preservation apply between two
1586 ENNIs connected by an OVC. This attribute does NOT affect ENNI to
1587 UNI frame exchange. Preservation means that the value of S-VLAN ID
1588 and/or S-VLAN CoS at one ENNI must be equal to the value at a
1589 different ENNI connected by the OVC. The purpose of the optional
1590 "svlan-id-ethernet-tag" leaf is to identify the service-wide
1591 "normalized S-tag".If optional "svlan-id-perservation" leaf is set to
1592 true, the "svlan-id-ethernet-tag" leaf MUST be configured.
1594 5.2.8. CVLAN ID Ethernet Tag
1596 An EVC can be set to preserve the CE-VLAN ID and CE-VLAN CoS from
1597 ingress to egress. This is required when the subscriber is using the
1598 VLAN header information between its locations. CE-VLAN ID
1599 Preservation and CE-VLAN CoS Preservation apply between two UNIs
1600 connected by EVC. Preservation means that the value of CE-VLAN ID
1601 and/or CE-VLAN CoS at one UNI must be equal to the value at a
1602 different UNI connected by the same EVC.
1604 If All-to-One bundling is Enabled , then preservation applies to all
1605 Ingress service frames. If All-to-One bundling is Disabled , then
1606 preservation applies to tagged Ingress service frames having CE-VLAN
1607 ID.
1609 5.2.9. CVLAN ID To SVC MAP
1611 When more than one service is multiplexed onto the same interface,
1612 ingress service frames are conditionally transmitted through one of
1613 the EVC/OVCs based upon pre-arranged customer VLAN to EVC mapping.
1614 Multiple customer VLANs can be bundled across the same EVC.
1616 "cvlan-id-to-svc-map", when applicable, contains the list of customer
1617 vlans to the service mapping in a free-form format. In most cases,
1618 this will be the VLAN access-list for the inner 802.1q tag (the
1619 C-tag).
1621 5.2.10. Service Level MAC Limit
1623 When multiple services are provided on the same network element, the
1624 MAC address table (and the Routing Information Base space for MAC-
1625 routes in the case of EVPN) is a shared common resource. Service
1626 providers may impose a maximum number of MAC addresses learned from
1627 the subscriber for a single service instance, and may specify the
1628 action when the upper limit is exceeded: drop the packet, flood the
1629 packet, or simply send a warning log message.
1631 For point-to-point services, if MAC learning is disabled then the MAC
1632 address limit is not necessary.
1634 The optional "service-level-mac-limit" container contains the
1635 subscriber MAC address limit and information to describe the action
1636 when the limit is exceeded.
1638 5.2.11. Load Balance Option
1640 As the subscribers start to deploy more 10G or 100G Ethernet
1641 equipment in their network, the demand for high bandwidth Ethernet
1642 connectivity services increases. These high bandwidth service
1643 requests also pose challenges on capacity planning and service
1644 delivery in the provider's network, especially when the contractual
1645 bandwidth is at, or close to, the speed of physical links of the
1646 service provider's core network. Because of the encapsulation
1647 overhead, the provider cannot deliver the throughput in the service
1648 level agreement over a single link. Although there may be bundled
1649 aggregation links between core network elements, or Equal Cost
1650 Multiple Paths (ECMP) in the network, an Ethernet-over-MPLS (EoMPLS)
1651 PWE or VxLAN circuit is still considered with a single data flow to a
1652 router or switch which uses the normal IP five-tuples in the hashing
1653 algorithm.
1655 Without burdening the core routers with additional processing of deep
1656 inspection into the payload, the service provider now has the option
1657 of inserting a flow or entropy label into the EoMPLS frames, or using
1658 different source UDP ports in case of VxLAN/EVPN, at ingress PE to
1659 facility load-balancing on the subsequent nodes along the path. The
1660 ingress PE is in a unique position to see the actual unencapsulated
1661 service frames and identify data flows based on the original Ethernet
1662 and IP header.
1664 On the other hand, not all Layer 2 Ethernet VPNs are suited for load-
1665 balancing across diverse ECMP paths. For example, a Layer 2 Ethernet
1666 service transported over a single RSVP signaled Label Switched Path
1667 will not take multiple ECMP routes. Or if the subscriber is
1668 concerned about latency/jitter, then diverse path load-balancing can
1669 be undesirable.
1671 The optional "load-balance-option" container is used to capture the
1672 load-balancing agreement between the subscriber and the provider. If
1673 the "load-balance" Boolean leaf is marked TRUE, then one of the
1674 following load-balance methods can be selected: "fat-pw", "entropy-
1675 label", or "vxlan-source-udp-port". FAT pseudowires are used to
1676 load-balance traffic in the core when equal cost multipaths are used.
1677 The MPLS labels add an additional label to the stack, called the flow
1678 label, which contains the flow information of a VC.
1680 5.2.12. Service Protection
1682 Sometimes the subscriber may desire end-to-end protection at the
1683 service level for applications with high availability requirements.
1684 There are two protection schemes to offer redundant services:
1686 o 1+1 protection: In this scheme, the primary circuit will be
1687 protected by a backup circuit, typically meeting certain diverse
1688 path/fiber/site/node criteria. Both primary and protection
1689 circuits are provisioned to be in the active forwarding state.
1690 The subscriber may choose to send the same service frames across
1691 both circuits simultaneously.
1693 o 1:1 protection: In this scheme, a backup circuit to the primary
1694 circuit is provisioned. Depending on the implementation
1695 agreement, the protection circuits may either always be in active
1696 forwarding state, or may only become active when a faulty state is
1697 detected on the primary circuit.
1699 The optional "service-protection" container is used to capture the
1700 desired service protection agreement between subscriber and provider.
1702 5.2.13. Multicast Service
1704 Multicast in L2VPNs is described in [RFC5501][RFC7117].
1706 If multicast support is required for an L2VPN, some global multicast
1707 parameters are required as input for the service request. When a CE
1708 sends (1) Broadcast, (2) Multicast, or (3) Unknown destination
1709 unicast, replication occurs at ingress PE, therefore three traffic
1710 type is supported.
1712 Users of this model will need to provide the flavors of trees that
1713 will be used by customers within the L2VPN (customer tree). The
1714 proposed model supports bidirectional, shared, and source-based trees
1715 (and can be augmented). Multiple flavors of trees can be supported
1716 simultaneously.
1718 Operator network
1719 ______________
1720 / \
1721 | |
1722 (SSM tree) |
1723 Recv -- Site2 ------- PE2 |
1724 | PE1 --- Site1 --- Source1
1725 | | \
1726 | | -- Source2
1727 | |
1728 (ASM tree) |
1729 Recv -- Site3 ------- PE3 |
1730 | |
1731 (SSM tree) |
1732 Recv -- Site4 ------- PE4 |
1733 | / |
1734 Recv -- Site5 -------- |
1735 (ASM tree) |
1736 | |
1737 \_______________/
1739 Group to port mappings can be created using the "rp-group-mappings"
1740 leaf. Two group to port mapping method are supported:
1742 o Static configuration of multicast Ethernet addresses and ports/
1743 interfaces.
1745 o Multicast control protocol based on Layer-2 technology that
1746 signals mappings of multicast addresses to ports/interfaces, such
1747 as Generic Attribute Registration Protocol / GARP Multicast
1748 Registration Protocol (GARP/GMRP) [802.1D].
1750 5.3. Site Overview
1752 A site represents a connection of a customer office to one or more
1753 VPN services.
1755 +-------------+
1756 / \
1757 +------------------+ +-----| VPN1 |
1758 | | | \ /
1759 | New York Office |------ (site) -----+ +-------------+
1760 | | | +-------------+
1761 +------------------+ | / \
1762 +-----| VPN2 |
1763 \ /
1764 +-------------+
1766 The "site" container is used for the provider to store information of
1767 detailed implementation arrangements made with either the customer or
1768 peer operators at each inter-connect location.
1770 We are restricting the L2SM to exterior interfaces only, so all
1771 internal interfaces and the underlying topology are outside the scope
1772 of L2SM.
1774 Typically, the following characteristics of a site interface handoff
1775 need to be documented as part of the service design:
1777 Unique identifier (site-id): An arbitrary string to uniquely
1778 identify the site within the overall network infrastructure. The
1779 format of site-id is determined by the local administration of the
1780 VPN service.
1782 Site Type (site-type): Defines the way the VPN multiplexing is done.
1784 Device (device): The customer can request one or more customer
1785 premise equipments from the service provider for a particular
1786 site.
1788 Management (management): Defines the model of management of the
1789 site, for example: type, management-transport, address.
1791 Location (location): The site location information to allow easy
1792 retrieval of data on which are the nearest available resources.
1794 Site diversity (site-diversity): Presents some parameters to support
1795 site diversity.
1797 Signaling Options(signaling-options): Defines which protocol or
1798 signaling must be activated between the subscriber and the
1799 provider.
1801 Load balancing (load-balance-options): Defines the load-balancing
1802 agreement information between the subscriber and provider.
1804 Site Network Accesses (site-network-accesses): Defines the list of
1805 ports to the sites and their properties: especially bearer,
1806 connection and service parameters.
1808 A site-network-access represents an Ethernet logical connection of a
1809 site. A site may have multiple site-network-accesses.
1811 +------------------+ Site
1812 | |-----------------------------------
1813 | |****** (site-network-access#1) ******
1814 | New York Office |
1815 | |****** (site-network-access#2) ******
1816 | |-----------------------------------
1817 +------------------+
1819 Multiple site-network-accesses are used, for instance, in the case of
1820 multihoming. Some other meshing cases may also include multiple
1821 site-network-accesses.
1823 The site configuration is viewed as a global entity; we assume that
1824 it is mostly the management system's role to split the parameters
1825 between the different elements within the network. For example, in
1826 the case of the site-network-access configuration, the management
1827 system needs to split the overall parameters between the PE
1828 configuration and the CE configuration.
1830 5.3.1. Devices and Locations
1832 The information in the "location" sub-container under a "site"and
1833 "device" container allows easy retrieval of data about which are the
1834 nearest available facilities and can be used for access topology
1835 planning. It may also be used by other network orchestration
1836 component to choose the targeted upstream PE and downstream CE.
1837 Location is expressed in terms of postal information.
1839 A site may be composed of multiple locations. All the locations will
1840 need to be configured as part of the "locations" container and list.
1841 A typical example of a multi-location site is a headquarters office
1842 in a city composed of multiple buildings. Those buildings may be
1843 located in different parts of the city and may be linked by intra-
1844 city fibers (customer metropolitan area network). In such a case,
1845 when connecting to a VPN service, the customer may ask for
1846 multihoming based on its distributed locations.
1848 New York Site
1850 +------------------+ Site
1851 | +--------------+ |-----------------------------------
1852 | | Manhattan | |****** (site-network-access#1) ******
1853 | +--------------+ |
1854 | +--------------+ |
1855 | | Brooklyn | |****** (site-network-access#2) ******
1856 | +--------------+ |
1857 | |-----------------------------------
1858 +------------------+
1860 A customer may also request some premises equipment entities (CEs)
1861 from the SP via the "devices" container. Requesting a CE implies a
1862 provider-managed or co-managed model. A particular device must be
1863 ordered to a particular already-configured location. This would help
1864 the SP send the device to the appropriate postal address. In a
1865 multi-location site, a customer may, for example, request a CE for
1866 each location on the site where multihoming must be implemented. In
1867 the figure above, one device may be requested for the Manhattan
1868 location and one other for the Brooklyn location.
1870 By using devices and locations, the user can influence the
1871 multihoming scenario he wants to implement: single CE, dual CE, etc.
1873 5.3.2. Signaling Option
1875 The "signaling-option" container captures service-wide attributes of
1876 the L2VPN instance.
1878 Although topology discovery or network device configuration is
1879 purposely out of scope for the L2SM model, certain VPN parameters for
1880 discovery are listed here. The information can then be passed to
1881 other elements in the whole automation eco-system (such as the
1882 configuration engine) which will handle the actual service
1883 provisioning function.
1885 [RFC6074] describes the provisioning, auto-Discovery, and signaling
1886 in L2VPNs. It specifies a number of L2VPN provisioning models, and
1887 further specifies the semantic structure of the endpoint identifiers
1888 required by each model, as well as the distribution of these
1889 identifiers by the discovery process, and then specifies how the
1890 endpoint identifiers are carried in the signaling protocols (e.g.
1891 LDP and L2TPv3).
1893 The "signaling-option" list uses the "type" as the index. The "type"
1894 leaf is for the signaling protocol: BGP- L2VPN, BGP-EVPN, T-LDP or
1895 L2TP.
1897 5.3.2.1. BGP L2VPN
1899 [RFC4761] and [RFC6624] describe the mechanism to auto-discover L2VPN
1900 VPLS/VPWS end points (CE-ID or VE-ID) and signal the label base and
1901 offset at the same time to allow remote PE to derive the VPN label to
1902 be used when sending packets to the advertising router.
1904 In addition [RFC6624] makes interesting considerations about the
1905 L2VPN Scaling scheme and the separation of Administrative
1906 Responsibilities between Customer and Service Provider.
1908 Due to the way auto-discovery operates, PEs that have at least one
1909 attachment circuit associated with a particular VPN service do not
1910 need to be specified explicitly.
1912 In the L2SM model, only the target community (or communities) is also
1913 not specified since the management system allocates the route target
1914 upon receiving VPN creation request.
1916 The "type" leaf under "mp-bgp-l2vpn" is an identityref to specify
1917 "vpws" or "vpls" sub-types.
1919 5.3.2.2. BGP EVPN
1921 Defined in [RFC7432], EVPN is an L2VPN technology based upon BGP MAC
1922 routing. It provides similar functionality to BGP VPWS/VPLS with
1923 improvement around redundancy, multicast optimization, provisioning,
1924 and simplicity.
1926 Due to the way auto-discovery operates, PEs that have at least one
1927 attachment circuit associated with a particular VPN service do not
1928 need to be specified explicitly.
1930 In the L2SM model, only the target community (or communities) is also
1931 not specified since the management system allocates the route target
1932 upon receiving VPN creation request.
1934 The "type" leaf under "mp-bgp-evpn" is an identityref to specify
1935 "vpws" or "vpls" sub-types.
1937 5.3.2.3. LDP Pseudowires
1939 [RFC4762] specifies the method of using targeted LDP sessions between
1940 PEs to exchange VC label information. This requires a configured
1941 full mesh of targeted LDP sessions between all PEs.
1943 As multiple attachment circuits may terminate on a single PE, this
1944 PE-to-PE mesh is not a per-site attribute. All PEs related to the
1945 L2VPN service will be listed in the "t-ldp-pwe" with associated "vc-
1946 id".
1948 The "type" leaf under "mp-bgp-evpn" is an identityref to specify
1949 "vpws" ,"vpls", "h-vpls"sub-types. In case of "h-vpls", "qinq" leaf
1950 must be specified.
1952 5.3.2.4. PWE Encapsulation Type
1954 Based on [RFC4448], there are two types of Ethernet services: "Port-
1955 to-Port Ethernet PW emulation" and "Vlan-to-Vlan Ethernet PW
1956 emulation", commonly referred to as Type 5 and Type 4 respectively.
1957 This concept applies to both BGP L2VPN VPWS/VPLS and T-LDP signaled
1958 PWE implementations.
1960 The "pwe-encapsulation-type" has two types: "ethernet" and "ethernet-
1961 vlan". If "signaling-option" is "mp-bgp-l2vpn" or "t-ldp-pwe", then
1962 "pwe-encapsulation-type" must be set one of "ethernet" and "ethernet-
1963 vlan" .
1965 5.3.2.5. PWE MTU
1967 During the signaling process of a BGP-L2VPN or T-LDP pseudowire, the
1968 pwe-mtu value is exchanged and must match at both ends. By default,
1969 the pwe-mtu is derived from physical interface MTU of the attachment
1970 circuit minus the EoMPLS transport header. In some cases, however,
1971 the physical interface on both ends of the circuit might not have
1972 identical MTU settings. For example, due to 802.1ad q-in-q
1973 operation, an I-NNI will need an extra four bytes to accommodate the
1974 S-tag. The inter-carrier E-NNI link may also have a different MTU
1975 size than the internal network interfaces.
1977 [RFC4448] requires the same MTU size on physical interfaces at both
1978 ends of the pseudowire. In actual implementations, many router
1979 vendors have provided a knob to explicitly specify the pwe-mtu, which
1980 can then be decoupled from the physical interface MTU.
1982 When there is a mismatch between the physical interface MTU and
1983 configured pwe-mtu, the "allow-mtu-mismatch" leaf in the "pwe-mtu"
1984 contained enables definition of the required behavior.
1986 5.3.2.6. Control Word
1988 A control word is an optional 4-byte field located between the MPLS
1989 label stack and the Layer 2 payload in the pseudowire packet. It
1990 plays a crucial role in Any Transport over MPLS (AToM). The 32-bit
1991 field carries generic and Layer 2 payload-specific information,
1992 including a C-bit which indicates whether the control word will
1993 present in the Ethernet over MPLS (EoMPLS) packets. If the C-bit is
1994 set to 1, the advertising PE expects the control word to be present
1995 in every pseudowire packet on the pseudowire that is being signaled.
1996 If the C-bit is set to 0, no control word is expected to be present.
1998 Whether to include control word in the pseudowire packets MUST match
1999 on PEs at both ends of the pseudowire and it is non-negotiable during
2000 the signaling process.
2002 The use of a control-word applies to pseduowires signaled using
2003 either BGP L2VPN VPWS/VPLS or T-LDP. It is a routing-instance level
2004 configuration parameter in many cases.
2006 The optional "control-word" leaf is a Boolean field in the L2SM model
2007 for the provider to explicitly specify whether the control-word will
2008 be signaled for the service instance.
2010 5.3.2.7. L2TP Pseudowires
2012 In the L2VPN framework , a LAC is a Provider Edge (PE) device. In
2013 the LAC-LAC reference model, a LAC serves as a cross-connect between
2014 attachment circuits and L2TP sessions. Each L2TP session acts as an
2015 emulated circuit, also known as pseudowire. A pseudowire is used to
2016 bind two attachment circuits together. For different L2VPN
2017 applications, different types of attachment circuits are defined.
2019 The "encapsulation-type" has one type,i.e.,l2tp type.
2021 The optional "control-word" leaf is a Boolean field in the L2SM model
2022 for the provider to explicitly specify whether the control-word will
2023 be signaled for the service instance.
2025 5.3.3. Site Network Accesses
2027 The L2SM includes a set of essential physical interface properties
2028 and Ethernet layer characteristics in the "site-network-accesses"
2029 container. Some of these are critical implementation arrangements
2030 that require consent from both customer and provider.
2032 As mentioned earlier, a site may be multihomed. Each logical network
2033 access for a site is defined in the "site-network-accesses"
2034 container. The site-network-access parameter defines how the site is
2035 connected on the network and is split into three main classes of
2036 parameters:
2038 o bearer: defines requirements of the attachment (below Layer 2).
2040 o connection: defines Layer 2 protocol parameters of the attachment.
2042 o availability: defines the site's availability policy. The
2043 availability parameters are defined in Section 5.2.8.
2045 The site-network-access has a specific type (site-network-access-
2046 type). This document defines two types:
2048 o point-to-point: describes a point-to-point connection between the
2049 SP and the customer.
2051 o multipoint: describes a multipoint connection between the SP and
2052 the customer.
2054 The type of site-network-access may have an impact on the parameters
2055 offered to the customer, e.g., an SP may not offer encryption for
2056 multipoint accesses. It is up to the provider to decide what
2057 parameter is supported for point-to-point and/or multipoint accesses;
2058 which is out of scope for this document. Some containers proposed in
2059 the model may require extensions in order to work properly for
2060 multipoint accesses.
2062 5.3.3.1. Bearer
2064 The "bearer" container defines the requirements for the site
2065 attachment to the provider network that are below Layer 3.
2067 The bearer parameters will help to determine the access media to be
2068 used.
2070 5.3.3.2. Connection
2072 The "connection" container defines the layer 2 protocol parameters of
2073 The Attachment and provides connectivity between customer Ethernet
2074 switches. Depending on the management mode, it refers to PE-CE- LAN
2075 segment addressing or CE-to-customer-LAN segment addressing. In any
2076 case, it describes the responsibility boundary between the provider
2077 and the customer. For a customer-managed site, it refers to the PE-
2078 CE LAN Segment connection. For a provider-managed site, it refers to
2079 the CE-to-LAN Segment connection.
2081 The connection container presents two sets of link attributes:
2082 physical interface or optional LAG interface attributes. These
2083 parameters are essential for the connection between customer and
2084 provider edge devices to establish properly. The connection
2085 container also defines L2CP attribute to allow control plane protocol
2086 interaction between the CE devices and PE device.
2088 5.3.3.2.1. Addressing
2090 If the Ethernet service is enabled on a logical unit on the
2091 connection at the interface, the connection
2092 addressing,"encapsulation-type ","sub-if-id" should be specified.
2094 The "connection" container also presents site specific (S-tag, C-tag)
2095 management options. The overall S-tag for the Ethernet circuit and
2096 C-tag to SVC mapping, if applicable, has been placed in the service
2097 container. The S-tag under "connection" should match the S-tag in
2098 the service container in most cases, however, vlan translation is
2099 required for the S-tag in certain deployment at the external facing
2100 interface or upstream PEs to "normalize" the outer VLAN tag to the
2101 service S-tag into the network and translate back to the site's S-tag
2102 in the opposite direction. One example of this is with a Layer 2
2103 aggregation switch along the path: the S-tag for the SVC has been
2104 previously assigned to another service thus can not be used by this
2105 attachment circuit.
2107 5.3.3.2.2. Physical Interface
2109 For each physical interface (phy-interface), there are basic
2110 configuration parameters like port number and speed, interface MTU,
2111 auto-negotiation and flow-control settings, etc. "encapsulation-
2112 type" is for user to select between Ethernet encapsulation (port-
2113 based) or Ethernet VLAN encapsulation (VLAN-based). All allowed
2114 Ethertypes of ingress service frames can be listed under "ethertype".
2115 In addition, the customer and provider may decide to enable advanced
2116 features, such as LLDP, 802.3AH link OAM, MAC loop detection/
2117 prevention at a UNI, based on mutual agreement.If Loop avoidance is
2118 required, the attribute "uni-loop-prevention" must be set to TRUE.
2120 5.3.3.2.3. LAG Interface
2122 Sometimes, the customer may require multiple physical links bundled
2123 together to form a single, logical, point-to-point LAG connection to
2124 the service provider. Typically, LACP (Link Aggregation Control
2125 Protocol) is used to dynamically manage adding or deleting member
2126 links of the aggregate group. In general, LAG allows for increased
2127 service bandwidth beyond the speed of a single physical link while
2128 providing graceful degradation as failure occurs, thus increased
2129 availability.
2131 In the L2SM, there is a set of attributes under "LAG-interface"
2132 related to link aggregation functionality. The customer and provider
2133 first need to decide on whether LACP PDU will be exchanged between
2134 the edge device by specifying the "LACP-state" to "On" or "Off". If
2135 LACP is to be enabled, then both parties need to further specify
2136 whether it will be running in active versus passive mode, plus the
2137 time interval and priority level of the LACP PDU. The subscriber and
2138 provider can also determine the minimum aggregate bandwidth for a LAG
2139 to be considered valid path by specifying the optional "mini-link"
2140 attribute. To enable fast detection of faulty links, micro-bfd runs
2141 independent UDP sessions to monitor the status of each member link.
2142 Subscriber and provider should consent to the BFD hello interval and
2143 hold time.
2145 Each member link will be listed under the LAG interface with basic
2146 physical link properties. Certain attributes like flow-control,
2147 encapsulation type, allowed ingress Ethertype and LLDP settings are
2148 at the LAG level.
2150 5.3.3.2.4. L2CP Control
2152 Customer and Service provider should make pre-arrangement on whether
2153 to allow control plane protocol interaction between the CE devices
2154 and PE device. To provide seamless operation with multicast data
2155 transport, the transparent operation of Ethernet control protocols
2156 (e.g., Spanning Tree Protocol [802.1D]) can be employed by customers.
2158 To support efficient dynamic transport, Ethernet multicast control
2159 frames (e.g., GARP/GMRP [802.1D]) can be used between CE and PE.
2160 However, solutions MUST NOT assume all CEs are always running such
2161 protocols (typically in the case where a CE is a router and is not
2162 aware of Layer-2 details).
2164 To facilitate interoperability between different Multiple System
2165 Operators (MSOs), interaction between the edge device of each
2166 administrative domain can be either allowed or keep each
2167 Administrative domain control plane separate on a per-protocol basis.
2168 the MEF has provided normative guidance on Layer 2 Control Protocol
2169 (L2CP) processing requirements for each service type.
2171 The destination MAC addresses of these L2CP PDUs fall within two
2172 reserved blocks specified by the IEEE 802.1 Working Group. Packet
2173 with destination MAC in these multicast ranges have special
2174 forwarding rules.
2176 o Bridge Block of Protocols: 01-80-C2-00-00-00 through
2177 01-80-C2-00-00-0F
2179 o MRP Block of Protocols: 01-80-C2-00-00-20 through
2180 01-80-C2-00-00-2F
2182 Layer 2 protocol tunneling allows service providers to pass
2183 subscriber Layer 2 control PDUs across the network without being
2184 interpreted and processed by intermediate network devices. These
2185 L2CP PDUs are transparently encapsulated across the MPLS-enabled core
2186 network in Q-in-Q fashion.
2188 The "L2CP-control" container contains the list of commonly used L2CP
2189 protocols and parameters. The service provider can specify DISCARD,
2190 PEER, or TUNNEL mode actions for each individual protocol.
2192 In addition, "provider-bridge-group" and "provider-bridge-mvrp"
2193 addresses are also listed in the L2CP container.
2195 5.4. Site Role
2197 A VPN has a particular service topology, as described in
2198 Section 5.1.3. As a consequence, each site belonging to a VPN is
2199 assigned with a particular role in this topology. The site-role leaf
2200 defines the role of the site in a particular VPN topology.
2202 In the any-to-any VPN service topology, all sites MUST have the same
2203 role, which will be "any-to-any-role".
2205 In the Hub-and-Spoke VPN service topology or the Hub and Spoke
2206 disjoint VPN service topology, sites MUST have a Hub role or a Spoke
2207 role.
2209 5.5. Site Belonging to Multiple VPNs
2211 5.5.1. Site VPN Flavor
2213 A site may be part of one or multiple VPNs. The "site-type" defines
2214 the way the VPN multiplexing is done. There are three possible types
2215 of external facing connections associated with an Ethernet VPN
2216 service and a site. Therefore the current version of the model
2217 supports three flavors:
2219 o site-vpn-flavor-single: The site belongs to only one VPN.
2221 o site-vpn-flavor-multi: The site belongs to multiple VPNs, and all
2222 the logical accesses of the sites belong to the same set of VPNs.
2224 o site-vpn-flavor-enni: The site represents an ENNI where two
2225 Ethernet service providers inter-connect with each other.
2227 5.5.1.1. Single VPN Attachment: site-vpn-flavor-single
2229 The figure below describes a single VPN attachment. The site
2230 connects to only one VPN.
2232 +--------+
2233 +------------------+ Site / \
2234 | |-----------------------------| |
2235 | |***(site-network-access#1)***| VPN1 |
2236 | New York Office | | |
2237 | |***(site-network-access#2)***| |
2238 | |-----------------------------| |
2239 +------------------+ \ /
2240 +--------+
2242 5.5.1.2. MultiVPN Attachment: site-vpn-flavor-multi
2244 The figure below describes a site connected to multiple VPNs.
2246 +---------+
2247 +---/----+ \
2248 +------------------+ Site / | \ |
2249 | |--------------------------------- | |VPN B|
2250 | |***(site-network-access#1)******* | | |
2251 | New York Office | | | | |
2252 | |***(site-network-access#2)******* \ | /
2253 | |-----------------------------| VPN A+-----|---+
2254 +------------------+ \ /
2255 +--------+
2257 In the example above, the New York office is multihomed. Both
2258 logical accesses are using the same VPN attachment rules, and both
2259 are connected to VPN A and VPN B.
2261 Reaching VPN A or VPN B from the New York office will be done via
2262 destination-based routing. Having the same destination reachable
2263 from the two VPNs may cause routing troubles. The customer
2264 administration's role in this case would be to ensure the appropriate
2265 mapping of its prefixes in each VPN.
2267 5.5.1.3. ENNI: site-vpn-flavor-enni
2269 A External Network-to-Network Interface (ENNI) scenario may be
2270 modeled using the sites container. It is helpful for the SP to
2271 indicate that the requested VPN connection is not a regular site but
2272 rather is an ENNI, as specific default device configuration
2273 parameters may be applied in the case of ENNIs (e.g., ACLs, routing
2274 policies).
2276 SP A SP B
2277 ------------------- -------------------
2278 / \ / \
2279 | | | |
2280 | ++++++++ Inter-AS link ++++++++ |
2281 | + +_______________+ + |
2282 | + (VSI1)---(VPN1)----(VSI1) + |
2283 | + ASBR + + ASBR + |
2284 | + (VSI2)---(VPN2)----(VSI2) + |
2285 | + +_______________+ + |
2286 | ++++++++ ++++++++ |
2287 | | | |
2288 | | | |
2289 | | | |
2290 | ++++++++ Inter-AS link ++++++++ |
2291 | + +_______________+ + |
2292 | + (VSI1)---(VPN1)----(VSI1) + |
2293 | + ASBR + + ASBR + |
2294 | + (VSI2)---(VPN2)----(VSI2) + |
2295 | + +_______________+ + |
2296 | ++++++++ ++++++++ |
2297 | | | |
2298 | | | |
2299 \ / \ /
2300 ------------------- -------------------
2302 The figure above describes an option A ENNI scenario that can be
2303 modeled using the sites container. In order to connect its customer
2304 VPNs (VPN1 and VPN2) in SP B, SP A may request the creation of some
2305 site-network-accesses to SP B. The site-vpn-flavor-enni will be used
2306 to inform SP B that this is an ENNI and not a regular customer site.
2308 5.5.2. Attaching a Site to a VPN
2310 Due to the multiple site-vpn flavors, the attachment of a site to an
2311 L2VPN is done at the site-network-access (logical access) level
2312 through the "vpn-attachment" container. The vpn-attachment container
2313 is mandatory. The model provides two ways to attach a site to a VPN:
2315 o By referencing the target VPN directly.
2317 o By referencing a VPN policy for attachments that are more complex.
2319 A choice is implemented to allow the user to choose the flavor that
2320 provides the best fit.
2322 5.5.2.1. Referencing a VPN
2324 Referencing a vpn-id provides an easy way to attach a particular
2325 logical access to a VPN. This is the best way in the case of a
2326 single VPN attachment. When referencing a vpn-id, the site-role
2327 setting must be added to express the role of the site in the target
2328 VPN service topology.
2330
2331 SITE1
2332
2333
2334 LA1
2335
2336 VPNA
2337 spoke-role
2338
2339
2340
2341 LA2
2342
2343 VPNB
2344 spoke-role
2345
2346
2347
2348
2350 The example above describes a multiVPN case where a site (SITE1) has
2351 two logical accesses (LA1 and LA2), attached to both VPNA and VPNB.
2353 5.5.2.2. VPN Policy
2355 The "vpn-policy" list helps express a multiVPN scenario where a
2356 logical access belongs to multiple VPNs.
2358 As a site can belong to multiple VPNs, the vpn-policy list may be
2359 composed of multiple entries. A filter can be applied to specify
2360 that only some LANs of the site should be part of a particular VPN.
2361 Each time a site (or LAN) is attached to a VPN, the user must
2362 precisely describe its role (site-role) within the target VPN service
2363 topology.
2365 +--------------------------------------------------------------+
2366 | Site1 ------ PE7 |
2367 +-------------------------+ [VPN2] |
2368 | |
2369 +-------------------------+ |
2370 | Site2 ------ PE3 PE4 ------ Site3 |
2371 +----------------------------------+ |
2372 | |
2373 +------------------------------------------------------------+ |
2374 | Site4 ------ PE5 | PE6 ------ Site5 | |
2375 | | |
2376 | [VPN3] | |
2377 +------------------------------------------------------------+ |
2378 | |
2379 +---------------------------+
2381 In the example above, Site5 is part of two VPNs: VPN3 and VPN2. It
2382 will play a Hub role in VPN2 and an any-to-any role in VPN3. We can
2383 express such a multiVPN scenario as follows:
2385
2386 Site5
2387
2388
2389 POLICY1
2390
2391 ENTRY1
2392
2393 VPN2
2394 hub-role
2395
2396
2397
2398 ENTRY2
2399
2400 VPN3
2401 any-to-any-role
2402
2403
2404
2405
2406
2407
2408 LA1
2409
2410 POLICY1
2411
2412
2413
2414
2416 Now, if a more-granular VPN attachment is necessary, filtering can be
2417 used. For example, if LAN1 from Site5 must be attached to VPN2 as a
2418 Hub and LAN2 must be attached to VPN3, the following configuration
2419 can be used:
2421
2422 Site5
2423
2424
2425 POLICY1
2426
2427 ENTRY1
2428
2429 LAN1
2430
2431
2432 VPN2
2433 hub-role
2434
2435
2436
2437 ENTRY2
2438
2439 LAN2
2440
2441
2442 VPN3
2443 any-to-any-role
2444
2445
2446
2447
2448
2449
2450 LA1
2451
2452 POLICY1
2453
2454
2455
2456
2458 5.6. Deciding Where to Connect the Site
2460 The management system will have to determine where to connect each
2461 site-network-access of a particular site to the provider network
2462 (e.g., PE, aggregation switch).
2464 The current model proposes parameters and constraints that can
2465 influence the meshing of the site-network-access.
2467 The management system should honor any customer constraints. If a
2468 constraint is too strict and cannot be fulfilled, the management
2469 system must not provision the site and should provide relevant
2470 information to the user. How the information is provided is out of
2471 scope for this document. Whether or not to relax the constraint
2472 would then be left up to the user.
2474 Parameters are just hints for the management system for service
2475 placement.
2477 In addition to parameters and constraints, the management system's
2478 decision MAY be based on any other internal constraints that are left
2479 up to the SP: least load, distance, etc.
2481 5.6.1. Constraint: Device
2483 In the case of provider management or co-management, one or more
2484 devices have been ordered by the customer. The customer may force a
2485 particular site-network-access to be connected on a particular device
2486 that he ordered.
2488 New York Site
2490 +------------------+ Site
2491 | +--------------+ |-----------------------------------
2492 | | Manhattan | |
2493 | | CE1********* (site-network-access#1) ******
2494 | +--------------+ |
2495 | +--------------+ |
2496 | | Brooklyn CE2********* (site-network-access#2) ******
2497 | +--------------+ |
2498 | |-----------------------------------
2499 +------------------+
2501 In the figure above, site-network-access#1 is associated with CE1 in
2502 the service request. The SP must ensure the provisioning of this
2503 connection.
2505 5.6.2. Constraint/Parameter: Site Location
2507 The location information provided in this model MAY be used by a
2508 management system to determine the target PE to mesh the site (SP
2509 side). A particular location must be associated with each site
2510 network access when configuring it. The SP MUST honor the
2511 termination of the access on the location associated with the site
2512 network access (customer side). The "country-code" in the site
2513 location should be expressed as an ISO ALPHA-2 code.
2515 The site-network-access location is determined by the "location-
2516 flavor". In the case of a provider-managed or co-managed site, the
2517 user is expected to configure a "device-reference" (device case) that
2518 will bind the site-network-access to a particular device that the
2519 customer ordered. As each device is already associated with a
2520 particular location, in such a case the location information is
2521 retrieved from the device location. In the case of a customer-
2522 managed site, the user is expected to configure a "location-
2523 reference" (location case); this provides a reference to an existing
2524 configured location and will help with placement.
2526 POP#1 (New York)
2527 +---------+
2528 | PE1 |
2529 Site #1 ---... | PE2 |
2530 (Atlantic City) | PE3 |
2531 +---------+
2533 POP#2 (Washington)
2534 +---------+
2535 | PE4 |
2536 | PE5 |
2537 | PE6 |
2538 +---------+
2540 POP#3 (Philadelphia)
2541 +---------+
2542 | PE7 |
2543 Site #2 CE#1---... | PE8 |
2544 (Reston) | PE9 |
2545 +---------+
2547 In the example above, Site #1 is a customer-managed site with a
2548 location L1, while Site #2 is a provider-managed site for which a CE
2549 (CE#1) was ordered. Site #2 is configured with L2 as its location.
2550 When configuring a site-network-access for Site #1, the user will
2551 need to reference location L1 so that the management system will know
2552 that the access will need to terminate on this location. Then, for
2553 distance reasons, this management system may mesh Site #1 on a PE in
2554 the Philadelphia POP. It may also take into account resources
2555 available on PEs to determine the exact target PE (e.g., least
2556 loaded). For Site #2, the user is expected to configure the site-
2557 network-access with a device-reference to CE#1 so that the management
2558 system will know that the access must terminate on the location of
2559 CE#1 and must be connected to CE#1. For placement of the SP side of
2560 the access connection, in the case of the nearest PE used, it may
2561 mesh Site #2 on the Washington POP.
2563 5.6.3. Constraint/Parameter: Access Type
2565 The management system needs to elect the access media to connect the
2566 site to the customer (for example, xDSL, leased line, Ethernet
2567 backhaul). The customer may provide some parameters/constraints that
2568 will provide hints to the management system.
2570 The bearer container information SHOULD be the first piece of
2571 information considered when making this decision:
2573 o The "requested-type" parameter provides information about the
2574 media type that the customer would like to use. If the "strict"
2575 leaf is equal to "true", this MUST be considered a strict
2576 constraint so that the management system cannot connect the site
2577 with another media type. If the "strict" leaf is equal to "false"
2578 (default) and if the requested media type cannot be fulfilled, the
2579 management system can select another media type. The supported
2580 media types SHOULD be communicated by the SP to the customer via a
2581 mechanism that is out of scope for this document.
2583 o The "always-on" leaf defines a strict constraint: if set to true,
2584 the management system MUST elect a media type that is "always-on"
2585 (e.g., this means no dial access type).
2587 o The "bearer-reference" parameter is used in cases where the
2588 customer has already ordered a network connection to the SP apart
2589 from the L2VPN site and wants to reuse this connection. The
2590 string used is an internal reference from the SP and describes the
2591 already-available connection. This is also a strict requirement
2592 that cannot be relaxed. How the reference is given to the
2593 customer is out of scope for this document, but as a pure example,
2594 when the customer ordered the bearer (through a process that is
2595 out of scope for this model), the SP may have provided the bearer
2596 reference that can be used for provisioning services on top.
2598 Any other internal parameters from the SP can also be used. The
2599 management system MAY use other parameters, such as the requested
2600 "svc-input-bandwidth" and "svc-output-bandwidth", to help decide
2601 which access type to use.
2603 5.6.4. Constraint: Access Diversity
2605 Each site-network-access may have one or more constraints that would
2606 drive the placement of the access. By default, the model assumes
2607 that there are no constraints, but allocation of a unique bearer per
2608 site-network-access is expected.
2610 In order to help with the different placement scenarios, a site-
2611 network-access may be tagged using one or multiple group identifiers.
2612 The group identifier is a string, so it can accommodate both explicit
2613 naming of a group of sites (e.g., "multihomed-set1") and the use of a
2614 numbered identifier (e.g., 12345678). The meaning of each group-id
2615 is local to each customer administrator, and the management system
2616 MUST ensure that different customers can use the same group-ids. One
2617 or more group-ids can also be defined at the site level; as a
2618 consequence, all site-network-accesses under the site MUST inherit
2619 the group-ids of the site they belong to. When, in addition to the
2620 site group-ids some group-ids are defined at the site-network-access
2621 level, the management system MUST consider the union of all groups
2622 (site level and site network access level) for this particular site-
2623 network-access.
2625 For an already-configured site-network-access, each constraint MUST
2626 be expressed against a targeted set of site-network-accesses. This
2627 site-network-access MUST never be taken into account in the targeted
2628 set -- for example, "My site-network-access S must not be connected
2629 on the same POP as the site-network-accesses that are part of Group
2630 10." The set of site-network-accesses against which the constraint
2631 is evaluated can be expressed as a list of groups, "all-other-
2632 accesses", or "all-other-groups". The all-other-accesses option
2633 means that the current site-network-access constraint MUST be
2634 evaluated against all the other site-network-accesses belonging to
2635 the current site. The all-other-groups option means that the
2636 constraint MUST be evaluated against all groups that the current
2637 site-network-access does not belong to.
2639 The current model proposes multiple constraint-types:
2641 o pe-diverse: The current site-network-access MUST NOT be connected
2642 to the same PE as the targeted site-network-accesses.
2644 o pop-diverse: The current site-network-access MUST NOT be connected
2645 to the same POP as the targeted site-network-accesses.
2647 o linecard-diverse: The current site-network-access MUST NOT be
2648 connected to the same linecard as the targeted site-network-
2649 accesses.
2651 o bearer-diverse: The current site-network-access MUST NOT use
2652 common bearer components compared to bearers used by the targeted
2653 site-network-accesses. "bearer-diverse" provides some level of
2654 diversity at the access level. As an example, two bearer-diverse
2655 site-network-accesses must not use the same DSLAM, BAS, or Layer 2
2656 switch.
2658 o same-pe: The current site-network-access MUST be connected to the
2659 same PE as the targeted site-network-accesses.
2661 o same-bearer: The current site-network-access MUST be connected
2662 using the same bearer as the targeted site-network-accesses.
2664 These constraint-types can be extended through augmentation. Each
2665 constraint is expressed as "The site-network-access S must be
2666 (e.g., pe-diverse, pop-diverse) from these
2667 site-network-accesses."
2669 The group-id used to target some site-network-accesses may be the
2670 same as the one used by the current site-network-access. This eases
2671 the configuration of scenarios where a group of site-network-access
2672 points has a constraint between the access points in the group.
2674 5.7. Route Distinguisher and Network Instance Allocation
2676 The route distinguisher (RD) is a critical parameter of BGP-based
2677 L2VPNs as described in [RFC4364] that provides the ability to
2678 distinguish common addressing plans in different VPNs. As for route
2679 targets (RTs), a management system is expected to allocate a VSI on
2680 the target PE and an RD for this VSI.
2682 If a VSI already exists on the target PE and the VSI fulfills the
2683 connectivity constraints for the site, there is no need to recreate
2684 another VSI, and the site MAY be meshed within this existing VSI.
2685 How the management system checks that an existing VSI fulfills the
2686 connectivity constraints for a site is out of scope for this
2687 document.
2689 If no such VSI exists on the target PE, the management system has to
2690 initiate the creation of a new VSI on the target PE and has to
2691 allocate a new RD for this new VSI.
2693 The management system MAY apply a per-VPN or per-VSI allocation
2694 policy for the RD, depending on the SP's policy. In a per-VPN
2695 allocation policy, all VSIs (dispatched on multiple PEs) within a VPN
2696 will share the same RD value. In a per-VRF model, all VRFs should
2697 always have a unique RD value. Some other allocation policies are
2698 also possible, and this document does not restrict the allocation
2699 policies to be used.
2701 The allocation of RDs MAY be done in the same way as RTs. The
2702 examples provided in Section 6.2.1.1 could be reused in this
2703 scenario.
2705 Note that an SP MAY configure a target PE for an automated allocation
2706 of RDs. In this case, there will be no need for any backend system
2707 to allocate an RD value.
2709 5.8. Site Network Access Availability
2711 A site may be multihomed, meaning that it has multiple site-network-
2712 access points. Placement constraints defined in previous sections
2713 will help ensure physical diversity.
2715 When the site-network-accesses are placed on the network, a customer
2716 may want to use a particular routing policy on those accesses. The
2717 "site-network-access/availability" container defines parameters for
2718 site redundancy. The "access-priority" leaf defines a preference for
2719 a particular access. This preference is used to model load-balancing
2720 or primary/backup scenarios. The higher the access-priority value,
2721 the higher the preference will be. The "redundancy mode" attribute
2722 is defined for an multi-homing site and used to model single-active
2723 and active/active scenarios. It allows for multiple active paths in
2724 forwarding state and for load-balancing options.
2726 The figure below describes how the access-priority attribute can be
2727 used.
2729 Hub#1 LAN (Primary/backup) Hub#2 LAN (Load-sharing)
2730 | |
2731 | access-priority 1 access-priority 1 |
2732 |--- CE1 ------- PE1 PE3 --------- CE3 --- |
2733 | |
2734 | |
2735 |--- CE2 ------- PE2 PE4 --------- CE4 --- |
2736 | access-priority 2 access-priority 1 |
2738 PE5
2739 |
2740 |
2741 |
2742 CE5
2743 |
2744 Spoke#1 site (Single-homed)
2746 In the figure above, Hub#2 requires load-sharing, so all the site-
2747 network-accesses must use the same access-priority value. On the
2748 other hand, as Hub#1 requires a primary site-network-access and a
2749 backup site-network-access, a higher access-priority setting will be
2750 configured on the primary site-network-access.
2752 Scenarios that are more complex can be modeled. Let's consider a Hub
2753 site with five accesses to the network (A1,A2,A3,A4,A5). The
2754 customer wants to load-share its traffic on A1,A2 in the nominal
2755 situation. If A1 and A2 fail, the customer wants to load-share its
2756 traffic on A3 and A4; finally, if A1 to A4 are down, he wants to use
2757 A5. We can model this easily by configuring the following access-
2758 priority values: A1=100, A2=100, A3=50, A4=50, A5=10.
2760 The access-priority scenario has some limitations. An access-
2761 priority scenario like the previous one with five accesses but with
2762 the constraint of having traffic load-shared between A3 and A4 in the
2763 case where A1 OR A2 is down is not achievable. But the authors
2764 believe that using the access-priority attribute will cover most of
2765 the deployment use cases and that the model can still be extended via
2766 augmentation to support additional use cases.
2768 5.9. SVC MTU
2770 The maximum MTU of subscriber service frames can be derived from the
2771 physical interface MTU by default, or specified under the "svc-mtu"
2772 leaf if it is different than the default number.
2774 5.10. Service
2776 The "service" container defines service parameters associated with
2777 the site.
2779 5.10.1. Bandwidth
2781 The service bandwidth refers to the bandwidth requirement between CE
2782 and PE. The requested bandwidth is expressed as svc-input-bandwidth
2783 and svc-output-bandwidth. Input/output direction is using customer
2784 site as reference: input bandwidth means download bandwidth for the
2785 site, and output bandwidth means upload bandwidth for the site.
2787 The service bandwidth is only configurable at the site-network-access
2788 level (i.e., for the site network access associated with the site).
2790 Using a different input and output bandwidth will allow service
2791 provider to know if a customer allows for asymmetric bandwidth access
2792 like ADSL. It can also be used to set a rate-limit in a different
2793 way for upload and download on symmetric bandwidth access.
2795 The svc-input-bandwidth or svc-output-bandwidth has specific type.
2796 This document defines four types:
2798 o bw-per-connection Bandwidth is per connection or site network
2799 access, providing rate enforcement for all service frames at the
2800 interface that are associated with a particular connection or
2801 network access.
2803 o bw-per-cos Bandwidth is per cos ,providing rate enforcement for
2804 all service frames for a given class of service with specific cos-
2805 id.
2807 o bw-per-site bandwidth is per site, providing rate enforcement for
2808 all service frames that are associated with a particular site-id.
2810 o opaque bandwidth is the total bandwidth that is not associated
2811 with any particular cos-id, site-id or site network access id.
2813 The svc-input-bandwidth or svc-output-bandwidth must include a "cos-
2814 id" parameter if the 'type' is set as 'bw-per-cos'. the cos-id can be
2815 assigned based on dot1p value in C-tag, or DSCP in IP header.
2816 Ingress service frames are metered against the bandwidth profile
2817 based on the cos- identifier.
2819 The svc-input-bandwidth or svc-output-bandwidth must include a "vpn-
2820 id" parameter if the 'type' is set as 'bw-per-connection'. Multiple
2821 input/output-bandwidthper-cos-id can be associated with the same
2822 Ethernet VPN service.
2824 5.10.2. QoS
2826 The model defines QoS parameters as an abstraction:
2828 o qos-classification-policy: Defines a set of ordered rules to
2829 classify customer traffic.
2831 o qos-profile: Provides a QoS scheduling profile to be applied.
2833 5.10.2.1. QoS Classification
2835 QoS classification rules are handled by qos-classification-policy.
2836 The qos-classification-policy is an ordered list of rules that match
2837 a flow or application and set the appropriate target class of service
2838 (target-class-id). The user can define the match using physical port
2839 reference or a more specific flow definition (based layer 2 source
2840 and destination MAC address, cos,dscp,cos-id, color-id etc.). A
2841 "color-id" will be assigned to a service frame to identify its QoS
2842 profile conformance. A service frame is "green" if it is conformant
2843 with "committed" rate of the bandwidth profile. A Service Frame is
2844 "yellow" if it is exceeding the "committed" rate but conformant with
2845 the "excess" rate of the bandwidth profile. Finally, a service frame
2846 is "red" if it is conformant with neither the "committed" nor
2847 "excess" rates of the bandwidth profile.
2849 When a flow definition is used, the user can use a target-sites leaf-
2850 list to identify the destination of a flow rather than using
2851 destination addresses. A rule that does not have a match statement
2852 is considered as a match-all rule. A service provider may implement
2853 a default terminal classification rule if the customer does not
2854 provide it. It will be up to the service provider to determine its
2855 default target class.
2857 5.10.2.2. QoS Profile
2859 User can choose between standard profile provided by the operator or
2860 a custom profile. The qos-profile defines the traffic scheduling
2861 policy to be used by the service provider.
2863 A custom qos-profile is defined as a list of class of services and
2864 associated properties. The properties are:
2866 o byte-offset: The optional "byte-offset" indicates how many bytes
2867 in the service frame header are excluded from rate enforcement.
2869 o rate-limit: Used to rate-limit the class of service. The value is
2870 expressed as a percentage of the global service bandwidth. When
2871 the qos-profile is implemented at CE side the svc-output-bandwidth
2872 is taken into account as reference. When it is implemented at PE
2873 side, the svc-input-bandwidth is used.
2875 o frame-delay: Used to define the latency constraint of the class.
2876 The latency constraint can be expressed as the lowest possible
2877 latency or a latency boundary expressed in milliseconds. How this
2878 latency constraint will be fulfilled is up to the service provider
2879 implementation: a strict priority queueing may be used on the
2880 access and in the core network, and/or a low latency routing may
2881 be created for this traffic class.
2883 o frame-jitter: Used to define the jitter constraint of the class.
2884 The jitter constraint can be expressed as the lowest possible
2885 jitter or a jitter boundary expressed in microseconds. How this
2886 jitter constraint will be fulfilled is up to the service provider
2887 implementation: a strict priority queueing may be used on the
2888 access and in the core network, and/or a jitter-aware routing may
2889 be created for this traffic class.
2891 o bandwidth: used to define a guaranteed amount of bandwidth for the
2892 class of service. It is expressed as a percentage. The
2893 "guaranteed-bw-percent" parameter uses available bandwidth as a
2894 reference. When the qos-profile container is implemented on the
2895 CE side, svc-output-bandwidth is taken into account as a
2896 reference. When it is implemented on the PE side, svc-input-
2897 bandwidth is used. By default, the bandwidth reservation is only
2898 guaranteed at the access level. The user can use the "end-to-end"
2899 leaf to request an end-to-end bandwidth reservation, including
2900 across the MPLS transport network. (In other words, the SP will
2901 activate something in the MPLS core to ensure that the bandwidth
2902 request from the customer will be fulfilled by the MPLS core as
2903 well.) How this is done (e.g., RSVP reservation, controller
2904 reservation) is out of scope for this document.
2906 Some constraints may not be offered by an SP; in this case, a
2907 deviation should be advertised. In addition, due to network
2908 conditions, some constraints may not be completely fulfilled by the
2909 SP; in this case, the SP should advise the customer about the
2910 limitations. How this communication is done is out of scope for this
2911 document.
2913 5.10.3. Multicast
2915 The "broadcast-unknowunicast-multicast" container defines the type of
2916 site in the customer multicast service topology: source, receiver, or
2917 both. These parameters will help the management system optimize the
2918 multicast service.
2920 Multiple multicast group to port mappings can be created using the
2921 "multicast-gp-address-mapping" list. The "multicast-gp-address-
2922 mapping" defines multicast group address and port lag number. Those
2923 parameters will help the SP select the appropriate association
2924 between interface and multicast group to fulfill the customer service
2925 requirement.
2927 A whole Layer-2 multicast frame (whether for data or control) SHOULD
2928 NOT be altered from a CE to CE(s) EXCEPT for the VLAN ID field,
2929 ensuring that it is transparently transported. If VLAN IDs are
2930 assigned by the SP, they can be altered.
2932 For point-to-point services, the provider only needs to deliver a
2933 single copy of each service frame to the remote PE, regardless
2934 whether the destination MAC address of the incoming frame is unicast,
2935 multicast or broadcast. Therefore, all service frames should be
2936 delivered unconditionally.
2938 B-U-M (Broadcast-UnknownUnicast-Multicast) frame forwarding in
2939 multipoint-to-multipoint services, on the other hand, involves both
2940 local flooding to other attachment circuits on the same PE and remote
2941 replication to all other PEs, thus consumes additional resources and
2942 core bandwidth. Special B-U-M frame disposition rules can be
2943 implemented at external facing interfaces (UNI or E-NNI) to rate-
2944 limit the B-U-M frames, in term of number of packets per second or
2945 bits per second.
2947 The threshold can apply to all B-U-M traffic, or one for each
2948 category.
2950 5.11. Site Management
2952 The "management" sub-container is intended for site management
2953 options, depending on the device ownership and security access
2954 control. The followings are three common management models:
2956 CE Provider Managed: The provider has the sole ownership of the CE
2957 device. Only the provider has access to the CE. The
2958 responsibility boundary between SP and customer is between CE and
2959 customer network. This is the most common use case.
2961 CE Customer Managed: The customer has the sole ownership of the CE
2962 device. Only the customer has access to the CE. In this model,
2963 the responsibility boundary between SP and customer is between PE
2964 and CE.
2966 CE Co-managed: The provider has ownership of the CE device and
2967 responsible for managing the CE. However, the provider grants the
2968 customer access to the CE for some configuration/monitoring
2969 purposes. In this co-managed mode, the responsibility boundary is
2970 the same as for the provider-managed model.
2972 The selected management mode is specified under the "type" leaf. The
2973 "address" leaf stores CE device management IP information. And the
2974 "management-transport" leaf is used to identify the transport
2975 protocol for management traffic: IPv4 or IPv6. Additional security
2976 options may be derived based on the particular management model
2977 selected.
2979 5.12. Security Filtering
2981 5.12.1. MAC Loop Protection
2983 MAC address flapping between different physical ports typically
2984 indicates a bridge loop condition in the subscriber network.
2985 Misleading entries in the MAC cache table can cause service frames to
2986 circulate around the network indefinitely and saturate the links
2987 throughout the provider's network, affecting other services in the
2988 same network. In case of EVPN, it also introduces massive BGP
2989 updates and control plane instability.
2991 The service provider may opt to implement a switching loop prevention
2992 mechanism at the external facing interfaces for multipoint-to-
2993 multipoint services by imposing a MAC address move threshold.
2995 The MAC move rate and prevention-type options are listed in the "mac-
2996 loop-prevention" container.
2998 5.12.2. MAC Address Limit
3000 The service provider may choose to impose a per-attachment circuit
3001 "mac-addr-limit" in addition to the service-level MAC limit, and
3002 specify the behavior when the limit is exceeded accordingly.
3004 5.13. Ethernet Service OAM
3006 The advent of Ethernet as a wide-area network technology brings
3007 additional requirements of end-to-end service monitoring and fault
3008 management in the carrier network, particularly in the area of
3009 service availability and Mean Time To Repair (MTTR). Ethernet
3010 Service OAM in the L2SM refers to the combined protocol suites of
3011 IEEE 802.1ag ([IEEE-802-1ag]) and ITU-T Y.1731 ([ITU-T-Y-1731]).
3013 Generally speaking, Ethernet Service OAM enables service providers to
3014 perform service continuity check, fault-isolation, and packet delay/
3015 jitter measurement at per customer per EVC granularity. The
3016 information collected from Ethernet Service OAM data sets is
3017 complementary to other higher layer IP/MPLS OSS tools to ensure the
3018 required service level agreements (SLAs) can be meet.
3020 The 802.1ag Connectivity Fault Management (CFM) functional model is
3021 structured with hierarchical maintenance domains (MDs), each assigned
3022 a unique maintenance level. Higher level MDs can be nested over
3023 lower level MDs. However, the MDs cannot intersect. The scope of
3024 each MD can be solely within a subscriber's network, solely within
3025 the provider's network, interact between the subscriber-to-provider
3026 or provider-to-provider edge equipment, or tunnel over another
3027 provider's network.
3029 Depending on the use case scenario, one or more maintenance end
3030 points (MEPs) can be placed on the external facing interface, sending
3031 CFM PDUs towards the core network (UP MEP) or downstream link (DOWN
3032 MEP).
3034 The "cfm-802.1-ag" sub-container under "port" currently presents two
3035 types of CFM maintenance association (MA): UP MEP for UNI-N to UNI-N
3036 Maintenance Association (MA) and DOWN MEP for UNI-N to UNI-C MA. For
3037 each MA, the user can define the maintenance domain ID (MAID), MEP
3038 level, MEP direction, remote MEP ID, CoS level of the CFM PDUs,
3039 Continuity Check Message (CCM) interval and hold time, alarm priority
3040 defect, CCM priority-type, etc.
3042 ITU-T Y.1731 Performance Monitoring (PM) provides essential network
3043 telemetry information that includes the measurement of Ethernet
3044 service frame delay, frame delay variation, frame loss, and frame
3045 throughput. The delay/jitter measurement can be either one-way or
3046 two-way. Typically, a Y.1731 PM probe sends a small amount of
3047 synthetic frames along with service frames to measure the SLA
3048 parameters.
3050 The "y-1731" sub-container under "port" contains a set of parameters
3051 for use to define the PM probe information, including MAID, local and
3052 remote MEP-ID, PM PDU type, message period and measurement interval,
3053 CoS level of the PM PDUs, loss measurement by synthetic or service
3054 frame options, one-way or two-way delay measurement, PM frame size,
3055 and session type.
3057 5.14. External ID References
3059 The service model sometimes refers to external information through
3060 identifiers. As an example, to order a cloud-access to a particular
3061 cloud service provider (CSP), the model uses an identifier to refer
3062 to the targeted CSP. If a customer is directly using this service
3063 model as an API (through REST or NETCONF, for example) to order a
3064 particular service, the SP should provide a list of authorized
3065 identifiers. In the case of cloud-access, the SP will provide the
3066 associated identifiers for each available CSP. The same applies to
3067 other identifiers, such as std-qos-profile.
3069 How an SP provides the meanings of those identifiers to the customer
3070 is out of scope for this document.
3072 5.15. Defining NNIs and Inter-AS support
3074 An autonomous system (AS) is a single network or group of networks
3075 that is controlled by a common system administration group and that
3076 uses a single, clearly defined routing protocol. In some cases, VPNs
3077 need to span different ASes in different geographic areas or span
3078 different SPs. The connection between ASes is established by the SPs
3079 and is seamless to the customer. Examples include:
3081 o A partnership between SPs (e.g., carrier, cloud) to extend their
3082 VPN service seamlessly.
3084 o An internal administrative boundary within a single SP (e.g.,
3085 backhaul versus core versus data center).
3087 NNIs (network-to-network interfaces) have to be defined to extend the
3088 VPNs across multiple ASes. [RFC4761] defines multiple flavors of VPN
3089 NNI implementations. Each implementation has pros and cons; this
3090 topic is outside the scope of this document. For example, in an
3091 Inter-AS option A, autonomous system border router (ASBR) peers are
3092 connected by multiple interfaces with at least one of those
3093 interfaces spanning the two ASes while being present in the same VPN.
3094 In order for these ASBRs to signal label blocks, they associate each
3095 interface with a Virtual Switching (VSI) instance and a Border
3096 Gateway Protocol (BGP) session. As a result, traffic between the
3097 back-to-back VPLS is Ethernet. In this scenario, the VPNs are
3098 isolated from each other, and because the traffic is ethernet, QoS
3099 mechanisms that operate on Ethernet traffic can be applied to achieve
3100 customer service level agreements (SLAs).
3102 -------- -------------- -----------
3103 / \ / \ / \
3104 | Cloud | | | | |
3105 | Provider |-----NNI-----| |----NNI---| Data Center |
3106 | #1 | | | | |
3107 \ / | | \ /
3108 -------- | | -----------
3109 | |
3110 -------- | My network | -----------
3111 / \ | | / \
3112 | Cloud | | | | |
3113 | Provider |-----NNI-----| |---NNI---| L2VPN |
3114 | #2 | | | | Partner |
3115 \ / | | | |
3116 -------- | | | |
3117 \ / | |
3118 -------------- \ /
3119 | -----------
3120 |
3121 NNI
3122 |
3123 |
3124 -------------------
3125 / \
3126 | |
3127 | |
3128 | |
3129 | L2VPN Partner |
3130 | |
3131 \ /
3132 -------------------
3134 The figure above describes an SP network called "My network" that has
3135 several NNIs. This network uses NNIs to:
3137 o increase its footprint by relying on L2VPN partners.
3139 o connect its own data center services to the customer L2VPN.
3141 o enable the customer to access its private resources located in a
3142 private cloud owned by some CSPs.
3144 5.15.1. Defining an NNI with the Option A Flavor
3146 AS A AS B
3147 ------------------- -------------------
3148 / \ / \
3149 | | | |
3150 | ++++++++ Inter-AS link ++++++++ |
3151 | + +_______________+ + |
3152 | + (VSI1)---(VPN1)----(VSI1) + |
3153 | + ASBR + + ASBR + |
3154 | + (VSI2)---(VPN2)----(VSI2) + |
3155 | + +_______________+ + |
3156 | ++++++++ ++++++++ |
3157 | | | |
3158 | | | |
3159 | | | |
3160 | ++++++++ Inter-AS link ++++++++ |
3161 | + +_______________+ + |
3162 | + (VSI1)---(VPN1)----(VSI1) + |
3163 | + ASBR + + ASBR + |
3164 | + (VSI2)---(VPN2)----(VSI2) + |
3165 | + +_______________+ + |
3166 | ++++++++ ++++++++ |
3167 | | | |
3168 | | | |
3169 \ / \ /
3170 ------------------- -------------------
3172 In option A, the two ASes are connected to each other with physical
3173 links on ASBRs. For resiliency purposes, there may be multiple
3174 physical connections between the ASes. A VPN connection -- physical
3175 or logical (on top of physical) -- is created for each VPN that needs
3176 to cross the AS boundary, thus providing a back-to-back VPLS model.
3178 From a service model's perspective, this VPN connection can be seen
3179 as a site. Let's say that AS B wants to extend some VPN connections
3180 for VPN C on AS A. The administrator of AS B can use this service
3181 model to order a site on AS A. All connection scenarios could be
3182 realized using the features of the current model. As an example, the
3183 figure above shows two physical connections that have logical
3184 connections per VPN overlaid on them. This could be seen as a
3185 multiVPN scenario. Also, the administrator of AS B will be able to
3186 choose the appropriate routing protocol (e.g., E-BGP) to dynamically
3187 exchange routes between ASes.
3189 This document assumes that the option A NNI flavor SHOULD reuse the
3190 existing VPN site modeling.
3192 Example: a customer wants its CSP A to attach its virtual network N
3193 to an existing L2VPN (VPN1) that he has from L2VPN SP B.
3195 CSP A L2VPN SP B
3197 ----------------- -------------------
3198 / \ / \
3199 | | | | |
3200 | VM --| ++++++++ NNI ++++++++ |--- VPN1
3201 | | + +_________+ + | Site#1
3202 | |--------(VSI1)---(VPN1)--(VSI1)+ |
3203 | | + ASBR + + ASBR + |
3204 | | + +_________+ + |
3205 | | ++++++++ ++++++++ |
3206 | VM --| | | |--- VPN1
3207 | |Virtual | | | Site#2
3208 | |Network | | |
3209 | VM --| | | |--- VPN1
3210 | | | | | Site#3
3211 \ / \ /
3212 ----------------- -------------------
3213 |
3214 |
3215 VPN1
3216 Site#4
3218 To create the VPN connectivity, the CSP or the customer may use the
3219 L2VPN service model that SP B exposes. We could consider that, as
3220 the NNI is shared, the physical connection (bearer) between CSP A and
3221 SP B already exists. CSP A may request through a service model the
3222 creation of a new site with a single site-network-access (single-
3223 homing is used in the figure). As a placement constraint, CSP A may
3224 use the existing bearer reference it has from SP A to force the
3225 placement of the VPN NNI on the existing link. The XML below
3226 illustrates a possible configuration request to SP B:
3228
3229 CSP_A_attachment
3230
3231 NY
3232 US
3233
3234 site-vpn-flavor-nni
3235
3236
3237 bgp-l2vpn
3238
3239 12456487
3240 kompella
3241
3242
3243
3244
3245
3246 CSP_A_VN1
3247
3248
3249 17
3250
3251
3252 dot1q
3253
3254
3255
3256
3257 opaque
3258 450000000
3259 20000000
3260 1000000000
3261 200000000
3262
3263
3264 350000000
3265 10000000
3266 800000000
3267 200000000
3268
3269
3270
3271 12456487
3272 spoke-role
3273
3274
3275
3276
3277 customer-managed
3279
3280
3282 The case described above is different from a scenario using the
3283 cloud-accesses container, as the cloud-access provides a public cloud
3284 access while this example enables access to private resources located
3285 in a CSP network.
3287 5.15.2. Defining an NNI with the Option B Flavor
3289 AS A AS B
3290 ------------------- -------------------
3291 / \ / \
3292 | | | |
3293 | ++++++++ Inter-AS link ++++++++ |
3294 | + +_______________+ + |
3295 | + + + + |
3296 | + ASBR +<---MP-BGP---->+ ASBR + |
3297 | + + + + |
3298 | + +_______________+ + |
3299 | ++++++++ ++++++++ |
3300 | | | |
3301 | | | |
3302 | | | |
3303 | ++++++++ Inter-AS link ++++++++ |
3304 | + +_______________+ + |
3305 | + + + + |
3306 | + ASBR +<---MP-BGP---->+ ASBR + |
3307 | + + + + |
3308 | + +_______________+ + |
3309 | ++++++++ ++++++++ |
3310 | | | |
3311 | | | |
3312 \ / \ /
3313 ------------------- -------------------
3315 In option B, the two ASes are connected to each other with physical
3316 links on ASBRs. For resiliency purposes, there may be multiple
3317 physical connections between the ASes. The VPN "connection" between
3318 ASes is done by exchanging VPN routes through MP-BGP [RFC4761].
3320 There are multiple flavors of implementations of such an NNI. For
3321 example:
3323 1. The NNI is internal to the provider and is situated between a
3324 backbone and a data center. There is enough trust between the
3325 domains to not filter the VPN routes. So, all the VPN routes are
3326 exchanged. RT filtering may be implemented to save some
3327 unnecessary route states.
3329 2. The NNI is used between providers that agreed to exchange VPN
3330 routes for specific RTs only. Each provider is authorized to use
3331 the RT values from the other provider.
3333 3. The NNI is used between providers that agreed to exchange VPN
3334 routes for specific RTs only. Each provider has its own RT
3335 scheme. So, a customer spanning the two networks will have
3336 different RTs in each network for a particular VPN.
3338 Case 1 does not require any service modeling, as the protocol enables
3339 the dynamic exchange of necessary VPN routes.
3341 Case 2 requires that an RT-filtering policy on ASBRs be maintained.
3342 From a service modeling point of view, it is necessary to agree on
3343 the list of RTs to authorize.
3345 In Case 3, both ASes need to agree on the VPN RT to exchange, as well
3346 as how to map a VPN RT from AS A to the corresponding RT in AS B (and
3347 vice versa).
3349 Those modelings are currently out of scope for this document.
3351 CSP A L3VPN SP B
3353 ----------------- ------------------
3354 / \ / \
3355 | | | | |
3356 | VM --| ++++++++ NNI ++++++++ |--- VPN1
3357 | | + +__________+ + | Site#1
3358 | |-------+ + + + |
3359 | | + ASBR +<-MP-BGP->+ ASBR + |
3360 | | + +__________+ + |
3361 | | ++++++++ ++++++++ |
3362 | VM --| | | |--- VPN1
3363 | |Virtual | | | Site#2
3364 | |Network | | |
3365 | VM --| | | |--- VPN1
3366 | | | | | Site#3
3367 \ / | |
3368 ----------------- | |
3369 \ /
3370 ------------------
3371 |
3372 |
3373 VPN1
3374 Site#4
3376 The example above describes an NNI connection between CSP A and SP
3377 network B. Both SPs do not trust themselves and use a different RT
3378 allocation policy. So, in terms of implementation, the customer VPN
3379 has a different RT in each network (RT A in CSP A and RT B in SP
3380 network B). In order to connect the customer virtual network in CSP
3381 A to the customer IP VPN (VPN1) in SP network B, CSP A should request
3382 that SP network B open the customer VPN on the NNI (accept the
3383 appropriate RT). Who does the RT translation depends on the
3384 agreement between the two SPs: SP B may permit CSP A to request VPN
3385 (RT) translation.
3387 5.15.3. Defining an NNI with the Option C Flavor
3388 AS A AS B
3389 ------------------- -------------------
3390 / \ / \
3391 | | | |
3392 | | | |
3393 | | | |
3394 | ++++++++ Multihop E-BGP ++++++++ |
3395 | + + + + |
3396 | + + + + |
3397 | + RGW +<----MP-BGP---->+ RGW + |
3398 | + + + + |
3399 | + + + + |
3400 | ++++++++ ++++++++ |
3401 | | | |
3402 | | | |
3403 | | | |
3404 | | | |
3405 | | | |
3406 | ++++++++ Inter-AS link ++++++++ |
3407 | + +_______________+ + |
3408 | + + + + |
3409 | + ASBR + + ASBR + |
3410 | + + + + |
3411 | + +_______________+ + |
3412 | ++++++++ ++++++++ |
3413 | | | |
3414 | | | |
3415 | | | |
3416 | ++++++++ Inter-AS link ++++++++ |
3417 | + +_______________+ + |
3418 | + + + + |
3419 | + ASBR + + ASBR + |
3420 | + + + + |
3421 | + +_______________+ + |
3422 | ++++++++ ++++++++ |
3423 | | | |
3424 | | | |
3425 \ / \ /
3426 ------------------- -------------------
3428 From a VPN service's perspective, the option C NNI is very similar to
3429 option B, as an MP-BGP session is used to exchange VPN routes between
3430 the ASes. The difference is that the forwarding plane and the
3431 control plane are on different nodes, so the MP-BGP session is
3432 multihop between routing gateway (RGW) nodes. From a VPN service's
3433 point of view, modeling options B and C will be identical.
3435 5.16. Inter-Provider support with EVC and OVC or NNI
3437 In the case where the ASes belong to different providers, one might
3438 imagine that providers would like to have fewer signaling sessions
3439 crossing the AS boundary and that the entities that terminate the
3440 sessions could be restricted to a smaller set of devices. Two
3441 approach can be taken:
3443 (a) Inter-provider control connections to run only between the two
3444 border routers
3446 (b) Allow an end-to-end, multi-segment connectivity to be
3447 constructed out of several connectivity segments, without
3448 maintaining an end-to-end control connection.
3450 Inter-provider control connection described in (a) can be realized
3451 using techniques of section 5.15(i.e., defining NNI). Multi-segment
3452 connectivity described in (b) can produce an inter-AS solution that
3453 more closely resembles option (b) in [RFC4364]. It can be realized
3454 using combination of Per Site connectivity and OVC at different
3455 segments, e.g., end to end connectivity between site_1 and Site 3 can
3456 be constructed by stitching network access connectivity within site_1
3457 with OVC1, OVC3, OVC4 and network access connectivity within
3458 site)3(See the following figure) Note that OVC can also be regarded
3459 as network access connectivity within a site and can be created as a
3460 normal site using L2SM service model.
3462 Site_1
3463 PE ------ ------
3464 //o/ \\\\ //// \\\\
3465 | \--OVC1---- o o - - - - - |
3466 | | OVC3\ |
3467 | /--OVC2-----o o- - - -\ \ |
3468 \\o\ //// \\\\ \ \ ------
3469 Site_2PE ------ ----- \/o/\ \\\\
3470 | \ |
3471 | \- - -- oPE Site_3
3472 | OVC4 |
3473 ------ ////
3474 //// /\o\ ----
3475 | / |
3476 | / |
3477 | OVC5 |
3478 \\o/ ////
3479 PE ------
3480 Site_4
3482 In this figure, we use EBGP redistribution of L2VPN NLRI from AS to
3483 neighboring AS. First, the PE routers use Internal BGP (IBGP) to
3484 redistribute L2VPN NLRI either to an ASBR, or to a route reflector of
3485 which an ASBR is a client. The ASBR then uses EBGP to redistribute
3486 those L2VPN NLRI to an ASBR in another AS, which in turn distributes
3487 them to the PE routers in that AS, or perhaps to another ASBR which
3488 in turn distributes them, and so on.
3490 In this case, a PE can learn the address of an ASBR through which it
3491 could reach another PE to which it wishes to establish a
3492 connectivity. That is, a local PE will receive a BGP advertisement
3493 containing L2VPN NLRI corresponding to an L2VPN instance in which the
3494 local PE has some attached members. The BGP next-hop for that L2VPN
3495 NLRI will be an ASBR of the local AS. Then, rather than building a
3496 control connection all the way to the remote PE, it builds one only
3497 to the ASBR. A connectivity segment can now be established from the
3498 PE to the ASBR. The ASBR in turn can establish a connectivity to the
3499 ASBR of the next AS, and stitching that connectivity to the
3500 connectivity from the PE as described in Section 3.5.4 and [RFC6073].
3501 Repeating the process at each ASBR leads to a sequence of
3502 connectivity segments that, when stitching together, connect the two
3503 PEs.
3505 Note that in the approach just described, the local PE may never
3506 learn the IP address of the remote PE. It learns the L2VPN NLRI
3507 advertised by the remote PE, which need not contain the remote PE
3508 address, and it learns the IP address of the ASBR that is the BGP
3509 next hop for that NLRI.
3511 When this approach is used for VPLS, or for full-mesh VPWS, it leads
3512 to a full mesh of connectivity among the PEs, but it does not require
3513 a full mesh of control connections (LDP or L2TPv3 sessions).
3514 Instead, the control connections within a single AS run among all the
3515 PEs of that AS and the ASBRs of the AS. A single control connection
3516 between the ASBRs of adjacent ASes can be used to support however
3517 many AS-to-AS connectivity segments are needed.
3519 6. Interaction with Other YANG Modules
3521 As expressed in Section 4, this service module is not intended to
3522 configure the network element, but is instantiated in a management
3523 system.
3525 The management system might follow modular design and comprise at
3526 least two different components:
3528 a. The component instantiating the service model (let's call it the
3529 service component)
3531 b. The component responsible for network element configuration
3532 (let's call it the configuration component)
3534 In some cases, when a split is needed between the behavior and
3535 functions that a customer requests and the technology that the
3536 network operator has available to deliver the service
3537 [I-D.ietf-opsawg-service-model-explained], a new component can be
3538 separated out of the service component (let's call it the control
3539 component). This component is responsible for network-centric
3540 operation and is aware of many features such as topology, technology,
3541 and operator policy. As an optional component, it can use the
3542 service model as input and is not required at all if the control
3543 component delegates its control operations to the configuration
3544 component.
3546 In Section 7 we provide some example of translation of service
3547 provisioning requests to router configuration lines as an
3548 illustration. In the NETCONF/YANG ecosystem, it is expected that
3549 NETCONF and YANG will be used between the configuration component and
3550 network elements to configure the requested service on those
3551 elements.
3553 In this framework, it is expected that YANG models will be used for
3554 configuring service components on network elements. There will be a
3555 strong relationship between the abstracted view provided by this
3556 service model and the detailed configuration view that will be
3557 provided by specific configuration models for network elements such
3558 as those defined in [I-D.ietf-bess-l2vpn-yang] and
3559 [I-D.ietf-bess-evpn-yang]. Service components needing configuration
3560 on network elements in support of the service model defined in this
3561 document include:
3563 o Network Instance definition including VPN policy expression.
3565 o Physical interface.
3567 o Ethernet layer (VLAN ID).
3569 o QoS: classification, profiles, etc.
3571 o Signaling Options: support of configuration of all protocols
3572 listed in the document, as well as vpn policies associated with
3573 these protocols.
3575 o Ethernet Service OAM Support.
3577 7. Service Model Usage Example
3579 As explained in Section 4, this service model is intended to be
3580 instantiated at a management layer and is not intended to be used
3581 directly on network elements. The management system serves as a
3582 central point of configuration of the overall service.
3584 This section provides an example on how a management system can use
3585 this model to configure an L2VPN service on network elements.
3587 The example is for of a VPN service for 3 sites using point-to-point
3588 EVC and a Hub and Spoke VPN service topology as shown in Figure 7.
3589 Loadbalancing is not considered in this case.
3591 UNI Site1
3592 ............
3593 : : E-Line using P2P EVC
3594 :Spoke Site:-----PE1--------------------------+
3595 : : | UNI Site3
3596 :..........: | ............
3597 | : :
3598 PE3-----: Hub Site :
3599 UNI Site2 | : :
3600 ............ | :..........:
3601 : : E-Line using P2P EVC |
3602 :Spoke Site:-----PE2--------------------------+
3603 : :
3604 :..........:
3606 Figure 7: Reference Network for Simple Example
3608 The following XML describes the overall simplified service
3609 configuration of this VPN.
3611
3612 12456487
3613 evpl
3614
3615
3616 UNI1
3617 UNI3
3618
3619
3620 hub-spoke
3621
3623
3624 12456488
3625 evpl
3626
3627
3628 UNI2
3629 UNI3
3630
3631
3632 hub-spoke
3633
3635 When receiving the request for provisioning the VPN service, the
3636 management system will internally (or through communication with
3637 another OSS component) allocates VPN route-targets. In this specific
3638 case two Route Targets (RTs) will be allocated (100:1 for Hubs and
3639 100:2 for Spokes). The output below describes the configuration of
3640 Spoke UNI Site1.
3642
3643 Spoke_Site1
3644
3645 NY
3646 US
3647
3648
3649
3650 bgp-l2vpn
3651
3652 12456487
3653 kompella
3654
3655
3656
3657
3658
3659 Spoke_UNI-Site1
3660
3661
3662
3663 20
3664
3665
3666
3667
3668
3669 17
3670
3671
3672 dot1q
3673
3674
3675
3676
3677 opaque
3678 450000000
3679 20000000
3680 1000000000
3681 200000000
3682
3683
3684 350000000
3685 10000000
3686 800000000
3687 200000000
3688
3689
3690
3691 TUNNEL
3692 TRUE
3693
3694
3695 12456487
3696 spoke-role
3697
3698
3699
3700
3701 provider-managed
3702
3703
3705 When receiving the request for provisioning Spoke1 site, the
3706 management system MUST allocate network resources for this site. It
3707 MUST first determine the target network elements to provision the
3708 access, and especially the PE router (and may be an aggregation
3709 switch). As described in Section 5.3.1, the management system SHOULD
3710 use the location information and SHOULD use the access-diversity
3711 constraint to find the appropriate PE. In this case, we consider
3712 Spoke1 requires PE diversity with Hub and that management system
3713 allocate PEs based on lowest distance. Based on the location
3714 information, the management system finds the available PEs in the
3715 nearest area of the customer and picks one that fits the access-
3716 diversity constraint.
3718 When the PE is chosen, the management system needs to allocate
3719 interface resources on the node. One interface is selected from the
3720 PE available pool. The management system can start provisioning the
3721 PE node by using any mean (Netconf, CLI, ...). The management system
3722 will check if a VFI is already present that fits the needs. If not,
3723 it will provision the VFI: Route Distinguisher will come from
3724 internal allocation policy model, route-targets are coming from the
3725 vpn-policy configuration of the site (management system allocated
3726 some RTs for the VPN). As the site is a Spoke site (site-role), the
3727 management system knows which RT must be imported and exported. As
3728 the site is provider managed, some management route-targets may also
3729 be added (100:5000). Standard provider VPN policies MAY also be
3730 added in the configuration.
3732 Example of generated PE configuration:
3734 l2vpn vfi context one
3735 vpn id 12456487
3736 autodiscovery bgp signaling bgp
3737 ve id 1001 <----identify the PE routers within the VPLS domain
3738 ve range 50 <---- VE size
3739 route-distinguisher 100:3123234324
3740 route-target import 100:1
3741 route-target import 100:5000 <---- Standard SP configuration
3742 route-target export 100:2 for provider managed CE
3743 !
3745 When the VFI has been provisioned, the management system can start
3746 configuring the access on the PE using the allocated interface
3747 information. The tag or VLAN (e.g., service instance tag)is chosen
3748 by the management system. One tag will be picked from an allocated
3749 subnet for the PE, another will be used for the CE configuration.
3750 LACP protocols will also be configured between PE and CE and due to
3751 provider managed model, the choice is up to service provider. This
3752 choice is independent of the LACP protocol chosen by customer.
3754 Example of generated PE configuration:
3756 !
3757 bridge-domain 1
3758 member Ethernet0/0 service-instance 100
3759 member vfi one
3761 !
3762 l2 router-id 10.100.1.1
3763 !
3765 interface Ethernet0/0
3766 no ip address
3767 service instance 100 ethernet
3768 encapsulation dot1q 100
3769 !
3771 !
3772 router bgp 1
3773 bgp log-neighbor-changes
3774 neighbor 10.100.1.4 remote-as 1
3775 neighbor 10.100.1.4 update-source Loopback0
3776 !
3777 address-family l2vpn vpls
3778 neighbor 10.100.1.4 activate
3779 neighbor 10.100.1.4 send-community extended
3780 neighbor 10.100.1.4 suppress-signaling-protocol ldp
3781 exit-address-family
3783 !
3784 interface vlan 100 <-- Associating the Attachment
3785 no ip address Circuit with the VSI at the PE
3786 xconnect vfi PE1-VPLS-A
3787 !
3788 vlan 100
3789 state active
3791 As the CE router is not reachable at this stage, the management
3792 system can produce a complete CE configuration that can be uploaded
3793 to the node by manual operation before sending the CE to customer
3794 premise. The CE configuration will be built as for the PE. Based on
3795 the CE type (vendor/model) allocated to the customer and bearer
3796 information, the management system knows which interface must be
3797 configured on the CE. PE-CE link configuration is expected to be
3798 handled automatically using the service provider OSS as both
3799 resources are managed internally. CE to LAN interface parameters
3800 like dot1Q tag are derived from the ethernet-connection taking into
3801 account how management system distributes dot1Q tag between PE and CE
3802 within subnet. This will allow to produce a plug'n'play
3803 configuration for the CE.
3805 Example of generated CE configuration:
3807 interface Ethernet0/1
3808 switchport trunk allowed vlan none
3809 switchport mode trunk
3810 service instance 100 ethernet
3811 encapsulation default
3812 l2protocol forward cdp
3813 xconnect 1.1.1.1 100 encapsulation mpls
3814 !
3816 8. YANG Module
3818 file "ietf-l2vpn-svc@2017-06-22.yang"
3819 module ietf-l2vpn-svc {
3820 namespace "urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc";
3821 prefix "l2svc";
3823 import ietf-inet-types {
3824 prefix inet;
3825 }
3826 import ietf-yang-types {
3827 prefix yang;
3828 }
3829 import iana-if-type {
3830 prefix ianaift;
3831 }
3832 organization
3833 "IETF L2SM Working Group.";
3834 contact
3835 "WG List: l2sm@ietf.org
3836 Editor: giuseppe.fioccola@telecomitalia.it";
3837 description
3838 "The YANG module defines a generic service configuration
3839 model for Layer 2 VPN services common across all of the
3840 vendor implementations.";
3841 revision 2017-06-22{
3842 description
3843 "Initial revision -02 version";
3844 reference
3845 "draft-ietf-l2sm-l2vpn-service-model-02.txt
3846 A YANG Data Model for L2VPN Service Delivery.";
3847 }
3848 /* Features */
3849 feature multicast{
3850 description
3851 "Enables multicast capabilities in a VPN.";
3852 }
3853 feature extranet-vpn{
3854 description
3855 "Extranet vpn";
3856 }
3857 feature L2CP-control {
3858 description
3859 "L2CP control";
3860 }
3861 feature input-bw {
3862 description
3863 "Input Bandwidth";
3864 }
3865 feature output-bw {
3866 description
3867 "Output Bandwidth";
3868 }
3870 feature uni-list {
3871 description
3872 "Enable support UNI list";
3873 }
3875 feature ovc-type {
3876 description
3877 "Enable support OVC type";
3878 }
3879 feature cloud-access {
3880 description
3881 "Allow VPN to connect to a Cloud Service
3882 provider.";
3883 }
3884 feature oam-3ah {
3885 description
3886 "Enables support of OAM 802.3ah";
3887 }
3888 feature micro-bfd {
3889 description
3890 "Enables support of Micro-BFD";
3891 }
3892 feature bfd {
3893 description
3894 "Enables support of BFD";
3895 }
3896 feature signaling-options {
3897 description
3898 "Enable support of signaling option";
3899 }
3900 feature site-diversity {
3901 description
3902 "Enables support of site diversity constraints";
3903 }
3904 feature encryption {
3905 description
3906 "Enables support of encryption";
3907 }
3908 feature always-on {
3909 description
3910 "Enables support for always-on access
3911 constraint.";
3912 }
3913 feature requested-type {
3914 description
3915 "Enables support for requested-type access
3916 constraint.";
3917 }
3918 feature bearer-reference {
3919 description
3920 "Enables support for bearer-reference access
3921 constraint.";
3922 }
3923 feature qos {
3924 description
3925 "Enables support of Class of Services";
3926 }
3927 feature qos-custom {
3928 description
3929 "Enables support of custom qos profile";
3930 }
3931 feature lag-interface{
3932 description
3933 "Enable lag-interface";
3934 }
3935 feature vlan {
3936 description
3937 "Enable VLAN";
3938 }
3939 feature dot1q{
3940 description
3941 "Enable Dot1Q";
3942 }
3943 feature qinq {
3944 description
3945 "Enable QinQ";
3946 }
3947 feature qinany{
3948 description
3949 "Enable QinAny";
3950 }
3951 feature vxlan {
3952 description
3953 "Enable VxLAN";
3954 }
3956 /* Typedefs */
3958 typedef svc-id {
3959 type string;
3960 description
3961 "Service ID";
3962 }
3963 typedef direction-type {
3964 type string;
3965 description
3966 "Direction";
3967 }
3968 typedef evc-id-type {
3969 type string;
3970 description
3971 "EVC ID type";
3972 }
3973 typedef ovc-id-type {
3974 type string;
3975 description
3976 "OVC ID type";
3977 }
3978 typedef ccm-priority-type {
3979 type uint8 {
3980 range "0..7";
3981 }
3982 description
3983 "A 3 bit priority value to be used in the VLAN tag, if present
3984 in the transmitted frame.";
3985 }
3986 typedef control-mode {
3987 type enumeration {
3988 enum peer {
3989 description
3990 "Peer mode";
3991 }
3992 enum tunnel {
3993 description
3994 "Tunnel mode";
3995 }
3996 enum discard {
3997 description
3998 "Discard mode";
3999 }
4000 }
4001 description
4002 "Defining a type of the control mode";
4003 }
4004 typedef neg-mode {
4005 type enumeration {
4006 enum full-duplex {
4007 description
4008 "Full duplex mode";
4009 }
4010 enum auto-neg {
4011 description
4012 "Auto negotiation mode";
4013 }
4015 }
4016 description
4017 "Defining a type of the negotiation mode";
4018 }
4020 /* Identities */
4021 identity multicast-tree-type {
4022 description
4023 "Base identity for multicast tree type.";
4024 }
4025 identity ssm-tree-type {
4026 base multicast-tree-type;
4027 description
4028 "Identity for SSM tree type.";
4029 }
4030 identity asm-tree-type {
4031 base multicast-tree-type;
4032 description
4033 "Identity for ASM tree type.";
4034 }
4035 identity bidir-tree-type {
4036 base multicast-tree-type;
4037 description
4038 "Identity for bidirectional tree type.";
4039 }
4041 identity mapping-type{
4042 description
4043 "Identity mapping-type";
4044 }
4045 identity static-mapping{
4046 base mapping-type;
4047 description
4048 "Identity for static mapping, i.e.,attach the interface
4049 to the Multicast group as static member";
4050 }
4051 identity dynamic-mapping{
4052 base mapping-type;
4053 description
4054 "Identity for dynamic mapping, i.e.,interface was added
4055 to the Multicast group as a result of snooping";
4056 }
4058 identity tf-type{
4059 description
4060 "Identity traffic-type";
4061 }
4062 identity multicast-traffic {
4063 base tf-type;
4064 description
4065 "Identity for multicast traffic";
4066 }
4067 identity broadcast-traffic {
4068 base tf-type;
4069 description
4070 "Identity for broadcast traffic";
4071 }
4072 identity unknown-unicast-traffic {
4073 base tf-type;
4074 description
4075 "Identity for unknown unicast traffic";
4076 }
4077 identity pwe-encapsulation-type{
4078 description
4079 "Identity pwe-encapsulation-type";
4080 }
4081 identity ethernet-over-mpls {
4082 base pwe-encapsulation-type;
4083 description
4084 "Identity for ethernet over mpls";
4085 }
4086 identity ethernet-tagged-mpls {
4087 base pwe-encapsulation-type;
4088 description
4089 "Identity for ethernet tagged over mpls";
4090 }
4092 identity l2tp-pw-type {
4093 description
4094 "Identity for L2TP PW type";
4095 }
4097 identity encapsulation-type {
4098 description
4099 "Identity for encapsulation type";
4100 }
4101 identity ethernet-type {
4102 base encapsulation-type;
4103 description
4104 "Identity for encapsulation type";
4105 }
4106 identity vlan-type {
4107 base encapsulation-type;
4108 description
4109 "Identity for encapsulation type";
4110 }
4112 identity protection-model {
4113 description
4114 "Identity of protection model";
4115 }
4117 identity oneplusone{
4118 base protection-model;
4119 description
4120 "In this scheme, the primary circuitEVC or OVC will be
4121 protected by a backup circuitEVC or OVC, typically meeting certain
4122 diverse path/fiber/site/node criteria. Both primary and
4123 protection circuits are provisioned to be in the active forwarding
4124 state. The subscriber may choose to send the same service frames
4125 across both circuits simultaneously.";
4126 }
4128 identity one2one{
4129 base protection-model;
4130 description
4131 "In this scheme, a backup circuit to the primary
4132 circuit is provisioned. Depending on the implementation
4133 agreement, the protection circuits may either always be in active
4134 forwarding state, or may only become active when a faulty state is
4135 detected on the primary circuit.";
4136 }
4137 identity eth-type {
4138 description
4139 "Identity of ethernet type";
4140 }
4142 identity bw-type {
4143 description
4144 "Identity of bandwidth";
4145 }
4146 identity bw-per-cos {
4147 base bw-type;
4148 description
4149 "Bandwidth is per cos";
4150 }
4151 identity bw-per-evc-ovc {
4152 base bw-type;
4153 description
4154 "Bandwidth is per evc or per ovc";
4155 }
4156 identity bw-per-port {
4157 base bw-type;
4158 description
4159 "Bandwidth is per site network access";
4160 }
4162 identity opaque {
4163 base bw-type;
4164 description
4165 "Opaque";
4166 }
4167 identity site-type {
4168 description
4169 "Identity of site type.";
4170 }
4171 identity uni {
4172 base site-type;
4173 description
4174 "Identity of User Network Interface ";
4175 }
4176 identity enni {
4177 base site-type;
4178 description
4179 "Identity of External Network to Network Interface";
4180 }
4182 identity service-type {
4183 description
4184 "Identity of service type.";
4185 }
4186 identity vpws {
4187 base service-type;
4188 description
4189 " point-to-point Virtual Private Wire Services(VPWS) type.";
4190 }
4191 identity pwe3 {
4192 base service-type;
4193 description
4194 " Pseudo-Wire Emulation Edge to
4195 Edge(PWE3)Service type. .";
4197 }
4198 identity evpn {
4199 base service-type;
4200 description
4201 "Ethernet VPN Service Type,
4202 Ethernet VPNs are specified in RFC 7432";
4203 }
4205 identity vpls-ldp {
4206 base service-type;
4207 description
4208 "LDP based multipoint Virtual Private LAN services (VPLS) Service Type.
4209 This VPLS uses LDP-signaled Pseudowires";
4210 }
4212 identity vpls-bgp {
4213 base service-type;
4214 description
4215 "BGP based multipoint Virtual Private LAN services (VPLS) Service Type.
4216 This VPLS uses a Border Gateway Protocol (BGP) control plane as
4217 described in RFC4761 and RFC6624. ";
4218 }
4219 identity epl {
4220 base service-type;
4221 description
4222 "Ethernet Private Line (EPL) Service Type. ";
4223 }
4224 identity evpl {
4225 base service-type;
4226 description
4227 "Ethernet Virtual Private Line (EVPL) Service Type. ";
4228 }
4230 identity ep-lan {
4231 base service-type;
4232 description
4233 " Ethernet Private LAN (EP-LAN)Service Type. ";
4234 }
4235 identity evp-lan {
4236 base service-type;
4237 description
4238 " Ethernet Virtual Private LAN (EVP-LAN)Service Type. ";
4239 }
4241 identity bundling-type {
4242 description
4243 "Bundling type.";
4244 }
4245 identity bundling {
4246 base bundling-type;
4247 description
4248 "Identity for bundling";
4249 }
4250 identity all2one-Bundling {
4251 base bundling-type;
4252 description
4253 "Identity for all to one bundling";
4254 }
4255 identity color-id {
4256 description
4257 "Identity of color id";
4258 }
4259 identity color-id-evc {
4260 base color-id;
4261 description
4262 "Identity of color id base on EVC";
4263 }
4264 identity color-id-evc-cvlan {
4265 base color-id;
4266 description
4267 "Identity of color id base on EVC and CVLAN ";
4268 }
4269 identity cos-id {
4270 description
4271 "Identity of class of service id";
4272 }
4273 identity cos-id-evc {
4274 base cos-id;
4275 description
4276 "Identity of cos id based on EVC";
4277 }
4278 identity cos-id-evc-pcp {
4279 base cos-id;
4280 description
4281 "Identity of cos id based on EVC and PCP";
4282 }
4283 identity cos-id-evc-dscp {
4284 base cos-id;
4285 description
4286 "Identity of cos id based on EVC and DSCP";
4287 }
4289 identity cos-id-ovc-ep {
4290 base cos-id;
4291 description
4292 "Identity of cos id based on OVC EP";
4293 }
4294 identity color-type {
4295 description
4296 "Identity of color types";
4297 }
4298 identity green {
4299 base color-type;
4300 description
4301 "Identity of green type";
4302 }
4303 identity yellow {
4304 base color-type;
4305 description
4306 "Identity of yellow type";
4307 }
4308 identity red {
4309 base color-type;
4310 description
4311 "Identity of red type";
4312 }
4313 identity perf-tier-opt {
4314 description
4315 "Identity of performance tier option.";
4316 }
4317 identity metro {
4318 base perf-tier-opt;
4319 description
4320 "Identity of metro";
4321 }
4322 identity regional {
4323 base perf-tier-opt;
4324 description
4325 "Identity of regional";
4326 }
4327 identity continental {
4328 base perf-tier-opt;
4329 description
4330 "Identity of continental";
4331 }
4332 identity global {
4333 base perf-tier-opt;
4334 description
4335 "Identity of global";
4336 }
4338 identity policing {
4339 description
4340 "Identity of policing type";
4341 }
4342 identity one-rate-two-color {
4343 base policing;
4344 description
4345 "Identity of one-rate, two-color (1R2C)";
4346 }
4347 identity two-rate-three-color {
4348 base policing;
4349 description
4350 "Identity of two-rate, three-color (2R3C)";
4351 }
4352 identity bum-type {
4353 description
4354 "Identity of BUM type";
4355 }
4356 identity broadcast {
4357 base bum-type;
4358 description
4359 "Identity of broadcast";
4360 }
4361 identity unicast {
4362 base bum-type;
4363 description
4364 "Identity of unicast";
4365 }
4366 identity multicast {
4367 base bum-type;
4368 description
4369 "Identity of multicast";
4370 }
4371 identity loop-prevention-type{
4372 description
4373 "Identity of loop prevention";
4374 }
4375 identity shut {
4376 base loop-prevention-type;
4377 description
4378 "Identity of shut protection";
4379 }
4380 identity trap {
4381 base loop-prevention-type;
4382 description
4383 "Identity of trap protection";
4384 }
4385 identity lacp-state {
4386 description
4387 "Identity of LACP state";
4388 }
4389 identity lacp-on {
4390 base lacp-state;
4391 description
4392 "Identity of LCAP on";
4393 }
4394 identity lacp-off {
4395 base lacp-state;
4396 description
4397 "Identity of LACP off";
4398 }
4399 identity lacp-mode {
4400 description
4401 "Identity of LACP mode";
4402 }
4403 identity lacp-passive {
4404 base lacp-mode;
4405 description
4406 "Identity of LACP passive";
4407 }
4408 identity lacp-active {
4409 base lacp-mode;
4410 description
4411 "Identity of LACP active";
4412 }
4413 identity lacp-speed {
4414 description
4415 "Identity of LACP speed";
4416 }
4417 identity lacp-fast {
4418 base lacp-speed;
4419 description
4420 "Identity of LACP fast";
4421 }
4422 identity lacp-slow {
4423 base lacp-speed;
4424 description
4425 "Identity of LACP slow";
4426 }
4427 identity vpn-signaling-type {
4428 description
4429 "Identity of VPN signaling types";
4430 }
4431 identity bgp-l2vpn {
4432 base vpn-signaling-type;
4433 description
4434 "Identity of bgp-l2vpn";
4435 }
4436 identity mp-bgp-evpn {
4437 base vpn-signaling-type;
4438 description
4439 "Identity of mp-bgp-evpn";
4440 }
4441 identity t-ldp-pwe3{
4442 base vpn-signaling-type;
4443 description
4444 "Identity of t-ldp-pwe";
4445 }
4447 identity l2tp-pw {
4448 base vpn-signaling-type;
4449 description
4450 "Identity of l2tp-pw";
4451 }
4453 identity t-ldp-pwe-type{
4454 description
4455 "Identity for t-ldp-pwe-type";
4456 }
4458 identity vpws-type {
4459 base t-ldp-pwe-type;
4460 description
4461 "Identity for VPWS";
4462 }
4464 identity vpls-type{
4465 base t-ldp-pwe-type;
4466 description
4467 "Identity for vpls";
4468 }
4470 identity h-vpls{
4471 base t-ldp-pwe-type;
4472 description
4473 "Identity for h-vpls";
4474 }
4476 identity l2vpn-type {
4477 description
4478 "Layer 2 VPN types";
4479 }
4480 identity kompella {
4481 base l2vpn-type;
4482 description
4483 "Use BGP as signaling protocol.";
4484 }
4485 identity martini {
4486 base l2vpn-type;
4487 description
4488 "Use LDP as signaling protocol";
4489 }
4490 identity both {
4491 base l2vpn-type;
4492 description
4493 "LDP based Signaling and BGP based Auto Discovery";
4494 }
4496 identity evpn-type {
4497 description
4498 "Ethernet VPN types";
4499 }
4500 identity pbb {
4501 base evpn-type;
4502 description
4503 " Provider Backbone Bridging-EVPN";
4504 }
4506 identity management {
4507 description
4508 "Base identity for site management scheme.";
4509 }
4510 identity co-managed {
4511 base management;
4512 description
4513 "Base identity for co-managed site.";
4514 }
4515 identity customer-managed {
4516 base management;
4517 description
4518 "Base identity for customer managed site.";
4519 }
4520 identity provider-managed {
4521 base management;
4522 description
4523 "Base identity for provider managed site.";
4524 }
4525 identity address-family {
4526 description
4527 "Base identity for an address family.";
4528 }
4529 identity ipv4 {
4530 base address-family;
4531 description
4532 "Identity for IPv4 address family.";
4533 }
4534 identity ipv6 {
4535 base address-family;
4536 description
4537 "Identity for IPv6 address family.";
4538 }
4539 identity vpn-topology {
4540 description
4541 "Base identity for VPN topology.";
4542 }
4543 identity any-to-any {
4544 base vpn-topology;
4545 description
4546 "Identity for any to any VPN topology.";
4547 }
4548 identity hub-spoke {
4549 base vpn-topology;
4550 description
4551 "Identity for Hub'n'Spoke VPN topology.";
4552 }
4553 identity hub-spoke-disjoint {
4554 base vpn-topology;
4555 description
4556 "Identity for Hub'n'Spoke VPN topology
4557 where Hubs cannot talk between each other.";
4558 }
4559 identity site-role {
4560 description
4561 "Base identity for site type.";
4562 }
4563 identity any-to-any-role {
4564 base site-role;
4565 description
4566 "Site in an any to any IPVPN.";
4567 }
4568 identity spoke-role {
4569 base site-role;
4570 description
4572 "Spoke Site in a Hub & Spoke IPVPN.";
4573 }
4574 identity hub-role {
4575 base site-role;
4576 description
4577 "Hub Site in a Hub & Spoke IPVPN.";
4578 }
4579 identity pm-type {
4580 description
4581 "Performance monitor type";
4582 }
4583 identity loss {
4584 base pm-type;
4585 description
4586 "Loss measurement";
4587 }
4588 identity delay {
4589 base pm-type;
4590 description
4591 "Delay measurement";
4592 }
4593 identity fault-alarm-defect-type {
4594 description
4595 "Indicating the alarm priority defect";
4596 }
4597 identity remote-rdi {
4598 base fault-alarm-defect-type;
4599 description
4600 "Indicates the aggregate health of the remote MEPs.";
4601 }
4602 identity remote-mac-error {
4603 base fault-alarm-defect-type;
4604 description
4605 "Indicates that one or more of the remote MEPs is
4606 reporting a failure in its Port Status TLV or
4607 Interface Status TLV.";
4608 }
4609 identity remote-invalid-ccm {
4610 base fault-alarm-defect-type;
4611 description
4612 "Indicates that at least one of the Remote MEP
4613 state machines is not receiving valid CCMs
4614 from its remote MEP.";
4615 }
4616 identity invalid-ccm {
4617 base fault-alarm-defect-type;
4618 description
4619 "Indicates that one or more invalid CCMs has been
4620 received and that 3.5 times that CCMs transmission
4621 interval has not yet expired.";
4622 }
4623 identity cross-connect-ccm {
4624 base fault-alarm-defect-type;
4625 description
4626 "Indicates that one or more cross connect CCMs has been
4627 received and that 3.5 times of at least one of those
4628 CCMs transmission interval has not yet expired.";
4629 }
4630 identity data-svc-frame-delivery {
4631 description
4632 "Delivery types";
4633 }
4634 identity discard {
4635 base data-svc-frame-delivery;
4636 description
4637 "Service Frames are discarded.";
4638 }
4639 identity unconditional {
4640 base data-svc-frame-delivery;
4641 description
4642 "Service Frames are unconditionally";
4643 }
4644 identity conditional {
4645 base data-svc-frame-delivery;
4646 description
4647 "Service Frame are conditionally
4648 delivered to the destination UNI.";
4649 }
4650 identity evc-type {
4651 description
4652 "Service topology Type";
4653 }
4654 identity point-to-point {
4655 base evc-type;
4656 description
4657 "Point to Point.";
4658 }
4659 identity multipoint-to-multipoint {
4660 base evc-type;
4661 description
4662 "Multipoint to Multipoint.";
4663 }
4664 identity rooted-multipoint {
4665 base evc-type;
4666 description
4667 "Rooted Multipoint.";
4668 }
4670 identity placement-diversity {
4671 description
4672 "Base identity for site placement
4673 constraints";
4674 }
4675 identity bearer-diverse {
4676 base placement-diversity;
4677 description
4678 "Identity for bearer diversity.
4679 The bearers should not use common elements.";
4680 }
4681 identity pe-diverse {
4682 base placement-diversity;
4683 description
4684 "Identity for PE diversity";
4685 }
4686 identity pop-diverse {
4687 base placement-diversity;
4688 description
4689 "Identity for POP diversity";
4690 }
4691 identity linecard-diverse {
4692 base placement-diversity;
4693 description
4694 "Identity for linecard diversity";
4695 }
4696 identity same-pe {
4697 base placement-diversity;
4698 description
4699 "Identity for having sites connected
4700 on the same PE";
4701 }
4702 identity same-bearer {
4703 base placement-diversity;
4704 description
4705 "Identity for having sites connected
4706 using the same bearer";
4707 }
4708 identity l2-access-type {
4709 description
4710 "This identify the access type
4711 of the vpn acccess interface";
4712 }
4713 identity untag {
4714 base l2-access-type;
4715 description
4716 "Untag";
4717 }
4718 identity port {
4719 base l2-access-type;
4720 description
4721 "Port";
4722 }
4723 identity dot1q {
4724 base l2-access-type;
4725 description
4726 "Qot1q";
4727 }
4728 identity qinq {
4729 base l2-access-type;
4730 description
4731 "QinQ";
4732 }
4733 identity sub-interface {
4734 base l2-access-type;
4735 description
4736 "Create a default sub-interface and keep vlan";
4737 }
4738 identity vxlan {
4739 base l2-access-type;
4740 description
4741 "Vxlan access into the vpn";
4742 }
4743 identity mac-learning-mode {
4744 description
4745 "MAC learning mode";
4746 }
4747 identity data-plane {
4748 base mac-learning-mode;
4749 description
4750 "User MAC addresses are learned through ARP broadcast.";
4751 }
4752 identity control-plane {
4753 base mac-learning-mode;
4754 description
4755 "User MAC addresses are advertised through EVPN-BGP";
4756 }
4758 /* Groupings */
4759 grouping vpn-service-cloud-access {
4760 container cloud-accesses {
4761 if-feature cloud-access;
4762 list cloud-access {
4763 key cloud-identifier;
4764 leaf cloud-identifier {
4765 type string;
4766 description
4767 "Identification of cloud service. Local
4768 admin meaning.";
4769 }
4770 choice list-flavor {
4771 case permit-any {
4772 leaf permit-any {
4773 type empty;
4774 description
4775 "Allow all sites.";
4776 }
4777 }
4778 case deny-any-except {
4779 leaf-list permit-site {
4780 type leafref {
4781 path "/l2vpn-svc/sites/site/site-id";
4782 }
4783 description
4784 "Site ID to be authorized.";
4785 }
4786 }
4787 case permit-any-except {
4788 leaf-list deny-site {
4789 type leafref {
4790 path "/l2vpn-svc/sites/site/site-id";
4791 }
4792 description
4793 "Site ID to be denied.";
4794 }
4795 }
4796 description
4797 "Choice for cloud access policy.";
4798 }
4799 description
4800 "Cloud access configuration.";
4801 }
4802 description
4803 "Container for cloud access configurations";
4804 }
4805 description
4806 "Grouping for vpn cloud definition";
4807 }
4809 grouping site-device {
4810 container device {
4811 list devices {
4812 key "device-id";
4813 leaf device-id {
4814 type string;
4815 description
4816 "Device ID";
4817 }
4818 leaf location {
4819 type leafref {
4820 path "/l2vpn-svc/sites/site/locations/location/location-id";
4821 }
4822 description
4823 "Site name";
4824 }
4825 container management {
4826 leaf address {
4827 type inet:ip-address;
4828 description
4829 "Address";
4830 }
4831 leaf management-transport {
4832 type identityref {
4833 base address-family;
4834 }
4835 description
4836 "Transport protocol used for management.";
4837 }
4838 description
4839 "Container for management";
4840 }
4841 description
4842 "List of devices";
4843 }
4844 description
4845 "Devices configuration";
4846 }
4847 description
4848 "Device parameters for the site.";
4849 }
4851 grouping site-management {
4852 container management {
4853 leaf type {
4854 type identityref {
4855 base management;
4856 }
4857 description
4858 "Management type of the connection.";
4859 }
4860 description
4861 "Container for management";
4862 }
4863 description
4864 "Grouping for management";
4865 }
4867 grouping site-vpn-policy {
4868 container vpn-policies {
4869 list vpn-policy {
4870 key vpn-policy-id;
4871 leaf vpn-policy-id {
4872 type string;
4873 description
4874 "Unique identifier for the VPN policy.";
4875 }
4876 list entries {
4877 key id;
4878 leaf id {
4879 type string;
4880 description
4881 "Unique identifier for the policy entry.";
4882 }
4884 container filter {
4885 choice lan {
4886 case lan-tag {
4887 leaf-list lan-tag {
4888 type string;
4889 description
4890 "List of lan-tags to be matched.";
4891 }
4892 }
4893 description
4894 "Choice for LAN matching type";
4895 }
4896 description
4897 "If used, it permit to split site LANs
4898 among multiple VPNs.
4899 If no filter used, all the LANs will be
4900 part of the same VPNs with the same
4901 role.";
4902 }
4903 container vpn {
4904 leaf vpn-id {
4905 type leafref {
4906 path "/l2vpn-svc/vpn-services/"+
4907 "vpn-svc/vpn-id";
4908 }
4909 mandatory true;
4910 description
4911 "Reference to an IPVPN.";
4912 }
4913 leaf site-role {
4914 type identityref {
4915 base site-role;
4916 }
4917 default any-to-any-role;
4918 description
4919 "Role of the site in the IPVPN.";
4920 }
4921 description
4922 "List of VPNs the LAN is associated to.";
4923 }
4924 description
4925 "List of entries for export policy.";
4926 }
4927 description
4928 "List of VPN policies.";
4929 }
4930 description
4931 "VPN policy.";
4932 }
4933 description
4934 "VPN policy parameters for the site.";
4935 }
4937 grouping umb-frame-delivery {
4938 leaf unicast-frame-delivery {
4939 type identityref {
4940 base data-svc-frame-delivery;
4941 }
4942 description
4943 "Unicast Data Service Frame Delivery Mode
4944 (unconditional[default], conditional, or discard).";
4945 }
4946 leaf multicast-frame-delivery {
4947 type identityref {
4948 base data-svc-frame-delivery;
4949 }
4950 description
4951 "Multicast Data Service Frame Delivery Mode
4952 (unconditional[default], conditional, or discard).";
4953 }
4954 leaf broadcast-frame-delivery {
4955 type identityref {
4956 base data-svc-frame-delivery;
4957 }
4958 description
4959 "Broadcast Data Service Frame Delivery Mode
4960 (unconditional[default], conditional, or discard).";
4961 }
4962 description
4963 "Grouping for unicast, mulitcast, broadcast frame delivery";
4964 }
4966 grouping customer-location-info {
4967 container locations {
4968 list location {
4969 key location-id;
4970 leaf location-id{
4971 type string;
4972 description
4973 "Location ID";
4974 }
4975 leaf address {
4976 type string;
4977 description
4978 "Address (number and street) of the site.";
4979 }
4980 leaf zip-code {
4981 type string;
4982 description
4983 "ZIP code of the site.";
4984 }
4985 leaf state {
4986 type string;
4987 description
4988 "State of the site. This leaf can also be used to
4989 describe a region for country who does not have
4990 states.";
4991 }
4992 leaf city {
4993 type string;
4994 description
4995 "City of the site.";
4996 }
4997 leaf country-code {
4998 type string;
4999 description
5000 "Country of the site.";
5001 }
5002 description
5003 "List for location";
5004 }
5005 description
5006 "Location of the site.";
5007 }
5008 description
5009 "This grouping defines customer location parameters";
5010 }
5012 grouping site-diversity {
5013 container site-diversity {
5014 if-feature site-diversity;
5015 container groups {
5016 list group {
5017 key group-id;
5018 leaf group-id {
5019 type string;
5020 description
5021 "Group-id the site is belonging to";
5022 }
5023 description
5024 "List of group-id";
5025 }
5026 description
5027 "Groups the site is belonging to.
5028 All site network accesses will inherit those group
5029 values.";
5030 }
5031 description
5032 "Diversity constraint type.";
5033 }
5034 description
5035 "This grouping defines site diversity parameters";
5036 }
5038 grouping site-service {
5040 list cvlan-id-to-svc-map {
5041 key "svc-id type";
5042 leaf svc-id {
5043 type leafref {
5044 path "/l2vpn-svc/vpn-services/vpn-svc/vpn-id";
5045 }
5046 description
5047 "EVC ID";
5048 }
5049 leaf type {
5050 type identityref {
5051 base bundling-type;
5052 }
5053 description
5054 "Bundling type";
5055 }
5056 list cvlan-id {
5057 key vid;
5058 leaf vid {
5059 type identityref {
5060 base ianaift:iana-interface-type;
5061 }
5062 description
5063 "CVLAN ID";
5064 }
5065 description
5066 "List of CVLAN-ID to EVC Map configurations";
5067 }
5068 description
5069 "List for cvlan-id to evc map configurations";
5070 }
5072 description
5073 "This grouping defines site service parameters";
5074 }
5076 grouping service-protection {
5077 container service-protection {
5078 leaf protection-model {
5079 type identityref {
5080 base protection-model;
5081 }
5082 description
5083 "Container of protection model configurations";
5084 }
5085 description
5086 "Container of End-to-end Service Protection
5087 configurations";
5088 }
5089 description
5090 "Grouping for service protection";
5091 }
5093 grouping vpn-service-multicast {
5094 container multicast {
5095 if-feature multicast;
5096 leaf enabled {
5097 type boolean;
5098 default false;
5099 description
5100 "Enables multicast.";
5101 }
5102 container customer-tree-flavors {
5103 leaf-list tree-flavor {
5104 type identityref {
5105 base multicast-tree-type;
5106 }
5107 description
5108 "Type of tree to be used.";
5109 }
5110 description
5111 "Type of trees used by customer.";
5112 }
5113 leaf traffic-type {
5114 type identityref {
5115 base tf-type;
5116 }
5117 description
5118 "Traffic Type";
5119 }
5120 leaf group-port-mapping {
5121 type identityref {
5122 base mapping-type;
5123 }
5124 description
5125 "Traffic Type";
5126 }
5127 description
5128 "Multicast global parameters for the VPN service.";
5129 }
5130 description
5131 "Grouping for multicast VPN definition.";
5132 }
5134 grouping vpn-extranet {
5135 container extranet-vpns {
5136 if-feature extranet-vpn;
5137 list extranet-vpn {
5138 key vpn-id;
5140 leaf vpn-id {
5141 type svc-id;
5142 description
5143 "Identifies the target VPN.";
5144 }
5145 leaf local-sites-role {
5146 type identityref {
5147 base site-role;
5149 }
5150 default any-to-any-role;
5151 description
5152 "This describes the role of the
5153 local sites in the target VPN topology.";
5154 }
5155 description
5156 "List of extranet VPNs the local VPN is attached to.";
5157 }
5158 description
5159 "Container for extranet VPN configuration.";
5160 }
5161 description
5162 "Grouping for extranet VPN configuration.
5163 This provides an easy way to interconnect
5164 all sites from two VPNs.";
5165 }
5167 grouping signaling-options-grouping {
5168 list signaling-options {
5169 key "type";
5170 leaf type {
5171 type identityref {
5172 base vpn-signaling-type;
5173 }
5174 description
5175 "VPN signaling types";
5176 }
5177 container bgp-l2vpn {
5178 when "../type = 'bgp-l2vpn'" {
5179 description
5180 "Only applies when vpn signaling type is bgp-l2vpn.";
5181 }
5183 leaf vpn-id {
5184 type leafref{
5185 path "/l2vpn-svc/vpn-services/vpn-svc/vpn-id";
5186 }
5187 description
5188 "Identifies the target VPN";
5189 }
5190 leaf type {
5191 type identityref {
5192 base l2vpn-type;
5193 }
5194 description
5195 "L2VPN types";
5196 }
5197 leaf address-family {
5198 type identityref {
5199 base address-family;
5200 }
5201 description
5202 "Address family used for management.";
5203 }
5204 description
5205 "Container for MP BGP L2VPN";
5206 }
5207 container mp-bgp-evpn {
5208 when "../type = 'mp-bgp-evpn'" {
5209 description
5210 "Only applies when vpn signaling type is mp-bgp-evpn.";
5211 }
5213 leaf vpn-id {
5214 type leafref{
5215 path "/l2vpn-svc/vpn-services/vpn-svc/vpn-id";
5216 }
5217 description
5218 "Identifies the target VPN";
5219 }
5220 leaf type {
5221 type identityref {
5222 base evpn-type;
5223 }
5224 description
5225 "L2VPN types";
5226 }
5227 leaf address-family {
5228 type identityref {
5229 base address-family;
5230 }
5231 description
5232 "Address family used for management.";
5233 }
5234 leaf pwe-encapsulation-type {
5235 type identityref {
5236 base pwe-encapsulation-type;
5237 }
5238 description
5239 "Leaf for PWE Encapsulation Type configurations";
5240 }
5241 container pwe-mtu {
5242 leaf allow-mtu-mismatch {
5243 type boolean;
5244 description
5245 "Allow MTU mismatch";
5246 }
5247 description
5248 "Container of PWE MTU configurations";
5249 }
5250 leaf mac-learning-mode {
5251 type identityref {
5252 base mac-learning-mode;
5253 }
5254 description
5255 "Indicates through which plane MAC addresses are
5256 advertised.";
5257 }
5258 leaf arp-suppress {
5259 type boolean;
5260 default false;
5261 description
5262 "Indicates whether to suppress ARP broadcast.";
5263 }
5264 description
5265 "Container for MP BGP L2VPN";
5266 }
5267 container t-ldp-pwe {
5268 when "../type = 't-ldp-pwe'" {
5269 description
5270 "Only applies when vpn signaling type is bgp-l2vpn.";
5271 }
5273 leaf type {
5274 type identityref {
5275 base t-ldp-pwe-type;
5276 }
5277 description
5278 "T-LDP PWE type";
5279 }
5280 list pe-eg-list {
5281 key "service-ip-addr vc-id";
5282 leaf service-ip-addr {
5283 type inet:ip-address;
5284 description
5285 "Service ip lo address";
5286 }
5287 leaf vc-id {
5288 type string;
5289 description
5290 "VC id";
5291 }
5292 description
5293 "List of PE/EG";
5294 }
5296 leaf control-word {
5297 type boolean;
5298 description
5299 "Control word configurations";
5300 }
5301 container qinq {
5302 when "../type = 'h-vpls'" {
5303 description
5304 "Only applies when t-ldp pwe type is h-vpls.";
5305 }
5306 leaf s-tag {
5307 type uint32;
5308 description
5309 "S-TAG";
5310 }
5311 leaf c-tag {
5312 type uint32;
5313 description
5314 "C-TAG";
5315 }
5316 description
5317 "Container for QinQ";
5318 }
5319 description
5320 "Container of T-LDP PWE configurations";
5321 }
5323 container l2tp-pw{
5324 leaf encapsulation-type {
5325 type identityref {
5326 base encapsulation-type;
5327 }
5328 description
5329 "Encapsulation type";
5330 }
5331 container control-word {
5332 description
5333 "Container for control word";
5334 }
5335 description
5336 "Container for l2tp pw";
5337 }
5339 description
5340 "List of VPN Signaling Option.";
5341 }
5342 description
5343 "Grouping for signaling option";
5344 }
5346 grouping load-balance-grouping {
5347 leaf fat-pw {
5348 type boolean;
5349 description
5350 "Fat label is applied to Pseudowires across MPLS
5351 network";
5352 }
5353 leaf entropy-label {
5354 type boolean;
5355 description
5356 "Entropy label is applied to IP forwarding,
5357 L2VPN or L3VPN across MPLS network";
5358 }
5359 leaf vxlan-source-port {
5360 type string;
5361 description
5362 "Vxlan source port";
5363 }
5364 description
5365 "Grouping for load balance ";
5366 }
5368 grouping operational-requirements-ops {
5369 leaf actual-site-start {
5370 type yang:date-and-time;
5371 config false;
5372 description
5373 "Optional leaf indicating actual date
5374 and time when the service at a particular
5375 site actually started";
5376 }
5377 leaf actual-site-stop {
5378 type yang:date-and-time;
5379 config false;
5380 description
5381 "Optional leaf indicating actual date
5382 and time when the service at a particular
5383 site actually stopped";
5384 }
5385 description
5386 "This grouping defines some operational parameters
5387 parameters";
5388 }
5390 grouping intra-mkt-grouping {
5391 list intra-mkt {
5392 key "metro-mkt-id mkt-name";
5393 leaf metro-mkt-id {
5394 type uint32;
5395 description
5396 "Metro MKT ID";
5397 }
5398 leaf mkt-name {
5399 type string;
5400 description
5401 "MKT Name";
5402 }
5403 leaf ovc-id {
5404 type leafref {
5405 path "/l2vpn-svc/vpn-services/vpn-svc/ovc/ovc-list/ovc-id";
5406 }
5407 description
5408 "OVC id";
5409 }
5410 leaf site-id {
5411 type leafref{
5412 path "/l2vpn-svc/sites/site/site-id";
5413 }
5414 description
5415 "OVC identifier";
5416 }
5417 description
5418 "List of intra-MKT";
5419 }
5420 description
5421 "Grouping for intra-MKT";
5422 }
5424 grouping inter-mkt-service {
5425 leaf inter-mkt-service{
5426 type boolean;
5427 description
5428 "Indicate whether service is inter market service.";
5429 }
5430 description
5431 "Grouping for inter-MKT service";
5432 }
5433 grouping svc-type-grouping {
5434 container evc {
5435 leaf enabled {
5436 type boolean;
5437 description
5438 "Enabled EVC";
5439 }
5440 leaf evc-type {
5441 type identityref {
5442 base evc-type;
5443 }
5444 description
5445 "EVC type";
5446 }
5447 leaf number-of-pe {
5448 type uint32;
5449 config false;
5450 description
5451 "Number of PE";
5452 }
5453 leaf number-of-site {
5454 type uint32;
5455 config false;
5456 description
5457 "Number of Sites";
5458 }
5459 container uni-list {
5460 if-feature uni-list;
5461 list uni-list {
5462 key "uni-site-id";
5463 leaf uni-site-id {
5464 type string;
5465 description
5466 "UNI site Identifier";
5467 }
5468 leaf off-net {
5469 type boolean;
5470 description
5471 "Off net enable";
5472 }
5473 description
5474 "List for UNIs";
5475 }
5476 description
5477 "Container for UNI List";
5478 }
5479 leaf ce-vlan-preservation {
5480 type boolean;
5481 description
5482 "CE vlan preservation";
5483 }
5484 leaf ce-vlan-cos-perservation {
5485 type boolean;
5486 description
5487 "CE vlan COS preservation";
5488 }
5489 leaf service-multiplexing {
5490 type boolean;
5491 description
5492 "Service multiplexing";
5493 }
5494 description
5495 "Container for Ethernet virtual connection.";
5496 }
5497 container ovc {
5498 list ovc-list {
5499 key ovc-id;
5500 leaf ovc-id {
5501 type svc-id;
5502 description
5503 "OVC ID type";
5504 }
5506 leaf off-net {
5507 type boolean;
5508 description
5509 "Off net";
5510 }
5511 leaf svlan-cos-preservation {
5512 type boolean;
5513 description
5514 "SVLAN CoS preservation";
5515 }
5516 leaf svlan-id-preservation {
5517 type boolean;
5518 description
5519 "SVLAN ID preservation";
5520 }
5521 leaf svlan-id-ethernet-tag {
5522 type string;
5523 description
5524 "SVLAN-ID/Ethernet Tag configurations";
5525 }
5526 leaf ovc-endpoint {
5527 type string;
5528 description
5529 "OVC Endpoint";
5530 }
5531 description
5532 "List for OVC";
5533 }
5534 description
5535 "Container for OVC";
5536 }
5537 description
5538 "Grouping of service types.";
5539 }
5541 grouping cfm-802-grouping {
5542 leaf maid {
5543 type string;
5544 description
5545 "MA ID";
5546 }
5547 leaf mep-id {
5548 type uint32;
5549 description
5550 "Local MEP ID";
5551 }
5552 leaf mep-level {
5553 type uint32;
5554 description
5555 "MEP level";
5556 }
5557 leaf mep-up-down {
5558 type enumeration {
5559 enum up {
5560 description
5561 "MEP up";
5562 }
5563 enum down {
5564 description
5565 "MEP down";
5566 }
5567 }
5568 description
5569 "MEP up/down";
5570 }
5571 leaf remote-mep-id {
5572 type uint32;
5573 description
5574 "Remote MEP ID";
5575 }
5576 leaf cos-for-cfm-pdus {
5577 type uint32;
5578 description
5579 "COS for CFM PDUs";
5580 }
5581 leaf ccm-interval {
5582 type uint32;
5583 description
5584 "CCM interval";
5585 }
5586 leaf ccm-holdtime {
5587 type uint32;
5588 description
5589 "CCM hold time";
5590 }
5591 leaf alarm-priority-defect {
5592 type identityref {
5593 base fault-alarm-defect-type;
5594 }
5595 description
5596 "The lowest priority defect that is
5597 allowed to generate a Fault Alarm.
5598 The non-existence of this leaf means
5599 that no defects are to be reported";
5600 }
5601 leaf ccm-p-bits-pri {
5602 type ccm-priority-type;
5603 description
5604 "The priority parameter for CCMs transmitted by the MEP";
5605 }
5606 description
5607 "Grouping for 802.1ag CFM attribute";
5608 }
5610 grouping y-1731 {
5611 list y-1731 {
5612 key maid;
5613 leaf maid {
5614 type string;
5615 description
5616 "MA ID ";
5617 }
5618 leaf mep-id {
5619 type uint32;
5620 description
5621 "Local MEP ID";
5622 }
5623 leaf type {
5624 type identityref {
5625 base pm-type;
5626 }
5627 description
5628 "Performance monitor types";
5629 }
5630 leaf remote-mep-id {
5631 type uint32;
5632 description
5633 "Remote MEP ID";
5634 }
5635 leaf message-period {
5636 type uint32;
5637 description
5638 "Defines the interval between OAM messages. The message
5639 period is expressed in milliseconds";
5640 }
5641 leaf measurement-interval {
5642 type uint32;
5643 description
5644 "Specifies the measurement interval for statistics. The
5645 measurement interval is expressed in seconds";
5646 }
5647 leaf cos {
5648 type uint32;
5649 description
5650 "Class of service";
5651 }
5652 leaf loss-measurement {
5653 type boolean;
5654 description
5655 "Whether enable loss measurement";
5656 }
5657 leaf synthethic-loss-measurement {
5658 type boolean;
5659 description
5660 "Indicate whether enable synthetic loss measurement";
5661 }
5662 container delay-measurement {
5663 leaf enable-dm {
5664 type boolean;
5665 description
5666 "Whether to enable delay measurement";
5667 }
5668 leaf two-way {
5669 type boolean;
5670 description
5671 "Whether delay measurement is two-way (true) of one-
5672 way (false)";
5673 }
5674 description
5675 "Container for delay measurement";
5676 }
5677 leaf frame-size {
5678 type uint32;
5679 description
5680 "Frame size";
5681 }
5682 leaf session-type {
5683 type enumeration {
5684 enum proactive {
5685 description
5686 "Proactive mode";
5687 }
5688 enum on-demand {
5689 description
5690 "On demand mode";
5691 }
5692 }
5693 description
5694 "Session type";
5695 }
5696 description
5697 "List for y-1731.";
5698 }
5699 description
5700 "Grouping for y.1731";
5701 }
5703 grouping enni-site-info-grouping {
5704 container site-info {
5705 leaf site-name {
5706 type string;
5707 description
5708 "Site name";
5709 }
5710 leaf address {
5711 type inet:ip-address;
5712 description
5713 "Address";
5714 }
5715 leaf Edge-Gateway-Device-Info {
5716 type string;
5717 description
5718 "Edge Gateway Device Info ";
5720 }
5721 description
5722 "Container of site info configurations";
5723 }
5724 description
5725 "Grouping for site information";
5726 }
5728 grouping site-security {
5729 container security-filtering {
5730 uses mac-loop-prevention-grouping;
5731 container access-control-list {
5732 list mac {
5733 key "mac-address";
5734 leaf mac-address {
5735 type yang:mac-address;
5736 description
5737 "MAC address";
5738 }
5739 description
5740 "List for MAC";
5741 }
5742 description
5743 "Container for access control";
5744 }
5745 uses mac-addr-limit-grouping;
5746 description
5747 "Security parameters";
5748 }
5749 description
5750 "This grouping defines security parameters for a site";
5751 }
5753 grouping lacp-grouping {
5754 container lacp {
5755 leaf lacp-state {
5756 type boolean;
5757 description
5758 "LACP on/off";
5759 }
5760 leaf lacp-mode {
5761 type boolean;
5762 description
5763 "LACP mode";
5764 }
5765 leaf lacp-speed {
5766 type boolean;
5767 description
5768 "LACP speed";
5769 }
5770 leaf mini-link {
5771 type uint32;
5772 description
5773 "Mini link";
5774 }
5775 leaf system-priority {
5776 type uint16;
5777 description
5778 "Indicates the LACP priority for the system.
5779 The range is from 0 to 65535.
5780 The default is 32768.";
5781 }
5782 container micro-bfd {
5783 if-feature micro-bfd;
5784 leaf micro-bfd-on-off {
5785 type enumeration {
5786 enum on {
5787 description
5788 "Micro-bfd on";
5789 }
5790 enum off {
5791 description
5792 "Micro-bfd off";
5793 }
5794 }
5795 description
5796 "Micro BFD ON/OFF";
5797 }
5798 leaf bfd-interval {
5799 type uint32;
5800 description
5801 "BFD interval";
5802 }
5803 leaf bfd-hold-timer {
5804 type uint32;
5805 description
5806 "BFD hold timer";
5807 }
5808 description
5809 "Container of Micro-BFD configurations";
5810 }
5811 container bfd {
5812 if-feature bfd;
5813 leaf bfd-enabled {
5814 type boolean;
5815 description
5816 "BFD activation";
5817 }
5818 choice holdtime {
5819 case profile {
5820 leaf profile-name {
5821 type string;
5822 description
5823 "Service provider well known profile.";
5824 }
5825 description
5826 "Service provider well known profile.";
5827 }
5828 case fixed {
5829 leaf fixed-value {
5830 type uint32;
5831 units msec;
5832 description
5833 "Expected hold time expressed in msec.";
5834 }
5835 }
5836 description
5837 "Choice for hold time flavor.";
5838 }
5839 description
5840 "Container for BFD.";
5841 }
5842 container member-link-list {
5843 list member-link {
5844 key "name";
5845 leaf name {
5846 type string;
5847 description
5848 "Member link name";
5849 }
5850 leaf port-speed {
5851 type uint32;
5852 description
5853 "Port speed";
5854 }
5855 leaf mode {
5856 type neg-mode;
5857 description
5858 "Negotiation mode";
5859 }
5860 leaf mtu {
5861 type uint32;
5862 description
5863 "MTU";
5865 }
5866 container oam-802.3ah-link {
5867 if-feature oam-3ah;
5868 leaf enable {
5869 type boolean;
5870 description
5871 "Indicate whether support oam 802.3 ah link";
5872 }
5873 description
5874 "Container for oam 802.3 ah link.";
5875 }
5876 description
5877 "Member link";
5878 }
5879 description
5880 "Container of Member link list";
5881 }
5882 leaf flow-control {
5883 type string;
5884 description
5885 "Flow control";
5886 }
5888 leaf encapsulation-type {
5889 type identityref {
5890 base encapsulation-type;
5891 }
5892 description
5893 "Encapsulation type";
5894 }
5895 leaf ethertype {
5896 type identityref {
5897 base eth-type;
5898 }
5899 description
5900 "Ether type";
5901 }
5902 leaf lldp {
5903 type boolean;
5904 description
5905 "LLDP";
5906 }
5907 description
5908 "LACP";
5909 }
5910 description
5911 "Grouping for lacp";
5912 }
5913 grouping phy-interface-grouping {
5914 container phy-interface {
5915 leaf port-number {
5916 type uint32;
5917 description
5918 "Port number";
5919 }
5920 leaf port-speed {
5921 type uint32;
5922 description
5923 "Port speed";
5924 }
5925 leaf mode {
5926 type neg-mode;
5927 description
5928 "Negotiation mode";
5929 }
5931 leaf phy-mtu {
5932 type uint32;
5933 description
5934 "PHY MTU";
5935 }
5936 leaf flow-control {
5937 type string;
5938 description
5939 "Flow control";
5940 }
5941 leaf encapsulation-type {
5942 type identityref {
5943 base encapsulation-type;
5944 }
5945 description
5946 "Encapsulation Type";
5947 }
5948 leaf ethertype {
5949 type identityref{
5950 base eth-type;
5951 }
5952 description
5953 "Ethertype";
5954 }
5955 leaf lldp {
5956 type boolean;
5957 description
5958 "LLDP";
5959 }
5960 container oam-802.3ah-link {
5961 if-feature oam-3ah;
5962 leaf enable {
5963 type boolean;
5964 description
5965 "Indicate whether support oam 802.3 ah link";
5966 }
5967 description
5968 "Container for oam 802.3 ah link.";
5969 }
5970 leaf uni-loop-prevention {
5971 type boolean;
5972 description
5973 "If this leaf set to truth that the port automatically
5974 goes down when a physical loopback is detect.";
5975 }
5976 description
5977 "Container of PHY Interface Attributes configurations";
5978 }
5979 description
5980 "Grouping for phy interface.";
5981 }
5983 grouping lag-interface-grouping {
5984 container lag-interface {
5985 if-feature lag-interface;
5986 list lag-interface {
5987 key "lag-interface-number";
5988 leaf lag-interface-number {
5989 type uint32;
5990 description
5991 "LAG interface number";
5992 }
5993 uses lacp-grouping;
5994 description
5995 "List of LAG interfaces";
5996 }
5997 description
5998 "Container of LAG interface attributes configuration";
5999 }
6000 description
6001 "Grouping for LAG interface";
6002 }
6003 grouping l2-access-grouping {
6004 container dot1q {
6005 when "'../l2-access-type'='dot1q'";
6006 if-feature dot1q;
6007 leaf physical-inf {
6008 type string;
6009 description
6010 "Physical Interface";
6011 }
6012 leaf c-vlan-id {
6013 type uint32;
6014 description
6015 "VLAN identifier";
6016 }
6017 description
6018 "Qot1q";
6019 }
6020 container qinq {
6021 when "'../l2-access-type'='qinq'";
6022 if-feature qinq;
6024 leaf s-vlan-id {
6025 type uint32;
6026 description
6027 "S-VLAN Identifier";
6028 }
6029 leaf c-vlan-id {
6030 type uint32;
6031 description
6032 "C-VLAN Identifier";
6033 }
6034 description
6035 "QinQ";
6036 }
6037 container qinany {
6038 if-feature qinany;
6039 leaf s-vlan-id {
6040 type uint32;
6041 description
6042 "S-Vlan ID";
6043 }
6044 description
6045 "Container for Q in Any";
6046 }
6047 container vxlan {
6048 when "'../l2-access-type'='vxlan'";
6049 if-feature vxlan;
6050 leaf vni-id {
6051 type uint32;
6052 description
6053 "VNI Identifier";
6054 }
6055 list peer-list {
6056 key peer-ip;
6057 leaf peer-ip {
6058 type inet:ip-address;
6059 description
6060 "Peer IP";
6061 }
6062 description
6063 "List for peer IP";
6064 }
6065 description
6066 "QinQ";
6067 }
6068 description
6069 "Grouping for Layer2 access";
6070 }
6072 grouping ethernet-connection-grouping {
6073 container connection {
6074 container encapsulation-type {
6075 leaf encapsulation-type {
6076 type identityref {
6077 base encapsulation-type;
6078 }
6079 description
6080 "Encapsulation Type";
6081 }
6082 leaf eth-type {
6083 type identityref {
6084 base eth-type;
6085 }
6086 description
6087 "Ethernet Type";
6088 }
6089 description
6090 "Container for encapsulation type";
6091 }
6093 leaf esi {
6094 type string;
6095 description
6096 "Ethernet segment id";
6097 }
6098 leaf interface-description {
6099 type string;
6100 description
6101 "Interface description";
6102 }
6103 leaf sub-if-id {
6104 when "'../l2-access-type'='sub-interface'";
6105 type uint32;
6106 description
6107 "Sub interface ID";
6108 }
6109 container vlan {
6110 if-feature vlan;
6111 leaf vlan-id {
6112 type uint32;
6113 description
6114 "VLAN-ID/Ethernet Tag configurations";
6115 }
6116 description
6117 "Abstract container for VLAN";
6118 }
6119 uses l2-access-grouping;
6120 uses phy-interface-grouping;
6121 uses lag-interface-grouping;
6122 uses l2cp-grouping;
6123 description
6124 "Container for bearer";
6125 }
6126 description
6127 "Grouping for bearer.";
6128 }
6130 grouping svc-mtu-grouping {
6131 leaf svc-mtu {
6132 type uint32;
6133 description
6134 "EVC MTU";
6135 }
6136 description
6137 "Grouping for evc mtu";
6138 }
6140 grouping mac-addr-limit-grouping {
6141 container mac-addr-limit {
6142 leaf exceeding-option {
6143 type uint32;
6144 description
6145 "Exceeding option";
6146 }
6147 description
6148 "Container of MAC-Addr limit configurations";
6149 }
6150 description
6151 "Grouping for mac address limit";
6152 }
6153 grouping availability-grouping {
6154 container availability {
6155 leaf access-priority {
6156 type uint32;
6157 description
6158 "Access priority";
6159 }
6160 choice redundancy-mode {
6161 case single-active {
6162 leaf single-active {
6163 type boolean;
6164 description
6165 "Single active";
6166 }
6167 description
6168 "Single active case";
6169 }
6170 case all-active {
6171 leaf all-active {
6172 type boolean;
6173 description
6174 "All active";
6175 }
6176 description
6177 "All active case";
6178 }
6179 description
6180 "Redundancy mode choice";
6181 }
6182 description
6183 "Container of availability optional configurations";
6184 }
6185 description
6186 "Grouping for availability";
6187 }
6189 grouping l2cp-grouping {
6190 container l2cp-control {
6191 if-feature L2CP-control;
6192 leaf stp-rstp-mstp {
6193 type control-mode;
6194 description
6195 "STP/RSTP/MSTP protocol type applicable to all UNIs";
6196 }
6197 leaf pause {
6198 type control-mode;
6199 description
6200 "Pause protocol type applicable to all UNIs";
6202 }
6203 leaf lacp-lamp {
6204 type control-mode;
6205 description
6206 "LACP/LAMP ";
6207 }
6209 leaf link-oam {
6210 type control-mode;
6211 description
6212 "Link OAM";
6213 }
6214 leaf esmc {
6215 type control-mode;
6216 description
6217 "ESMC";
6218 }
6219 leaf l2cp-802.1x {
6220 type control-mode;
6221 description
6222 "802.x";
6223 }
6224 leaf e-lmi {
6225 type control-mode;
6226 description
6227 "E-LMI";
6228 }
6229 leaf lldp {
6230 type boolean;
6231 description
6232 "LLDP protocol type applicable to all UNIs";
6233 }
6234 leaf ptp-peer-delay {
6235 type control-mode;
6236 description
6237 "PTP peer delay";
6238 }
6239 leaf garp-mrp {
6240 type control-mode;
6241 description
6242 "GARP/MRP";
6243 }
6244 leaf provider-bridge-group {
6245 type control-mode;
6246 description
6247 "Provider bridge group reserved MAC address
6248 01-80-C2-00-00-08";
6249 }
6250 leaf provider-bridge-mvrp {
6251 type control-mode;
6252 description
6253 "Provider bridge MVRP reserved MAC address
6254 01-80-C2-00-00-0D";
6255 }
6256 description
6257 "Container of L2CP control configurations";
6258 }
6259 description
6260 "Grouping for l2cp control";
6261 }
6263 grouping B-U-M-grouping {
6264 container broadcast-unknown-unicast-multicast {
6265 leaf multicast-site-type {
6266 type enumeration {
6267 enum receiver-only {
6268 description
6269 "The site only has receivers.";
6270 }
6271 enum source-only {
6272 description
6273 "The site only has sources.";
6274 }
6275 enum source-receiver {
6276 description
6277 "The site has both sources and receivers.";
6278 }
6279 }
6280 default "source-receiver";
6281 description
6282 "Type of multicast site.";
6283 }
6284 list multicast-gp-address-mapping {
6285 key id;
6286 leaf id {
6287 type uint16;
6288 description
6289 "Unique identifier for the mapping.";
6290 }
6291 leaf vlan-id {
6292 type uint32;
6293 description
6294 "the VLAN ID of the Multicast group";
6295 }
6296 leaf mac-gp-address {
6297 type yang:mac-address;
6298 description
6299 "the MAC address of the Multicast group";
6300 }
6301 leaf port-lag-number {
6302 type uint32;
6303 description
6304 "the ports/LAGs belonging to the Multicast group";
6305 }
6306 description
6307 "List of Port to group mappings.";
6308 }
6309 leaf bum-overall-rate {
6310 type uint32;
6311 description
6312 "overall rate for BUM";
6313 }
6314 list bum-rate-per-type {
6315 key "type";
6316 leaf type {
6317 type identityref {
6318 base bum-type;
6319 }
6320 description
6321 "BUM type";
6322 }
6323 leaf rate {
6324 type uint32;
6325 description
6326 "rate for BUM";
6327 }
6328 description
6329 "List of rate per type";
6330 }
6331 description
6332 "Container of broadcast, unknown unicast, and multicast configurations";
6333 }
6334 description
6335 "Grouping for broadcast, unknown unicast, and multicast ";
6336 }
6338 grouping mac-loop-prevention-grouping {
6339 container mac-loop-prevention {
6340 leaf frequency {
6341 type uint32;
6342 description
6343 "Frequency";
6344 }
6345 leaf protection-type {
6346 type identityref {
6347 base loop-prevention-type;
6348 }
6349 description
6350 "Protection type";
6351 }
6352 leaf number-retries {
6353 type uint32;
6354 description
6355 "Number of retries";
6356 }
6357 description
6358 "Container of MAC loop prevention.";
6359 }
6360 description
6361 "Grouping for MAC loop prevention";
6362 }
6364 grouping ethernet-svc-oam-grouping {
6365 container ethernet-service-oam {
6366 leaf md-name {
6367 type string;
6368 description
6369 "Maintenance domain name";
6370 }
6371 leaf md-level {
6372 type uint8;
6373 description
6374 "Maintenance domain level";
6375 }
6377 container cfm-802.1-ag {
6378 list n2-uni-c {
6379 key "maid";
6380 uses cfm-802-grouping;
6381 description
6382 "List of UNI-N to UNI-C";
6383 }
6384 list n2-uni-n {
6385 key "maid";
6386 uses cfm-802-grouping;
6387 description
6388 "List of UNI-N to UNI-N";
6389 }
6390 description
6391 "Container of 802.1ag CFM configurations.";
6392 }
6393 uses y-1731;
6394 description
6395 "Container for Ethernet service OAM.";
6396 }
6397 description
6398 "Grouping for Ethernet service OAM.";
6399 }
6401 grouping fate-sharing-group {
6402 container groups {
6403 leaf fate-sharing-group-size {
6404 type uint16;
6405 description
6406 "Fate sharing group size.";
6407 }
6408 list group {
6409 key group-id;
6410 leaf group-id {
6411 type string;
6412 description
6413 "Group-id the site network access
6414 is belonging to";
6415 }
6416 description
6417 "List of group-id";
6418 }
6419 description
6420 "Groups the fate sharing group member
6421 is belonging to";
6422 }
6423 description
6424 "Grouping for Fate sharing group.";
6425 }
6427 grouping site-group {
6428 container groups {
6429 list group {
6430 key group-id;
6431 leaf group-id {
6432 type string;
6433 description
6434 "Group-id the site is belonging to";
6435 }
6436 description
6437 "List of group-id";
6438 }
6439 description
6440 "Groups the site or site-network-access
6441 is belonging to.";
6442 }
6443 description
6444 "Grouping definition to assign
6445 group-ids to site or site-network-access";
6446 }
6448 grouping access-diversity {
6449 container access-diversity {
6450 if-feature site-diversity;
6451 uses fate-sharing-group;
6452 container constraints {
6453 list constraint {
6454 key constraint-type;
6455 leaf constraint-type {
6456 type identityref {
6457 base placement-diversity;
6458 }
6459 description
6460 "Diversity constraint type.";
6461 }
6462 container target {
6463 choice target-flavor {
6464 case id {
6465 list group {
6466 key group-id;
6467 leaf group-id {
6468 type string;
6469 description
6470 "The constraint will apply
6471 against this particular
6472 group-id";
6473 }
6474 description
6475 "List of groups";
6476 }
6477 }
6478 case all-accesses {
6479 leaf all-other-accesses {
6480 type empty;
6481 description
6482 "The constraint will apply
6483 against all other site network
6484 access of this site";
6485 }
6486 }
6487 case all-groups {
6489 leaf all-other-groups {
6490 type empty;
6491 description
6492 "The constraint will apply
6493 against all other groups the
6494 customer is managing";
6495 }
6496 }
6497 description
6498 "Choice for the group definition";
6499 }
6500 description
6501 "The constraint will apply against
6502 this list of groups";
6503 }
6504 description
6505 "List of constraints";
6506 }
6507 description
6508 "Constraints for placing this site
6509 network access";
6510 }
6511 description
6512 "Diversity parameters.";
6513 }
6514 description
6515 "This grouping defines access diversity
6516 parameters";
6517 }
6519 grouping request-type-profile-grouping {
6520 container request-type-profile {
6521 choice request-type-choice {
6522 case dot1q-case {
6523 container dot1q {
6524 leaf physical-if {
6525 type string;
6526 description
6527 "Physical interface";
6528 }
6529 leaf vlan-id {
6530 type uint16;
6531 description
6532 "VLAN ID";
6533 }
6534 description
6535 "Container for dot1q.";
6536 }
6537 description
6538 "Case for dot1q";
6539 }
6540 case physical-case {
6541 leaf physical-if {
6542 type string;
6543 description
6544 "Physical interface";
6545 }
6546 leaf circuit-id {
6547 type string;
6548 description
6549 "Circuit ID";
6550 }
6551 description
6552 "Physical case";
6553 }
6554 description
6555 "Choice for request type";
6556 }
6557 description
6558 "Container for request type profile.";
6559 }
6560 description
6561 "Grouping for request type profile";
6562 }
6564 grouping site-attachment-bearer {
6565 container bearer {
6566 container requested-type {
6567 if-feature requested-type;
6568 leaf requested-type {
6569 type string;
6570 description
6571 "Type of requested bearer Ethernet, DSL,
6572 Wireless ..Operator specific.";
6573 }
6574 leaf strict {
6575 type boolean;
6576 default false;
6577 description
6578 "Define if the requested-type is a preference
6579 or a strict requirement.";
6580 }
6581 uses request-type-profile-grouping;
6582 description
6583 "Container for requested type.";
6584 }
6585 leaf always-on {
6586 if-feature always-on;
6587 type boolean;
6588 default true;
6589 description
6590 "Request for an always on access type.
6591 This means no Dial access type for
6592 example.";
6593 }
6594 leaf bearer-reference {
6595 if-feature bearer-reference;
6596 type string;
6597 description
6598 "This is an internal reference for the
6599 service provider.";
6600 }
6601 description
6602 "Bearer specific parameters.
6603 To be augmented.";
6604 }
6605 description
6606 "Grouping to define physical properties of
6607 a site attachment.";
6608 }
6610 grouping vpn-attachment-grouping {
6611 container vpn-attachment {
6612 leaf device-id {
6613 type string;
6614 description
6615 "Device ID";
6616 }
6617 container management {
6618 leaf address-family {
6619 type identityref {
6620 base address-family;
6621 }
6622 description
6623 "Address family used for management.";
6624 }
6625 leaf address {
6626 type inet:ip-address;
6627 description
6628 "Management address";
6629 }
6630 description
6631 "Management configuration..";
6632 }
6633 choice attachment-flavor {
6634 case vpn-flavor {
6635 list vpn-flavor {
6636 key vpn-id;
6637 leaf vpn-id {
6638 type leafref {
6639 path "/l2vpn-svc/vpn-services"+
6640 "/vpn-svc/vpn-id";
6641 }
6642 description
6643 "Reference to a VPN.";
6644 }
6645 leaf site-role {
6646 type identityref {
6647 base site-role;
6648 }
6649 default any-to-any-role;
6650 description
6651 "Role of the site in the IPVPN.";
6652 }
6653 description
6654 "List of IPVPNs attached by the Site Network Access";
6655 }
6656 }
6657 case vpn-policy-id {
6658 leaf vpn-policy-id {
6659 type leafref {
6660 path "/l2vpn-svc/sites/site/vpn-policies/vpn-policy/vpn-policy-id";
6661 }
6662 description
6663 "Reference to a vpn policy";
6664 }
6665 }
6666 mandatory true;
6667 description
6668 "Choice for VPN attachment flavor.";
6669 }
6670 description
6671 "Defines VPN attachment of a site.";
6672 }
6673 description
6674 "Grouping for access attachment";
6675 }
6677 grouping site-service-basic {
6678 container svc-input-bandwidth {
6679 if-feature input-bw;
6680 list input-bandwidth {
6681 key "type";
6682 leaf type {
6683 type identityref {
6684 base bw-type;
6685 }
6686 description
6687 "Bandwidth Type";
6688 }
6689 leaf cos-id {
6690 type uint8;
6691 description
6692 "CoS id";
6693 }
6694 leaf vpn-id {
6695 type svc-id;
6696 description
6697 "EVC ID";
6698 }
6699 leaf CIR {
6700 type uint64;
6701 description
6702 "Committed Information Rate";
6703 }
6704 leaf CBS {
6705 type uint64;
6706 description
6707 "Committed Burst Size";
6708 }
6709 leaf EIR {
6710 type uint64;
6711 description
6712 "Excess Information Rate";
6713 }
6714 leaf EBS {
6715 type uint64;
6716 description
6717 "Excess Burst Size";
6718 }
6719 leaf CM {
6720 type uint8;
6721 description
6722 "Color Mode";
6723 }
6724 description
6725 "List for input bandwidth";
6726 }
6727 description
6728 "From the PE perspective, the service input
6729 bandwidth of the connection.";
6730 }
6731 container svc-output-bandwidth {
6732 if-feature output-bw;
6733 list output-bandwidth {
6734 key "type";
6735 leaf type {
6736 type identityref {
6737 base bw-type;
6738 }
6739 description
6740 "Bandwidth Type";
6741 }
6742 leaf cos-id {
6743 type uint8;
6744 description
6745 "CoS id";
6746 }
6747 leaf vpn-id {
6748 type svc-id;
6749 description
6750 "EVC ID";
6751 }
6752 leaf CIR {
6753 type uint64;
6754 description
6755 "Committed Information Rate";
6756 }
6757 leaf CBS {
6758 type uint64;
6759 description
6760 "Committed Burst Size";
6761 }
6762 leaf EIR {
6763 type uint64;
6764 description
6765 "Excess Information Rate";
6766 }
6767 leaf EBS {
6768 type uint64;
6769 description
6770 "Excess Burst Size";
6771 }
6772 leaf CM {
6773 type uint8;
6774 description
6775 "Color Mode";
6776 }
6777 description
6778 "List for output bandwidth";
6780 }
6781 description
6782 "From the PE perspective, the service output
6783 bandwidth of the connection.";
6784 }
6785 description
6786 "Grouping for site service";
6787 }
6789 grouping flow-definition {
6790 container match-flow {
6791 leaf dscp {
6792 type inet:dscp;
6793 description
6794 "DSCP value.";
6795 }
6796 leaf dot1p {
6797 type uint8 {
6798 range "0 .. 7";
6799 }
6800 description
6801 "802.1p matching.";
6802 }
6803 leaf pcp {
6804 type uint8;
6805 description
6806 "PCP value";
6807 }
6808 leaf src-mac {
6809 type yang:mac-address;
6810 description
6811 "Source MAC";
6812 }
6813 leaf dst-mac {
6814 type yang:mac-address;
6815 description
6816 "Destination MAC";
6817 }
6818 container composite-id {
6819 leaf endpoint-id {
6820 type string;
6821 description
6822 "Endpoint ID";
6823 }
6824 leaf cos-label {
6825 type identityref {
6826 base cos-id;
6827 }
6828 description
6829 "COS label";
6830 }
6831 leaf pcp {
6832 type uint8;
6833 description
6834 "PCP value";
6835 }
6836 leaf dscp {
6837 type inet:dscp;
6838 description
6839 "DSCP value.";
6840 }
6841 description
6842 "Container for cos color id";
6843 }
6844 leaf color-type {
6845 type identityref {
6846 base color-type;
6847 }
6848 description
6849 "Color Types";
6850 }
6851 leaf-list target-sites {
6852 type svc-id;
6853 description
6854 "Identify a site as traffic destination.";
6855 }
6856 description
6857 "Describe flow matching criterions.";
6858 }
6859 description
6860 "Flow definition based on criteria.";
6861 }
6863 grouping site-service-qos-profile {
6864 container qos {
6865 if-feature qos;
6866 container qos-classification-policy {
6867 list rule {
6868 key id;
6869 ordered-by user;
6870 leaf id {
6871 type uint16;
6872 description
6873 "ID of the rule.";
6874 }
6875 choice match-type {
6876 case match-flow {
6877 uses flow-definition;
6879 }
6880 case match-phy-port {
6881 leaf match-phy-port {
6882 type uint16;
6883 description
6884 "Defines the physical port
6885 to match.";
6886 }
6887 }
6888 description
6889 "Choice for classification";
6890 }
6891 leaf target-class-id {
6892 type string;
6893 description
6894 "Identification of the class of service.
6895 This identifier is internal to the
6896 administration.";
6897 }
6898 description
6899 "List of marking rules.";
6900 }
6901 description
6902 "Need to express marking rules ...";
6903 }
6904 container qos-profile {
6905 choice qos-profile {
6906 description
6907 "Choice for QoS profile.
6908 Can be standard profile or custom.";
6909 case standard {
6910 leaf ingress-profile {
6911 type string;
6912 description
6913 "Ingress QoS Profile to be used";
6914 }
6915 leaf egress-profile {
6916 type string;
6917 description
6918 "Egress QoS Profile to be used";
6919 }
6920 }
6921 case custom {
6922 container classes {
6923 if-feature qos-custom;
6924 list class {
6925 key class-id;
6926 leaf class-id {
6927 type string;
6928 description
6929 "Identification of the class of
6930 service. This identifier is internal
6931 to the administration.";
6932 }
6933 leaf direction {
6934 type direction-type;
6935 description
6936 "Direction type";
6937 }
6938 leaf policing {
6939 type identityref {
6940 base policing;
6941 }
6942 description
6943 "The policing can be either one-rate,
6944 two-color (1R2C) or two-rate, three-color
6945 (2R3C)";
6946 }
6947 leaf byte-offset {
6948 type uint16;
6949 description
6950 "For not including extra VLAN tags in the QoS
6951 calculation";
6952 }
6954 leaf rate-limit {
6955 type uint8;
6956 units percent;
6957 description
6958 "To be used if class must be rate limited.
6959 Expressed as percentage of the svc-bw.";
6960 }
6961 leaf discard-percentage {
6962 type uint8;
6964 default 100;
6965 description
6966 "The value of the discard-percentage,
6967 Expressed as pecentage of the svc-bw ";
6968 }
6969 container frame-delay {
6970 choice flavor {
6971 case lowest {
6972 leaf use-low-del {
6973 type empty;
6974 description
6975 "The traffic class should use
6976 the lowest delay path";
6977 }
6978 }
6979 case boundary {
6980 leaf delay-bound {
6981 type uint16;
6982 units msec;
6983 description
6984 "The traffic class should use
6985 a path with a defined maximum
6986 delay.";
6987 }
6988 }
6989 description
6990 "Delay constraint on the traffic
6991 class";
6992 }
6993 description
6994 "Delay constraint on the traffic
6995 class";
6996 }
6997 container frame-jitter {
6998 choice flavor {
6999 case lowest {
7000 leaf use-low-jit {
7001 type empty;
7002 description
7003 "The traffic class should use
7004 the lowest jitter path";
7005 }
7006 }
7007 case boundary {
7008 leaf delay-bound {
7009 type uint32;
7010 units usec;
7011 description
7012 "The traffic class should use
7013 a path with a defined maximum
7014 jitter.";
7015 }
7016 }
7017 description
7019 "Jitter constraint on the traffic
7020 class";
7021 }
7022 description
7023 "Jitter constraint on the traffic
7024 class";
7025 }
7026 container frame-loss {
7027 leaf fr-loss-rate {
7028 type decimal64 {
7029 fraction-digits 2;
7030 }
7031 description
7032 "Loss constraint on the traffic class";
7033 }
7034 description
7035 "Container for frame loss";
7036 }
7037 container bandwidth {
7038 leaf guaranteed-bw-percent {
7039 type uint8;
7040 units percent;
7041 description
7042 "To be used to define the guaranteed bandwidth
7043 as a percentage of the available service
7044 bandwidth.";
7045 }
7046 leaf end-to-end {
7047 type empty;
7048 description
7049 "Used if the bandwidth reservation
7050 must be done on the MPLS network too.";
7051 }
7052 description
7053 "Bandwidth constraint on the traffic class.";
7054 }
7055 description
7056 "List of class of services.";
7057 }
7058 description
7059 "Container for list of class of services.";
7060 }
7061 }
7062 }
7063 description
7064 "Qos profile configuration.";
7065 }
7066 description
7067 "QoS configuration.";
7068 }
7069 description
7070 "This grouping defines QoS parameters
7071 for a site";
7072 }
7073 grouping services-grouping {
7074 container service {
7075 uses site-service-qos-profile;
7076 description
7077 "Container for service";
7078 }
7079 description
7080 "Grouping for Services";
7081 }
7083 grouping service-grouping {
7084 container service {
7085 uses site-service-basic;
7087 uses site-service-qos-profile;
7088 description
7089 "Container for service";
7090 }
7091 description
7092 "Grouping for service.";
7093 }
7095 /* MAIN L2VPN SERVICE */
7097 container l2vpn-svc {
7099 container vpn-services {
7100 list vpn-svc {
7101 key "vpn-id";
7102 leaf vpn-id {
7103 type svc-id;
7104 description
7105 "Defining a service id.";
7106 }
7107 leaf vpn-type {
7108 type identityref {
7109 base service-type;
7110 }
7111 description
7112 "Service type";
7113 }
7114 leaf customer-account-number {
7115 type uint32;
7116 description
7117 "Customer account number";
7118 }
7119 leaf customer-name {
7120 type string;
7121 description
7122 "Customer name";
7123 }
7124 uses svc-type-grouping;
7125 leaf svc-topo {
7126 type identityref {
7127 base vpn-topology;
7128 }
7129 description
7130 "Defining service topology, such as
7131 any-to-any,hub-spoke, etc.";
7132 }
7133 uses vpn-service-cloud-access; // need fixed??
7135 container metro-network-id {
7136 uses inter-mkt-service;
7137 uses intra-mkt-grouping;
7138 description
7139 "Container of Metro-Network ID configurations";
7140 }
7141 container global-l2cp-control {
7142 if-feature L2CP-control;
7143 leaf stp-rstp-mstp {
7144 type control-mode;
7145 description
7146 "STP/RSTP/MSTP protocol type applicable to all UNIs";
7147 }
7148 leaf pause {
7149 type control-mode;
7150 description
7151 "Pause protocol type applicable to all UNIs ";
7152 }
7153 leaf lldp {
7154 type boolean;
7155 description
7156 "LLDP protocol type applicable to all UNIs ";
7157 }
7158 description
7159 "Container of L2CP control global configurations";
7160 }
7161 container load-balance-options {
7162 uses load-balance-grouping;
7163 description
7164 "Container for load balance options";
7165 }
7166 leaf service-level-mac-limit {
7167 type string;
7168 description
7169 "Service-level MAC-limit (E-LAN only)";
7170 }
7171 uses service-protection;
7172 uses site-service;
7173 uses vpn-service-multicast;
7174 uses vpn-extranet;
7175 description
7176 "List of vpn-svc";
7177 }
7178 description
7179 "Container for VPN services.";
7180 }
7182 /* SITE */
7183 container sites {
7184 list site {
7185 key "site-id site-type";
7186 leaf site-id {
7187 type string;
7188 description
7189 "Site id";
7190 }
7191 leaf site-type {
7192 type identityref {
7193 base site-type;
7194 }
7195 description
7196 "Site type";
7197 }
7198 uses site-device;
7199 uses customer-location-info;
7200 uses site-management;
7201 uses site-diversity;
7202 uses site-vpn-policy ;
7203 container signaling-options {
7204 if-feature signaling-options;
7205 uses signaling-options-grouping;
7206 description
7207 "Container for signaling option";
7208 }
7209 container load-balance-options {
7210 uses load-balance-grouping;
7211 description
7212 "Container for load balance options";
7213 }
7214 uses services-grouping;
7215 uses B-U-M-grouping;
7216 uses site-security;
7217 uses operational-requirements-ops;
7218 container site-network-accesses {
7219 list site-network-accesse {
7220 key "network-access-id";
7221 leaf network-access-id {
7222 type string;
7223 description
7224 "Identifier of network access";
7225 }
7226 leaf remote-carrier-name {
7227 when "'../site-type' = 'enni'" {
7228 description
7229 "Site type = enni";
7230 }
7231 type string;
7232 description
7233 "Remote carrier name";
7234 }
7235 uses access-diversity;
7236 uses site-attachment-bearer;
7237 uses ethernet-connection-grouping;
7238 uses svc-mtu-grouping;
7239 uses availability-grouping;
7240 uses vpn-attachment-grouping;
7241 uses service-grouping;
7242 uses B-U-M-grouping;
7243 uses ethernet-svc-oam-grouping;
7244 uses site-security;
7245 description
7246 "List of ports";
7247 }
7248 description
7249 "Container of port configurations";
7250 }
7251 description
7252 "List of sites";
7253 }
7254 description
7255 "Container of site configurations";
7256 }
7258 description
7259 "Container for L2VPN service";
7260 }
7261 }
7263
7265 9. Security Considerations
7267 The YANG modules defined in this document MAY be accessed via the
7268 RESTCONF protocol [RFC8040] or NETCONF protocol ([RFC6241]). The
7269 lowest RESTCONF or NETCONF layer requires that the transport-layer
7270 protocol provides both data integrity and confidentiality, see
7271 Section 2 in [RFC8040] and [RFC6241]. The client MUST carefully
7272 examine the certificate presented by the server to determine if it
7273 meets the client's expectations, and the server MUST authenticate
7274 client access to any protected resource. The client identity derived
7275 from the authentication mechanism used is subject to the NETCONF
7276 Access Control Module (NACM) ([RFC6536]). Other protocols to access
7277 this YANG module are also required to support the similar mechanism.
7279 The data nodes defined in the "ietf-l2vpn-svc" YANG module MUST be
7280 carefully created/read/updated/deleted. The entries in the lists
7281 below include customer proprietary or confidential information,
7282 therefore only authorized clients MUST access the information and the
7283 other clients MUST NOT be able to access to the information.
7285 o /l2vpn-svc/customer-info/customer-info
7287 o /l2vpn-svc/vpn-services/vpn-svc
7289 o /l2vpn-svc/sites/site
7291 10. Acknowledgements
7293 Thanks to Qin Wu and Adrian Farrel for facilitating work on the
7294 initial revisions of this document. Thanks to Zonghe Huang, Wei Deng
7295 and Xiaoling Song to help review this draft.
7297 This document has drawn on the work of the L3SM Working Group
7298 expressed in [RFC8049].
7300 11. IANA Considerations
7302 IANA is requested to assign a new URI from the IETF XML registry
7303 ([RFC3688]). The following URI is suggested:
7305 URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc
7306 Registrant Contact: L2SM WG
7307 XML: N/A, the requested URI is an XML namespace
7309 This document also requests a new YANG module name in the YANG Module
7310 Names registry ([RFC6020]) with the following suggestion:
7312 name: ietf-l2vpn-svc
7313 namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc
7314 prefix: l2vpn-svc
7315 reference: RFC XXXX
7317 12. References
7319 12.1. Normative References
7321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
7322 Requirement Levels", BCP 14, RFC 2119,
7323 DOI 10.17487/RFC2119, March 1997,
7324 .
7326 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
7327 DOI 10.17487/RFC3688, January 2004,
7328 .
7330 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
7331 "Encapsulation Methods for Transport of Ethernet over MPLS
7332 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
7333 .
7335 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
7336 LAN Service (VPLS) Using BGP for Auto-Discovery and
7337 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
7338 .
7340 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
7341 LAN Service (VPLS) Using Label Distribution Protocol (LDP)
7342 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
7343 .
7345 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
7346 the Network Configuration Protocol (NETCONF)", RFC 6020,
7347 DOI 10.17487/RFC6020, October 2010,
7348 .
7350 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
7351 Aissaoui, "Segmented Pseudowire", RFC 6073,
7352 DOI 10.17487/RFC6073, January 2011,
7353 .
7355 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo,
7356 "Provisioning, Auto-Discovery, and Signaling in Layer 2
7357 Virtual Private Networks (L2VPNs)", RFC 6074,
7358 DOI 10.17487/RFC6074, January 2011,
7359 .
7361 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
7362 and A. Bierman, Ed., "Network Configuration Protocol
7363 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
7364 .
7366 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
7367 Protocol (NETCONF) Access Control Model", RFC 6536,
7368 DOI 10.17487/RFC6536, March 2012,
7369 .
7371 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
7372 RFC 6991, DOI 10.17487/RFC6991, July 2013,
7373 .
7375 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module",
7376 RFC 7224, DOI 10.17487/RFC7224, May 2014,
7377 .
7379 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
7380 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
7381 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
7382 2015, .
7384 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
7385 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
7386 .
7388 [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data
7389 Model for L3VPN Service Delivery", RFC 8049,
7390 DOI 10.17487/RFC8049, February 2017,
7391 .
7393 12.2. Informative References
7395 [I-D.ietf-bess-evpn-yang]
7396 Brissette, P., Sajassi, A., Shah, H., Li, Z.,
7397 Tiruveedhula, K., Hussain, I., and J. Rabadan, "Yang Data
7398 Model for EVPN", draft-ietf-bess-evpn-yang-02 (work in
7399 progress), March 2017.
7401 [I-D.ietf-bess-l2vpn-yang]
7402 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B.,
7403 and K. Tiruveedhula, "YANG Data Model for MPLS-based
7404 L2VPN", draft-ietf-bess-l2vpn-yang-06 (work in progress),
7405 June 2017.
7407 [I-D.ietf-opsawg-service-model-explained]
7408 Wu, Q., LIU, W., and A. Farrel, "Service Models
7409 Explained", draft-ietf-opsawg-service-model-explained-01
7410 (work in progress), June 2017.
7412 [IEEE-802-1ag]
7413 IEEE, "802.1ag - Connectivity Fault Management", December
7414 2007.
7416 [ITU-T-Y-1731]
7417 ITU-T, "Recommendation Y.1731 - OAM functions and
7418 mechanisms for Ethernet based networks", February 2008.
7420 [MEF-23-2]
7421 MEF Forum, "Implementation Agreement MEF 23.2 : Carrier
7422 Ethernet Class of Service - Phase 3", August 2016.
7424 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
7425 Virtual Private Networks Using BGP for Auto-Discovery and
7426 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012,
7427 .
7429 Appendix A. Changes Log
7431 Changes in v-(01) include:
7433 o Reference Update.
7435 o Fix figure in section 3.3 and section 3.4
7437 o Consider VPWS, VPLS, EVPN as basic service and view EVC related
7438 service as additional service.
7440 o Model structure change, move two customer information related
7441 parameter into VPN Services container, remove 'customer-info
7442 'container
7444 o Redefine vpn-type to cover VPWS, VPLS, EVPN service;
7446 o Consolidate EVC and OVC container, make them optional since for
7447 some L2VPN service such as EVPN sevice, OVC, EVC are not needed.
7449 o Add service and security filter under sites container and change
7450 "ports" into "site-network-accesses" to get consistent with L3SM
7451 and also make it generalized.
7453 o Fixed usage examples in the l2sm model draft.
7455 Changes in v-(02) include:
7457 o Fix figure 3 and figure 4 in section 3.4 to apply IEEE802.3 on the
7458 segment between C and CE and apply IEEE802.1Q on the segment
7459 between CE and PE.
7461 o Update Signaling Option section and add L2TP support and classify
7462 the signaling option type into BGP-L2VPN, BGP-EVPN, LDP-PWE, L2TP-
7463 PW.
7465 o Add Multicast Support in section 5.2.13, section 5.10.3 and move
7466 the text in BUM Storm Control section into section 5.10.3.
7468 o Add new section 5.3.1, section 5.4, section 5.5, section 5.6,
7469 section 5.7, section 5.8, section 5.11to explain the usage of
7470 constraint parameters and service placement related parameters.
7472 o Add new section 5.1 and 5.14 to allow augmentation and external ID
7473 References.
7475 o Add new section to discuss inter-AS support and inter-provider
7476 support with NNI and EVC, OVC.
7478 o Update Service Section 5.10 and define four type for svc-input-
7479 bandwidth and svc-output-bandwidth and add guaranteed-bw-percent
7480 parameter and related description.
7482 o Add extranet VPN support.
7484 o Remove duplicated parameters from cloud access.
7486 o Move L2CP control plane protocol parameters under connection.
7488 o Update section 5.3.3.2 to address loop avoidance issue and divide
7489 section 5.3.3.2 into Physical interface section, LAG interface
7490 section and Addressing Section.
7492 o Reference Update.
7494 Appendix B. Open Issues
7496 o Do we need to support L2VPN Interworking with ATMoMPLS,PPPoMPLS,
7497 FroMPLS?
7499 o Need to understand relationship between member link name under LAG-
7500 interface and network-access-id.
7502 o Need to Revisit Signaling Option to see how it is applied.
7504 Authors' Addresses
7506 Bin Wen
7507 Comcast
7509 Email: bin_wen@comcast.com
7511 Giuseppe Fioccola (editor)
7512 Telecom Italia
7514 Email: giuseppe.fioccola@telecomitalia.it
7516 Chongfeng Xie
7517 China Telecom
7519 Email: xiechf@ctbri.com.cn
7521 Luay Jalil
7522 Verizon
7524 Email: luay.jalil@verizon.com