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