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