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