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