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