idnits 2.17.1
draft-ietf-l2sm-l2vpn-service-model-00.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 3 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 719 has weird spacing: '...lo-addr inet...'
== Line 744 has weird spacing: '...nt-type iden...'
== Line 799 has weird spacing: '...-number uin...'
-- The document date (February 26, 2017) is 2615 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: 'LAG-interface-number' is mentioned on line 798, but
not defined
== Missing Reference: 'MAID' is mentioned on line 966, but not defined
** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341)
== Outdated reference: A later version (-07) exists of
draft-ietf-bess-evpn-yang-01
== Outdated reference: A later version (-10) exists of
draft-ietf-bess-l2vpn-yang-02
== Outdated reference: A later version (-06) exists of
draft-wu-opsawg-service-model-explained-05
Summary: 1 error (**), 0 flaws (~~), 10 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
5 Expires: August 30, 2017 Telecom Italia
6 C. Xie
7 China Telecom
8 L. Jalil
9 Verizon
10 February 26, 2017
12 A YANG Data Model for L2VPN Service Delivery
13 draft-ietf-l2sm-l2vpn-service-model-00
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 use specific
25 configurations models to configure the different network elements to
26 deliver the service. How configuration of network elements is done
27 is out of scope of the document.
29 The data model in this document includes support for point-to-point
30 Virtual Private Wire Services (VPWS) and multipoint Virtual Private
31 LAN services (VPLS) that use Pseudowires signaled using the Label
32 Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as
33 described in RFC4761 and RFC6624.
35 Requirements Language
37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
39 document are to be interpreted as described in [RFC2119].
41 Status of This Memo
43 This Internet-Draft is submitted in full conformance with the
44 provisions of BCP 78 and BCP 79.
46 Internet-Drafts are working documents of the Internet Engineering
47 Task Force (IETF). Note that other groups may also distribute
48 working documents as Internet-Drafts. The list of current Internet-
49 Drafts is at http://datatracker.ietf.org/drafts/current/.
51 Internet-Drafts are draft documents valid for a maximum of six months
52 and may be updated, replaced, or obsoleted by other documents at any
53 time. It is inappropriate to use Internet-Drafts as reference
54 material or to cite them other than as "work in progress."
56 This Internet-Draft will expire on August 30, 2017.
58 Copyright Notice
60 Copyright (c) 2017 IETF Trust and the persons identified as the
61 document authors. All rights reserved.
63 This document is subject to BCP 78 and the IETF Trust's Legal
64 Provisions Relating to IETF Documents
65 (http://trustee.ietf.org/license-info) in effect on the date of
66 publication of this document. Please review these documents
67 carefully, as they describe your rights and restrictions with respect
68 to this document. Code Components extracted from this document must
69 include Simplified BSD License text as described in Section 4.e of
70 the Trust Legal Provisions and are provided without warranty as
71 described in the Simplified BSD License.
73 Table of Contents
75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
76 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
77 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 4
78 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
79 3. The Layer 2 VPN Service Model . . . . . . . . . . . . . . . . 6
80 3.1. Applicability of the Layer 2 VPN Service Model . . . . . 6
81 3.2. Layer 2 VPN Service Types . . . . . . . . . . . . . . . . 7
82 3.3. Layer 2 VPN Service Network Topology . . . . . . . . . . 8
83 3.4. Layer 2 VPN Ethernet Virtual Circuit Construct . . . . . 9
84 4. Service Data Model Usage . . . . . . . . . . . . . . . . . . 11
85 5. Design of the Data Model . . . . . . . . . . . . . . . . . . 13
86 5.1. Overview of Main Components of the Model . . . . . . . . 22
87 5.1.1. Customer Information . . . . . . . . . . . . . . . . 23
88 5.1.2. VPN Service Overview . . . . . . . . . . . . . . . . 23
89 5.1.2.1. Service Type . . . . . . . . . . . . . . . . . . 24
90 5.1.2.2. Ethernet Connection Service Type . . . . . . . . 25
91 5.1.2.3. VPN Service Topology . . . . . . . . . . . . . . 25
92 5.1.2.4. Cloud Access . . . . . . . . . . . . . . . . . . 25
93 5.1.2.5. Metro Network Partition . . . . . . . . . . . . . 26
94 5.1.2.6. Load Balance Option . . . . . . . . . . . . . . . 26
95 5.1.2.7. SVLAN ID Ethernet Tag . . . . . . . . . . . . . . 27
96 5.1.2.8. CVLAN ID To EVC MAP . . . . . . . . . . . . . . . 27
97 5.1.2.9. Service Level MAC Limit . . . . . . . . . . . . . 27
98 5.1.2.10. Service Protection . . . . . . . . . . . . . . . 28
99 5.1.3. site . . . . . . . . . . . . . . . . . . . . . . . . 28
100 5.1.3.1. Generic Site Objects . . . . . . . . . . . . . . 29
101 6. Interaction with Other YANG Modules . . . . . . . . . . . . . 42
102 7. Service Model Usage Example . . . . . . . . . . . . . . . . . 43
103 8. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 48
104 9. Security Considerations . . . . . . . . . . . . . . . . . . . 112
105 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 113
106 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 113
107 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 113
108 12.1. Normative References . . . . . . . . . . . . . . . . . . 113
109 12.2. Informative References . . . . . . . . . . . . . . . . . 115
110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 115
112 1. Introduction
114 This document defines a YANG data model for Layer 2 VPN (L2VPN)
115 service configuration. This model is intended to be instantiated at
116 management system to allow a user (a customer or an application) to
117 request the service from a service provider. This model is not a
118 configuration model to be used directly on network elements, but
119 provides an abstracted view of the L2VPN service configuration
120 components. It is up to a management system to take this as an input
121 and use specific configurations models to configure the different
122 network elements to deliver the service. How configuration of
123 network elements is done is out of scope of the document.
125 The data model in this document includes support for point-to-point
126 Virtual Private Wire Services (VPWS) and multipoint Virtual Private
127 LAN services (VPLS) that use Pseudowires signaled using the Label
128 Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as
129 described in [RFC4761] and [RFC6624].
131 Further discussion of the way that services are modelled in YANG and
132 of the relationship between "customer service models" like the one
133 described in this document and configuration models can be found in
134 [I-D.wu-opsawg-service-model-explained]. Section 4 and Section 6
135 also provide more information of how this service model could be used
136 and how it fits into the overall modelling architecture.
138 1.1. Terminology
140 The following terms are defined in [RFC6241] and are not redefined
141 here:
143 o client
144 o configuration data
146 o server
148 o state data
150 The following terms are defined in [RFC6020] and are not redefined
151 here:
153 o augment
155 o data model
157 o data node
159 The terminology for describing YANG data models is found in
160 [RFC6020].
162 1.2. Tree diagram
164 A simplified graphical representation of the data model is presented
165 in Section 5.
167 The meaning of the symbols in these diagrams is as follows:
169 o Brackets "[" and "]" enclose list keys.
171 o Curly braces "{" and "}" contain names of optional features that
172 make the corresponding node conditional.
174 o Abbreviations before data node names: "rw" means configuration
175 (read-write), and "ro" state data (read-only).
177 o Symbols after data node names: "?" means an optional node and "*"
178 denotes a "list" or "leaf-list".
180 o Parentheses enclose choice and case nodes, and case nodes are also
181 marked with a colon (":").
183 o Ellipsis ("...") stands for contents of subtrees that are not
184 shown.
186 2. Definitions
188 This document uses the following terms:
190 Service Provider (SP): The organization (usually a commercial
191 undertaking) responsible for operating the network that offers VPN
192 services to clients and customers.
194 Customer Edge (CE) Device: Equipment that is dedicated to a
195 particular customer and is directly connected to one or more PE
196 devices via attachment circuits. A CE is usually located at the
197 customer premises, and is usually dedicated to a single VPN,
198 although it may support multiple VPNs if each one has separate
199 attachment circuits. The CE devices can be routers, bridges,
200 switches, or hosts.
202 Provider Edge (PE) Device: Equipment managed by the SP that can
203 support multiple VPNs for different customers, and is directly
204 connected to one or more CE devices via attachment circuits. A PE
205 is usually located at an SP point of presence (PoP) and is managed
206 by the SP.
208 Virtual Private LAN Service (VPLS): A VPLS is a provider service
209 that emulates the full functionality of a traditional Local Area
210 Network (LAN). A VPLS makes it possible to interconnect several
211 LAN segments over a packet switched network (PSN) and makes the
212 remote LAN segments behave as one single LAN.
214 Virtual Private Wire Service (VPWS): A VPWS is a point-to-point
215 circuit (i.e., link) connecting two CE devices. The link is
216 established as a logical through a packet switched network. The
217 CE in the customer network is connected to a PE in the provider
218 network via an Attachment Circuit (AC): the AC is either a
219 physical or a logical circuit. A VPWS differs from a VPLS in that
220 the VPLS is point-to-multipoint, while the VPWS is point-to-point.
221 In some implementations, a set of VPWSs is used to create a multi-
222 site L2VPN network.
224 This document uses the following abbreviations:
226 BSS: Business Support System
228 B-U-M: Broadcast-UnknownUnicast-Multicast
230 CoS: Class of Service
232 LAG: Link Aggregation Group
234 LLDP: Link Level Discovery Protocol
236 OAM: Operations, Administration, and Maintenance
237 OSS: Operations Support System
239 PDU: Protocol Data Unit
241 QoS: Quality of Service
243 UNI: User to Network Interface
245 3. The Layer 2 VPN Service Model
247 A Layer 2 VPN service is a collection of sites that are authorized to
248 exchange traffic between each other over a shared infrastructure of a
249 common technology. This Layer 2 VPN service model (L2SM) provides a
250 common understanding of how the corresponding Layer 2 VPN service is
251 to be deployed over the shared infrastructure.
253 This document presents the L2SM using the YANG data modeling language
254 [RFC6020] as a formal language that is both human-readable and
255 parsable by software for use with protocols such as NETCONF [RFC6241]
256 and RESTCONF [RFC8040].
258 This service model is limited to VPWS and VPLS based VPNs as
259 described in [RFC4761] and [RFC6624].
261 3.1. Applicability of the Layer 2 VPN Service Model
263 The L2SM defined in this document applies to both point-to-point
264 (E-Line) and multipoint-to-multipoint (E-LAN) carrier Ethernet
265 services.
267 Over the past decade, The MEF Forum (MEF) has published a series of
268 technical specifications of Ethernet virtual circuit service
269 attributes and implementation agreements between providers. Many
270 Ethernet VPN service providers worldwide have adopted these MEF
271 standards and developed backoffice tools accordingly.
273 Rather than introducing a new set of terminologies, the L2SM will
274 align with existing MEF attributes when it's applicable. Therefore,
275 service providers can easily integrate any new application that
276 leverages the L2SM data (for example, a Service Orchestrator), with
277 existing BSS/OSS toolsets. Service providers also have the option to
278 generate L2SM data for current L2VPN customer circuits already
279 deployed in the network.
281 3.2. Layer 2 VPN Service Types
283 A Layer 2 VPN circuit can be port-based, in which case any service
284 frames received from a subscriber within the contracted bandwidth
285 will be delivered to the corresponding remote site, regardless of the
286 customer VLAN value (C-tag) of the incoming frame. The service
287 frames can also be native Ethernet frames without a C-tag: in this
288 scenario, only one Ethernet Virtual Circuit (EVC) is allowed on a
289 single provider to subscriber link.
291 Contrary to the above use case, incoming customer service frames may
292 be split into multiple EVCs based on pre-arrangement between the
293 service provider and customer. Typically, C-tag of the incoming
294 frames will serve as the service delimiter for EVC multiplexing over
295 the same provider to subscriber interconnection.
297 Combining the service-multiplexing attribute with the connection type
298 (point-to-point or multipoint-to-multipoint), a Layer 2 VPN circuit
299 may fall into one of the following service types:
301 o E-Line services: Point-to-Point Layer 2 connections.
303 EPL: In its simplest form, a port-based Ethernet Private Line
304 (EPL) service provides a high degree of transparency delivering
305 all customer service frames between local and remote UNIs using
306 All-to-One Bundling. All unicast/broadcast/multicast packets
307 are delivered unconditionally over the EVC. No service
308 multiplexing is allowed on an EPL UNI.
310 EVPL: On the other hand, an Ethernet Virtual Private Line (EVPL)
311 service supports multiplexing more than one point-to-point, or
312 even other virtual private services, on the same UNI. Ingress
313 service frames are conditionally transmitted through one of the
314 EVCs based upon pre-agreed C-tag to EVC mapping. EVPL supports
315 multiple C-tags to one EVC bundling.
317 o E-LAN services: Multipoint-to-Multipoint Layer 2 connections.
319 EP-LAN: An Ethernet Private LAN Service (EP-LAN) transparently
320 connects multiple subscriber sites together with All-to-One
321 Bundling. No service multiplexing is allowed on an EP-LAN UNI.
323 EVP-LAN: Some subscribers may desire more sophisticated control
324 of data access between multiple sites. An Ethernet Virtual
325 Private LAN Service (EVP-LAN) allows multiple EVCs to be
326 connected to from one or more of the UNIs. Services frame
327 disposition is based on C-tag to EVC mapping. EVP-LAN supports
328 multiple C-tags bundled to one EVC.
330 3.3. Layer 2 VPN Service Network Topology
332 Figure 1depicts a typical service provider's physical network
333 topology. Most service providers have deployed an IP, MPLS, or
334 Segment Routing (SR) multi-service core infrastructure. Customer
335 Edge (CE) devices are placed at customer premises as demarcation
336 points that backhaul in-profile service frames from the subscriber
337 over the access network to the Provider Edge (PE) equipment. The
338 actual transport technology or physical topology between CE and PE is
339 outside the scope of the L2SM model.
341 --- ---- ---
342 | | | | | |
343 | C +---+ CE | | C |
344 | | | | --------- | |
345 --- ----\ ( ) /---
346 \ ---- ( ) ---- ---- /
347 \| | ( ) | | | |/
348 | PE +---+ IP/MPLS/SR +---+ PE +---+ CE |
349 /| | ( Network ) | | | |\
350 / ---- ( ) ---- ---- \
351 --- ----/ ( ) \---
352 | | | | ----+---- | |
353 | C +---+ CE | | | C |
354 | | | | --+-- | |
355 --- ---- | PE | ---
356 --+--
357 |
358 --+--
359 | CE |
360 --+--
361 |
362 --+--
363 | C |
364 -----
366 Figure 1: Reference Network for the Use of the L2VPN Service Model
368 From the subscriber perspective, however, all the edge networks
369 devices are connected over a simulated LAN environment as shown in
370 Figure 2. Broadcast and multicast packets are sent to all
371 participants in the same bridge domain.
373 C---+----+---+---C
374 | | |
375 | | |
376 | | |
377 C---+ C +---C
379 Figure 2: Customer View of the L2VPN
381 3.4. Layer 2 VPN Ethernet Virtual Circuit Construct
383 The base model of EVC is shown in Figure 3.
385 Subscriber edge network device (C) connects to the service provider's
386 CE equipment. The link between C and CE devices is referred as the
387 User Network Interface (UNI). For clarification, this is called the
388 UNI-C on the subscriber side and UNI-N on the provider side.
390 The service provider is obligated to deliver the original service
391 frame across the network to the remote UNI-C. All Ethernet and IP
392 header information, including (but not limit to) source and
393 destination MAC addresses, EtherType, VLAN (C-tag), Class-of-Service
394 marking (802.1p or DSCP), etc.
396 In coming service frames are first examined at UNI-N based on C-tag,
397 Class-of-Services identifier, EtherType value. Conforming packets
398 are then metered against the contractual service bandwidth. In-
399 profile packets will be delivered to the remote UNI via the Ethernet
400 Virtual Circuit (EVC), which spans between UNI-N and UNI-N.
402 When both CEs are located in the same provider's network, a single
403 operator maintains the EVC. In this case, the EVC consists only one
404 Operator Virtual Circuit (OVC).
406 Typically, the CE device at customer premises is a layer 2 Ethernet
407 switch or NID. A service provider may choose to impose an outer VLAN
408 tag (S-tag) into the received subscriber traffic following 802.1ad
409 Q-in-Q standard, especially when Layer 2 aggregation devices exist
410 between CE and PE.
412 The uplink from CE to PE is referred as an Internal Network-to-
413 Network Interface (I-NNI). When 802.1ad Q-in-Q is implemented,
414 Ethernet frames from CE to PE are double tagged with both provider
415 and subscriber VLANs (S-tag, C-tag).
417 Most service providers have deployed MPLS or SR multi-service core
418 infrastructure. Ingress service frames will be mapped to either
419 Ethernet Pseudowire (PWE) or VxLAN tunnel PE-to-PE. The details of
420 these tunneling mechanism are at the provider's discretion and not
421 part of the L2SM.
423 The service provider may also choose a Seamless MPLS approach to
424 expand the PWE or VxLAN tunnel between UNI-N to UNI-N.
426 The service provider may leverage multi-protocol BGP to auto-discover
427 and signal the PWE or VxLAN tunnel end points.
429 EVC
430 :<-------------------------------------------->:
431 : :
432 : :
433 : OVC (Optional) :
434 :<-------------------------------------------->:
435 : :
436 : :
437 : PW / VXLAN :
438 : :<-------------------------->: :
439 : : : :
440 : : : :
441 : : -------- : :
442 : : ( ) : :
443 --- ---- ---- ( ) ---- ---- ---
444 | | | | | | ( ) | | | | | |
445 | C +---+ CE +---+ PE +---+ IP/MPLS/SR +---+ PE +---+ CE +---+ C |
446 | | | | | | ( Network ) | | | | | |
447 --- ---- ---- ( ) ---- ---- ---
448 ^ ^ : ( ) : :
449 : : : -------- : :
450 UNI-C UNI-N : : :
451 : : : :
452 :<------>:<-------------------------->:<------>:
453 802.1ad IP/MPLS/SR Domain 802.1ad
454 q-in-q q-in-q
456 Figure 3: Architectural Model for EVC over a Single Network
458 Nevertheless, the remote site may be outside of the provider's
459 service territory. In this case, the provider may partner with the
460 operator of another metro network to provide service to the off-net
461 location as shown in Figure 4.
463 The first provider owns the customer relationship, thus the end-to-
464 end EVC. The EVC is comprised of two or more OVCs. The EVC is
465 partially composed of an OVC from local the UNI-C to the inter-
466 provider interface. The provider will purchase an Ethernet Access
467 (E-Access) OVC from the second operator to deliver packet to the
468 remote UNI-C.
470 The inter-connect between the two operators edge gateway (EG) devices
471 is defined as the External Network-to-Network Interface (E-NNI).
473 EVC
474 :<---------------------------------------------------->:
475 : :
476 : :
477 : OVC (Optional) :
478 :<----------------------->: :
479 : : :
480 : : :
481 : PW / VXLAN : :
482 : :<------------------>: :
483 : : : :
484 : : : :
485 : : ----- : ----- :
486 : : ( ) : ( ) :
487 - -- -- ( IP/ ) ---- ---- ( IP/ ) -- -- -
488 |C+-+CE+-+PE+--+ MPLS/ +--+Edge+--+Edge+--+ MPLS/ +--+PE+-+CE+-+C|
489 - -- -- ( SR ) |G/W | |G/W | ( SR ) -- -- -
490 ^ ^ : ( ) ---- ---- ( ) ^
491 : : : ----- ^ ^ ----- :
492 UNI UNI : ENNI ENNI :
493 C N : : : :
494 : : : : Remote
495 :<->:<------------------>:<->: Customer
496 802.1ad IP/MPLS/SR 802.1ad Site
497 q-in-q Domain q-in-q
499 Figure 4: Architectural Model for EVC over Multiple Networks
501 4. Service Data Model Usage
503 The L2VPN service model provides an abstracted interface to request,
504 configure, and manage the components of a L2VPN service. The model
505 is used by a customer who purchases connectivity and other services
506 from an SP to communicate with that SP.
508 A typical usage for this model is to be an input to an orchestration
509 layer that is responsible for translating it into configuration
510 commands for the network elements that deliver/enable the service.
511 The network elements may be routers, but also servers (like AAA) that
512 are necessary within the network.
514 The configuration of network elements may be done using the Command
515 Line Interface (CLI), or any other configuration (or "southbound")
516 interface such as NETCONF [RFC6241] in combination with device-
517 specific and protocol-specific YANG models.
519 This way of using the service model is illustrated in Figure 5 and
520 described in more detail in [I-D.wu-opsawg-service-model-explained].
521 The usage of this service model is not limited to this example: it
522 can be used by any component of the management system, but not
523 directly by network elements.
525 The usage and structure of this model should be compared to the Layer
526 3 VPN service model defined in [I-D.ietf-l3sm-l3vpn-service-model].
528 ----------------------------
529 | Customer Service Requester |
530 ----------------------------
531 |
532 L2VPN |
533 Service |
534 Model |
535 |
536 -----------------------
537 | Service Orchestration |
538 -----------------------
539 |
540 | Service +-------------+
541 | Delivery +------>| Application |
542 | Model | | BSS/OSS |
543 | V +-------------+
544 -----------------------
545 | Network Orchestration |
546 -----------------------
547 | |
548 +----------------+ |
549 | Config manager | |
550 +----------------+ | Device
551 | | Models
552 | |
553 --------------------------------------------
554 Network
556 Figure 5: Reference Architecture for the Use of the L2VPN Service
557 Model
559 Additionally, this data model can be compared with the service
560 delivery models described in [I-D.ietf-bess-l2vpn-yang] and
561 [I-D.ietf-bess-evpn-yang] as discussed in Section 6.
563 5. Design of the Data Model
565 The YANG module is divided in three main containers: customer-info,
566 vpn-services, and sites.
568 The customer-info defines global parameters for a specific customer.
570 The vpn-svc container under vpn-services defines global parameters
571 for the VPN service for a specific customer.
573 A site contains at least one port (i.e., ports providing access to
574 the sites defined in Section 5.1.3.1.8) and there may be multiple
575 ports in case of multihoming. The site to port attachment is done
576 through a bearer with a Layer 2 connection on top. The bearer refers
577 to properties of the attachment that are below layer 2 while the
578 connection refers to layer 2 protocol oriented properties. The
579 bearer may be allocated dynamically by the service provider and the
580 customer may provide some constraints or parameters to drive the
581 placement.
583 Authorization of traffic exchange is done through what we call a VPN
584 policy or VPN topology defining routing exchange rules between sites.
586 The figure below describe the overall structure of the YANG module:
588 module: ietf-l2vpn-svc
590 +--rw l2vpn-svc
591 +--rw customer-info
592 | +--rw customer-info* [customer-account-number customer-name]
593 | +--rw customer-account-number uint32
594 | +--rw customer-name string
595 | +--rw customer-operation-center
596 | +--rw customer-noc-street-address? string
597 | +--rw customer-noc-phone-number
598 | +--rw main-phone-num? uint32
599 | +--rw extension-options? uint32
600 +--rw vpn-services
601 | +--rw vpn-svc* [vpn-id]
602 | +--rw vpn-id svc-id
603 | +--rw svc-type? identityref
604 | +--rw evc-type
605 | | +--rw evc-id? svc-id
606 | | +--ro number-of-pe? uint32
607 | | +--ro number-of-site? uint32
608 | | +--rw uni-list {uni-list}?
609 | | +--rw uni-list* [network-access-id]
610 | | +--rw network-access-id string
611 | +--rw ovc-type {ovc-type}?
612 | | +--rw ovc-list* [ovc-id]
613 | | +--rw ovc-id svc-id
614 | | +--rw on-net? boolean
615 | | +--rw off-net? boolean
616 | +--rw ethernet-svc-type
617 | | +--rw (ethernet-svc-type)?
618 | | +--:(e-line)
619 | | | +--rw epl? boolean
620 | | | +--rw evpl? boolean
621 | | +--:(e-lan)
622 | | | +--rw ep-lan? boolean
623 | | | +--rw evp-lan? boolean
624 | | +--:(e-access)
625 | | +--rw access-epl? boolean
626 | | +--rw access-evpl? boolean
627 | +--rw svc-topo? identityref
628 | +--rw cloud-accesses {cloud-access}?
629 | | +--rw cloud-access* [cloud-identifier]
630 | | +--rw cloud-identifier string
631 | | +--rw (list-flavor)?
632 | | | +--:(permit-any)
633 | | | | +--rw permit-any? empty
634 | | | +--:(deny-any-except)
635 | | | | +--rw permit-site* -> /l2vpn-svc/sites/site/site-id
636 | | | +--:(permit-any-except)
637 | | | +--rw deny-site* -> /l2vpn-svc/sites/site/site-id
638 | | +--rw authorized-sites
639 | | | +--rw authorized-site* [site-id]
640 | | | +--rw site-id -> /l2vpn-svc/sites/site/site-id
641 | | +--rw denied-sites
642 | | +--rw denied-site* [site-id]
643 | | +--rw site-id -> /l2vpn-svc/sites/site/site-id
644 | +--rw ce-vlan-preservation
645 | +--rw metro-network-id
646 | | +--rw inter-mkt-service? boolean
647 | | +--rw intra-mkt* [metro-mkt-id mkt-name]
648 | | +--rw metro-mkt-id uint32
649 | | +--rw mkt-name string
650 | | +--rw ovc-id? string
651 | +--rw L2CP-control
652 | | +--rw stp-rstp-mstp? control-mode
653 | | +--rw pause? control-mode
654 | | +--rw lldp? boolean
655 | +--rw load-balance-options
656 | | +--rw fat-pw? boolean
657 | | +--rw entropy-label? boolean
658 | | +--rw vxlan-source-port? string
659 | +--rw svlan-id-ethernet-tag? string
660 | +--rw cvlan-id-to-evc-map* [evc-id type]
661 | | +--rw evc-id -> /l2vpn-svc/vpn-services/vpn-svc/vpn-id
662 | | +--rw type identityref
663 | | +--rw cvlan-id* [vid]
664 | | +--rw vid identityref
665 | +--rw service-level-mac-limit? string
666 | +--rw service-protection
667 | | +--rw protection-model
668 | | +--rw peer-evc-id
669 | +--rw sla-targets
670 +--rw sites
671 +--rw site* [site-id site-type]
672 +--rw site-id string
673 +--rw site-type identityref
674 +--rw device
675 | +--rw devices* [device-id]
676 | +--rw device-id string
677 | +--rw site-name? string
678 | +--rw management
679 | +--rw address? inet:ip-address
680 | +--rw management-transport? identityref
681 +--rw managemnt
682 | +--rw type? identityref
683 +--rw location
684 | +--rw address? string
685 | +--rw zip-code? string
686 | +--rw state? string
687 | +--rw city? string
688 | +--rw country-code? string
689 +--rw site-diversity {site-diversity}?
690 | +--rw groups
691 | +--rw group* [group-id]
692 | +--rw group-id string
693 +--rw vpn-policies
694 | +--rw vpn-policy* [vpn-policy-id]
695 | +--rw vpn-policy-id string
696 | +--rw entries* [id]
697 | +--rw id string
698 | +--rw filter
699 | | +--rw (lan)?
700 | | +--:(lan-tag)
701 | | +--rw lan-tag* string
702 | +--rw vpn
703 | +--rw vpn-id
704 | | -> /l2vpn-svc/vpn-services/vpn-svc/vpn-id
705 | +--rw site-role? identityref
706 +--rw signaling-option {signaling-option}?
707 | +--rw signaling-option* [type]
708 | +--rw type identityref
709 | +--rw mp-bgp-l2vpn
710 | | +--rw vpn-id? svc-id
711 | | +--rw type? identityref
712 | +--rw mp-bgp-evpn
713 | | +--rw vpn-id? svc-id
714 | | +--rw type? identityref
715 | | +--rw mac-learning-mode? identityref
716 | | +--rw arp-suppress? boolean
717 | +--rw t-ldp-pwe
718 | | +--rw PE-EG-list* [service-ip-lo-addr vc-id]
719 | | +--rw service-ip-lo-addr inet:ip-address
720 | | +--rw vc-id string
721 | +--rw pwe-encapsulation-type
722 | | +--rw ethernet? boolean
723 | | +--rw vlan? boolean
724 | +--rw pwe-mtu
725 | | +--rw allow-mtu-mismatch? boolean
726 | +--rw control-word
727 +--rw load-balance-options
728 | +--rw fat-pw? boolean
729 | +--rw entropy-label? boolean
730 | +--rw vxlan-source-port? string
731 +--ro actual-site-start? yang:date-and-time
732 +--ro actual-site-stop? yang:date-and-time
733 +--rw ports
734 +--rw port* [network-access-id]
735 +--rw network-access-id string
736 +--rw remote-carrier-name? string
737 +--rw access-diversity {site-diversity}?
738 | +--rw groups
739 | | +--rw fate-sharing-group-size? uint16
740 | | +--rw group* [group-id]
741 | | +--rw group-id string
742 | +--rw constraints
743 | +--rw constraint* [constraint-type]
744 | +--rw constraint-type identityref
745 | +--rw target
746 | +--rw (target-flavor)?
747 | +--:(id)
748 | | +--rw group* [group-id]
749 | | +--rw group-id string
750 | +--:(all-accesses)
751 | | +--rw all-other-accesses? empty
752 | +--:(all-groups)
753 | +--rw all-other-groups? empty
754 +--rw bearer
755 | +--rw requested-type {requested-type}?
756 | | +--rw requested-type? string
757 | | +--rw strict? boolean
758 | | +--rw request-type-profile
759 | | +--rw (request-type-choice)?
760 | | +--:(dot1q-case)
761 | | | +--rw dot1q
762 | | | +--rw physical-if? string
763 | | | +--rw vlan-id? uint16
764 | | +--:(physical-case)
765 | | +--rw physical-if? string
766 | | +--rw circuit-id? string
767 | +--rw always-on? boolean {always-on}?
768 | +--rw bearer-reference? string {bearer-reference}?
769 +--rw ethernet-connection
770 | +--rw ESI? string
771 | +--rw interface-description? string
772 | +--rw vlan
773 | | +--rw vlan-id? uint32
774 | +--rw dot1q
775 | | +--rw physical-inf? string
776 | | +--rw vlan-id? uint32
777 | +--rw qinq
778 | | +--rw s-vlan-id? uint32
779 | | +--rw c-vlan-id? uint32
780 | +--rw sub-if-id? uint32
781 | +--rw vxlan
782 | | +--rw vni-id? uint32
783 | | +--rw peer-list* [peer-ip]
784 | | +--rw peer-ip inet:ip-address
785 | +--rw phy-interface
786 | | +--rw port-number? uint32
787 | | +--rw port-speed? uint32
788 | | +--rw mode? neg-mode
789 | | +--rw phy-mtu? uint32
790 | | +--rw flow-control? string
791 | | +--rw encapsulation-type? enumeration
792 | | +--rw ethertype? string
793 | | +--rw lldp? boolean
794 | | +--rw oam-802.3AH-link {oam-3ah}?
795 | | | +--rw enable? boolean
796 | | +--rw uni-loop-prevention? boolean
797 | +--rw LAG-interface
798 | +--rw LAG-interface* [LAG-interface-number]
799 | +--rw LAG-interface-number uint32
800 | +--rw LACP
801 | +--rw LACP-state? boolean
802 | +--rw LACP-mode? boolean
803 | +--rw LACP-speed? boolean
804 | +--rw mini-link? uint32
805 | +--rw system-priority? uint16
806 | +--rw Micro-BFD {Micro-BFD}?
807 | | +--rw Micro-BFD-on-off? enumeration
808 | | +--rw bfd-interval? uint32
809 | | +--rw bfd-hold-timer? uint32
810 | +--rw bfd {bfd}?
811 | | +--rw bfd-enabled? boolean
812 | | +--rw (holdtime)?
813 | | +--:(profile)
814 | | | +--rw profile-name? string
815 | | +--:(fixed)
816 | | +--rw fixed-value? uint32
817 | +--rw Member-link-list
818 | | +--rw member-link* [name]
819 | | +--rw name string
820 | | +--rw port-speed? uint32
821 | | +--rw mode? neg-mode
822 | | +--rw mtu? uint32
823 | | +--rw oam-802.3AH-link {oam-3ah}?
824 | | +--rw enable? boolean
825 | +--rw flow-control? string
826 | +--rw encapsulation-type? enumeration
827 | +--rw ethertype? string
828 | +--rw lldp? boolean
829 +--rw L2CP-control
830 | +--rw stp-rstp-mstp? control-mode
831 | +--rw pause? control-mode
832 | +--rw lacp-lamp? control-mode
833 | +--rw link-oam? control-mode
834 | +--rw esmc? control-mode
835 | +--rw l2cp-802.1x? control-mode
836 | +--rw e-lmi? control-mode
837 | +--rw lldp? boolean
838 | +--rw ptp-peer-delay? control-mode
839 | +--rw garp-mrp? control-mode
840 | +--rw provider-bridge-group? control-mode
841 | +--rw provider-bridge-mvrp? control-mode
842 +--rw evc-mtu? uint32
843 +--rw availability
844 | +--rw (redundancy-mode)?
845 | +--:(single-active)
846 | | +--rw single-active? boolean
847 | +--:(all-active)
848 | +--rw all-active? boolean
849 +--rw vpn-attachment
850 | +--rw device-id? string
851 | +--rw management
852 | | +--rw address-family? identityref
853 | | +--rw address? inet:ip-address
854 | +--rw (attachment-flavor)
855 | +--:(vpn-id)
856 | +--rw vpn-id?
857 | | -> /l2vpn-svc/vpn-services/vpn-svc/vpn-id
858 | +--rw site-role? identityref
859 +--rw service
860 | +--rw svc-input-bandwidth {input-bw}?
861 | | +--rw input-bandwidth* [id type]
862 | | +--rw id string
863 | | +--rw type identityref
864 | | +--rw evc-id? svc-id
865 | | +--rw CIR? uint32
866 | | +--rw CBS? uint32
867 | | +--rw EIR? uint32
868 | | +--rw EBS? uint32
869 | | +--rw CM? uint32
870 | +--rw svc-output-bandwidth {output-bw}?
871 | | +--rw output-bandwidth* [id type]
872 | | +--rw id string
873 | | +--rw type identityref
874 | | +--rw evc-id? svc-id
875 | | +--rw CIR? uint32
876 | | +--rw CBS? uint32
877 | | +--rw EIR? uint32
878 | | +--rw EBS? uint32
879 | | +--rw CM? uint32
880 | +--rw svlan-id-ethernet-tag? string
881 | +--rw cvlan-id-to-evc-map* [evc-id type]
882 | | +--rw evc-id
883 | | | -> /l2vpn-svc/vpn-services/vpn-svc/vpn-id
884 | | +--rw type identityref
885 | | +--rw cvlan-id* [vid]
886 | | +--rw vid identityref
887 | +--rw service-level-mac-limit? string
888 | +--rw service-multiplexing? boolean
889 | +--rw qos {qos}?
890 | +--rw qos-classification-policy
891 | | +--rw rule* [id]
892 | | +--rw id uint16
893 | | +--rw (match-type)?
894 | | | +--:(match-flow)
895 | | | | +--rw match-flow
896 | | | | +--rw dscp? inet:dscp
897 | | | | +--rw dot1p? uint8
898 | | | | +--rw pcp? uint8
899 | | | | +--rw src-mac? yang:mac-address
900 | | | | +--rw dst-mac? yang:mac-address
901 | | | | +--rw cos-color-id
902 | | | | | +--rw device-id? string
903 | | | | | +--rw cos-label? identityref
904 | | | | | +--rw pcp? uint8
905 | | | | | +--rw dscp? inet:dscp
906 | | | | +--rw color-type? identityref
907 | | | | +--rw target-sites* svc-id
908 | | | +--:(match-phy-port)
909 | | | +--rw match-phy-port? uint16
910 | | +--rw target-class-id? string
911 | +--rw qos-profile
912 | +--rw (qos-profile)?
913 | +--:(standard)
914 | | +--rw ingress-profile? string
915 | | +--rw egress-profile? string
916 | +--:(custom)
917 | +--rw classes {qos-custom}?
918 | +--rw class* [class-id]
919 | +--rw class-id string
920 | +--rw direction? direction-type
921 | +--rw policing? identityref
922 | +--rw byte-offset? uint16
923 | +--rw perf-tier-opt? identityref
924 | +--rw rate-limit? uint8
925 | +--rw discard-percentage? uint8
926 | +--rw frame-delay
927 | | +--rw (flavor)?
928 | | +--:(lowest)
929 | | | +--rw use-low-del? empty
930 | | +--:(boundary)
931 | | +--rw delay-bound? uint16
932 | +--rw frame-jitter
933 | | +--rw (flavor)?
934 | | +--:(lowest)
935 | | | +--rw use-low-jit? empty
936 | | +--:(boundary)
937 | | +--rw delay-bound? uint32
938 | +--rw frame-loss
939 | +--rw fr-loss-rate? decimal64
940 +--rw Ethernet-Service-OAM
941 | +--rw MD-name? string
942 | +--rw MD-level? uint8
943 | +--rw cfm-802.1-ag
944 | | +--rw n2-uni-c* [MAID]
945 | | | +--rw MAID string
946 | | | +--rw mep-id? uint32
947 | | | +--rw mep-level? uint32
948 | | | +--rw mep-up-down? enumeration
949 | | | +--rw remote-mep-id? uint32
950 | | | +--rw cos-for-cfm-pdus? uint32
951 | | | +--rw ccm-interval? uint32
952 | | | +--rw ccm-holdtime? uint32
953 | | | +--rw alarm-priority-defect? identityref
954 | | | +--rw ccm-p-bits-pri? ccm-priority-type
955 | | +--rw n2-uni-n* [MAID]
956 | | +--rw MAID string
957 | | +--rw mep-id? uint32
958 | | +--rw mep-level? uint32
959 | | +--rw mep-up-down? enumeration
960 | | +--rw remote-mep-id? uint32
961 | | +--rw cos-for-cfm-pdus? uint32
962 | | +--rw ccm-interval? uint32
963 | | +--rw ccm-holdtime? uint32
964 | | +--rw alarm-priority-defect? identityref
965 | | +--rw ccm-p-bits-pri? ccm-priority-type
966 | +--rw y-1731* [MAID]
967 | +--rw MAID string
968 | +--rw mep-id? uint32
969 | +--rw type? identityref
970 | +--rw remote-mep-id? uint32
971 | +--rw message-period? uint32
972 | +--rw measurement-interval? uint32
973 | +--rw cos? uint32
974 | +--rw loss-measurement? boolean
975 | +--rw synthethic-loss-measurement? boolean
976 | +--rw delay-measurement
977 | | +--rw enable-dm? boolean
978 | | +--rw two-way? boolean
979 | +--rw frame-size? uint32
980 | +--rw session-type? enumeration
981 +--rw security-filtering
982 +--rw mac-loop-prevention
983 | +--rw frequency? uint32
984 | +--rw protection-type? identityref
985 | +--rw number-retries? uint32
986 +--rw access-control-list
987 | +--rw mac* [mac-address]
988 | +--rw mac-address yang:mac-address
989 +--rw mac-addr-limit
990 | +--rw exceeding-option? uint32
991 +--rw B-U-M-storm-control
992 +--rw BUM-overall-rate? uint32
993 +--rw BUM-rate-per-type* [type]
994 +--rw type identityref
995 +--rw rate? uint32
997 Figure 6
999 5.1. Overview of Main Components of the Model
1001 The L2SM model is structured in a way that allows the provider to
1002 list multiple circuits of various service types for the same
1003 subscriber.
1005 5.1.1. Customer Information
1007 The "customer-info" container contains essential information to
1008 identify the subscriber.
1010 "customer-account-number" is an internal alphanumerical number
1011 assigned by the service provider to identify the subscriber. It MUST
1012 be unique within the service provider's OSS/BSS system. The actual
1013 format depends on the system tool the provider uses. "customer-name"
1014 is in a more readable form.
1016 The subscriber operation center and main contact number are also
1017 listed here for reference purpose.
1019 5.1.2. VPN Service Overview
1021 A vpn-service list item contains generic informations about the VPN
1022 service. The vpn-id of the vpn-service refers to an internal
1023 reference for this VPN service. This identifier is purely internal
1024 to the organization responsible for the VPN service.
1026 A vpn-service is composed of some characteristics:
1028 Service Type (vpn-type): Used to indicate service Type. The
1029 identifier is a string allowing to any encoding for the local
1030 administration of the VPN service.
1032 Ethernet Connection Service Type (eth-svc-type): used to identify
1033 supported Ethernet Connection Service Types.
1035 Cloud Access (cloud-access): All sites in the L2VPN MUST be
1036 authorized to access to the cloud.The cloud-access container
1037 provides parameters for authorization rules. A cloud identifier
1038 is used to reference the target service. This identifier is local
1039 to each administration.
1041 Service Topology (svc-topo): Used to identify the type of VPN
1042 service topology is required for configuration.
1044 Metro Network Partition: Used by service provide to divide the
1045 network into several administrative domains.
1047 VPN Signaling (vpn-signaling-option): Defines which protocol or
1048 signaling must be activated between the subscriber and the
1049 provider.
1051 Load Balance (load-balance-option): Intended to capture the load-
1052 balance agreement between the subscriber and provider.
1054 SVLAN ID Ethernet Tag: Used to identify the service-wide "normalized
1055 S-tag".
1057 CVLAN ID To EVC MAP: Contains the list of customer vlans to the
1058 service mapping in a free-form format. In most cases, this will
1059 be the VLAN access-list for the inner 802.1q tags.
1061 Service Level MAC Limit: Contains the subscriber MAC address limit
1062 and exceeding action information.
1064 Service Protection (svc-protection): Capture the desired service
1065 protection agreement between subscriber and provider.
1067 5.1.2.1. Service Type
1069 The "svc-type" supports two service types: one for EVC (Ethernet
1070 Virtual Connection) and the other for OVC (Operator Virtual
1071 Connection). These two parameters are not mutually exclusive.
1072 Depending on the service-type, a Layer 2 VPN service may be
1073 identified by EVCtype, OVCtype, or both. E-Line and E-LAN providers
1074 shall have an EVC-ID assigned to the UNI-to-UNI circuit. If the
1075 service has remote UNIs in an off-net partner's network, there will
1076 be one OVC-ID for the on-net segment between the local UNI and the
1077 E-NNI interconnect, and one OVC-ID for each off-net segment from
1078 E-NNI to the remote UNI.
1080 E-Access, on the other hand, is an OVC-based service. The E-Access
1081 service provider will assign an OVC-ID for the circuit between UNI
1082 and E-NNI.
1084 New service types could be added by augmentation.
1086 5.1.2.1.1. EVC
1088 The "evc" case contains an "evc-id" leaf and "uni-list" container.
1089 And the "vpn-id" will be associated with the "evc-id". Only one
1090 "evc-id" is allowed for each "vpn-id". The "evc-id" leaf will be
1091 specified for E-Line and E-LAN service types. "uni-list" will
1092 specify the UNI list associated with the same EVC service.
1094 The EVC-ID is intended to be a structured string. Each service
1095 provider can decide the nomenclature in its network. In addition,
1096 "number of PEs" and "number of sites" can be specified under the
1097 "evc" container.
1099 5.1.2.1.2. OVC
1101 The "ovc" case contains "ovc-list". For each "ovc-list" entry, there
1102 are two boolean subcases ("on-net" and "off-net") and one "ovc-id"
1103 leaf is specified.
1105 For E-Access or services with off-net UNIs, the "on-net" leaf MUST be
1106 marked TRUE, and the "ovc-id" will be specified.
1108 In case of E-Access, the "vpn-id" will be associated with the on-net
1109 "ovc-id". Only one on-net "ovc-id" is allowed for each "vpn-id".
1111 If the service is E-Line or E-LAN with remote UNIs, there will be
1112 one, and only one, on-net "ovc-id" and a list of off-net "ovc-id"
1113 objects for the remote UNIs. However, the "vpn-id" is still
1114 associated with the "evc-id". Only one "evc-id" is allowed for each
1115 "vpn-id".
1117 5.1.2.2. Ethernet Connection Service Type
1119 The "ethernet-svc-type" group contains all supported Ethernet
1120 connection service types. One, and only one, "ethernet-svc-type" is
1121 selected for each "vpn-id".
1123 The currently supported Ethernet Connection service types are listed
1124 in Section 3.2. New Ethernet Connection service types can be added
1125 in the future.
1127 5.1.2.3. VPN Service Topology
1129 The type of VPN service topology can be used for configuration if
1130 needed. The module currently supports: any-to-any, hub and spoke
1131 (where hubs can exchange traffic), and hub and spoke disjoint (where
1132 hubs cannot exchange traffic). New topologies could be added by
1133 augmentation. By default, the any-to-any VPN service topology is
1134 used.
1136 5.1.2.4. Cloud Access
1138 This model provides cloud access configuration through the cloud-
1139 access container. The usage of cloud-access is targeted for public
1140 cloud and Internet Access. The cloud-access container provides
1141 parameters for authorization rules.
1143 Private cloud access may be addressed through the site contianer as
1144 described in Section 5.1.3 with the use consistent with sites of type
1145 E-NNI.
1147 A cloud identifier is used to reference the target service. This
1148 identifier is local to each administration.
1150 5.1.2.5. Metro Network Partition
1152 Some service providers may divide their networks into multiple
1153 administrative domains. And a Layer 2 VPN service may span across
1154 more than one metro network belonging to the same service provider.
1155 The optional "metro-network-id" container is intended be used by
1156 these multi-domain providers to differentiate intra-market versus
1157 inter-market services.
1159 When the "inter-mkt-service" leaf is marked TRUE, multiple associated
1160 "metro-mkt-id"s will be listed. Otherwise, the service is intra-
1161 domain and only one "metro-mkt-id" is allowed.
1163 5.1.2.6. Load Balance Option
1165 As the subscribers start to deploy more 10G or 100G Ethernet
1166 equipment in their network, the demand for high bandwidth Ethernet
1167 connectivity services increases. Along with the great revenue
1168 opportunities, these high bandwidth service requests also pose
1169 challenges on capacity planning and service delivery in the
1170 provider's network, especially when the contractual bandwidth is at,
1171 or close to, the speed of physical links of the service provider's
1172 core network. Because of the encapsulation overhead, the provider
1173 cannot deliver the throughput in the service level agreement over a
1174 single link. Although there may be bundled Nx10G or Nx100G
1175 aggregation links between core network elements, or Equal Cost
1176 Multiple Paths (ECMP) in the network, an Ethernet-over-MPLS (EoMPLS)
1177 PWE or VxLAN circuit is considered a single flow to a router or
1178 switch which uses the normal IP five-tuples in the hashing algorithm.
1180 Without burdening the core routers with additional processing of deep
1181 inspection into the payload, the service provider now has the option
1182 of inserting a flow or entropy label into the EoMPLS frames, or using
1183 different source UDP ports in case of VxLAN/EVPN, at ingress PE to
1184 facility load-balancing on the subsequent nodes along the path. The
1185 ingress PE is in a unique position to see the actual unencapsulated
1186 service frames and identify data flows based on the original Ethernet
1187 and IP header.
1189 On the other hand, not all Layer 2 Ethernet VPNs are suited for load-
1190 balancing across diverse ECMP paths. For example, a Layer 2 Ethernet
1191 service transported over a single RSVP signaled Label Switched Path
1192 will not take multiple ECMP routes. Or if the subscriber is
1193 concerned about latency/jitter, then diverse path load-balancing can
1194 be undesirable.
1196 The optional "load-balance-option" container is used to capture the
1197 load-balancing agreement between the subscriber and the provider. If
1198 the "load-balance" Boolean leaf is marked TRUE, then one of the
1199 following load-balance methods can be selected: "fat-pw", "entropy-
1200 label", or "vxlan-source-udp-port".
1202 5.1.2.7. SVLAN ID Ethernet Tag
1204 Service providers have the option of inserting an outer VLAN tag (the
1205 S-tag) into the service frames from the subscriber to improve service
1206 scalability and customer VLAN transparency.
1208 Ideally, all external interfaces (UNI and E-NNI) associated with a
1209 given service will have the same S-tag assigned. However, this may
1210 not always be the case. Traffic with all attachments using different
1211 S-tags will need to be "normalized" to a single service S-tag. (One
1212 example of this is a multipoint service that involves multiple off-
1213 net OVCs terminating on the same E-NNI. Each of these off-net OVCs
1214 will have a distinct S-tag which can be different from the S-tag used
1215 in the on-net part of the service.)
1217 The purpose of the optional "svlan-id-ethernet-tag" leaf is to
1218 identify the service-wide "normalized S-tag".
1220 5.1.2.8. CVLAN ID To EVC MAP
1222 When more than one service is multiplexed onto the same interface,
1223 ingress service frames are conditionally transmitted through one of
1224 the EVC/OVCs based upon pre-arranged customer VLAN to EVC mapping.
1225 Multiple customer VLANs can be bundled across the same EVC.
1227 "cvlan-id-to-evc-map", when applicable, contains the list of customer
1228 vlans to the service mapping in a free-form format. In most cases,
1229 this will be the VLAN access-list for the inner 802.1q tag (the
1230 C-tag).
1232 5.1.2.9. Service Level MAC Limit
1234 When multiple services are provided on the same network element, the
1235 MAC address table (and the Routing Information Base space for MAC-
1236 routes in the case of EVPN) is a shared common resource. Service
1237 providers may impose a maximum number of MAC addresses learned from
1238 the subscriber for a single service instance, and may specify the
1239 action when the upper limit is exceeded: drop the packet, flood the
1240 packet, or simply send a warning log message.
1242 For point-to-point services, if MAC learning is disabled then the MAC
1243 address limit is not necessary.
1245 The optional "service-level-mac-limit" container contains the
1246 subscriber MAC address limit and information to describe the action
1247 when the limit is exceeded.
1249 5.1.2.10. Service Protection
1251 Sometimes the subscriber may desire end-to-end protection at the
1252 service level for applications with high availability requirements.
1253 There are two protection schemes to offer redundant services:
1255 o 1+1 protection: In this scheme, the primary EVC or OVC will be
1256 protected by a backup EVC or OVC, typically meeting certain
1257 diverse path/fiber/site/node criteria. Both primary and
1258 protection circuits are provisioned to be in the active forwarding
1259 state. The subscriber may choose to send the same service frames
1260 across both circuits simultaneously.
1262 o 1:1 protection: In this scheme, a backup circuit to the primary
1263 circuit is provisioned. Depending on the implementation
1264 agreement, the protection circuits may either always be in active
1265 forwarding state, or may only become active when a faulty state is
1266 detected on the primary circuit.
1268 The optional "service-protection" container is used to capture the
1269 desired service protection agreement between subscriber and provider.
1271 An "peer-evc-id" should be specified when the "protection-model" has
1272 been set.
1274 5.1.3. site
1276 The "site" container is used for the provider to store information of
1277 detailed implementation arrangements made with either the subscriber
1278 or peer operators at each inter-connect location.
1280 We are restricting the L2SM to exterior interfaces only, so all
1281 internal interfaces and the underlying topology are outside the scope
1282 of L2SM.
1284 There are two possible types of external facing connections
1285 associated with an Ethernet VPN service. These give rise to two
1286 different types of site at which the connection is made:
1288 o UNI site: where a customer edge device connects to one or more VPN
1289 services.
1291 o E-NNI site: where two Ethernet service providers inter-connect
1292 with each other.
1294 Most of the attributes of a site are common to the two typs of site
1295 and so are presented just once. Divergences (that is, attributes
1296 that are specific to the type of site) are captured in type-dependent
1297 containers. In the text that follows, the phrase "between the
1298 subscriber and the provider" is used to follow the more common case
1299 of a UNI site, but should also be taken to apply to "between two
1300 providers" in the E-NNI case.
1302 For each site, there are sub-containers to maintain physical link
1303 attributes, service frame and Layer 2 control protocol frame
1304 disposition, Ethernet service OAM attributes, and agreements for
1305 service bandwidth profiles and priority levels.
1307 5.1.3.1. Generic Site Objects
1309 Typically, the following characteristics of a site interface handoff
1310 need to be documented as part of the service design:
1312 Unique identifier (site-id): An arbitrary string to uniquely
1313 identify the site within the overall network infrastructure. The
1314 format of site-id is determined by the local administration of the
1315 VPN service.
1317 Site Type (site-type): Defines the way the VPN multiplexing is done.
1319 Device (device): The customer can request one or more customer
1320 premise equipments from the service provider for a particular
1321 site.
1323 Management (management): Defines the model of management of the
1324 site, for example: type, management-transport, address.
1326 Location (location): The site location information to allow easy
1327 retrieval of data on which are the nearest available resources.
1329 Site diversity (site-diversity): Presents some parameters to support
1330 site diversity.
1332 Site signaling (signaling-options): Defines which protocol or
1333 signaling must be activated between the subscriber and the
1334 provider.
1336 Load balancing (load-balance-options): Defines the load-balancing
1337 agreement information between the subscriber and provider.
1339 Site Network Accesses (ports): Defines the list of ports to the
1340 sites and their properties: especially bearer, connection and
1341 service parameters.
1343 5.1.3.1.1. Site ID
1345 The "site-id" leaf contains an arbitrary string to uniquely identify
1346 the site within the overall network infrastructure. The format of
1347 the site-id is determined by the local administration of the VPN
1348 service.
1350 5.1.3.1.2. Site Management
1352 The "management" sub-container is intended for site management
1353 options, depending on the device ownership and security access
1354 control. The followings are three common management models:
1356 CE Provider Managed: The provider has the sole ownership of the CE
1357 device. Only the provider has access to the CE. The
1358 responsibility boundary between SP and customer is between CE and
1359 customer network. This is the most common use case.
1361 CE Customer Managed: The customer has the sole ownership of the CE
1362 device. Only the customer has access to the CE. In this model,
1363 the responsibility boundary between SP and customer is between PE
1364 and CE.
1366 CE Co-managed: The provider has ownership of the CE device and
1367 responsible for managing the CE. However, the provider grants the
1368 customer access to the CE for some configuration/monitoring
1369 purposes. In this co-managed mode, the responsibility boundary is
1370 the same as for the provider-managed model.
1372 The selected management mode is specified under the "type" leaf. The
1373 "address" leaf stores CE device management IP information. And the
1374 "management-transport" leaf is used to identify the transport
1375 protocol for management traffic: IPv4 or IPv6. Additional security
1376 options may be derived based on the particular management model
1377 selected.
1379 5.1.3.1.3. Site Location
1381 The information in the "location" sub-container under a "site" allows
1382 easy retrieval of data about which are the nearest available
1383 facilities and can be used for access topology planning. It may also
1384 be used by other network orchestration component to choose the
1385 targeted upstream PE. Location is expressed in terms of postal
1386 information.
1388 5.1.3.1.4. Site Diversity
1390 Some subscribers may request upstream PE diversity between two or
1391 more sites. These sites will share the same diversity group ID under
1392 the optional "site-diversity" sub-container.
1394 5.1.3.1.5. Site Security
1396 This sub-container presents parameters for ingress service stream
1397 admission control and encryption profile information. It is also a
1398 placeholder for further site-security options that may be added by
1399 augmentation.
1401 5.1.3.1.6. Site signaling Option
1403 The "signaling-option" container captures service-wide attributes of
1404 the L2VPN instance.
1406 Although topology discovery or network device configuration is
1407 purposely out of scope for the L2SM model, certain VPN parameters are
1408 listed here. The information can then be passed to other elements in
1409 the whole automation eco-system (such as the configuration engine)
1410 which will handle the actual service provisioning function.
1412 The "signaling-option" list uses the combination of "name" and "type"
1413 as the key. The "name" leaf is a free-form string of the VPN
1414 instance name. The "type" leaf is for the signaling protocol: BGP-
1415 L2VPN, BGP-EVPN, or T-LDP.
1417 5.1.3.1.6.1. BGP L2VPN
1419 [RFC4761] and [RFC6624] describe the mechanism to auto-discover L2VPN
1420 VPLS/VPWS end points (CE-ID or VE-ID) and signal the label base and
1421 offset at the same time to allow remote PE to derive the VPN label to
1422 be used when sending packets to the advertising router.
1424 Due to the way auto-discovery operates, PEs that have at least one
1425 attachment circuit associated with a particular VPN service do not
1426 need to be specified explicitly.
1428 In the L2SM model, only the target community (or communities) are
1429 listed at the service level.
1431 The "type" leaf under "mp-bgp-l2vpn" is an identityref to specify
1432 "vpws" or "vpls" sub-types.
1434 5.1.3.1.6.2. BGP EVPN
1436 Defined in [RFC7432], EVPN is an L2VPN technology based upon BGP MAC
1437 routing. It provides similar functionality to BGP VPWS/VPLS with
1438 improvement around redundancy, multicast optimization, provisioning,
1439 and simplicity.
1441 Due to the way auto-discovery operates, PEs that have at least one
1442 attachment circuit associated with a particular VPN service do not
1443 need to be specified explicitly.
1445 In the L2SM model, only the target community (or communities) are
1446 listed at the service level.
1448 The "type" leaf under "mp-bgp-evpn" is an identityref to specify
1449 "vpws" or "vpls" sub-types.
1451 5.1.3.1.6.3. LDP Pseudowires
1453 [RFC4762] specifies the method of using targeted LDP sessions between
1454 PEs to exchange VC label information. This requires a configured
1455 full mesh of targeted LDP sessions between all PEs.
1457 As multiple attachment circuits may terminate on a single PE, this
1458 PE-to-PE mesh is not a per-site attribute. All PEs related to the
1459 L2VPN service will be listed in the "t-ldp-pwe" with associated "vc-
1460 id".
1462 5.1.3.1.6.4. PWE Encapsulation Type
1464 Based on [RFC4448], there are two types of Ethernet services: "Port-
1465 to-Port Ethernet PW emulation" and "Vlan-to-Vlan Ethernet PW
1466 emulation", commonly referred to as Type 5 and Type 4 respectively.
1467 This concept applies to both BGP L2VPN VPWS/VPLS and T-LDP signaled
1468 PWE implementations.
1470 The "pwe-encapsulation-type" container contains two Boolean type
1471 leaves: "ethernet" and "ethernet-vlan". If "signaling-option" is
1472 "mp-bgp-l2vpn" or "t-ldp-pwe", then exactly one of "ethernet" and
1473 "ethernet-vlan" MUST be marked TRUE .
1475 5.1.3.1.6.5. PWE MTU
1477 During the signaling process of a BGP-L2VPN or T-LDP pseudowire, the
1478 pwe-mtu value is exchanged and must match at both ends. By default,
1479 the pwe-mtu is derived from physical interface MTU of the attachment
1480 circuit minus the EoMPLS transport header. In some cases, however,
1481 the physical interface on both ends of the circuit might not have
1482 identical MTU settings. For example, due to 802.1ad q-in-q
1483 operation, an I-NNI will need an extra four bytes to accommodate the
1484 S-tag. The inter-carrier E-NNI link may also have a different MTU
1485 size than the internal network interfaces.
1487 [RFC4448] requires the same MTU size on physical interfaces at both
1488 ends of the pseudowire. In actual implementations, many router
1489 vendors have provided a knob to explicitly specify the pwe-mtu, which
1490 can then be decoupled from the physical interface MTU.
1492 When there is a mismatch between the physical interface MTU and
1493 configured pwe-mtu, the "allow-mtu-mismatch" leaf in the "pwe-mtu"
1494 contained enables definition of the required behavior.
1496 5.1.3.1.6.6. Control Word
1498 A control word is an optional 4-byte field located between the MPLS
1499 label stack and the Layer 2 payload in the pseudowire packet. It
1500 plays a crucial role in Any Transport over MPLS (AToM). The 32-bit
1501 field carries generic and Layer 2 payload-specific information,
1502 including a C-bit which indicates whether the control word will
1503 present in the Ethernet over MPLS (EoMPLS) packets. If the C-bit is
1504 set to 1, the advertising PE expects the control word to be present
1505 in every pseudowire packet on the pseudowire that is being signaled.
1506 If the C-bit is set to 0, no control word is expected to be present.
1508 Whether to include control word in the pseudowire packets MUST match
1509 on PEs at both ends of the pseudowire and it is non-negotiable during
1510 the signaling process.
1512 The use of a control-word applies to pseduowires signaled using
1513 either BGP L2VPN VPWS/VPLS or T-LDP. It is a routing-instance level
1514 configuration parameter in many cases.
1516 The optional "control-word" leaf is a Boolean field in the L2SM model
1517 for the provider to explicitly specify whether the control-word will
1518 be signaled for the service instance.
1520 5.1.3.1.7. Site Load Balance Options
1522 See Section 5.1.2.6.
1524 5.1.3.1.8. Ports
1526 The L2SM includes a set of essential physical interface properties
1527 and Ethernet layer characteristics in the "port" sub-container. Some
1528 of these are critical implementation arrangements that require
1529 consent from both subscriber and provider.
1531 5.1.3.1.8.1. ID
1533 "id" is a free-form string to identify a given interface. The
1534 service provider can decide on the actual nomenclature used in the
1535 management systems.
1537 5.1.3.1.8.2. Remote Carrier Name
1539 Remote Carrier Name is the Name of Remote Carrier associated with the
1540 remote end of an E-NNI and so only applies for that type of VPN
1541 connectivity.
1543 5.1.3.1.8.3. Access Diversity
1545 In order to help the different placement scenarios, a site-network-
1546 access (i.e., port defined in Section 5.1.3.1.8) may be tagged using
1547 one or more fate sharing group identifiers. The fate sharing group
1548 identifier is a string so it can accommodate both explicit naming of
1549 a group of sites (e.g. "multihomed-set1") or a numbered identifier
1550 (e.g. 12345678). The meaning of each group-id is local to each
1551 customer administrator.
1553 5.1.3.1.8.4. Bearer
1555 The "bearer" container defines the requirements for the site
1556 attachment to the provider network that are below Layer 3.
1558 The bearer parameters will help to determine the access media to be
1559 used.
1561 5.1.3.1.8.5. Ethernet Connection
1563 The ethernet-connection container presents two sets of link
1564 attributes: physical or optional LAG interface attributes. These
1565 parameters are essential for the connection between subscriber and
1566 provider edge devices to establish properly.
1568 For each physical interface (phy-interface), there are basic
1569 configuration parameters like port number and speed, interface MTU,
1570 auto-negotiation and flow-control settings, etc. "encapsulation-
1571 type" is for user to select between Ethernet encapsulation (port-
1572 based) or Ethernet VLAN encapsulation (VLAN-based). All allowed
1573 Ethertypes of ingress service frames can be listed under "ethertype".
1574 In addition, the subscriber and provider may decide to enable
1575 advanced features, such as LLDP, 802.3AH link OAM, MAC loop
1576 detection/prevention at a UNI, based on mutual agreement.
1578 Sometimes, the subscriber may require multiple physical links bundled
1579 together to form a single, logical, point-to-point LAG connection to
1580 the service provider. Typically, LACP (Link Aggregation Control
1581 Protocol) is used to dynamically manage adding or deleting member
1582 links of the aggregate group. In general, LAG allows for increased
1583 service bandwidth beyond the speed of a single physical link while
1584 providing graceful degradation as failure occurs, thus increased
1585 availability.
1587 In the L2SM, there is a set of attributes under "LAG-interface"
1588 related to link aggregation functionality. The subscriber and
1589 provider first need to decide on whether LACP PDU will be exchanged
1590 between the edge device by specifying the "LACP-state" to "On" or
1591 "Off". If LACP is to be enabled, then both parties need to further
1592 specify whether it will be running in active versus passive mode,
1593 plus the time interval and priority level of the LACP PDU. The
1594 subscriber and provider can also determine the minimum aggregate
1595 bandwidth for a LAG to be considered valid path by specifying the
1596 optional "mini-link" attribute. To enable fast detection of faulty
1597 links, micro-BFD runs independent UDP sessions to monitor the status
1598 of each member link. Subscriber and provider should consent to the
1599 BFD hello interval and hold time.
1601 Each member link will be listed under the LAG interface with basic
1602 physical link properties. Certain attributes like flow-control,
1603 encapsulation type, allowed ingress Ethertype and LLDP settings are
1604 at the LAG level.
1606 If the Ethernet service is enabled on a logical unit on the
1607 connection at the interface, the "sub-if-id" should be specified.
1609 The "Ethernet-connection" container also presents site specific
1610 (S-tag, C-tag) management options. The overall S-tag for the
1611 Ethernet circuit and C-tag to EVC mapping, if applicable, has been
1612 placed in the service container. The S-tag under "port" should match
1613 the S-tag in the service container in most cases, however, vlan
1614 translation is required for the S-tag in certain deployment at the
1615 external facing interface or upstream PEs to "normalize" the outer
1616 VLAN tag to the service S-tag into the network and translate back to
1617 the site's S-tag in the opposite direction. One example of this is
1618 with a Layer 2 aggregation switch along the path: the S-tag for the
1619 EVC has been previously assigned to another service thus can not be
1620 used by this attachment circuit. Another use case is when multiple
1621 E-access OVCs from the same E-NNIs are attached to the same E-LAN
1622 service.
1624 The "svlan-id-ethernet-tag" in the "Ethernet-connection" container is
1625 either the S-tag inserted at a UNI or the outer tag of ingress
1626 packets at an E-NNI. These parameters are included in the L2SM to
1627 facilitate other management system to generate proper configuration
1628 for the network elements.
1630 The "ethernet-connection" container also contains an optional site-
1631 specific C-tag to EVC mapping.
1633 5.1.3.1.8.6. EVC MTU
1635 The maximum MTU of subscriber service frames can be derived from the
1636 physical interface MTU by default, or specified under the "evc-mtu"
1637 leaf if it is different than the default number.
1639 5.1.3.1.8.7. MAC Address Limit
1641 The service provider may choose to impose a per-attachment circuit
1642 "mac-addr-limit" in addition to the service-level MAC limit, and
1643 specify the behavior when the limit is exceeded accordingly.
1645 5.1.3.1.8.8. Availability
1647 EVPN supports PE geo-redundancy in the access domain. The connection
1648 between a multi-homed CE to PE is identified with a uniquely assigned
1649 ID referred as an Ethernet Segment Identifier (ESI). Because a
1650 learned MAC address is propagated via BGP, it allows for multiple
1651 active paths in forwarding state and for load-balancing options.
1653 The "availability" container contains ESI and redundancy mode
1654 attributes for an EVPN multi-homing site.
1656 5.1.3.1.8.9. L2CP-Control
1658 To facilitate interoperability between different Multiple System
1659 Operators (MSOs), the MEF has provided normative guidance on Layer 2
1660 Control Protocol (L2CP) processing requirements for each service
1661 type. Subscriber and provider should make pre- arrangement on
1662 whether to allow interaction between the edge device or keep each
1663 other's control plane separate on a per-protocol basis.
1665 The destination MAC addresses of these L2CP PDUs fall within two
1666 reserved blocks specified by the IEEE 802.1 Working Group. Packet
1667 with destination MAC in these multicast ranges have special
1668 forwarding rules.
1670 o Bridge Block of Protocols: 01-80-C2-00-00-00 through
1671 01-80-C2-00-00-0F
1673 o MRP Block of Protocols: 01-80-C2-00-00-20 through
1674 01-80-C2-00-00-2F
1676 Layer 2 protocol tunneling allows service providers to pass
1677 subscriber Layer 2 control PDUs across the network without being
1678 interpreted and processed by intermediate network devices. These
1679 L2CP PDUs are transparently encapsulated across the MPLS-enabled core
1680 network in Q-in-Q fashion.
1682 The "L2CP-control" container contains the list of commonly used L2CP
1683 protocols and parameters. The service provider can specify DISCARD,
1684 PEER, or TUNNEL mode actions for each individual protocol.
1686 In addition, "provider-bridge-group" and "provider-bridge-mvrp"
1687 addresses are also listed in the L2CP container.
1689 5.1.3.1.8.10. Service
1691 The "service" container defines service parameters associated with
1692 the site.
1694 5.1.3.1.8.10.1. Bandwidth
1696 The service bandwidth refers to the bandwidth requirement between PE
1697 and CE. The requested bandwidth is expressed as svc-input-bandwidth
1698 and svc-output-bandwidth. Input/output direction is using customer
1699 site as reference: input bandwidth means download bandwidth for the
1700 site, and output bandwidth means upload bandwidth for the site.
1702 The service bandwidth is only configurable at the site-network-access
1703 level (i.e., for the port associated with the site).
1705 Using a different input and output bandwidth will allow service
1706 provider to know if a customer allows for asymmetric bandwidth access
1707 like ADSL. It can also be used to set a rate-limit in a different
1708 way for upload and download on symmetric bandwidth access.
1710 The bandwidth container may also include a "cos-id" parameter. If
1711 the "cos-id" is not present within the bandwidth container, the
1712 bandwidth is per evc, which provides rate enforcement for all ingress
1713 service frames at the interface that are associated with a particular
1714 EVC.
1716 If the "cos-id" is present, the bandwidth is per CoS, which provides
1717 rate enforcement for all service frames for a given class of service.
1718 The class of service is identified via a CoS identifier. So this
1719 bandwidth profile applies to service frames over an EVC with a
1720 particular CoS value. Multiple input/output-bandwidthper-cos-id can
1721 be associated with the same EVC.
1723 5.1.3.1.8.10.2. QoS
1725 The model defines QoS parameters as an abstraction:
1727 o qos-classification-policy: Defines a set of ordered rules to
1728 classify customer traffic.
1730 o qos-profile: Provides a QoS scheduling profile to be applied.
1732 5.1.3.1.8.10.2.1. QoS Classification
1734 In MEF 23.2 ([MEF-23-2]) three types of model are defined as the
1735 following:
1737 Class-of-Service Identifier based on EVC or OVC EP (End Point): In
1738 this model, regardless of customer marking, all in-profile frames
1739 will be marked with the service level in the contractual
1740 agreement. Customer CoS markings are preserved throughout the
1741 provider network. The bandwidth profile consists of one set of
1742 CIR/CBS and EIR/EBS values.
1744 Class-of-Service Identifier based on Priority Code Point: Using this
1745 model, multiple classes of services can be associated with a
1746 single customer EVC, identified by dot1p bits in the C-tag. Each
1747 service level has its own individual bandwidth profile. Out-of-
1748 profile packets will be discarded. Customer CoS markings are
1749 preserved.
1751 Class-of-Service Identifier based on DSCP: Using this model,
1752 multiple classes of service can be associated with a single
1753 customer EVC, identified by DSCP bits in the IP header. Each
1754 service level has its own individual bandwidth profile. Out-of-
1755 profile packets will be discarded. Customer CoS markings are
1756 preserved.
1758 Similarly, the cos-color-id can be assigned based on EVC or OVC EP,
1759 dot1p value in C-tag, or DSCP in IP header. Ingress service frames
1760 are metered against the bandwidth profile based on the cos-
1761 identifier. A "color" will be assigned to a service frame to
1762 identify its bandwidth profile conformance. A service frame is
1763 "green" if it is conformant with "committed" rate of the bandwidth
1764 profile. A Service Frame is "yellow" if it is exceeding the
1765 "committed" rate but conformant with the "excess" rate of the
1766 bandwidth profile. Finally, a service frame is "red" if it is
1767 conformant with neither the "committed" nor "excess" rates of the
1768 bandwidth profile.
1770 Ingress/egress-bandwidth-profile-per-evc presents the ingress/egress
1771 bandwidth profile per EVC, providing rate enforcement for all ingress
1772 service frames at the interface that are associated with a particular
1773 EVC.
1775 Alternately, ingress/egress-bandwidth-profile-per-cos-id presents the
1776 ingress/egress bandwidth profile per CoS, providing rate enforcement
1777 for all service frames for a given class of service. The class of
1778 service is identified via a CoS identifier. So this bandwidth
1779 profile applies to service frames over an EVC with a particular CoS
1780 value. Multiple ingress/egress-bandwidth-profile-per-cos-id can be
1781 associated with the same EVC.
1783 QoS classification rules are handled by qos-classification-policy.
1784 The qos-classification-policy is an ordered list of rules that match
1785 a flow or application and set the appropriate target class of service
1786 (target-class-id). The user can define the match using physical port
1787 reference or a more specific flow definition (based layer 2 source
1788 and destination MAC address, cos,dscp,cos-id, color-id etc.). When a
1789 flow definition is used, the user can use a target-sites leaf- list
1790 to identify the destination of a flow rather than using destination
1791 addresses. A rule that does not have a match statement is considered
1792 as a match-all rule. A service provider may implement a default
1793 terminal classification rule if the customer does not provide it. It
1794 will be up to the service provider to determine its default target
1795 class.
1797 5.1.3.1.8.10.2.2. QoS Profile
1799 User can choose between standard profile provided by the operator or
1800 a custom profile. The qos-profile defines the traffic scheduling
1801 policy to be used by the service provider.
1803 A custom qos-profile is defined as a list of class of services and
1804 associated properties. The properties are:
1806 o byte-offset: The optional "byte-offset" indicates how many bytes
1807 in the service frame header are excluded from rate enforcement.
1809 o rate-limit: Used to rate-limit the class of service. The value is
1810 expressed as a percentage of the global service bandwidth. When
1811 the qos-profile is implemented at CE side the svc-output-bandwidth
1812 is taken into account as reference. When it is implemented at PE
1813 side, the svc-input-bandwidth is used.
1815 o frame-delay: Used to define the latency constraint of the class.
1816 The latency constraint can be expressed as the lowest possible
1817 latency or a latency boundary expressed in milliseconds. How this
1818 latency constraint will be fulfilled is up to the service provider
1819 implementation: a strict priority queueing may be used on the
1820 access and in the core network, and/or a low latency routing may
1821 be created for this traffic class.
1823 o frame-jitter: Used to define the jitter constraint of the class.
1824 The jitter constraint can be expressed as the lowest possible
1825 jitter or a jitter boundary expressed in microseconds. How this
1826 jitter constraint will be fulfilled is up to the service provider
1827 implementation: a strict priority queueing may be used on the
1828 access and in the core network, and/or a jitter-aware routing may
1829 be created for this traffic class.
1831 5.1.3.1.8.11. Security Filtering
1833 5.1.3.1.8.11.1. BUM Strom Control
1835 For point-to-point E-LINE services, the provider only needs to
1836 deliver a single copy of each service frame to the remote PE,
1837 regardless whether the destination MAC address of the incoming frame
1838 is unicast, multicast or broadcast. Therefore, all in-profile
1839 service frames should be delivered unconditionally.
1841 B-U-M (Broadcast-UnknownUnicast-Multicast) frame forwarding in
1842 multipoint-to-multipoint services, on the other hand, involves both
1843 local flooding to other attachment circuits on the same PE and remote
1844 replication to all other PEs, thus consumes additional resources and
1845 core bandwidth. Special B-U-M frame disposition rules can be
1846 implemented at external facing interfaces (UNI or E-NNI) to rate-
1847 limit the B-U-M frames, in term of number of packets per second or
1848 bits per second.
1850 The threshold can apply to all B-U-M traffic, or one for each
1851 category.
1853 5.1.3.1.8.11.2. MAC Loop Protection
1855 MAC address flapping between different physical ports typically
1856 indicates a bridge loop condition in the subscriber network.
1857 Misleading entries in the MAC cache table can cause service frames to
1858 circulate around the network indefinitely and saturate the links
1859 throughout the provider's network, affecting other services in the
1860 same network. In case of EVPN, it also introduces massive BGP
1861 updates and control plane instability.
1863 The service provider may opt to implement a switching loop prevention
1864 mechanism at the external facing interfaces for multipoint-to-
1865 multipoint services by imposing a MAC address move threshold.
1867 The MAC move rate and prevention-type options are listed in the "mac-
1868 loop-prevention" container.
1870 5.1.3.1.8.11.3. Service Level MAC Limit
1872 See Section 5.1.2.10.
1874 5.1.3.1.8.12. Ethernet Service OAM
1876 The advent of Ethernet as a wide-area network technology brings
1877 additional requirements of end-to-end service monitoring and fault
1878 management in the carrier network, particularly in the area of
1879 service availability and Mean Time To Repair (MTTR). Ethernet
1880 Service OAM in the L2SM refers to the combined protocol suites of
1881 IEEE 802.1ag ([IEEE-802-1ag]) and ITU-T Y.1731 ([ITU-T-Y-1731]).
1883 Generally speaking, Ethernet Service OAM enables service providers to
1884 perform service continuity check, fault-isolation, and packet delay/
1885 jitter measurement at per customer per EVC granularity. The
1886 information collected from Ethernet Service OAM data sets is
1887 complementary to other higher layer IP/MPLS OSS tools to ensure the
1888 required service level agreements (SLAs) can be meet.
1890 The 802.1ag Connectivity Fault Management (CFM) functional model is
1891 structured with hierarchical maintenance domains (MDs), each assigned
1892 a unique maintenance level. Higher level MDs can be nested over
1893 lower level MDs. However, the MDs cannot intersect. The scope of
1894 each MD can be solely within a subscriber's network, solely within
1895 the provider's network, interact between the subscriber-to-provider
1896 or provider-to-provider edge equipment, or tunnel over another
1897 provider's network.
1899 Depending on the use case scenario, one or more maintenance end
1900 points (MEPs) can be placed on the external facing interface, sending
1901 CFM PDUs towards the core network (UP MEP) or downstream link (DOWN
1902 MEP).
1904 The "cfm-802.1-ag" sub-container under "port" currently presents two
1905 types of CFM maintenance association (MA): UP MEP for UNI-N to UNI-N
1906 Maintenance Association (MA) and DOWN MEP for UNI-N to UNI-C MA. For
1907 each MA, the user can define the maintenance domain ID (MAID), MEP
1908 level, MEP direction, remote MEP ID, CoS level of the CFM PDUs,
1909 Continuity Check Message (CCM) interval and hold time, alarm priority
1910 defect, CCM priority-type, etc.
1912 ITU-T Y.1731 Performance Monitoring (PM) provides essential network
1913 telemetry information that includes the measurement of Ethernet
1914 service frame delay, frame delay variation, frame loss, and frame
1915 throughput. The delay/jitter measurement can be either one-way or
1916 two-way. Typically, a Y.1731 PM probe sends a small amount of
1917 synthetic frames along with service frames to measure the SLA
1918 parameters.
1920 The "y-1731" sub-container under "port" contains a set of parameters
1921 for use to define the PM probe information, including MAID, local and
1922 remote MEP-ID, PM PDU type, message period and measurement interval,
1923 CoS level of the PM PDUs, loss measurement by synthetic or service
1924 frame options, one-way or two-way delay measurement, PM frame size,
1925 and session type.
1927 6. Interaction with Other YANG Modules
1929 As expressed in Section 4, this service module is not intended to
1930 configure the network element, but is instantiated in a management
1931 system.
1933 The management system might follow modular design and comprise at
1934 least two different components:
1936 a. The component instantiating the service model (let's call it the
1937 service component)
1939 b. The component responsible for network element configuration
1940 (let's call it the configuration component)
1942 In some cases, when a split is needed between the behavior and
1943 functions that a customer requests and the technology that the
1944 network operator has available to deliver the service
1945 [I-D.wu-opsawg-service-model-explained], a new component can be
1946 separated out of the service component (let's call it the control
1947 component). This component is responsible for network-centric
1948 operation and is aware of many features such as topology, technology,
1949 and operator policy. As an optional component, it can use the
1950 service model as input and is not required at all if the control
1951 component delegates its control operations to the configuration
1952 component.
1954 In Section 7 we provide some example of translation of service
1955 provisioning requests to router configuration lines as an
1956 illustration. In the NETCONF/YANG ecosystem, it is expected that
1957 NETCONF and YANG will be used between the configuration component and
1958 network elements to configure the requested service on those
1959 elements.
1961 In this framework, it is expected that YANG models will be used for
1962 configuring service components on network elements. There will be a
1963 strong relationship between the abstracted view provided by this
1964 service model and the detailed configuration view that will be
1965 provided by specific configuration models for network elements such
1966 as those defined in [I-D.ietf-bess-l2vpn-yang] and
1967 [I-D.ietf-bess-evpn-yang]. Service components needing configuration
1968 on network elements in support of the service model defined in this
1969 document include:
1971 o VRF definition including VPN policy expression.
1973 o Physical interface.
1975 o Ethernet layer (VLAN ID).
1977 o QoS: classification, profiles, etc.
1979 o Signaling Options: support of configuration of all protocols
1980 listed in the document, as well as vpn policies associated with
1981 these protocols.
1983 o Ethernet Service OAM Support.
1985 7. Service Model Usage Example
1987 As explained in Section 4, this service model is intended to be
1988 instantiated at a management layer and is not intended to be used
1989 directly on network elements. The management system serves as a
1990 central point of configuration of the overall service.
1992 This section provides an example on how a management system can use
1993 this model to configure an L2VPN service on network elements.
1995 The example is for of a VPN service for 3 sites using point-to-point
1996 EVC and a Hub and Spoke VPN service topology as shown in Figure 7.
1997 Loadbalancing is not considered in this case.
1999 UNI Site1
2000 ............
2001 : : E-Line using P2P EVC
2002 :Spoke Site:-----PE1--------------------------+
2003 : : | UNI Site3
2004 :..........: | ............
2005 | : :
2006 PE3-----: Hub Site :
2007 UNI Site2 | : :
2008 ............ | :..........:
2009 : : E-Line using P2P EVC |
2010 :Spoke Site:-----PE2--------------------------+
2011 : :
2012 :..........:
2014 Figure 7: Reference Network for Simple Example
2016 The following XML describes the overall simplified service
2017 configuration of this VPN.
2019
2020 12456487
2021 EVC
2022
2023
2024 UNI1
2025 UNI3
2026
2027
2028 eline
2029 hub-spoke
2030
2032
2033 12456488
2034 EVC
2035
2036
2037 UNI2
2038 UNI3
2039
2040
2041 eline
2042 hub-spoke
2043
2045 When receiving the request for provisioning the VPN service, the
2046 management system will internally (or through communication with
2047 another OSS component) allocates VPN route-targets. In this specific
2048 case two Route Taregts (RTs) will be allocated (100:1 for Hubs and
2049 100:2 for Spokes). The output below describes the configuration of
2050 Spoke UNI Site1.
2052
2053 Spoke_Site1
2054
2055 NY
2056 US
2057
2058
2059
2060 VRF
2061
2062 12456487
2063 VPWS
2064
2065
2066
2067
2068
2069 Spoke_UNI-Site1
2070
2071
2072
2073 20
2074
2075
2076
2077
2078
2079 17
2080
2081
2082 ETH
2083
2084
2085
2086
2087 450000000
2088 20000000
2089 1000000000
2090 200000000
2091
2092
2093 350000000
2094 10000000
2095 800000000
2096 200000000
2097
2098
2099
2100 TUNNEL
2101 TRUE
2102
2103
2104 12456487
2105 spoke-role
2106
2107
2108
2109
2110 provider-managed
2111
2112
2114 When receiving the request for provisioning Spoke1 site, the
2115 management system MUST allocate network resources for this site. It
2116 MUST first determine the target network elements to provision the
2117 access, and especially the PE router (and may be an aggregation
2118 switch). As described in Section 5.1.3.1.3, the management system
2119 SHOULD use the location information and SHOULD use the access-
2120 diversity constraint to find the appropriate PE. In this case, we
2121 consider Spoke1 requires PE diversity with Hub and that management
2122 system allocate PEs based on lowest distance. Based on the location
2123 information, the management system finds the available PEs in the
2124 nearest area of the customer and picks one that fits the access-
2125 diversity constraint.
2127 When the PE is chosen, the management system needs to allocate
2128 interface resources on the node. One interface is selected from the
2129 PE available pool. The management system can start provisioning the
2130 PE node by using any mean (Netconf, CLI, ...). The management system
2131 will check if a VRF is already present that fits the needs. If not,
2132 it will provision the VRF: Route Distinguisher will come from
2133 internal allocation policy model, route-targets are coming from the
2134 vpn-policy configuration of the site (management system allocated
2135 some RTs for the VPN). As the site is a Spoke site (site-role), the
2136 management system knows which RT must be imported and exported. As
2137 the site is provider managed, some management route-targets may also
2138 be added (100:5000). Standard provider VPN policies MAY also be
2139 added in the configuration.
2141 Example of generated PE configuration:
2143 ip vrf Customer1
2144 export-map STD-CUSTOMER-EXPORT <---- Standard SP configuration
2145 route-distinguisher 100:3123234324
2146 route-target import 100:1
2147 route-target import 100:5000 <---- Standard SP configuration
2148 route-target export 100:2 for provider managed
2149 !
2151 When the VRF has been provisioned, the management system can start
2152 configuring the access on the PE using the allocated interface
2153 information. The VLAN tag is chosen by the management system. One
2154 VLAN tag will be picked from an allocated subnet for the PE, another
2155 will be used for the CE configuration. LACP protocols will also be
2156 configured between PE and CE and due to provider managed model, the
2157 choice is up to service provider. This choice is independent of the
2158 LACP protocol chosen by customer.
2160 Example of generated PE configuration:
2162 interface GigabitEthernet0/0/0/3.100 l2transport
2163 encapsulation dot1ad 100
2164 rewrite ingress tag pop 1 symmetric
2165 l2vpn
2166 xconnect group EPL
2167 p2p EPL
2168 interface GigabitEthernet0/0/0/3.100
2169 neighbor 100.100.100.1 pw-id 100
2170 !
2171 interface GigabitEthernet4/8
2172 no ip address
2173 speed nonegotiate
2174 no keepalive
2175 ethernet dot1ad nni
2176 service instance 100 ethernet
2177 encapsulation dot1q 100
2178 rewrite ingress tag pop 1 symmetric
2179 xconnect 100.100.100.2 100 encapsulation mpls
2181 As the CE router is not reachable at this stage, the management
2182 system can produce a complete CE configuration that can be uploaded
2183 to the node by manual operation before sending the CE to customer
2184 premise. The CE configuration will be built as for the PE. Based on
2185 the CE type (vendor/model) allocated to the customer and bearer
2186 information, the management system knows which interface must be
2187 configured on the CE. PE-CE link configuration is expected to be
2188 handled automatically using the service provider OSS as both
2189 resources are managed internally. CE to LAN interface parameters
2190 like dot1Q tag are derived from the ethernet-connection taking into
2191 account how management system distributes dot1Q tag between PE and CE
2192 within subnet. This will allow to produce a plug'n'play
2193 configuration for the CE.
2195 Example of generated CE configuration:
2197 interface GigabitEthernet0/9
2198 switchport trunk allowed vlan none
2199 switchport mode trunk
2200 service instance 100 ethernet
2201 encapsulation default
2202 l2protocol forward cdp
2203 xconnect 1.1.1.1 100 encapsulation mpls
2204 !
2206 8. YANG Module
2208
2209 file "ietf-l2vpn-svc@2017-02-10.yang"
2210 module ietf-l2vpn-svc {
2211 namespace "urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc";
2212 prefix "l2svc";
2214 import ietf-inet-types {
2215 prefix inet;
2216 }
2217 import ietf-yang-types {
2218 prefix yang;
2219 }
2220 import iana-if-type {
2221 prefix ianaift;
2222 }
2224 organization
2225 "IETF L2SM Working Group.";
2227 contact
2228 "WG List: l2sm@ietf.org
2229 Editor: Bin_Wen@comcast.com";
2230 description
2231 "The YANG module defines a generic service configuration
2232 model for Layer 2 VPN services common across all of the
2233 vendor implementations.";
2234 revision 2017-02-13{
2235 description
2236 "Initial revision -04 version";
2237 reference
2238 "draft-wen-l2sm-l2vpn-service-model-04.txt
2239 A YANG Data Model for L2VPN Service Delivery.";
2240 }
2242 /* Features */
2244 feature input-bw {
2245 description
2246 "Input Bandwidth";
2247 }
2248 feature output-bw {
2249 description
2250 "Output Bandwidth";
2251 }
2252 feature uni-list {
2253 description
2254 "Enable support UNI list";
2255 }
2256 feature ovc-type {
2257 description
2258 "Enable support OVC type";
2259 }
2260 feature cloud-access {
2261 description
2262 "Allow VPN to connect to a Cloud Service
2263 provider.";
2264 }
2265 feature oam-3ah {
2266 description
2267 "Enables support of OAM 802.3ah";
2268 }
2269 feature Micro-BFD {
2270 description
2271 "Enables support of Micro-BFD";
2272 }
2273 feature bfd {
2274 description
2275 "Enables support of BFD";
2276 }
2277 feature signaling-option {
2278 description
2279 "Enable support of signaling option";
2280 }
2281 feature site-diversity {
2282 description
2283 "Enables support of site diversity constraints";
2284 }
2285 feature encryption {
2286 description
2287 "Enables support of encryption";
2288 }
2289 feature always-on {
2290 description
2291 "Enables support for always-on access
2292 constraint.";
2293 }
2294 feature requested-type {
2295 description
2296 "Enables support for requested-type access
2297 constraint.";
2298 }
2299 feature bearer-reference {
2300 description
2301 "Enables support for bearer-reference access
2302 constraint.";
2303 }
2304 feature qos {
2305 description
2306 "Enables support of Class of Services";
2307 }
2308 feature qos-custom {
2309 description
2310 "Enables support of custom qos profile";
2311 }
2313 /* Typedefs */
2315 typedef svc-id {
2316 type string;
2317 description
2318 "Service ID";
2319 }
2320 typedef direction-type {
2321 type string;
2322 description
2323 "Direction";
2324 }
2325 typedef evc-id-type {
2326 type string;
2327 description
2328 "EVC ID type";
2329 }
2330 typedef ovc-id-type {
2331 type string;
2332 description
2333 "OVC ID type";
2334 }
2335 typedef ccm-priority-type {
2336 type uint8 {
2337 range "0..7";
2338 }
2339 description
2340 "A 3 bit priority value to be used in the VLAN tag, if present
2341 in the transmitted frame.";
2342 }
2343 typedef control-mode {
2344 type enumeration {
2345 enum peer {
2346 description
2347 "Peer mode";
2348 }
2349 enum tunnel {
2350 description
2351 "Tunnel mode";
2352 }
2353 enum discard {
2354 description
2355 "Discard mode";
2356 }
2357 }
2358 description
2359 "Defining a type of the control mode";
2360 }
2361 typedef neg-mode {
2362 type enumeration {
2363 enum full-duplex {
2364 description
2365 "Full duplex mode";
2366 }
2367 enum auto-neg {
2368 description
2369 "Auto negotiation mode";
2370 }
2372 }
2373 description
2374 "Defining a type of the negotiation mode";
2375 }
2377 /* Identities */
2379 identity bw-type {
2380 description
2381 "Identity of bandwidth";
2382 }
2383 identity bw-per-cos {
2384 base bw-type;
2385 description
2386 "Bandwidth is per cos";
2387 }
2388 identity opaque {
2389 base bw-type;
2390 description
2391 "Opaque";
2392 }
2393 identity site-type {
2394 description
2395 "Identity of site type.";
2396 }
2397 identity uni {
2398 base site-type;
2399 description
2400 "Identity of User Network Interface ";
2401 }
2402 identity enni {
2403 base site-type;
2404 description
2405 "Identity of External Network to Network Interface";
2406 }
2407 identity service-type {
2408 description
2409 "Identity of service type.";
2410 }
2411 identity evc {
2412 base service-type;
2413 description
2414 "EVC type.";
2415 }
2416 identity ovc {
2417 base service-type;
2418 description
2419 "OVC type.";
2421 }
2422 identity bundling-type {
2423 description
2424 "Bundling type.";
2425 }
2426 identity bundling {
2427 base bundling-type;
2428 description
2429 "Identity for bundling";
2430 }
2431 identity all2one-Bundling {
2432 base bundling-type;
2433 description
2434 "Identity for all to one bundling";
2435 }
2436 identity color-id {
2437 description
2438 "Identity of color id";
2439 }
2440 identity color-id-evc {
2441 base color-id;
2442 description
2443 "Identity of color id base on EVC";
2444 }
2445 identity color-id-evc-cvlan {
2446 base color-id;
2447 description
2448 "Identity of color id base on EVC and CVLAN ";
2449 }
2450 identity cos-id {
2451 description
2452 "Identity of class of service id";
2453 }
2454 identity cos-id-evc {
2455 base cos-id;
2456 description
2457 "Identity of cos id based on EVC";
2458 }
2459 identity cos-id-evc-pcp {
2460 base cos-id;
2461 description
2462 "Identity of cos id based on EVC and PCP";
2463 }
2464 identity cos-id-evc-dscp {
2465 base cos-id;
2466 description
2467 "Identity of cos id based on EVC and DSCP";
2468 }
2469 identity cos-id-ovc-ep {
2470 base cos-id;
2471 description
2472 "Identity of cos id based on OVC EP";
2473 }
2474 identity color-type {
2475 description
2476 "Identity of color types";
2477 }
2478 identity green {
2479 base color-type;
2480 description
2481 "Identity of green type";
2482 }
2483 identity yellow {
2484 base color-type;
2485 description
2486 "Identity of yellow type";
2487 }
2488 identity red {
2489 base color-type;
2490 description
2491 "Identity of red type";
2492 }
2493 identity perf-tier-opt {
2494 description
2495 "Identity of performance tier option.";
2496 }
2497 identity metro {
2498 base perf-tier-opt;
2499 description
2500 "Identity of metro";
2501 }
2502 identity regional {
2503 base perf-tier-opt;
2504 description
2505 "Identity of regional";
2506 }
2507 identity continental {
2508 base perf-tier-opt;
2509 description
2510 "Identity of continental";
2511 }
2512 identity global {
2513 base perf-tier-opt;
2514 description
2515 "Identity of global";
2516 }
2517 identity policing {
2518 description
2519 "Identity of policing type";
2520 }
2521 identity one-rate-two-color {
2522 base policing;
2523 description
2524 "Identity of one-rate, two-color (1R2C)";
2525 }
2526 identity two-rate-three-color {
2527 base policing;
2528 description
2529 "Identity of two-rate, three-color (2R3C)";
2530 }
2531 identity BUM-type {
2532 description
2533 "Identity of BUM type";
2534 }
2535 identity broadcast {
2536 base BUM-type;
2537 description
2538 "Identity of broadcast";
2539 }
2540 identity unicast {
2541 base BUM-type;
2542 description
2543 "Identity of unicast";
2544 }
2545 identity multicast {
2546 base BUM-type;
2547 description
2548 "Identity of multicast";
2549 }
2550 identity loop-prevention-type{
2551 description
2552 "Identity of loop prevention";
2553 }
2554 identity shut {
2555 base loop-prevention-type;
2556 description
2557 "Identity of shut protection";
2558 }
2559 identity trap {
2560 base loop-prevention-type;
2561 description
2562 "Identity of trap protection";
2563 }
2564 identity lacp-state {
2565 description
2566 "Identity of LACP state";
2567 }
2568 identity lacp-on {
2569 base lacp-state;
2570 description
2571 "Identity of LCAP on";
2572 }
2573 identity lacp-off {
2574 base lacp-state;
2575 description
2576 "Identity of LACP off";
2577 }
2578 identity lacp-mode {
2579 description
2580 "Identity of LACP mode";
2581 }
2582 identity lacp-passive {
2583 base lacp-mode;
2584 description
2585 "Identity of LACP passive";
2586 }
2587 identity lacp-active {
2588 base lacp-mode;
2589 description
2590 "Identity of LACP active";
2591 }
2592 identity lacp-speed {
2593 description
2594 "Identity of LACP speed";
2595 }
2596 identity lacp-fast {
2597 base lacp-speed;
2598 description
2599 "Identity of LACP fast";
2600 }
2601 identity lacp-slow {
2602 base lacp-speed;
2603 description
2604 "Identity of LACP slow";
2605 }
2606 identity vpn-signaling-type {
2607 description
2608 "Identity of VPN signaling types";
2609 }
2610 identity vrf {
2611 base vpn-signaling-type;
2612 description
2613 "Virtual routing and forwarding (VRF).";
2614 }
2615 identity vfi {
2616 base vpn-signaling-type;
2617 description
2618 "Virtual forwarder interface";
2619 }
2620 identity evi {
2621 base vpn-signaling-type;
2622 description
2623 "Ethernet virtual interconnect.";
2624 }
2625 identity l2vpn-type {
2626 description
2627 "Layer 2 VPN types";
2628 }
2629 identity vpws {
2630 base l2vpn-type;
2631 description
2632 "Virtual Private Wire Service";
2633 }
2634 identity vpls {
2635 base l2vpn-type;
2636 description
2637 "Virtual Private LAN Service";
2638 }
2639 identity evpn {
2640 base l2vpn-type;
2641 description
2642 "Ethernet VPN";
2643 }
2644 identity management {
2645 description
2646 "Base identity for site management scheme.";
2647 }
2648 identity co-managed {
2649 base management;
2650 description
2651 "Base identity for co-managed site.";
2652 }
2653 identity customer-managed {
2654 base management;
2655 description
2656 "Base identity for customer managed site.";
2657 }
2658 identity provider-managed {
2659 base management;
2660 description
2661 "Base identity for provider managed site.";
2662 }
2663 identity address-family {
2664 description
2665 "Base identity for an address family.";
2666 }
2667 identity ipv4 {
2668 base address-family;
2669 description
2670 "Identity for IPv4 address family.";
2671 }
2672 identity ipv6 {
2673 base address-family;
2674 description
2675 "Identity for IPv6 address family.";
2676 }
2677 identity vpn-topology {
2678 description
2679 "Base identity for VPN topology.";
2680 }
2681 identity any-to-any {
2682 base vpn-topology;
2683 description
2684 "Identity for any to any VPN topology.";
2685 }
2686 identity hub-spoke {
2687 base vpn-topology;
2688 description
2689 "Identity for Hub'n'Spoke VPN topology.";
2690 }
2691 identity hub-spoke-disjoint {
2692 base vpn-topology;
2693 description
2694 "Identity for Hub'n'Spoke VPN topology
2695 where Hubs cannot talk between each other.";
2696 }
2697 identity site-role {
2698 description
2699 "Base identity for site type.";
2700 }
2701 identity any-to-any-role {
2702 base site-role;
2703 description
2704 "Site in an any to any IPVPN.";
2705 }
2706 identity spoke-role {
2707 base site-role;
2708 description
2709 "Spoke Site in a Hub & Spoke IPVPN.";
2710 }
2711 identity hub-role {
2712 base site-role;
2713 description
2714 "Hub Site in a Hub & Spoke IPVPN.";
2715 }
2716 identity pm-type {
2717 description
2718 "Performance monitor type";
2719 }
2720 identity loss {
2721 base pm-type;
2722 description
2723 "Loss measurement";
2724 }
2725 identity delay {
2726 base pm-type;
2727 description
2728 "Delay measurement";
2729 }
2730 identity fault-alarm-defect-type {
2731 description
2732 "Indicating the alarm priority defect";
2733 }
2734 identity remote-rdi {
2735 base fault-alarm-defect-type;
2736 description
2737 "Indicates the aggregate health of the remote MEPs.";
2738 }
2739 identity remote-mac-error {
2740 base fault-alarm-defect-type;
2741 description
2742 "Indicates that one or more of the remote MEPs is
2743 reporting a failure in its Port Status TLV or
2744 Interface Status TLV.";
2745 }
2746 identity remote-invalid-ccm {
2747 base fault-alarm-defect-type;
2748 description
2749 "Indicates that at least one of the Remote MEP
2750 state machines is not receiving valid CCMs
2751 from its remote MEP.";
2752 }
2753 identity invalid-ccm {
2754 base fault-alarm-defect-type;
2755 description
2756 "Indicates that one or more invalid CCMs has been
2757 received and that 3.5 times that CCMs transmission
2758 interval has not yet expired.";
2759 }
2760 identity cross-connect-ccm {
2761 base fault-alarm-defect-type;
2762 description
2763 "Indicates that one or more cross connect CCMs has been
2764 received and that 3.5 times of at least one of those
2765 CCMs transmission interval has not yet expired.";
2766 }
2767 identity data-svc-frame-delivery {
2768 description
2769 "Delivery types";
2770 }
2771 identity discard {
2772 base data-svc-frame-delivery;
2773 description
2774 "Service Frames are discarded.";
2775 }
2776 identity unconditional {
2777 base data-svc-frame-delivery;
2778 description
2779 "Service Frames are unconditionally";
2780 }
2781 identity conditional {
2782 base data-svc-frame-delivery;
2783 description
2784 "Service Frame are conditionally
2785 delivered to the destination UNI.";
2786 }
2787 identity svc-topo-type {
2788 description
2789 "Service topology Type";
2790 }
2791 identity point-to-point {
2792 base svc-topo-type;
2793 description
2794 "Point to Point.";
2795 }
2796 identity multipoint-to-multipoint {
2797 base svc-topo-type;
2798 description
2799 "Multipoint to Multipoint.";
2800 }
2801 identity rooted-multipoint {
2802 base svc-topo-type;
2803 description
2804 "Rooted Multipoint.";
2806 }
2807 identity placement-diversity {
2808 description
2809 "Base identity for site placement
2810 constraints";
2811 }
2812 identity bearer-diverse {
2813 base placement-diversity;
2814 description
2815 "Identity for bearer diversity.
2816 The bearers should not use common elements.";
2817 }
2818 identity pe-diverse {
2819 base placement-diversity;
2820 description
2821 "Identity for PE diversity";
2822 }
2823 identity pop-diverse {
2824 base placement-diversity;
2825 description
2826 "Identity for POP diversity";
2827 }
2828 identity linecard-diverse {
2829 base placement-diversity;
2830 description
2831 "Identity for linecard diversity";
2832 }
2833 identity same-pe {
2834 base placement-diversity;
2835 description
2836 "Identity for having sites connected
2837 on the same PE";
2838 }
2839 identity same-bearer {
2840 base placement-diversity;
2841 description
2842 "Identity for having sites connected
2843 using the same bearer";
2844 }
2845 identity l2-access-type {
2846 description
2847 "This identify the access type
2848 of the vpn acccess interface";
2849 }
2850 identity untag {
2851 base l2-access-type;
2852 description
2853 "Untag";
2855 }
2856 identity port {
2857 base l2-access-type;
2858 description
2859 "Port";
2860 }
2861 identity dot1q {
2862 base l2-access-type;
2863 description
2864 "Qot1q";
2865 }
2866 identity qinq {
2867 base l2-access-type;
2868 description
2869 "QinQ";
2870 }
2871 identity sub-interface {
2872 base l2-access-type;
2873 description
2874 "Create a default sub-interface and keep vlan";
2875 }
2876 identity vxlan {
2877 base l2-access-type;
2878 description
2879 "Vxlan access into the vpn";
2880 }
2881 identity mac-learning-mode {
2882 description
2883 "MAC learning mode";
2884 }
2885 identity data-plane {
2886 base mac-learning-mode;
2887 description
2888 "User MAC addresses are learned through ARP broadcast.";
2889 }
2890 identity control-plane {
2891 base mac-learning-mode;
2892 description
2893 "User MAC addresses are advertised through EVPN-BGP";
2894 }
2896 /* Groupings */
2898 grouping customer-info-grouping {
2899 list customer-info {
2900 key "customer-account-number customer-name";
2901 leaf customer-account-number {
2902 type uint32;
2903 description
2904 "Customer account number";
2905 }
2906 leaf customer-name {
2907 type string;
2908 description
2909 "Customer name";
2910 }
2911 container customer-operation-center {
2912 leaf customer-noc-street-address {
2913 type string;
2914 description
2915 "Customer NOC street Address.";
2916 }
2917 container customer-noc-phone-number {
2918 leaf main-phone-num {
2919 type uint32;
2920 description
2921 "Main phone number.";
2922 }
2923 leaf extension-options {
2924 type uint32;
2925 description
2926 "Extension or options";
2927 }
2928 description
2929 "Configuration of customer NOCc phone number";
2930 }
2931 description
2932 "Configuration of customer operation center";
2933 }
2934 description
2935 "List of customer information";
2936 }
2937 description
2938 "Grouping for customer information";
2939 }
2941 grouping vpn-service-cloud-access {
2942 container cloud-accesses {
2943 if-feature cloud-access;
2944 list cloud-access {
2945 key cloud-identifier;
2946 leaf cloud-identifier {
2947 type string;
2948 description
2949 "Identification of cloud service. Local
2950 admin meaning.";
2952 }
2953 choice list-flavor {
2954 case permit-any {
2955 leaf permit-any {
2956 type empty;
2957 description
2958 "Allow all sites.";
2959 }
2960 }
2961 case deny-any-except {
2962 leaf-list permit-site {
2963 type leafref {
2964 path "/l2vpn-svc/sites/site/site-id";
2965 }
2966 description
2967 "Site ID to be authorized.";
2968 }
2969 }
2970 case permit-any-except {
2971 leaf-list deny-site {
2972 type leafref {
2973 path "/l2vpn-svc/sites/site/site-id";
2974 }
2975 description
2976 "Site ID to be denied.";
2977 }
2978 }
2979 description
2980 "Choice for cloud access policy.";
2981 }
2982 container authorized-sites {
2983 list authorized-site {
2984 key site-id;
2985 leaf site-id {
2986 type leafref {
2987 path "/l2vpn-svc/sites/site/site-id";
2988 }
2989 description
2990 "Site ID.";
2991 }
2992 description
2993 "List of authorized sites.";
2994 }
2995 description
2996 "Configuration of authorized sites";
2997 }
2998 container denied-sites {
2999 list denied-site {
3000 key site-id;
3001 leaf site-id {
3002 type leafref {
3003 path "/l2vpn-svc/sites/site/site-id";
3004 }
3005 description
3006 "Site ID.";
3007 }
3008 description
3009 "List of denied sites.";
3010 }
3011 description
3012 "Configuration of denied sites";
3013 }
3014 description
3015 "Cloud access configuration.";
3016 }
3017 description
3018 "Container for cloud access configurations";
3019 }
3020 description
3021 "Grouping for vpn cloud definition";
3022 }
3024 grouping site-device {
3025 container device {
3026 list devices {
3027 key "device-id";
3028 leaf device-id {
3029 type string;
3030 description
3031 "Device ID";
3032 }
3033 leaf site-name {
3034 type string;
3035 description
3036 "Site name";
3037 }
3038 container management {
3039 leaf address {
3040 type inet:ip-address;
3041 description
3042 "Address";
3043 }
3044 leaf management-transport {
3045 type identityref {
3046 base address-family;
3047 }
3048 description
3049 "Transport protocol used for management.";
3050 }
3051 description
3052 "Container for management";
3053 }
3054 description
3055 "List of devices";
3056 }
3057 description
3058 "Devices configuration";
3059 }
3060 description
3061 "Device parameters for the site.";
3062 }
3064 grouping site-management {
3065 container managemnt {
3066 leaf type {
3067 type identityref {
3068 base management;
3069 }
3070 description
3071 "Management type of the connection.";
3072 }
3073 description
3074 "Container for management";
3075 }
3076 description
3077 "Grouping for management";
3078 }
3080 grouping site-vpn-policy {
3081 container vpn-policies {
3082 list vpn-policy {
3083 key vpn-policy-id;
3084 leaf vpn-policy-id {
3085 type string;
3086 description
3087 "Unique identifier for the VPN policy.";
3088 }
3089 list entries {
3090 key id;
3091 leaf id {
3092 type string;
3093 description
3094 "Unique identifier for the policy entry.";
3095 }
3096 container filter {
3097 choice lan {
3098 case lan-tag {
3099 leaf-list lan-tag {
3100 type string;
3101 description
3102 "List of lan-tags to be matched.";
3103 }
3104 }
3105 description
3106 "Choice for LAN matching type";
3107 }
3108 description
3109 "If used, it permit to split site LANs
3110 among multiple VPNs.
3111 If no filter used, all the LANs will be
3112 part of the same VPNs with the same
3113 role.";
3114 }
3115 container vpn {
3116 leaf vpn-id {
3117 type leafref {
3118 path "/l2vpn-svc/vpn-services/"+
3119 "vpn-svc/vpn-id";
3120 }
3121 mandatory true;
3122 description
3123 "Reference to an IPVPN.";
3124 }
3125 leaf site-role {
3126 type identityref {
3127 base site-role;
3128 }
3129 default any-to-any-role;
3130 description
3131 "Role of the site in the IPVPN.";
3132 }
3133 description
3134 "List of VPNs the LAN is associated to.";
3135 }
3136 description
3137 "List of entries for export policy.";
3138 }
3139 description
3140 "List of VPN policies.";
3141 }
3142 description
3143 "VPN policy.";
3145 }
3146 description
3147 "VPN policy parameters for the site.";
3148 }
3150 grouping umb-frame-delivery {
3151 leaf unicast-frame-delivery {
3152 type identityref {
3153 base data-svc-frame-delivery;
3154 }
3155 description
3156 "Unicast Data Service Frame Delivery Mode
3157 (unconditional[default], conditional, or discard).";
3158 }
3159 leaf multicast-frame-delivery {
3160 type identityref {
3161 base data-svc-frame-delivery;
3162 }
3163 description
3164 "Multicast Data Service Frame Delivery Mode
3165 (unconditional[default], conditional, or discard).";
3166 }
3167 leaf broadcast-frame-delivery {
3168 type identityref {
3169 base data-svc-frame-delivery;
3170 }
3171 description
3172 "Broadcast Data Service Frame Delivery Mode
3173 (unconditional[default], conditional, or discard).";
3174 }
3175 description
3176 "Grouping for unicast, mulitcast, broadcast frame delivery";
3177 }
3179 grouping customer-location-info {
3180 container location {
3181 leaf address {
3182 type string;
3183 description
3184 "Address (number and street) of the site.";
3185 }
3186 leaf zip-code {
3187 type string;
3188 description
3189 "ZIP code of the site.";
3190 }
3191 leaf state {
3192 type string;
3193 description
3194 "State of the site. This leaf can also be used to
3195 describe a region for country who does not have
3196 states.";
3197 }
3198 leaf city {
3199 type string;
3200 description
3201 "City of the site.";
3202 }
3203 leaf country-code {
3204 type string;
3205 description
3206 "Country of the site.";
3207 }
3208 description
3209 "Location of the site.";
3210 }
3211 description
3212 "This grouping defines customer location parameters";
3213 }
3215 grouping site-diversity {
3216 container site-diversity {
3217 if-feature site-diversity;
3218 container groups {
3219 list group {
3220 key group-id;
3221 leaf group-id {
3222 type string;
3223 description
3224 "Group-id the site is belonging to";
3225 }
3226 description
3227 "List of group-id";
3228 }
3229 description
3230 "Groups the site is belonging to.
3231 All site network accesses will inherit those group
3232 values.";
3233 }
3234 description
3235 "Diversity constraint type.";
3236 }
3237 description
3238 "This grouping defines site diversity parameters";
3239 }
3240 grouping site-service {
3241 leaf svlan-id-ethernet-tag {
3242 type string;
3243 description
3244 "SVLAN-ID/Ethernet Tag configurations";
3245 }
3246 list cvlan-id-to-evc-map {
3247 key "evc-id type";
3248 leaf evc-id {
3249 type leafref {
3250 path "/l2vpn-svc/vpn-services/vpn-svc/vpn-id";
3251 }
3252 description
3253 "EVC ID";
3254 }
3255 leaf type {
3256 type identityref {
3257 base bundling-type;
3258 }
3259 description
3260 "Bundling type";
3261 }
3262 list cvlan-id {
3263 key vid;
3264 leaf vid {
3265 type identityref {
3266 base ianaift:iana-interface-type;
3267 }
3268 description
3269 "CVLAN ID";
3270 }
3271 description
3272 "List of CVLAN-ID to EVC Map configurations";
3273 }
3274 description
3275 "List for cvlan-id to evc map configurations";
3276 }
3277 leaf service-level-mac-limit {
3278 type string;
3279 description
3280 "Service-level MAC-limit (E-LAN only)";
3281 }
3282 description
3283 "This grouping defines site service parameters";
3284 }
3286 grouping service-protection {
3287 container service-protection {
3288 container protection-model {
3289 description
3290 "Container of protection model configurations";
3291 }
3292 container peer-evc-id {
3293 description
3294 "Container of peer EVC ID configurations";
3295 }
3296 description
3297 "Container of End-to-end Service Protection
3298 configurations";
3299 }
3300 description
3301 "Grouping for service protection";
3302 }
3304 grouping ethernet-service-type {
3305 choice ethernet-svc-type {
3306 case e-line {
3307 leaf epl {
3308 type boolean;
3309 description
3310 "Ethernet private line";
3311 }
3312 leaf evpl {
3313 type boolean;
3314 description
3315 "Ethernet virtual private line";
3316 }
3317 description
3318 "Case of e-line";
3319 }
3320 case e-lan {
3321 leaf ep-lan {
3322 type boolean;
3323 description
3324 "Ethernet private LAN";
3325 }
3326 leaf evp-lan {
3327 type boolean;
3328 description
3329 "Ethernet virtual private LAN";
3330 }
3331 description
3332 "Case of e-lan";
3333 }
3334 case e-access {
3335 leaf access-epl {
3336 type boolean;
3337 description
3338 "Access Ethernet virtual private line";
3339 }
3340 leaf access-evpl {
3341 type boolean;
3342 description
3343 "Access Ethernet virtual private line";
3344 }
3345 description
3346 "Case of e-access.";
3347 }
3348 description
3349 "Choice of Ethernet service type";
3350 }
3351 description
3352 "Grouping for Ethernet service type.";
3353 }
3355 grouping signaling-option-grouping {
3356 list signaling-option {
3357 key "type";
3358 leaf type {
3359 type identityref {
3360 base vpn-signaling-type;
3361 }
3362 description
3363 "VPN signaling types";
3364 }
3365 container mp-bgp-l2vpn {
3366 leaf vpn-id {
3367 type svc-id;
3368 description
3369 "Identifies the target VPN";
3370 }
3371 leaf type {
3372 type identityref {
3373 base l2vpn-type;
3374 }
3375 description
3376 "L2VPN types";
3377 }
3378 description
3379 "Container for MP BGP L2VPN";
3380 }
3381 container mp-bgp-evpn {
3382 leaf vpn-id {
3383 type svc-id;
3384 description
3385 "Identifies the target VPN";
3386 }
3387 leaf type {
3388 type identityref {
3389 base l2vpn-type;
3390 }
3391 description
3392 "L2VPN types";
3393 }
3394 leaf mac-learning-mode {
3395 type identityref {
3396 base mac-learning-mode;
3397 }
3398 description
3399 "Indicates through which plane MAC addresses are
3400 advertised.";
3401 }
3402 leaf arp-suppress {
3403 type boolean;
3404 default false;
3405 description
3406 "Indicates whether to suppress ARP broadcast.";
3407 }
3408 description
3409 "Container for MP BGP L2VPN";
3410 }
3411 container t-ldp-pwe {
3412 list PE-EG-list {
3413 key "service-ip-lo-addr vc-id";
3414 leaf service-ip-lo-addr {
3415 type inet:ip-address;
3416 description
3417 "Service ip lo address";
3418 }
3419 leaf vc-id {
3420 type string;
3421 description
3422 "VC id";
3423 }
3424 description
3425 "List of PE/EG";
3426 }
3427 description
3428 "Container of T-LDP PWE configurations";
3429 }
3430 container pwe-encapsulation-type {
3431 leaf ethernet {
3432 type boolean;
3433 description
3434 "Ethernet";
3435 }
3436 leaf vlan {
3437 type boolean;
3438 description
3439 "VLAN";
3440 }
3441 description
3442 "Container of PWE Encapsulation Type configurations";
3443 }
3444 container pwe-mtu {
3445 leaf allow-mtu-mismatch {
3446 type boolean;
3447 description
3448 "Allow MTU mismatch";
3449 }
3450 description
3451 "Container of PWE MTU configurations";
3452 }
3453 container control-word {
3454 description
3455 "Container of control word configurations";
3456 }
3457 description
3458 "List of VPN Signaling Option.";
3459 }
3460 description
3461 "Grouping for signaling option";
3462 }
3464 grouping load-balance-grouping {
3465 leaf fat-pw {
3466 type boolean;
3467 description
3468 "Fat label is applied to Pseudowires across MPLS
3469 network";
3470 }
3471 leaf entropy-label {
3472 type boolean;
3473 description
3474 "Entropy label is applied to IP forwarding,
3475 L2VPN or L3VPN across MPLS network";
3476 }
3477 leaf vxlan-source-port {
3478 type string;
3479 description
3480 "Vxlan source port";
3481 }
3482 description
3483 "Grouping for load balance ";
3484 }
3486 grouping operational-requirements-ops {
3487 leaf actual-site-start {
3488 type yang:date-and-time;
3489 config false;
3490 description
3491 "Optional leaf indicating actual date
3492 and time when the service at a particular
3493 site actually started";
3494 }
3495 leaf actual-site-stop {
3496 type yang:date-and-time;
3497 config false;
3498 description
3499 "Optional leaf indicating actual date
3500 and time when the service at a particular
3501 site actually stopped";
3502 }
3503 description
3504 "This grouping defines some operational parameters
3505 parameters";
3506 }
3508 grouping intra-mkt-grouping {
3509 list intra-mkt {
3510 key "metro-mkt-id mkt-name";
3511 leaf metro-mkt-id {
3512 type uint32;
3513 description
3514 "Metro MKT ID";
3515 }
3516 leaf mkt-name {
3517 type string;
3518 description
3519 "MKT Name";
3520 }
3521 leaf ovc-id {
3522 type string;
3523 description
3524 "OVC identifier";
3525 }
3526 description
3527 "List of intra-MKT";
3529 }
3530 description
3531 "Grouping for intra-MKT";
3532 }
3534 grouping inter-mkt-service {
3535 leaf inter-mkt-service{
3536 type boolean;
3537 description
3538 "Indicate whether service is inter market service.";
3539 }
3540 description
3541 "Grouping for inter-MKT service";
3542 }
3544 grouping evc-id-grouping {
3545 leaf evc-id {
3546 type svc-id;
3547 description
3548 "Ethernet Virtual Connection identifier";
3549 }
3550 description
3551 "Grouping for EVC-ID";
3552 }
3554 grouping svc-type-grouping {
3555 container evc-type {
3556 uses evc-id-grouping;
3557 leaf number-of-pe {
3558 type uint32;
3559 config false;
3560 description
3561 "Number of PE";
3562 }
3563 leaf number-of-site {
3564 type uint32;
3565 config false;
3566 description
3567 "Number of Sites";
3568 }
3569 container uni-list {
3570 if-feature uni-list;
3571 list uni-list {
3572 key "network-access-id";
3573 leaf network-access-id {
3574 type string;
3575 description
3576 "Network Access Identifier";
3578 }
3579 description
3580 "List for UNIs";
3581 }
3582 description
3583 "Container for UNI List";
3584 }
3585 description
3586 "Container for Ethernet virtual connection.";
3587 }
3588 container ovc-type {
3589 if-feature ovc-type;
3590 list ovc-list {
3591 key ovc-id;
3592 leaf ovc-id {
3593 type svc-id;
3594 description
3595 "OVC ID type";
3596 }
3597 leaf on-net {
3598 type boolean;
3599 description
3600 "On net";
3601 }
3602 leaf off-net {
3603 type boolean;
3604 description
3605 "Off net";
3606 }
3607 description
3608 "List for OVC";
3609 }
3610 description
3611 "Container for OVC";
3612 }
3613 description
3614 "Grouping of service types.";
3615 }
3617 grouping cfm-802-grouping {
3618 leaf MAID {
3619 type string;
3620 description
3621 "MA ID";
3622 }
3623 leaf mep-id {
3624 type uint32;
3625 description
3626 "Local MEP ID";
3627 }
3628 leaf mep-level {
3629 type uint32;
3630 description
3631 "MEP level";
3632 }
3633 leaf mep-up-down {
3634 type enumeration {
3635 enum up {
3636 description
3637 "MEP up";
3638 }
3639 enum down {
3640 description
3641 "MEP down";
3642 }
3643 }
3644 description
3645 "MEP up/down";
3646 }
3647 leaf remote-mep-id {
3648 type uint32;
3649 description
3650 "Remote MEP ID";
3651 }
3652 leaf cos-for-cfm-pdus {
3653 type uint32;
3654 description
3655 "COS for CFM PDUs";
3656 }
3657 leaf ccm-interval {
3658 type uint32;
3659 description
3660 "CCM interval";
3661 }
3662 leaf ccm-holdtime {
3663 type uint32;
3664 description
3665 "CCM hold time";
3666 }
3667 leaf alarm-priority-defect {
3668 type identityref {
3669 base fault-alarm-defect-type;
3670 }
3671 description
3672 "The lowest priority defect that is
3673 allowed to generate a Fault Alarm.
3675 The non-existence of this leaf means
3676 that no defects are to be reported";
3677 }
3678 leaf ccm-p-bits-pri {
3679 type ccm-priority-type;
3680 description
3681 "The priority parameter for CCMs transmitted by the MEP";
3682 }
3683 description
3684 "Grouping for 802.1ag CFM attribute";
3685 }
3687 grouping y-1731 {
3688 list y-1731 {
3689 key MAID;
3690 leaf MAID {
3691 type string;
3692 description
3693 "MA ID ";
3694 }
3695 leaf mep-id {
3696 type uint32;
3697 description
3698 "Local MEP ID";
3699 }
3700 leaf type {
3701 type identityref {
3702 base pm-type;
3703 }
3704 description
3705 "Performance monitor types";
3706 }
3707 leaf remote-mep-id {
3708 type uint32;
3709 description
3710 "Remote MEP ID";
3711 }
3712 leaf message-period {
3713 type uint32;
3714 description
3715 "Defines the interval between OAM messages. The message
3716 period is expressed in milliseconds";
3717 }
3718 leaf measurement-interval {
3719 type uint32;
3720 description
3721 "Specifies the measurement interval for statistics. The
3722 measurement interval is expressed in seconds";
3724 }
3725 leaf cos {
3726 type uint32;
3727 description
3728 "Class of service";
3729 }
3730 leaf loss-measurement {
3731 type boolean;
3732 description
3733 "Whether enable loss measurement";
3734 }
3735 leaf synthethic-loss-measurement {
3736 type boolean;
3737 description
3738 "Indicate whether enable synthetic loss measurement";
3739 }
3740 container delay-measurement {
3741 leaf enable-dm {
3742 type boolean;
3743 description
3744 "Whether to enable delay measurement";
3745 }
3746 leaf two-way {
3747 type boolean;
3748 description
3749 "Whether delay measurement is two-way (true) of one-
3750 way (false)";
3751 }
3752 description
3753 "Container for delay measurement";
3754 }
3755 leaf frame-size {
3756 type uint32;
3757 description
3758 "Frame size";
3759 }
3760 leaf session-type {
3761 type enumeration {
3762 enum proactive {
3763 description
3764 "Proactive mode";
3765 }
3766 enum on-demand {
3767 description
3768 "On demand mode";
3769 }
3770 }
3771 description
3772 "Session type";
3773 }
3774 description
3775 "List for y-1731.";
3776 }
3777 description
3778 "Grouping for y.1731";
3779 }
3781 grouping enni-site-info-grouping {
3782 container site-info {
3783 leaf site-name {
3784 type string;
3785 description
3786 "Site name";
3787 }
3788 leaf address {
3789 type inet:ip-address;
3790 description
3791 "Address";
3792 }
3793 leaf Edge-Gateway-Device-Info {
3794 type string;
3795 description
3796 "Edge Gateway Device Info ";
3797 }
3798 description
3799 "Container of site info configurations";
3800 }
3801 description
3802 "Grouping for site information";
3803 }
3805 grouping site-security {
3806 container security-filtering {
3807 uses mac-loop-prevention-grouping;
3808 container access-control-list {
3809 list mac {
3810 key "mac-address";
3811 leaf mac-address {
3812 type yang:mac-address;
3813 description
3814 "MAC address";
3815 }
3816 description
3817 "List for MAC";
3818 }
3819 description
3820 "Container for access control";
3821 }
3822 uses mac-addr-limit-grouping;
3823 uses B-U-M-storm-control-grouping;
3824 description
3825 "Security parameters";
3826 }
3827 description
3828 "This grouping defines security parameters for a site";
3829 }
3831 grouping lacp-grouping {
3832 container LACP {
3833 leaf LACP-state {
3834 type boolean;
3835 description
3836 "LACP on/off";
3837 }
3838 leaf LACP-mode {
3839 type boolean;
3840 description
3841 "LACP mode";
3842 }
3843 leaf LACP-speed {
3844 type boolean;
3845 description
3846 "LACP speed";
3847 }
3848 leaf mini-link {
3849 type uint32;
3850 description
3851 "Mini link";
3852 }
3853 leaf system-priority {
3854 type uint16;
3855 description
3856 "Indicates the LACP priority for the system.
3857 The range is from 0 to 65535.
3858 The default is 32768.";
3859 }
3860 container Micro-BFD {
3861 if-feature Micro-BFD;
3862 leaf Micro-BFD-on-off {
3863 type enumeration {
3864 enum on {
3865 description
3866 "Micro-bfd on";
3867 }
3868 enum off {
3869 description
3870 "Micro-bfd off";
3871 }
3872 }
3873 description
3874 "Micro BFD ON/OFF";
3875 }
3876 leaf bfd-interval {
3877 type uint32;
3878 description
3879 "BFD interval";
3880 }
3881 leaf bfd-hold-timer {
3882 type uint32;
3883 description
3884 "BFD hold timer";
3885 }
3886 description
3887 "Container of Micro-BFD configurations";
3888 }
3889 container bfd {
3890 if-feature bfd;
3891 leaf bfd-enabled {
3892 type boolean;
3893 description
3894 "BFD activation";
3895 }
3896 choice holdtime {
3897 case profile {
3898 leaf profile-name {
3899 type string;
3900 description
3901 "Service provider well known profile.";
3902 }
3903 description
3904 "Service provider well known profile.";
3905 }
3906 case fixed {
3907 leaf fixed-value {
3908 type uint32;
3909 units msec;
3910 description
3911 "Expected hold time expressed in msec.";
3912 }
3913 }
3914 description
3915 "Choice for hold time flavor.";
3917 }
3918 description
3919 "Container for BFD.";
3920 }
3921 container Member-link-list {
3922 list member-link {
3923 key "name";
3924 leaf name {
3925 type string;
3926 description
3927 "Member link name";
3928 }
3929 leaf port-speed {
3930 type uint32;
3931 description
3932 "Port speed";
3933 }
3934 leaf mode {
3935 type neg-mode;
3936 description
3937 "Negotiation mode";
3938 }
3939 leaf mtu {
3940 type uint32;
3941 description
3942 "MTU";
3943 }
3944 container oam-802.3AH-link {
3945 if-feature oam-3ah;
3946 leaf enable {
3947 type boolean;
3948 description
3949 "Indicate whether support oam 802.3 ah link";
3950 }
3951 description
3952 "Container for oam 802.3 ah link.";
3953 }
3954 description
3955 "Member link";
3956 }
3957 description
3958 "Container of Member link list";
3959 }
3960 leaf flow-control {
3961 type string;
3962 description
3963 "Flow control";
3964 }
3965 leaf encapsulation-type {
3966 type enumeration {
3967 enum VLAN {
3968 description
3969 "VLAN";
3970 }
3971 enum ether {
3972 description
3973 "Ethernet";
3974 }
3975 }
3976 description
3977 "Encapsulation type";
3978 }
3979 leaf ethertype {
3980 type string;
3981 description
3982 "Ether type";
3983 }
3984 leaf lldp {
3985 type boolean;
3986 description
3987 "LLDP";
3988 }
3989 description
3990 "LACP";
3991 }
3992 description
3993 "Grouping for lacp";
3994 }
3996 grouping phy-interface-grouping {
3997 container phy-interface {
3998 leaf port-number {
3999 type uint32;
4000 description
4001 "Port number";
4002 }
4003 leaf port-speed {
4004 type uint32;
4005 description
4006 "Port speed";
4007 }
4008 leaf mode {
4009 type neg-mode;
4010 description
4011 "Negotiation mode";
4012 }
4013 leaf phy-mtu {
4014 type uint32;
4015 description
4016 "PHY MTU";
4017 }
4018 leaf flow-control {
4019 type string;
4020 description
4021 "Flow control";
4022 }
4023 leaf encapsulation-type {
4024 type enumeration {
4025 enum VLAN {
4026 description
4027 "VLAN";
4028 }
4029 enum Ethernet {
4030 description
4031 "Ethernet";
4032 }
4033 }
4034 description
4035 "Encapsulation-type";
4036 }
4037 leaf ethertype {
4038 type string;
4039 description
4040 "Ethertype";
4041 }
4042 leaf lldp {
4043 type boolean;
4044 description
4045 "LLDP";
4046 }
4047 container oam-802.3AH-link {
4048 if-feature oam-3ah;
4049 leaf enable {
4050 type boolean;
4051 description
4052 "Indicate whether support oam 802.3 ah link";
4053 }
4054 description
4055 "Container for oam 802.3 ah link.";
4056 }
4057 leaf uni-loop-prevention {
4058 type boolean;
4059 description
4060 "If this leaf set to truth that the port automatically
4061 goes down when a physical loopback is detect.";
4062 }
4063 description
4064 "Container of PHY Interface Attributes configurations";
4065 }
4066 description
4067 "Grouping for phy interface.";
4068 }
4070 grouping lag-interface-grouping {
4071 container LAG-interface {
4072 list LAG-interface {
4073 key "LAG-interface-number";
4074 leaf LAG-interface-number {
4075 type uint32;
4076 description
4077 "LAG interface number";
4078 }
4079 uses lacp-grouping;
4080 description
4081 "List of LAG interfaces";
4082 }
4083 description
4084 "Container of LAG interface attributes configuration";
4085 }
4086 description
4087 "Grouping for LAG interface";
4088 }
4089 grouping l2-access-grouping {
4090 container dot1q {
4091 when "'../l2-access-type'='dot1q'";
4092 leaf physical-inf {
4093 type string;
4094 description
4095 "Physical Interface";
4096 }
4097 leaf vlan-id {
4098 type uint32;
4099 description
4100 "VLAN identifier";
4101 }
4102 description
4103 "Qot1q";
4104 }
4105 container qinq {
4106 when "'../l2-access-type'='qinq'";
4107 leaf s-vlan-id {
4108 type uint32;
4109 description
4110 "S-VLAN Identifier";
4111 }
4112 leaf c-vlan-id {
4113 type uint32;
4114 description
4115 "C-VLAN Identifier";
4116 }
4117 description
4118 "QinQ";
4119 }
4120 leaf sub-if-id {
4121 when "'../l2-access-type'='sub-interface'";
4122 type uint32;
4123 description
4124 "Sub interface ID";
4125 }
4126 container vxlan {
4127 when "'../l2-access-type'='vxlan'";
4128 leaf vni-id {
4129 type uint32;
4130 description
4131 "VNI Identifier";
4132 }
4133 list peer-list {
4134 key peer-ip;
4135 leaf peer-ip {
4136 type inet:ip-address;
4137 description
4138 "Peer IP";
4139 }
4140 description
4141 "List for peer IP";
4142 }
4143 description
4144 "QinQ";
4145 }
4146 description
4147 "Grouping for Layer2 access";
4148 }
4150 grouping ethernet-connection-grouping {
4151 container ethernet-connection {
4152 leaf ESI {
4153 type string;
4154 description
4155 "Ethernet segment id";
4156 }
4157 leaf interface-description {
4158 type string;
4159 description
4160 "Interface description";
4161 }
4162 container vlan {
4163 leaf vlan-id {
4164 type uint32;
4165 description
4166 "VLAN-ID/Ethernet Tag configurations";
4167 }
4168 description
4169 "Abstract container for VLAN";
4170 }
4171 uses l2-access-grouping;
4172 uses phy-interface-grouping;
4173 uses lag-interface-grouping;
4174 description
4175 "Container for bearer";
4176 }
4177 description
4178 "Grouping for bearer.";
4179 }
4181 grouping evc-mtu-grouping {
4182 leaf evc-mtu {
4183 type uint32;
4184 description
4185 "EVC MTU";
4186 }
4187 description
4188 "Grouping for evc mtu";
4189 }
4191 grouping mac-addr-limit-grouping {
4192 container mac-addr-limit {
4193 leaf exceeding-option {
4194 type uint32;
4195 description
4196 "Exceeding option";
4197 }
4198 description
4199 "Container of MAC-Addr limit configurations";
4200 }
4201 description
4202 "Grouping for mac address limit";
4203 }
4204 grouping availability-grouping {
4205 container availability {
4206 choice redundancy-mode {
4207 case single-active {
4208 leaf single-active {
4209 type boolean;
4210 description
4211 "Single active";
4212 }
4213 description
4214 "Single active case";
4215 }
4216 case all-active {
4217 leaf all-active {
4218 type boolean;
4219 description
4220 "All active";
4221 }
4222 description
4223 "All active case";
4224 }
4225 description
4226 "Redundancy mode choice";
4227 }
4228 description
4229 "Container of availability optional configurations";
4230 }
4231 description
4232 "Grouping for availability";
4233 }
4235 grouping l2cp-grouping {
4236 container L2CP-control {
4237 leaf stp-rstp-mstp {
4238 type control-mode;
4239 description
4240 "STP/RSTP/MSTP";
4241 }
4242 leaf pause {
4243 type control-mode;
4244 description
4245 "Pause";
4246 }
4247 leaf lacp-lamp {
4248 type control-mode;
4249 description
4250 "LACP/LAMP";
4251 }
4252 leaf link-oam {
4253 type control-mode;
4254 description
4255 "Link OAM";
4256 }
4257 leaf esmc {
4258 type control-mode;
4259 description
4260 "ESMC";
4261 }
4262 leaf l2cp-802.1x {
4263 type control-mode;
4264 description
4265 "802.x";
4266 }
4267 leaf e-lmi {
4268 type control-mode;
4269 description
4270 "E-LMI";
4271 }
4272 leaf lldp {
4273 type boolean;
4274 description
4275 "LLDP";
4276 }
4277 leaf ptp-peer-delay {
4278 type control-mode;
4279 description
4280 "PTP peer delay";
4281 }
4282 leaf garp-mrp {
4283 type control-mode;
4284 description
4285 "GARP/MRP";
4286 }
4287 leaf provider-bridge-group {
4288 type control-mode;
4289 description
4290 "Provider bridge group reserved MAC address
4291 01-80-C2-00-00-08";
4292 }
4293 leaf provider-bridge-mvrp {
4294 type control-mode;
4295 description
4296 "Provider bridge MVRP reserved MAC address
4297 01-80-C2-00-00-0D";
4298 }
4299 description
4300 "Container of L2CP control configurations";
4301 }
4302 description
4303 "Grouping for l2cp control";
4304 }
4306 grouping service-level-grouping {
4307 container service-level {
4308 leaf cos-identifier {
4309 type identityref {
4310 base cos-id;
4311 }
4312 description
4313 "COS Identifier [ EVC | EVC + PCP ]";
4314 }
4315 leaf color-identifier {
4316 type identityref {
4317 base color-id;
4318 }
4319 description
4320 "Color Identifier [ EVC | EVC + CVLAN ]";
4321 }
4322 leaf ingress-bw-profile-per-evc {
4323 type string;
4324 description
4325 "Ingress Bandwidth Profile per EVC";
4326 }
4327 leaf ingress-bw-profile-per-cos-id {
4328 type string;
4329 description
4330 "Ingress Bandwidth Profile per COS Identifier";
4331 }
4332 leaf egress-bw-profile-per-evc {
4333 type string;
4334 description
4335 "Egress Bandwidth Profile per EVC";
4336 }
4337 leaf egress-bw-profile-per-cos-id {
4338 type string;
4339 description
4340 "Egress Bandwidth Profile per COS Identifier";
4341 }
4342 leaf byte-offset {
4343 type uint16;
4344 description
4345 "For not including extra VLAN tags in the QoS
4346 calculation";
4347 }
4348 leaf policing {
4349 type identityref {
4350 base policing;
4351 }
4352 description
4353 "The policing can be either one-rate,
4354 two-color (1R2C) or two-rate, three-color (2R3C)";
4355 }
4356 leaf perf-tier-opt {
4357 type identityref {
4358 base perf-tier-opt;
4359 }
4360 description
4361 "Performance tier option";
4362 }
4363 leaf COS {
4364 type uint32;
4365 description
4366 "Class of Service";
4367 }
4368 description
4369 "Container of service level configurations.";
4370 }
4371 description
4372 "Grouping for service level.";
4373 }
4375 grouping B-U-M-storm-control-grouping {
4376 container B-U-M-storm-control {
4377 leaf BUM-overall-rate {
4378 type uint32;
4379 description
4380 "overall rate for BUM";
4381 }
4382 list BUM-rate-per-type {
4383 key "type";
4384 leaf type {
4385 type identityref {
4386 base BUM-type;
4387 }
4388 description
4389 "BUM type";
4390 }
4391 leaf rate {
4392 type uint32;
4393 description
4394 "rate for BUM";
4395 }
4396 description
4397 "List of rate per type";
4398 }
4399 description
4400 "Container of B-U-M-strom-control configurations";
4401 }
4402 description
4403 "Grouping for B-U-M-strom-control";
4404 }
4406 grouping mac-loop-prevention-grouping {
4407 container mac-loop-prevention {
4408 leaf frequency {
4409 type uint32;
4410 description
4411 "Frequency";
4412 }
4413 leaf protection-type {
4414 type identityref {
4415 base loop-prevention-type;
4416 }
4417 description
4418 "Protection type";
4419 }
4420 leaf number-retries {
4421 type uint32;
4422 description
4423 "Number of retries";
4424 }
4425 description
4426 "Container of MAC loop prevention.";
4427 }
4428 description
4429 "Grouping for MAC loop prevention";
4430 }
4432 grouping ethernet-svc-oam-grouping {
4433 container Ethernet-Service-OAM {
4434 leaf MD-name {
4435 type string;
4436 description
4437 "Maintenance domain name";
4438 }
4439 leaf MD-level {
4440 type uint8;
4441 description
4442 "Maintenance domain level";
4443 }
4444 container cfm-802.1-ag {
4445 list n2-uni-c {
4446 key "MAID";
4447 uses cfm-802-grouping;
4448 description
4449 "List of UNI-N to UNI-C";
4450 }
4451 list n2-uni-n {
4452 key "MAID";
4453 uses cfm-802-grouping;
4454 description
4455 "List of UNI-N to UNI-N";
4456 }
4457 description
4458 "Container of 802.1ag CFM configurations.";
4459 }
4460 uses y-1731;
4461 description
4462 "Container for Ethernet service OAM.";
4463 }
4464 description
4465 "Grouping for Ethernet service OAM.";
4466 }
4468 grouping fate-sharing-group {
4469 container groups {
4470 leaf fate-sharing-group-size {
4471 type uint16;
4472 description
4473 "Fate sharing group size.";
4474 }
4475 list group {
4476 key group-id;
4477 leaf group-id {
4478 type string;
4479 description
4480 "Group-id the site network access
4481 is belonging to";
4482 }
4483 description
4484 "List of group-id";
4485 }
4486 description
4487 "Groups the fate sharing group member
4488 is belonging to";
4489 }
4490 description
4491 "Grouping for Fate sharing group.";
4493 }
4495 grouping site-group {
4496 container groups {
4497 list group {
4498 key group-id;
4499 leaf group-id {
4500 type string;
4501 description
4502 "Group-id the site is belonging to";
4503 }
4504 description
4505 "List of group-id";
4506 }
4507 description
4508 "Groups the site or site-network-access
4509 is belonging to.";
4510 }
4511 description
4512 "Grouping definition to assign
4513 group-ids to site or site-network-access";
4514 }
4516 grouping access-diversity {
4517 container access-diversity {
4518 if-feature site-diversity;
4519 uses fate-sharing-group;
4520 container constraints {
4521 list constraint {
4522 key constraint-type;
4523 leaf constraint-type {
4524 type identityref {
4525 base placement-diversity;
4526 }
4527 description
4528 "Diversity constraint type.";
4529 }
4530 container target {
4531 choice target-flavor {
4532 case id {
4533 list group {
4534 key group-id;
4535 leaf group-id {
4536 type string;
4537 description
4538 "The constraint will apply
4539 against this particular
4540 group-id";
4542 }
4543 description
4544 "List of groups";
4545 }
4546 }
4547 case all-accesses {
4548 leaf all-other-accesses {
4549 type empty;
4550 description
4551 "The constraint will apply
4552 against all other site network
4553 access of this site";
4554 }
4555 }
4556 case all-groups {
4557 leaf all-other-groups {
4558 type empty;
4559 description
4560 "The constraint will apply
4561 against all other groups the
4562 customer is managing";
4563 }
4564 }
4565 description
4566 "Choice for the group definition";
4567 }
4568 description
4569 "The constraint will apply against
4570 this list of groups";
4571 }
4572 description
4573 "List of constraints";
4574 }
4575 description
4576 "Constraints for placing this site
4577 network access";
4578 }
4579 description
4580 "Diversity parameters.";
4581 }
4582 description
4583 "This grouping defines access diversity
4584 parameters";
4585 }
4587 grouping request-type-profile-grouping {
4588 container request-type-profile {
4589 choice request-type-choice {
4590 case dot1q-case {
4591 container dot1q {
4592 leaf physical-if {
4593 type string;
4594 description
4595 "Physical interface";
4596 }
4597 leaf vlan-id {
4598 type uint16;
4599 description
4600 "VLAN ID";
4601 }
4602 description
4603 "Container for dot1q.";
4604 }
4605 description
4606 "Case for dot1q";
4607 }
4608 case physical-case {
4609 leaf physical-if {
4610 type string;
4611 description
4612 "Physical interface";
4613 }
4614 leaf circuit-id {
4615 type string;
4616 description
4617 "Circuit ID";
4618 }
4619 description
4620 "Physical case";
4621 }
4622 description
4623 "Choice for request type";
4624 }
4625 description
4626 "Container for request type profile.";
4627 }
4628 description
4629 "Grouping for request type profile";
4630 }
4632 grouping site-attachment-bearer {
4633 container bearer {
4634 container requested-type {
4635 if-feature requested-type;
4636 leaf requested-type {
4637 type string;
4638 description
4639 "Type of requested bearer Ethernet, DSL,
4640 Wireless ... Operator specific.";
4641 }
4642 leaf strict {
4643 type boolean;
4644 default false;
4645 description
4646 "Define if the requested-type is a preference
4647 or a strict requirement.";
4648 }
4649 uses request-type-profile-grouping;
4650 description
4651 "Container for requested type.";
4652 }
4653 leaf always-on {
4654 if-feature always-on;
4655 type boolean;
4656 default true;
4657 description
4658 "Request for an always on access type.
4659 This means no Dial access type for
4660 example.";
4661 }
4662 leaf bearer-reference {
4663 if-feature bearer-reference;
4664 type string;
4665 description
4666 "This is an internal reference for the
4667 service provider.";
4668 }
4669 description
4670 "Bearer specific parameters.
4671 To be augmented.";
4672 }
4673 description
4674 "Grouping to define physical properties of
4675 a site attachment.";
4676 }
4678 grouping vpn-attachment-grouping {
4679 container vpn-attachment {
4680 leaf device-id {
4681 type string;
4682 description
4683 "Device ID";
4684 }
4685 container management {
4686 leaf address-family {
4687 type identityref {
4688 base address-family;
4689 }
4690 description
4691 "Address family used for management.";
4692 }
4693 leaf address {
4694 type inet:ip-address;
4695 description
4696 "Management address";
4697 }
4698 description
4699 "Management configuration..";
4700 }
4701 choice attachment-flavor {
4702 case vpn-id {
4703 leaf vpn-id {
4704 type leafref {
4705 path "/l2vpn-svc/vpn-services"+
4706 "/vpn-svc/vpn-id";
4707 }
4708 description
4709 "Reference to a VPN.";
4710 }
4711 leaf site-role {
4712 type identityref {
4713 base site-role;
4714 }
4715 default any-to-any-role;
4716 description
4717 "Role of the site in the IPVPN.";
4718 }
4719 }
4720 mandatory true;
4721 description
4722 "Choice for VPN attachment flavor.";
4723 }
4724 description
4725 "Defines VPN attachment of a site.";
4726 }
4727 description
4728 "Grouping for access attachment";
4729 }
4731 grouping site-service-basic {
4732 container svc-input-bandwidth {
4733 if-feature input-bw;
4734 list input-bandwidth {
4735 key "id type";
4736 leaf id {
4737 type string;
4738 description
4739 "ID";
4740 }
4741 leaf type {
4742 type identityref {
4743 base bw-type;
4744 }
4745 description
4746 "Bandwidth Type";
4747 }
4748 leaf evc-id {
4749 type svc-id;
4750 description
4751 "EVC ID";
4752 }
4753 leaf CIR {
4754 type uint32;
4755 description
4756 "Committed Information Rate";
4757 }
4758 leaf CBS {
4759 type uint32;
4760 description
4761 "Committed Burst Size";
4762 }
4763 leaf EIR {
4764 type uint32;
4765 description
4766 "Excess Information Rate";
4767 }
4768 leaf EBS {
4769 type uint32;
4770 description
4771 "Excess Burst Size";
4772 }
4773 leaf CM {
4774 type uint32;
4775 description
4776 "Color Mode";
4777 }
4778 description
4779 "List for input bandwidth";
4780 }
4781 description
4782 "From the PE perspective, the service input
4783 bandwidth of the connection.";
4784 }
4785 container svc-output-bandwidth {
4786 if-feature output-bw;
4787 list output-bandwidth {
4788 key "id type";
4789 leaf id {
4790 type string;
4791 description
4792 "ID";
4793 }
4794 leaf type {
4795 type identityref {
4796 base bw-type;
4797 }
4798 description
4799 "Bandwidth Type";
4800 }
4801 leaf evc-id {
4802 type svc-id;
4803 description
4804 "EVC ID";
4805 }
4806 leaf CIR {
4807 type uint32;
4808 description
4809 "Committed Information Rate";
4810 }
4811 leaf CBS {
4812 type uint32;
4813 description
4814 "Committed Burst Size";
4815 }
4816 leaf EIR {
4817 type uint32;
4818 description
4819 "Excess Information Rate";
4820 }
4821 leaf EBS {
4822 type uint32;
4823 description
4824 "Excess Burst Size";
4825 }
4826 leaf CM {
4827 type uint32;
4828 description
4829 "Color Mode";
4831 }
4832 description
4833 "List for output bandwidth";
4835 }
4836 description
4837 "From the PE perspective, the service output
4838 bandwidth of the connection.";
4839 }
4840 description
4841 "Grouping for site service";
4842 }
4844 grouping flow-definition {
4845 container match-flow {
4846 leaf dscp {
4847 type inet:dscp;
4848 description
4849 "DSCP value.";
4850 }
4851 leaf dot1p {
4852 type uint8 {
4853 range "0 .. 7";
4854 }
4855 description
4856 "802.1p matching.";
4857 }
4858 leaf pcp {
4859 type uint8;
4860 description
4861 "PCP value";
4862 }
4863 leaf src-mac {
4864 type yang:mac-address;
4865 description
4866 "Source MAC";
4867 }
4868 leaf dst-mac {
4869 type yang:mac-address;
4870 description
4871 "Destination MAC";
4872 }
4873 container cos-color-id {
4874 leaf device-id {
4875 type string;
4876 description
4877 "Device ID";
4878 }
4879 leaf cos-label {
4880 type identityref {
4881 base cos-id;
4882 }
4883 description
4884 "COS label";
4885 }
4886 leaf pcp {
4887 type uint8;
4888 description
4889 "PCP value";
4890 }
4891 leaf dscp {
4892 type inet:dscp;
4893 description
4894 "DSCP value.";
4895 }
4896 description
4897 "Container for cos color id";
4898 }
4899 leaf color-type {
4900 type identityref {
4901 base color-type;
4902 }
4903 description
4904 "Color Types";
4905 }
4906 leaf-list target-sites {
4907 type svc-id;
4908 description
4909 "Identify a site as traffic destination.";
4910 }
4911 description
4912 "Describe flow matching criterions.";
4913 }
4914 description
4915 "Flow definition based on criteria.";
4916 }
4918 grouping site-service-qos-profile {
4919 container qos {
4920 if-feature qos;
4921 container qos-classification-policy {
4922 list rule {
4923 key id;
4924 ordered-by user;
4925 leaf id {
4926 type uint16;
4927 description
4928 "ID of the rule.";
4929 }
4930 choice match-type {
4931 case match-flow {
4932 uses flow-definition;
4933 }
4934 case match-phy-port {
4935 leaf match-phy-port {
4936 type uint16;
4937 description
4938 "Defines the physical port
4939 to match.";
4940 }
4941 }
4942 description
4943 "Choice for classification";
4944 }
4945 leaf target-class-id {
4946 type string;
4947 description
4948 "Identification of the class of service.
4949 This identifier is internal to the
4950 administration.";
4951 }
4952 description
4953 "List of marking rules.";
4954 }
4955 description
4956 "Need to express marking rules ...";
4957 }
4958 container qos-profile {
4959 choice qos-profile {
4960 description
4961 "Choice for QoS profile.
4962 Can be standard profile or custom.";
4963 case standard {
4964 leaf ingress-profile {
4965 type string;
4966 description
4967 "Ingress QoS Profile to be used";
4968 }
4969 leaf egress-profile {
4970 type string;
4971 description
4972 "Egress QoS Profile to be used";
4973 }
4974 }
4975 case custom {
4976 container classes {
4977 if-feature qos-custom;
4978 list class {
4979 key class-id;
4980 leaf class-id {
4981 type string;
4982 description
4983 "Identification of the class of
4984 service. This identifier is internal
4985 to the administration.";
4986 }
4987 leaf direction {
4988 type direction-type;
4989 description
4990 "Direction type";
4991 }
4992 leaf policing {
4993 type identityref {
4994 base policing;
4995 }
4996 description
4997 "The policing can be either one-rate,
4998 two-color (1R2C) or two-rate, three-color
4999 (2R3C)";
5000 }
5001 leaf byte-offset {
5002 type uint16;
5003 description
5004 "For not including extra VLAN tags in the QoS
5005 calculation";
5006 }
5007 leaf perf-tier-opt {
5008 type identityref {
5009 base perf-tier-opt;
5010 }
5011 description
5012 "Performance tier option";
5013 }
5014 leaf rate-limit {
5015 type uint8;
5016 units percent;
5017 description
5018 "To be used if class must be rate limited.
5019 Expressed as percentage of the svc-bw.";
5020 }
5021 leaf discard-percentage {
5022 type uint8;
5023 default 100;
5024 description
5025 "The value of the discard-percentage,
5026 Expressed as pecentage of the svc-bw ";
5027 }
5028 container frame-delay {
5029 choice flavor {
5030 case lowest {
5031 leaf use-low-del {
5032 type empty;
5033 description
5034 "The traffic class should use
5035 the lowest delay path";
5036 }
5037 }
5038 case boundary {
5039 leaf delay-bound {
5040 type uint16;
5041 units msec;
5042 description
5043 "The traffic class should use
5044 a path with a defined maximum
5045 delay.";
5046 }
5047 }
5048 description
5049 "Delay constraint on the traffic
5050 class";
5051 }
5052 description
5053 "Delay constraint on the traffic
5054 class";
5055 }
5056 container frame-jitter {
5057 choice flavor {
5058 case lowest {
5059 leaf use-low-jit {
5060 type empty;
5061 description
5062 "The traffic class should use
5063 the lowest jitter path";
5064 }
5065 }
5066 case boundary {
5067 leaf delay-bound {
5068 type uint32;
5069 units usec;
5070 description
5071 "The traffic class should use
5072 a path with a defined maximum
5073 jitter.";
5074 }
5075 }
5076 description
5077 "Jitter constraint on the traffic
5078 class";
5079 }
5080 description
5081 "Jitter constraint on the traffic
5082 class";
5083 }
5084 container frame-loss {
5085 leaf fr-loss-rate {
5086 type decimal64 {
5087 fraction-digits 2;
5088 }
5089 description
5090 "Loss constraint on the traffic class";
5091 }
5092 description
5093 "Container for frame loss";
5094 }
5095 description
5096 "List of class of services.";
5097 }
5098 description
5099 "Container for list of class of services.";
5100 }
5101 }
5102 }
5103 description
5104 "Qos profile configuration.";
5105 }
5106 description
5107 "QoS configuration.";
5108 }
5109 description
5110 "This grouping defines QoS parameters
5111 for a site";
5112 }
5114 grouping service-grouping {
5115 container service {
5116 uses site-service-basic;
5117 uses site-service;
5118 leaf service-multiplexing {
5119 type boolean;
5120 description
5121 "Service multiplexing";
5122 }
5123 uses site-service-qos-profile;
5124 description
5125 "Container for service";
5126 }
5127 description
5128 "Grouping for service.";
5129 }
5131 /* MAIN L2VPN SERVICE */
5133 container l2vpn-svc {
5134 container customer-info {
5135 uses customer-info-grouping;
5136 description
5137 "Container for customer information.";
5138 }
5139 container vpn-services {
5140 list vpn-svc {
5141 key "vpn-id";
5142 leaf vpn-id {
5143 type svc-id;
5144 description
5145 "Defining a service id.";
5146 }
5147 leaf svc-type {
5148 type identityref {
5149 base service-type;
5150 }
5151 description
5152 "Service type";
5153 }
5154 uses svc-type-grouping;
5155 container ethernet-svc-type {
5156 uses ethernet-service-type;
5157 description
5158 "Container of Ethernet service type";
5159 }
5160 leaf svc-topo {
5161 type identityref {
5162 base svc-topo-type;
5163 }
5164 description
5165 "Defining service topology, such as
5166 point to point, multipoint to multipoint,
5167 rooted multipoint, etc.";
5168 }
5169 uses vpn-service-cloud-access; // need fixed??
5170 container ce-vlan-preservation {
5171 description
5172 "CE vlan preservation";
5173 }
5174 container metro-network-id {
5175 uses inter-mkt-service;
5176 uses intra-mkt-grouping;
5177 description
5178 "Container of Metro-Network ID configurations";
5179 }
5180 container L2CP-control {
5181 leaf stp-rstp-mstp {
5182 type control-mode;
5183 description
5184 "STP/RSTP/MSTP";
5185 }
5186 leaf pause {
5187 type control-mode;
5188 description
5189 "Pause";
5190 }
5191 leaf lldp {
5192 type boolean;
5193 description
5194 "LLDP";
5195 }
5196 description
5197 "Container of L2CP control configurations";
5198 }
5199 container load-balance-options {
5200 uses load-balance-grouping;
5201 description
5202 "Container for load balance options";
5203 }
5204 uses site-service;
5205 uses service-protection;
5206 container sla-targets {
5207 description
5208 "Container for SLA targets";
5209 }
5210 description
5211 "List of vpn-svc";
5212 }
5213 description
5214 "Container for VPN services.";
5216 }
5218 /* SITE */
5220 container sites {
5221 list site {
5222 key "site-id site-type";
5223 leaf site-id {
5224 type string;
5225 description
5226 "Site id";
5227 }
5228 leaf site-type {
5229 type identityref {
5230 base site-type;
5231 }
5232 description
5233 "Site type";
5234 }
5235 uses site-device;
5236 uses site-management;
5237 uses customer-location-info;
5238 uses site-diversity;
5239 uses site-vpn-policy ;
5240 container signaling-option {
5241 if-feature signaling-option;
5242 uses signaling-option-grouping;
5243 description
5244 "Container for signaling option";
5245 }
5246 container load-balance-options {
5247 uses load-balance-grouping;
5248 description
5249 "Container for load balance options";
5250 }
5251 uses operational-requirements-ops;
5252 container ports {
5253 list port {
5254 key "network-access-id";
5255 leaf network-access-id {
5256 type string;
5257 description
5258 "Identifier of network access";
5259 }
5260 leaf remote-carrier-name {
5261 when "'../site-type' = 'enni'" {
5262 description
5263 "Site type = enni";
5265 }
5266 type string;
5267 description
5268 "Remote carrier name";
5269 }
5270 uses access-diversity;
5271 uses site-attachment-bearer;
5272 uses ethernet-connection-grouping;
5273 uses l2cp-grouping;
5274 uses evc-mtu-grouping;
5275 uses availability-grouping;
5276 uses vpn-attachment-grouping;
5277 uses service-grouping;
5278 uses ethernet-svc-oam-grouping;
5279 uses site-security;
5280 description
5281 "List of ports";
5282 }
5283 description
5284 "Container of port configurations";
5285 }
5286 description
5287 "List of sites";
5288 }
5289 description
5290 "Container of site configurations";
5291 }
5293 description
5294 "Container for L2VPN service";
5295 }
5296 }
5297
5299 9. Security Considerations
5301 The YANG modules defined in this document MAY be accessed via the
5302 RESTCONF protocol [RFC8040] or NETCONF protocol ([RFC6241]). The
5303 lowest RESTCONF or NETCONF layer requires that the transport-layer
5304 protocol provides both data integrity and confidentiality, see
5305 Section 2 in [RFC8040] and [RFC6241]. The client MUST carefully
5306 examine the certificate presented by the server to determine if it
5307 meets the client's expectations, and the server MUST authenticate
5308 client access to any protected resource. The client identity derived
5309 from the authentication mechanism used is subject to the NETCONF
5310 Access Control Module (NACM) ([RFC6536]). Other protocols to access
5311 this YANG module are also required to support the similar mechanism.
5313 The data nodes defined in the "ietf-l2vpn-svc" YANG module MUST be
5314 carefully created/read/updated/deleted. The entries in the lists
5315 below include customer proprietary or confidential information,
5316 therefore only authorized clients MUST access the information and the
5317 other clients MUST NOT be able to access to the information.
5319 o /l2vpn-svc/customer-info/customer-info
5321 o /l2vpn-svc/vpn-services/vpn-svc
5323 o /l2vpn-svc/sites/site
5325 10. Acknowledgements
5327 Thanks to Qin Wu and Adrian Farrel for facilitating work on the
5328 initial revisions of this document.
5330 This document has drawn on the work of the L3SM Working Group
5331 expressed in [I-D.ietf-l3sm-l3vpn-service-model].
5333 11. IANA Considerations
5335 IANA is requested to assign a new URI from the IETF XML registry
5336 ([RFC3688]). The following URI is suggested:
5338 URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc
5339 Registrant Contact: L2SM WG
5340 XML: N/A, the requested URI is an XML namespace
5342 This document also requests a new YANG module name in the YANG Module
5343 Names registry ([RFC6020]) with the following suggestion:
5345 name: ietf-l2vpn-svc
5346 namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc
5347 prefix: l2vpn-svc
5348 reference: RFC XXXX
5350 12. References
5352 12.1. Normative References
5354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
5355 Requirement Levels", BCP 14, RFC 2119,
5356 DOI 10.17487/RFC2119, March 1997,
5357 .
5359 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
5360 DOI 10.17487/RFC3688, January 2004,
5361 .
5363 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
5364 "Encapsulation Methods for Transport of Ethernet over MPLS
5365 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
5366 .
5368 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
5369 LAN Service (VPLS) Using BGP for Auto-Discovery and
5370 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
5371 .
5373 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
5374 LAN Service (VPLS) Using Label Distribution Protocol (LDP)
5375 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
5376 .
5378 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
5379 the Network Configuration Protocol (NETCONF)", RFC 6020,
5380 DOI 10.17487/RFC6020, October 2010,
5381 .
5383 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
5384 and A. Bierman, Ed., "Network Configuration Protocol
5385 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
5386 .
5388 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
5389 Protocol (NETCONF) Access Control Model", RFC 6536,
5390 DOI 10.17487/RFC6536, March 2012,
5391 .
5393 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
5394 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
5395 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
5396 2015, .
5398 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
5399 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
5400 .
5402 12.2. Informative References
5404 [I-D.ietf-bess-evpn-yang]
5405 Brissette, P., Sajassi, A., Shah, H., Li, Z.,
5406 Tiruveedhula, K., Hussain, I., and J. Rabadan, "Yang Data
5407 Model for EVPN", draft-ietf-bess-evpn-yang-01 (work in
5408 progress), July 2016.
5410 [I-D.ietf-bess-l2vpn-yang]
5411 Shah, H., Brissette, P., Chen, I., Hussain, I., and B.
5412 Wen, "YANG Data Model for MPLS-based L2VPN", draft-ietf-
5413 bess-l2vpn-yang-02 (work in progress), October 2016.
5415 [I-D.ietf-l3sm-l3vpn-service-model]
5416 Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data
5417 Model for L3VPN service delivery", draft-ietf-l3sm-l3vpn-
5418 service-model-19 (work in progress), November 2016.
5420 [I-D.wu-opsawg-service-model-explained]
5421 Wu, Q., LIU, S., and A. Farrel, "Service Models
5422 Explained", draft-wu-opsawg-service-model-explained-05
5423 (work in progress), January 2017.
5425 [IEEE-802-1ag]
5426 IEEE, "802.1ag - Connectivity Fault Management", December
5427 2007.
5429 [ITU-T-Y-1731]
5430 ITU-T, "Recommendation Y.1731 - OAM functions and
5431 mechanisms for Ethernet based networks", February 2008.
5433 [MEF-23-2]
5434 MEF Forum, "Implementation Agreement MEF 23.2 : Carrier
5435 Ethernet Class of Service - Phase 3", August 2016.
5437 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
5438 Virtual Private Networks Using BGP for Auto-Discovery and
5439 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012,
5440 .
5442 Authors' Addresses
5444 Bin Wen
5445 Comcast
5447 Email: bin_wen@comcast.com
5448 Giuseppe Fioccola
5449 Telecom Italia
5451 Email: giuseppe.fioccola@telecomitalia.it
5453 Chongfeng Xie
5454 China Telecom
5456 Email: xiechf@ctbri.com.cn
5458 Luay Jalil
5459 Verizon
5461 Email: luay.jalil@verizon.com