idnits 2.17.1
draft-ietf-l2sm-l2vpn-service-model-06.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 39 instances of too long lines in the document, the longest
one being 31 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 508 has weird spacing: '...--rw id str...'
== Line 510 has weird spacing: '...--rw id str...'
== Line 512 has weird spacing: '...--rw id str...'
== Line 514 has weird spacing: '...--rw id str...'
== Line 542 has weird spacing: '...mapping ide...'
== (20 more instances...)
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords -- however, there's a paragraph with
a matching beginning. Boilerplate error?
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document date (February 8, 2018) is 2269 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: 'VPN2' is mentioned on line 1944, but not defined
== Missing Reference: 'VPN3' is mentioned on line 1953, but not defined
== Unused Reference: 'RFC4448' is defined on line 7241, but no explicit
reference was found in the text
== Unused Reference: 'RFC4762' is defined on line 7256, but no explicit
reference was found in the text
== Unused Reference: 'RFC6991' is defined on line 7296, but no explicit
reference was found in the text
== Unused Reference: 'RFC7224' is defined on line 7300, but no explicit
reference was found in the text
== Unused Reference: 'MEF-23-2' is defined on line 7354, but no explicit
reference was found in the text
** Downref: Normative reference to an Informational RFC: RFC 4664
** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341)
** Downref: Normative reference to an Informational RFC: RFC 7348
== Outdated reference: A later version (-07) exists of
draft-ietf-bess-evpn-yang-03
== Outdated reference: A later version (-10) exists of
draft-ietf-bess-l2vpn-yang-07
Summary: 5 errors (**), 0 flaws (~~), 18 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: August 12, 2018 Telecom Italia
6 C. Xie
7 China Telecom
8 L. Jalil
9 Verizon
10 February 8, 2018
12 A YANG Data Model for L2VPN Service Delivery
13 draft-ietf-l2sm-l2vpn-service-model-06
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 Status of This Memo
37 This Internet-Draft is submitted in full conformance with the
38 provisions of BCP 78 and BCP 79.
40 Internet-Drafts are working documents of the Internet Engineering
41 Task Force (IETF). Note that other groups may also distribute
42 working documents as Internet-Drafts. The list of current Internet-
43 Drafts is at https://datatracker.ietf.org/drafts/current/.
45 Internet-Drafts are draft documents valid for a maximum of six months
46 and may be updated, replaced, or obsoleted by other documents at any
47 time. It is inappropriate to use Internet-Drafts as reference
48 material or to cite them other than as "work in progress."
49 This Internet-Draft will expire on August 12, 2018.
51 Copyright Notice
53 Copyright (c) 2018 IETF Trust and the persons identified as the
54 document authors. All rights reserved.
56 This document is subject to BCP 78 and the IETF Trust's Legal
57 Provisions Relating to IETF Documents
58 (https://trustee.ietf.org/license-info) in effect on the date of
59 publication of this document. Please review these documents
60 carefully, as they describe your rights and restrictions with respect
61 to this document. Code Components extracted from this document must
62 include Simplified BSD License text as described in Section 4.e of
63 the Trust Legal Provisions and are provided without warranty as
64 described in the Simplified BSD License.
66 Table of Contents
68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
69 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
70 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 5
71 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 5
72 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
73 3. The Layer 2 VPN Service Model . . . . . . . . . . . . . . . . 7
74 3.1. Layer 2 VPN Service Types . . . . . . . . . . . . . . . . 7
75 3.2. Layer 2 VPN Physical Network Topology . . . . . . . . . . 8
76 4. Service Data Model Usage . . . . . . . . . . . . . . . . . . 9
77 5. Design of the Data Model . . . . . . . . . . . . . . . . . . 11
78 5.1. Features and Augmentation . . . . . . . . . . . . . . . . 21
79 5.2. VPN Service Overview . . . . . . . . . . . . . . . . . . 21
80 5.2.1. VPN Service Type . . . . . . . . . . . . . . . . . . 22
81 5.2.2. VPN Service Topology . . . . . . . . . . . . . . . . 22
82 5.2.2.1. Route Target Allocation . . . . . . . . . . . . . 23
83 5.2.2.2. Any-to-Any . . . . . . . . . . . . . . . . . . . 23
84 5.2.2.3. Hub-and-Spoke . . . . . . . . . . . . . . . . . . 23
85 5.2.2.4. Hub-and-Spoke-Disjoint . . . . . . . . . . . . . 24
86 5.2.3. Cloud Access . . . . . . . . . . . . . . . . . . . . 24
87 5.2.4. Extranet VPNs . . . . . . . . . . . . . . . . . . . . 27
88 5.2.5. Frame Delivery Service . . . . . . . . . . . . . . . 29
89 5.3. Site Overview . . . . . . . . . . . . . . . . . . . . . . 30
90 5.3.1. Devices and Locations . . . . . . . . . . . . . . . . 31
91 5.3.2. Site Network Accesses . . . . . . . . . . . . . . . . 32
92 5.3.2.1. Bearer . . . . . . . . . . . . . . . . . . . . . 33
93 5.3.2.2. Connection . . . . . . . . . . . . . . . . . . . 33
94 5.4. Site Role . . . . . . . . . . . . . . . . . . . . . . . . 38
95 5.5. Site Belonging to Multiple VPNs . . . . . . . . . . . . . 38
96 5.5.1. Site VPN Flavor . . . . . . . . . . . . . . . . . . . 38
97 5.5.1.1. Single VPN Attachment: site-vpn-flavor-single . . 38
98 5.5.1.2. MultiVPN Attachment: site-vpn-flavor-multi . . . 39
99 5.5.1.3. NNI: site-vpn-flavor-nni . . . . . . . . . . . . 39
100 5.5.1.4. E2E: site-vpn-flavor-e2e . . . . . . . . . . . . 40
101 5.5.2. Attaching a Site to a VPN . . . . . . . . . . . . . . 41
102 5.5.2.1. Referencing a VPN . . . . . . . . . . . . . . . . 41
103 5.5.2.2. VPN Policy . . . . . . . . . . . . . . . . . . . 43
104 5.6. Deciding Where to Connect the Site . . . . . . . . . . . 48
105 5.6.1. Constraint: Device . . . . . . . . . . . . . . . . . 48
106 5.6.2. Constraint/Parameter: Site Location . . . . . . . . . 49
107 5.6.3. Constraint/Parameter: Access Type . . . . . . . . . . 50
108 5.6.4. Constraint: Access Diversity . . . . . . . . . . . . 51
109 5.7. Route Distinguisher and Network Instance Allocation . . . 52
110 5.8. Site Network Access Availability . . . . . . . . . . . . 53
111 5.9. SVC MTU . . . . . . . . . . . . . . . . . . . . . . . . . 54
112 5.10. Service . . . . . . . . . . . . . . . . . . . . . . . . . 55
113 5.10.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . 55
114 5.10.2. QoS . . . . . . . . . . . . . . . . . . . . . . . . 56
115 5.10.2.1. QoS Classification . . . . . . . . . . . . . . . 56
116 5.10.2.2. QoS Profile . . . . . . . . . . . . . . . . . . 57
117 5.10.3. Broadcast Multicast Unknow Unicast Support . . . . . 58
118 5.11. Site Management . . . . . . . . . . . . . . . . . . . . . 59
119 5.12. MAC Loop Protection . . . . . . . . . . . . . . . . . . . 59
120 5.13. MAC Address Limit . . . . . . . . . . . . . . . . . . . . 60
121 5.14. Enhanced VPN Features . . . . . . . . . . . . . . . . . . 60
122 5.14.1. Carriers' Carriers . . . . . . . . . . . . . . . . . 60
123 5.15. External ID References . . . . . . . . . . . . . . . . . 62
124 5.16. Defining NNIs and Inter-AS support . . . . . . . . . . . 62
125 5.16.1. Defining an NNI with the Option A Flavor . . . . . . 63
126 5.16.2. Defining an NNI with the Option B Flavor . . . . . . 67
127 5.16.3. Defining an NNI with the Option C Flavor . . . . . . 69
128 5.17. Applicability of L2SM model in Inter-Provider and Inter-
129 Domain Orchestration . . . . . . . . . . . . . . . . . . 71
130 6. Interaction with Other YANG Modules . . . . . . . . . . . . . 72
131 7. Service Model Usage Example . . . . . . . . . . . . . . . . . 73
132 8. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 80
133 9. Security Considerations . . . . . . . . . . . . . . . . . . . 153
134 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 154
135 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 154
136 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 155
137 12.1. Normative References . . . . . . . . . . . . . . . . . . 155
138 12.2. Informative References . . . . . . . . . . . . . . . . . 157
139 Appendix A. Changes Log . . . . . . . . . . . . . . . . . . . . 158
140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 162
142 1. Introduction
144 This document defines a YANG data model for Layer 2 VPN (L2VPN)
145 service configuration. This model is intended to be instantiated at
146 management system to allow a user (a customer or an application) to
147 request the service from a service provider. This model is not a
148 configuration model to be used directly on network elements, but
149 provides an abstracted view of the L2VPN service configuration
150 components. It is up to a management system to take this as an input
151 and generate specific configurations models to configure the
152 different network elements to deliver the service. How configuration
153 of network elements is done is out of scope of the document.
155 The data model in this document includes support for point-to-point
156 Virtual Private Wire Services (VPWS) and multipoint Virtual Private
157 LAN services (VPLS) that use Pseudowires signaled using the Label
158 Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as
159 described in [RFC4761] and [RFC6624].
161 Further discussion of the way that services are modeled in YANG and
162 the relationship between "customer service models" like the one
163 described in this document and configuration models can be found in
164 [RFC8309] and [RFC8199]. Section 4 and Section 6 also provide more
165 information of how this service model could be used and how it fits
166 into the overall modeling architecture.
168 1.1. Terminology
170 The following terms are defined in [RFC6241] and are not redefined
171 here:
173 o client
175 o configuration data
177 o server
179 o state data
181 The following terms are defined in [RFC6020] and are not redefined
182 here:
184 o augment
186 o data model
188 o data node
189 The terminology for describing YANG data models is found in
190 [RFC6020].
192 1.1.1. Requirements Language
194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
196 "OPTIONAL" in this document are to be interpreted as described in BCP
197 14 [RFC2119] [RFC8174]when, and only when, they appear in all
198 capitals, as shown here.
200 1.2. Tree diagram
202 A simplified graphical representation of the data model is presented
203 in Section 5.
205 The meaning of the symbols in these diagrams is as follows:
207 o Brackets "[" and "]" enclose list keys.
209 o Curly braces "{" and "}" contain names of optional features that
210 make the corresponding node conditional.
212 o Abbreviations before data node names: "rw" means configuration
213 (read-write), and "ro" state data (read-only).
215 o Symbols after data node names: "?" means an optional node and "*"
216 denotes a "list" or "leaf-list".
218 o Parentheses enclose choice and case nodes, and case nodes are also
219 marked with a colon (":").
221 o Ellipsis ("...") stands for contents of subtrees that are not
222 shown.
224 2. Definitions
226 This document uses the following terms:
228 Service Provider (SP): The organization (usually a commercial
229 undertaking) responsible for operating the network that offers VPN
230 services to clients and customers.
232 Customer Edge (CE) Device: Equipment that is dedicated to a
233 particular customer and is directly connected to one or more PE
234 devices via attachment circuits. A CE is usually located at the
235 customer premises, and is usually dedicated to a single VPN,
236 although it may support multiple VPNs if each one has separate
237 attachment circuits. The CE devices can be routers, bridges,
238 switches, or hosts.
240 Provider Edge (PE) Device: Equipment managed by the SP that can
241 support multiple VPNs for different customers, and is directly
242 connected to one or more CE devices via attachment circuits. A PE
243 is usually located at an SP point of presence (PoP) and is managed
244 by the SP.
246 Virtual Private LAN Service (VPLS): A VPLS is a provider service
247 that emulates the full functionality of a traditional Local Area
248 Network (LAN). A VPLS makes it possible to interconnect several
249 LAN segments over a packet switched network (PSN) and makes the
250 remote LAN segments behave as one single LAN.
252 Virtual Private Wire Service (VPWS): A VPWS is a point-to-point
253 circuit (i.e., link) connecting two CE devices. The link is
254 established as a logical through a packet switched network. The
255 CE in the customer network is connected to a PE in the provider
256 network via an Attachment Circuit (AC): the AC is either a
257 physical or a logical circuit. A VPWS differs from a VPLS in that
258 the VPLS is point-to-multipoint, while the VPWS is point-to-point.
259 In some implementations, a set of VPWSs is used to create a multi-
260 site L2VPN network.
262 Pseudowire(PW): A pseudowire is an emulation of a native service
263 over a packet switched network (PSN). The native service may be
264 ATM, frame relay, Ethernet, low-rate TDM, or SONET/SDH, while the
265 PSN may be MPLS, IP (either IPv4 or IPv6), or L2TPv3.
267 MAC-VRF: A Virtual Routing and Forwarding table for Media Access
268 Control (MAC) addresses on a PE. It is sometime also referred to
269 as a Virtual Switching Instance (VSI).
271 UNI: User to Network Interface. The physical demarcation point
272 between the responsibility of Customer and the responsibility of
273 Provider.
275 NNI: Network to Network Interface. A reference point representing
276 the boundary between two Networks that are operated as separate
277 administrative domains. The two networks may belong to the same
278 provider or to two different providers.
280 This document uses the following abbreviations:
282 BSS: Business Support System
284 B-U-M: Broadcast-UnknownUnicast-Multicast
285 CoS: Class of Service
287 LAG: Link Aggregation Group
289 LLDP: Link Level Discovery Protocol
291 OAM: Operations, Administration, and Maintenance
293 OSS: Operations Support System
295 PDU: Protocol Data Unit
297 QoS: Quality of Service
299 3. The Layer 2 VPN Service Model
301 A Layer 2 VPN (L2VPN) service is a collection of sites that are
302 authorized to exchange traffic between each other over a shared
303 infrastructure of a common technology. This L2VPN service model
304 (L2SM) provides a common understanding of how the corresponding L2VPN
305 service is to be deployed over the shared infrastructure.
307 This document presents the L2SM using the YANG data modeling language
308 [RFC6020] as a formal language that is both human-readable and
309 parsable by software for use with protocols such as NETCONF [RFC6241]
310 and RESTCONF [RFC8040].
312 This service model is limited to VPWS and VPLS based VPNs as
313 described in [RFC4761] and [RFC6624], EVPN as described in [RFC7432].
315 3.1. Layer 2 VPN Service Types
317 From a technology perspective, a set of basic L2VPN service types
318 include:
320 o Point-to-point Virtual Private Wire Services (VPWSs) that use LDP-
321 signaled Psedowires or L2TP-signaled Psedowires [RFC6074];
323 o Multipoint Virtual Private LAN Services (VPLSs) that use LDP-
324 signaled Pseudowires or L2TP-signaled Psedowires [RFC6074];
326 o Multipoint Virtual Private LAN Services (VPLSs) that use a Border
327 Gateway Protocol (BGP) control plane as described in [RFC4761] and
328 [RFC6624];
330 o IP-Only LAN-Like Services (IPLSs) that are a functional subset of
331 VPLS services [RFC4664];
333 o BGP MPLS-based Ethernet VPN Services as described in [RFC7432] and
334 [RFC7209];
336 o Ethernet VPN VPWS specified in [RFC8214] and [RFC7432];
338 3.2. Layer 2 VPN Physical Network Topology
340 Figure 1 depicts a typical service provider's physical network
341 topology. Most service providers have deployed an IP, MPLS, or
342 Segment Routing (SR) multi-service core infrastructure. Ingress
343 Layer 2 service frames will be mapped to either an Ethernet
344 Pseudowire (PWE) or a VxLAN PE-to-PE tunnel. The details of these
345 tunneling mechanism are at the provider's discretion and not part of
346 the L2SM.
348 An L2VPN provides end-to-end L2 connectivity over this multi-service
349 core infrastructure between two or more customer locations or a
350 collection of sites. Attachment Circuits are placed between CE
351 devices and PE Devices that backhaul layer 2 service frames from the
352 customer over the access network to the Provider Network or remote
353 Site. The demarcation point (i.e., UNI) between the customer and
354 service provider can be either placed between Customer nodes and the
355 Customer Edge Device, or between the Customer Edge Device and the
356 Provider Edge Device. The actual bearer connection between CE and PE
357 will be described in the L2SM model.
359 The service provider may also choose a Seamless MPLS approach to
360 expand the PWE or VxLAN tunnel between sites.
362 The service provider may leverage multi-protocol BGP to auto-discover
363 and signal the PWE or VxLAN tunnel end points.
365 Site A | |Site B
366 --- ---- | VXLAN/PW | ---
367 | | | | |<------------------------>| | |
368 | C +---+ CE | | | | C |
369 | | | | | --------- | | |
370 --- ----\ | ( ) | /---
371 \ -|-- ( ) -|-- ---- /
372 \| | ( ) | | | |/
373 | PE +---+ IP/MPLS/SR +---+ PE +---+ CE |
374 /| | ( Network ) | | | |\
375 / ---- ( ) ---- ---- \
376 --- ----/ ( ) \---
377 | | | | ----+---- | |
378 | C +---+ CE | | | C |
379 | | | | --+-- | |
380 --- ---- | PE | ---
381 --+--
382 | Site C
383 --+--
384 | CE |
385 --+--
386 |
387 --+--
388 | C |
389 -----
391 Figure 1: Reference Network for the Use of the L2VPN Service Model
393 From the customer perspective, however, all the customer edge devices
394 are connected over a simulated LAN environment as shown in Figure 2.
395 Broadcast and multicast packets are sent to all participants in the
396 same bridge domain.
398 CE---+----+-----+---CE
399 | | |
400 | | |
401 | | |
402 CE---+ CE +---CE
404 Figure 2: Customer View of the L2VPN
406 4. Service Data Model Usage
408 The L2VPN service model provides an abstracted interface to request,
409 configure, and manage the components of an L2VPN service. The model
410 is used by a customer who purchases connectivity and other services
411 from an SP to communicate with that SP.
413 A typical usage for this model is as an input to an orchestration
414 layer that is responsible for translating it into configuration
415 commands for the network elements that deliver/enable the service.
416 The network elements may be routers, but also servers (like AAA) that
417 are necessary within the network.
419 The configuration of network elements may be done using the Command
420 Line Interface (CLI), or any other configuration (or "southbound")
421 interface such as NETCONF [RFC6241] in combination with device-
422 specific and protocol-specific YANG models.
424 This way of using the service model is illustrated in Figure 3 and
425 described in more detail in [RFC8309] and [RFC8199]. The usage of
426 this service model is not limited to this example: it can be used by
427 any component of the management system, but not directly by network
428 elements.
430 The usage and structure of this model should be compared to the Layer
431 3 VPN service model defined in [RFC8299].
433 ----------------------------
434 | Customer Service Requester |
435 ----------------------------
436 |
437 L2VPN |
438 Service |
439 Model |
440 |
441 -----------------------
442 | Service Orchestration |
443 -----------------------
444 |
445 | Service +-------------+
446 | Delivery +------>| Application |
447 | Model | | BSS/OSS |
448 | V +-------------+
449 -----------------------
450 | Network Orchestration |
451 -----------------------
452 | |
453 +----------------+ |
454 | Config manager | |
455 +----------------+ | Device
456 | | Models
457 | |
458 --------------------------------------------
459 Network
460 +++++++
461 + AAA +
462 +++++++
464 ++++++++ Bearer ++++++++ ++++++++ ++++++++
465 + CE A + ----------- + PE A + + PE B + ---- + CE B +
466 ++++++++ Connection ++++++++ ++++++++ ++++++++
468 Site A Site B
470 Figure 3: Reference Architecture for the Use of the L2VPN Service
471 Model
473 5. Design of the Data Model
475 The L2SM model is structured in a way that allows the provider to
476 list multiple circuits of various service types for the same
477 customer. A circuit represents an end-to-end connection between two
478 or more locations of Customers.
480 The YANG module is divided into two main containers: vpn-services and
481 sites. The vpn-svc container under vpn-services defines global
482 parameters for the VPN service for a specific customer.
484 A site contains at least one network access (i.e., site network
485 accesses providing access to the sites defined in Section 5.3.2) and
486 there may be multiple network accesses in case of multihoming. The
487 site to network access attachment is done through a bearer with a
488 Layer 2 connection on top. The bearer refers to properties of the
489 attachment that are below layer 2 while the connection refers to
490 layer 2 protocol oriented properties. The bearer may be allocated
491 dynamically by the service provider and the customer may provide some
492 constraints or parameters to drive the placement.
494 Authorization of traffic exchange is done through what we call a VPN
495 policy or VPN topology defining routing exchange rules between sites.
497 An end to end Multi-segment connectivity can be realized using a
498 combination of per site connectivity and per segment connectivity at
499 different segments.
501 The figure below describe the overall structure of the YANG module:
503 module: ietf-l2vpn-svc
504 +--rw l2vpn-svc
505 +--rw vpn-profiles
506 | +--rw valid-provider-identifiers
507 | +--rw cloud-identifier* [id] {cloud-access}?
508 | | +--rw id string
509 | +--rw qos-profile-identifier* [id]
510 | | +--rw id string
511 | +--rw bfd-profile-identifier* [id]
512 | | +--rw id string
513 | +--rw remote-carrier-identifier* [id]
514 | +--rw id string
515 +--rw vpn-services
516 | +--rw vpn-service* [vpn-id]
517 | +--rw vpn-id svc-id
518 | +--rw svc-type? identityref
519 | +--rw customer-name? string
520 | +--rw svc-topo? identityref
521 | +--rw cloud-accesses {cloud-access}?
522 | | +--rw cloud-access* [cloud-identifier]
523 | | +--rw cloud-identifier
524 | | | -> /l2vpn-svc/vpn-profiles/
525 | | | valid-provider-identifiers/cloud-identifier/id
526 | | +--rw (list-flavor)?
527 | | +--:(permit-any)
528 | | | +--rw permit-any? empty
529 | | +--:(deny-any-except)
530 | | | +--rw permit-site*
531 | | | : -> /l2vpn-svc/sites/site/site-id
532 | | +--:(permit-any-except)
533 | | +--rw deny-site*
534 | | -> /l2vpn-svc/sites/site/site-id
535 | +--rw frame-delivery {frame-delivery}?
536 | | +--rw customer-tree-flavors
537 | | | +--rw tree-flavor* identityref
538 | | +--rw bum-frame-delivery
539 | | | +--rw bum-frame-delivery* [frame-type]
540 | | | +--rw frame-type identityref
541 | | | +--rw delivery-mode? identityref
542 | | +--rw multicast-gp-port-mapping identityref
543 | +--rw extranet-vpns {extranet-vpn}?
544 | | +--rw extranet-vpn* [vpn-id]
545 | | +--rw vpn-id svc-id
546 | | +--rw local-sites-role? identityref
547 | +--rw ce-vlan-preservation boolean
548 | +--rw ce-vlan-cos-perservation boolean
549 | +--rw carrierscarrier? boolean {carrierscarrier}?
550 +--rw sites
551 +--rw site* [site-id]
552 +--rw site-id string
553 +--rw site-vpn-flavor? identityref
554 +--rw devices
555 | +--rw device* [device-id]
556 | +--rw device-id string
557 | +--rw location
558 | | -> ../../../locations/location/location-id
559 | +--rw management
560 | +--rw transport? identityref
561 | +--rw address? inet:ip-address
562 +--rw locations
563 | +--rw location* [location-id]
564 | +--rw location-id string
565 | +--rw address? string
566 | +--rw zip-code? string
567 | +--rw state? string
568 | +--rw city? string
569 | +--rw country-code? string
570 +--rw management
571 | +--rw type identityref
572 +--rw site-diversity {site-diversity}?
573 | +--rw groups
574 | +--rw group* [group-id]
575 | +--rw group-id string
576 +--rw vpn-policies
577 | +--rw vpn-policy* [vpn-policy-id]
578 | +--rw vpn-policy-id string
579 | +--rw entries* [id]
580 | +--rw id string
581 | +--rw filters
582 | | +--rw filter* [type]
583 | | +--rw type identityref
584 | | +--rw lan-tag* uint32 {lan-tag}?
585 | +--rw vpn* [vpn-id]
586 | +--rw vpn-id
587 | | -> /l2vpn-svc/vpn-services/
588 | | vpn-service/vpn-id
589 | +--rw site-role? identityref
590 +--rw service
591 | +--rw qos {qos}?
592 | | +--rw classification-policy
593 | | | +--rw rule* [id]
594 | | | +--rw id string
595 | | | +--rw (match-type)?
596 | | | | +--:(match-flow)
597 | | | | | +--rw match-flow
598 | | | | | +--rw dscp? inet:dscp
599 | | | | | +--rw dot1q? uint16
600 | | | | | +--rw pcp? uint8
601 | | | | | +--rw src-mac? yang:mac-address
602 | | | | | +--rw dst-mac? yang:mac-address
603 | | | | | +--rw color-type? identityref
604 | | | | | +--rw target-sites*
605 | | | | | | svc-id {target-sites}?
606 | | | | | +--rw any? empty
607 | | | | | +--rw vpn-id? svc-id
608 | | | | +--:(match-application)
609 | | | | +--rw match-application? identityref
610 | | | +--rw target-class-id? string
611 | | +--rw qos-profile
612 | | +--rw (qos-profile)?
613 | | +--:(standard)
614 | | | +--rw profile?
615 | | | -> /l2vpn-svc/vpn-profiles/
616 | | | valid-provider-identifiers/
617 | | | qos-profile-identifier/id
618 | | +--:(custom)
619 | | +--rw classes {qos-custom}?
620 | | +--rw class* [class-id]
621 | | +--rw class-id string
622 | | +--rw direction? identityref
623 | | +--rw policing? identityref
624 | | +--rw byte-offset? uint16
625 | | +--rw frame-delay
626 | | | +--rw (flavor)?
627 | | | +--:(lowest)
628 | | | | +--rw use-lowest-latency? empty
629 | | | +--:(boundary)
630 | | | +--rw delay-bound? uint16
631 | | +--rw frame-jitter
632 | | | +--rw (flavor)?
633 | | | +--:(lowest)
634 | | | | +--rw use-lowest-jitter? empty
635 | | | +--:(boundary)
636 | | | +--rw delay-bound? uint32
637 | | +--rw frame-loss
638 | | | +--rw rate? decimal64
639 | | +--rw bandwidth
640 | | +--rw guaranteed-bw-percent decimal64
641 | | +--rw end-to-end? empty
642 | +--rw carrierscarrier {carrierscarrier}?
643 | +--rw signaling-type? identityref
644 +--rw broadcast-unknown-unicast-multicast {bum}?
645 | +--rw multicast-site-type? enumeration
646 | +--rw multicast-gp-address-mapping* [id]
647 | | +--rw id uint16
648 | | +--rw vlan-id uint16
649 | | +--rw mac-gp-address yang:mac-address
650 | | +--rw port-lag-number? uint32
651 | +--rw bum-overall-rate? uint32
652 | +--rw bum-rate-per-type* [type]
653 | +--rw type identityref
654 | +--rw rate? uint32
655 +--rw mac-loop-prevention {mac-loop-prevention}?
656 | +--rw protection-type? identityref
657 | +--rw frequency? uint32
658 | +--rw retry-timer? uint32
659 +--rw access-control-list
660 | +--rw mac* [mac-address]
661 | +--rw mac-address yang:mac-address
662 +--ro actual-site-start? yang:date-and-time
663 +--ro actual-site-stop? yang:date-and-time
664 +--rw bundling-type? identityref
665 +--rw default-ce-vlan-id uint32
666 +--rw site-network-accesses
667 +--rw site-network-access* [network-access-id]
668 +--rw network-access-id string
669 +--rw remote-carrier-name? string
670 +--rw type? identityref
671 +--rw (location-flavor)
672 | +--:(location)
673 | | +--rw location-reference?
674 | | -> ../../../locations/location/
675 | | location-id
676 | +--:(device)
677 | +--rw device-reference?
678 | -> ../../../devices/device/device-id
679 +--rw access-diversity {site-diversity}?
680 | +--rw groups
681 | | +--rw group* [group-id]
682 | | +--rw group-id string
683 | +--rw constraints
684 | +--rw constraint* [constraint-type]
685 | +--rw constraint-type identityref
686 | +--rw target
687 | +--rw (target-flavor)?
688 | +--:(id)
689 | | +--rw group* [group-id]
690 | | +--rw group-id string
691 | +--:(all-accesses)
692 | | +--rw all-other-accesses? empty
693 | +--:(all-groups)
694 | +--rw all-other-groups? empty
695 +--rw bearer
696 | +--rw requested-type {requested-type}?
697 | | +--rw type? string
698 | | +--rw strict? boolean
699 | +--rw always-on? boolean {always-on}?
700 | +--rw bearer-reference? string {bearer-reference}?
701 +--rw connection
702 | +--rw encapsulation-type? identityref
703 | +--rw eth-inf-type? identityref
704 | +--rw tagged-interface
705 | | +--rw type? identityref
706 | | +--rw dot1q-vlan-tagged {dot1q}?
707 | | | +--rw tg-type? identityref
708 | | | +--rw cvlan-id uint16
709 | | +--rw priority-tagged
710 | | | +--rw tag-type? identityref
711 | | +--rw qinq {qinq}?
712 | | | +--rw tag-type? identityref
713 | | | +--rw svlan-id uint16
714 | | | +--rw cvlan-id uint16
715 | | +--rw qinany {qinany}?
716 | | | +--rw tag-type? identityref
717 | | | +--rw svlan-id uint16
718 | | +--rw vxlan {vxlan}?
719 | | +--rw vni-id uint32
720 | | +--rw peer-mode? identityref
721 | | +--rw peer-list* [peer-ip]
722 | | +--rw peer-ip inet:ip-address
723 | +--rw untagged-interface
724 | | +--rw speed? uint32
725 | | +--rw mode? neg-mode
726 | | +--rw phy-mtu? uint32
727 | | +--rw lldp? boolean
728 | | +--rw oam-802.3ah-link {oam-3ah}?
729 | | | +--rw enable? boolean
730 | | +--rw uni-loop-prevention? boolean
731 | +--rw lag-interfaces {lag-interface}?
732 | | +--rw lag-interface* [index]
733 | | +--rw index string
734 | | +--rw lacp {lacp}?
735 | | +--rw enable? boolean
736 | | +--rw mode? neg-mode
737 | | +--rw speed? uint32
738 | | +--rw mini-link-num? uint32
739 | | +--rw system-priority? uint16
740 | | +--rw micro-bfd {micro-bfd}?
741 | | | +--rw enable? enumeration
742 | | | +--rw interval? uint32
743 | | | +--rw hold-timer? uint32
744 | | +--rw bfd {bfd}?
745 | | | +--rw enabled? boolean
746 | | | +--rw (holdtime)?
747 | | | +--:(profile)
748 | | | | +--rw profile-name?
749 | | | | -> /l2vpn-svc/
750 | | | | vpn-profiles/
751 | | | | valid-provider-identifiers/
752 | | | | bfd-profile-identifier/id
753 | | | +--:(fixed)
754 | | | +--rw fixed-value? uint32
755 | | +--rw member-links
756 | | | +--rw member-link* [name]
757 | | | +--rw name string
758 | | | +--rw speed? uint32
759 | | | +--rw mode? neg-mode
760 | | | +--rw link-mtu? uint32
761 | | | +--rw oam-802.3ah-link {oam-3ah}?
762 | | | +--rw enable? boolean
763 | | +--rw flow-control? boolean
764 | | +--rw lldp? boolean
765 | +--rw cvlan-id-to-svc-map* [svc-id]
766 | | +--rw svc-id
767 | | | -> /l2vpn-svc/vpn-services/vpn-service/
768 | | | vpn-id
769 | | +--rw cvlan-id* [vid]
770 | | +--rw vid uint16
771 | +--rw l2cp-control {l2cp-control}?
772 | | +--rw stp-rstp-mstp? control-mode
773 | | +--rw pause? control-mode
774 | | +--rw lacp-lamp? control-mode
775 | | +--rw link-oam? control-mode
776 | | +--rw esmc? control-mode
777 | | +--rw l2cp-802.1x? control-mode
778 | | +--rw e-lmi? control-mode
779 | | +--rw lldp? boolean
780 | | +--rw ptp-peer-delay? control-mode
781 | | +--rw garp-mrp? control-mode
782 | +--rw oam {oam}
783 | +--rw md-name string
784 | +--rw md-level uint16
785 | +--rw cfm-802.1-ag* [maid]
786 | | +--rw maid string
787 | | +--rw mep-id? uint32
788 | | +--rw mep-level? uint32
789 | | +--rw mep-up-down? enumeration
790 | | +--rw remote-mep-id? uint32
791 | | +--rw cos-for-cfm-pdus? uint32
792 | | +--rw ccm-interval? uint32
793 | | +--rw ccm-holdtime? uint32
794 | | +--rw alarm-priority-defect? identityref
795 | | +--rw ccm-p-bits-pri? ccm-priority-type
796 | +--rw y-1731* [maid]
797 | +--rw maid string
798 | +--rw mep-id? uint32
799 | +--rw type? identityref
800 | +--rw remote-mep-id? uint32
801 | +--rw message-period? uint32
802 | +--rw measurement-interval? uint32
803 | +--rw cos? uint32
804 | +--rw loss-measurement? boolean
805 | +--rw synthethic-loss-measurement? boolean
806 | +--rw delay-measurement
807 | | +--rw enable-dm? boolean
808 | | +--rw two-way? boolean
809 | +--rw frame-size? uint32
810 | +--rw session-type? enumeration
811 +--rw availability
812 | +--rw access-priority? uint32
813 | +--rw (redundancy-mode)?
814 | +--:(single-active)
815 | | +--rw single-active? empty
816 | +--:(all-active)
817 | +--rw all-active? empty
818 +--rw vpn-attachment
819 | +--rw (attachment-flavor)
820 | +--:(vpn-id)
821 | | +--rw vpn-id?
822 | | | -> /l2vpn-svc/vpn-services/
823 | | | vpn-service/vpn-id
824 | | +--rw site-role? identityref
825 | +--:(vpn-policy-id)
826 | +--rw vpn-policy-id?
827 | -> ../../../../vpn-policies/
828 | vpn-policy/vpn-policy-id
829 +--rw service
830 | +--rw svc-bandwidth {input-bw}?
831 | | +--rw bandwidth* [direction type]
832 | | +--rw direction identityref
833 | | +--rw type identityref
834 | | +--rw cos-id? uint8
835 | | +--rw vpn-id? svc-id
836 | | +--rw cir uint64
837 | | +--rw cbs uint64
838 | | +--rw eir? uint64
839 | | +--rw ebs? uint64
840 | | +--rw pir? uint64
841 | | +--rw pbs? uint64
842 | +--rw svc-mtu uint16
843 | +--rw qos {qos}?
844 | | +--rw classification-policy
845 | | | +--rw rule* [id]
846 | | | +--rw id string
847 | | | +--rw (match-type)?
848 | | | | +--:(match-flow)
849 | | | | | +--rw match-flow
850 | | | | | +--rw dscp? inet:dscp
851 | | | | | +--rw dot1q? uint16
852 | | | | | +--rw pcp? uint8
853 | | | | | +--rw src-mac? yang:mac-address
854 | | | | | +--rw dst-mac? yang:mac-address
855 | | | | | +--rw color-type? identityref
856 | | | | | +--rw target-sites*
857 | | | | | | svc-id {target-sites}?
858 | | | | | +--rw any? empty
859 | | | | | +--rw vpn-id? svc-id
860 | | | | +--:(match-application)
861 | | | | +--rw match-application? identityref
862 | | | +--rw target-class-id? string
863 | | +--rw qos-profile
864 | | +--rw (qos-profile)?
865 | | +--:(standard)
866 | | | +--rw profile?
867 | | | -> /l2vpn-svc/vpn-profiles/
868 | | | valid-provider-identifiers/
869 | | | qos-profile-identifier/id
870 | | +--:(custom)
871 | | +--rw classes {qos-custom}?
872 | | +--rw class* [class-id]
873 | | +--rw class-id string
874 | | +--rw direction? identityref
875 | | +--rw policing? identityref
876 | | +--rw byte-offset? uint16
877 | | +--rw frame-delay
878 | | | +--rw (flavor)?
879 | | | +--:(lowest)
880 | | | | +--rw use-lowest-latency?
881 | | | | empty
882 | | | +--:(boundary)
883 | | | +--rw delay-bound? uint16
884 | | +--rw frame-jitter
885 | | | +--rw (flavor)?
886 | | | +--:(lowest)
887 | | | | +--rw use-lowest-jitter?
888 | | | | empty
889 | | | +--:(boundary)
890 | | | +--rw delay-bound? uint32
891 | | +--rw frame-loss
892 | | | +--rw rate? decimal64
893 | | +--rw bandwidth
894 | | +--rw guaranteed-bw-percent
895 | | | decimal64
896 | | +--rw end-to-end? empty
897 | +--rw carrierscarrier {carrierscarrier}?
898 | +--rw signaling-type? identityref
899 +--rw broadcast-unknown-unicast-multicast {bum}?
900 | +--rw multicast-site-type? enumeration
901 | +--rw multicast-gp-address-mapping* [id]
902 | | +--rw id uint16
903 | | +--rw vlan-id uint16
904 | | +--rw mac-gp-address yang:mac-address
905 | | +--rw port-lag-number? uint32
906 | +--rw bum-overall-rate? uint32
907 | +--rw bum-rate-per-type* [type]
908 | +--rw type identityref
909 | +--rw rate? uint32
910 +--rw mac-loop-prevention {mac-loop-prevention}?
911 | +--rw protection-type? identityref
912 | +--rw frequency? uint32
913 | +--rw retry-timer? uint32
914 +--rw access-control-list
915 | +--rw mac* [mac-address]
916 | +--rw mac-address yang:mac-address
917 +--rw mac-addr-limit
918 +--rw limit-number? uint16
919 +--rw time-interval? uint32
920 +--rw action? identityref
922 Figure 4
924 5.1. Features and Augmentation
926 The model defined in this document implements many features that
927 allow implementations to be modular. As an example, the layer 2
928 protocols parameters (Section 5.3.2.2) proposed to the customer may
929 also be enabled through features. This model also defines some
930 features for options that are more advanced, such as support for
931 extranet VPNs (Section 5.2.4), site diversity (Section 5.3), and QoS
932 (Section 5.10.2).
934 In addition, as for any YANG model, this service model can be
935 augmented to implement new behaviors or specific features. For
936 example, this model defines VXLAN [RFC7348] for Ethernet packet
937 Encapsulation; if VXLAN Encapsulation does not fulfill all
938 requirements for describing the service, new options can be added
939 through augmentation.
941 5.2. VPN Service Overview
943 A vpn-service list item contains generic information about the VPN
944 service. The vpn-id of the vpn-service refers to an internal
945 reference for this VPN service. This identifier is purely internal
946 to the organization responsible for the VPN service.
948 A vpn-service is composed of some characteristics:
950 Customer information: Used to identify the customer.
952 VPN Service Type (svc-type): Used to indicate the VPN service Type.
953 The identifier is a string allowing any encoding for the local
954 administration of the VPN service.
956 Cloud Access (cloud-access): All sites in the L2VPN MUST be
957 authorized to access to the cloud. The cloud-access container
958 provides parameters for authorization rules. A cloud identifier
959 is used to reference the target service. This identifier is local
960 to each administration.
962 Service Topology (svc-topo): Used to identify the type of VPN
963 service topology that is required.
965 Frame Delivery Service (frame-delivery): Defines the frame delivery
966 support required for the L2VPN, e.g., multicast delivery, unicast
967 delivery, or broadcast delivery.
969 Extranet VPN (extranet-vpns): Indicates that a particular VPN needs
970 access to resources located in another VPN.
972 5.2.1. VPN Service Type
974 The "svc-type" defines the service type for provider provisioned
975 L2VPNs. The current version of the model supports six flavors:
977 o Point-to-point Virtual Private Wire Services (VPWS) connecting two
978 customer Sites;
980 o Point-to-point or point-to-multipoint Virtual Private Wire
981 Services (VPWS) connecting a set of customer sites [RFC8214];
983 o Multipoint Virtual Private LAN services (VPLS) connecting a set of
984 customer sites;
986 o Multipoint Virtual Private LAN services (VPLS) connecting one or
987 more root sites and a set of leave sites, but preventing inter-
988 leaf sites communication.
990 o EVPN Service connecting a set of customer sites.
992 o Ethernet VPN VPWS between two customer sites or a set of customer
993 sites specified in [RFC8214] and [RFC7432];
995 Other L2VPN Service Types could be included by augmentation. Note
996 that an Ethernet Private Line (EPL) service or an Ethernet Virtual
997 Private Line (EVPL) service is an E-Line service or a point-to-point
998 Ethernet Virtual Circuit (EVC) service, while an Ethernet Private LAN
999 (EP-LAN) service or an Ethernet Virtual Private LAN (EVP-LAN) service
1000 is an E-LAN service or a multipoint-to-multipoint EVC service.
1002 5.2.2. VPN Service Topology
1004 The type of VPN service topology can be used for configuration if
1005 needed. The module currently supports: any-to-any; hub-and-spoke
1006 (where hubs can exchange traffic); and hub-and-spoke-disjoint (where
1007 hubs cannot exchange traffic). New topologies could be added by
1008 augmentation. By default, the any-to-any VPN service topology is
1009 used.
1011 5.2.2.1. Route Target Allocation
1013 A Layer 2 PE-based VPN (such as a VPLS-based VPN, or an EVPN that
1014 uses BGP as its signaling protocol) can be built using route targets
1015 (RTs) as described in [RFC4364] an [RFC7432]. The management system
1016 is expected to automatically allocate a set of RTs upon receiving a
1017 VPN service creation request. How the management system allocates
1018 RTs is out of scope for this document, but multiple ways could be
1019 envisaged, as described in the Section 6.2.1.1 of [RFC8299].
1021 5.2.2.2. Any-to-Any
1023 +------------------------------------------------------------+
1024 | VPN1_Site1 ------ PE1 PE2 ------ VPN1_Site2 |
1025 | |
1026 | VPN1_Site3 ------ PE3 PE4 ------ VPN1_Site4 |
1027 +------------------------------------------------------------+
1029 Any-to-Any VPN Service Topology
1031 In the any-to-any VPN service topology, all VPN sites can communicate
1032 with each other without any restrictions. The management system that
1033 receives an any-to-any L2VPN service request through this model is
1034 expected to assign and then configure the MAC-VRF and RTs on the
1035 appropriate PEs. In the any-to-any case, a single RT is generally
1036 required, and every MAC-VRF imports and exports this RT.
1038 5.2.2.3. Hub-and-Spoke
1040 +-------------------------------------------------------------+
1041 | Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
1042 | +----------------------------------+
1043 | |
1044 | +----------------------------------+
1045 | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
1046 +-------------------------------------------------------------+
1048 Hub-and-Spoke VPN Service Topology
1050 In the Hub-and-Spoke VPN service topology, all Spoke sites can
1051 communicate only with Hub sites, but not with each other. And Hubs
1052 can also communicate with each other. The management system that
1053 receives a Hub-and-Spoke L2VPN service request through this model is
1054 expected to assign and then configure the MAC-VRF and RTs on the
1055 appropriate PEs. In the Hub-and-Spoke case, two RTs are generally
1056 required (one RT for Hub routes, and one RT for Spoke routes). A Hub
1057 MAC-VRF that connects Hub sites will export Hub routes with the Hub
1058 RT and will import Spoke routes through the Spoke RT. It will also
1059 import the Hub RT to allow Hub-to-Hub communication. A Spoke MAC-VRF
1060 that connects Spoke sites will export Spoke routes with the Spoke RT
1061 and will import Hub routes through the Hub RT.
1063 5.2.2.4. Hub-and-Spoke-Disjoint
1065 +-------------------------------------------------------------+
1066 | Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
1067 +--------------------------+ +-------------------------------+
1068 | |
1069 +--------------------------+ +-------------------------------+
1070 | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
1071 +-------------------------------------------------------------+
1073 Hub-and-Spoke-Disjoint VPN Service Topology
1075 In the Hub-and-Spoke-Disjoint VPN service topology, all Spoke sites
1076 can communicate only with Hub sites, but not with each other. And
1077 Hubs cannot communicate with each other. The management system that
1078 receives a Hub-and-Spoke-Disjoint L2VPN service request through this
1079 model is expected to assign and then configure the VRF and RTs on the
1080 appropriate PEs. In the Hub-and-Spoke-Disjoint case, two RTs
1081 arerequired (one RT for Hub routes and one RT for Spoke routes). A
1082 Hub VRF that connects Hub sites will export Hub routes with the Hub
1083 RT and will import Spoke routes through the Spoke RT. A Spoke VRF
1084 that connects Spoke sites will export Spoke routes with the Spoke RT
1085 and will import Hub routes through the Hub RT.
1087 The management system MUST take into account constraints on Hub-and-
1088 Spoke connections, as in the previous case.
1090 Hub-and-Spoke-Disjoint can also be seen as multiple Hub-and-Spoke
1091 VPNs (one per Hub) that share a common set of Spoke sites.
1093 5.2.3. Cloud Access
1095 This model provides cloud access configuration through the cloud-
1096 access container. The usage of cloud-access is targeted for public
1097 cloud and for Internet access. The cloud-access container provides
1098 parameters for authorization rules.
1100 Private cloud access may be addressed through the site container as
1101 described in Section 5.3 with use consistent with sites of type NNI.
1103 A cloud identifier is used to reference the target service. This
1104 identifier is local to each administration.
1106 By default, all sites in the L2VPN MUST be authorized to access the
1107 cloud. If restrictions are required, a user MAY configure the
1108 "permit-site" or "deny-site" leaf-list. The permit-site leaf-list
1109 defines the list of sites authorized for cloud access. The deny-site
1110 leaf-list defines the list of sites denied for cloud access. The
1111 model supports both "deny-any-except" and "permit-any-except"
1112 authorization.
1114 How the restrictions will be configured on network elements is out of
1115 scope for this document.
1117 L2VPN
1118 ++++++++++++++++++++++++++++++++ ++++++++++++
1119 + Site 3 + --- + Cloud 1 +
1120 + Site 1 + ++++++++++++
1121 + +
1122 + Site 2 + --- ++++++++++++
1123 + + + Internet +
1124 + Site 4 + ++++++++++++
1125 ++++++++++++++++++++++++++++++++
1126 |
1127 +++++++++++
1128 + Cloud 2 +
1129 +++++++++++
1131 In the example above, we configure the global VPN to access the
1132 Internet by creating a cloud-access container pointing to the cloud
1133 identifier for the Internet service. No authorized sites will be
1134 configured, as all sites are required to be able to access the
1135 Internet.
1137
1138
1139
1140
1141 123456487
1142
1143
1144 INTERNET
1145
1146
1147 true
1148 true
1149
1150
1151
1153 If Site 1 and Site 2 require access to Cloud 1, a new cloud-access
1154 container pointing to the cloud identifier of Cloud 1 will be
1155 created. The permit-site leaf-list will be filled with a reference
1156 to Site 1 and Site 2.
1158
1159
1160
1161
1162 123456487
1163
1164
1165 Cloud1
1166 site1
1167 site2
1168
1169
1170 true
1171 true
1172
1173
1174
1176 If all sites except Site 1 require access to Cloud 2, a new cloud-
1177 access container pointing to the cloud identifier of Cloud 2 will be
1178 created. The deny-site leaf-list will be filled with a reference to
1179 Site 1.
1181
1182
1183
1184
1185 123456487
1186
1187
1188 Cloud2
1189 site1
1190
1191
1192 true
1193 true
1194
1195
1196
1198 5.2.4. Extranet VPNs
1200 There are some cases where a particular VPN needs access to resources
1201 (servers, hosts, etc.) that are external. Those resources may be
1202 located in another VPN.
1204 +-----------+ +-----------+
1205 / \ / \
1206 Site A -- | VPN A | --- | VPN B | --- Site B
1207 \ / \ / (Shared
1208 +-----------+ +-----------+ resources)
1210 In the figure above, VPN B has some resources on Site B that need to
1211 be made available to some customers/partners. Specifically, VPN A
1212 must be able to access those VPN B resources.
1214 Such a VPN connection scenario can be achieved via a VPN policy as
1215 defined in Section 5.5.2.2. But there are some simple cases where a
1216 particular VPN (VPN A) needs access to all resources in another VPN
1217 (VPN B). The model provides an easy way to set up this connection
1218 using the "extranet-vpns" container.
1220 The extranet-vpns container defines a list of VPNs a particular VPN
1221 wants to access. The extranet-vpns container is used on customer
1222 VPNs accessing extranet resources in another VPN. In the figure
1223 above, in order to provide VPN A with access to VPN B, the extranet-
1224 vpns container needs to be configured under VPN A with an entry
1225 corresponding to VPN B. There is no service configuration
1226 requirement on VPN B.
1228 Readers should note that even if there is no configuration
1229 requirement on VPN B, if VPN A lists VPN B as an extranet, all sites
1230 in VPN B will gain access to all sites in VPN A.
1232 The "site-role" leaf defines the role of the local VPN sites in the
1233 target extranet VPN service topology. Site roles are defined in
1234 Section 5.4.
1236 In the example below, VPN A accesses VPN B resources through an
1237 extranet connection. A Spoke role is required for VPN A sites, as
1238 sites from VPN A must not be able to communicate with each other
1239 through the extranet VPN connection.
1241
1242
1243
1244
1245 VPNB
1246 hub-spoke
1247
1248
1249 VPNA
1250 any-to-any
1251
1252
1253 VPNB
1254 spoke-role
1255
1256
1257 true
1258 true
1259
1260
1261
1263 This model does not define how the extranet configuration will be
1264 achieved within the network.
1266 Any VPN interconnection scenario that is more complex (e.g., only
1267 certain parts of sites on VPN A accessing only certain parts of sites
1268 on VPN B) needs to be achieved using a VPN attachment as defined in
1269 Section 5.5.2, and especially a VPN policy as defined in
1270 Section 5.5.2.2.
1272 5.2.5. Frame Delivery Service
1274 If Frame Delivery Service support is required for an L2VPN, some
1275 global frame delivery parameters are required as input for the
1276 service request. When a CE sends packets that are Broadcast,
1277 Multicast, or Unknown-destination-unicast, replication occurs at the
1278 ingress PE, therefore three frame types are supported.
1280 Users of this model will need to provide the flavors of trees that
1281 will be used by customers within the L2VPN (customer-tree-flavors).
1282 The model defined in this document supports bidirectional, shared,
1283 and source-based trees (and can be augmented to contain other tree
1284 types). Multiple flavors of trees can be supported simultaneously.
1286 Operator network
1287 ______________
1288 / \
1289 | |
1290 | |
1291 Recv -- Site2 ------- PE2 |
1292 | PE1 --- Site1 --- Source1
1293 | | \
1294 | | -- Source2
1295 | |
1296 | |
1297 Recv -- Site3 ------- PE3 |
1298 | |
1299 | |
1300 Recv -- Site4 ------- PE4 |
1301 / | |
1302 Recv -- Site5 ------- | |
1303 | |
1304 | |
1305 \_______________/
1307 Multicast Group to port mappings can be created using the "rp-group-
1308 mappings" leaf. Two group to port mapping methods are supported:
1310 o Static configuration of multicast Ethernet addresses and ports/
1311 interfaces.
1313 o Multicast control protocol based on Layer-2 technology that
1314 signals mappings of multicast addresses to ports/interfaces, such
1315 as Generic Attribute Registration Protocol / GARP Multicast
1316 Registration Protocol (GARP/GMRP) [IEEE-802-1D].
1318 5.3. Site Overview
1320 A site represents a connection of a customer office to one or more
1321 VPN services. Each site is associated with one or more location.
1323 +-------------+
1324 / \
1325 +-----| VPN1 |
1326 +------------------+ | \ /
1327 | | | +-------------+
1328 | New York Office |------ (site) -----+
1329 | | | +-------------+
1330 +------------------+ | / \
1331 +-----| VPN2 |
1332 \ /
1333 +-------------+
1335 The "site" container is used for the provider to store information of
1336 detailed implementation arrangements made with either the customer or
1337 with peer operators at each inter-connect location.
1339 We restrict the L2SM to exterior interfaces only, so all internal
1340 interfaces and the underlying topology are outside the scope of L2SM.
1342 Typically, the following characteristics of a site interface handoff
1343 need to be documented as part of the service design:
1345 Unique identifier (site-id): An arbitrary string to uniquely
1346 identify the site within the overall network infrastructure. The
1347 format of site-id is determined by the local administration of the
1348 VPN service.
1350 Device (device): The customer can request one or more customer
1351 premise equipments from the service provider for a particular
1352 site.
1354 Management (management): Defines the model of management for the
1355 site, for example: type, management-transport, address.
1357 Location (location): The site location information to allow easy
1358 retrieval of data about which are the nearest available resources.
1360 Site diversity (site-diversity): Presents some parameters to support
1361 site diversity.
1363 Site Network Accesses (site-network-accesses): Defines the list of
1364 ports to the site and their properties: especially bearer,
1365 connection, and service parameters.
1367 A site-network-access represents an Ethernet logical connection to a
1368 site. A site may have multiple site-network-accesses.
1370 +------------------+ Site
1371 | |-----------------------------------
1372 | |****** (site-network-access#1) ******
1373 | New York Office |
1374 | |****** (site-network-access#2) ******
1375 | |-----------------------------------
1376 +------------------+
1378 Multiple site-network-accesses are used, for instance, in the case of
1379 multihoming. Some other meshing cases may also include multiple
1380 site-network-accesses.
1382 The site configuration is viewed as a global entity; we assume that
1383 it is mostly the management system's role to split the parameters
1384 between the different elements within the network. For example, in
1385 the case of the site-network-access configuration, the management
1386 system needs to split the parameters between the PE configuration and
1387 the CE configuration.
1389 5.3.1. Devices and Locations
1391 The information in the "location" sub-container under a "site" and in
1392 the "device" container allows easy retrieval of data about which are
1393 the nearest available facilities and can be used for access topology
1394 planning. It may also be used by other network orchestration
1395 components to choose the targeted upstream PE and downstream CE.
1396 Location is expressed in terms of postal information.
1398 A site may be composed of multiple locations. All the locations will
1399 need to be configured as part of the "locations" container and list.
1400 A typical example of a multi-location site is a headquarters office
1401 in a city composed of multiple buildings. Those buildings may be
1402 located in different parts of the city and may be linked by intra-
1403 city fibers (a customer metropolitan area network). In such a case,
1404 when connecting to a VPN service, the customer may ask for
1405 multihoming based on its distributed locations.
1407 New York Site
1408 +------------------+ Site
1409 | +--------------+ |-----------------------------------
1410 | | Manhattan | |****** (site-network-access#1) ******
1411 | +--------------+ |
1412 | +--------------+ |
1413 | | Brooklyn | |****** (site-network-access#2) ******
1414 | +--------------+ |-----------------------------------
1415 +------------------+
1417 A customer may also request the use of some premises equipment
1418 entities (CEs) from the SP via the "devices" container. Requesting a
1419 CE implies a provider-managed or co-managed model. A particular
1420 device must be ordered to a particular already-configured location.
1421 This would help the SP send the device to the appropriate postal
1422 address. In a multi-location site, a customer may, for example,
1423 request a CE for each location on the site where multihoming must be
1424 implemented. In the figure above, one device may be requested for
1425 the Manhattan location and one other for the Brooklyn location.
1427 By using devices and locations, the user can influence the
1428 multihoming scenario he wants to implement: single CE, dual CE, etc.
1430 5.3.2. Site Network Accesses
1432 The L2SM includes a set of essential physical interface properties
1433 and Ethernet layer characteristics in the "site-network-accesses"
1434 container. Some of these are critical implementation arrangements
1435 that require consent from both customer and provider.
1437 As mentioned earlier, a site may be multihomed. Each logical network
1438 access for a site is defined in the "site-network-accesses"
1439 container. The site-network-access parameter defines how the site is
1440 connected on the network and is split into three main classes of
1441 parameters:
1443 o bearer: defines requirements of the attachment (below Layer 2).
1445 o connection: defines Layer 2 protocol parameters of the attachment.
1447 o availability: defines the site's availability policy. The
1448 availability parameters are defined in Section 5.8.
1450 The site-network-access has a specific type (site-network-access-
1451 type). This document defines two types:
1453 o point-to-point: describes a point-to-point connection between the
1454 SP and the customer.
1456 o multipoint: describes a multipoint connection between the SP and
1457 the customer.
1459 This site-network-access type may have an impact on the parameters
1460 offered to the customer, e.g., an SP might not offer encryption for
1461 multipoint accesses. It is up to the provider to decide what
1462 parameters are supported for point-to-point and/or multipoint
1463 accesses. Multipoint accesses are out of scope for this document and
1464 some containers defined in the model may require extensions in order
1465 to work properly for multipoint accesses.
1467 5.3.2.1. Bearer
1469 The "bearer" container defines the requirements for the site
1470 attachment to the provider network that are below Layer 3.
1472 The bearer parameters will help to determine the access media to be
1473 used.
1475 5.3.2.2. Connection
1477 The "connection" container defines the layer 2 protocol parameters of
1478 the attachment (e.g.,vlan-id or circuit-id) and provides connectivity
1479 between customer Ethernet switches. Depending on the management
1480 mode, it refers to PE-CE-LAN segment addressing or to CE-to-customer-
1481 LAN segment addressing. In any case, it describes the responsibility
1482 boundary between the provider and the customer. For a customer-
1483 managed site, it refers to the PE-CE-LAN Segment connection. For a
1484 provider-managed site, it refers to the CE-to-LAN Segment connection.
1486 "encapsulation-type" allows the user to select between Ethernet
1487 encapsulation (port-based) or Ethernet VLAN encapsulation (VLAN-
1488 based). All of the allowed Ethernet interface types of service frame
1489 can be listed under "ether-inf-type", e.g., untagged interface,
1490 tagged interface, LAG interface.
1492 Corresponding to "ether-inf-type", the connection container also
1493 presents three sets of link attributes: untagged interface, tagged
1494 interface, or optional LAG interface attributes. These parameters
1495 are essential for the connection to establish properly between the
1496 customer and provider edge devices. The connection container also
1497 defines an L2CP attribute to allow control plane protocol interaction
1498 between the CE devices and PE device.
1500 5.3.2.2.1. Untagged Interface
1502 For each untagged interface (untagged-interface), there are basic
1503 configuration parameters like interface index and speed, interface
1504 MTU, auto-negotiation and flow-control settings, etc. In addition
1505 and based on mutual agreement, the customer and provider may decide
1506 to enable advanced features, such as LLDP, 802.3AH link OAM, MAC loop
1507 detection/prevention at a UNI. If Loop avoidance is required, the
1508 attribute "uni-loop-prevention" must be set to TRUE.
1510 5.3.2.2.2. Tagged Interface
1512 If the tagged service is enabled on a logical unit on the connection
1513 at the interface, "encapsulation-type" should be specified as the
1514 Ethernet VLAN ecapsulation (if VLAN-based) or VXLAN encapsulation,
1515 and "eth-inf-type" should be set to indicate a tagged interface.
1517 In addition, "tagged-interface-type" should be specified under
1518 "tagged-interface" container to determines how tagging needs to be
1519 done. The current model defines five ways to perform VLAN tagging:
1521 o priority-tagged: Service providers encapsulate and tag packets
1522 between CE and PE with the frame priority level.
1524 o dot1q-vlan-tagged: Service providers encapsulate packets between
1525 CE and PE with one or a set of customer VLAN IDs (C-VLANs)
1527 o qinq: service providers encapsulate packets that enter the
1528 service-provider network with multiple customer VLAN IDs (C-VLANs)
1529 and a single VLAN tag with a single service provider VLAN
1530 (S-VLAN).
1532 o qinany: service providers encapsulate packets that enter the
1533 service-provider network with unknown C-VLAN and a single VLAN tag
1534 with a single service provider VLAN (S-VLAN).
1536 o vxlan: service providers encapsulate packets that enter the
1537 service-provider network with VNI and peer list.
1539 The overall S-tag for the Ethernet circuit and C-tag-to-SVC mapping,
1540 if applicable, has been placed in the service container. For the
1541 qinq an qinany options, the S-tag under "qinq" and "qinany" should
1542 match the S-tag in the service container in most cases, however, vlan
1543 translation is required for the S-tag in certain deployment at the
1544 external facing interface or upstream PEs to "normalize" the outer
1545 VLAN tag to the service S-tag into the network and translate back to
1546 the site's S-tag in the opposite direction. One example of this is
1547 with a Layer 2 aggregation switch along the path: the S-tag for the
1548 SVC has been previously assigned to another service thus can not be
1549 used by this attachment circuit.
1551 5.3.2.2.3. LAG Interface
1553 Sometimes, the customer may require multiple physical links bundled
1554 together to form a single, logical, point-to-point LAG connection to
1555 the service provider. Typically, LACP (Link Aggregation Control
1556 Protocol) is used to dynamically manage adding or deleting member
1557 links of the aggregate group. In general, a LAG allows for increased
1558 service bandwidth beyond the speed of a single physical link while
1559 providing graceful degradation as failure occurs, thus increased
1560 availability.
1562 In the L2SM, there is a set of attributes under "LAG-interface"
1563 related to link aggregation functionality. The customer and provider
1564 first need to decide on whether LACP PDUs will be exchanged between
1565 the edge devices by specifying the "LACP-state" to "On" or "Off". If
1566 LACP is to be enabled, then both parties need to further specify
1567 whether it will be running in active or passive mode, plus the time
1568 interval and priority level of the LACP PDU. The customer and
1569 provider can also determine the minimum aggregate bandwidth for a LAG
1570 to be considered as a valid path by specifying the optional "mini-
1571 link" attribute. To enable fast detection of faulty links, micro-bfd
1572 runs independent UDP sessions to monitor the status of each member
1573 link. Customer and provider should agree the BFD hello interval and
1574 hold time.
1576 Each member link will be listed under the LAG interface with basic
1577 physical link properties. Certain attributes like flow-control,
1578 encapsulation type, allowed ingress Ethertype and LLDP settings are
1579 at the LAG level.
1581 5.3.2.2.4. CVLAN ID To SVC MAP
1583 When more than one service is multiplexed onto the same interface,
1584 ingress service frames are conditionally transmitted through one of
1585 the L2VPN services based upon pre-arranged customer VLAN-to-SVC
1586 mapping. Multiple customer VLANs can be bundled across the same SVC.
1587 The bundling type will determine how a group of CVLANs is bundled
1588 into one VPN service (i.e., VLAN-Bundling).
1590 "cvlan-id-to-svc-map", when applicable, contains the list of customer
1591 VLANs that are mapped to the same service. In most cases, this will
1592 be the VLAN access-list for the inner 802.1q tag (the C-tag).
1594 A VPN Service can be set to preserve the CE-VLAN ID and CE-VLAN CoS
1595 from source site to destination site. This is required when the
1596 customer wants to use the VLAN header information between its two
1597 sites. CE-VLAN ID Preservation and CE-VLAN CoS Preservation are
1598 applied on each site-network-access within sites. Preservation means
1599 that the value of CE-VLAN ID and/or CE-VLAN CoS at source site must
1600 be equal to the value at a destination site belonging to the same
1601 L2VPN Service.
1603 If All-to-One bundling is Enabled (i.e., bundling type is set to all-
1604 to-one bundling), then preservation applies to all Ingress service
1605 frames. If All-to-One bundling is Disabled, then preservation
1606 applies to tagged Ingress service frames having the CE-VLAN ID.
1608 5.3.2.2.5. L2CP Control Support
1610 Customer and Service provider should pre-arrange whether to allow
1611 control plane protocol interaction between the CE devices and PE
1612 device. To provide seamless operation with multicast data transport,
1613 the transparent operation of Ethernet control protocols (e.g.,
1614 Spanning Tree Protocol [IEEE-802-1D]) can be employed by customers.
1616 To support efficient dynamic transport, Ethernet multicast control
1617 frames (e.g., GARP/GMRP [IEEE-802-1D]) can be used between CE and PE.
1618 However, solutions MUST NOT assume all CEs are always running such
1619 protocols (typically in the case where a CE is a router and is not
1620 aware of Layer-2 details).
1622 The destination MAC addresses of these L2CP PDUs fall within two
1623 reserved blocks specified by the IEEE 802.1 Working Group. Packet
1624 with destination MAC in these multicast ranges have special
1625 forwarding rules.
1627 o Bridge Block of Protocols: 01-80-C2-00-00-00 through
1628 01-80-C2-00-00-0F
1630 o MRP Block of Protocols: 01-80-C2-00-00-20 through
1631 01-80-C2-00-00-2F
1633 Layer 2 protocol tunneling allows service providers to pass
1634 subscriber Layer 2 control PDUs across the network without being
1635 interpreted and processed by intermediate network devices. These
1636 L2CP PDUs are transparently encapsulated across the MPLS-enabled core
1637 network in Q-in-Q fashion.
1639 The "L2CP-control" container contains the list of commonly used L2CP
1640 protocols and parameters. The service provider can specify DISCARD,
1641 PEER, or TUNNEL mode actions for each individual protocol.
1643 5.3.2.2.6. Ethernet Service OAM
1645 The advent of Ethernet as a wide-area network technology brings
1646 additional requirements of end-to-end service monitoring and fault
1647 management in the SP network, particularly in the area of service
1648 availability and Mean Time To Repair (MTTR). Ethernet Service OAM in
1649 the L2SM model refers to the combined protocol suites of IEEE 802.1ag
1650 ([IEEE-802-1ag]) and ITU-T Y.1731 ([ITU-T-Y-1731]).
1652 Generally speaking, Ethernet Service OAM enables service providers to
1653 perform service continuity check, fault-isolation, and packet delay/
1654 jitter measurement at per-customer and per-site network access
1655 granularity. The information collected from Ethernet Service OAM
1656 data sets is complementary to other higher layer IP/MPLS OSS tools to
1657 ensure the required service level agreements (SLAs) can be meet.
1659 The 802.1ag Connectivity Fault Management (CFM) functional model is
1660 structured with hierarchical maintenance domains (MDs), each assigned
1661 with a unique maintenance level. Higher level MDs can be nested over
1662 lower level MDs. However, the MDs cannot intersect. The scope of
1663 each MD can be solely within a customer network, solely within the SP
1664 network, interact between the customer-to-provider or provider-to-
1665 provider edge equipment, or tunnel over another SP network.
1667 Depending on the use case scenario, one or more maintenance end
1668 points (MEPs) can be placed on the external facing interface, sending
1669 CFM PDUs towards the core network (Up MEP) or downstream link (Down
1670 MEP).
1672 The "cfm-802.1-ag" sub-container under "site-network-access" presents
1673 the CFM maintenance association (MA): i.e., Down MEP for the UNI MA.
1674 For each MA, the user can define the maintenance domain ID (MAID),
1675 MEP level, MEP direction, remote MEP ID, CoS level of the CFM PDUs,
1676 Continuity Check Message (CCM) interval and hold time, alarm priority
1677 defect, CCM priority-type, etc.
1679 ITU-T Y.1731 Performance Monitoring (PM) provides essential network
1680 telemetry information that includes the measurement of Ethernet
1681 service frame delay, frame delay variation, frame loss, and frame
1682 throughput. The delay/jitter measurement can be either one-way or
1683 two-way. Typically, a Y.1731 PM probe sends a small amount of
1684 synthetic frames along with service frames to measure the SLA
1685 parameters.
1687 The "y-1731" sub-container under "site-network-access" contains a set
1688 of parameters to define the PM probe information, including MAID,
1689 local and remote MEP-ID, PM PDU type, message period and measurement
1690 interval, CoS level of the PM PDUs, loss measurement by synthetic or
1691 service frame options, one-way or two-way delay measurement, PM frame
1692 size, and session type.
1694 5.4. Site Role
1696 A VPN has a particular service topology, as described in
1697 Section 5.2.2. As a consequence, each site belonging to a VPN is
1698 assigned a particular role in this topology. The site-role leaf
1699 defines the role of the site in a particular VPN topology.
1701 In the any-to-any VPN service topology, all sites MUST have the same
1702 role, which will be "any-to-any-role".
1704 In the Hub-and-Spoke VPN service topology or the Hub-and-Spoke-
1705 Disjoint VPN service topology, sites MUST have a Hub role or a Spoke
1706 role.
1708 5.5. Site Belonging to Multiple VPNs
1710 5.5.1. Site VPN Flavor
1712 A site may be part of one or more VPNs. The "site-vpn-flavor"
1713 defines the way the VPN multiplexing is done. There are three
1714 possible types of external facing connections associated with an
1715 Ethernet VPN service and a site. Therefore the model supports three
1716 flavors:
1718 o site-vpn-flavor-single: The site belongs to only one VPN.
1720 o site-vpn-flavor-multi: The site belongs to multiple VPNs, and all
1721 the logical accesses of the sites belong to the same set of VPNs.
1723 o site-vpn-flavor-nni: The site represents an NNI where two
1724 administrative domains belonging to the same or different
1725 providers inter-connect.
1727 o site-vpn-flavor-e2e: The site represents an end-to-end multi-
1728 segment connection.
1730 5.5.1.1. Single VPN Attachment: site-vpn-flavor-single
1732 The figure below describes a single VPN attachment. The site
1733 connects to only one VPN.
1735 +--------+
1736 +------------------+ Site / \
1737 | |-----------------------------| |
1738 | |***(site-network-access#1)***| VPN1 |
1739 | New York Office | | |
1740 | |***(site-network-access#2)***| |
1741 | |-----------------------------| |
1742 +------------------+ \ /
1743 +--------+
1745 5.5.1.2. MultiVPN Attachment: site-vpn-flavor-multi
1747 The figure below describes a site connected to multiple VPNs.
1749 +---------+
1750 +---/----+ \
1751 +------------------+ Site / | \ |
1752 | |--------------------------------- | |VPN B|
1753 | |***(site-network-access#1)******* | | |
1754 | New York Office | | | | |
1755 | |***(site-network-access#2)******* \ | /
1756 | |-----------------------------| VPN A+-----|---+
1757 +------------------+ \ /
1758 +--------+
1760 In the example above, the New York office is multihomed. Both
1761 logical accesses are using the same VPN attachment rules, and both
1762 are connected to VPN A and to VPN B.
1764 Reaching VPN A or VPN B from the New York office will be done via
1765 destination-based routing. Having the same destination reachable
1766 from the two VPNs may cause routing problems. The customer
1767 administration's role in this case would be to ensure the appropriate
1768 mapping of its prefixes in each VPN.
1770 5.5.1.3. NNI: site-vpn-flavor-nni
1772 A Network-to-Network Interface (NNI) scenario may be modeled using
1773 the sites container. It is helpful for the SP to indicate that the
1774 requested VPN connection is not a regular site but rather is an NNI,
1775 as specific default device configuration parameters may be applied in
1776 the case of NNIs (e.g., ACLs, routing policies).
1778 SP A SP B
1779 ------------------- -------------------
1780 / \ / \
1781 | | | |
1782 | ++++++++ Inter-AS link ++++++++ |
1783 | + +_______________+ + |
1784 | + (MAC-VRF1)-(VPN1)-(MAC-VRF1)+ |
1785 | + + + + |
1786 | + ASBR + + ASBR + |
1787 | + + + + |
1788 | + (MAC-VRF2)-(VPN2)-(MAC-VRF2)+ |
1789 | + +_______________+ + |
1790 | ++++++++ ++++++++ |
1791 | | | |
1792 | | | |
1793 | | | |
1794 | ++++++++ Inter-AS link ++++++++ |
1795 | + +_______________+ + |
1796 | + (MAC-VRF1)-(VPN1)-(MAC-VRF1)+ |
1797 | + + + + |
1798 | + ASBR + + ASBR + |
1799 | + + + + |
1800 | + (MAC-VRF2)-(VPN2)-(MAC-VRF2)+ |
1801 | + +_______________+ + |
1802 | ++++++++ ++++++++ |
1803 | | | |
1804 | | | |
1805 \ / \ /
1806 ------------------- -------------------
1808 The figure above describes an option A NNI scenario that can be
1809 modeled using the sites container. In order to connect its customer
1810 VPNs (VPN1 and VPN2) in SP B, SP A may request the creation of some
1811 site-network-accesses to SP B. The site-vpn-flavor-nni will be used
1812 to inform SP B that this is an NNI and not a regular customer site.
1814 5.5.1.4. E2E: site-vpn-flavor-e2e
1816 A end to end multi-segment VPN connection to be constructed out of
1817 several connectivity segments may be modeled. It is helpful for the
1818 SP to indicate the requested VPN connection is not a regular site but
1819 rather is an end-to-end VPN connection, as specific default device
1820 configuration parameters may be applied in case of site-vpn-flavor-
1821 e2e (e.g., QoS configuration). In order to establish a connection
1822 between Site 1 in SP A and Site 2 in SP B spanning across multiple
1823 domains, SP A may request the creation of end-to-end connectivity to
1824 SP B. The site-vpn-flavor-e2e will be used to indicate that this is
1825 an end-to-end connectivity setup and not a regular customer site.
1827 5.5.2. Attaching a Site to a VPN
1829 Due to the multiple site-vpn flavors, the attachment of a site to an
1830 L2VPN is done at the site-network-access (logical access) level
1831 through the "vpn-attachment" container. The vpn-attachment container
1832 is mandatory. The model provides two ways to attach a site to a VPN:
1834 o By referencing the target VPN directly.
1836 o By referencing a VPN policy for attachments that are more complex.
1838 A choice is implemented to allow the user to choose the flavor that
1839 provides the best fit.
1841 5.5.2.1. Referencing a VPN
1843 Referencing a vpn-id provides an easy way to attach a particular
1844 logical access to a VPN. This is the best way in the case of a
1845 single VPN attachment. When referencing a vpn-id, the site-role
1846 setting must be added to express the role of the site in the target
1847 VPN service topology.
1849
1850
1851
1852
1853 VPNA
1854 true
1855 true
1856
1857
1858 VPNB
1859 true
1860 true
1861
1862
1863
1864
1865 SITE1
1866
1867
1868 L1
1869
1870
1871
1872 customer-managed
1873
1874
1875
1876 < network-access-id>LA1 network-access-id>
1877
1878
1879
1880 input-bw
1881 bw-per-cos
1882 450000000
1883 20000000
1884 1000000000
1885 200000000
1886
1887
1888
1889 bgp
1890
1891 1514
1892
1893
1894 VPNA
1895 spoke-role
1896
1897
1898
1899 < network-access-id>LA2 network-access-id>
1900
1901
1902
1903 input-bw
1904 bw-per-cos
1905 450000000
1906 20000000
1907 1000000000
1908 200000000
1909
1910
1911
1912 bgp
1913
1914 1514
1915
1916
1917 VPNB
1918 spoke-role
1919
1920
1921
1922
1924
1925
1927 The example above describes a multi-VPN case where a site (SITE1) has
1928 two logical accesses (LA1 and LA2), attached to both VPNA and VPNB.
1930 5.5.2.2. VPN Policy
1932 The "vpn-policy" list helps express a multi-VPN scenario where a
1933 logical access belongs to multiple VPNs.
1935 As a site can belong to multiple VPNs, the vpn-policy list may be
1936 composed of multiple entries. A filter can be applied to specify
1937 that only some LANs at the site should be part of a particular VPN.
1938 Each time a site (or LAN) is attached to a VPN, the user must
1939 precisely describe its role (site-role) within the target VPN service
1940 topology.
1942 +--------------------------------------------------------------+
1943 | Site1 ------ PE7 |
1944 +-------------------------+ [VPN2] |
1945 | |
1946 +-------------------------+ |
1947 | Site2 ------ PE3 PE4 ------ Site3 |
1948 +----------------------------------+ |
1949 | |
1950 +------------------------------------------------------------+ |
1951 | Site4 ------ PE5 | PE6 ------ Site5 | |
1952 | | |
1953 | [VPN3] | |
1954 +------------------------------------------------------------+ |
1955 | |
1956 +---------------------------+
1958 In the example above, Site5 is part of two VPNs: VPN3 and VPN2. It
1959 will play a Hub role in VPN2 and an any-to-any role in VPN3. We can
1960 express such a multi-VPN scenario as follows:
1962
1963
1964
1965
1966 VPN2
1967 true
1968 true
1969
1970
1971 VPN3
1972 true
1973 true
1974
1975
1976
1977
1978
1979
1980 L1
1981
1982
1983
1984 customer-managed
1985
1986 Site5
1987
1988
1989 POLICY1
1990
1991 ENTRY1
1992
1993 VPN2
1994 hub-role
1995
1996
1997
1998 ENTRY2
1999
2000 VPN3
2001 any-to-any-role
2002
2003
2004
2005
2006
2007
2008 < network-access-id>LA1 network-access-id>
2009
2010 SITE1
2011
2012
2013 L1
2014
2015
2016
2017 customer-managed
2018
2019
2020
2021 < network-access-id>LA1 network-access-id>
2022
2023
2024
2025 input-bw
2026 bw-per-cos
2027 450000000
2028 20000000
2029 1000000000
2030 200000000
2031
2032
2033
2034 bgp
2035
2036 1514
2037
2038
2039 VPNA
2040 spoke-role
2041
2042
2043
2044 < network-access-id>LA2 network-access-id>
2045
2046
2047
2048 input-bw
2049 bw-per-cos
2050 450000000
2051 20000000
2052 1000000000
2053 200000000
2054
2055
2056
2057 bgp
2058
2059 1514
2060
2061
2062 VPNB
2063 spoke-role
2064
2065
2066
2067
2068
2069 POLICY1
2070
2071
2072
2073
2074
2075
2077 Now, if a more-granular VPN attachment is necessary, filtering can be
2078 used. For example, if LAN1 from Site5 must be attached to VPN2 as a
2079 Hub and LAN2 must be attached to VPN3, the following configuration
2080 can be used:
2082
2083
2084
2085
2086 VPN2
2087 true
2088 true
2089
2090
2091 VPN3
2092 true
2093 true
2094
2095
2096
2097
2098
2099 L1
2100
2101
2102
2103 customer-managed
2104
2105 Site5
2106
2107
2108 POLICY1
2109
2110 ENTRY1
2111
2112
2113 lan
2114 LAN1
2115
2117
2118
2119 VPN2
2120 hub-role
2121
2122
2123
2124 ENTRY2
2125
2126
2127 lan
2128 LAN2
2129
2130
2131
2132 VPN3
2133 any-to-any-role
2134
2135
2136
2137
2138
2139
2140 < network-access-id>LA1 network-access-id>
2141
2142
2143
2144 input-bw
2145 bw-per-cos
2146 450000000
2147 20000000
2148 1000000000
2149 200000000
2150
2151
2152
2153 bgp
2154
2155 1514
2156
2157
2158 POLICY1
2159
2160
2161
2162
2163
2164
2166 5.6. Deciding Where to Connect the Site
2168 The management system will have to determine where to connect each
2169 site-network-access of a particular site to the provider network
2170 (e.g., PE or aggregation switch).
2172 This model defines parameters and constraints that can influence the
2173 meshing of the site-network-access.
2175 The management system MUST honor all customer constraints, or if a
2176 constraint is too strict and cannot be fulfilled, the management
2177 system MUST NOT provision the site and MUST provide information to
2178 the user about which constraints that could not be fulfilled. How
2179 the information is provided is out of scope for this document.
2180 Whether or not to relax the constraint would then be left up to the
2181 user.
2183 Parameters such as site location (see Section 5.6.2) and access type
2184 are just hints (see Section 5.6.3) for the management system for
2185 service placement.
2187 In addition to parameters and constraints, the management system's
2188 decision MAY be based on any other internal constraints that are left
2189 up to the SP, such as least load, distance, etc.
2191 5.6.1. Constraint: Device
2193 In the case of provider management or co-management, one or more
2194 devices have been ordered by the customer to a particular location
2195 that has already been configured. The customer may force a
2196 particular site- network-access to be connected on a particular
2197 device that he ordered.
2199 New York Site
2200 +------------------+ Site
2201 | +--------------+ |-----------------------------------
2202 | | Manhattan | |
2203 | | CE1********* (site-network-access#1) ******
2204 | +--------------+ |
2205 | +--------------+ |
2206 | | Brooklyn | |
2207 | | CE2********* (site-network-access#2) ******
2208 | +--------------+ |
2209 | |-----------------------------------
2210 +------------------+
2212 In the figure above, site-network-access#1 is associated with CE1 in
2213 the service request. The SP must ensure the provisioning of this
2214 connection.
2216 5.6.2. Constraint/Parameter: Site Location
2218 The location information provided in this model MAY be used by a
2219 management system to determine the target PE to mesh the site (SP
2220 side). A particular location must be associated with each site
2221 network access when configuring it. The SP MUST honor the
2222 termination of the access on the location associated with the site
2223 network access (customer side). The "country-code" in the site
2224 location should be expressed as an ISO ALPHA-2 code.
2226 The site-network-access location is determined by the "location-
2227 flavor". In the case of a provider-managed or co-managed site, the
2228 user is expected to configure a "device-reference" (device case) that
2229 will bind the site-network-access to a particular device that the
2230 customer ordered. As each device is already associated with a
2231 particular location, in such a case the location information is
2232 retrieved from the device location. In the case of a customer-
2233 managed site, the user is expected to configure a "location-
2234 reference" (location case); this provides a reference to an existing
2235 configured location and will help with placement.
2237 POP#1 (New York)
2238 +---------+
2239 | PE1 |
2240 Site #1 ---... | PE2 |
2241 (Atlantic City) | PE3 |
2242 +---------+
2244 POP#2 (Washington)
2245 +---------+
2246 | PE4 |
2247 | PE5 |
2248 | PE6 |
2249 +---------+
2251 POP#3 (Philadelphia)
2252 +---------+
2253 | PE7 |
2254 Site #2 CE#1---... | PE8 |
2255 (Reston) | PE9 |
2256 +---------+
2258 In the example above, Site #1 is a customer-managed site with a
2259 location L1, while Site #2 is a provider-managed site for which a CE
2260 (CE#1) was ordered. Site #2 is configured with L2 as its location.
2261 When configuring a site-network-access for Site #1, the user will
2262 need to reference location L1 so that the management system will know
2263 that the access will need to terminate on this location. Then, for
2264 distance reasons, this management system may mesh Site #1 on a PE in
2265 the Philadelphia POP. It may also take into account resources
2266 available on PEs to determine the exact target PE (e.g., least
2267 loaded). For Site #2, the user is expected to configure the site-
2268 network-access with a device-reference to CE#1 so that the management
2269 system will know that the access must terminate on the location of
2270 CE#1 and must be connected to CE#1. For placement of the SP side of
2271 the access connection, in the case of the nearest PE used, it may
2272 mesh Site #2 on the Washington POP.
2274 5.6.3. Constraint/Parameter: Access Type
2276 The management system needs to elect the access media to connect the
2277 site to the customer (for example, xDSL, leased line, Ethernet
2278 backhaul). The customer may provide some parameters/constraints that
2279 will provide hints to the management system.
2281 The bearer container information SHOULD be the first piece of
2282 information considered when making this decision:
2284 o The "requested-type" parameter provides information about the
2285 media type that the customer would like to use. If the "strict"
2286 leaf is equal to "true", this MUST be considered a strict
2287 constraint so that the management system cannot connect the site
2288 with another media type. If the "strict" leaf is equal to "false"
2289 (default) and if the requested media type cannot be fulfilled, the
2290 management system can select another media type. The supported
2291 media types SHOULD be communicated by the SP to the customer via a
2292 mechanism that is out of scope for this document.
2294 o The "always-on" leaf defines a strict constraint: if set to true,
2295 the management system MUST elect a media type that is "always-on"
2296 (e.g., this means no dial access type).
2298 o The "bearer-reference" parameter is used in cases where the
2299 customer has already ordered a network connection to the SP apart
2300 from the L2VPN site and wants to reuse this connection. The
2301 string used is an internal reference from the SP and describes the
2302 already-available connection. This is also a strict requirement
2303 that cannot be relaxed. How the reference is given to the
2304 customer is out of scope for this document, but as an example,
2305 when the customer ordered the bearer (through a process that is
2306 out of scope for this model), the SP may have provided the bearer
2307 reference that can be used for provisioning services on top.
2309 Any other internal parameters from the SP can also be used. The
2310 management system MAY use other parameters, such as the requested
2311 "svc-input-bandwidth" and "svc-output-bandwidth", to help decide
2312 which access type to use.
2314 5.6.4. Constraint: Access Diversity
2316 Each site-network-access may have one or more constraints that would
2317 drive the placement of the access. By default, the model assumes
2318 that there are no constraints, but allocation of a unique bearer per
2319 site-network-access is expected.
2321 In order to help with the different placement scenarios, a site-
2322 network-access may be tagged using one or multiple group identifiers.
2323 The group identifier is a string, so it can accommodate both explicit
2324 naming of a group of sites (e.g., "multihomed-set1") and the use of a
2325 numbered identifier (e.g., 12345678). The meaning of each group-id
2326 is local to each customer administrator, and the management system
2327 MUST ensure that different customers can use the same group-ids. One
2328 or more group-ids can also be defined at the site level; as a
2329 consequence, all site-network-accesses under the site MUST inherit
2330 the group-ids of the site they belong to. When, in addition to the
2331 site group-ids some group-ids are defined at the site-network-access
2332 level, the management system MUST consider the union of all groups
2333 (site level and site network access level) for this particular site-
2334 network-access.
2336 For an already-configured site-network-access, each constraint MUST
2337 be expressed against a targeted set of site-network-accesses. This
2338 site-network-access MUST never be taken into account in the targeted
2339 set -- for example, "My site-network-access S must not be connected
2340 on the same POP as the site-network-accesses that are part of Group
2341 10." The set of site-network-accesses against which the constraint
2342 is evaluated can be expressed as a list of groups, "all-other-
2343 accesses", or "all-other-groups". The all-other-accesses option
2344 means that the current site-network-access constraint MUST be
2345 evaluated against all the other site-network-accesses belonging to
2346 the current site. The all-other-groups option means that the
2347 constraint MUST be evaluated against all groups that the current
2348 site-network-access does not belong to.
2350 The current model defines multiple constraint-types:
2352 o pe-diverse: The current site-network-access MUST NOT be connected
2353 to the same PE as the targeted site-network-accesses.
2355 o pop-diverse: The current site-network-access MUST NOT be connected
2356 to the same POP as the targeted site-network-accesses.
2358 o linecard-diverse: The current site-network-access MUST NOT be
2359 connected to the same linecard as the targeted site-network-
2360 accesses.
2362 o bearer-diverse: The current site-network-access MUST NOT use
2363 common bearer components compared to bearers used by the targeted
2364 site-network-accesses. "bearer-diverse" provides some level of
2365 diversity at the access level. As an example, two bearer-diverse
2366 site-network-accesses must not use the same DSLAM, BAS, or Layer 2
2367 switch.
2369 o same-pe: The current site-network-access MUST be connected to the
2370 same PE as the targeted site-network-accesses.
2372 o same-bearer: The current site-network-access MUST be connected
2373 using the same bearer as the targeted site-network-accesses.
2375 These constraint-types can be extended through augmentation. Each
2376 constraint is expressed as "The site-network-access S must be
2377 (e.g., pe-diverse, pop-diverse) from these
2378 site-network-accesses."
2380 The group-id used to target some site-network-accesses may be the
2381 same as the one used by the current site-network-access. This eases
2382 the configuration of scenarios where a group of site-network-access
2383 points has a constraint between the access points in the group.
2385 5.7. Route Distinguisher and Network Instance Allocation
2387 The route distinguisher (RD) is a critical parameter of BGP-based
2388 L2VPNs as described in [RFC4364] that provides the ability to
2389 distinguish common addressing plans in different VPNs. As for route
2390 targets (RTs), a management system is expected to allocate a MAC-VRF
2391 on the target PE and an RD for this MAC-VRF. This RD MUST be unique
2392 across all MAC-VRFs on the target PE.
2394 If a MAC-VRF already exists on the target PE and the MAC-VRF fulfills
2395 the connectivity constraints for the site, there is no need to
2396 recreate another MAC-VRF, and the site MAY be meshed within this
2397 existing MAC-VRF. How the management system checks that an existing
2398 MAC-VRF fulfills the connectivity constraints for a site is out of
2399 scope for this document.
2401 If no such MAC-VRF exists on the target PE, the management system has
2402 to initiate the creation of a new MAC-VRF on the target PE and has to
2403 allocate a new RD for this new MAC-VRF.
2405 The management system MAY apply a per-VPN or per-MAC-VRF allocation
2406 policy for the RD, depending on the SP's policy. In a per-VPN
2407 allocation policy, all MAC-VRFs (dispatched on multiple PEs) within a
2408 VPN will share the same RD value. In a per-MAC-VRF model, all MAC-
2409 VRF should always have a unique RD value. Some other allocation
2410 policies are also possible, and this document does not restrict the
2411 allocation policies to be used.
2413 The allocation of RDs MAY be done in the same way as RTs. The
2414 examples provided in Section 5.2.2.1 could be reused in this
2415 scenario.
2417 Note that an SP MAY configure a target PE for an automated allocation
2418 of RDs. In this case, there will be no need for any backend system
2419 to allocate an RD value.
2421 5.8. Site Network Access Availability
2423 A site may be multihomed, meaning that it has multiple site-network-
2424 access points. Placement constraints defined in previous sections
2425 will help ensure physical diversity.
2427 When the site-network-accesses are placed on the network, a customer
2428 may want to use a particular routing policy on those accesses. The
2429 "site-network-access/availability" container defines parameters for
2430 site redundancy. The "access-priority" leaf defines a preference for
2431 a particular access. This preference is used to model load-balancing
2432 or primary/backup scenarios. The higher the access-priority value,
2433 the higher the preference will be. The "redundancy mode" attribute
2434 is defined for an multi-homing site and used to model single-active
2435 and active/active scenarios. It allows for multiple active paths in
2436 forwarding state and for load-balancing options.
2438 The figure below describes how the access-priority attribute can be
2439 used.
2441 Hub#1 LAN (Primary/backup) Hub#2 LAN (Load-sharing)
2442 | |
2443 | access-priority 1 access-priority 1 |
2444 |--- CE1 ------- PE1 PE3 --------- CE3 --- |
2445 | |
2446 | |
2447 |--- CE2 ------- PE2 PE4 --------- CE4 --- |
2448 | access-priority 2 access-priority 1 |
2450 PE5
2451 |
2452 |
2453 |
2454 CE5
2455 |
2456 Spoke#1 site (Single-homed)
2458 In the figure above, Hub#2 requires load-sharing, so all the site-
2459 network-accesses must use the same access-priority value. On the
2460 other hand, as Hub#1 requires a primary site-network-access and a
2461 backup site-network-access, a higher access-priority setting will be
2462 configured on the primary site-network-access.
2464 Scenarios that are more complex can also be modeled. Let's consider
2465 a Hub site with five accesses to the network (A1, A2, A3, A4, and
2466 A5). The customer wants to load-share its traffic on A1 and A2 in
2467 the nominal situation. If A1 and A2 fail, the customer wants to
2468 load-share its traffic on A3 and A4; finally, if all of A1 to A4 are
2469 down, he wants to use A5. We can model this easily by configuring
2470 the following access-priority values: A1=100, A2=100, A3=50, A4=50,
2471 A5=10.
2473 The access-priority scenario has some limitations. An access-
2474 priority scenario like the previous one with five accesses but with
2475 the constraint of having traffic load-shared between A3 and A4 in the
2476 case where just one of A1 or A2 is down is not achievable. But the
2477 access-priority attribute defined will cover most of the deployment
2478 use cases, and if necessary the model can be extended via
2479 augmentation to support additional use cases.
2481 5.9. SVC MTU
2483 The maximum MTU of subscriber service frames can be derived from the
2484 physical interface MTU by default, or specified under the "svc-mtu"
2485 leaf if it is different than the default number.
2487 5.10. Service
2489 The "service" container defines service parameters associated with
2490 the site.
2492 5.10.1. Bandwidth
2494 The service bandwidth refers to the bandwidth requirement between CE
2495 and PE. The requested bandwidth is expressed as ingress bandwidth
2496 and egress bandwidth. Ingress/egress direction uses the customer
2497 site as the point of reference: Ingress direction bandwidth means
2498 download bandwidth for the site, and egresss bandwidth means upload
2499 bandwidth for the site.
2501 The service bandwidth is only configurable at the site-network-access
2502 level (i.e., for the site network access associated with the site).
2504 Using a different ingress and egress bandwidth will allow service
2505 provider to know if a customer allows for asymmetric bandwidth access
2506 like ADSL. It can also be used to set the rate limit in a different
2507 way for upload and download on symmetric bandwidth access.
2509 The svc-bandwidth has specific type. This document defines four
2510 types:
2512 o bw-per-access Bandwidth is per connection or site network access,
2513 providing rate enforcement for all service frames at the interface
2514 that are associated with a particular network access.
2516 o bw-per-cos Bandwidth is per cos, providing rate enforcement for
2517 all service frames for a given class of service with specific cos-
2518 id.
2520 o bw-per-svc bandwidth is per site, providing rate enforcement for
2521 all service frames that are associated with a particular VPN
2522 service.
2524 o opaque bandwidth is the total bandwidth that is not associated
2525 with any particular cos-id, vpn service identified with the vpn-
2526 id, or site network access id.
2528 The svc-bandwidth must include a "cos-id" parameter if the 'type' is
2529 set as 'bw-per-cos'. The cos-id can be assigned based on the dot1p
2530 value in the C-tag, or on the DSCP in the Ethernet Frame header.
2531 Service frames are metered against the bandwidth profile based on the
2532 cos-identifier.
2534 The svc-bandwidth must be associated with a specific "site-network-
2535 access- id" parameter if the 'type' is set as 'bw-per-access'.
2536 Multiple bandwidths per cos-id can be associated with the same Site
2537 Network access.
2539 The svc-bandwidth must include a specific "vpn-id" parameter if the
2540 'type' is set as 'bw-per-svc'. Multiple bandwidths per cos-id can be
2541 associated with the same Ethernet VPN service.
2543 5.10.2. QoS
2545 The model defines QoS parameters as an abstraction:
2547 o qos-classification-policy: Defines a set of ordered rules to
2548 classify customer traffic.
2550 o qos-profile: Provides a QoS scheduling profile to be applied.
2552 5.10.2.1. QoS Classification
2554 QoS classification rules are handled by qos-classification-policy.
2555 The qos-classification-policy is an ordered list of rules that match
2556 a flow or application and set the appropriate target class of service
2557 (target-class-id). The user can define the match using a more
2558 specific flow definition (based on layer 2 source and destination MAC
2559 addresses, cos, dscp, cos-id, color-id, etc.). A "color-id" will be
2560 assigned to a service frame to identify its QoS profile conformance.
2561 A service frame is "green" if it is conformant with the "committed"
2562 rate of the bandwidth profile. A Service Frame is "yellow" if it is
2563 exceeding the "committed" rate, but conformant with the "excess" rate
2564 of the bandwidth profile. Finally, a service frame is "red" if it is
2565 conformant with neither the "committed" nor "excess" rates of the
2566 bandwidth profile.
2568 When a flow definition is used, the user can use a target-sites leaf-
2569 list to identify the destination of a flow rather than using
2570 destination addresses. In such a case, an association between the
2571 site abstraction and the MAC addresses used by this site must be done
2572 dynamically. How this association is done is out of scope for this
2573 document. The association of a site to an L2VPN is done through the
2574 "vpn-attachment" container. Therefore, the user can also employ the
2575 "target-sites" leaf-list and "vpn-attachment" to identify the
2576 destination of a flow targeted to specific VPN service. A rule that
2577 does not have a match statement is considered as a match-all rule. A
2578 service provider may implement a default terminal classification rule
2579 if the customer does not provide it. It will be up to the service
2580 provider to determine its default target class. This model defines
2581 some applications, but new application identities may be added
2582 through augmentation. The exact meaning of each application identity
2583 is up to the SP, so it will be necessary for the SP to advise the
2584 customer on the usage of application matching.
2586 5.10.2.2. QoS Profile
2588 A user can choose between the standard profile provided by the
2589 operator or a custom profile. The qos-profile defines the traffic
2590 scheduling policy to be used by the service provider.
2592 A custom qos-profile is defined as a list of class of services and
2593 associated properties. The properties are:
2595 o direction: Used to specify the direction to which the qos-profile
2596 is applied. This model supports "Site-to-WAN" direction, "WAN-to-
2597 Site" direction, and "both" directions. By default, "both"
2598 directions is used. In case of "both" directions, the provider
2599 should ensure scheduling according to the requested policy in both
2600 traffic directions (SP to customer, and customer to SP). As an
2601 example, a device-scheduling policy may be implemented on both the
2602 PE side and the CE side of the WAN link. In case of "WAN-to-Site"
2603 direction, the provider should ensure scheduling from the SP
2604 network to the customer site. As an example, a device- scheduling
2605 policy may be implemented only on the PE side of the WAN link
2606 towards the customer.
2608 o policing: The optional "policing" indicates whether policing
2609 should apply to one-rate two-colors or to two-rates three-colors.
2611 o byte-offset: The optional "byte-offset" indicates how many bytes
2612 in the service frame header are excluded from rate enforcement.
2614 o frame-delay: Used to define the latency constraint of the class.
2615 The latency constraint can be expressed as the lowest possible
2616 latency, or as a latency boundary expressed in milliseconds. How
2617 this latency constraint will be fulfilled is up to the service
2618 provider implementation: a strict priority queueing mechanism may
2619 be used on the access and in the core network, or a low latency
2620 routing path may be created for this traffic class.
2622 o frame-jitter: Used to define the jitter constraint of the class.
2623 The jitter constraint can be expressed as the lowest possible
2624 jitter, or as a jitter boundary expressed in microseconds. How
2625 this jitter constraint will be fulfilled is up to the service
2626 provider implementation: a strict priority queueing mechanism may
2627 be used on the access and in the core network, or a jitter-aware
2628 routing path may be created for this traffic class.
2630 o bandwidth: used to define a guaranteed amount of bandwidth for the
2631 class of service. It is expressed as a percentage. The
2632 "guaranteed-bw-percent" parameter uses available bandwidth as a
2633 reference. The available bandwidth should not fall below the
2634 Committed Information Rate (CIR) defined under svc-input-bandwidth
2635 or svc-output-bandwidth. When the qos-profile container is
2636 implemented on the CE side, svc-output-bandwidth is taken into
2637 account as a reference. When it is implemented on the PE side,
2638 svc-input-bandwidth is used. By default, the bandwidth
2639 reservation is only guaranteed at the access level. The user can
2640 use the "end-to-end" leaf to request an end-to-end bandwidth
2641 reservation, including across the MPLS transport network. (In
2642 other words, the SP will activate something in the MPLS core to
2643 ensure that the bandwidth request from the customer will be
2644 fulfilled by the MPLS core as well.) How this is done (e.g.,
2645 RSVP-TE reservation, controller reservation) is out of scope for
2646 this document.
2648 In addition, due to network conditions, some constraints may not be
2649 completely fulfilled by the SP; in this case, the SP should advise
2650 the customer about the limitations. How this communication is done
2651 is out of scope for this document.
2653 5.10.3. Broadcast Multicast Unknow Unicast Support
2655 The "broadcast-unknowunicast-multicast" container defines the type of
2656 site in the customer multicast service topology: source, receiver, or
2657 both. These parameters will help the management system optimize the
2658 multicast service.
2660 Multiple multicast group-to-port mappings can be created using the
2661 "multicast-gp-address-mapping" list. The "multicast-gp-address-
2662 mapping" defines multicast group address and port LAG number. Those
2663 parameters will help the SP select the appropriate association
2664 between interface and multicast group to fulfill the customer service
2665 requirement.
2667 The whole Layer-2 multicast frame (whether for data or control)
2668 SHOULD NOT be altered from CE to CEs except that the VLAN ID field
2669 may be modified, ensuring that it is transparently transported. If
2670 VLAN IDs are assigned by the SP, they can also be altered.
2672 For point-to-point services, the provider only needs to deliver a
2673 single copy of each service frame to the remote PE, regardless
2674 whether the destination MAC address of the incoming frame is unicast,
2675 multicast or broadcast. Therefore, all service frames should be
2676 delivered unconditionally.
2678 B-U-M (Broadcast-UnknownUnicast-Multicast) frame forwarding in
2679 multipoint-to-multipoint services, on the other hand, involves both
2680 local flooding to other attachment circuits on the same PE and remote
2681 replication to all other PEs, thus consumes additional resources and
2682 core bandwidth. Special B-U-M frame disposition rules can be
2683 implemented at external facing interfaces (UNI or E-NNI) to rate-
2684 limit the B-U-M frames, in term of number of packets per second or
2685 bits per second.
2687 The threshold can apply to all B-U-M traffic, or one for each
2688 category.
2690 5.11. Site Management
2692 The "management" sub-container is intended for site management
2693 options, depending on the device ownership and security access
2694 control. The followings are three common management models:
2696 CE Provider Managed: The provider has the sole ownership of the CE
2697 device. Only the provider has access to the CE. The
2698 responsibility boundary between SP and customer is between CE and
2699 customer network. This is the most common use case.
2701 CE Customer Managed: The customer has the sole ownership of the CE
2702 device. Only the customer has access to the CE. In this model,
2703 the responsibility boundary between SP and customer is between PE
2704 and CE.
2706 CE Co-managed: The provider has ownership of the CE device and
2707 responsible for managing the CE. However, the provider grants the
2708 customer access to the CE for some configuration/monitoring
2709 purposes. In this co-managed mode, the responsibility boundary is
2710 the same as for the provider-managed model.
2712 The selected management mode is specified under the "type" leaf. The
2713 "address" leaf stores CE device management addressing information.
2714 And the "management-transport" leaf is used to identify the transport
2715 protocol for management traffic: IPv4 or IPv6. Additional security
2716 options may be derived based on the particular management model
2717 selected.
2719 5.12. MAC Loop Protection
2721 MAC address flapping between different physical ports typically
2722 indicates a bridge loop condition in the customer network.
2723 Misleading entries in the MAC cache table can cause service frames to
2724 circulate around the network indefinitely and saturate the links
2725 throughout the provider's network, affecting other services in the
2726 same network. In case of EVPN, it also introduces massive BGP
2727 updates and control plane instability.
2729 The service provider may opt to implement a switching loop prevention
2730 mechanism at the external facing interfaces for multipoint-to-
2731 multipoint services by imposing a MAC address move threshold.
2733 The MAC move rate and prevention-type options are listed in the "mac-
2734 loop-prevention" container.
2736 5.13. MAC Address Limit
2738 The optional "mac-address-limit" container contains the customer MAC
2739 address limit and information to describe the action when the limit
2740 is exceeded and the aging time for a MAC address.
2742 When multiple services are provided on the same network element, the
2743 MAC address table (and the Routing Information Base space for MAC-
2744 routes in the case of EVPN) is a shared common resource. Service
2745 providers may impose a maximum number of MAC addresses learned from
2746 the customer for a single service instance by using 'mac-limit'leaf,
2747 and may use 'action' leaf to specify the action when the upper limit
2748 is exceeded: drop the packet, flood the packet, or simply send a
2749 warning log message.
2751 For point-to-point services, if MAC learning is disabled then the MAC
2752 address limit is not necessary.
2754 5.14. Enhanced VPN Features
2756 5.14.1. Carriers' Carriers
2758 In the case of Carriers' Carrier (CsC) [RFC6624], a customer may want
2759 to build an MPLS service using an L2VPN to carry its traffic.
2761 LAN customer1
2762 |
2763 |
2764 CE1
2765 |
2766 | -------------
2767 (vrf_cust1)
2768 CE1_ISP1
2769 | ISP1 POP
2770 | MPLS link
2771 | -------------
2772 |
2773 (vrf ISP1)
2774 PE1
2776 (...) Provider backbone
2778 PE2
2779 (vrf ISP1)
2780 |
2781 | ------------
2782 |
2783 | MPLS link
2784 | ISP1 POP
2785 CE2_ISP1
2786 (vrf_cust1)
2787 | ------------
2788 |
2789 CE2
2790 |
2791 LAN customer1
2793 In the figure above, ISP1 resells an L2VPN service but has no core
2794 network infrastructure between its POPs. ISP1 uses an L2VPN as the
2795 core network infrastructure (belonging to another provider) between
2796 its POPs.
2798 In order to support CsC, the VPN service must indicate MPLS support
2799 by setting the "carrierscarrier" leaf to true in the vpn-service
2800 list. The link between CE1_ISP1/PE1 and CE2_ISP1/PE2 must also run
2801 an MPLS signalling protocol. This configuration is done at the site
2802 level.
2804 In this model, LDP or BGP can be used as the MPLS signalling
2805 protocol. In the case of LDP, an IGP routing protocol MUST also be
2806 activated. In the case of BGP signalling, BGP MUST also be
2807 configured as the routing protocol.
2809 If CsC is enabled, the requested "svc-mtu" leaf will refer to the
2810 MPLS MTU and not to the link MTU.
2812 5.15. External ID References
2814 The service model sometimes refers to external information through
2815 identifiers. As an example, to order cloud-access to a particular
2816 cloud service provider (CSP), the model uses an identifier to refer
2817 to the targeted CSP. If a customer is directly using this service
2818 model as an API (through REST or NETCONF, for example) to order a
2819 particular service, the SP should provide a list of authorized
2820 identifiers. In the case of cloud-access, the SP will provide the
2821 associated identifiers for each available CSP. The same applies to
2822 other identifiers, such as std-qos-profile.
2824 How an SP provides the meanings of those identifiers to the customer
2825 is out of scope for this document.
2827 5.16. Defining NNIs and Inter-AS support
2829 An autonomous system (AS) is a single network or group of networks
2830 that is controlled by a common system administration group and that
2831 uses a single, clearly defined routing protocol. In some cases, VPNs
2832 need to span different ASes in different geographic areas or span
2833 different SPs. The connection between ASes is established by the SPs
2834 and is seamless to the customer. Examples include:
2836 o A partnership between SPs (e.g., carrier, cloud) to extend their
2837 VPN services seamlessly.
2839 o An internal administrative boundary within a single SP (e.g.,
2840 backhaul versus core versus data center).
2842 NNIs have to be defined to extend the VPNs across multiple ASes.
2843 [RFC4761] defines multiple flavors of VPN NNI implementation. Each
2844 implementation has pros and cons; this topic is outside the scope of
2845 this document. For example, in an Inter-AS option A, autonomous
2846 system border router (ASBR) peers are connected by multiple
2847 interfaces with at least one of those interfaces spanning the two
2848 ASes while being present in the same VPN. In order for these ASBRs
2849 to signal label blocks, they associate each interface with a Virtual
2850 Switching (MAC-VRF) instance and a BGP session. As a result, traffic
2851 between the back-to-back VPLS is Ethernet. In this scenario, the
2852 VPNs are isolated from each other, and because the traffic is
2853 Ethernet, QoS mechanisms that operate on Ethernet traffic can be
2854 applied to achieve customer service level agreements (SLAs).
2856 -------- -------------- -----------
2857 / \ / \ / \
2858 | Cloud | | | | |
2859 | Provider |-----NNI-----| |----NNI---| Data Center |
2860 | #1 | | | | |
2861 \ / | | \ /
2862 -------- | | -----------
2863 | |
2864 -------- | My network | -----------
2865 / \ | | / \
2866 | Cloud | | | | |
2867 | Provider |-----NNI-----| |---NNI---| L2VPN |
2868 | #2 | | | | Partner |
2869 \ / | | | |
2870 -------- | | | |
2871 \ / | |
2872 -------------- \ /
2873 | -----------
2874 |
2875 NNI
2876 |
2877 |
2878 -------------------
2879 / \
2880 | |
2881 | |
2882 | |
2883 | L2VPN Partner |
2884 | |
2885 \ /
2886 -------------------
2888 The figure above describes an SP network called "My network" that has
2889 several NNIs. This network uses NNIs to:
2891 o increase its footprint by relying on L2VPN partners.
2893 o connect its own data center services to the customer L2VPN.
2895 o enable the customer to access its private resources located in a
2896 private cloud owned by some CSPs.
2898 5.16.1. Defining an NNI with the Option A Flavor
2899 AS A AS B
2900 ------------------- -------------------
2901 / \ / \
2902 | | | |
2903 | ++++++++ Inter-AS link +++++++++ |
2904 | + +_______________+ + |
2905 | +(MAC-VRF1)--(VPN1)--(MAC-VRF1)+ |
2906 | + + + + |
2907 | + ASBR + + ASBR + |
2908 | + + + + |
2909 | +(MAC-VRF2)--(VPN2)--(MAC-VRF2)+ |
2910 | + +_______________+ + |
2911 | ++++++++ +++++++++ |
2912 | | | |
2913 | | | |
2914 | | | |
2915 | ++++++++ Inter-AS link +++++++++ |
2916 | + +_______________+ + |
2917 | +(MAC-VRF1)--(VPN1)--(MAC-VRF1)+ |
2918 | + + + + |
2919 | + ASBR + + ASBR + |
2920 | + + + + |
2921 | +(MAC-VRF2)--(VPN2)--(MAC-VRF2)+ |
2922 | + +_______________+ + |
2923 | ++++++++ +++++++++ |
2924 | | | |
2925 | | | |
2926 \ / \ /
2927 ------------------- -------------------
2929 In option A, the two ASes are connected to each other with physical
2930 links on ASBRs. For resiliency purposes, there may be multiple
2931 physical connections between the ASes. A VPN connection -- physical
2932 or logical (on top of physical) -- is created for each VPN that needs
2933 to cross the AS boundary, thus providing a back-to-back VPLS model.
2935 From a service model's perspective, this VPN connection can be seen
2936 as a site. Let's say that AS B wants to extend some VPN connections
2937 for VPN C on AS A. The administrator of AS B can use this service
2938 model to order a site on AS A. All connection scenarios could be
2939 realized using the features of the current model. As an example, the
2940 figure above shows two physical connections that have logical
2941 connections per VPN overlaid on them. This could be seen as a multi-
2942 VPN scenario. Also, the administrator of AS B will be able to choose
2943 the appropriate routing protocol (e.g., E-BGP) to dynamically
2944 exchange routes between ASes.
2946 This document assumes that the option A NNI flavor SHOULD re-use the
2947 existing VPN site modeling.
2949 Example: a customer wants its CSP A to attach its virtual network N
2950 to an existing L2VPN (VPN1) that he has from L2VPN SP B.
2952 CSP A L2VPN SP B
2953 ----------------- -----------
2954 / \ / \
2955 | | | | |
2956 | VM --| ++++++++ NNI ++++++++++ |--- VPN1
2957 | | + +____________+ + | Site#1
2958 | |-------+(MAC-VRF1)-(VPN1)-(MAC-VRF1)+ |
2959 | | + + + + |
2960 | | + ASBR + + ASBR + |
2961 | | + +____________+ + |
2962 | | ++++++++ ++++++++++ |
2963 | VM --| | | |--- VPN1
2964 | |Virtual | | | Site#2
2965 | |Network | | |
2966 | VM --| | | |--- VPN1
2967 | | | | | Site#3
2968 \ / \ /
2969 ----------------- -----------
2970 |
2971 |
2972 VPN1
2973 Site#4
2975 To create the VPN connectivity, the CSP or the customer may use the
2976 L2VPN service model that SP B exposes. We could consider that, as
2977 the NNI is shared, the physical connection (bearer) between CSP A and
2978 SP B already exists. CSP A may request through a service model the
2979 creation of a new site with a single site-network-access (single-
2980 homing is used in the figure). As a placement constraint, CSP A may
2981 use the existing bearer reference it has from SP A to force the
2982 placement of the VPN NNI on the existing link. The XML below
2983 illustrates a possible configuration request to SP B:
2985
2986
2987
2988
2989
2990 GOLD
2991
2992
2993 PLATINUM
2995
2996
2997
2998
2999
3000 VPN1
3001 true
3002 true
3003
3004
3005
3006
3007 CSP_A_attachment
3008
3009
3010 NY1
3011 NY
3012 US
3013
3014
3015 site-vpn-flavor-nni
3016
3017
3018 < network-access-id>CSP_A_VN1 network-access-id>
3019
3020 vlan
3021 tagged
3022
3023 dot1q
3024
3025 17
3026
3027
3028
3029
3030
3031
3032 input-bw
3033 bw-per-cos
3034 450000000
3035 20000000
3036 1000000000
3037 200000000
3038
3039
3040
3041 bgp
3042
3044
3045
3046 12456487
3047 spoke-role
3048
3049
3050
3051
3052 customer-managed
3053
3054
3055
3056
3058 The case described above is different from a scenario using the
3059 cloud-accesses container, as the cloud-access provides a public cloud
3060 access while this example enables access to private resources located
3061 in a CSP network.
3063 5.16.2. Defining an NNI with the Option B Flavor
3065 AS A AS B
3066 ------------------- -------------------
3067 / \ / \
3068 | | | |
3069 | ++++++++ Inter-AS link ++++++++ |
3070 | + +_______________+ + |
3071 | + + + + |
3072 | + ASBR +<---MP-BGP---->+ ASBR + |
3073 | + + + + |
3074 | + +_______________+ + |
3075 | ++++++++ ++++++++ |
3076 | | | |
3077 | | | |
3078 | | | |
3079 | ++++++++ Inter-AS link ++++++++ |
3080 | + +_______________+ + |
3081 | + + + + |
3082 | + ASBR +<---MP-BGP---->+ ASBR + |
3083 | + + + + |
3084 | + +_______________+ + |
3085 | ++++++++ ++++++++ |
3086 | | | |
3087 | | | |
3088 \ / \ /
3089 ------------------- -------------------
3091 In option B, the two ASes are connected to each other with physical
3092 links on ASBRs. For resiliency purposes, there may be multiple
3093 physical connections between the ASes. The VPN "connection" between
3094 ASes is done by exchanging VPN routes through MP-BGP [RFC4761].
3096 There are multiple flavors of implementations of such an NNI. For
3097 example:
3099 1. The NNI is internal to the provider and is situated between a
3100 backbone and a data center. There is enough trust between the
3101 domains to not filter the VPN routes. So, all the VPN routes are
3102 exchanged. RT filtering may be implemented to save some
3103 unnecessary route states.
3105 2. The NNI is used between providers that agreed to exchange VPN
3106 routes for specific RTs only. Each provider is authorized to use
3107 the RT values from the other provider.
3109 3. The NNI is used between providers that agreed to exchange VPN
3110 routes for specific RTs only. Each provider has its own RT
3111 scheme. So, a customer spanning the two networks will have
3112 different RTs in each network for a particular VPN.
3114 Case 1 does not require any service modeling, as the protocol enables
3115 the dynamic exchange of necessary VPN routes.
3117 Case 2 requires that an RT-filtering policy on ASBRs be maintained.
3118 From a service modeling point of view, it is necessary to agree on
3119 the list of RTs to authorize.
3121 In Case 3, both ASes need to agree on the VPN RT to exchange, as well
3122 as how to map a VPN RT from AS A to the corresponding RT in AS B (and
3123 vice versa).
3125 Those modelings are currently out of scope for this document.
3127 CSP A L3VPN SP B
3129 ----------------- ------------------
3130 / \ / \
3131 | | | | |
3132 | VM --| ++++++++ NNI ++++++++ |--- VPN1
3133 | | + +__________+ + | Site#1
3134 | |-------+ + + + |
3135 | | + ASBR +<-MP-BGP->+ ASBR + |
3136 | | + +__________+ + |
3137 | | ++++++++ ++++++++ |
3138 | VM --| | | |--- VPN1
3139 | |Virtual | | | Site#2
3140 | |Network | | |
3141 | VM --| | | |--- VPN1
3142 | | | | | Site#3
3143 \ / | |
3144 ----------------- | |
3145 \ /
3146 ------------------
3147 |
3148 |
3149 VPN1
3150 Site#4
3152 The example above describes an NNI connection between CSP A and SP
3153 network B. The SPs do not trust each other and use different RT
3154 allocation policies. So, in terms of implementation, the customer
3155 VPN has a different RT in each network (RT A in CSP A and RT B in SP
3156 network B). In order to connect the customer's virtual network in
3157 CSP A to the customer's L2VPN (VPN1) in SP network B, CSP A should
3158 request that SP network B open the customer VPN on the NNI (accept
3159 the appropriate RT). Who does the RT translation depends on the
3160 agreement between the two SPs: SP B may permit CSP A to request VPN
3161 (RT) translation.
3163 5.16.3. Defining an NNI with the Option C Flavor
3164 AS A AS B
3165 ------------------- -------------------
3166 / \ / \
3167 | | | |
3168 | | | |
3169 | | | |
3170 | ++++++++ Multihop E-BGP ++++++++ |
3171 | + + + + |
3172 | + + + + |
3173 | + RGW +<----MP-BGP---->+ RGW + |
3174 | + + + + |
3175 | + + + + |
3176 | ++++++++ ++++++++ |
3177 | | | |
3178 | | | |
3179 | | | |
3180 | | | |
3181 | | | |
3182 | ++++++++ Inter-AS link ++++++++ |
3183 | + +_______________+ + |
3184 | + + + + |
3185 | + ASBR + + ASBR + |
3186 | + + + + |
3187 | + +_______________+ + |
3188 | ++++++++ ++++++++ |
3189 | | | |
3190 | | | |
3191 | | | |
3192 | ++++++++ Inter-AS link ++++++++ |
3193 | + +_______________+ + |
3194 | + + + + |
3195 | + ASBR + + ASBR + |
3196 | + + + + |
3197 | + +_______________+ + |
3198 | ++++++++ ++++++++ |
3199 | | | |
3200 | | | |
3201 \ / \ /
3202 ------------------- -------------------
3204 From a VPN service's perspective, the option C NNI is very similar to
3205 option B, as an MP-BGP session is used to exchange VPN routes between
3206 the ASes. The difference is that the forwarding plane and the
3207 control plane are on different nodes, so the MP-BGP session is
3208 multihop between routing gateway (RGW) nodes. From a VPN service's
3209 point of view, modeling options B and C will be identical.
3211 5.17. Applicability of L2SM model in Inter-Provider and Inter-Domain
3212 Orchestration
3214 In the case where the ASes belong to different providers, one might
3215 imagine that providers would like to have fewer signaling sessions
3216 crossing the AS boundary and that the entities that terminate the
3217 sessions could be restricted to a smaller set of devices. Two
3218 approaches can be taken:
3220 a. Inter-provider control connections to run only between the two
3221 border routers
3223 b. Allow an end-to-end, multi-segment connectivity to be constructed
3224 out of several connectivity segments, without maintaining an end-
3225 to-end control connection.
3227 Inter-provider control connection described in (a) can be realized
3228 using techniques of Section 5.15 (i.e., defining NNI). Multi-segment
3229 connectivity described in (b) can produce an inter-AS solution that
3230 more closely resembles option (b) in [RFC4364]. It may be realized
3231 using stitching of per-site connectivity and service segments at
3232 different domains, e.g., end-to-end connectivity between Site_1 and
3233 Site_3 spans multiple domains (e.g., Metro networks) and can be
3234 constructed by stitching network access connectivity within Site_1
3235 with SEG1, SEG3, SEG4 and network access connectivity within Site_3
3236 (as shown in the following figure). The assumption is that service
3237 the orchestration component in Figure 3 should have visibility of the
3238 complete abstract topology and resource availability. This may rely
3239 on network planning.
3241 Note that OVC can also be regarded as network access connectivity
3242 within a site and can be created as a normal site using L2SM service
3243 model.
3245 ---------- ---------- ----------
3246 | | | | | |
3247 +--+ +---+ +---+ +--+
3248 Site_1|PE|==SEG1==| |==SEG3==| |==SEG4==|PE|Site_3
3249 +--+ +---+ | | +--+
3250 | | | | | | ----------
3251 | | | | | | | |
3252 +--+ +---+ | | +---+ +--+
3253 Site_2|PE|==SEG2==| |==SEG5==| |==SEG6==| |==SEG7==|PE|Site_4
3254 +--+ +---+ +---+ +---+ +--+
3255 | | | | | | | |
3256 ---------- ---------- ---------- ----------
3258 In this figure, we use EBGP redistribution of L2VPN NLRIs from AS to
3259 neighboring AS. First, the PE routers use Internal BGP (IBGP) to
3260 redistribute L2VPN NLRIs either to an ASBR, or to a route reflector
3261 of which an ASBR is a client. The ASBR then uses EBGP to
3262 redistribute those L2VPN NLRI to an ASBR in another AS, which in turn
3263 distributes them to the PE routers in that AS, or perhaps to another
3264 ASBR which in turn distributes them, and so on.
3266 In this case, a PE can learn the address of an ASBR through which it
3267 could reach another PE to which it wishes to establish a
3268 connectivity. That is, a local PE will receive a BGP advertisement
3269 containing L2VPN NLRI corresponding to an L2VPN instance in which the
3270 local PE has some attached members. The BGP next-hop for that L2VPN
3271 NLRI will be an ASBR of the local AS. Then, rather than building a
3272 control connection all the way to the remote PE, it builds one only
3273 to the ASBR. A connectivity segment can now be established from the
3274 PE to the ASBR. The ASBR in turn can establish a connectivity to the
3275 ASBR of the next AS, and stitching that connectivity to the
3276 connectivity from the PE as described in [RFC6073]. Repeating the
3277 process at each ASBR leads to a sequence of connectivity segments
3278 that, when stitching together, connect the two PEs.
3280 Note that in the approach just described, the local PE may never
3281 learn the IP address of the remote PE. It learns the L2VPN NLRI
3282 advertised by the remote PE, which need not contain the remote PE
3283 address, and it learns the IP address of the ASBR that is the BGP
3284 next hop for that NLRI.
3286 When this approach is used for VPLS, or for full-mesh VPWS, it leads
3287 to a full mesh of connectivity among the PEs, but it does not require
3288 a full mesh of control connections (LDP or L2TPv3 sessions).
3289 Instead, the control connections within a single AS run among all the
3290 PEs of that AS and the ASBRs of the AS. A single control connection
3291 between the ASBRs of adjacent ASes can be used to support however
3292 many AS-to-AS connectivity segments are needed.
3294 6. Interaction with Other YANG Modules
3296 As expressed in Section 4, this service module is not intended to
3297 configure the network element, but is instantiated in a management
3298 system.
3300 The management system might follow modular design and comprise at
3301 least two different components:
3303 a. The component instantiating the service model (let's call it the
3304 service component)
3306 b. The component responsible for network element configuration
3307 (let's call it the configuration component)
3309 In some cases, when a split is needed between the behavior and
3310 functions that a customer requests and the technology that the
3311 network operator has available to deliver the service [RFC8309], a
3312 new component can be separated out of the service component (let's
3313 call it the control component). This component is responsible for
3314 network-centric operation and is aware of many features such as
3315 topology, technology, and operatorpolicy. As an optional component,
3316 it can use the service model as input and is not required at all if
3317 the control component delegates itscontrol operations to the
3318 configuration component.
3320 In Section 7 we provide some example of translation of service
3321 provisioning requests to router configuration lines as an
3322 illustration. In the NETCONF/YANG ecosystem, it is expected that
3323 NETCONF and YANG will be used between the configuration component and
3324 network elements to configure the requested service on those
3325 elements.
3327 In this framework, it is expected that YANG models will be used for
3328 configuring service components on network elements. There will be a
3329 strong relationship between the abstracted view provided by this
3330 service model and the detailed configuration view that will be
3331 provided by specific configuration models for network elements such
3332 as those defined in [I-D.ietf-bess-l2vpn-yang] and
3333 [I-D.ietf-bess-evpn-yang]. Service components needing configuration
3334 on network elements in support of the service model defined in this
3335 document include:
3337 o Network Instance definition including VPN policy expression.
3339 o Physical interface.
3341 o Ethernet layer (VLAN ID).
3343 o QoS: classification, profiles, etc.
3345 o Ethernet Service OAM Support.
3347 7. Service Model Usage Example
3349 As explained in Section 4, this service model is intended to be
3350 instantiated at a management layer and is not intended to be used
3351 directly on network elements. The management system serves as a
3352 central point of configuration of the overall service.
3354 This section provides an example on how a management system can use
3355 this model to configure an L2VPN service on network elements.
3357 The example is to provide a VPN service for 3 sites using point-to-
3358 point VPWS and a Hub and Spoke VPN service topology as shown in
3359 Figure 5. Loadbalancing is not considered in this case.
3361 Site1
3362 ............
3363 : : P2P VPWS
3364 :Spoke Site:-----PE1--------------------------+
3365 : : | Site3
3366 :..........: | ............
3367 | : :
3368 PE3-----: Hub Site :
3369 Site2 | : :
3370 ............ | :..........:
3371 : : P2P VPWS |
3372 :Spoke Site:-----PE2--------------------------+
3373 : :
3374 :..........:
3376 Figure 5: Reference Network for Simple Example
3378 The following XML describes the overall simplified service
3379 configuration of this VPN.
3381
3382
3383
3384
3385
3386 GOLD
3387
3388
3389 PLATINUM
3390
3391
3392
3393
3394
3395 12456487
3396 vpws
3397 hub-spoke
3398 true
3399 true
3400
3401
3402 12456488
3403 vpws
3404 hub-spoke
3405 true
3406 true
3407
3408
3409
3411 When receiving the request for provisioning the VPN service, the
3412 management system will internally (or through communication with
3413 another OSS component) allocates VPN route-targets. In this specific
3414 case two Route Targets (RTs) will be allocated (100:1 for Hubs and
3415 100:2 for Spokes). The output below describes the configuration of
3416 Spoke Site1.
3418
3419
3420
3421
3422
3423 GOLD
3424
3425
3426 PLATINUM
3427
3428
3430
3431
3432
3433 12456487
3434 hub-spoke
3435 true
3436 true
3437
3438
3439
3440
3441 Spoke_Site1
3442
3443
3444 NY1
3445 NY
3446 US
3447
3448
3449
3450
3451 Spoke_UNI-Site1
3452
3453
3454
3455 20
3456
3457
3458
3459
3460 vlan
3461
3462
3463 17
3464
3465
3466
3467 tunnel
3468 true
3469
3470
3471
3472
3473
3474 input-bw
3475 bw-per-cos
3476 450000000
3477 20000000
3478 1000000000
3479 200000000
3480
3481
3482
3483 bgp
3484
3485
3486
3487 12456487
3488 spoke-role
3489
3490
3491
3492
3493 provider-managed
3494
3495
3496
3497
3499 When receiving the request for provisioning the Spoke1 site, the
3500 management system MUST allocate network resources for this site. It
3501 MUST first determine the target network elements to provision the
3502 access, and especially the PE router (and may be an aggregation
3503 switch). As described in Section 5.3.1, the management system SHOULD
3504 use the location information and MUST use the access-diversity
3505 constraint to find the appropriate PE. In this case, we consider
3506 Spoke1 requires PE diversity with Hub and that management system
3507 allocate PEs based on lowest distance. Based on the location
3508 information, the management system finds the available PEs in the
3509 nearest area of the customer and picks one that fits the access-
3510 diversity constraint.
3512 When the PE is chosen, the management system needs to allocate
3513 interface resources on the node. One interface is selected from the
3514 PE available pool. The management system can start provisioning the
3515 PE node by using any mean (Netconf, CLI, ...). The management system
3516 will check if a VSI is already present that fits the needs. If not,
3517 it will provision the VSI: the Route Distinguisher will come from the
3518 internal allocation policy model, and the route-targets come from the
3519 vpn-policy configuration of the site (management system allocated
3520 some RTs for the VPN). As the site is a Spoke site (site-role), the
3521 management system knows which RT must be imported and exported. As
3522 the site is provider managed, some management route-targets may also
3523 be added (100:5000). Standard provider VPN policies MAY also be
3524 added in the configuration.
3526 Example of generated PE configuration:
3528 l2vpn vsi context one
3529 vpn id 12456487
3530 autodiscovery bgp signaling bgp
3531 ve id 1001 <----identify the PE routers within the VPLS domain
3532 ve range 50 <---- VE size
3533 route-distinguisher 100:3123234324
3534 route-target import 100:1
3535 route-target import 100:5000 <---- Standard SP configuration
3536 route-target export 100:2 for provider managed CE
3537 !
3539 When the VSI has been provisioned, the management system can start
3540 configuring the access on the PE using the allocated interface
3541 information. The tag or VLAN (e.g., service instance tag)is chosen
3542 by the management system. One tag will be picked from an allocated
3543 subnet for the PE, another will be used for the CE configuration.
3544 LACP protocols will also be configured between PE and CE and due to
3545 provider managed model, the choice is up to service provider. This
3546 choice is independent of the LACP protocol chosen by customer.
3548 Example of generated PE configuration:
3550 !
3551 bridge-domain 1
3552 member Ethernet0/0 service-instance 100
3553 member vsi one
3555 !
3556 l2 router-id 10.100.1.1
3557 !
3559 interface Ethernet0/0
3560 no ip address
3561 service instance 100 ethernet
3562 encapsulation dot1q 100
3563 !
3565 !
3566 router bgp 1
3567 bgp log-neighbor-changes
3568 neighbor 10.100.1.4 remote-as 1
3569 neighbor 10.100.1.4 update-source Loopback0
3570 !
3571 address-family l2vpn vpls
3572 neighbor 10.100.1.4 activate
3573 neighbor 10.100.1.4 send-community extended
3574 neighbor 10.100.1.4 suppress-signaling-protocol ldp
3575 exit-address-family
3577 !
3578 interface vlan 100 <-- Associating the Attachment
3579 no ip address Circuit with the MAC-VRF at the PE
3580 xconnect vsi PE1-VPLS-A
3581 !
3582 vlan 100
3583 state active
3585 As the CE router is not reachable at this stage, the management
3586 system can produce a complete CE configuration that can be uploaded
3587 to the node by manual operation before sending the CE to customer
3588 premise. The CE configuration will be built as for the PE. Based on
3589 the CE type (vendor/model) allocated to the customer and bearer
3590 information, the management system knows which interface must be
3591 configured on the CE. PE-CE link configuration is expected to be
3592 handled automatically using the service provider OSS as both
3593 resources are managed internally. CE to LAN interface parameters
3594 like dot1Q tag are derived from the ethernet-connection taking into
3595 account how management system distributes dot1Q tag between PE and CE
3596 within subnet. This will allow to produce a plug'n'play
3597 configuration for the CE.
3599 Example of generated CE configuration:
3601 interface Ethernet0/1
3602 switchport trunk allowed vlan none
3603 switchport mode trunk
3604 service instance 100 ethernet
3605 encapsulation default
3606 l2protocol forward cdp
3607 xconnect 1.1.1.1 100 encapsulation mpls
3608 !
3610 8. YANG Module
3612 file "ietf-l2vpn-svc@2018-02-05.yang"
3613 module ietf-l2vpn-svc {
3614 yang-version 1.1;
3615 namespace "urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc";
3616 prefix l2vpn-svc;
3618 import ietf-inet-types {
3619 prefix inet;
3620 }
3621 import ietf-yang-types {
3622 prefix yang;
3623 }
3624 import ietf-netconf-acm {
3625 prefix nacm;
3626 }
3628 organization
3629 "IETF L2SM Working Group.";
3630 contact
3631 "WG List: l2sm@ietf.org
3632 Editor: giuseppe.fioccola@telecomitalia.it";
3633 description
3634 "The YANG module defines a generic service configuration
3635 model for Layer 2 VPN services common across all of the
3636 vendor implementations.";
3638 revision 2018-02-05 {
3639 description
3640 "Initial revision -04 version";
3641 reference
3642 "draft-ietf-l2sm-l2vpn-service-model-05.txt
3643 A YANG Data Model for L2VPN Service Delivery.";
3644 }
3646 feature carrierscarrier {
3647 description
3648 "Enables support of CsC.";
3649 }
3651 feature ethernet-oam {
3652 description
3653 "Enables support of ethernet OAM.";
3654 }
3656 feature extranet-vpn {
3657 description
3658 "Enable the Support of Extranet VPN.";
3659 }
3661 feature l2cp-control {
3662 description
3663 "Enable the Support of L2CP control.";
3664 }
3666 feature input-bw {
3667 description
3668 "Enable the suppport of Input Bandwidth in a VPN.";
3669 }
3671 feature output-bw {
3672 description
3673 "Enable the support of Output Bandwidth in a VPN";
3674 }
3676 feature uni-list {
3677 description
3678 "Enable the support of UNI list in a VPN.";
3679 }
3681 feature cloud-access {
3682 description
3683 "Allow VPN to connect to a Cloud Service
3684 provider.";
3685 }
3687 feature oam-3ah {
3688 description
3689 "Enables the support of OAM 802.3ah.";
3690 }
3692 feature micro-bfd {
3693 description
3694 "Enables the support of Micro-BFD.";
3696 }
3698 feature bfd {
3699 description
3700 "Enables the support of BFD.";
3701 }
3703 feature signaling-options {
3704 description
3705 "Enable the support of signaling option.";
3706 }
3708 feature site-diversity {
3709 description
3710 "Enables the support of site diversity constraints in a VPN.";
3711 }
3713 feature encryption {
3714 description
3715 "Enables support of encryption.";
3716 }
3718 feature always-on {
3719 description
3720 "Enables support for always-on access
3721 constraint.";
3722 }
3724 feature requested-type {
3725 description
3726 "Enables support for requested-type access
3727 constraint.";
3728 }
3730 feature bearer-reference {
3731 description
3732 "Enables support for bearer-reference access
3733 constraint.";
3734 }
3736 feature qos {
3737 description
3738 "Enables support of Class of Services.";
3739 }
3741 feature qos-custom {
3742 description
3743 "Enables support of custom qos profile.";
3745 }
3747 feature lag-interface {
3748 description
3749 "Enable lag-interface.";
3750 }
3752 feature vlan {
3753 description
3754 "Enable the support of VLAN.";
3755 }
3757 feature dot1q {
3758 description
3759 "Enable the support of Dot1Q.";
3760 }
3762 feature sub-inf {
3763 description
3764 "Enable the support of Sub Interface.";
3765 }
3767 feature qinq {
3768 description
3769 "Enable the support of QinQ.";
3770 }
3772 feature qinany {
3773 description
3774 "Enable the support of QinAny.";
3775 }
3777 feature vxlan {
3778 description
3779 "Enable the support of VxLAN.";
3780 }
3782 feature lan-tag {
3783 description
3784 "Enables LAN Tag support in a VPN.";
3785 }
3787 feature target-sites {
3788 description
3789 "Enables support of the 'target-sites' match flow parameter.";
3790 }
3792 feature bum {
3793 description
3794 "Enables broadcast,unknown-unicast,multicast capabilities in a VPN.";
3795 }
3797 feature mac-loop-prevention {
3798 description
3799 " Enables MAC Loop prevention capability in a VPN. ";
3800 }
3802 feature lacp {
3803 description
3804 " Enables LACP capability in a VPN. ";
3805 }
3807 feature mac-addr-limit{
3808 description
3809 " Enables MAC Address Limit capability in a VPN. ";
3810 }
3812 feature acl {
3813 description
3814 "Enables ACL capability in a VPN. ";
3815 }
3817 feature cfm {
3818 description
3819 "Enables cfm 802.1 ag capability in a VPN.";
3820 }
3822 feature y-1731 {
3823 description
3824 "Enable Y.1731 capability in a VPN.";
3825 }
3827 typedef svc-id {
3828 type string;
3829 description
3830 "Defines a type of service component identifier.";
3831 }
3833 typedef ccm-priority-type {
3834 type uint8 {
3835 range "0..7";
3836 }
3837 description
3838 "A 3 bits priority value to be used in the VLAN tag,
3839 if present in the transmitted frame.";
3840 }
3841 typedef control-mode {
3842 type enumeration {
3843 enum "peer" {
3844 description
3845 "Peer mode, i.e., participate in the protocol towards the CE.
3846 Peering is common for LACP and E-LMI and occasionally
3847 for LLDP. For virtual private services the Subscriber
3848 can also request that the Service Provider peer
3849 spanning tree.";
3850 }
3851 enum "tunnel" {
3852 description
3853 "Tunnel mode,i.e.,pass to the egress or destination site.
3854 For EPL, the expectation is that L2CP frames are tunneled.";
3855 }
3856 enum "discard" {
3857 description
3858 "Discard mode,i.e.,discard the frame.";
3859 }
3860 }
3861 description
3862 "Defining a type of the control mode on L2CP protocols.";
3863 }
3865 typedef neg-mode {
3866 type enumeration {
3867 enum "full-duplex" {
3868 description
3869 "Defining Full duplex mode";
3870 }
3871 enum "auto-neg" {
3872 description
3873 "Defining Auto negotiation mode";
3874 }
3875 }
3876 description
3877 "Defining a type of the negotiation mode";
3878 }
3880 identity site-network-access-type {
3881 description
3882 "Base identity for site-network-access type.";
3883 }
3885 identity point-to-point {
3886 base site-network-access-type;
3887 description
3888 "Identity for point-to-point connection.";
3890 }
3892 identity multipoint {
3893 base site-network-access-type;
3894 description
3895 "Identity for multipoint connection.
3896 Example: Ethernet broadcast segment.";
3897 }
3899 identity tag-type {
3900 description
3901 "Base identity from which all tag types
3902 are derived from";
3903 }
3905 identity c-vlan {
3906 base tag-type;
3907 description
3908 "A Customer-VLAN tag, normally using the 0x8100
3909 Ethertype";
3910 }
3912 identity s-vlan {
3913 base tag-type;
3914 description
3915 "A Service-VLAN tag.";
3916 }
3918 identity c-s-vlan {
3919 base tag-type;
3920 description
3921 "Using both Customer-VLAN tag and Service-VLAN tag.";
3922 }
3924 identity multicast-tree-type {
3925 description
3926 "Base identity for multicast tree type.";
3927 }
3929 identity ssm-tree-type {
3930 base multicast-tree-type;
3931 description
3932 "Identity for SSM tree type.";
3933 }
3935 identity asm-tree-type {
3936 base multicast-tree-type;
3937 description
3938 "Identity for ASM tree type.";
3939 }
3941 identity bidir-tree-type {
3942 base multicast-tree-type;
3943 description
3944 "Identity for bidirectional tree type.";
3945 }
3947 identity mapping-type {
3948 description
3949 "Identity mapping-type";
3950 }
3952 identity static-mapping {
3953 base mapping-type;
3954 description
3955 "Identity for static mapping, i.e.,attach the interface
3956 to the Multicast group as static member";
3957 }
3959 identity dynamic-mapping {
3960 base mapping-type;
3961 description
3962 "Identity for dynamic mapping, i.e.,interface was added
3963 to the Multicast group as a result of snooping";
3964 }
3966 identity tf-type {
3967 description
3968 "Identity traffic-type";
3969 }
3971 identity multicast-traffic {
3972 base tf-type;
3973 description
3974 "Identity for multicast traffic";
3975 }
3977 identity broadcast-traffic {
3978 base tf-type;
3979 description
3980 "Identity for broadcast traffic";
3981 }
3983 identity unknown-unicast-traffic {
3984 base tf-type;
3985 description
3986 "Identity for unknown unicast traffic";
3987 }
3989 identity encapsulation-type {
3990 description
3991 "Identity for encapsulation type";
3992 }
3994 identity ethernet {
3995 base encapsulation-type;
3996 description
3997 "Identity for ethernet type";
3998 }
4000 identity vlan {
4001 base encapsulation-type;
4002 description
4003 "Identity for VLAN type";
4004 }
4006 identity carrierscarrier-type {
4007 description
4008 "Identity of carrierscarrier";
4009 }
4011 identity ldp {
4012 base carrierscarrier-type;
4013 description
4014 "Use LDP as the signalling protocol
4015 between the PE and the CE.";
4016 }
4018 identity bgp {
4019 base carrierscarrier-type;
4020 description
4021 "Use BGP (as per RFC 3107) as the signalling protocol
4022 between the PE and the CE.
4023 In this case, BGP must also be configured as
4024 the routing protocol.";
4025 }
4027 identity eth-inf-type {
4028 description
4029 "Identity of Ethernet Interface Type.";
4030 }
4032 identity tagged {
4033 base eth-inf-type;
4034 description
4035 "Identity of tagged Interface type.";
4036 }
4038 identity untagged {
4039 base eth-inf-type;
4040 description
4041 "Identity of untagged Interface type.";
4042 }
4044 identity lag {
4045 base eth-inf-type;
4046 description
4047 "Identity of LAG Interface type";
4048 }
4050 identity bw-type {
4051 description
4052 "Identity of bandwidth";
4053 }
4055 identity bw-per-cos {
4056 base bw-type;
4057 description
4058 "Bandwidth is per cos";
4059 }
4061 identity bw-per-port {
4062 base bw-type;
4063 description
4064 "Bandwidth is per site network access";
4065 }
4067 identity bw-per-site {
4068 base bw-type;
4069 description
4070 "Bandwidth is per site. It is applicable to
4071 all the site network accesses within the site.";
4072 }
4074 identity bw-per-svc {
4075 base bw-type;
4076 description
4077 "Bandwidth is per VPN service";
4078 }
4080 identity site-vpn-flavor {
4081 description
4082 "Base identity for the site VPN service flavor.";
4083 }
4085 identity site-vpn-flavor-single {
4086 base site-vpn-flavor;
4087 description
4088 "Identity for the site VPN service flavor.
4089 Used when the site belongs to only one VPN.";
4090 }
4092 identity site-vpn-flavor-multi {
4093 base site-vpn-flavor;
4094 description
4095 "Identity for the site VPN service flavor.
4096 Used when a logical connection of a site
4097 belongs to multiple VPNs.";
4098 }
4100 identity site-vpn-flavor-nni {
4101 base site-vpn-flavor;
4102 description
4103 "Identity for the site VPN service flavor.
4104 Used to describe an NNI option A connection.";
4105 }
4107 identity service-type {
4108 description
4109 "Base Identity of service type.";
4110 }
4112 identity vpws {
4113 base service-type;
4114 description
4115 "point-to-point Virtual Private Wire Services(VPWS) type.";
4116 }
4118 identity pwe3 {
4119 base service-type;
4120 description
4121 "Pseudo-Wire Emulation Edge to
4122 Edge(PWE3)Service type. .";
4123 }
4125 identity ldp-l2tp-vpls {
4126 base service-type;
4127 description
4128 "LDP based or L2TP based multipoint Virtual Private LAN
4129 services (VPLS) Service Type.This VPLS uses LDP-signaled
4130 Pseudowires or L2TP signaled Pseudowires.";
4131 }
4133 identity bgp-vpls {
4134 base service-type;
4135 description
4136 "BGP based multipoint Virtual Private LAN services (VPLS)
4137 Service Type. This VPLS uses a Border Gateway Protocol
4138 (BGP) control plane as described in RFC4761 and RFC6624.";
4139 }
4141 identity vpws-evpn {
4142 base service-type;
4143 description
4144 "VPWS Service Type using Ethernet VPN(EVPN) specified in RFC 7432.";
4145 }
4147 identity pbb-evpn {
4148 base service-type;
4149 description
4150 "PBB Service Type using Ethernet VPN(EVPN) specified in RFC 7432.";
4151 }
4153 identity bundling-type {
4154 description
4155 "This is base identity for Bundling type. It supports
4156 multiple CE-VLAN associated with L2VPN service or
4157 all CE-VLANs associated with L2VPN service.";
4158 }
4160 identity multi-svc-bundling {
4161 base bundling-type;
4162 description
4163 "Identity for multiple service bundling,i.e.,
4164 multiple CE-VLAN IDs can be associated with an
4165 L2VPN Service at site.";
4166 }
4168 identity one2one-bundling {
4169 base bundling-type;
4170 description
4171 "Identity for one to one service bundling,i.e.,
4172 Each L2VPN can be associated with only one CE-VLAN IDs
4173 at site.";
4174 }
4176 identity all2one-bundling {
4177 base bundling-type;
4178 description
4179 "Identity for all to one bundling,i.e.,all CE-VLAN IDs
4180 are mapped to one L2VPN Service";
4181 }
4183 identity color-id {
4184 description
4185 "base identity of color id";
4186 }
4188 identity color-id-cvlan {
4189 base color-id;
4190 description
4191 "Identity of color id base on CVLAN ";
4192 }
4194 identity cos-id {
4195 description
4196 "Identity of class of service id";
4197 }
4199 identity cos-id-pcp {
4200 base cos-id;
4201 description
4202 "Identity of cos id based on PCP";
4203 }
4205 identity cos-id-dscp {
4206 base cos-id;
4207 description
4208 "Identity of cos id based on DSCP";
4209 }
4211 identity color-type {
4212 description
4213 "Identity of color types";
4214 }
4216 identity green {
4217 base color-type;
4218 description
4219 "Identity of green type";
4220 }
4222 identity yellow {
4223 base color-type;
4224 description
4225 "Identity of yellow type";
4227 }
4229 identity red {
4230 base color-type;
4231 description
4232 "Identity of red type";
4233 }
4235 identity policing {
4236 description
4237 "Identity of policing type";
4238 }
4240 identity one-rate-two-color {
4241 base policing;
4242 description
4243 "Identity of one-rate, two-color (1R2C).";
4244 }
4246 identity two-rate-three-color {
4247 base policing;
4248 description
4249 "Identity of two-rate, three-color (2R3C).";
4250 }
4252 identity bum-type {
4253 description
4254 "Identity of BUM type.";
4255 }
4257 identity broadcast {
4258 base bum-type;
4259 description
4260 "Identity of broadcast.";
4261 }
4263 identity unicast {
4264 base bum-type;
4265 description
4266 "Identity of unicast";
4267 }
4269 identity multicast {
4270 base bum-type;
4271 description
4272 "Identity of multicast.";
4273 }
4274 identity loop-prevention-type {
4275 description
4276 "Identity of loop prevention.";
4277 }
4279 identity shut {
4280 base loop-prevention-type;
4281 description
4282 "Identity of shut protection.";
4283 }
4285 identity trap {
4286 base loop-prevention-type;
4287 description
4288 "Identity of trap protection.";
4289 }
4291 identity lacp-state {
4292 description
4293 "Identity of LACP state.";
4294 }
4296 identity lacp-on {
4297 base lacp-state;
4298 description
4299 "Identity of LCAP on.";
4300 }
4302 identity lacp-off {
4303 base lacp-state;
4304 description
4305 "Identity of LACP off";
4306 }
4308 identity lacp-mode {
4309 description
4310 "Identity of LACP mode";
4311 }
4313 identity lacp-passive {
4314 base lacp-mode;
4315 description
4316 "Identity of LACP passive";
4317 }
4319 identity lacp-active {
4320 base lacp-mode;
4321 description
4322 "Identity of LACP active";
4323 }
4325 identity lacp-speed {
4326 description
4327 "Identity of LACP speed";
4328 }
4330 identity lacp-fast {
4331 base lacp-speed;
4332 description
4333 "Identity of LACP fast";
4334 }
4336 identity lacp-slow {
4337 base lacp-speed;
4338 description
4339 "Identity of LACP slow";
4340 }
4342 identity bw-direction {
4343 description
4344 "Identity for bandwidth direction";
4345 }
4347 identity input-bw {
4348 base bw-direction;
4349 description
4350 "Identity for input bandwidth";
4351 }
4353 identity output-bw {
4354 base bw-direction;
4355 description
4356 "Identity for output bandwidth";
4357 }
4359 identity management {
4360 description
4361 "Base identity for site management scheme.";
4362 }
4364 identity co-managed {
4365 base management;
4366 description
4367 "Identity for co-managed site.";
4368 }
4369 identity customer-managed {
4370 base management;
4371 description
4372 "Identity for customer managed site.";
4373 }
4375 identity provider-managed {
4376 base management;
4377 description
4378 "Identity for provider managed site.";
4379 }
4381 identity address-family {
4382 description
4383 "Identity for an address family.";
4384 }
4386 identity ipv4 {
4387 base address-family;
4388 description
4389 "Identity for IPv4 address family.";
4390 }
4392 identity ipv6 {
4393 base address-family;
4394 description
4395 "Identity for IPv6 address family.";
4396 }
4398 identity vpn-topology {
4399 description
4400 "Base identity for VPN topology.";
4401 }
4403 identity any-to-any {
4404 base vpn-topology;
4405 description
4406 "Identity for any to any VPN topology.";
4407 }
4409 identity hub-spoke {
4410 base vpn-topology;
4411 description
4412 "Identity for Hub'n'Spoke VPN topology.";
4413 }
4415 identity hub-spoke-disjoint {
4416 base vpn-topology;
4417 description
4418 "Identity for Hub'n'Spoke VPN topology
4419 where Hubs cannot talk between each other.";
4420 }
4422 identity site-role {
4423 description
4424 "Base identity for site type.";
4425 }
4427 identity any-to-any-role {
4428 base site-role;
4429 description
4430 "Site in an any to any L2VPN.";
4431 }
4433 identity spoke-role {
4434 base site-role;
4435 description
4436 "Spoke Site in a Hub-and-Spoke L2VPN.";
4437 }
4439 identity hub-role {
4440 base site-role;
4441 description
4442 "Hub Site in a Hub-and-Spoke L2VPN.";
4443 }
4445 identity pm-type {
4446 description
4447 "Performance monitor type";
4448 }
4450 identity loss {
4451 base pm-type;
4452 description
4453 "Loss measurement";
4454 }
4456 identity delay {
4457 base pm-type;
4458 description
4459 "Delay measurement";
4460 }
4462 identity fault-alarm-defect-type {
4463 description
4464 "Indicating the alarm priority defect";
4466 }
4468 identity remote-rdi {
4469 base fault-alarm-defect-type;
4470 description
4471 "Indicates the aggregate health
4472 of the remote MEPs.";
4473 }
4475 identity remote-mac-error {
4476 base fault-alarm-defect-type;
4477 description
4478 "Indicates that one or more of the remote MEPs is
4479 reporting a failure in its Port Status TLV or
4480 Interface Status TLV.";
4481 }
4483 identity remote-invalid-ccm {
4484 base fault-alarm-defect-type;
4485 description
4486 "Indicates that at least one of the Remote MEP
4487 state machines is not receiving valid CCMs
4488 from its remote MEP.";
4489 }
4491 identity invalid-ccm {
4492 base fault-alarm-defect-type;
4493 description
4494 "Indicates that one or more invalid CCMs has been
4495 received and that 3.5 times that CCMs transmission
4496 interval has not yet expired.";
4497 }
4499 identity cross-connect-ccm {
4500 base fault-alarm-defect-type;
4501 description
4502 "Indicates that one or more cross connect CCMs has been
4503 received and that 3.5 times of at least one of those
4504 CCMs transmission interval has not yet expired.";
4505 }
4507 identity frame-delivery-mode {
4508 description
4509 "Delivery types";
4510 }
4512 identity discard {
4513 base frame-delivery-mode;
4514 description
4515 "Service Frames are discarded.";
4516 }
4518 identity unconditional {
4519 base frame-delivery-mode;
4520 description
4521 "Service Frames are unconditionally
4522 delivered to the destination.";
4523 }
4525 identity unknown-discard {
4526 base frame-delivery-mode;
4527 description
4528 "Service Frame are conditionally
4529 delivered to the destination site and
4530 the packet with unknown destination address
4531 will be discarded.";
4532 }
4534 identity placement-diversity {
4535 description
4536 "Base identity for site placement
4537 constraints.";
4538 }
4540 identity bearer-diverse {
4541 base placement-diversity;
4542 description
4543 "Identity for bearer diversity.
4544 The bearers should not use common elements.";
4545 }
4547 identity pe-diverse {
4548 base placement-diversity;
4549 description
4550 "Identity for PE diversity";
4551 }
4553 identity pop-diverse {
4554 base placement-diversity;
4555 description
4556 "Identity for POP diversity";
4557 }
4559 identity linecard-diverse {
4560 base placement-diversity;
4561 description
4562 "Identity for linecard diversity";
4563 }
4565 identity same-pe {
4566 base placement-diversity;
4567 description
4568 "Identity for having sites connected
4569 on the same PE";
4570 }
4572 identity same-bearer {
4573 base placement-diversity;
4574 description
4575 "Identity for having sites connected
4576 using the same bearer";
4577 }
4579 identity tagged-inf-type {
4580 description
4581 "Identity for the tagged
4582 interface type.";
4583 }
4585 identity priority-tagged {
4586 base tagged-inf-type;
4587 description
4588 "This identity the priority-tagged interface.";
4589 }
4591 identity qinq {
4592 base tagged-inf-type;
4593 description
4594 "Identity for the qinq tagged interface.";
4595 }
4597 identity dot1q {
4598 base tagged-inf-type;
4599 description
4600 "Identity for dot1q vlan tagged interface.";
4601 }
4603 identity qinany {
4604 base tagged-inf-type;
4605 description
4606 "Identity for qinany tagged inteface.";
4607 }
4609 identity vxlan {
4610 base tagged-inf-type;
4611 description
4612 "Identity for vxlan tagged inteface.";
4613 }
4615 identity provision-model {
4616 description
4617 "base identity for provision model.";
4618 }
4620 identity single-side-provision {
4621 description
4622 "Identity for single side provisioning with discovery.";
4623 }
4625 identity doubled-side-provision {
4626 description
4627 "Identity for double side provisioning.";
4628 }
4630 identity mac-learning-mode {
4631 description
4632 "MAC learning mode";
4633 }
4635 identity data-plane {
4636 base mac-learning-mode;
4637 description
4638 "User MAC addresses are learned through ARP broadcast.";
4639 }
4641 identity control-plane {
4642 base mac-learning-mode;
4643 description
4644 "User MAC addresses are advertised through EVPN-BGP";
4645 }
4647 identity vpn-policy-filter-type {
4648 description
4649 "Base identity for filter type.";
4650 }
4652 identity lan {
4653 base vpn-policy-filter-type;
4654 description
4655 "Identity for lan tag filter type.";
4656 }
4657 identity mac-action {
4658 description
4659 "Base identity for MAC action.";
4660 }
4662 identity drop {
4663 base mac-action;
4664 description
4665 "Identity for packet drop.";
4666 }
4668 identity flood {
4669 base mac-action;
4670 description
4671 "Identity for packet flooding.";
4672 }
4674 identity warning {
4675 base mac-action;
4676 description
4677 "Identity for sending a warning log message.";
4678 }
4680 identity load-balance-method {
4681 description
4682 "Base identity for load balance method.";
4683 }
4685 identity fat-pw {
4686 base load-balance-method;
4687 description
4688 "Identity for Fat PW. Fat label is
4689 applied to Pseudowires across MPLS
4690 network.";
4691 }
4693 identity entropy-label {
4694 base load-balance-method;
4695 description
4696 "Identity for entropy label.Entropy label
4697 is applied to IP forwarding,
4698 L2VPN or L3VPN across MPLS network";
4699 }
4701 identity vxlan-source-port {
4702 base load-balance-method;
4703 description
4704 "Identity for vxlan source port.VxLAN
4705 Source Port is one load balancing method.";
4706 }
4708 identity qos-profile-direction {
4709 description
4710 "Base identity for qos profile direction.";
4711 }
4713 identity site-to-wan {
4714 base qos-profile-direction;
4715 description
4716 "Identity for Site to WAN direction.";
4717 }
4719 identity wan-to-site {
4720 base qos-profile-direction;
4721 description
4722 "Identity for WAN to Site direction.";
4723 }
4725 identity bidirectional {
4726 base qos-profile-direction;
4727 description
4728 "Identity for both WAN to Site direction
4729 and Site to WAN direction.";
4730 }
4732 identity vxlan-peer-mode {
4733 description
4734 "Base identity for vxlan peer mode.";
4735 }
4737 identity static-mode {
4738 base vxlan-peer-mode;
4739 description
4740 "Identity for the vxlan access in static mode.";
4741 }
4743 identity bgp-mode {
4744 base vxlan-peer-mode;
4745 description
4746 "Identity for the vxlan access by bgp evpn learning.";
4747 }
4749 identity customer-application {
4750 description
4751 "Base identity for customer application.";
4752 }
4753 identity web {
4754 base customer-application;
4755 description
4756 "Identity for Web application (e.g., HTTP, HTTPS).";
4757 }
4759 identity mail {
4760 base customer-application;
4761 description
4762 "Identity for mail application.";
4763 }
4765 identity file-transfer {
4766 base customer-application;
4767 description
4768 "Identity for file transfer application (e.g., FTP, SFTP).";
4769 }
4771 identity database {
4772 base customer-application;
4773 description
4774 "Identity for database application.";
4775 }
4777 identity social {
4778 base customer-application;
4779 description
4780 "Identity for social-network application.";
4781 }
4783 identity games {
4784 base customer-application;
4785 description
4786 "Identity for gaming application.";
4787 }
4789 identity p2p {
4790 base customer-application;
4791 description
4792 "Identity for peer-to-peer application.";
4793 }
4795 identity network-management {
4796 base customer-application;
4797 description
4798 "Identity for management application
4799 (e.g., Telnet, syslog, SNMP).";
4800 }
4801 identity voice {
4802 base customer-application;
4803 description
4804 "Identity for voice application.";
4805 }
4807 identity video {
4808 base customer-application;
4809 description
4810 "Identity for video conference application.";
4811 }
4813 identity embb {
4814 base customer-application;
4815 description
4816 "Identity for enhanced Mobile Broadband(eMBB)
4817 application. Note that eMBB application demands
4818 the network performance with wide variety of
4819 characteristics such as data rate, latency,
4820 loss rate, reliability and many other parameters.";
4821 }
4823 identity urllc {
4824 base customer-application;
4825 description
4826 "Identity for Ultra-Reliable and Low Latency
4827 Communications (URLLC) application. Note that
4828 URLLC application demands the network performance
4829 with wide variety of characteristics such as latency,
4830 reliability and many other parameters.";
4831 }
4833 identity mmtc {
4834 base customer-application;
4835 description
4836 "Identity for massive Machine Type
4837 Communications (mMTC) application. Note that
4838 mMTC application demands the network performance
4839 with wide variety of characteristics such as data
4840 rate, latency, loss rate, reliability and many
4841 other parameters.";
4842 }
4844 grouping vpn-service-cloud-access {
4845 container cloud-accesses {
4846 if-feature cloud-access;
4847 list cloud-access {
4848 key "cloud-identifier";
4849 leaf cloud-identifier {
4850 type leafref {
4851 path "/l2vpn-svc/vpn-profiles/valid-provider-identifiers/cloud-identifier/id";
4852 }
4853 description
4854 "Identification of cloud service.
4855 Local administration meaning.";
4856 }
4857 choice list-flavor {
4858 case permit-any {
4859 leaf permit-any {
4860 type empty;
4861 description
4862 "Allow all sites.";
4863 }
4864 }
4865 case deny-any-except {
4866 leaf-list permit-site {
4867 type leafref {
4868 path "/l2vpn-svc/sites/site/site-id";
4869 }
4870 description
4871 "Site ID to be authorized.";
4872 }
4873 }
4874 case permit-any-except {
4875 leaf-list deny-site {
4876 type leafref {
4877 path "/l2vpn-svc/sites/site/site-id";
4878 }
4879 description
4880 "Site ID to be denied.";
4881 }
4882 }
4883 description
4884 "Choice for cloud access policy.
4885 By default, all sites in the L2VPN
4886 MUST be authorized to access the cloud.";
4887 }
4888 description
4889 "Cloud access configuration.";
4890 }
4891 description
4892 "Container for cloud access configurations";
4893 }
4894 description
4895 "Grouping for vpn cloud definition";
4896 }
4897 grouping site-vpn-flavor {
4898 leaf site-vpn-flavor {
4899 type identityref {
4900 base site-vpn-flavor;
4901 }
4902 default "site-vpn-flavor-single";
4903 description
4904 "Defines the way the VPN multiplexing is
4905 done ,e.g.,whether the site belongs to
4906 a single VPN site or a multiVPN; By
4907 default, the site belongs to a single VPN.";
4908 }
4909 description
4910 "Grouping for site VPN flavor.";
4911 }
4913 grouping site-device {
4914 container devices {
4915 when "derived-from-or-self(../management/type, 'l2vpn-svc:provider-managed')"+
4916 " or derived-from-or-self(../management/type, 'l2vpn-svc:co-managed')" {
4917 description
4918 "Applicable only for provider-managed or
4919 co-managed device.";
4920 }
4921 list device {
4922 key "device-id";
4923 leaf device-id {
4924 type string;
4925 description
4926 "Identifier for the device.";
4927 }
4928 leaf location {
4929 type leafref {
4930 path "../../../locations/location/location-id";
4931 }
4932 mandatory true;
4933 description
4934 "Location of the device.";
4935 }
4936 container management {
4937 when "derived-from-or-self(../../../management/type,'l2vpn-svc:co-managed')" {
4938 description
4939 "Applicable only for co-managed device.";
4940 }
4941 leaf transport {
4942 type identityref {
4943 base address-family;
4944 }
4945 description
4946 "Transport protocol or Address family used for management.";
4947 }
4948 leaf address {
4949 when "(../ transport)" {
4950 description
4951 "If address-family is specified, then address should
4952 also be specified. If the transport is not specified,
4953 then address should also not be specified.";
4954 }
4955 type inet:ip-address;
4956 description
4957 "Management address.";
4958 }
4959 description
4960 "Management configuration. Applicable only for
4961 co-managed device.";
4962 }
4963 description
4964 "List of devices requested by customer.";
4965 }
4966 description
4967 "Devices configuration";
4968 }
4969 description
4970 "Device parameters for the site.";
4971 }
4973 grouping site-management {
4974 container management {
4975 leaf type {
4976 type identityref {
4977 base management;
4978 }
4979 mandatory true;
4980 description
4981 "Management type of the connection.";
4982 }
4983 description
4984 "Management configuration.";
4985 }
4986 description
4987 "Management parameter for the site.";
4988 }
4990 grouping site-vpn-policy {
4991 container vpn-policies {
4992 list vpn-policy {
4993 key "vpn-policy-id";
4994 leaf vpn-policy-id {
4995 type string;
4996 description
4997 "Unique identifier for the VPN policy.";
4998 }
4999 list entries {
5000 key "id";
5001 leaf id {
5002 type string;
5003 description
5004 "Unique identifier for the policy entry.";
5005 }
5006 container filters {
5007 list filter {
5008 key "type";
5009 ordered-by user;
5010 leaf type {
5011 type identityref {
5012 base vpn-policy-filter-type;
5013 }
5014 description
5015 "Type of VPN Policy filter.";
5016 }
5017 leaf-list lan-tag {
5018 when "derived-from-or-self(../type, 'l2vpn-svc:lan')" {
5019 description
5020 "Only applies when VPN Policy filter is LAN Tag filter.";
5021 }
5022 if-feature lan-tag;
5023 type uint32;
5024 description
5025 "List of Ethernet LAN Tag to be matched. Ethernet LAN Tag
5026 identifies a particular broadcast domain in a VPN. ";
5027 }
5028 description
5029 "List of filters used on the site. This list can
5030 be augmented.";
5031 }
5032 description
5033 "If a more-granular VPN attachment is necessary, filtering can
5034 be used. If used, it permits the splitting of site LANs among
5035 multiple VPNs. The Site LAN can be split based on either LAN-tag
5036 or LAN prefix. If no filter is used, all the LANs will be
5037 part of the same VPNs with the same role.";
5038 }
5039 list vpn {
5040 key "vpn-id";
5041 leaf vpn-id {
5042 type leafref {
5043 path "/l2vpn-svc/vpn-services/vpn-service/vpn-id";
5044 }
5045 description
5046 "Reference to L2VPN.";
5047 }
5048 leaf site-role {
5049 type identityref {
5050 base site-role;
5051 }
5052 default "any-to-any-role";
5053 description
5054 "Role of the site in the L2VPN.";
5055 }
5056 description
5057 "List of VPNs the LAN is associated with.";
5058 }
5059 description
5060 "List of entries for export policy.";
5061 }
5062 description
5063 "List of VPN policies.";
5064 }
5065 description
5066 "VPN policy.";
5067 }
5068 description
5069 "VPN policy parameters for the site.";
5070 }
5072 grouping bum-frame-delivery {
5073 container bum-frame-delivery {
5074 list bum-frame-delivery {
5075 key "frame-type";
5076 leaf frame-type {
5077 type identityref {
5078 base tf-type;
5079 }
5080 description
5081 "Type of frame delivery. It support unicast
5082 frame delivery, multicast frame delivery
5083 and broadcast frame delivery.";
5084 }
5085 leaf delivery-mode {
5086 type identityref {
5087 base frame-delivery-mode;
5088 }
5089 default "unconditional";
5090 description
5091 "Define Frame Delivery Mode
5092 (unconditional[default],
5093 conditional, or discard).
5094 By default, Service Frames
5095 are unconditionally delivered
5096 to the destination. ";
5097 }
5098 description
5099 "List of frame delivery type and mode.";
5100 }
5101 description
5102 "Define frame delivery type and mode.";
5103 }
5104 description
5105 "Grouping for unicast, mulitcast, broadcast frame delivery";
5106 }
5108 grouping cvlan-svc-map-grouping {
5109 list cvlan-id-to-svc-map {
5110 key "svc-id";
5111 leaf svc-id {
5112 type leafref {
5113 path "/l2vpn-svc/vpn-services/vpn-service/vpn-id";
5114 }
5115 description
5116 "VPN Service identifier";
5117 }
5118 list cvlan-id {
5119 key "vid";
5120 leaf vid {
5121 type uint16;
5122 description
5123 "CVLAN ID";
5124 }
5125 description
5126 "List of CVLAN-ID to SVC Map configurations";
5127 }
5128 description
5129 "List for cvlan-id to L2VPn Service map configurations";
5130 }
5131 description
5132 "Grouping for cvlan to L2VPN service mapping";
5133 }
5135 grouping customer-location-info {
5136 container locations {
5137 list location {
5138 key "location-id";
5139 leaf location-id {
5140 type string;
5141 description
5142 "Location ID";
5143 }
5144 leaf address {
5145 type string;
5146 description
5147 "Address (number and street) of the site.";
5148 }
5149 leaf zip-code {
5150 type string;
5151 description
5152 "ZIP code of the site.";
5153 }
5154 leaf state {
5155 type string;
5156 description
5157 "State of the site. This leaf can also be used to
5158 describe a region for country who does not have
5159 states.";
5160 }
5161 leaf city {
5162 type string;
5163 description
5164 "City of the site.";
5165 }
5166 leaf country-code {
5167 type string;
5168 description
5169 "Country of the site.";
5170 }
5171 description
5172 "List for location";
5173 }
5174 description
5175 "Location of the site.";
5176 }
5177 description
5178 "This grouping defines customer location parameters";
5179 }
5181 grouping site-diversity {
5182 container site-diversity {
5183 if-feature site-diversity;
5184 container groups {
5185 list group {
5186 key "group-id";
5187 leaf group-id {
5188 type string;
5189 description
5190 "Group-id the site is belonging to";
5191 }
5192 description
5193 "List of group-id";
5194 }
5195 description
5196 "Groups the site is belonging to.
5197 All site network accesses will inherit those group
5198 values.";
5199 }
5200 description
5201 "Diversity constraint type.";
5202 }
5203 description
5204 "This grouping defines site diversity parameters";
5205 }
5207 grouping vpn-service-multicast {
5208 container frame-delivery {
5209 if-feature bum;
5210 container customer-tree-flavors {
5211 leaf-list tree-flavor {
5212 type identityref {
5213 base multicast-tree-type;
5214 }
5215 description
5216 "Type of tree to be used.";
5217 }
5218 description
5219 "Type of trees used by customer.";
5220 }
5221 uses bum-frame-delivery;
5222 leaf multicast-gp-port-mapping {
5223 type identityref {
5224 base mapping-type;
5225 }
5226 mandatory true;
5227 description
5228 "Describe the way in which each interface is
5229 associated with the Multicast group";
5230 }
5231 description
5232 "Multicast global parameters for the VPN service.";
5234 }
5235 description
5236 "Grouping for multicast VPN definition.";
5237 }
5239 grouping vpn-extranet {
5240 container extranet-vpns {
5241 if-feature extranet-vpn;
5242 list extranet-vpn {
5243 key "vpn-id";
5244 leaf vpn-id {
5245 type svc-id;
5246 description
5247 "Identifies the target VPN the local VPN want to access.";
5248 }
5249 leaf local-sites-role {
5250 type identityref {
5251 base site-role;
5252 }
5253 default "any-to-any-role";
5254 description
5255 "This describes the role of the local sites in the target
5256 VPN topology. In the any-to-any VPN service topology,
5257 the local sites must have the same role, which will be
5258 'any-to-any-role '. In the Hub-and-Spoke VPN service
5259 topology or the Hub and Spoke disjoint VPN service topology,
5260 the local sites must have a Hub role or a Spoke role";
5261 }
5262 description
5263 "List of extranet VPNs the local VPN is attached to.";
5264 }
5265 description
5266 "Container for extranet VPN configuration.";
5267 }
5268 description
5269 "Grouping for extranet VPN configuration.
5270 This provides an easy way to interconnect
5271 all sites from two VPNs.";
5272 }
5274 grouping operational-requirements-ops {
5275 leaf actual-site-start {
5276 type yang:date-and-time;
5277 config false;
5278 description
5279 "Optional leaf indicating actual date
5280 and time when the service at a particular
5281 site actually started";
5283 }
5284 leaf actual-site-stop {
5285 type yang:date-and-time;
5286 config false;
5287 description
5288 "Optional leaf indicating actual date
5289 and time when the service at a particular
5290 site actually stopped";
5291 }
5292 leaf bundling-type {
5293 type identityref {
5294 base bundling-type;
5295 }
5296 default "one2one-bundling";
5297 description
5298 "Bundling type. By default, Each L2VPN
5299 can be associated with only one
5300 CE-VLAN ,i.e., one to one bundling is used.";
5301 }
5302 leaf default-ce-vlan-id {
5303 type uint32;
5304 mandatory true;
5305 description
5306 "Default CE VLAN ID set at site level.";
5307 }
5308 description
5309 "This grouping defines some operational parameters
5310 Parameters.";
5311 }
5313 grouping cfm-8021-ag {
5314 list cfm-8021-ag {
5315 if-feature cfm;
5316 key "maid";
5317 leaf maid {
5318 type string;
5319 mandatory true;
5320 description
5321 "Identify an Maintenance Association (MA).";
5322 }
5323 leaf mep-id {
5324 type uint32;
5325 description
5326 "Local Maintenance End Point (MEP) ID.
5327 The non-existence of this leaf means
5328 that no defects are to be reported.";
5329 }
5330 leaf mep-level {
5331 type uint32;
5332 description
5333 "Define Maintenance End Point (MEP) level.
5334 The non-existence of this leaf means that
5335 no defects are to be reported.";
5336 }
5337 leaf mep-up-down {
5338 type enumeration {
5339 enum "up" {
5340 description
5341 "MEP up.";
5342 }
5343 enum "down" {
5344 description
5345 "MEP down.";
5346 }
5347 }
5348 default "up";
5349 description
5350 "MEP up/down. By default, MEP up is used.
5351 The non-existence of this leaf means that
5352 no defects are to be reported.";
5353 }
5354 leaf remote-mep-id {
5355 type uint32;
5356 description
5357 "Remote MEP ID. The non-existence of this leaf means
5358 that no defects are to be reported.";
5359 }
5360 leaf cos-for-cfm-pdus {
5361 type uint32;
5362 description
5363 "COS for CFM PDUs. The non-existence of this leaf means
5364 that no defects are to be reported.";
5365 }
5366 leaf ccm-interval {
5367 type uint32;
5368 units "msec";
5369 default "10000";
5370 description
5371 "Continuity Check Message(CCM) interval.
5372 By default, ccm-interval is 10 seconds.";
5373 }
5374 leaf ccm-holdtime {
5375 type uint32;
5376 units "msec";
5377 default "35000";
5378 description
5379 "CCM hold time. By default ccm hold time
5380 is 3.5 times of ccm interval.";
5381 }
5382 leaf alarm-priority-defect {
5383 type identityref {
5384 base fault-alarm-defect-type;
5385 }
5386 default "remote-invalid-ccm";
5387 description
5388 "The lowest priority defect that is
5389 allowed to generate a Fault Alarm.By default,
5390 fault-alarm-defect-type is set to remote-invalid-ccm.
5391 The non-existence of this leaf means
5392 that no defects are to be reported.";
5393 }
5394 leaf ccm-p-bits-pri {
5395 type ccm-priority-type;
5396 description
5397 "The priority parameter for CCMs transmitted by the MEP.
5398 The non-existence of this leaf means
5399 that no defects are to be reported.";
5400 }
5401 description
5402 "List of 802.1ag CFM attributes";
5403 }
5404 description
5405 "Grouping for 802.1ag CFM attributes.";
5406 }
5408 grouping y-1731 {
5409 list y-1731 {
5410 if-feature y-1731;
5411 key "maid";
5412 leaf maid {
5413 type string;
5414 mandatory true;
5415 description
5416 "Identify an Maintenance Association (MA).";
5417 }
5418 leaf mep-id {
5419 type uint32;
5420 description
5421 "Local Maintenance End Point(MEP) ID.
5422 The non-existence of this leaf means
5423 that no measurements are to be reported.";
5424 }
5425 leaf type {
5426 type identityref {
5427 base pm-type;
5428 }
5429 default "delay";
5430 description
5431 "Performance monitor types. By default, the
5432 performance monitoring type is set to delay.
5433 The non-existence of this leaf means that no
5434 measurements are to be reported.";
5435 }
5436 leaf remote-mep-id {
5437 type uint32;
5438 description
5439 "Remote MEP ID. The non-existence of this
5440 leaf means that no measurements are to be
5441 reported.";
5442 }
5443 leaf message-period {
5444 type uint32;
5445 units "msec";
5446 default "10000";
5447 description
5448 "Defines the interval between Y.1731
5449 performance monitoring messages. The message
5450 period is expressed in milliseconds.";
5451 }
5452 leaf measurement-interval {
5453 type uint32;
5454 units "sec";
5455 description
5456 "Specifies the measurement interval for statistics. The
5457 measurement interval is expressed in seconds.";
5458 }
5459 leaf cos {
5460 type uint32;
5461 description
5462 "Class of service. The non-existence
5463 of this leaf means that no measurements
5464 are to be reported.";
5465 }
5466 leaf loss-measurement {
5467 type boolean;
5468 default "false";
5469 description
5470 "Whether enable loss measurement.
5471 By default, loss measurement is not
5472 enabled.";
5473 }
5474 leaf synthethic-loss-measurement {
5475 type boolean;
5476 default "false";
5477 description
5478 "Indicate whether enable synthetic loss
5479 measurement.By default, synthethic loss
5480 measurement is not enabled.";
5481 }
5482 container delay-measurement {
5483 leaf enable-dm {
5484 type boolean;
5485 default "false";
5486 description
5487 "Whether to enable delay measurement.
5488 By defaut, the delay measurement is
5489 not enabled.";
5490 }
5491 leaf two-way {
5492 type boolean;
5493 default "false";
5494 description
5495 "Whether delay measurement is two-way (true) of one-
5496 way (false). By default, one way measurement is enabled.";
5497 }
5498 description
5499 "Container for delay measurement.";
5500 }
5501 leaf frame-size {
5502 type uint32;
5503 units "bytes";
5504 description
5505 "Frame size. The non-existence of this leaf means
5506 that no measurements are to be reported.";
5507 }
5508 leaf session-type {
5509 type enumeration {
5510 enum "proactive" {
5511 description
5512 "Proactive mode.";
5513 }
5514 enum "on-demand" {
5515 description
5516 "On demand mode.";
5517 }
5518 }
5519 default "on-demand";
5520 description
5521 "Session type. By default, the session type is on demand mode.
5522 The non-existence of this leaf means that no measurements
5523 are to be reported.";
5524 }
5525 description
5526 "List for y-1731.";
5527 }
5528 description
5529 "Grouping for y.1731.";
5530 }
5532 grouping site-acl {
5533 container access-control-list {
5534 if-feature acl;
5535 list mac {
5536 key "mac-address";
5537 leaf mac-address {
5538 type yang:mac-address;
5539 description
5540 "MAC address.";
5541 }
5542 description
5543 "List for MAC.";
5544 }
5545 description
5546 "Container for access control List.";
5547 }
5548 description
5549 "This grouping defines Access Control List.";
5550 }
5552 grouping lacp {
5553 container lacp {
5554 if-feature lacp;
5555 leaf enable {
5556 type boolean;
5557 default "false";
5558 description
5559 "LACP on/off.By default, LACP is disabled.";
5560 }
5561 leaf mode {
5562 type neg-mode;
5563 description
5564 "LACP mode. LACP modes have auto negotiation mode
5565 and passive mode (false). Auto negotiation mode
5566 means initiating the auto speed negotiation and
5567 trying to form Ethernet Channel with other end.
5568 Passive mode means not initiating the negotiation,
5569 but responding to LACP packets initiated by other
5570 end(e.g., full duplex or half duplex. ";
5572 }
5573 leaf speed {
5574 type uint32;
5575 units "mbps";
5576 default "10";
5577 description
5578 "LACP speed. By default, the lacp speed is 10Mbps.";
5579 }
5580 leaf mini-link-num {
5581 type uint32;
5582 description
5583 "Defines the minimum number of links that must be
5584 active before the aggregating link is put
5585 into service.";
5586 }
5587 leaf system-priority {
5588 type uint16;
5589 default "32768";
5590 description
5591 "Indicates the LACP priority for the system.
5592 The range is from 0 to 65535.
5593 The default is 32768.";
5594 }
5595 container micro-bfd {
5596 if-feature micro-bfd;
5597 leaf enable {
5598 type enumeration {
5599 enum "on" {
5600 description
5601 "Micro-bfd on.";
5602 }
5603 enum "off" {
5604 description
5605 "Micro-bfd off.";
5606 }
5607 }
5608 default "off";
5609 description
5610 "Micro BFD ON/OFF. By default,
5611 the micro-bfd is set to off.";
5612 }
5613 leaf interval {
5614 type uint32;
5615 units "msec";
5616 description
5617 "BFD interval.";
5618 }
5619 leaf hold-timer {
5620 type uint32;
5621 units "msec";
5622 description
5623 "BFD hold timer.";
5624 }
5625 description
5626 "Container of Micro-BFD configurations.";
5627 }
5628 container bfd {
5629 if-feature bfd;
5630 leaf enabled {
5631 type boolean;
5632 default "false";
5633 description
5634 "BFD activation. By default, BFD is not activated.";
5635 }
5636 choice holdtime {
5637 default "fixed";
5638 case profile {
5639 leaf profile-name {
5640 type leafref {
5641 path "/l2vpn-svc/vpn-profiles/valid-provider-identifiers/bfd-profile-identifier/id";
5642 }
5643 description
5644 "Service provider well known profile.";
5645 }
5646 description
5647 "Service provider well known profile.";
5648 }
5649 case fixed {
5650 leaf fixed-value {
5651 type uint32;
5652 units "msec";
5653 description
5654 "Expected hold time expressed in msec.";
5655 }
5656 }
5657 description
5658 "Choice for hold time flavor.";
5659 }
5660 description
5661 "Container for BFD.";
5662 }
5663 container member-links {
5664 list member-link {
5665 key "name";
5666 leaf name {
5667 type string;
5668 description
5669 "Member link name.";
5670 }
5671 leaf speed {
5672 type uint32;
5673 units "mbps";
5674 default "10";
5675 description
5676 "Port speed.";
5677 }
5678 leaf mode {
5679 type neg-mode;
5680 default "auto-neg";
5681 description
5682 "Negotiation mode.";
5683 }
5684 leaf link-mtu {
5685 type uint32;
5686 units "bytes";
5687 description
5688 "Link MTU size.";
5689 }
5690 container oam-802.3ah-link {
5691 if-feature oam-3ah;
5692 leaf enable {
5693 type boolean;
5694 default "false";
5695 description
5696 "Indicate whether oam 802.3 ah link is supported.";
5697 }
5698 description
5699 "Container for oam 802.3 ah link.";
5700 }
5701 description
5702 "Member link";
5703 }
5704 description
5705 "Container of Member link list";
5706 }
5707 leaf flow-control {
5708 type boolean;
5709 default "false";
5710 description
5711 "Flow control. Indicate whether flow control is supported.";
5712 }
5713 leaf lldp {
5714 type boolean;
5715 default "false";
5716 description
5717 "LLDP. Indicate whether lldp is supported.";
5718 }
5719 description
5720 "LACP.";
5721 }
5722 description
5723 "Grouping for LACP.";
5724 }
5726 grouping untagged-interface-grouping {
5727 container untagged-interface {
5728 leaf speed {
5729 type uint32;
5730 units "mbps";
5731 default "10";
5732 description
5733 "Port speed.";
5734 }
5735 leaf mode {
5736 type neg-mode;
5737 default "auto-neg";
5738 description
5739 "Negotiation mode.";
5740 }
5741 leaf phy-mtu {
5742 type uint32;
5743 units "bytes";
5744 description
5745 "PHY MTU.";
5746 }
5747 leaf lldp {
5748 type boolean;
5749 default "false";
5750 description
5751 "LLDP. Indicate LLDP is supported.";
5752 }
5753 container oam-802.3ah-link {
5754 if-feature oam-3ah;
5755 leaf enable {
5756 type boolean;
5757 default "false";
5758 description
5759 "Indicate whether support oam 802.3 ah link";
5760 }
5761 description
5762 "Container for oam 802.3 ah link.";
5763 }
5764 leaf uni-loop-prevention {
5765 type boolean;
5766 default "false";
5767 description
5768 "If this leaf set to truth that the port automatically
5769 goes down when a physical loopback is detect.";
5770 }
5771 description
5772 "Container of Untagged Interface Attributes
5773 configurations.";
5774 }
5775 description
5776 "Grouping for Untagged interface.";
5777 }
5779 grouping lag-interface-grouping {
5780 container lag-interfaces {
5781 if-feature lag-interface;
5782 list lag-interface {
5783 key "index";
5784 leaf index {
5785 type string;
5786 description
5787 "LAG interface index.";
5788 }
5789 uses lacp;
5790 description
5791 "List of LAG interfaces.";
5792 }
5793 description
5794 "Container of LAG interface attributes configuration";
5795 }
5796 description
5797 "Grouping for LAG interface";
5798 }
5800 grouping tagged-interface-grouping {
5801 container tagged-interface {
5802 leaf type {
5803 type identityref {
5804 base tagged-inf-type;
5805 }
5806 default "priority-tagged";
5807 description
5808 "Tagged interface type. By default,
5809 the Tagged interface type is priority
5810 tagged interface. ";
5811 }
5812 container dot1q-vlan-tagged {
5813 when "derived-from-or-self(../type, 'l2vpn-svc:dot1q')" {
5814 description
5815 "Only applies when Tagged interface type is dot1q.";
5816 }
5817 if-feature dot1q;
5818 leaf tg-type {
5819 type identityref {
5820 base tag-type;
5821 }
5822 default "c-vlan";
5823 description
5824 "TAG type.By default, Tag type is Customer-VLAN tag.";
5825 }
5826 leaf cvlan-id {
5827 type uint16;
5828 mandatory true;
5829 description
5830 "VLAN identifier.";
5831 }
5832 description
5833 "Tagged interface.";
5834 }
5835 container priority-tagged {
5836 when "derived-from-or-self(../type, 'l2vpn-svc:priority-tagged')" {
5837 description
5838 "Only applies when Tagged interface type
5839 is priority tagged interface.";
5840 }
5841 leaf tag-type {
5842 type identityref {
5843 base tag-type;
5844 }
5845 default "c-vlan";
5846 description
5847 "TAG type.By default, the TAG type is Customer-VLAN tag.";
5848 }
5849 description
5850 "Priority tagged.";
5851 }
5852 container qinq {
5853 when "derived-from-or-self(../type, 'l2vpn-svc:qinq')" {
5854 description
5855 "Only applies when Tagged interface type is qinq.";
5856 }
5857 if-feature qinq;
5858 leaf tag-type {
5859 type identityref {
5860 base tag-type;
5861 }
5862 default "c-s-vlan";
5863 description
5864 "Tag type. By default, the Tag type is c-s-vlan.";
5865 }
5866 leaf svlan-id {
5867 type uint16;
5868 mandatory true;
5869 description
5870 "S-VLAN Identifier.";
5871 }
5872 leaf cvlan-id {
5873 type uint16;
5874 mandatory true;
5875 description
5876 "C-VLAN Identifier";
5877 }
5878 description
5879 "QinQ.";
5880 }
5881 container qinany {
5882 when "derived-from-or-self(../type, 'l2vpn-svc:qinany')" {
5883 description
5884 "Only applies when Tagged interface type is qinany.";
5885 }
5886 if-feature qinany;
5887 leaf tag-type {
5888 type identityref {
5889 base tag-type;
5890 }
5891 default "s-vlan";
5892 description
5893 "Tag type.By default, the Tag type is Service-VLAN tag.";
5894 }
5895 leaf svlan-id {
5896 type uint16;
5897 mandatory true;
5898 description
5899 "S-Vlan ID.";
5900 }
5901 description
5902 "Container for Qin Any.";
5903 }
5904 container vxlan {
5905 when "derived-from-or-self(../type, 'l2vpn-svc:vxlan')" {
5906 description
5907 "Only applies when Tagged interface type is vxlan.";
5909 }
5910 if-feature vxlan;
5911 leaf vni-id {
5912 type uint32;
5913 mandatory true;
5914 description
5915 "VNI Identifier.";
5916 }
5917 leaf peer-mode {
5918 type identityref {
5919 base vxlan-peer-mode;
5920 }
5921 default "static-mode";
5922 description
5923 "specify the vxlan access mode. By default the peer mode is
5924 Set as static mode.";
5925 }
5926 list peer-list {
5927 key "peer-ip";
5928 leaf peer-ip {
5929 type inet:ip-address;
5930 description
5931 "Peer IP.";
5932 }
5933 description
5934 "List for peer IP.";
5935 }
5936 description
5937 "QinQ.";
5938 }
5939 description
5940 "Container for tagged Interface.";
5941 }
5942 description
5943 "Grouping for tagged interface.";
5944 }
5946 grouping site-attachment-ethernet-connection {
5947 container connection {
5948 leaf encapsulation-type {
5949 type identityref {
5950 base encapsulation-type;
5951 }
5952 default "ethernet";
5953 description
5954 "Encapsulation Type. By default,the
5955 encapsulation type is set as Ethernet.";
5956 }
5957 leaf eth-inf-type {
5958 type identityref {
5959 base eth-inf-type;
5960 }
5961 default "untagged";
5962 description
5963 "Ethernet Interface Type. By default,
5964 the Ethernet Interface Type is set as
5965 untagged interface.";
5966 }
5967 uses tagged-interface-grouping;
5968 uses untagged-interface-grouping;
5969 uses lag-interface-grouping;
5970 uses cvlan-svc-map-grouping;
5971 uses l2cp-grouping;
5972 uses ethernet-svc-oam-grouping;
5973 description
5974 "Container for bearer";
5975 }
5976 description
5977 "Grouping for bearer.";
5978 }
5980 grouping svc-mtu {
5981 leaf svc-mtu {
5982 type uint16;
5983 units "bytes";
5984 mandatory true;
5985 description
5986 "SVC MTU, it is also known as the maximum transmission unit or
5987 maximum frame size,When a frame is larger than the MTU, it is
5988 broken down, or fragmented, into smaller pieces by the network
5989 protocol to accommodate the MTU of the network. If CsC is
5990 enabled,the requested svc-mtu leaf will refer to the
5991 MPLS MTU and not to the link MTU. ";
5992 }
5993 description
5994 "Grouping for service mtu.";
5995 }
5997 grouping svc-preservation-grouping {
5998 leaf ce-vlan-preservation {
5999 type boolean;
6000 mandatory true;
6001 description
6002 "Preserve the CE-VLAN ID from ingress to egress,i.e.,
6003 CE-VLAN tag of the egress frame are identical to
6004 those of the ingress frame that yielded this
6005 egress service frame. If All-to-One bundling within a site
6006 is Enabled, then preservation applies to all Ingress service
6007 frames. If All-to-One bundling is Disabled , then preservation
6008 applies to tagged Ingress service frames having CE-VLAN ID 1
6009 through 4094.";
6010 }
6011 leaf ce-vlan-cos-perservation {
6012 type boolean;
6013 mandatory true;
6014 description
6015 "CE vlan CoS preservation. PCP bits in the CE-VLAN tag of the egress
6016 frame are identical to those of the ingress frame that yielded this
6017 egress service frame.";
6018 }
6019 description
6020 "Grouping for service preservation.";
6021 }
6023 grouping site-mac-addr-limit {
6024 container mac-addr-limit {
6025 if-feature mac-addr-limit;
6026 leaf limit-number {
6027 type uint16;
6028 default "2";
6029 description
6030 "maximum number of MAC addresses learned from
6031 the subscriber for a single service instance.
6032 The default allowed maximum number of MAC addresses is 2.";
6033 }
6034 leaf time-interval {
6035 type uint32;
6036 units "sec";
6037 default "300";
6038 description
6039 "The aging time of the mac address. By default,
6040 the aging time is set 300 seconds.";
6041 }
6042 leaf action {
6043 type identityref {
6044 base mac-action;
6045 }
6046 default "warning";
6047 description
6048 "specify the action when the upper limit is
6049 exceeded: drop the packet, flood the
6050 packet, or simply send a warning log message. By default,
6051 action is set to warning.";
6052 }
6053 description
6054 "Container of MAC-Addr limit configurations";
6055 }
6056 description
6057 "Grouping for mac address limit";
6058 }
6060 grouping site-attachment-availability {
6061 container availability {
6062 leaf access-priority {
6063 type uint32;
6064 default "100";
6065 description
6066 "Access priority. The higher the access-priority value,
6067 the higher the preference of the access will be.";
6068 }
6069 choice redundancy-mode {
6070 case single-active {
6071 leaf single-active {
6072 type empty;
6073 description
6074 "Single active.";
6075 }
6076 description
6077 "Single active case.";
6078 }
6079 case all-active {
6080 leaf all-active {
6081 type empty;
6082 description
6083 "All active.";
6084 }
6085 description
6086 "All active case.";
6087 }
6088 description
6089 "Redundancy mode choice.";
6090 }
6091 description
6092 "Container of availability optional configurations.";
6093 }
6094 description
6095 "Grouping for availability.";
6096 }
6098 grouping l2cp-grouping {
6099 container l2cp-control {
6100 if-feature l2cp-control;
6101 leaf stp-rstp-mstp {
6102 type control-mode;
6103 description
6104 "STP/RSTP/MSTP protocol type applicable to all Sites.";
6105 }
6106 leaf pause {
6107 type control-mode;
6108 description
6109 "Pause protocol type applicable to all Sites.";
6110 }
6111 leaf lacp-lamp {
6112 type control-mode;
6113 description
6114 "LACP/LAMP.";
6115 }
6116 leaf link-oam {
6117 type control-mode;
6118 description
6119 "Link OAM.";
6120 }
6121 leaf esmc {
6122 type control-mode;
6123 description
6124 "ESMC.";
6125 }
6126 leaf l2cp-802.1x {
6127 type control-mode;
6128 description
6129 "IEEE 802.x.";
6130 }
6131 leaf e-lmi {
6132 type control-mode;
6133 description
6134 "E-LMI.";
6135 }
6136 leaf lldp {
6137 type boolean;
6138 description
6139 "LLDP protocol type applicable to all sites.";
6140 }
6141 leaf ptp-peer-delay {
6142 type control-mode;
6143 description
6144 "PTP peer delay.";
6145 }
6146 leaf garp-mrp {
6147 type control-mode;
6148 description
6149 "GARP/MRP.";
6150 }
6151 description
6152 "Container of L2CP control configurations";
6153 }
6154 description
6155 "Grouping for l2cp control.";
6156 }
6158 grouping site-bum {
6159 container broadcast-unknown-unicast-multicast {
6160 if-feature bum;
6161 leaf multicast-site-type {
6162 type enumeration {
6163 enum "receiver-only" {
6164 description
6165 "The site only has receivers.";
6166 }
6167 enum "source-only" {
6168 description
6169 "The site only has sources.";
6170 }
6171 enum "source-receiver" {
6172 description
6173 "The site has both sources and receivers.";
6174 }
6175 }
6176 default "source-receiver";
6177 description
6178 "Type of multicast site.";
6179 }
6180 list multicast-gp-address-mapping {
6181 key "id";
6182 leaf id {
6183 type uint16;
6184 description
6185 "Unique identifier for the mapping.";
6186 }
6187 leaf vlan-id {
6188 type uint16 {
6189 range "0..1024";
6190 }
6191 mandatory true;
6192 description
6193 "The VLAN ID of the Multicast group.
6194 The range of 12 bit VLAN ID is 0 to 1024.";
6195 }
6196 leaf mac-gp-address {
6197 type yang:mac-address;
6198 mandatory true;
6199 description
6200 "the MAC address of the Multicast group.";
6201 }
6202 leaf port-lag-number {
6203 type uint32;
6204 description
6205 "the ports/LAGs belonging to the Multicast group.";
6206 }
6207 description
6208 "List of Port to group mappings.";
6209 }
6210 leaf bum-overall-rate {
6211 type uint32;
6212 units "bps";
6213 description
6214 "overall rate for BUM.";
6215 }
6216 list bum-rate-per-type {
6217 key "type";
6218 leaf type {
6219 type identityref {
6220 base bum-type;
6221 }
6222 description
6223 "BUM type.";
6224 }
6225 leaf rate {
6226 type uint32;
6227 units "bps";
6228 description
6229 "rate for BUM.";
6230 }
6231 description
6232 "List of rate per type.";
6233 }
6234 description
6235 "Container of broadcast, unknown unicast, and multicast
6236 configurations.";
6237 }
6238 description
6239 "Grouping for broadcast, unknown unicast, and multicast.";
6240 }
6242 grouping site-mac-loop-prevention {
6243 container mac-loop-prevention {
6244 if-feature mac-loop-prevention;
6245 leaf protection-type {
6246 type identityref {
6247 base loop-prevention-type;
6248 }
6249 default "trap";
6250 description
6251 "Protection type. By default, the protection
6252 type is trap protection type.";
6253 }
6254 leaf frequency {
6255 type uint32;
6256 default "5";
6257 description
6258 "The number of times to detect MAC duplication.
6259 When duplicate-MAC situation has occurred and the
6260 duplicated MAC is added into to a duplicate-MAC
6261 list. By default, the number of times is 5.";
6262 }
6263 leaf retry-timer {
6264 type uint32;
6265 units "seconds";
6266 description
6267 "The retry timer. When retry timer expires,
6268 the duplicated MAC will be flushed from
6269 the MAC-VRF. ";
6270 }
6271 description
6272 "Container of MAC loop prevention.";
6273 }
6274 description
6275 "Grouping for MAC loop prevention.";
6276 }
6278 grouping ethernet-svc-oam-grouping {
6279 container oam {
6280 if-feature ethernet-oam;
6281 leaf md-name {
6282 type string;
6283 mandatory true;
6284 description
6285 "Maintenance domain name.";
6286 }
6287 leaf md-level {
6288 type uint16 {
6289 range "0..255";
6290 }
6291 mandatory true;
6292 description
6293 "Maintenance domain level. The level may be
6294 restricted in certain protocols (e.g.,
6295 protocol in layer 0 to layer 7).";
6296 }
6297 uses cfm-8021-ag;
6298 uses y-1731;
6299 description
6300 "Container for Ethernet service OAM.";
6301 }
6302 description
6303 "Grouping for Ethernet service OAM.";
6304 }
6306 grouping site-group {
6307 container groups {
6308 list group {
6309 key "group-id";
6310 leaf group-id {
6311 type string;
6312 description
6313 "Group-id the site is belonging to.";
6314 }
6315 description
6316 "List of group-id";
6317 }
6318 description
6319 "Groups the site or site-network-access
6320 is belonging to.";
6321 }
6322 description
6323 "Grouping definition to assign
6324 group-ids to site or site-network-access.";
6325 }
6327 grouping access-diversity {
6328 container access-diversity {
6329 if-feature site-diversity;
6330 uses site-group;
6331 container constraints {
6332 list constraint {
6333 key "constraint-type";
6334 leaf constraint-type {
6335 type identityref {
6336 base placement-diversity;
6337 }
6338 description
6339 "Diversity constraint type.";
6340 }
6341 container target {
6342 choice target-flavor {
6343 default "id";
6344 case id {
6345 list group {
6346 key "group-id";
6347 leaf group-id {
6348 type string;
6349 description
6350 "The constraint will apply
6351 against this particular
6352 group-id.";
6353 }
6354 description
6355 "List of groups.";
6356 }
6357 }
6358 case all-accesses {
6359 leaf all-other-accesses {
6360 type empty;
6361 description
6362 "The constraint will apply
6363 against all other site network
6364 access of this site.";
6365 }
6366 }
6367 case all-groups {
6368 leaf all-other-groups {
6369 type empty;
6370 description
6371 "The constraint will apply
6372 against all other groups the
6373 customer is managing.";
6374 }
6375 }
6376 description
6377 "Choice for the group definition.";
6378 }
6379 description
6380 "The constraint will apply against
6381 this list of groups.";
6382 }
6383 description
6384 "List of constraints.";
6385 }
6386 description
6387 "Constraints for placing this site
6388 network access.";
6390 }
6391 description
6392 "Diversity parameters.";
6393 }
6394 description
6395 "This grouping defines access diversity
6396 parameters";
6397 }
6399 grouping site-attachment-bearer {
6400 container bearer {
6401 container requested-type {
6402 if-feature requested-type;
6403 leaf type {
6404 type string;
6405 description
6406 "Type of requested bearer Ethernet, ATM, Frame
6407 Relay, IP Layer 2 Transport, Frame Relay DLCI,
6408 SONET/SDH,PPP.";
6409 }
6410 leaf strict {
6411 type boolean;
6412 default "false";
6413 description
6414 "Define if the requested-type is a preference
6415 or a strict requirement.";
6416 }
6417 description
6418 "Container for requested type.";
6419 }
6420 leaf always-on {
6421 if-feature always-on;
6422 type boolean;
6423 default "true";
6424 description
6425 "Request for an always on access type.
6426 For example.This could mean no Dial access type.";
6427 }
6428 leaf bearer-reference {
6429 if-feature bearer-reference;
6430 type string;
6431 description
6432 "This is an internal reference for the
6433 service provider.";
6434 }
6435 description
6436 "Bearer specific parameters.
6437 To be augmented.";
6439 }
6440 description
6441 "Grouping to define physical properties of
6442 a site attachment.";
6443 }
6445 grouping site-vpn-attachment {
6446 container vpn-attachment {
6447 choice attachment-flavor {
6448 case vpn-id {
6449 leaf vpn-id {
6450 type leafref {
6451 path "/l2vpn-svc/vpn-services/vpn-service/vpn-id";
6452 }
6453 description
6454 "Reference to a L2VPN. Referencing a vpn-id provides
6455 an easy way to attach a particular logical access to
6456 a VPN. In this case, vpn-id must be configured.";
6457 }
6458 leaf site-role {
6459 type identityref {
6460 base site-role;
6461 }
6462 default "any-to-any-role";
6463 description
6464 "Role of the site in the L2VPN. When referencing a vpn-id,
6465 the site-role setting must be added to express the role of
6466 the site in the target VPN service topology.";
6467 }
6468 }
6469 case vpn-policy-id {
6470 leaf vpn-policy-id {
6471 type leafref {
6472 path "../../../../vpn-policies/vpn-policy/vpn-policy-id";
6473 }
6474 description
6475 "Reference to a vpn policy.";
6476 }
6477 }
6478 mandatory true;
6479 description
6480 "Choice for VPN attachment flavor.";
6481 }
6482 description
6483 "Defines VPN attachment of a site.";
6484 }
6485 description
6486 "Grouping for access attachment.";
6488 }
6490 grouping site-service-basic {
6491 container svc-bandwidth {
6492 if-feature input-bw;
6493 list bandwidth {
6494 key "direction type";
6495 leaf direction {
6496 type identityref {
6497 base bw-direction;
6498 }
6499 description
6500 "Indicate the bandwidth direction. It can be bandwidth download
6501 direction from the SP to the site or bandwidth upload direction
6502 from the site to the SP.";
6503 }
6504 leaf type {
6505 type identityref {
6506 base bw-type;
6507 }
6508 description
6509 "Bandwidth Type. By default, the bandwidth type is set as bandwidth per cos.";
6510 }
6511 leaf cos-id {
6512 when "../type = 'bw-per-cos'" {
6513 description
6514 "Relevant when the bandwidth type is set as bandwidth per cos.";
6515 }
6516 type uint8;
6517 description
6518 "Identifier of Class of Service
6519 , indicated by DSCP or a CE-CLAN
6520 CoS(802.1p)value in the service frame.
6521 If bandwidth type is set as bandwidth
6522 per cos, cos-id MUST be specified.";
6523 }
6524 leaf vpn-id {
6525 when "../type = 'bw-per-svc'" {
6526 description
6527 "Relevant when the bandwidth type is
6528 set as bandwidth per VPN service.";
6529 }
6530 type svc-id;
6531 description
6532 "Identifies the target VPN. If bandwidth
6533 type is set as bandwidth per VPN service,
6534 vpn-id MUST be specified.";
6535 }
6536 leaf cir {
6537 type uint64;
6538 units "bps";
6539 mandatory true;
6540 description
6541 "Committed Information Rate. The maximum number of
6542 bits that a port can receive or send during
6543 one-second over an interface.";
6544 }
6545 leaf cbs {
6546 type uint64;
6547 units "bps";
6548 mandatory true;
6549 description
6550 "Committed Burst Size.CBS controls the bursty nature
6551 of the traffic. Traffic that does not use the configured
6552 CIR accumulates credits until the credits reach the
6553 configured CBS.";
6554 }
6555 leaf eir {
6556 type uint64;
6557 units "bps";
6558 description
6559 "Excess Information Rate,i.e.,Excess frame delivery
6560 allowed not subject to SLA.The traffic rate can be
6561 limited by eir.";
6562 }
6563 leaf ebs {
6564 type uint64;
6565 units "bps";
6566 description
6567 "Excess Burst Size. The bandwidth available for burst
6568 traffic from the EBS is subject to the amount of
6569 bandwidth that is accumulated during periods when
6570 traffic allocated by the EIR policy is not used.";
6571 }
6572 leaf pir {
6573 type uint64;
6574 units "bps";
6575 description
6576 "Peak Information Rate, i.e., maixmum frame delivery
6577 allowed.It is equal to or less than sum of cir
6578 and eir.";
6579 }
6580 leaf pbs {
6581 type uint64;
6582 units "bps";
6583 description
6584 "Peak Burst Size. It is measured in bytes per second.";
6585 }
6586 description
6587 "List for bandwidth.";
6588 }
6589 description
6590 "From the customer site's perspective, the service
6591 input/out bandwidth of the connection or download/upload
6592 bandwidth from the SP/site to the site/SP.";
6593 }
6594 uses svc-mtu;
6595 description
6596 "Define basic service parameters for the site.";
6597 }
6599 grouping flow-definition {
6600 container match-flow {
6601 leaf dscp {
6602 type inet:dscp;
6603 description
6604 "DSCP value.";
6605 }
6606 leaf dot1q {
6607 type uint16;
6608 description
6609 "802.1q matching. It is VLAN Tag added into frame.";
6610 }
6611 leaf pcp {
6612 type uint8 {
6613 range "0 .. 7";
6614 }
6615 description
6616 "PCP value.";
6617 }
6618 leaf src-mac {
6619 type yang:mac-address;
6620 description
6621 "Source MAC";
6622 }
6623 leaf dst-mac {
6624 type yang:mac-address;
6625 description
6626 "Destination MAC.";
6627 }
6628 leaf color-type {
6629 type identityref {
6630 base color-type;
6631 }
6632 description
6633 "Color Types.";
6634 }
6635 leaf-list target-sites {
6636 if-feature target-sites;
6637 type svc-id;
6638 description
6639 "Identify a site as traffic destination.";
6640 }
6641 leaf any {
6642 type empty;
6643 description
6644 "Allow all.";
6645 }
6646 leaf vpn-id {
6647 type svc-id;
6648 description
6649 "Reference to the target VPN.";
6650 }
6651 description
6652 "Describe flow matching criteria.";
6653 }
6654 description
6655 "Flow definition based on criteria.";
6656 }
6658 grouping site-service-qos-profile {
6659 container qos {
6660 if-feature qos;
6661 container classification-policy {
6662 list rule {
6663 key "id";
6664 ordered-by user;
6665 leaf id {
6666 type string;
6667 description
6668 "A description identifying qos classification
6669 policy rule.";
6670 }
6671 choice match-type {
6672 default "match-flow";
6673 case match-flow {
6674 uses flow-definition;
6675 }
6676 case match-application {
6677 leaf match-application {
6678 type identityref {
6679 base customer-application;
6681 }
6682 description
6683 "Defines the application to match.";
6684 }
6685 }
6686 description
6687 "Choice for classification";
6688 }
6689 leaf target-class-id {
6690 type string;
6691 description
6692 "Identification of the class of service.
6693 This identifier is internal to the
6694 administration.";
6695 }
6696 description
6697 "List of marking rules.";
6698 }
6699 description
6700 "Configuration of the traffic classification policy.";
6701 }
6702 container qos-profile {
6703 choice qos-profile {
6704 description
6705 "Choice for QoS profile.
6706 Can be standard profile or customized profile.";
6707 case standard {
6708 description
6709 "Standard QoS profile.";
6710 leaf profile {
6711 type leafref {
6712 path "/l2vpn-svc/vpn-profiles/valid-provider-identifiers/qos-profile-identifier/id";
6713 }
6714 description
6715 "QoS Profile to be used.";
6716 }
6717 }
6718 case custom {
6719 description
6720 "Customized QoS profile.";
6721 container classes {
6722 if-feature qos-custom;
6723 list class {
6724 key "class-id";
6725 leaf class-id {
6726 type string;
6727 description
6728 "Identification of the class of
6729 service. This identifier is internal
6730 to the administration.";
6731 }
6732 leaf direction {
6733 type identityref {
6734 base qos-profile-direction;
6735 }
6736 default "bidirectional";
6737 description
6738 "The direction which QoS profile is applied to.
6739 By default,the direction is bidirectional.";
6740 }
6741 leaf policing {
6742 type identityref {
6743 base policing;
6744 }
6745 default "one-rate-two-color";
6746 description
6747 "The policing can be either one-rate,
6748 two-color (1R2C) or two-rate, three-color
6749 (2R3C). By default, the policing is on rate two color.";
6750 }
6751 leaf byte-offset {
6752 type uint16;
6753 description
6754 "For not including extra VLAN tags in the QoS
6755 calculation.";
6756 }
6757 container frame-delay {
6758 choice flavor {
6759 case lowest {
6760 leaf use-lowest-latency {
6761 type empty;
6762 description
6763 "The traffic class should use
6764 the lowest delay path.";
6765 }
6766 }
6767 case boundary {
6768 leaf delay-bound {
6769 type uint16;
6770 units "msec";
6771 description
6772 "The traffic class should use
6773 a path with a defined maximum
6774 delay.";
6775 }
6776 }
6777 description
6778 "Delay constraint on the traffic
6779 class.";
6780 }
6781 description
6782 "Delay constraint on the traffic
6783 class.";
6784 }
6785 container frame-jitter {
6786 choice flavor {
6787 case lowest {
6788 leaf use-lowest-jitter {
6789 type empty;
6790 description
6791 "The traffic class should use
6792 the lowest jitter path.";
6793 }
6794 }
6795 case boundary {
6796 leaf delay-bound {
6797 type uint32;
6798 units "usec";
6799 description
6800 "The traffic class should use
6801 a path with a defined maximum
6802 jitter.";
6803 }
6804 }
6805 description
6806 "Jitter constraint on the traffic
6807 class.";
6808 }
6809 description
6810 "Jitter constraint on the traffic
6811 class.";
6812 }
6813 container frame-loss {
6814 leaf rate {
6815 type decimal64 {
6816 fraction-digits 2;
6817 range "0..100";
6818 }
6819 units "percent";
6820 description
6821 "Frame Loss rate constraint on the traffic class.";
6822 }
6823 description
6824 "Container for frame loss rate.";
6826 }
6827 container bandwidth {
6828 leaf guaranteed-bw-percent {
6829 type decimal64 {
6830 fraction-digits 5;
6831 range "0..100";
6832 }
6833 units "percent";
6834 mandatory true;
6835 description
6836 "To be used to define the guaranteed bandwidth
6837 as a percentage of the available service
6838 bandwidth.";
6839 }
6840 leaf end-to-end {
6841 type empty;
6842 description
6843 "Used if the bandwidth reservation
6844 must be done on the MPLS network too.";
6845 }
6846 description
6847 "Bandwidth constraint on the traffic class.";
6848 }
6849 description
6850 "List of class of services.";
6851 }
6852 description
6853 "Container for list of class of services.";
6854 }
6855 }
6856 }
6857 description
6858 "Qos profile configuration.";
6859 }
6860 description
6861 "QoS configuration.";
6862 }
6863 description
6864 "This grouping defines QoS parameters
6865 for a site";
6866 }
6868 grouping site-service {
6869 container service {
6870 uses site-service-qos-profile;
6871 uses site-service-mpls;
6872 description
6873 "Service parameters on the attachment.";
6875 }
6876 description
6877 "Grouping for Service parameters.";
6878 }
6880 grouping site-service-mpls {
6881 container carrierscarrier {
6882 if-feature carrierscarrier;
6883 leaf signaling-type {
6884 type identityref {
6885 base carrierscarrier-type;
6886 }
6887 default "bgp";
6888 description
6889 "Carrierscarrier. By default,the signaling type is bgp.";
6890 }
6891 description
6892 "Container for carrierscarrier";
6893 }
6894 description
6895 "Grouping for carrierscarrier";
6896 }
6898 grouping site-network-access-service {
6899 container service {
6900 uses site-service-basic;
6901 uses site-service-qos-profile;
6902 uses site-service-mpls;
6903 description
6904 "Container for service";
6905 }
6906 description
6907 "Grouping for service.";
6908 }
6910 grouping vpn-profile-cfg {
6911 container valid-provider-identifiers {
6912 list cloud-identifier {
6913 if-feature cloud-access;
6914 key "id";
6915 leaf id {
6916 type string;
6917 description
6918 "Identification of cloud service.
6919 Local administration meaning.";
6920 }
6921 description
6922 "List for Cloud Identifiers.";
6924 }
6925 list qos-profile-identifier {
6926 key "id";
6927 leaf id {
6928 type string;
6929 description
6930 "Identification of the QoS Profile to be used.
6931 Local administration meaning.";
6932 }
6933 description
6934 "List for QoS Profile Identifiers.";
6935 }
6936 list bfd-profile-identifier {
6937 key "id";
6938 leaf id {
6939 type string;
6940 description
6941 "Identification of the SP BFD Profile to be used.
6942 Local administration meaning.";
6943 }
6944 description
6945 "List for BFD Profile identifiers.";
6946 }
6947 list remote-carrier-identifier {
6948 key "id";
6949 leaf id {
6950 type string;
6951 description
6952 "Identification of the remote carrier name to be used.
6953 Local administration meaning.";
6954 }
6955 description
6956 "List for remote carrier identifiers.";
6957 }
6958 nacm:default-deny-write;
6959 description
6960 "Container for Valid Provider Identifies.";
6961 }
6962 description
6963 "Grouping for VPN Profile configuration.";
6964 }
6966 grouping site-network-access-top-level-cfg {
6967 leaf type {
6968 type identityref {
6969 base site-network-access-type;
6970 }
6971 default "point-to-point";
6972 description
6973 "Describes the type of connection, e.g.,
6974 point-to-point or multipoint.";
6975 }
6976 choice location-flavor {
6977 case location {
6978 when "derived-from-or-self(../../management/type, 'l2vpn-svc:customer-managed')" {
6979 description
6980 "Applicable only for customer-managed device.";
6981 }
6982 leaf location-reference {
6983 type leafref {
6984 path "../../../locations/location/location-id";
6985 }
6986 description
6987 "Location of the site-network-access.";
6988 }
6989 }
6990 case device {
6991 when "derived-from-or-self(../../management/type, 'l2vpn-svc:provider-managed')"+
6992 " or derived-from-or-self(../../management/type, 'l2vpn-svc:co-managed')" {
6993 description
6994 "Applicable only for provider-managed
6995 or co-managed device.";
6996 }
6997 leaf device-reference {
6998 type leafref {
6999 path "../../../devices/device/device-id";
7000 }
7001 description
7002 "Identifier of CE to use.";
7003 }
7004 }
7005 mandatory true;
7006 description
7007 "Choice of how to describe the site's location.";
7008 }
7009 uses access-diversity;
7010 uses site-attachment-bearer;
7011 uses site-attachment-ethernet-connection;
7012 uses site-attachment-availability;
7013 uses site-vpn-attachment;
7014 uses site-network-access-service;
7015 uses site-bum;
7016 uses site-mac-loop-prevention;
7017 uses site-acl;
7018 uses site-mac-addr-limit;
7019 description
7020 "Grouping for site network access top-level
7021 configuration.";
7022 }
7024 container l2vpn-svc {
7025 container vpn-profiles {
7026 uses vpn-profile-cfg;
7027 description
7028 "Container for VPN Profiles.";
7029 }
7030 container vpn-services {
7031 list vpn-service {
7032 key "vpn-id";
7033 leaf vpn-id {
7034 type svc-id;
7035 description
7036 "Defining a service id.";
7037 }
7038 leaf svc-type {
7039 type identityref {
7040 base service-type;
7041 }
7042 default "vpws";
7043 description
7044 "Service type. By default, the service type is VPWS.";
7045 }
7046 leaf customer-name {
7047 type string;
7048 description
7049 "Customer name.";
7050 }
7051 leaf svc-topo {
7052 type identityref {
7053 base vpn-topology;
7054 }
7055 default "any-to-any";
7056 description
7057 "Defining service topology, such as
7058 any-to-any,hub-spoke, etc.";
7059 }
7060 uses vpn-service-cloud-access;
7061 uses vpn-service-multicast;
7062 uses vpn-extranet;
7063 uses svc-preservation-grouping;
7064 leaf carrierscarrier {
7065 if-feature carrierscarrier;
7066 type boolean;
7067 default "false";
7068 description
7069 "The VPN is using CsC, and so MPLS
7070 is required.";
7071 }
7072 description
7073 "List of vpn services.";
7074 }
7075 description
7076 "Container for VPN services.";
7077 }
7078 container sites {
7079 list site {
7080 key "site-id";
7081 leaf site-id {
7082 type string;
7083 description
7084 "Identifier of the site.";
7085 }
7086 uses site-vpn-flavor;
7087 uses site-device;
7088 uses customer-location-info;
7089 uses site-management;
7090 uses site-diversity;
7091 uses site-vpn-policy;
7092 uses site-service;
7093 uses site-bum;
7094 uses site-mac-loop-prevention;
7095 uses site-acl;
7096 uses operational-requirements-ops;
7097 container site-network-accesses {
7098 list site-network-access {
7099 key "network-access-id";
7100 leaf network-access-id {
7101 type string;
7102 description
7103 "Identifier of network access";
7104 }
7105 leaf remote-carrier-name {
7106 when "derived-from-or-self(../../../site-vpn-flavor,'l2vpn-svc:site-vpn-flavor-nni')" {
7107 description
7108 "Relevant when Site vpn flavor is site-vpn-flavor-nni.";
7109 }
7110 type leafref {
7111 path "/l2vpn-svc/vpn-profiles/valid-provider-identifiers/remote-carrier-identifier/id";
7112 }
7113 description
7114 "Remote carrier name. The remote-carrier-name
7115 must be configured only when site-vpn-flavor
7116 is set to site vpn-flavor-nni. If it is not
7117 set,it indicates customer does not know remote
7118 carrier name beforehand.";
7119 }
7120 uses site-network-access-top-level-cfg;
7121 description
7122 "List of Site Network Accesses.";
7123 }
7124 description
7125 "Container of port configurations.";
7126 }
7127 description
7128 "List of sites.";
7129 }
7130 description
7131 "Container of site configurations.";
7132 }
7133 description
7134 "Container for L2VPN service.";
7135 }
7136 }
7137
7139 9. Security Considerations
7141 The YANG modules defined in this document MAY be accessed via the
7142 RESTCONF protocol [RFC8040] or NETCONF protocol ([RFC6241]). The
7143 lowest RESTCONF or NETCONF layer requires that the transport-layer
7144 protocol provides both data integrity and confidentiality, see
7145 Section 2 in [RFC8040] and [RFC6241]. The lowest NETCONF layer is
7146 the secure transport layer, and the mandatory-to-implement secure
7147 transport is Secure Shell (SSH)[RFC6242] . The lowest RESTCONF layer
7148 is HTTPS, and the mandatory-to-implement secure transport is TLS
7149 [RFC5246].
7151 The NETCONF access control model [RFC6536] provides the means to
7152 restrict access for particular NETCONF or RESTCONF users to a
7153 preconfigured subset of all available NETCONF or RESTCONF protocol
7154 operations and content.
7156 There are a number of data nodes defined in this YANG module that are
7157 writable/creatable/deletable (i.e., config true, which is the
7158 default). These data nodes may be considered sensitive or vulnerable
7159 in some network environments. Write operations (e.g., edit-config)
7160 to these data nodes without proper protection can have a negative
7161 effect on network operations. These are the subtrees and data nodes
7162 and their sensitivity/vulnerability:
7164 o /l2vpn-svc/vpn-services/vpn-service
7166 The entries in the list above include the whole vpn service
7167 configurations which the customer subscribes, and indirectly
7168 create or modify the PE and CE device configurations. Unexpected
7169 changes to these entries could lead to the service disruption and/
7170 or network misbehavior.
7172 o /l2vpn-svc/sites/site
7174 The entries in the list above include the customer site
7175 configurations. As above, unexpected changes to these entries
7176 could lead to the service disruption and/or network misbehavior.
7178 Some of the readable data nodes in this YANG module may be considered
7179 sensitive or vulnerable in some network environments. It is thus
7180 important to control read access (e.g., via get, get-config, or
7181 notification) to these data nodes. These are the subtrees and data
7182 nodes and their sensitivity/vulnerability:
7184 o /l2vpn-svc/vpn-services/vpn-service
7186 o /l2vpn-svc/sites/site
7188 The entries in the lists above include customer-proprietary or
7189 confidential information, e.g., customer-name, site location, what
7190 service the customer subscribes.
7192 The data model defines some security parameters that can be extended
7193 via augmentation as part of the customer service request; those
7194 parameters are described in Section 5.12 and Section 5.13.
7196 10. Acknowledgements
7198 Thanks to Qin Wu and Adrian Farrel for facilitating work on the
7199 initial revisions of this document. Thanks to Zonghe Huang, Wei Deng
7200 and Xiaoling Song to help review this draft.
7202 Special thanks to Jan Lindblat for his careful review of the YANG.
7204 This document has drawn on the work of the L3SM Working Group
7205 expressed in [RFC8299].
7207 11. IANA Considerations
7209 IANA is requested to assign a new URI from the IETF XML registry
7210 ([RFC3688]). The following URI is suggested:
7212 URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc
7213 Registrant Contact: L2SM WG
7214 XML: N/A, the requested URI is an XML namespace
7216 This document also requests a new YANG module name in the YANG Module
7217 Names registry ([RFC6020]) with the following suggestion:
7219 name: ietf-l2vpn-svc
7220 namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc
7221 prefix: l2vpn-svc
7222 reference: RFC XXXX
7224 12. References
7226 12.1. Normative References
7228 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
7229 Requirement Levels", BCP 14, RFC 2119,
7230 DOI 10.17487/RFC2119, March 1997,
7231 .
7233 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
7234 DOI 10.17487/RFC3688, January 2004,
7235 .
7237 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
7238 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
7239 2006, .
7241 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
7242 "Encapsulation Methods for Transport of Ethernet over MPLS
7243 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
7244 .
7246 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
7247 2 Virtual Private Networks (L2VPNs)", RFC 4664,
7248 DOI 10.17487/RFC4664, September 2006,
7249 .
7251 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
7252 LAN Service (VPLS) Using BGP for Auto-Discovery and
7253 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
7254 .
7256 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
7257 LAN Service (VPLS) Using Label Distribution Protocol (LDP)
7258 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
7259 .
7261 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
7262 (TLS) Protocol Version 1.2", RFC 5246,
7263 DOI 10.17487/RFC5246, August 2008,
7264 .
7266 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
7267 the Network Configuration Protocol (NETCONF)", RFC 6020,
7268 DOI 10.17487/RFC6020, October 2010,
7269 .
7271 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
7272 Aissaoui, "Segmented Pseudowire", RFC 6073,
7273 DOI 10.17487/RFC6073, January 2011,
7274 .
7276 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo,
7277 "Provisioning, Auto-Discovery, and Signaling in Layer 2
7278 Virtual Private Networks (L2VPNs)", RFC 6074,
7279 DOI 10.17487/RFC6074, January 2011,
7280 .
7282 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
7283 and A. Bierman, Ed., "Network Configuration Protocol
7284 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
7285 .
7287 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
7288 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
7289 .
7291 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
7292 Protocol (NETCONF) Access Control Model", RFC 6536,
7293 DOI 10.17487/RFC6536, March 2012,
7294 .
7296 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
7297 RFC 6991, DOI 10.17487/RFC6991, July 2013,
7298 .
7300 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module",
7301 RFC 7224, DOI 10.17487/RFC7224, May 2014,
7302 .
7304 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
7305 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
7306 eXtensible Local Area Network (VXLAN): A Framework for
7307 Overlaying Virtualized Layer 2 Networks over Layer 3
7308 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
7309 .
7311 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
7312 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
7313 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
7314 2015, .
7316 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
7317 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
7318 .
7320 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
7321 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
7322 May 2017, .
7324 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
7325 Rabadan, "Virtual Private Wire Service Support in Ethernet
7326 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
7327 .
7329 12.2. Informative References
7331 [I-D.ietf-bess-evpn-yang]
7332 Brissette, P., Sajassi, A., Shah, H., Li, Z.,
7333 Tiruveedhula, K., Hussain, I., and J. Rabadan, "Yang Data
7334 Model for EVPN", draft-ietf-bess-evpn-yang-03 (work in
7335 progress), October 2017.
7337 [I-D.ietf-bess-l2vpn-yang]
7338 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B.,
7339 and K. Tiruveedhula, "YANG Data Model for MPLS-based
7340 L2VPN", draft-ietf-bess-l2vpn-yang-07 (work in progress),
7341 October 2017.
7343 [IEEE-802-1ag]
7344 IEEE, "802.1ag - Connectivity Fault Management", December
7345 2007.
7347 [IEEE-802-1D]
7348 IEEE, "802.1D-2004 - MAC Bridges", June 2004.
7350 [ITU-T-Y-1731]
7351 ITU-T, "Recommendation Y.1731 - OAM functions and
7352 mechanisms for Ethernet based networks", February 2008.
7354 [MEF-23-2]
7355 MEF Forum, "Implementation Agreement MEF 23.2 : Carrier
7356 Ethernet Class of Service - Phase 3", August 2016.
7358 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
7359 Virtual Private Networks Using BGP for Auto-Discovery and
7360 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012,
7361 .
7363 [RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N.,
7364 Henderickx, W., and A. Isaac, "Requirements for Ethernet
7365 VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014,
7366 .
7368 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module
7369 Classification", RFC 8199, DOI 10.17487/RFC8199, July
7370 2017, .
7372 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
7373 "YANG Data Model for L3VPN Service Delivery", RFC 8299,
7374 DOI 10.17487/RFC8299, January 2018,
7375 .
7377 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
7378 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
7379 .
7381 Appendix A. Changes Log
7383 Changes in v-(01) include:
7385 o Reference Update.
7387 o Fix figure in section 3.3 and section 3.4
7389 o Consider VPWS, VPLS, EVPN as basic service and view EVC related
7390 service as additional service.
7392 o Model structure change, move two customer information related
7393 parameter into VPN Services container, remove 'customer-info
7394 'container
7396 o Redefine vpn-type to cover VPWS, VPLS, EVPN service;
7397 o Consolidate EVC and OVC container, make them optional since for
7398 some L2VPN service such as EVPN sevice, OVC, EVC are not needed.
7400 o Add service and security filter under sites container and change
7401 "ports" into "site-network-accesses" to get consistent with L3SM
7402 and also make it generalized.
7404 o Fixed usage examples in the l2sm model draft.
7406 Changes in v-(02) include:
7408 o Fix figure 3 and figure 4 in section 3.4 to apply IEEE802.3 on the
7409 segment between C and CE and apply IEEE802.1Q on the segment
7410 between CE and PE.
7412 o Update Signaling Option section and add L2TP support and classify
7413 the signaling option type into BGP-L2VPN, BGP-EVPN, LDP-PWE, L2TP-
7414 PW.
7416 o Add Multicast Support in section 5.2.13, section 5.10.3 and move
7417 the text in BUM Storm Control section into section 5.10.3.
7419 o Add new section 5.3.1, section 5.4, section 5.5, section 5.6,
7420 section 5.7, section 5.8, section 5.11to explain the usage of
7421 constraint parameters and service placement related parameters.
7423 o Add new section 5.1 and 5.14 to allow augmentation and external ID
7424 References.
7426 o Add new section to discuss inter-AS support and inter-provider
7427 support with NNI and EVC, OVC.
7429 o Update Service Section 5.10 and define four type for svc-input-
7430 bandwidth and svc-output-bandwidth and add guaranteed-bw-percent
7431 parameter and related description.
7433 o Add extranet VPN support.
7435 o Remove duplicated parameters from cloud access.
7437 o Move L2CP control plane protocol parameters under connection.
7439 o Update section 5.3.3.2 to address loop avoidance issue and divide
7440 section 5.3.3.2 into Physical interface section, LAG interface
7441 section and Addressing Section.
7443 o Reference Update.
7445 Changes in v-(03) include:
7447 o Introduce additional terminology.
7449 o Modify figure 5 to get consistent with RFC8049.
7451 o Add end to end Multi-segment connectivity support and site-vpn-
7452 flavor-e2e attribute.
7454 o Add usage example to explain how to use EVC and OVC.
7456 o Discuss applicability of this model to inter-provider support.
7458 o Reduce redundant parameters related to encapsulation type and
7459 Ethernet type in the model.
7461 o Clarify the relationship between guarantee-bandwidth-percent and
7462 CIR, EIR and PIR.
7464 o Modify model structure for VPN service to make it consistent with
7465 the text in section 5.
7467 o Remove Sub-inf parameter since it is similar to QinQ parameter.
7469 o Add "direction" parameter for QoS profile.
7471 o Update XML example and figure in section 5.16.
7473 Changes in v-(04) include:
7475 o Remove EVC and OVC related attributes.
7477 o Remove Metro-Network related attributes.
7479 o Remove Customer Account Number attributes.
7481 o Update L2VPN service Types.
7483 o Remove load banlancing options since access-priority within
7484 availability can be used to support load balancing.
7486 o Remove service protection attribute since we have site diversity
7487 attributes.
7489 o Move SVC-MTU to service level.
7491 o Move CVLAN to Service Mapping to Network Access Level.
7493 o Add two new parameters under qos-classification-policy.
7495 o Remove Security Container.
7497 o Remove IPv4/IPv6 prefix filter from VPN policy.
7499 o Add Delivery mode support at service level.
7501 Changes in v-(05) include:
7503 o Change type from 16-bit integer to string for the leaf id under
7504 "qos-classification-policy" container.
7506 o Stick to using ordered-by user and remove inefficiency to map
7507 service model sequence number to device model sequence number.
7509 o Remove mandating the use of deviations and add "if-feature target-
7510 sites" under the leaf-list target-sites in section 5.10.2.
7512 o RFC2119 language changes on operation of the management system in
7513 Section 5.6,3rd paragraph and section 7.
7515 o Fix incomplete description statements.
7517 o Change the use of the absolute paths to the use of relative paths
7518 in the "must" statement or "path" statement for vpn-policy-id leaf
7519 node, management container, location leaf node, devices container,
7520 location case, location-reference leaf, device case, device-
7521 reference leaf to make configuration is only applicable to the
7522 current sites.
7524 o Change "must" statement to "when" statement for management
7525 container device container.
7527 o Define new grouping vpn-profile-cfg for all the identifiers
7528 provided by SP to the customer. The identifiers include cloud-
7529 identifier, std-qos-profile.
7531 o Add in the XPATH string representation and remove unqualified
7532 name.
7534 o Remove redundant parameters in the cloud access.
7536 o Add a few text to clarify what the site is in section 6.3.
7538 o Add multi-filter and multi-VPN per entry support for VPN policy.
7540 o Modify description for svc-bandwidth leaf to make it consistent
7541 with the text in section 5.10.1.
7543 o Add text to clarify the way to achieve Per-VPN QoS policy.
7545 o Change guaranteed-bw-percent data type from uint8 to decimal64.
7547 Authors' Addresses
7549 Bin Wen
7550 Comcast
7552 Email: bin_wen@comcast.com
7554 Giuseppe Fioccola (editor)
7555 Telecom Italia
7557 Email: giuseppe.fioccola@telecomitalia.it
7559 Chongfeng Xie
7560 China Telecom
7562 Email: xiechf@ctbri.com.cn
7564 Luay Jalil
7565 Verizon
7567 Email: luay.jalil@verizon.com