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