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