idnits 2.17.1 draft-wen-l2sm-l2vpn-service-model-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 608 has weird spacing: '...lo-addr ine...' == Line 648 has weird spacing: '...roup-id strin...' == Line 662 has weird spacing: '...lo-addr ine...' -- The document date (October 25, 2016) is 2733 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'LAG-interface-number' is mentioned on line 696, but not defined == Missing Reference: 'ESI' is mentioned on line 736, but not defined == Missing Reference: 'MAID' is mentioned on line 806, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-17 ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-07) exists of draft-ietf-bess-evpn-yang-01 == Outdated reference: A later version (-10) exists of draft-ietf-bess-l2vpn-yang-00 == Outdated reference: A later version (-19) exists of draft-ietf-l3sm-l3vpn-service-model-18 == Outdated reference: A later version (-06) exists of draft-wu-opsawg-service-model-explained-03 Summary: 1 error (**), 0 flaws (~~), 12 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 5 Expires: April 28, 2017 Telecom Italia 6 C. Xie 7 China Telecom 8 L. Jalil 9 Verizon 10 October 25, 2016 12 A YANG Data Model for L2VPN Service Delivery 13 draft-wen-l2sm-l2vpn-service-model-02 15 Abstract 17 This document defines a YANG data model that can be used to configure 18 a Layer 2 Provider Provisioned VPN service. 20 This model is intended to be instantiated at management system to 21 deliver the overall service. This model is not a configuration model 22 to be used directly on network elements, but provides an abstracted 23 view of the Layer 2 VPN service configuration components. It is up 24 to a management system to take this as an input and use specific 25 configurations models to configure the different network elements to 26 deliver the service. How configuration of network elements is done 27 is out of scope of the document. 29 The data model in this document includes support for point-to-point 30 Virtual Private Wire Services (VPWS) and multipoint Virtual Private 31 LAN services (VPLS) that use Pseudowires signaled using the Label 32 Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as 33 described in RFC4761 and RFC6624. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in [RFC2119]. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on April 28, 2017. 58 Copyright Notice 60 Copyright (c) 2016 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 4 78 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 3. The Layer 2 VPN Service Model . . . . . . . . . . . . . . . . 5 80 3.1. Applicability of the Layer 2 VPN Service Model . . . . . 6 81 3.2. Layer 2 VPN Service Types . . . . . . . . . . . . . . . . 6 82 3.3. Layer 2 VPN Service Network Topology . . . . . . . . . . 7 83 3.4. Layer 2 VPN Ethernet Virtual Circuit Construct . . . . . 8 84 4. Service Data Model Usage . . . . . . . . . . . . . . . . . . 11 85 5. Design of the Data Model . . . . . . . . . . . . . . . . . . 13 86 5.1. Overview of Main Components of the Model . . . . . . . . 19 87 5.1.1. Customer Information . . . . . . . . . . . . . . . . 19 88 5.1.2. VPN Service Overview . . . . . . . . . . . . . . . . 19 89 5.1.2.1. Service Type . . . . . . . . . . . . . . . . . . 19 90 5.1.2.2. ethernet-svc-type . . . . . . . . . . . . . . . . 20 91 5.1.2.3. Metro Network Partition . . . . . . . . . . . . . 20 92 5.1.2.4. vpn-signaling-option . . . . . . . . . . . . . . 21 93 5.1.2.5. Load Balance Option . . . . . . . . . . . . . . . 23 94 5.1.2.6. SVLAN ID Ethernet Tag . . . . . . . . . . . . . . 24 95 5.1.2.7. CVLAN ID To EVC MAP . . . . . . . . . . . . . . . 24 96 5.1.2.8. Service Level MAC Limit . . . . . . . . . . . . . 25 97 5.1.2.9. Service Protection . . . . . . . . . . . . . . . 25 98 5.1.3. site . . . . . . . . . . . . . . . . . . . . . . . . 26 99 5.1.3.1. Generic Site Objects . . . . . . . . . . . . . . 26 100 6. Interaction with Other YANG Modules . . . . . . . . . . . . . 35 101 7. Service Model Usage Example . . . . . . . . . . . . . . . . . 36 102 8. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 36 103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 76 104 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 76 105 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76 106 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 107 12.1. Normative References . . . . . . . . . . . . . . . . . . 77 108 12.2. Informative References . . . . . . . . . . . . . . . . . 78 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79 111 1. Introduction 113 This document defines a YANG data model for Layer 2 VPN (L2VPN) 114 service configuration. This model is intended to be instantiated at 115 management system to allow a user (a customer or an application) to 116 request the service. This model is not a configuration model to be 117 used directly on network elements, but provides an abstracted view of 118 the L2VPN service configuration components. It is up to a management 119 system to take this as an input and use specific configurations 120 models to configure the different network elements to deliver the 121 service. How configuration of network elements is done is out of 122 scope of the document. 124 The data model in this document includes support for point-to-point 125 Virtual Private Wire Services (VPWS) and multipoint Virtual Private 126 LAN services (VPLS) that use Pseudowires signaled using the Label 127 Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as 128 described in [RFC4761] and [RFC6624]. 130 Further discussion of the way that service are modelled in YANG and 131 of the relationship between "customer service models" like the one 132 described in this document and configuration models can be found in 133 [I-D.wu-opsawg-service-model-explained]. Section 4 and Section 6 134 also provide more information of how this service model could be used 135 and how it fits into the overall modelling architecture. 137 1.1. Terminology 139 The following terms are defined in [RFC6241] and are not redefined 140 here: 142 o client 143 o configuration data 145 o server 147 o state data 149 The following terms are defined in [RFC6020] and are not redefined 150 here: 152 o augment 154 o data model 156 o data node 158 The terminology for describing YANG data models is found in 159 [RFC6020]. 161 1.2. Tree diagram 163 A simplified graphical representation of the data model is presented 164 in Section 5. 166 The meaning of the symbols in these diagrams is as follows: 168 o Brackets "[" and "]" enclose list keys. 170 o Curly braces "{" and "}" contain names of optional features that 171 make the corresponding node conditional. 173 o Abbreviations before data node names: "rw" means configuration 174 (read-write), and "ro" state data (read-only). 176 o Symbols after data node names: "?" means an optional node and "*" 177 denotes a "list" or "leaf-list". 179 o Parentheses enclose choice and case nodes, and case nodes are also 180 marked with a colon (":"). 182 o Ellipsis ("...") stands for contents of subtrees that are not 183 shown. 185 2. Definitions 187 This document uses the following terms: 189 Service Provider (SP): The organization (usually a commercial 190 undertaking) responsible for operating the network that offers VPN 191 services to clients and customers. 193 Customer Edge (CE) Device: Equipment that is dedicated to a 194 particular customer and is directly connected to one or more PE 195 devices via attachment circuits. A CE is usually located at the 196 customer premises, and is usually dedicated to a single VPN, 197 although it may support multiple VPNs if each one has separate 198 attachment circuits. The CE devices can be routers, bridges, 199 switches, or hosts. 201 Provider Edge (PE) Device: Equipment managed by the SP that can 202 support multiple VPNs for different customers, and is directly 203 connected to one or more CE devices via attachment circuits. A PE 204 is usually located at an SP point of presence (PoP) and is managed 205 by the SP. 207 Virtual Private LAN Service (VPLS): A VPLS is a provider service 208 that emulates the full functionality of a traditional Local Area 209 Network (LAN). A VPLS makes it possible to interconnect several 210 LAN segments over a packet switched network (PSN) and makes the 211 remote LAN segments behave as one single LAN. 213 Virtual Private Wire Service (VPWS): A VPWS is a point-to-point 214 circuit (i.e., link) connecting two CE devices. The link is 215 established as a logical through a packet switched network. The 216 CE in the customer network is connected to a PE in the provider 217 network via an Attachment Circuit (AC); the AC is either a 218 physical or a logical circuit. A VPWS differs from a VPLS in that 219 the VPLS is point-to-multipoint, while the VPWS is point-to-point. 220 In some implementations, a set of VPWSs is used to create a multi- 221 site L2VPN network. 223 3. The Layer 2 VPN Service Model 225 A Layer 2 VPN service is a collection of sites that are authorized to 226 exchange traffic between each other over a shared infrastructure of a 227 common technology. This Layer 2 VPN service model (L2SM) provides a 228 common understanding of how the corresponding Layer 2 VPN service is 229 to be deployed over the shared infrastructure. 231 This document presents the L2SM using the YANG data modeling language 232 [RFC6020] as a formal language that is both human-readable and 233 parsable by software for use with protocols such as NETCONF [RFC6241] 234 and RESTCONF [I-D.ietf-netconf-restconf]. 236 This service model is limited to VPWS and VPLS based VPNs as 237 described in [RFC4761] and [RFC6624]. 239 3.1. Applicability of the Layer 2 VPN Service Model 241 The L2SM defined in this document applies to both point-to-point 242 (E-Line) and multipoint-to-multipoint (E-LAN) carrier Ethernet 243 services. 245 Over the past decade, The MEF Forum (MEF) has published a series of 246 technical specifications of Ethernet virtual circuit service 247 attributes and implementation agreements between providers. Many 248 Ethernet VPN service providers worldwide have adopted these MEF 249 standards and developed backoffice tools accordingly. 251 Rather than introducing a new set of terminologies, the L2SM will 252 align with existing MEF attributes when it's applicable. Therefore, 253 service providers can easily integrate any new application that 254 leverages the L2SM data, Service Orchestrator for example, with 255 existing BSS/OSS toolsets. Service providers also have the option to 256 generate L2SM data for current L2VPN customer circuits already 257 deployed in the network. 259 3.2. Layer 2 VPN Service Types 261 A Layer 2 VPN circuit can be port-based; in which case any service 262 frames received from subscriber within contractual bandwidth will be 263 delivered to the corresponding remote site, regardless of customer 264 VLAN value (C-tag) of the incoming frame. The service frames can 265 also be native Ethernet frames without C-tag. In this scenario, only 266 one Ethernet Virtual Circuit (EVC) is allowed on a single provider to 267 subscriber link. 269 Contrary to the above use case, incoming customer service frames may 270 be split into multiple EVCs based on pre-arrangement between the 271 service provider and customer. Typically, C-tag of the incoming 272 frames will serve as the service delimiter for EVC multiplexing over 273 the same provider to subscriber interconnection. 275 Combining the service-multiplexing attribute with point-to-point 276 verses multipoint-to-multipoint connection type, a Layer 2 VPN 277 circuit may fall under one of the following service types: 279 o E-Line services: Point-to-Point Layer 2 connections. 281 EPL: In its simplest form, a port-based Ethernet Private Line 282 (EPL) service provides a high degree of transparency delivering 283 all customer service frames between UNI-to-UNI interfaces using 284 All-to-One Bundling. All unicast/broadcast/multicast packets 285 are delivered unconditionally over the EVC. No service 286 multiplexing is allowed on an EPL UNI interface. 288 EVPL: On the other hand, Ethernet Virtual Private Line (EVPL) 289 service supports multiplexing more than one Point-to-Point, or 290 even other virtual private services, on the same UNI interface. 291 Ingress service frames are conditionally transmitted through 292 one of the EVCs based upon pre-agreed C-tag to EVC mapping. 293 EVPL supports multiple C-tags to one EVC bundling. 295 o E-LAN services: Multipoint-to-Multipoint Layer 2 connections. 297 EP-LAN: Ethernet Private LAN Service (EP-LAN) transparently 298 connects multiple subscriber sites together with All-to-One 299 Bundling. No service multiplexing is allowed on an EP-LAN UNI 300 interface. 302 EVP-LAN: Some subscriber may desire more sophisticated control of 303 data access between multiple sites. Ethernet Virtual Private 304 LAN Service (EVP-LAN) allows connecting to multiple EVCs from 305 one or more of the UNI interfaces. Services frame disposition 306 is based on C-tag to EVC mapping. EVP-LAN supports multiple 307 C-tags to one EVC bundling. 309 3.3. Layer 2 VPN Service Network Topology 311 Figure 1depicts a typical service provider's physical network 312 topology. Most service providers have deployed an IP, MPLS, or 313 Segment Routing (SR) multi-service core infrastructure. Customer 314 Edge (CE) devices are placed at customer premises as demarcation 315 points to backhaul in profile service frames from the subscriber over 316 the access network to the Provider Edge (PE) equipment. The actual 317 transport technology or physical topology between CE and PE is 318 outside the scope of the L2SM model. 320 --- ---- --- 321 | | | | | | 322 | C +---+ CE | | C | 323 | | | | --------- | | 324 --- ----\ ( ) /--- 325 \ ---- ( ) ---- ---- / 326 \| | ( ) | | | |/ 327 | PE +---+ IP/MPLS/SR +---+ PE +---+ CE | 328 /| | ( Network ) | | | |\ 329 / ---- ( ) ---- ---- \ 330 --- ----/ ( ) \--- 331 | | | | ----+---- | | 332 | C +---+ CE | | | C | 333 | | | | --+-- | | 334 --- ---- | PE | --- 335 --+-- 336 | 337 --+-- 338 | CE | 339 --+-- 340 | 341 --+-- 342 | C | 343 ----- 345 Figure 1: Reference Network for the Use of the L2VPN Service Model 347 From the subscriber perspective, however, all the edge networks 348 devices are connected over a simulated LAN environment as shown in 349 Figure 2. Broadcast and multicast packets are sent to all 350 participants in the same bridge domain. 352 C---+----+---+---C 353 | | | 354 | | | 355 | | | 356 C---+ C +---C 358 Figure 2: Customer View of the L2VPN 360 3.4. Layer 2 VPN Ethernet Virtual Circuit Construct 362 The base model of EVC is shown in Figure 3. 364 Subscriber edge network device (C) connects to the service provider's 365 CE equipment. The link between C and CE devices is referred as User 366 Network Interface (UNI). For clarification, this is called UNI-C on 367 subscriber side and UNI-N on provider side. 369 The service provider is obligated to deliver the original service 370 frame across the network to the remote UNI-C. All Ethernet and IP 371 header information, including (but not limit to) source and 372 destination MAC addresses, EtherType, VLAN (C-tag), Class-of-Service 373 marking (802.1p or DSCP), etc. 375 In coming service frames are first examined at UNI-N based on C-tag, 376 Class-of-Services identifier, EtherType value. Conforming packets 377 are then metered against the contractual service bandwidth. In- 378 profile packets will be delivered to the remote UNI via the Ethernet 379 Virtual Circuit (EVC), which spans between UNI-N to UNI-N. 381 When both CEs are located in the same provider's network, a single 382 operator maintains the EVC. In this case, the EVC consists only one 383 Operator Virtual Circuit (OVC). 385 Typically, the CE device at customer premises is a layer 2 Ethernet 386 switch or NID. Service provider may choose to impose an outer VLAN 387 tag (S-tag) into the received subscriber traffic following 802.1ad 388 Q-in-Q standard, especially when Layer 2 aggregation devices exist 389 between CE and PE. 391 The uplink from CE to PE is referred as Internal Network-to-Network 392 Interface (I-NNI). When 802.1ad Q-in-Q is implemented, Ethernet 393 frames from CE to PE are double tagged with both provider and 394 subscriber VLANs (S-tag, C-tag). 396 Most service providers have deployed MPLS or SR multi-service core 397 infrastructure. Ingress service frames will be mapped to either 398 Ethernet Pseudowire (PWE) or VxLAN tunnel PE-to-PE. The details of 399 these tunneling mechanism are at the provider's discretion and not 400 part of the L2SM. 402 Service provider may also choose Seamless MPLS approach to expand the 403 PWE or VxLAN tunnel between UNI-N to UNI-N. 405 Service provider may leverage multi-protocol BGP to auto discover and 406 signal the PWE or VxLAN tunnel end points. 408 EVC 409 :<-------------------------------------------->: 410 : : 411 : : 412 : OVC (Optional) : 413 :<-------------------------------------------->: 414 : : 415 : : 416 : PW / VXLAN : 417 : :<-------------------------->: : 418 : : : : 419 : : : : 420 : : -------- : : 421 : : ( ) : : 422 --- ---- ---- ( ) ---- ---- --- 423 | | | | | | ( ) | | | | | | 424 | C +---+ CE +---+ PE +---+ IP/MPLS/SR +---+ PE +---+ CE +---+ C | 425 | | | | | | ( Network ) | | | | | | 426 --- ---- ---- ( ) ---- ---- --- 427 ^ ^ : ( ) : : 428 : : : -------- : : 429 UNI-C UNI-N : : : 430 : : : : 431 :<------>:<-------------------------->:<------>: 432 802.1ad IP/MPLS/SR Domain 802.1ad 433 q-in-q q-in-q 435 Figure 3: Architectural Model for EVC over a Single Network 437 Nevertheless, the remote site may be outside of the provider's 438 service territory. In this case, the provider may partner with the 439 operator of another metro network to provider service to the off-net 440 location as shown in Figure 4. 442 The first provider owns the customer relationship, thus the end-to- 443 end EVC. The EVC is comprised of two or more OVCs. Partially of the 444 EVC is an OVC from local UNI-C to the inter-provider interface. The 445 provider will purchase an Ethernet Access (E-Access) OVC from the 446 second operator to deliver packet to the remote UNI-C. 448 The inter-connect between the two operators edge gateway (EG) devices 449 is defined as the External Network-to-Network Interface (E-NNI). 451 EVC 452 :<---------------------------------------------------->: 453 : : 454 : : 455 : OVC (Optional) : 456 :<----------------------->: : 457 : : : 458 : : : 459 : PW / VXLAN : : 460 : :<------------------>: : 461 : : : : 462 : : : : 463 : : ----- : ----- : 464 : : ( ) : ( ) : 465 - -- -- ( IP/ ) ---- ---- ( IP/ ) -- -- - 466 |C+-+CE+-+PE+--+ MPLS/ +--+Edge+--+Edge+--+ MPLS/ +--+PE+-+CE+-+C| 467 - -- -- ( SR ) |G/W | |G/W | ( SR ) -- -- - 468 ^ ^ : ( ) ---- ---- ( ) ^ 469 : : : ----- ^ ^ ----- : 470 UNI UNI : ENNI ENNI : 471 C N : : : : 472 : : : : Remote 473 :<->:<------------------>:<->: Customer 474 802.1ad IP/MPLS/SR 802.1ad Site 475 q-in-q Domain q-in-q 477 Figure 4: Architectural Model for EVC over Multiple Networks 479 4. Service Data Model Usage 481 The L2VPN service model provides an abstracted interface to request, 482 configure and manage the components of a L2VPN service. The model is 483 used by a customer who purchases connectivity and other services from 484 an SP to communicate with that SP. 486 A typical usage is for this model to be an input for an orchestration 487 layer that is responsible for translating it into configuration 488 commands for the network elements that deliver/enable the service. 489 The network elements may be routers, but also servers (like AAA) 490 necessary within the network. 492 The configuration of network elements may be done using the Command 493 Line Interface (CLI), or any other configuration (or "southbound") 494 interface such as NETCONF [RFC6241] in combination with device- 495 specific and protocol-specific YANG models. 497 This way of using the service model is illustrated in Figure 5 and 498 described in more detail in [I-D.wu-opsawg-service-model-explained]. 499 The usage of this service model is not limited to this example: it 500 can be used by any component of the management system, but not 501 directly by network elements. 503 The usage and structure of this model should be compared to the Layer 504 3 VPN service model defined in [I-D.ietf-l3sm-l3vpn-service-model]. 506 ---------------------------- 507 | Customer Service Requester | 508 ---------------------------- 509 | 510 L2VPN | 511 Service | 512 Model | 513 | 514 ----------------------- 515 | Service Orchestration | 516 ----------------------- 517 | 518 | Service +-------------+ 519 | Delivery +------>| Application | 520 | Model | | BSS/OSS | 521 | V +-------------+ 522 ----------------------- 523 | Network Orchestration | 524 ----------------------- 525 | | 526 +----------------+ | 527 | Config manager | | 528 +----------------+ | Device 529 | | Models 530 | | 531 -------------------------------------------- 532 Network 534 Figure 5: Reference Architecture for the Use of the L2VPN Service 535 Model 537 Additionally, this data model can be compared with the service 538 delivery models described in [I-D.ietf-bess-l2vpn-yang] and 539 [I-D.ietf-bess-evpn-yang] as discussed in Section 6. 541 5. Design of the Data Model 543 The YANG module is divided in three main containers : customer-info, 544 vpn-services, and sites. 546 The customer-info defines global parameters for a specific customer. 548 The vpn-svc container under vpn-services defines global parameters 549 for the VPN service for a specific customer. 551 A site is composed of at least one uni-site or one enni-site. 553 Authorization of traffic exchange is done through what we call a VPN 554 policy or VPN topology defining routing exchange rules between sites. 556 The figure below describe the overall structure of the YANG module: 558 module: ietf-l2vpn-svc 559 +--rw l2vpn-svc 560 +--rw customer-info 561 | +--rw customer-info* [customer-account-number customer-name] 562 | +--rw customer-account-number uint32 563 | +--rw customer-name string 564 | +--rw customer-operation-center 565 | +--rw customer-noc-street-address? string 566 | +--rw customer-noc-phone-number 567 | +--rw main-phone-num? uint32 568 | +--rw extension-options? uint32 569 +--rw vpn-services 570 | +--rw vpn-svc* [svc-id] 571 | +--rw svc-id string 572 | +--rw svc-type 573 | | +--rw evc 574 | | | +--rw evc-id? boolean 575 | | | +--ro number-of-pe? uint32 576 | | | +--ro number-of-site? uint32 577 | | +--rw ovc 578 | | +--rw on-net-ovc-id? boolean 579 | | +--rw off-net-ov-id? boolean 580 | +--rw ethernet-svc-type 581 | | +--rw (ethernet-svc-type)? 582 | | +--:(e-line) 583 | | | +--rw epl? boolean 584 | | | +--rw evpl? boolean 585 | | +--:(e-lan) 586 | | | +--rw ep-lan? boolean 587 | | | +--rw evp-lan? boolean 588 | | +--:(e-access) 589 | | +--rw access-epl? boolean 590 | | +--rw access-evpl? boolean 591 | +--rw metro-network-id 592 | | +--rw inter-mkt-service? boolean 593 | | +--rw intra-mkt* [metro-mkt-id mkt-name] 594 | | +--rw metro-mkt-id uint32 595 | | +--rw mkt-name string 596 | +--rw signaling-option 597 | | +--rw signaling-option* [name type] 598 | | +--rw name string 599 | | +--rw type identityref 600 | | +--rw mp-bgp-l2vpn 601 | | | +--rw vpn-id? string 602 | | | +--rw type? identityref 603 | | +--rw mp-bgp-evpn 604 | | | +--rw vpn-id? string 605 | | | +--rw type? identityref 606 | | +--rw t-ldp-pwe 607 | | | +--rw PE-EG-list* [service-ip-lo-addr vc-id] 608 | | | +--rw service-ip-lo-addr inet:ip-address 609 | | | +--rw vc-id string 610 | | +--rw pwe-encapsulation-type 611 | | | +--rw ethernet? boolean 612 | | | +--rw vlan? boolean 613 | | +--rw pwe-mtu 614 | | | +--rw allow-mtu-mismatch? boolean 615 | | +--rw control-word 616 | +--rw load-balance-options 617 | | +--rw fat-pw? boolean 618 | | +--rw entropy-label? boolean 619 | | +--rw vxlan-source-port? string 620 | +--rw svlan-id-ethernet-tag? string 621 | +--rw cvlan-id-to-evc-map? string 622 | +--rw service-level-mac-limit? string 623 | +--rw service-protection 624 | | +--rw protection-model 625 | | +--rw peer-evc-id 626 | +--rw sla-targets 627 +--rw sites 628 +--rw site* [site-id site-type] 629 +--rw site-id string 630 +--rw site-type identityref 631 +--rw device 632 | +--rw devices* [device-id] 633 | +--rw device-id string 634 | +--rw site-name? string 635 | +--rw address? inet:ip-address 636 | +--rw management-transport? identityref 637 +--rw managemnt 638 | +--rw type? identityref 639 +--rw location 640 | +--rw address? string 641 | +--rw zip-code? string 642 | +--rw state? string 643 | +--rw city? string 644 | +--rw country-code? string 645 +--rw site-diversity {site-diversity}? 646 | +--rw groups 647 | +--rw group* [group-id] 648 | +--rw group-id string 649 +--rw security 650 +--rw signaling-option {signaling-option}? 651 | +--rw signaling-option* [name type] 652 | +--rw name string 653 | +--rw type identityref 654 | +--rw mp-bgp-l2vpn 655 | | +--rw vpn-id? string 656 | | +--rw type? identityref 657 | +--rw mp-bgp-evpn 658 | | +--rw vpn-id? string 659 | | +--rw type? identityref 660 | +--rw t-ldp-pwe 661 | | +--rw PE-EG-list* [service-ip-lo-addr vc-id] 662 | | +--rw service-ip-lo-addr inet:ip-address 663 | | +--rw vc-id string 664 | +--rw pwe-encapsulation-type 665 | | +--rw ethernet? boolean 666 | | +--rw vlan? boolean 667 | +--rw pwe-mtu 668 | | +--rw allow-mtu-mismatch? boolean 669 | +--rw control-word 670 +--rw load-balance-options 671 | +--rw fat-pw? boolean 672 | +--rw entropy-label? boolean 673 | +--rw vxlan-source-port? string 674 +--rw ports 675 +--rw port* [id] 676 +--rw id string 677 +--rw remote-carrier-name? string 678 +--rw groups 679 | +--rw fate-sharing-group-size? uint16 680 | +--rw group* [group-id] 681 | +--rw group-id string 682 +--rw bearer 683 | +--rw phy-interface 684 | | +--rw port-number? uint32 685 | | +--rw port-speed? uint32 686 | | +--rw auto-neg? string 687 | | +--rw phy-mtu? uint32 688 | | +--rw flow-control? string 689 | | +--rw encapsulation-type? enumeration 690 | | +--rw ethertype? string 691 | | +--rw lldp? boolean 692 | | +--rw oam-802.3AH-link {oam-3ah}? 693 | | | +--rw enable? boolean 694 | | +--rw uni-loop-prevention? boolean 695 | +--rw LAG-interface 696 | | +--rw LAG-interface* [LAG-interface-number] 697 | | +--rw LAG-interface-number uint32 698 | | +--rw LACP 699 | | +--rw LACP-state? identityref 700 | | +--rw LACP-mode? identityref 701 | | +--rw LACP-speed? identityref 702 | | +--rw mini-link? uint32 703 | | +--rw system-priority? uint16 704 | | +--rw Micro-BFD {Micro-BFD}? 705 | | | +--rw Micro-BFD-on-off? enumeration 706 | | | +--rw bfd-interval? uint32 707 | | | +--rw bfd-hold-timer? uint32 708 | | +--rw bfd {bfd}? 709 | | | +--rw bfd-enabled? boolean 710 | | | +--rw (holdtime)? 711 | | | +--:(profile) 712 | | | | +--rw profile-name? string 713 | | | +--:(fixed) 714 | | | +--rw fixed-value? uint32 715 | | +--rw Member-link-list 716 | | | +--rw member-link* [name] 717 | | | +--rw name string 718 | | | +--rw port-speed? uint32 719 | | | +--rw auto-neg? string 720 | | | +--rw mtu? uint32 721 | | | +--rw oam-802.3AH-link {oam-3ah}? 722 | | | +--rw enable? boolean 723 | | +--rw flow-control? string 724 | | +--rw encapsulation-type? enumeration 725 | | +--rw ethertype? string 726 | | +--rw lldp? boolean 727 | +--rw interface-description? string 728 | +--rw sub-if-id? uint32 729 +--rw ethernet-connection 730 | +--rw vlan 731 | +--rw svlan-id-ethernet-tag? string 732 +--rw evc-mtu? uint32 733 +--rw mac-addr-limit 734 | +--rw exceeding-option? uint32 735 +--rw multihoming 736 | +--rw multihoming* [ESI] 737 | +--rw ESI string 738 | +--rw (redundancy-mode)? 739 | +--:(single-active) 740 | | +--rw single-active? boolean 741 | +--:(all-active) 742 | +--rw all-active? boolean 743 +--rw L2CP-control 744 | +--rw stp-rstp-mstp? control-mode 745 | +--rw pause? control-mode 746 | +--rw lacp-lamp? control-mode 747 | +--rw link-oam? control-mode 748 | +--rw esmc? control-mode 749 | +--rw l2cp-802.1x? control-mode 750 | +--rw e-lmi? control-mode 751 | +--rw lldp? boolean 752 | +--rw ptp-peer-delay? control-mode 753 | +--rw garp-mrp? control-mode 754 | +--rw provider-bridge-group? yang:mac-address 755 | +--rw provider-bridge-mvrp? yang:mac-address 756 +--rw service 757 | +--rw svlan-id-ethernet-tag? string 758 | +--rw cvlan-id-to-evc-map? string 759 | +--rw service-level-mac-limit? string 760 | +--rw service-level 761 | +--rw cos-identifier? identityref 762 | +--rw color-identifier? identityref 763 | +--rw ingress-bw-profile-per-evc? string 764 | +--rw ingress-bw-profile-per-cos-id? string 765 | +--rw egress-bw-profile-per-evc? string 766 | +--rw egress-bw-profile-per-cos-id? string 767 | +--rw byte-offset? uint16 768 | +--rw policing? identityref 769 | +--rw performance-tier-option? identityref 770 | +--rw COS? uint32 771 +--rw B-U-M-strom-control 772 | +--rw BUM-overall-rate? uint32 773 | +--rw BUM-rate-per-type* [type] 774 | +--rw type identityref 775 | +--rw rate? uint32 776 +--rw mac-loop-prevention 777 | +--rw frequency? uint32 778 | +--rw protection-type? identityref 779 | +--rw number-retries? uint32 780 +--rw Ethernet-Service-OAM 781 | +--rw MD-name? string 782 | +--rw MD-level? uint8 783 | +--rw cfm-802.1-ag 784 | | +--rw n2-uni-c* [MAID] 785 | | | +--rw MAID string 786 | | | +--rw mep-id? uint32 787 | | | +--rw mep-level? uint32 788 | | | +--rw mep-up-down? enumeration 789 | | | +--rw remote-mep-id? uint32 790 | | | +--rw cos-for-cfm-pdus? uint32 791 | | | +--rw ccm-interval? uint32 792 | | | +--rw ccm-holdtime? uint32 793 | | | +--rw alarm-priority-defect? identityref 794 | | | +--rw ccm-p-bits-pri? ccm-priority-type 795 | | +--rw n2-uni-n* [MAID] 796 | | +--rw MAID string 797 | | +--rw mep-id? uint32 798 | | +--rw mep-level? uint32 799 | | +--rw mep-up-down? enumeration 800 | | +--rw remote-mep-id? uint32 801 | | +--rw cos-for-cfm-pdus? uint32 802 | | +--rw ccm-interval? uint32 803 | | +--rw ccm-holdtime? uint32 804 | | +--rw alarm-priority-defect? identityref 805 | | +--rw ccm-p-bits-pri? ccm-priority-type 806 | +--rw y-1731* [MAID] 807 | +--rw MAID string 808 | +--rw mep-id? uint32 809 | +--rw type? identityref 810 | +--rw remote-mep-id? uint32 811 | +--rw message-period? uint32 812 | +--rw measurement-interval? uint32 813 | +--rw cos? uint32 814 | +--rw loss-measurement? boolean 815 | +--rw synthethic-loss-measurement? boolean 816 | +--rw delay-measurement 817 | | +--rw enable-dm? boolean 818 | | +--rw two-way? boolean 819 | +--rw frame-size? uint32 820 | +--rw session-type? enumeration 821 +--rw security 823 Figure 6 825 5.1. Overview of Main Components of the Model 827 The L2SM model is structured in a way that allows the provider to 828 list multiple circuits of various service types for the same 829 subscriber. 831 5.1.1. Customer Information 833 The "customer-info" container contains essential information to 834 identify the subscriber. 836 "customer-account-number" is an internal alphanumerical number 837 assigned by the service provider to identify the subscriber. It MUST 838 be unique within the service provider?s OSS/BSS system. The actual 839 format depends on the system tool the provider uses. "customer-name" 840 is in more readable form. 842 Subscriber operation center and main contact number are also listed 843 here for reference purpose. 845 5.1.2. VPN Service Overview 847 The "svc-type" container contains two optional leaves: one for EVC 848 (Ethernet Virtual Connection) and the other one for OVC (Operator 849 Virtual Connection). These two parameters are not mutually 850 exclusive. Depending on the service-type, a Layer 2 VPN service may 851 be identified by EVC-ID, OVC-ID, or both. 853 E-Line and E-LAN provider shall have EVC-ID assigned to the UNI-to- 854 UNI circuit. If the service has remote UNIs in off-net partner's 855 network, there will be one OVC-ID for the on-net segment between 856 local UNI to the E-NNI interconnect, and one OVC-ID for each off-net 857 segment from E-NNI to the remote UNI. E-Access, on the other hand, 858 is OVC-based service. The E-Access service provider will assign OVC- 859 ID for the circuit between UNI to E-NNI. 861 The "svc-type" container can be augmented in the future to support 862 other new technologies. Note that the "svc-id" should be 863 corresponding to the "svc-type". 865 5.1.2.1. Service Type 867 The "svc-type" container contains two cases, one for EVC (Ethernet 868 Virtual Connection), the other for OVC (Operator Virtual Connection). 869 It can be used to indicate the type of service pipe type. The model 870 user also can augment the "svc-type" container with other cases to 871 support future technologies. Notes that the "svc-id" should be 872 corresponding to the "svc-type". 874 5.1.2.1.1. EVC 876 The "evc"case contains an "evc-id" leaf with boolean type. The "evc- 877 id" leaf will be marked TRUE for E-Line and E-LAN service types. And 878 the "svc-id" will be associated with the "evc-id". Only one "evc-id" 879 is allowed for each "svc-id". 881 The EVC ID is intended to be a structured string. Each service 882 provider can decide the nomenclature in its network. For example, 883 many carriers in North American have implemented the COMMON LANGUAGE? 884 Special Service Circuit Codes (CLCI S/S Codes) - Serial Number 885 Format, which is defined in defined in ANSI ATIS-0300097. 887 5.1.2.1.2. OVC 889 The "ovc" case contains two boolean subcases: "on-net-ovc" and "off- 890 net-ovc". 892 For E-Access or services with off-net UNIs, the "on-net-ovc" leaf 893 MUST be marked TRUE. And the "on-net-ovc-id" will be specified. 895 In case of E-Access, the "svc-id" will be associated with the "on- 896 net-ovc-id". Only one "on-net-ovc-id" is allowed for each "svc-id". 898 If the service is E-Line or E-LAN with remote UNIs, there will be 899 one, and only one, "on-net-ovc-id" and a list of "off-net-ovc-id"s 900 for the remote UNIs. However, the "svc-id" is still associated with 901 the "evc-id". Only one "evc-id" is allowed for each "svc-id". New 902 ovc type could be added by augmentation. 904 5.1.2.2. ethernet-svc-type 906 The "ethernet-svc-type" group contains all supported Ethernet service 907 types. One, and only one, "ethernet-svc-type" must be selected for 908 each "svc-id". 910 The current supported Ethernet service types are listed in 911 Section 3.2. New service types can be added in the future. 913 5.1.2.3. Metro Network Partition 915 Some service providers may divide their network into multiple 916 administrative domains. And a Layer 2 VPN service may span across 917 more than one metro network of the same service provider. The 918 optional "metro-network-id" container is intended be used by these 919 multi-domain providers to differentiate intra-market versus inter- 920 market services. 922 When the "inter-mkt-service" leaf is marked TRUE, multiple associated 923 "metro-mkt-id"s will be listed. Otherwise, the service is intra- 924 domain and only one "metro-mkt-id" is allowed. 926 5.1.2.4. vpn-signaling-option 928 The "signaling-option" container captures service-wide attributes of 929 the L2VPN instance. 931 Although topology discovery or network device configurations is 932 purposely out-scoped from the L2SM model, certain VPN parameters are 933 listed here nevertheless. The information here can then be passed to 934 other elements in the whole automation eco-system, such as the 935 configuration engine, which will handle the actual service 936 provisioning function. 938 The "signaling-option" list uses "name" and "type" combination as the 939 key. The "name" leaf is a free-form string of the VPN instance name. 940 The "type" leaf is for the signaling protocol: BGP-L2VPN, BGP-EVPN, 941 or T-LDP. 943 5.1.2.4.1. BGP L2VPN 945 [RFC4761] and [RFC6624] describe the mechanism to auto-discover L2VPN 946 VPLS/VPWS end points (CE-ID or VE-ID) and signal the label base and 947 offset at the same time to allow remote PE to derive the VPN label to 948 be used when sending packets to the advertising router. 950 Due to the auto-discovery natural, PEs that have at least one 951 attachment circuit associated with a particular VPN service do not 952 need to be specified explicitly. 954 In the L2SM model, only the target community (or communities) will be 955 listed at the service level. 957 The "type" leaf under "mp-bgp-l2vpn" is an identityref to specify 958 "vpws" or "vpls" sub-types. 960 5.1.2.4.2. BGP EVPN 962 Defined in [RFC7432], EVPN is a new promising L2VPN technology based 963 upon BGP MAC routing. It's considered the next generation L2VPN 964 solution that provides similar functionality of BGP VPWS/VPLS with 965 improvement around redundancy, multicast optimization, provisioning 966 and simplicity. 968 Due to the auto-discovery natural, PEs that have at least one 969 attachment circuit associated with a particular VPN service do not 970 need to be specified explicitly. 972 In the L2SM model, only the target community (or communities) will be 973 listed at the service level. 975 The "type" leaf under "mp-bgp-evpn" is an identityref to specify 976 "vpws" or "vpls" sub-types. 978 5.1.2.4.3. LDP Pseudowires 980 [RFC4762] specified the method of using targeted LDP sessions between 981 PEs to exchange VC label information. This requires a manually 982 define a full mesh of targeted LDP sessions between all PEs. 984 As multiple attachment circuits may terminate on a single PE, this 985 PE-to-PE mesh is not a per site attribute. All PEs related to the 986 L2VPN service will be listed in the "t-ldp-pwe" with associated "vc- 987 id". 989 5.1.2.4.4. PWE Encapsulation Type 991 Based on [RFC4448], there are two types of Ethernet services: "Port- 992 to-Port Ethernet PW emulation" and "Vlan-to-Vlan Ethernet PW 993 emulation", commonly referred to as Type 5 and Type 4 respectively. 994 This concept applies to both BGP L2VPN VPWS/VPLS and T-LDP signaled 995 PWE implementations. 997 The "pwe-encapsulation-type" container contains two Boolean type 998 leaves: "ethernet" and "ethernet-vlan", only one should be marked 999 TRUE if "signaling-option" is "mp-bgp-l2vpn" or "t-ldp-pwe". 1001 5.1.2.4.5. PWE MTU 1003 During the signaling process of BGP-L2VPN or T-LDP pseudowire, the 1004 pwe-mtu value is exchanged and must match on both ends. By default, 1005 the pwe-mtu is derived from physical interface MTU of the attachment 1006 circuit minus the EoMPLS transport header. In some cases, however, 1007 the physical interface on both ends of the circuits may not have 1008 identical MTU settings. For example, due to 802.1ad q-in-q 1009 operation, I-NNI interface will need extra four bytes to accommodate 1010 the S-tag. The inter-carrier E-NNI link may also have a different 1011 MTU size then the internal network interfaces. 1013 [RFC4448] requires same MTU size on physical interface on both end of 1014 the pseudowire. In actual implementations, many router vendors have 1015 provided the knob to explicitly specify the pwe-mtu, which can then 1016 be decoupled from the physical interface MTU. 1018 When there's a mismatch between the physical interface MTU and 1019 configured pwe-mtu, "allow-mtu-mismatch" knob is also required in 1020 many cases. 1022 The optional "pwe-mtu" container is for this purpose. 1024 5.1.2.4.6. Control Word 1026 A control word is an optional 4-byte field located between the MPLS 1027 label stack and the Layer 2 payload in the pseudowire packet. It 1028 plays a vital role in Any Transport over MPLS (AToM). The 32-bit 1029 field carries generic and Layer 2 payload-specific information, 1030 including a C-bit which indicates whether the control word will 1031 present in the Ethernet over MPLS (EoMPLS) packets. If the C-bit is 1032 set to 1, the advertising PE expects the control word to be present 1033 in every pseudowire packet on the pseudowire that is being signaled. 1034 If the C-bit is set to 0, no control word is expected to be present. 1036 Whether to include control word in the pseudowire packets MUST match 1037 on PEs at both ends of the pseudowire and it's non-negotiable during 1038 the signaling process. 1040 Control-word applies to both BGP L2VPN VPWS/VPLS and T-LDP signaled 1041 PWE implementations. It is a routing-instance level configuration in 1042 many cases. 1044 The optional "control-word" leaf is a Boolean field in the L2SM model 1045 for the provider to explicitly specify whether control-word will be 1046 signaled for the service instance. 1048 5.1.2.5. Load Balance Option 1050 As the subscribers start to deploy more 10G or 100G Ethernet 1051 equipment in their network, the demand for high bandwidth Ethernet 1052 services increases. Along with the great revenue opportunities, 1053 these high bandwidth service requests also pose challenges on 1054 capacity planning and service delivery in the provider's network. 1055 Especially when the contractual bandwidth is at, or close to, the 1056 speed of physical link of the service provider's core network. 1057 Because of the encapsulation overhead, the provider can not deliver 1058 the throughput in the service level agreement over a single link. 1059 Although there may be bundled Nx10G or Nx100G aggregation links 1060 between core network elements, or Equal Cost Multiple Paths (ECMP) in 1061 the network, an EoMPLS PWE or VxLAN circuit is considered a single 1062 flow to a router or switch which uses the five tuples in the hashing 1063 algorithm. 1065 Without burdening the core routers with additional processing of deep 1066 inspection into the payload, the service provider now have the option 1067 of inserting flow or entropy label into the EoMPLS frames, or using 1068 different source UDP ports in case of VxLAN/EVPN, at ingress PE to 1069 facility load-balancing on the subsequent nodes along the path. The 1070 ingress PE is in a unique position to see the actual unencapsulated 1071 service frames and identify data flows based on the original Ethernet 1072 and IP header. 1074 On the other hand, not all Layer 2 Ethernet VPNs is suited for load- 1075 balancing across diverse ECMP paths. For example, a Layer 2 Ethernet 1076 service transported over a single RSVP signaled LSP will not take 1077 multiple ECMP paths. Or if the subscriber is concerned about 1078 latency/jitter then diverse path load-balance can be undesirable. 1080 The optional "load-balance-option" container is intended to capture 1081 the load-balance agreement between the subscriber and provider. If 1082 the "load-balance" Boolean leaf is marked TRUE, then one of the 1083 following load-balance methods can be selected: "fat-pw", "entropy- 1084 label", or "vxland-source-udp-port". 1086 5.1.2.6. SVLAN ID Ethernet Tag 1088 Service providers have the option of inserting an outer VLAN tag (the 1089 S-tag) into the service frames from the subscriber to improve service 1090 scalability and customer VLAN transparency. 1092 Ideally, all external interfaces (UNI and E-NNI) associated with a 1093 given service will have the same S-tag assigned. However, this may 1094 not always be the case. Traffic with all attachments using different 1095 S-tags will need to be "normalized" to a single service S-tag. (One 1096 example of this is a multipoint service involves multiple off-net 1097 OVCs terminating on the same E-NNI interface. Each of these off-net 1098 OVCs will have a distinct S-tag, which can be different from the 1099 S-tag used in the on-net part of the service.) 1101 The purpose of the optional "svlan-id-ethernet-tag" leaf is to 1102 identify the service-wide "normalized S-tag". 1104 5.1.2.7. CVLAN ID To EVC MAP 1106 When more than one services are multiplexed on the same interface, 1107 ingress service frames are conditionally transmitted through one of 1108 the EVC/OVCs based upon pre-arranged customer VLAN to EVC mapping. 1109 Multiple customer VLANs can be bundled across the same EVC. 1111 "cvlan-id-to-evc-map", when applicable, contains the list of customer 1112 vlans to the service mapping in a free-form format. In most cases, 1113 this will be the VLAN access-list for the inner 802.1q tags (the 1114 C-tag). 1116 5.1.2.8. Service Level MAC Limit 1118 When multiple services are provided on the same network element, MAC 1119 address table, and RIB space for MAC-routes in case of EVPN, are 1120 shared common resource. Service providers may impose a maximum 1121 number of MAC learned from the subscriber for a single service 1122 instance, and specify the action when the upper limit is violated: 1123 drop the packet, flood the packet, or simply send a warning log 1124 message. 1126 For point-to-point services, if MAC learning is disabled then MAC 1127 limit is not necessary in this kind of implementation. 1129 The optional "service-level-mac-limit" container contains the 1130 subscriber MAC address limit and exceeding action information. 1132 5.1.2.9. Service Protection 1134 Sometimes the subscriber may desire end-to-end protection at the 1135 service level for applications with high availability requirements. 1136 There are two protection schemes to offer redundant services: 1138 o 1+1 protection: In this scheme, the primary EVC or OVC will be 1139 protected by a backup EVC or OVC, typically meet certain 1140 diversified path/fiber/site/node criteria. Both primary and 1141 protection circuits are provisioning to be in forwarding state. 1142 Subscriber may choose to send the same service frames across both 1143 circuits simultaneously. 1145 o 1:1 protection: In this scheme, a backup circuit can be 1146 provisioning to the primary circuits. Depending on the 1147 implementation agreement, the protection circuits may either 1148 always be in forwarding state, or only become active when 1149 detecting a faulty state or the primary circuit. 1151 The optional "service-protection" container hereby is to capture the 1152 desired service protection agreement between subscriber and provider. 1154 An "peer-evc-id" should be specified when the "protection-model" has 1155 value. 1157 5.1.3. site 1159 The "site" container is intended for the provider to store 1160 information of detailed implementation arrangement with either the 1161 subscriber or peer operators at each inter-connect location. 1163 We are restricting the L2SM to exterior interfaces only. All 1164 internal interfaces or the underlying topology is outside the scope 1165 of L2SM. 1167 There are possibly two types of external facing connections 1168 associated with an Ethernet VPN service: 1170 o UNI site: where a customer edge device connects to one or more VPN 1171 services. 1173 o E-NNI site: where two Ethernet service providers inter-connect 1174 with each other. 1176 Most of the attributes of a site are common to the two typs of site 1177 and so are presented just once. Divergences, that is, attributes 1178 that are specific to the type of site, are captured in type-dependent 1179 containers. 1181 For each site, there are sub-containers to maintain physical link 1182 attributes, service frame and Layer 2 control protocol frame 1183 disposition, Ethernet service OAM attributes, and service bandwidth 1184 profile and priority level agreement. 1186 5.1.3.1. Generic Site Objects 1188 Typically, the following characteristics of a site interface handoff 1189 need to be documented as part of the service design: 1191 Unique identifier (site-id) : An arbitrary string to uniquely 1192 identify the site within the overall network infrastructure. The 1193 format of site-id is determined by the local administration of the 1194 VPN service. 1196 Site Type (site-type) : TBD. 1198 Device (device) : TBD. 1200 Management (management) : Defines the model of management of the 1201 site, for example: type, management-transport, address. 1203 Location (location) : The site location information to allow easy 1204 retrieval on nearest available resources. 1206 Site diversity (site-diversity) : Presents some parameters to 1207 support site diversity. 1209 Site security (security) : TBD. 1211 Site signaling (signaling-options) : TBD. 1213 Load balancing (load-balance-options) : TBD. 1215 Ports (ports) : Defines the list of ports to the sites and their 1216 properties. 1218 5.1.3.1.1. Site ID 1220 The "site-id" leaf contains an arbitrary string to uniquely identify 1221 the site within the overall network infrastructure. The format of 1222 the site-id is determined by the local administration of the VPN 1223 service. 1225 5.1.3.1.2. Site Management 1227 The "management" sub-container is intended for site management 1228 options, depending on the device ownership and security access 1229 control. The followings are three common management models: 1231 CE Provider Managed : The provider has the sole ownership of the CE 1232 device. Only the provider has access to the CE. The 1233 responsibility boundary between SP and customer is between CE and 1234 customer network. This is the most common use case. 1236 CE Customer Managed : The customer has the sole ownership of the CE 1237 device. Only the customer has access to the CE. In this model, 1238 the responsibility boundary between SP and customer is between PE 1239 and CE. 1241 CE Co-managed : The provider has ownership of the CE device and 1242 responsible for managing the CE. However, the provider grant the 1243 customer accessing the CE for some configuration/monitoring 1244 purpose. In this co-managed mode the responsibility boundary is 1245 the same as the provider-managed model. 1247 The selected management mode is specified under the "type" leaf. The 1248 "address" leaf stores CE device management IP information. And " 1249 management-transport" leaf is used to identify the transport protocol 1250 for management traffic, IPv4 or IPv6. Additional security options 1251 MAY be derived based on the particular management model selected. 1253 5.1.3.1.3. Site Location 1255 The information in the "location" sub-container under a "site" allows 1256 easy retrieval on nearest available facility for access topology 1257 planning. It may also be used by other network orchestration 1258 component to decide the targeted upstream PE. Location is express in 1259 terms of postal information. 1261 5.1.3.1.4. Site Diversity 1263 Some subscriber may request upstream PE diversity between two or more 1264 sites. These sites will share the same diversity group ID under the 1265 optional "site-diversity" sub-container. 1267 5.1.3.1.5. Site Security 1269 This sub-container is is a placeholder for site-security options. It 1270 presents parameters for ingress service stream admission control and 1271 encryption profile information. 1273 5.1.3.1.6. Site Signaling Option 1275 See Section 5.1.2.4. 1277 5.1.3.1.7. Site Load Balance Options 1279 TBD. 1281 5.1.3.1.8. Ports 1283 The L2SM includes a set of essential physical interface properties 1284 and Ethernet layer characteristics in the "port" sub-container. Some 1285 of these are critical implementation arrangements that require 1286 consent from both subscriber and provider. 1288 5.1.3.1.8.1. ID 1290 "id" is a free-form string to identify a given interface. Service 1291 provider can decide on the actual nomenclature used in the management 1292 systems. 1294 5.1.3.1.8.2. Remote Carrier Name 1296 TBD. 1298 5.1.3.1.8.3. Fate Sharing Group 1300 TBD. 1302 5.1.3.1.8.4. Bearer 1304 Under port, there is a bearer container that presents two sets of 1305 link attributes: physical or optional LAG interface attributes. 1306 These parameters are essential for the connection between subscriber 1307 and provider edge devices to establish properly. 1309 For each physical interface (phy-interface), there are basic 1310 configuration parameters like port number and speed, interface face 1311 MTU, auto-negotiation and flow-control settings, etc. 1312 "encapsulation-type" is for user to select between Ethernet 1313 encapsulation (port-based) or Ethernet VLAN encapsulation (VLAN- 1314 based). All allowed Ethertypes of ingress service frames can be 1315 listed under "ethertype". In addition, the subscriber and provider 1316 may decide to enable advanced features, such as LLDP, 802.3AH link 1317 OAM, MAC loop detection/prevention at a UNI, based on mutual 1318 agreement. 1320 Sometimes the subscriber may require multiple physical links bundled 1321 together to form single logical point-to-point LAG connection to the 1322 service provider. Typically, LACP (Link Aggregation Control 1323 Protocol) is used to dynamically manage adding or deleting member 1324 links of the aggregate group. In general, LAG allows for increased 1325 service bandwidth beyond the speed of a single physical link while 1326 providing graceful degradation as failure occurs, thus increased 1327 availability. 1329 In the L2SM, there is a set of attributes under "LAG-interface" 1330 related to link aggregation functionality. The subscriber and 1331 provider first need to decide on whether LACP PDU will be exchanged 1332 between the edge device by specifying the "LACP-state" to "On" or 1333 "Off". If LACP is to be enabled, then both parties need to further 1334 specify whether it will be running in active versus passive mode, 1335 plus the time interval and priority level of the LACP PDU. 1336 Subscriber and provider can also determine the minimum aggregate 1337 bandwidth for a LAG group to be considered valid path by specifying 1338 the optional "mini-link" attribute. To enable fast detection of 1339 faulty links, Micro-BFD runs independent UDP sessions to monitor the 1340 status of each member link. Subscriber and provider should consent 1341 to the BFD hello interval and hold time. 1343 Each member link will be listed under the LAG interface with basic 1344 physical link properties. Certain attributes like flow-control, 1345 encapsulation type, allowed ingress Ethertype and LLDP settings are 1346 at the LAG level. 1348 If the Ethernet service is enabled on a logical unit on the 1349 connection at the interface, the "sub-if-id" should be specified. 1351 5.1.3.1.8.5. Ethernet Connection 1353 The "Ethernet-connection" container presents site specific (S-tag, 1354 C-tag) management options. The overall S-tag for the Ethernet 1355 circuit and C-tag to EVC mapping, if applicable, has been placed in 1356 the service container. The S-tag under "port" should match the S-tag 1357 in service container in most cases. However, vlan translation is 1358 required for the S-tag in certain deployment at the external facing 1359 interface or upstream PEs to "normalize" the outer VLAN tag to the 1360 service S-tag into the network and translate back to the site' S-tag 1361 in the opposite direction. One example of this is, with Layer 2 1362 aggregation switch alone the path, the S-tag for the EVC has been 1363 previously assigned to another service thus can not be used by this 1364 attachment circuit. Another use case is when multiple E-access OVCs 1365 from the same E-NNI interfaces are attached to the same E-LAN 1366 service. 1368 The "svlan-id-ethernet-tag" in the "Ethernet-connection" container is 1369 either the S-tag inserted at a UNI or the outer tag of ingress 1370 packets at an E-NNI. These parameters are included in the L2SM to 1371 facilitate other management system to generate proper configuration 1372 for the network elements. 1374 "Ethernet-connection" container also contains optional site-specific 1375 C-tag to EVC mapping. 1377 5.1.3.1.8.6. EVC MTU 1379 The maximum MTU of subscriber service frames can be derived from the 1380 physical interface MTU by default, or specified under the "evc-mtu" 1381 leaf if it is different than the default number. 1383 5.1.3.1.8.7. MAC Address Limit 1385 The service provider may choose to impose a per attachment circuit 1386 "mac-addr-limit" in addition to the service-lever MAC limit, and 1387 specify the exceeding options accordingly. 1389 5.1.3.1.8.8. Multihoming 1391 EVPN supports PE geo-redundancy in the access domain. The connection 1392 between a multi-homed CE to PE is identified with a uniquely assigned 1393 ID referred as an Ethernet Segment Identifier (ESI). Because a 1394 learned MAC address is propagated via BGP, it allows for multiple 1395 active paths in forwarding state and load-balancing options. 1397 The "multihoming" container contains ESI and redundancy mode 1398 attribute for EVPN multi-homing site. 1400 5.1.3.1.8.9. L2CP-Control 1402 To facilitate interoperability between different MSOs, MEF has 1403 provided normative guidance on Layer 2 control protocol (L2CP) 1404 processing requirements for each service type. Subscriber and 1405 provider should make pre-arrangement on whether to allow interaction 1406 between the edge device or keep each others control plane separate on 1407 a per protocol base. 1409 The destination MAC addresses of these L2CP PDUs fall within two 1410 reserved blocks specified by IEEE 802.1 Working Group. Packet with 1411 destination MAC in these multicast ranges has special forwarding 1412 rules. 1414 o Bridge Block of Protocols: 01-80-C2-00-00-00 through 1415 01-80-C2-00-00-0F 1417 o MRP Block of Protocols: 01-80-C2-00-00-20 through 1418 01-80-C2-00-00-2F 1420 Layer 2 protocol tunneling allows service providers to pass 1421 subscriber Layer 2 control PDUs across the network without being 1422 interpreted and processed by intermediate network devices. These 1423 L2CP PDUs are transparently encapsulated across the MPLS-enabled core 1424 network in Q-in-Q fashion. 1426 The "L2CP-control" container contains the list of commonly used L2CP 1427 protocols. Service provider can specify DISCARD, PEER or TUNNEL 1428 action for each individual protocol. 1430 In addition, "provider-bridge-group" and "provider-bridge-mvrp" 1431 addresses are also listed in the L2CP container. 1433 5.1.3.1.8.10. Service Profile 1435 In MEF 23.2 ([MEF-23-2]) two types of model are defined as the 1436 following: 1438 Class-of-Service Identifier based on EVC or OVC EP (End Point): In 1439 this model, regardless of customer marking, all in-profile frames 1440 will be marked with service level in contractual agreement. 1441 Customer CoS markings are preserved throughout the provider 1442 network. The bandwidth profile consists of one set of CIR/CBS and 1443 EIR/EBS values. 1445 Class-of-Service Identifier based on Priority Code Point: Using this 1446 model, multiple classes of services can be associated with a 1447 single customer EVC, identified by dot1p bits in the C-tag. Each 1448 service level has its own individual bandwidth profile. Out-of- 1449 profile packets will be discarded. Customer CoS markings are 1450 preserved. 1452 Class-of-Service Identifier based on DSCP: Using this model, 1453 multiple classes of services can be associated with a single 1454 customer EVC, identified by DSCP bits in the IP header. Each 1455 service level has its own individual bandwidth profile. Out-of- 1456 profile packets will be discarded. Customer CoS markings are 1457 preserved. 1459 Similarly, Color-identifier can be assigned based on EVC or OVC EP, 1460 dot1p value in C-tag, or DSCP in IP header. Ingress service frames 1461 are metered against the bandwidth profile based on the cos- 1462 identifier. A "color" will be assigned to a service frame to 1463 identify its bandwidth profile conformance. A service frame is 1464 "green" if it is conformant with "committed" rate of the bandwidth 1465 profile. A Service Frame is "yellow" if it is exceeding the 1466 "committed" rate but conformant with the "excess" rate of the 1467 bandwidth profile. Finally, a service frame is "red" if it is 1468 conformant with neither the "committed" nor "excess" rates of the 1469 bandwidth profile. 1471 Ingress/egress-bandwidth-profile-per-evc presents the ingress/egress 1472 bandwidth profile per EVC, providing rate enforcement for all ingress 1473 service frames at the interface that are associated with a particular 1474 EVC. 1476 Alternately, ingress/egress-bandwidth-profile-per-cos-id presents the 1477 ingress/egress bandwidth profile per CoS, providing rate enforcement 1478 for all service frames for a given class of service. The class of 1479 service is identified via a CoS identifier. So this bandwidth 1480 profile applies to service frames over an EVC with a particular CoS 1481 value. Multiple ingress/egress-bandwidth-profile-per-cos-id can be 1482 associated with the same EVC. 1484 The optional "byte-offset" indicates how many bytes in the service 1485 frame header are excluded from rate enforcement. 1487 5.1.3.1.8.11. BUM Strom Control 1489 For point-to-point E-LINE services, the provider only needs to 1490 deliver a single copy of each service frame to the remote PE, 1491 regardless whether the destination MAC address of the incoming frame 1492 is unicast, multicast or broadcast. Therefore, all in-profile 1493 service frames should be delivered unconditionally. 1495 B-U-M (Broadcast-UnknownUnicast-Multicast) frame forwarding in 1496 multipoint-to-multipoint services, on the other hand, involves both 1497 local flooding to other attachment circuits on the same PE and remote 1498 replication to all other PEs, thus consumes additional resources and 1499 core bandwidth. Special B-U-M frame disposition rules can be 1500 implemented at external facing interfaces (UNI or E-NNI) to rate- 1501 limit the B-U-M frames, in term of number of packets per second or 1502 bits per second. 1504 The threshold can apply to all B-U-M traffic, or one for each 1505 category. 1507 5.1.3.1.8.12. MAC Loop Protection 1509 MAC address flapping between different physical ports typically 1510 indicates a bridge loop condition in the subscriber network. 1511 Misleading entries in the MAC cache table can cause service frames to 1512 circulate around the network indefinitely and saturate the links 1513 throughout the provider's network, affecting other services in the 1514 same network. In case of EVPN, it also introduces massive BGP 1515 updates and control plane instability. 1517 Service provider may opt to implement switching loop prevention 1518 mechanism at the external facing interfaces for multipoint-to- 1519 multipoint services by imposing a MAC address move threshold. 1521 The MAC move rate and prevention-type options are listed in the "mac- 1522 loop-prevention" container. 1524 5.1.3.1.8.13. Ethernet Service OAM 1526 The advent of Ethernet as wide-area network technology brings 1527 additional requirements of end-to-end service monitoring and fault 1528 management in the carrier network, particularly in the area of 1529 service availability and Mean Time To Repair (MTTR). Ethernet 1530 Service OAM in the L2SM refers to the combined protocol suites of 1531 IEEE 802.1ag ([IEEE-802-1ag]) and ITU-T Y.1731 ([ITU-T-Y-1731]). 1533 Generally speaking, Ethernet Service OAM enables service provider to 1534 perform service continuity check, fault-isolation, and packet delay/ 1535 jitter measurement at per customer per EVC granularity. The 1536 information collected from Ethernet Service OAM data sets is 1537 complementary to other higher layer IP/MPLS OSS tools to ensure the 1538 required service level agreements (SLAs) can be meet. 1540 The 802.1ag Connectivity Fault Management (CFM) functional model is 1541 structured with hierarchical maintenance domains (MD), each assigned 1542 a unique maintenance level. Higher level MD can be nested over lower 1543 level MD. However, the MD can not intersect. The scope of each MD 1544 can be solely within a subscriber's network, solely within the 1545 provider's network, interact between the subscriber-to-provider or 1546 provider-to-provider edge equipment, or tunnel over another 1547 provider's network. 1549 Depending on the use case scenario, one or more maintenance end point 1550 (MEP) can be placed on the external facing interface, sending CFM 1551 PDUs towards the core network (UP MEP) or downstream link (DOWN MEP). 1553 The "cfm-802.1-ag" sub-container under "port" currently presents two 1554 types of CFM maintenance association (MA): UP MEP for UNI-N to UNI-N 1555 MA and DOWN MEP for UNI-N to UNI-C MA. For each MA, user can define 1556 the maintenance domain ID (MAID), MEP level, MEP direction, remote 1557 MEP ID, CoS level of the CFM PDUs, Continuity Check Message (CCM) 1558 interval and hold time, alarm priority defect, CCM priority-type, 1559 etc. 1561 ITU-T Y.1731 Performance Monitoring (PM) provides essential network 1562 telemetry information that includes the measurement of Ethernet 1563 service frame delay, frame delay variation, frame loss, and frame 1564 throughput. The delay/jitter measurement can be either one-way or 1565 two-way. Typically, a Y.1731 PM probe sends a small amount of 1566 synthetic frames along with service frames to measure the SLA 1567 parameters. 1569 The "y-1731" sub-container under "port" contains a set of parameters 1570 for use to define the PM probe information, including MAID, local and 1571 remote MEP-ID, PM PDU type, message period and measurement interval, 1572 CoS level of the PM PDUs, loss measurement by synthetic or service 1573 frame options, one-way or two-way delay measurement, PM frame size, 1574 and session type. 1576 6. Interaction with Other YANG Modules 1578 As expressed in Section 4, this service module is not intended to 1579 configure the network element, but is instantiated in a management 1580 system. 1582 The management system might follow modular design and comprise at 1583 least two different components: 1585 a. The component instantiating the service model (let' call it the 1586 service component) 1588 b. The component responsible for network element configuration 1589 (let's call it the configuration component) 1591 In some cases when the split is needed between the behavior and 1592 functions that a customer requests and the technology that the 1593 network operator has available to deliver the service 1594 [I-D.wu-opsawg-service-model-explained]. A new component can be 1595 separated out of the service component (let's call it the control 1596 component). This component is responsible for network-centric 1597 operation and is aware of many features such as topology, technology, 1598 and operator policy. As an optional component, it can use service 1599 model as input and is not required if the control component delegates 1600 its control operations to the configuration component. 1602 In Section 7 we provide some example of translation of service 1603 provisioning request to router configuration lines as an 1604 illustration. In the NETCONF/YANG ecosystem, it is expected that 1605 NETCONF and YANG will be used between the configuration component and 1606 network elements to configure the requested service on those 1607 elements. 1609 In this framework, it is expected that YANG models will be used for 1610 configuring service components on network elements. There will be a 1611 strong relationship between the abstracted view provided by this 1612 service model and the detailed configuration view that will be 1613 provided by specific configuration models for network elements such 1614 as those defined in [I-D.ietf-bess-l2vpn-yang] and 1615 [I-D.ietf-bess-evpn-yang]. Service components needing configuration 1616 on network elements in support of the service model defined in this 1617 document include: 1619 o VRF definition including VPN policy expression. 1621 o Physical interface. 1623 o Ethernet layer (VLAN ID). 1625 o QoS : classification, profiles, etc. 1627 o Routing protocols : support of configuration of all protocols 1628 listed in the document, as well as routing policies associated 1629 with these protocols. 1631 o Multicast Support. 1633 o Ethernet Service OAM Support. 1635 7. Service Model Usage Example 1637 *** TBD *** 1639 8. YANG Module 1641 1642 file "ietf-l2vpn-svc@2016-09-29.yang" 1643 module ietf-l2vpn-svc { 1644 namespace "urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc"; 1645 prefix "l2svc"; 1646 import ietf-inet-types { 1647 prefix inet; 1648 } 1649 import ietf-yang-types { 1650 prefix yang; 1651 } 1652 organization 1653 "IETF L2SM Working Group."; 1654 contact 1655 "WG List: l2sm@ietf.org 1656 Editor: Bin_Wen@comcast.com"; 1657 description 1658 "The YANG module defines a generic service configuration 1659 model for Layer 2 VPN services common across all of the 1660 vendor implementations."; 1661 revision 2016-10-15 { 1662 description 1663 "Initial revision."; 1664 reference 1665 "draft-wen-l2sm-l2vpn-service-model-01.txt 1666 A YANG Data Model for L2VPN Service Delivery."; 1667 } 1669 /* Features */ 1671 feature oam-3ah { 1672 description 1673 "Enables support of OAM 802.3ah"; 1674 } 1676 feature Micro-BFD { 1677 description 1678 "Enables support of Micro-BFD"; 1679 } 1681 feature bfd { 1682 description 1683 "Enables support of BFD"; 1684 } 1686 feature signaling-option { 1687 description 1688 "Enable support of signaling option"; 1689 } 1691 feature site-diversity { 1692 description 1693 "Enables support of site diversity constraints"; 1694 } 1696 feature encryption { 1697 description 1698 "Enables support of encryption"; 1699 } 1701 /* Typedefs */ 1703 typedef ccm-priority-type { 1704 type uint8 { 1705 range "0..7"; 1706 } 1707 description 1708 "A 3 bit priority value to be used in the VLAN tag, if present 1709 in the transmitted frame."; 1710 } 1711 typedef control-mode { 1712 type enumeration { 1713 enum peer { 1714 description 1715 "Peer mode"; 1716 } 1717 enum tunnel { 1718 description 1719 "Tunnel mode"; 1721 } 1722 enum discard { 1723 description 1724 "Discard mode"; 1725 } 1726 } 1727 description 1728 "Defining a type of the control mode"; 1729 } 1731 /* Identities */ 1733 identity site-type { 1734 description 1735 "Identity of site type."; 1736 } 1738 identity uni { 1739 base site-type; 1740 description 1741 "Identity of User Network Interface "; 1742 } 1744 identity enni { 1745 base site-type; 1746 description 1747 "Identity of External Network to Network Interface"; 1748 } 1750 identity color-id { 1751 description 1752 "Identity of color id"; 1753 } 1755 identity color-id-evc { 1756 base color-id; 1757 description 1758 "Identity of color id base on EVC"; 1759 } 1761 identity color-id-evc-cvlan { 1762 base color-id; 1763 description 1764 "Identity of color id base on EVC and CVLAN "; 1765 } 1767 identity cos-id { 1768 description 1769 "Identity of class of service id"; 1770 } 1772 identity cos-id-evc { 1773 base cos-id; 1774 description 1775 "Identity of cos id based on EVC"; 1776 } 1778 identity cos-id-evc-pcp { 1779 base cos-id; 1780 description 1781 "Identity of cos id based on EVC and PCP"; 1782 } 1784 identity cos-id-evc-dscp { 1785 base cos-id; 1786 description 1787 "Identity of cos id based on EVC and DSCP"; 1788 } 1790 identity cos-id-ovc-ep { 1791 base cos-id; 1792 description 1793 "Identity of cos id based on OVC EP"; 1794 } 1796 identity performance-tier-option { 1797 description 1798 "Identity of performance tier option."; 1799 } 1801 identity metro { 1802 base performance-tier-option; 1803 description 1804 "Identity of metro"; 1805 } 1807 identity regional { 1808 base performance-tier-option; 1809 description 1810 "Identity of regional"; 1811 } 1813 identity continental { 1814 base performance-tier-option; 1815 description 1816 "Identity of continental"; 1818 } 1820 identity global { 1821 base performance-tier-option; 1822 description 1823 "Identity of global"; 1824 } 1826 identity policing { 1827 description 1828 "Identity of policing type"; 1829 } 1831 identity one-rate-two-color { 1832 base policing; 1833 description 1834 "Identity of one-rate, two-color (1R2C)"; 1835 } 1837 identity two-rate-three-color { 1838 base policing; 1839 description 1840 "Identity of two-rate, three-color (2R3C)"; 1841 } 1843 identity BUM-type { 1844 description 1845 "Identity of BUM type"; 1846 } 1848 identity broadcast { 1849 base BUM-type; 1850 description 1851 "Identity of broadcast"; 1852 } 1854 identity unicast { 1855 base BUM-type; 1856 description 1857 "Identity of unicast"; 1858 } 1860 identity multicast { 1861 base BUM-type; 1862 description 1863 "Identity of multicast"; 1864 } 1865 identity loop-prevention-type{ 1866 description 1867 "Identity of loop prevention"; 1868 } 1870 identity shut { 1871 base loop-prevention-type; 1872 description 1873 "Identity of shut protection"; 1874 } 1876 identity trap { 1877 base loop-prevention-type; 1878 description 1879 "Identity of trap protection"; 1880 } 1882 identity lacp-state { 1883 description 1884 "Identity of LACP state"; 1885 } 1887 identity lacp-on { 1888 base lacp-state; 1889 description 1890 "Identity of LCAP on"; 1891 } 1893 identity lacp-off { 1894 base lacp-state; 1895 description 1896 "Identity of LACP off"; 1897 } 1899 identity lacp-mode { 1900 description 1901 "Identity of LACP mode"; 1902 } 1904 identity lacp-passive { 1905 base lacp-mode; 1906 description 1907 "Identity of LACP passive"; 1908 } 1910 identity lacp-active { 1911 base lacp-mode; 1912 description 1913 "Identity of LACP active"; 1914 } 1916 identity lacp-speed { 1917 description 1918 "Identity of LACP speed"; 1919 } 1921 identity lacp-fast { 1922 base lacp-speed; 1923 description 1924 "Identity of LACP fast"; 1925 } 1927 identity lacp-slow { 1928 base lacp-speed; 1929 description 1930 "Identity of LACP slow"; 1931 } 1933 identity vpn-signaling-type { 1934 description 1935 "Identity of VPN signaling types"; 1936 } 1938 identity vrf { 1939 base vpn-signaling-type; 1940 description 1941 "Virtual routing and forwarding (VRF)."; 1942 } 1944 identity vfi { 1945 base vpn-signaling-type; 1946 description 1947 "Virtual forwarder interface"; 1948 } 1950 identity evi { 1951 base vpn-signaling-type; 1952 description 1953 "Ethernet virtual interconnect."; 1954 } 1956 identity l2vpn-type { 1957 description 1958 "Layer 2 VPN types"; 1959 } 1960 identity vpws { 1961 base l2vpn-type; 1962 description 1963 "Virtual Private Wire Service"; 1964 } 1966 identity vpls { 1967 base l2vpn-type; 1968 description 1969 "Virtual Private LAN Service"; 1970 } 1972 identity evpn { 1973 base l2vpn-type; 1974 description 1975 "Ethernet VPN"; 1976 } 1978 identity management { 1979 description 1980 "Base identity for site management scheme."; 1981 } 1983 identity co-managed { 1984 base management; 1985 description 1986 "Base identity for co-managed site."; 1987 } 1989 identity customer-managed { 1990 base management; 1991 description 1992 "Base identity for customer managed site."; 1993 } 1995 identity provider-managed { 1996 base management; 1997 description 1998 "Base identity for provider managed site."; 1999 } 2001 identity address-family { 2002 description 2003 "Base identity for an address family."; 2004 } 2006 identity ipv4 { 2007 base address-family; 2008 description 2009 "Identity for IPv4 address family."; 2010 } 2012 identity ipv6 { 2013 base address-family; 2014 description 2015 "Identity for IPv6 address family."; 2016 } 2018 identity vpn-topology { 2019 description 2020 "Base identity for VPN topology."; 2021 } 2023 identity any-to-any { 2024 base vpn-topology; 2025 description 2026 "Identity for any to any VPN topology."; 2027 } 2029 identity hub-spoke { 2030 base vpn-topology; 2031 description 2032 "Identity for Hub'n'Spoke VPN topology."; 2033 } 2035 identity hub-spoke-disjoint { 2036 base vpn-topology; 2037 description 2038 "Identity for Hub'n'Spoke VPN topology 2039 where Hubs cannot talk between each other."; 2041 } 2043 identity site-role { 2044 description 2045 "Base identity for site type."; 2046 } 2048 identity any-to-any-role { 2049 base site-role; 2050 description 2051 "Site in an any to any IPVPN."; 2052 } 2054 identity spoke-role { 2055 base site-role; 2056 description 2057 "Spoke Site in a Hub & Spoke IPVPN."; 2058 } 2060 identity hub-role { 2061 base site-role; 2062 description 2063 "Hub Site in a Hub & Spoke IPVPN."; 2064 } 2066 identity pm-type { 2067 description 2068 "Performance monitor type"; 2069 } 2071 identity loss { 2072 base pm-type; 2073 description 2074 "Loss measurement"; 2075 } 2077 identity delay { 2078 base pm-type; 2079 description 2080 "Delay measurement"; 2081 } 2083 identity fault-alarm-defect-type { 2084 description 2085 "Indicating the alarm priority defect"; 2086 } 2088 identity remote-rdi { 2089 base fault-alarm-defect-type; 2090 description 2091 "Indicates the aggregate health of the remote MEPs."; 2092 } 2094 identity remote-mac-error { 2095 base fault-alarm-defect-type; 2096 description 2097 "Indicates that one or more of the remote MEPs is 2098 reporting a failure in its Port Status TLV or 2099 Interface Status TLV."; 2100 } 2102 identity remote-invalid-ccm { 2103 base fault-alarm-defect-type; 2104 description 2105 "Indicates that at least one of the Remote MEP 2106 state machines is not receiving valid CCMs 2107 from its remote MEP."; 2108 } 2110 identity invalid-ccm { 2111 base fault-alarm-defect-type; 2112 description 2113 "Indicates that one or more invalid CCMs has been 2114 received and that 3.5 times that CCMs transmission 2115 interval has not yet expired."; 2116 } 2118 identity cross-connect-ccm { 2119 base fault-alarm-defect-type; 2120 description 2121 "Indicates that one or more cross connect CCMs has been 2122 received and that 3.5 times of at least one of those 2123 CCMs transmission interval has not yet expired."; 2124 } 2126 /* Groupings */ 2128 grouping customer-info-grouping { 2129 list customer-info { 2130 key "customer-account-number customer-name"; 2131 leaf customer-account-number { 2132 type uint32; 2133 description 2134 "Customer account number"; 2135 } 2136 leaf customer-name { 2137 type string; 2138 description 2139 "Customer name"; 2140 } 2141 container customer-operation-center { 2142 leaf customer-noc-street-address { 2143 type string; 2144 description 2145 "Customer NOC street Address."; 2146 } 2147 container customer-noc-phone-number { 2148 leaf main-phone-num { 2149 type uint32; 2150 description 2151 "Main phone number."; 2153 } 2154 leaf extension-options { 2155 type uint32; 2156 description 2157 "Extension or options"; 2158 } 2159 description 2160 "Configuration of customer NOCc phone number"; 2161 } 2162 description 2163 "Configuration of customer operation center"; 2164 } 2165 description 2166 "List of customer information"; 2167 } 2168 description 2169 "Grouping for customer information"; 2170 } 2172 grouping site-device { 2173 container device { 2174 list devices { 2175 key "device-id"; 2176 leaf device-id { 2177 type string; 2178 description 2179 "Device ID"; 2180 } 2181 leaf site-name { 2182 type string; 2183 description 2184 "Site name"; 2185 } 2186 leaf address { 2187 type inet:ip-address; 2188 description 2189 "Address"; 2190 } 2191 leaf management-transport { 2192 type identityref { 2193 base address-family; 2194 } 2195 description 2196 "Transport protocol used for management."; 2197 } 2198 description 2199 "List of devices"; 2200 } 2201 description 2202 "Devices configuration"; 2203 } 2204 description 2205 "Device parameters for the site."; 2206 } 2208 grouping site-management { 2209 container managemnt { 2210 leaf type { 2211 type identityref { 2212 base management; 2213 } 2214 description 2215 "Management type of the connection."; 2216 } 2217 description 2218 "Container for management"; 2219 } 2220 description 2221 "Grouping for management"; 2222 } 2224 grouping customer-location-info { 2225 container location { 2226 leaf address { 2227 type string; 2228 description 2229 "Address (number and street) of the site."; 2230 } 2231 leaf zip-code { 2232 type string; 2233 description 2234 "ZIP code of the site."; 2235 } 2236 leaf state { 2237 type string; 2238 description 2239 "State of the site. This leaf can also be used to 2240 describe a region for country who does not have 2241 states."; 2242 } 2243 leaf city { 2244 type string; 2245 description 2246 "City of the site."; 2247 } 2248 leaf country-code { 2249 type string; 2250 description 2251 "Country of the site."; 2252 } 2253 description 2254 "Location of the site."; 2255 } 2256 description 2257 "This grouping defines customer location parameters"; 2258 } 2260 grouping site-diversity { 2261 container site-diversity { 2262 if-feature site-diversity; 2263 container groups { 2264 list group { 2265 key group-id; 2266 leaf group-id { 2267 type string; 2268 description 2269 "Group-id the site is belonging to"; 2270 } 2271 description 2272 "List of group-id"; 2273 } 2274 description 2275 "Groups the site is belonging to. 2276 All site network accesses will inherit those group 2277 values."; 2278 } 2279 description 2280 "Diversity constraint type."; 2281 } 2282 description 2283 "This grouping defines site diversity parameters"; 2284 } 2286 grouping site-service { 2287 leaf svlan-id-ethernet-tag { 2288 type string; 2289 description 2290 "SVLAN-ID/Ethernet Tag configurations"; 2291 } 2292 leaf cvlan-id-to-evc-map { 2293 type string; 2294 description 2295 "List of CVLAN-ID to EVC Map configurations"; 2296 } 2297 leaf service-level-mac-limit { 2298 type string; 2299 description 2300 "Service-level MAC-limit (E-LAN only)"; 2301 } 2302 description 2303 "This grouping defines site service parameters"; 2304 } 2306 grouping service-protection { 2307 container service-protection { 2308 container protection-model { 2309 description 2310 "Container of protection model configurations"; 2311 } 2312 container peer-evc-id { 2313 description 2314 "Container of peer EVC ID configurations"; 2315 } 2316 description 2317 "Container of End-to-end Service Protection 2318 configurations"; 2319 } 2320 description 2321 "Grouping for service protection"; 2322 } 2324 grouping ethernet-service-type { 2325 choice ethernet-svc-type { 2326 case e-line { 2327 leaf epl { 2328 type boolean; 2329 description 2330 "Ethernet private line"; 2331 } 2332 leaf evpl { 2333 type boolean; 2334 description 2335 "Ethernet virtual private line"; 2336 } 2337 description 2338 "Case of e-line"; 2339 } 2340 case e-lan { 2341 leaf ep-lan { 2342 type boolean; 2343 description 2344 "Ethernet private LAN"; 2346 } 2347 leaf evp-lan { 2348 type boolean; 2349 description 2350 "Ethernet virtual private LAN"; 2351 } 2352 description 2353 "Case of e-lan"; 2354 } 2355 case e-access { 2356 leaf access-epl { 2357 type boolean; 2358 description 2359 "Access Ethernet virtual private line"; 2360 } 2361 leaf access-evpl { 2362 type boolean; 2363 description 2364 "Access Ethernet virtual private line"; 2365 } 2366 description 2367 "Case of e-access."; 2368 } 2369 description 2370 "Choice of Ethernet service type"; 2371 } 2372 description 2373 "Grouping for Ethernet service type."; 2374 } 2376 grouping signaling-option-grouping { 2377 list signaling-option { 2378 key "name type"; 2379 leaf name { 2380 type string; 2381 description 2382 "VRF/VFI/EVI Name"; 2383 } 2384 leaf type { 2385 type identityref { 2386 base vpn-signaling-type; 2387 } 2388 description 2389 "VPN signaling types"; 2390 } 2391 container mp-bgp-l2vpn { 2392 leaf vpn-id { 2393 type string; 2394 description 2395 "Identifies the target VPN"; 2396 } 2397 leaf type { 2398 type identityref { 2399 base l2vpn-type; 2400 } 2401 description 2402 "L2VPN types"; 2403 } 2404 description 2405 "Container for MP BGP L2VPN"; 2406 } 2407 container mp-bgp-evpn { 2408 leaf vpn-id { 2409 type string; 2410 description 2411 "Identifies the target VPN"; 2412 } 2413 leaf type { 2414 type identityref { 2415 base l2vpn-type; 2416 } 2417 description 2418 "L2VPN types"; 2419 } 2420 description 2421 "Container for MP BGP L2VPN"; 2422 } 2423 container t-ldp-pwe { 2424 list PE-EG-list { 2425 key "service-ip-lo-addr vc-id"; 2426 leaf service-ip-lo-addr { 2427 type inet:ip-address; 2428 description 2429 "Service ip lo address"; 2430 } 2431 leaf vc-id { 2432 type string; 2433 description 2434 "VC id"; 2435 } 2436 description 2437 "List of PE/EG"; 2438 } 2439 description 2440 "Container of T-LDP PWE configurations"; 2441 } 2442 container pwe-encapsulation-type { 2443 leaf ethernet { 2444 type boolean; 2445 description 2446 "Ethernet"; 2447 } 2448 leaf vlan { 2449 type boolean; 2450 description 2451 "VLAN"; 2452 } 2453 description 2454 "Container of PWE Encapsulation Type configurations"; 2455 } 2456 container pwe-mtu { 2457 leaf allow-mtu-mismatch { 2458 type boolean; 2459 description 2460 "Allow MTU mismatch"; 2461 } 2462 description 2463 "Container of PWE MTU configurations"; 2464 } 2465 container control-word { 2466 description 2467 "Container of control word configurations"; 2468 } 2469 description 2470 "List of VPN Signaling Option."; 2471 } 2472 description 2473 "Grouping for signaling option"; 2474 } 2476 grouping load-balance-grouping { 2477 leaf fat-pw { 2478 type boolean; 2479 description 2480 "Fat label is applied to Pseudowires across MPLS 2481 network"; 2482 } 2483 leaf entropy-label { 2484 type boolean; 2485 description 2486 "Entropy label is applied to IP forwarding, 2487 L2VPN or L3VPN across MPLS network"; 2488 } 2489 leaf vxlan-source-port { 2490 type string; 2491 description 2492 "Vxlan source port"; 2493 } 2494 description 2495 "Grouping for load balance "; 2496 } 2498 grouping intra-mkt-grouping { 2499 list intra-mkt { 2500 key "metro-mkt-id mkt-name"; 2501 leaf metro-mkt-id { 2502 type uint32; 2503 description 2504 "Metro MKT ID"; 2505 } 2506 leaf mkt-name { 2507 type string; 2508 description 2509 "MKT Name"; 2510 } 2511 description 2512 "List of intra-MKT"; 2513 } 2514 description 2515 "Grouping for intra-MKT"; 2516 } 2518 grouping inter-mkt-service { 2519 leaf inter-mkt-service{ 2520 type boolean; 2521 description 2522 "Indicate whether service is inter market service."; 2523 } 2524 description 2525 "Grouping for inter-MKT service"; 2526 } 2528 grouping evc-id-grouping { 2529 leaf evc-id { 2530 type boolean; 2531 description 2532 "Ethernet Virtual Connection identifier"; 2533 } 2534 description 2535 "Grouping for EVC-ID"; 2536 } 2537 grouping svc-type-grouping { 2538 container svc-type { 2539 container evc { 2540 leaf evc-id { 2541 type boolean; 2542 description 2543 "Indicate whether the Ethernet virtual connection 2544 id support."; 2545 } 2546 leaf number-of-pe { 2547 type uint32; 2548 config false; 2549 description 2550 "Number of PEs"; 2551 } 2552 leaf number-of-site { 2553 type uint32; 2554 config false; 2555 description 2556 "Number of Sites"; 2557 } 2558 description 2559 "Container for Ethernet virtual connection."; 2560 } 2561 container ovc { 2562 leaf on-net-ovc-id { 2563 type boolean; 2564 description 2565 "Indicate whether the on net OVC id support."; 2566 } 2567 leaf off-net-ov-id { 2568 type boolean; 2569 description 2570 "Indicate whether the off net OVC id support."; 2571 } 2572 description 2573 "Container for OVC"; 2574 } 2575 description 2576 "Container for service types."; 2577 } 2578 description 2579 "Grouping of service types."; 2580 } 2582 grouping cfm-802-grouping { 2583 leaf MAID { 2584 type string; 2585 description 2586 "MA ID"; 2587 } 2588 leaf mep-id { 2589 type uint32; 2590 description 2591 "Local MEP ID"; 2592 } 2593 leaf mep-level { 2594 type uint32; 2595 description 2596 "MEP level"; 2597 } 2598 leaf mep-up-down { 2599 type enumeration { 2600 enum up { 2601 description 2602 "MEP up"; 2603 } 2604 enum down { 2605 description 2606 "MEP down"; 2607 } 2608 } 2609 description 2610 "MEP up/down"; 2611 } 2612 leaf remote-mep-id { 2613 type uint32; 2614 description 2615 "Remote MEP ID"; 2616 } 2617 leaf cos-for-cfm-pdus { 2618 type uint32; 2619 description 2620 "COS for CFM PDUs"; 2621 } 2622 leaf ccm-interval { 2623 type uint32; 2624 description 2625 "CCM interval"; 2626 } 2627 leaf ccm-holdtime { 2628 type uint32; 2629 description 2630 "CCM hold time"; 2631 } 2632 leaf alarm-priority-defect { 2633 type identityref { 2634 base fault-alarm-defect-type; 2635 } 2636 description 2637 "The lowest priority defect that is 2638 allowed to generate a Fault Alarm. 2639 The non-existence of this leaf means 2640 that no defects are to be reported"; 2641 } 2642 leaf ccm-p-bits-pri { 2643 type ccm-priority-type; 2644 description 2645 "The priority parameter for CCMs transmitted by the MEP"; 2646 } 2647 description 2648 "Grouping for 802.1ag CFM attribute"; 2649 } 2651 grouping y-1731{ 2652 list y-1731 { 2653 key MAID; 2654 leaf MAID { 2655 type string; 2656 description 2657 "MA ID "; 2658 } 2659 leaf mep-id { 2660 type uint32; 2661 description 2662 "Local MEP ID"; 2663 } 2664 leaf type { 2665 type identityref { 2666 base pm-type; 2667 } 2668 description 2669 "Performance monitor types"; 2670 } 2671 leaf remote-mep-id { 2672 type uint32; 2673 description 2674 "Remote MEP ID"; 2675 } 2676 leaf message-period { 2677 type uint32; 2678 description 2679 "Defines the interval between OAM messages. The message 2680 period is expressed in milliseconds"; 2682 } 2683 leaf measurement-interval { 2684 type uint32; 2685 description 2686 "Specifies the measurement interval for statistics. The 2687 measurement interval is expressed in seconds"; 2688 } 2689 leaf cos { 2690 type uint32; 2691 description 2692 "Class of service"; 2693 } 2694 leaf loss-measurement { 2695 type boolean; 2696 description 2697 "Whether enable loss measurement"; 2698 } 2699 leaf synthethic-loss-measurement { 2700 type boolean; 2701 description 2702 "Indicate whether enable synthetic loss measurement"; 2703 } 2704 container delay-measurement { 2705 leaf enable-dm { 2706 type boolean; 2707 description 2708 "Whether to enable delay measurement"; 2709 } 2710 leaf two-way { 2711 type boolean; 2712 description 2713 "Whether delay measurement is two-way (true) of one- 2714 way (false)"; 2715 } 2716 description 2717 "Container for delay measurement"; 2718 } 2719 leaf frame-size { 2720 type uint32; 2721 description 2722 "Frame size"; 2723 } 2724 leaf session-type { 2725 type enumeration { 2726 enum proactive { 2727 description 2728 "Proactive mode"; 2729 } 2730 enum on-demand { 2731 description 2732 "On demand mode"; 2733 } 2734 } 2735 description 2736 "Session type"; 2737 } 2738 description 2739 "List for y-1731."; 2740 } 2741 description 2742 "Grouping for y.1731"; 2743 } 2745 grouping enni-site-info-grouping { 2746 container site-info { 2747 leaf site-name { 2748 type string; 2749 description 2750 "Site name"; 2751 } 2752 leaf address { 2753 type inet:ip-address; 2754 description 2755 "Address"; 2756 } 2757 leaf Edge-Gateway-Device-Info { 2758 type string; 2759 description 2760 "Edge Gateway Device Info "; 2761 } 2762 description 2763 "Container of site info configurations"; 2764 } 2765 description 2766 "Grouping for site information"; 2767 } 2769 grouping site-security { 2770 container security { 2771 description 2772 "Security parameters"; 2773 } 2774 description 2775 "This grouping defines security parameters for a site"; 2776 } 2777 grouping lacp-grouping { 2778 container LACP { 2779 leaf LACP-state { 2780 type identityref { 2781 base lacp-state; 2782 } 2783 description 2784 "LACP on/off"; 2785 } 2786 leaf LACP-mode { 2787 type identityref { 2788 base lacp-mode; 2789 } 2790 description 2791 "LACP mode"; 2792 } 2793 leaf LACP-speed { 2794 type identityref { 2795 base lacp-speed; 2796 } 2797 description 2798 "LACP speed"; 2799 } 2800 leaf mini-link { 2801 type uint32; 2802 description 2803 "Mini link"; 2804 } 2805 leaf system-priority { 2806 type uint16; 2807 description 2808 "Indicates the LACP priority for the system. 2809 The range is from 0 to 65535. 2810 The default is 32768."; 2811 } 2812 container Micro-BFD { 2813 if-feature Micro-BFD; 2814 leaf Micro-BFD-on-off { 2815 type enumeration { 2816 enum on { 2817 description 2818 "Micro-bfd on"; 2819 } 2820 enum off { 2821 description 2822 "Micro-bfd off"; 2823 } 2824 } 2825 description 2826 "Micro BFD ON/OFF"; 2827 } 2828 leaf bfd-interval { 2829 type uint32; 2830 description 2831 "BFD interval"; 2832 } 2833 leaf bfd-hold-timer { 2834 type uint32; 2835 description 2836 "BFD hold timer"; 2837 } 2838 description 2839 "Container of Micro-BFD configurations"; 2840 } 2841 container bfd { 2842 if-feature bfd; 2843 leaf bfd-enabled { 2844 type boolean; 2845 description 2846 "BFD activation"; 2847 } 2848 choice holdtime { 2849 case profile { 2850 leaf profile-name { 2851 type string; 2852 description 2853 "Service provider well known profile."; 2854 } 2855 description 2856 "Service provider well known profile."; 2857 } 2858 case fixed { 2859 leaf fixed-value { 2860 type uint32; 2861 units msec; 2862 description 2863 "Expected hold time expressed in msec."; 2864 } 2865 } 2866 description 2867 "Choice for hold time flavor."; 2868 } 2869 description 2870 "Container for BFD."; 2871 } 2872 container Member-link-list { 2873 list member-link { 2874 key "name"; 2875 leaf name { 2876 type string; 2877 description 2878 "Member link name"; 2879 } 2880 leaf port-speed { 2881 type uint32; 2882 description 2883 "Port speed"; 2884 } 2885 leaf auto-neg { 2886 type string; 2887 description 2888 "Auto neg"; 2889 } 2890 leaf mtu { 2891 type uint32; 2892 description 2893 "MTU"; 2894 } 2895 container oam-802.3AH-link { 2896 if-feature oam-3ah; 2897 leaf enable { 2898 type boolean; 2899 description 2900 "Indicate whether support oam 802.3 ah link"; 2901 } 2902 description 2903 "Container for oam 802.3 ah link."; 2904 } 2905 description 2906 "Member link"; 2907 } 2908 description 2909 "Container of Member link list"; 2910 } 2911 leaf flow-control { 2912 type string; 2913 description 2914 "Flow control"; 2915 } 2916 leaf encapsulation-type { 2917 type enumeration { 2918 enum VLAN { 2919 description 2920 "VLAN"; 2922 } 2923 enum ether { 2924 description 2925 "Ethernet"; 2926 } 2927 } 2928 description 2929 "Encapsulation type"; 2930 } 2931 leaf ethertype { 2932 type string; 2933 description 2934 "Ether type"; 2935 } 2936 leaf lldp { 2937 type boolean; 2938 description 2939 "LLDP"; 2940 } 2941 description 2942 "LACP"; 2943 } 2944 description 2945 "Grouping for lacp"; 2946 } 2948 grouping phy-interface-grouping { 2949 container phy-interface { 2950 leaf port-number { 2951 type uint32; 2952 description 2953 "Port number"; 2954 } 2955 leaf port-speed { 2956 type uint32; 2957 description 2958 "Port speed"; 2959 } 2960 leaf auto-neg { 2961 type string; 2962 description 2963 "Auto neg"; 2964 } 2965 leaf phy-mtu { 2966 type uint32; 2967 description 2968 "PHY MTU"; 2969 } 2970 leaf flow-control { 2971 type string; 2972 description 2973 "Flow control"; 2974 } 2975 leaf encapsulation-type { 2976 type enumeration { 2977 enum VLAN { 2978 description 2979 "VLAN"; 2980 } 2981 enum Ethernet { 2982 description 2983 "Ethernet"; 2984 } 2985 } 2986 description 2987 "Encapsulation-type"; 2988 } 2989 leaf ethertype { 2990 type string; 2991 description 2992 "Ethertype"; 2993 } 2994 leaf lldp { 2995 type boolean; 2996 description 2997 "LLDP"; 2998 } 2999 container oam-802.3AH-link{ 3000 if-feature oam-3ah; 3001 leaf enable { 3002 type boolean; 3003 description 3004 "Indicate whether support oam 802.3 ah link"; 3005 } 3006 description 3007 "Container for oam 802.3 ah link."; 3008 } 3009 leaf uni-loop-prevention { 3010 type boolean; 3011 description 3012 "If this leaf set to truth that the port automatically 3013 goes down when a physical loopback is detect."; 3014 } 3015 description 3016 "Container of PHY Interface Attributes configurations"; 3017 } 3018 description 3019 "Grouping for phy interface."; 3020 } 3022 grouping lag-interface-grouping { 3023 container LAG-interface { 3024 list LAG-interface { 3025 key "LAG-interface-number"; 3026 leaf LAG-interface-number { 3027 type uint32; 3028 description 3029 "LAG interface number"; 3030 } 3031 uses lacp-grouping; 3032 description 3033 "List of LAG interfaces"; 3034 } 3035 description 3036 "Container of LAG interface attributes configuration"; 3037 } 3038 description 3039 "Grouping for LAG interface"; 3040 } 3042 grouping bearer-grouping { 3043 container bearer { 3044 uses phy-interface-grouping; 3045 uses lag-interface-grouping; 3046 leaf interface-description { 3047 type string; 3048 description 3049 "Interface description"; 3050 } 3051 leaf sub-if-id { 3052 type uint32; 3053 description 3054 "Sub-if id"; 3055 } 3056 description 3057 "Container for bearer"; 3058 } 3059 description 3060 "Grouping for bearer."; 3061 } 3063 grouping ethernet-connection-grouping { 3064 container ethernet-connection { 3065 container vlan { 3066 leaf svlan-id-ethernet-tag { 3067 type string; 3068 description 3069 "SVLAN-ID/Ethernet Tag configurations"; 3070 } 3071 description 3072 "Abstract container for VLAN"; 3073 } 3074 description 3075 "Container for Ethernet connection"; 3076 } 3077 description 3078 "Grouping for Ethernet connection"; 3079 } 3081 grouping evc-mtu-grouping { 3082 leaf evc-mtu { 3083 type uint32; 3084 description 3085 "EVC MTU"; 3086 } 3087 description 3088 "Grouping for evc mtu"; 3089 } 3091 grouping mac-addr-limit-grouping { 3092 container mac-addr-limit { 3093 leaf exceeding-option { 3094 type uint32; 3095 description 3096 "Exceeding option"; 3097 } 3098 description 3099 "Container of MAC-Addr limit configurations"; 3100 } 3101 description 3102 "Grouping for mac address limit"; 3103 } 3105 grouping multihoming-grouping { 3106 container multihoming { 3107 list multihoming { 3108 key "ESI"; 3109 leaf ESI { 3110 type string; 3111 description 3112 "Ethernet segment id"; 3113 } 3114 choice redundancy-mode { 3115 case single-active { 3116 leaf single-active { 3117 type boolean; 3118 description 3119 "Single active"; 3120 } 3121 description 3122 "Single active case"; 3123 } 3124 case all-active { 3125 leaf all-active { 3126 type boolean; 3127 description 3128 "All active"; 3129 } 3130 description 3131 "All active case"; 3132 } 3133 description 3134 "Redundancy mode choice"; 3135 } 3136 description 3137 "List of multihomings"; 3138 } 3139 description 3140 "Container of multihoming optional configurations"; 3141 } 3142 description 3143 "Grouping for multihoming"; 3144 } 3146 grouping l2cp-grouping { 3147 container L2CP-control { 3148 leaf stp-rstp-mstp { 3149 type control-mode; 3150 description 3151 "STP/RSTP/MSTP"; 3152 } 3153 leaf pause { 3154 type control-mode; 3155 description 3156 "Pause"; 3157 } 3158 leaf lacp-lamp { 3159 type control-mode; 3160 description 3161 "LACP/LAMP"; 3163 } 3164 leaf link-oam { 3165 type control-mode; 3166 description 3167 "Link OAM"; 3168 } 3169 leaf esmc { 3170 type control-mode; 3171 description 3172 "ESMC"; 3173 } 3174 leaf l2cp-802.1x { 3175 type control-mode; 3176 description 3177 "802.x"; 3178 } 3179 leaf e-lmi { 3180 type control-mode; 3181 description 3182 "E-LMI"; 3183 } 3184 leaf lldp { 3185 type boolean; 3186 description 3187 "LLDP"; 3188 } 3189 leaf ptp-peer-delay { 3190 type control-mode; 3191 description 3192 "PTP peer delay"; 3193 } 3194 leaf garp-mrp { 3195 type control-mode; 3196 description 3197 "GARP/MARP"; 3198 } 3199 leaf provider-bridge-group { 3200 type yang:mac-address; 3201 description 3202 "Provider bridge group reserved MAC address 3203 01-80-C2-00-00-08"; 3204 } 3205 leaf provider-bridge-mvrp { 3206 type yang:mac-address; 3207 description 3208 "Provider bridge MVRP reserved MAC address 3209 01-80-C2-00-00-0D"; 3210 } 3211 description 3212 "Container of L2CP control configurations"; 3213 } 3214 description 3215 "Grouping for l2cp control"; 3216 } 3218 grouping service-level-grouping { 3219 container service-level { 3220 leaf cos-identifier { 3221 type identityref { 3222 base cos-id; 3223 } 3224 description 3225 "COS Identifier [ EVC | EVC + PCP ]"; 3226 } 3227 leaf color-identifier { 3228 type identityref { 3229 base color-id; 3230 } 3231 description 3232 "Color Identifier [ EVC | EVC + CVLAN ]"; 3233 } 3234 leaf ingress-bw-profile-per-evc { 3235 type string; 3236 description 3237 "Ingress Bandwidth Profile per EVC"; 3238 } 3239 leaf ingress-bw-profile-per-cos-id { 3240 type string; 3241 description 3242 "Ingress Bandwidth Profile per COS Identifier"; 3243 } 3244 leaf egress-bw-profile-per-evc { 3245 type string; 3246 description 3247 "Egress Bandwidth Profile per EVC"; 3248 } 3249 leaf egress-bw-profile-per-cos-id { 3250 type string; 3251 description 3252 "Egress Bandwidth Profile per COS Identifier"; 3253 } 3254 leaf byte-offset { 3255 type uint16; 3256 description 3257 "For not including extra VLAN tags in the QoS 3258 calculation"; 3260 } 3261 leaf policing { 3262 type identityref { 3263 base policing; 3264 } 3265 description 3266 "The policing can be either one-rate, 3267 two-color (1R2C) or two-rate, three-color (2R3C)"; 3268 } 3269 leaf performance-tier-option { 3270 type identityref { 3271 base performance-tier-option; 3272 } 3273 description 3274 "Performance tier option"; 3275 } 3276 leaf COS { 3277 type uint32; 3278 description 3279 "Class of Service"; 3280 } 3281 description 3282 "Container of service level configurations."; 3283 } 3284 description 3285 "Grouping for service level."; 3286 } 3288 grouping B-U-M-strom-control-grouping { 3289 container B-U-M-strom-control { 3290 leaf BUM-overall-rate { 3291 type uint32; 3292 description 3293 "overall rate for BUM"; 3294 } 3295 list BUM-rate-per-type { 3296 key "type"; 3297 leaf type { 3298 type identityref { 3299 base BUM-type; 3300 } 3301 description 3302 "BUM type"; 3303 } 3304 leaf rate { 3305 type uint32; 3306 description 3307 "rate for BUM"; 3309 } 3310 description 3311 "List of rate per type"; 3312 } 3313 description 3314 "Container of B-U-M-strom-control configurations"; 3315 } 3316 description 3317 "Grouping for B-U-M-strom-control"; 3318 } 3320 grouping mac-loop-prevention-grouping { 3321 container mac-loop-prevention { 3322 leaf frequency { 3323 type uint32; 3324 description 3325 "Frequency"; 3326 } 3327 leaf protection-type { 3328 type identityref { 3329 base loop-prevention-type; 3330 } 3331 description 3332 "Protection type"; 3333 } 3334 leaf number-retries { 3335 type uint32; 3336 description 3337 "Number of retries"; 3338 } 3339 description 3340 "Container of MAC loop prevention."; 3341 } 3342 description 3343 "Grouping for MAC loop prevention"; 3344 } 3346 grouping ethernet-svc-oam-grouping { 3347 container Ethernet-Service-OAM { 3348 leaf MD-name{ 3349 type string; 3350 description 3351 "Maintenance domain name"; 3352 } 3353 leaf MD-level { 3354 type uint8; 3355 description 3356 "Maintenance domain level"; 3358 } 3359 container cfm-802.1-ag { 3360 list n2-uni-c { 3361 key "MAID"; 3362 uses cfm-802-grouping; 3363 description 3364 "List of UNI-N to UNI-C"; 3365 } 3366 list n2-uni-n { 3367 key "MAID"; 3368 uses cfm-802-grouping; 3369 description 3370 "List of UNI-N to UNI-N"; 3371 } 3372 description 3373 "Container of 802.1ag CFM configurations."; 3374 } 3375 uses y-1731; 3376 description 3377 "Container for Ethernet service OAM."; 3378 } 3379 description 3380 "Grouping for Ethernet service OAM."; 3381 } 3383 grouping fate-sharing-group { 3384 container groups { 3385 leaf fate-sharing-group-size { 3386 type uint16; 3387 description 3388 "fate sharing group size."; 3389 } 3390 list group { 3391 key group-id; 3392 leaf group-id { 3393 type string; 3394 description 3395 "Group-id the site network access 3396 is belonging to"; 3397 } 3398 description 3399 "List of group-id"; 3400 } 3401 description 3402 "Groups the fate sharing group member 3403 is belonging to"; 3404 } 3405 description 3406 "Grouping for Fate sharing group."; 3407 } 3409 /* MAIN L2VPN SERVICE */ 3411 container l2vpn-svc { 3413 /* CUSTOMER */ 3414 container customer-info { 3415 uses customer-info-grouping; 3416 description 3417 "Container of customer information configurations."; 3418 } 3420 /* SERVICE */ 3421 container vpn-services { 3422 list vpn-svc { 3423 key "svc-id"; 3424 leaf svc-id { 3425 type string; 3426 description 3427 "Defining a service id."; 3428 } 3429 uses svc-type-grouping; 3430 container ethernet-svc-type { 3431 uses ethernet-service-type; 3432 description 3433 "Container of Ethernet service type"; 3434 } 3435 container metro-network-id { 3436 uses inter-mkt-service; 3437 uses intra-mkt-grouping; 3438 description 3439 "Container of Metro-Network ID configurations"; 3440 } 3441 container signaling-option { 3442 uses signaling-option-grouping; 3443 description 3444 "Container for signaling option"; 3445 } 3446 container load-balance-options{ 3447 uses load-balance-grouping; 3448 description 3449 "Container for load balance options"; 3450 } 3451 uses site-service; 3452 uses service-protection; 3453 container sla-targets { 3454 description 3455 "Container for SLA targets"; 3456 } 3457 description 3458 "List of vpn-svc"; 3459 } 3460 description 3461 "Container of vpn-services configurations"; 3462 } 3464 /* SITE */ 3465 container sites { 3466 list site { 3467 key "site-id site-type"; 3468 leaf site-id { 3469 type string; 3470 description 3471 "Site id"; 3472 } 3473 leaf site-type { 3474 type identityref { 3475 base site-type; 3476 } 3477 description 3478 "Site type"; 3479 } 3480 uses site-device; 3481 uses site-management; 3482 uses customer-location-info; 3483 uses site-diversity; 3484 uses site-security; 3485 container signaling-option { 3486 if-feature signaling-option; 3487 uses signaling-option-grouping; 3488 description 3489 "Container for signaling option"; 3490 } 3491 container load-balance-options { 3492 uses load-balance-grouping; 3493 description 3494 "Container for load balance options"; 3495 } 3496 container ports { 3497 list port { 3498 key "id"; 3499 leaf id { 3500 type string; 3501 description 3502 "Identifier"; 3503 } 3504 leaf remote-carrier-name { 3505 when "../site-type = enni" { 3506 description 3507 "Site type = enni"; 3508 } 3509 type string; 3510 description 3511 "Remote carrier name"; 3512 } 3513 uses fate-sharing-group; 3514 uses bearer-grouping; 3515 uses ethernet-connection-grouping; 3516 uses evc-mtu-grouping; 3517 uses mac-addr-limit-grouping; 3518 uses multihoming-grouping; 3519 uses l2cp-grouping; 3520 container service { 3521 uses site-service; 3522 uses service-level-grouping; 3523 description 3524 "Container for site service."; 3525 } 3526 uses B-U-M-strom-control-grouping; 3527 uses mac-loop-prevention-grouping; 3528 uses ethernet-svc-oam-grouping; 3529 uses site-security; 3530 description 3531 "List of ports"; 3532 } 3533 description 3534 "Container of port configurations"; 3535 } 3536 description 3537 "List of sites"; 3538 } 3539 description 3540 "Container of site configurations"; 3541 } 3542 description 3543 "Container of l2vpn-svc configurations"; 3544 } 3545 } 3546 3548 9. Security Considerations 3550 The YANG modules defined in this document MAY be accessed via the 3551 RESTCONF protocol [I-D.ietf-netconf-restconf] or NETCONF protocol 3552 ([RFC6241]. The lowest RESTCONF or NETCONF layer requires that the 3553 transport-layer protocol provides both data integrity and 3554 confidentiality, see Section 2 in [I-D.ietf-netconf-restconf] and 3555 [RFC6241]. The client MUST carefully examine the certificate 3556 presented by the server to determine if it meets the client's 3557 expectations, and the server MUST authenticate client access to any 3558 protected resource. The client identity derived from the 3559 authentication mechanism used is subject to the NETCONF Access 3560 Control Module (NACM) ([RFC6536]). Other protocols to access this 3561 YANG module are also required to support the similar mechanism. 3563 The data nodes defined in the "ietf-l2vpn-svc" YANG module MUST be 3564 carefully created/read/updated/deleted. The entries in the lists 3565 below include customer proprietary or confidential information, 3566 therefore only authorized clients MUST access the information and the 3567 other clients MUST NOT be able to access to the information. 3569 o /l2vpn-svc/vpn-services/vpn-svc 3571 o /l2vpn-svc/sites/site 3573 10. Acknowledgements 3575 Thanks to Qin Wu and Adrian Farrel for facilitating work on the 3576 initial revisions of this document. 3578 This document has drawn on the work of the L3SM Working Group 3579 expressed in [I-D.ietf-l3sm-l3vpn-service-model]. 3581 11. IANA Considerations 3583 IANA is requested to assign a new URI from the IETF XML registry 3584 ([RFC3688]). The following URI is suggested: 3586 URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc 3587 Registrant Contact: L2SM WG 3588 XML: N/A, the requested URI is an XML namespace 3590 This document also requests a new YANG module name in the YANG Module 3591 Names registry ([RFC6020]) with the following suggestion: 3593 name: ietf-l2vpn-svc 3594 namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc 3595 prefix: l2vpn-svc 3596 reference: RFC XXXX 3598 12. References 3600 12.1. Normative References 3602 [I-D.ietf-netconf-restconf] 3603 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3604 Protocol", draft-ietf-netconf-restconf-17 (work in 3605 progress), September 2016. 3607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3608 Requirement Levels", BCP 14, RFC 2119, 3609 DOI 10.17487/RFC2119, March 1997, 3610 . 3612 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3613 DOI 10.17487/RFC3688, January 2004, 3614 . 3616 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 3617 "Encapsulation Methods for Transport of Ethernet over MPLS 3618 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 3619 . 3621 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 3622 LAN Service (VPLS) Using BGP for Auto-Discovery and 3623 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 3624 . 3626 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 3627 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 3628 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 3629 . 3631 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 3632 the Network Configuration Protocol (NETCONF)", RFC 6020, 3633 DOI 10.17487/RFC6020, October 2010, 3634 . 3636 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3637 and A. Bierman, Ed., "Network Configuration Protocol 3638 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3639 . 3641 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 3642 Protocol (NETCONF) Access Control Model", RFC 6536, 3643 DOI 10.17487/RFC6536, March 2012, 3644 . 3646 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 3647 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 3648 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 3649 2015, . 3651 12.2. Informative References 3653 [I-D.ietf-bess-evpn-yang] 3654 Brissette, P., Sajassi, A., Shah, H., Li, Z., 3655 Tiruveedhula, K., Hussain, I., and J. Rabadan, "Yang Data 3656 Model for EVPN", draft-ietf-bess-evpn-yang-01 (work in 3657 progress), July 2016. 3659 [I-D.ietf-bess-l2vpn-yang] 3660 Shah, H., Brissette, P., Chen, I., Hussain, I., and B. 3661 Wen, "YANG Data Model for MPLS-based L2VPN", draft-ietf- 3662 bess-l2vpn-yang-00 (work in progress), June 2016. 3664 [I-D.ietf-l3sm-l3vpn-service-model] 3665 Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 3666 Model for L3VPN service delivery", draft-ietf-l3sm-l3vpn- 3667 service-model-18 (work in progress), October 2016. 3669 [I-D.wu-opsawg-service-model-explained] 3670 Wu, Q., LIU, S., and A. Farrel, "Service Models 3671 Explained", draft-wu-opsawg-service-model-explained-03 3672 (work in progress), September 2016. 3674 [IEEE-802-1ag] 3675 IEEE, "802.1ag - Connectivity Fault Management", December 3676 2007. 3678 [ITU-T-Y-1731] 3679 ITU-T, "Recommendation Y.1731 - OAM functions and 3680 mechanisms for Ethernet based networks", February 2008. 3682 [MEF-23-2] 3683 MEF Forum, "Implementation Agreement MEF 23.2 : Carrier 3684 Ethernet Class of Service - Phase 3", August 2016. 3686 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 3687 Virtual Private Networks Using BGP for Auto-Discovery and 3688 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 3689 . 3691 Authors' Addresses 3693 Bin Wen 3694 Comcast 3696 Email: Bin_Wen@comcast.com 3698 Giuseppe Fioccola 3699 Telecom Italia 3701 Email: giuseppe.fioccola@telecomitalia.it 3703 Chongfeng Xie 3704 China Telecom 3706 Email: xiechf@ctbri.com.cn 3708 Luay Jalil 3709 Verizon 3711 Email: luay.jalil@verizon.com