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