idnits 2.17.1 draft-wen-l2sm-l2vpn-service-model-01.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 611 has weird spacing: '...lo-addr inet...' == Line 647 has weird spacing: '...roup-id str...' == Line 834 has weird spacing: '...roup-id strin...' == Line 857 has weird spacing: '...lo-addr ine...' == Line 888 has weird spacing: '...-number uin...' -- The document date (September 29, 2016) is 2759 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 887, but not defined == Missing Reference: 'ESI' is mentioned on line 929, but not defined == Missing Reference: 'MAID' is mentioned on line 999, 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-16 == Outdated reference: A later version (-06) exists of draft-wu-opsawg-service-model-explained-03 Summary: 1 error (**), 0 flaws (~~), 14 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 2, 2017 Telecom Italia 6 C. Xie 7 China Telecom 8 L. Jalil 9 Verizon 10 September 29, 2016 12 A YANG Data Model for L2VPN Service Delivery 13 draft-wen-l2sm-l2vpn-service-model-01 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 2, 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 . . . . . 9 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 . . . . . . . . 23 87 5.1.1. Customer Information . . . . . . . . . . . . . . . . 23 88 5.1.2. VPN Service Overview . . . . . . . . . . . . . . . . 23 89 5.1.2.1. Service Type . . . . . . . . . . . . . . . . . . 23 90 5.1.2.2. ethernet-svc-type . . . . . . . . . . . . . . . . 24 91 5.1.2.3. Metro Network Partition . . . . . . . . . . . . . 24 92 5.1.2.4. vpn-signaling-option . . . . . . . . . . . . . . 25 93 5.1.2.5. Load Balance Option . . . . . . . . . . . . . . . 27 94 5.1.2.6. SVLAN ID Ethernet Tag . . . . . . . . . . . . . . 28 95 5.1.2.7. CVLAN ID To EVC MAP . . . . . . . . . . . . . . . 28 96 5.1.2.8. Service Level MAC Limit . . . . . . . . . . . . . 29 97 5.1.2.9. Service Protection . . . . . . . . . . . . . . . 29 98 5.1.3. site . . . . . . . . . . . . . . . . . . . . . . . . 30 99 5.1.3.1. uni-site . . . . . . . . . . . . . . . . . . . . 30 100 5.1.3.2. enni-site . . . . . . . . . . . . . . . . . . . . 38 101 6. Interaction with Other YANG Modules . . . . . . . . . . . . . 39 102 7. Service Model Usage Example . . . . . . . . . . . . . . . . . 40 103 8. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 40 104 9. Security Considerations . . . . . . . . . . . . . . . . . . . 83 105 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 83 106 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 107 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 84 108 12.1. Normative References . . . . . . . . . . . . . . . . . . 84 109 12.2. Informative References . . . . . . . . . . . . . . . . . 85 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86 112 1. Introduction 114 This document defines a YANG data model for Layer 2 VPN (L2VPN) 115 service configuration. This model is intended to be instantiated at 116 management system to allow a user (a customer or an application) to 117 request the service. This model is not a configuration model to be 118 used directly on network elements, but provides an abstracted view of 119 the L2VPN service configuration components. It is up to a management 120 system to take this as an input and use specific configurations 121 models to configure the different network elements to deliver the 122 service. How configuration of network elements is done is out of 123 scope of the document. 125 The data model in this document includes support for point-to-point 126 Virtual Private Wire Services (VPWS) and multipoint Virtual Private 127 LAN services (VPLS) that use Pseudowires signaled using the Label 128 Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as 129 described in RFC4761 and RFC6624. 131 Further discussion of the way that service are modelled in YANG and 132 of the relationship between "customer service models" like the one 133 described in this document and configuration models can be found in 134 [I-D.wu-opsawg-service-model-explained]. Section 4 and Section 6 135 also provide more information of how this service model could be used 136 and how it fits into the overall modelling architecture. 138 1.1. Terminology 140 The following terms are defined in [RFC6241] and are not redefined 141 here: 143 o client 144 o configuration data 146 o server 148 o state data 150 The following terms are defined in [RFC6020] and are not redefined 151 here: 153 o augment 155 o data model 157 o data node 159 The terminology for describing YANG data models is found in 160 [RFC6020]. 162 1.2. Tree diagram 164 A simplified graphical representation of the data model is presented 165 in Section 5. 167 The meaning of the symbols in these diagrams is as follows: 169 o Brackets "[" and "]" enclose list keys. 171 o Curly braces "{" and "}" contain names of optional features that 172 make the corresponding node conditional. 174 o Abbreviations before data node names: "rw" means configuration 175 (read-write), and "ro" state data (read-only). 177 o Symbols after data node names: "?" means an optional node and "*" 178 denotes a "list" or "leaf-list". 180 o Parentheses enclose choice and case nodes, and case nodes are also 181 marked with a colon (":"). 183 o Ellipsis ("...") stands for contents of subtrees that are not 184 shown. 186 2. Definitions 188 This document uses the following terms: 190 Service Provider (SP): The organization (usually a commercial 191 undertaking) responsible for operating the network that offers VPN 192 services to clients and customers. 194 Customer Edge (CE) Device: Equipment that is dedicated to a 195 particular customer and is directly connected to one or more PE 196 devices via attachment circuits. A CE is usually located at the 197 customer premises, and is usually dedicated to a single VPN, 198 although it may support multiple VPNs if each one has separate 199 attachment circuits. The CE devices can be routers, bridges, 200 switches, or hosts. 202 Provider Edge (PE) Device: Equipment managed by the SP that can 203 support multiple VPNs for different customers, and is directly 204 connected to one or more CE devices via attachment circuits. A PE 205 is usually located at an SP point of presence (PoP) and is managed 206 by the SP. 208 Virtual Private LAN Service (VPLS): A VPLS is a provider service 209 that emulates the full functionality of a traditional Local Area 210 Network (LAN). A VPLS makes it possible to interconnect several 211 LAN segments over a packet switched network (PSN) and makes the 212 remote LAN segments behave as one single LAN. 214 Virtual Private Wire Service (VPWS): A VPWS is a point-to-point 215 circuit (i.e., link) connecting two CE devices. The link is 216 established as a logical through a packet switched network. The 217 CE in the customer network is connected to a PE in the provider 218 network via an Attachment Circuit (AC); the AC is either a 219 physical or a logical circuit. A VPWS differs from a VPLS in that 220 the VPLS is point-to-multipoint, while the VPWS is point-to-point. 221 In some implementations, a set of VPWSs is used to create a multi- 222 site L2VPN network. 224 3. The Layer 2 VPN Service Model 226 A Layer 2 VPN service is a collection of sites that are authorized to 227 exchange traffic between each other over a shared infrastructure of a 228 common technology. This Layer 2 VPN service model (L2SM) provides a 229 common understanding of how the corresponding Layer 2 VPN service is 230 to be deployed over the shared infrastructure. 232 This document presents the L2SM using the YANG data modeling language 233 [RFC6020] as a formal language that is both human-readable and 234 parsable by software for use with protocols such as NETCONF [RFC6241] 235 and RESTCONF [I-D.ietf-netconf-restconf]. 237 This service model is limited to VPWS and VPLS based VPNs as 238 described in [RFC4761] and [RFC6624]. 240 3.1. Applicability of the Layer 2 VPN Service Model 242 The L2SM defined in this document applies to both point-to-point 243 (E-Line) and multipoint-to-multipoint (E-LAN) carrier Ethernet 244 services. 246 Over the past decade, Metro Ethernet Forum (MEF) has published a 247 series of technical specifications of Ethernet virtual circuit 248 service attributes and implementation agreements between providers. 249 Many Ethernet VPN service providers worldwide have adopted these MEF 250 standards and developed backoffice tools accordingly. 252 Rather than introducing a new set of terminologies, the L2SM will 253 align with existing MEF attributes when it's applicable. Therefore, 254 service providers can easily integrate any new application that 255 leverages the L2SM data, Service Orchestrator for example, with 256 existing BSS/OSS toolsets. Service providers also have the option to 257 generate L2SM data for current L2VPN customer circuits already 258 deployed in the network. 260 3.2. Layer 2 VPN Service Types 262 A Layer 2 VPN circuit can be port-based; in which case any service 263 frames received from subscriber within contractual bandwidth will be 264 delivered to the corresponding remote site, regardless of customer 265 VLAN value (C-tag) of the incoming frame. The service frames can 266 also be native Ethernet frames without C-tag. In this scenario, only 267 one Ethernet Virtual Circuit (EVC) is allowed on a single provider to 268 subscriber link. 270 Contrary to the above use case, incoming customer service frames may 271 be split into multiple EVCs based on pre-arrangement between the 272 service provider and customer. Typically, C-tag of the incoming 273 frames will serve as the service delimiter for EVC multiplexing over 274 the same provider to subscriber interconnection. 276 Combining the service-multiplexing attribute with point-to-point 277 verses multipoint-to-multipoint connection type, a Layer 2 VPN 278 circuit may fall under one of the following service types: 280 o E-Line services: Point-to-Point Layer 2 connections. 282 EPL: In its simplest form, a port-based Ethernet Private Line 283 (EPL) service provides a high degree of transparency delivering 284 all customer service frames between UNI-to-UNI interfaces using 285 All-to-One Bundling. All unicast/broadcast/multicast packets 286 are delivered unconditionally over the EVC. No service 287 multiplexing is allowed on an EPL UNI interface. 289 EVPL: On the other hand, Ethernet Virtual Private Line (EVPL) 290 service supports multiplexing more than one Point-to-Point, or 291 even other virtual private services, on the same UNI interface. 292 Ingress service frames are conditionally transmitted through 293 one of the EVCs based upon pre-agreed C-tag to EVC mapping. 294 EVPL supports multiple C-tags to one EVC bundling. 296 o E-LAN services: Multipoint-to-Multipoint Layer 2 connections. 298 EP-LAN: Ethernet Private LAN Service (EP-LAN) transparently 299 connects multiple subscriber sites together with All-to-One 300 Bundling. No service multiplexing is allowed on an EP-LAN UNI 301 interface. 303 EVP-LAN: Some subscriber may desire more sophisticated control of 304 data access between multiple sites. Ethernet Virtual Private 305 LAN Service (EVP-LAN) allows connecting to multiple EVCs from 306 one or more of the UNI interfaces. Services frame disposition 307 is based on C-tag to EVC mapping. EVP-LAN supports multiple 308 C-tags to one EVC bundling. 310 3.3. Layer 2 VPN Service Network Topology 312 Figure 1depicts a typical service provider's physical network 313 topology. Most service providers have deployed an IP, MPLS, or 314 Segment Routing (SR) multi-service core infrastructure. Customer 315 Edge (CE) devices are placed at customer premises as demarcation 316 points to backhaul in profile service frames from the subscriber over 317 the access network to the Provider Edge (PE) equipment. The actual 318 transport technology or physical topology between CE and PE is 319 outside the scope of the L2SM model. 321 --- ---- --- 322 | | | | | | 323 | C +---+ CE | | C | 324 | | | | --------- | | 325 --- ----\ ( ) /--- 326 \ ---- ( ) ---- ---- / 327 \| | ( ) | | | |/ 328 | PE +---+ IP/MPLS/SR +---+ PE +---+ CE | 329 /| | ( Network ) | | | |\ 330 / ---- ( ) ---- ---- \ 331 --- ----/ ( ) \--- 332 | | | | ----+---- | | 333 | C +---+ CE | | | C | 334 | | | | --+-- | | 335 --- ---- | PE | --- 336 --+-- 337 | 338 --+-- 339 | CE | 340 --+-- 341 | 342 --+-- 343 | C | 344 ----- 346 Figure 1: Reference Network for the Use of the L2VPN Service Model 348 From the subscriber perspective, however, all the edge networks 349 devices are connected over a simulated LAN environment as shown in 350 Figure 2. Broadcast and multicast packets are sent to all 351 participants in the same bridge domain. 353 C---+----+---+---C 354 | | | 355 | | | 356 | | | 357 C---+ C +---C 359 Figure 2: Customer View of the L2VPN 361 3.4. Layer 2 VPN Ethernet Virtual Circuit Construct 363 The base model of EVC is shown in Figure 3. 365 Subscriber edge network device (C) connects to the service provider's 366 CE equipment. The link between C and CE devices is referred as User 367 Network Interface (UNI). For clarification, this is called UNI-C on 368 subscriber side and UNI-N on provider side. 370 The service provider is obligated to deliver the original service 371 frame across the network to the remote UNI-C. All Ethernet and IP 372 header information, including (but not limit to) source and 373 destination MAC addresses, EtherType, VLAN (C-tag), Class-of-Service 374 marking (802.1p or DSCP), etc. 376 In coming service frames are first examined at UNI-N based on C-tag, 377 Class-of-Services identifier, EtherType value. Conforming packets 378 are then metered against the contractual service bandwidth. In- 379 profile packets will be delivered to the remote UNI via the Ethernet 380 Virtual Circuit (EVC), which spans between UNI-N to UNI-N. 382 When both CEs are located in the same provider's network, a single 383 operator maintains the EVC. In this case, the EVC consists only one 384 Operator Virtual Circuit (OVC). 386 Typically, the CE device at customer premises is a layer 2 Ethernet 387 switch or NID. Service provider may choose to impose an outer VLAN 388 tag (S-tag) into the received subscriber traffic following 802.1ad 389 Q-in-Q standard, especially when Layer 2 aggregation devices exist 390 between CE and PE. 392 The uplink from CE to PE is referred as Internal Network-to-Network 393 Interface (I-NNI). When 802.1ad Q-in-Q is implemented, Ethernet 394 frames from CE to PE are double tagged with both provider and 395 subscriber VLANs (S-tag, C-tag). 397 Most service providers have deployed MPLS or SR multi-service core 398 infrastructure. Ingress service frames will be mapped to either 399 Ethernet Pseudowire (PWE) or VxLAN tunnel PE-to-PE. The details of 400 these tunneling mechanism are at the provider's discretion and not 401 part of the L2SM. 403 Service provider may also choose Seamless MPLS approach to expand the 404 PWE or VxLAN tunnel between UNI-N to UNI-N. 406 Service provider may leverage multi-protocol BGP to auto discover and 407 signal the PWE or VxLAN tunnel end points. 409 EVC 410 :<-------------------------------------------->: 411 : : 412 : : 413 : OVC (Optional) : 414 :<-------------------------------------------->: 415 : : 416 : : 417 : PW / VXLAN : 418 : :<-------------------------->: : 419 : : : : 420 : : : : 421 : : -------- : : 422 : : ( ) : : 423 --- ---- ---- ( ) ---- ---- --- 424 | | | | | | ( ) | | | | | | 425 | C +---+ CE +---+ PE +---+ IP/MPLS/SR +---+ PE +---+ CE +---+ C | 426 | | | | | | ( Network ) | | | | | | 427 --- ---- ---- ( ) ---- ---- --- 428 ^ ^ : ( ) : : 429 : : : -------- : : 430 UNI-C UNI-N : : : 431 : : : : 432 :<------>:<-------------------------->:<------>: 433 802.1ad IP/MPLS/SR Domain 802.1ad 434 q-in-q q-in-q 436 Figure 3: Architectural Model for EVC over a Single Network 438 Nevertheless, the remote site may be outside of the provider's 439 service territory. In this case, the provider may partner with the 440 operator of another metro network to provider service to the off-net 441 location as shown in Figure 4. 443 The first provider owns the customer relationship, thus the end-to- 444 end EVC. The EVC is comprised of two or more OVCs. Partially of the 445 EVC is an OVC from local UNI-C to the inter-provider interface. The 446 provider will purchase an Ethernet Access (E-Access) OVC from the 447 second operator to deliver packet to the remote UNI-C. 449 The inter-connect between the two operators edge gateway (EG) devices 450 is defined as the External Network-to-Network Interface (E-NNI). 452 EVC 453 :<---------------------------------------------------->: 454 : : 455 : : 456 : OVC (Optional) : 457 :<----------------------->: : 458 : : : 459 : : : 460 : PW / VXLAN : : 461 : :<------------------>: : 462 : : : : 463 : : : : 464 : : ----- : ----- : 465 : : ( ) : ( ) : 466 - -- -- ( IP/ ) ---- ---- ( IP/ ) -- -- - 467 |C+-+CE+-+PE+--+ MPLS/ +--+Edge+--+Edge+--+ MPLS/ +--+PE+-+CE+-+C| 468 - -- -- ( SR ) |G/W | |G/W | ( SR ) -- -- - 469 ^ ^ : ( ) ---- ---- ( ) ^ 470 : : : ----- ^ ^ ----- : 471 UNI UNI : ENNI ENNI : 472 C N : : : : 473 : : : : Remote 474 :<->:<------------------>:<->: Customer 475 802.1ad IP/MPLS/SR 802.1ad Site 476 q-in-q Domain q-in-q 478 Figure 4: Architectural Model for EVC over Multiple Networks 480 4. Service Data Model Usage 482 The L2VPN service model provides an abstracted interface to request, 483 configure and manage the components of a L2VPN service. The model is 484 used by a customer who purchases connectivity and other services from 485 an SP to communicate with that SP. 487 A typical usage is for this model to be an input for an orchestration 488 layer that is responsible for translating it into configuration 489 commands for the network elements that deliver/enable the service. 490 The network elements may be routers, but also servers (like AAA) 491 necessary within the network. 493 The configuration of network elements may be done using the Command 494 Line Interface (CLI), or any other configuration (or "southbound") 495 interface such as NETCONF [RFC6241] in combination with device- 496 specific and protocol-specific YANG models. 498 This way of using the service model is illustrated in Figure 5 and 499 described in more detail in [I-D.wu-opsawg-service-model-explained]. 500 The usage of this service model is not limited to this example: it 501 can be used by any component of the management system, but not 502 directly by network elements. 504 The usage and structure of this model should be compared to the Layer 505 3 VPN service model defined in [I-D.ietf-l3sm-l3vpn-service-model]. 507 ---------------------------- 508 | Customer Service Requester | 509 ---------------------------- 510 | 511 L2VPN | 512 Service | 513 Model | 514 | 515 ----------------------- 516 | Service Orchestration | 517 ----------------------- 518 | 519 | Service +-------------+ 520 | Delivery +------>| Application | 521 | Model | | BSS/OSS | 522 | V +-------------+ 523 ----------------------- 524 | Network Orchestration | 525 ----------------------- 526 | | 527 +----------------+ | 528 | Config manager | | 529 +----------------+ | Device 530 | | Models 531 | | 532 -------------------------------------------- 533 Network 535 Figure 5: Reference Architecture for the Use of the L2VPN Service 536 Model 538 Additionally, this data model can be compared with the service 539 delivery models described in [I-D.ietf-bess-l2vpn-yang] and 540 [I-D.ietf-bess-evpn-yang] as discussed in Section 6. 542 5. Design of the Data Model 544 The YANG module is divided in three main containers : customer-info, 545 vpn-services, and sites. 547 The customer-info defines global parameters for a specific customer. 549 The vpn-svc container under vpn-services defines global parameters 550 for the VPN service for a specific customer. 552 A site is composed of at least one uni-site or one enni-site. 554 Authorization of traffic exchange is done through what we call a VPN 555 policy or VPN topology defining routing exchange rules between sites. 557 The figure below describe the overall structure of the YANG module: 559 module: ietf-l2svc 561 module: ietf-l2vpn-svc 562 +--rw l2vpn-svc 563 +--rw customer-info 564 | +--rw customer-info* [customer-account-number customer-name] 565 | +--rw customer-account-number uint32 566 | +--rw customer-name string 567 | +--rw customer-operation-center 568 | +--rw customer-noc-street-address? string 569 | +--rw customer-noc-phone-number 570 | +--rw main-phone-num? uint32 571 | +--rw extension-options? uint32 572 +--rw vpn-services 573 | +--rw vpn-svc* [svc-id] 574 | +--rw svc-id string 575 | +--rw svc-type 576 | | +--rw evc 577 | | | +--rw evc-id? boolean 578 | | | +--rw max-number-of-pe? uint32 579 | | | +--rw max-number-of-site? uint32 580 | | +--rw ovc 581 | | +--rw on-net-ovc-id? boolean 582 | | +--rw off-net-ov-id? boolean 583 | +--rw ethernet-svc-type 584 | | +--rw (ethernet-svc-type)? 585 | | +--:(e-line) 586 | | | +--rw epl? boolean 587 | | | +--rw evpl? boolean 588 | | +--:(e-lan) 589 | | | +--rw ep-lan? boolean 590 | | | +--rw evp-lan? boolean 591 | | +--:(e-access) 592 | | +--rw access-epl? boolean 593 | | +--rw access-evpl? boolean 594 | +--rw metro-network-id 595 | | +--rw inter-mkt-service? boolean 596 | | +--rw intra-mkt* [metro-mkt-id mkt-name] 597 | | +--rw metro-mkt-id uint32 598 | | +--rw mkt-name string 599 | +--rw signaling-option 600 | | +--rw signaling-option* [name type] 601 | | +--rw name string 602 | | +--rw type identityref 603 | | +--rw mp-bgp-l2vpn 604 | | | +--rw vpn-id? string 605 | | | +--rw type? identityref 606 | | +--rw mp-bgp-evpn 607 | | | +--rw vpn-id? string 608 | | | +--rw type? identityref 609 | | +--rw t-ldp-pwe 610 | | | +--rw PE-EG-list* [service-ip-lo-addr vc-id] 611 | | | +--rw service-ip-lo-addr inet:ip-address 612 | | | +--rw vc-id string 613 | | +--rw pwe-encapsulation-type 614 | | | +--rw ethernet? boolean 615 | | | +--rw vlan? boolean 616 | | +--rw pwe-mtu 617 | | | +--rw allow-mtu-mismatch? boolean 618 | | +--rw control-word 619 | +--rw load-balance-options 620 | | +--rw fat-pw? boolean 621 | | +--rw entropy-label? boolean 622 | +--rw svlan-id-ethernet-tag? string 623 | +--rw cvlan-id-to-evc-map? string 624 | +--rw service-level-mac-limit? string 625 | +--rw service-protection 626 | +--rw protection-model 627 | +--rw peer-evc-id 628 +--rw site 629 +--rw uni-sites 630 | +--rw uni-site* [site-id] 631 | +--rw site-id string 632 | +--rw management 633 | | +--rw site-name? string 634 | | +--rw address? inet:ip-address 635 | | +--rw ce-device-info? string 636 | | +--rw type? identityref 637 | | +--rw management-transport? identityref 638 | +--rw location 639 | | +--rw address? string 640 | | +--rw zip-code? string 641 | | +--rw state? string 642 | | +--rw city? string 643 | | +--rw country-code? string 644 | +--rw site-diversity {site-diversity}? 645 | | +--rw groups 646 | | +--rw group* [group-id] 647 | | +--rw group-id string 648 | +--rw security 649 | +--rw signaling-option {signaling-option}? 650 | | +--rw signaling-option* [name type] 651 | | +--rw name string 652 | | +--rw type identityref 653 | | +--rw mp-bgp-l2vpn 654 | | | +--rw vpn-id? string 655 | | | +--rw type? identityref 656 | | +--rw mp-bgp-evpn 657 | | | +--rw vpn-id? string 658 | | | +--rw type? identityref 659 | | +--rw t-ldp-pwe 660 | | | +--rw PE-EG-list* [service-ip-lo-addr vc-id] 661 | | | +--rw service-ip-lo-addr inet:ip-address 662 | | | +--rw vc-id string 663 | | +--rw pwe-encapsulation-type 664 | | | +--rw ethernet? boolean 665 | | | +--rw vlan? boolean 666 | | +--rw pwe-mtu 667 | | | +--rw allow-mtu-mismatch? boolean 668 | | +--rw control-word 669 | +--rw load-balance-options 670 | | +--rw fat-pw? boolean 671 | | +--rw entropy-label? boolean 672 | | +--rw vxlan-source-port? string 673 | +--rw uni-ports 674 | +--rw uni-port* [uni-id] 675 | +--rw uni-id string 676 | +--rw groups 677 | | +--rw fate-sharing-group-size? uint16 678 | | +--rw group* [group-id] 679 | | +--rw group-id string 680 | +--rw bearer 681 | | +--rw phy-interface 682 | | | +--rw port-number? uint32 683 | | | +--rw port-speed? uint32 684 | | | +--rw auto-neg? string 685 | | | +--rw phy-mtu? uint32 686 | | | +--rw flow-control? string 687 | | | +--rw encapsulation-type? enumeration 688 | | | +--rw ethertype? string 689 | | | +--rw lldp? boolean 690 | | | +--rw oam-802.3AH-link {oam-3ah}? 691 | | | | +--rw enable? boolean 692 | | | +--rw uni-loop-prevention? boolean 693 | | +--rw LAG-interface 694 | | | +--rw LAG-interface* [LAG-interface-number] 695 | | | +--rw LAG-interface-number uint32 696 | | | +--rw LACP 697 | | | +--rw LACP-state? identityref 698 | | | +--rw LACP-mode? identityref 699 | | | +--rw LACP-speed? identityref 700 | | | +--rw mini-link? uint32 701 | | | +--rw system-priority? uint16 702 | | | +--rw Micro-BFD {Micro-BFD}? 703 | | | | +--rw Micro-BFD-on-off? enumeration 704 | | | | +--rw bfd-interval? uint32 705 | | | | +--rw bfd-hold-timer? uint32 706 | | | +--rw bfd {bfd}? 707 | | | | +--rw bfd-enabled? boolean 708 | | | | +--rw (holdtime)? 709 | | | | +--:(profile) 710 | | | | | +--rw profile-name? string 711 | | | | +--:(fixed) 712 | | | | +--rw fixed-value? uint32 713 | | | +--rw Member-link-list 714 | | | | +--rw member-link* [name] 715 | | | | +--rw name string 716 | | | | +--rw port-speed? uint32 717 | | | | +--rw auto-neg? string 718 | | | | +--rw mtu? uint32 719 | | | | +--rw oam-802.3AH-link {oam-3ah}? 720 | | | | +--rw enable? boolean 721 | | | +--rw flow-control? string 722 | | | +--rw encapsulation-type? enumeration 723 | | | +--rw ethertype? string 724 | | | +--rw lldp? boolean 725 | | +--rw interface-description? string 726 | | +--rw sub-if-id? uint32 727 | +--rw ethernet-connection 728 | | +--rw vlan 729 | | +--rw svlan-id-ethernet-tag? string 730 | +--rw evc-mtu? uint32 731 | +--rw mac-addr-limit 732 | | +--rw exceeding-option? uint32 733 | +--rw S-vlan 734 | | +--rw c-vlan2evc-mapping? string 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 822 +--rw enni-sites 823 +--rw enni-site* [site-id] 824 +--rw site-id string 825 +--rw location 826 | +--rw address? string 827 | +--rw zip-code? string 828 | +--rw state? string 829 | +--rw city? string 830 | +--rw country-code? string 831 +--rw site-diversity {site-diversity}? 832 | +--rw groups 833 | +--rw group* [group-id] 834 | +--rw group-id string 835 +--rw management 836 | +--rw site-name? string 837 | +--rw address? inet:ip-address 838 | +--rw Edge-Gateway-Device-Info? string 839 | +--rw type? identityref 840 | +--rw management-transport? identityref 841 +--rw security 842 +--rw service-protection 843 | +--rw protection-model 844 | +--rw peer-evc-id 845 +--rw signaling-option {signaling-option}? 846 | +--rw signaling-option* [name type] 847 | +--rw name string 848 | +--rw type identityref 849 | +--rw mp-bgp-l2vpn 850 | | +--rw vpn-id? string 851 | | +--rw type? identityref 852 | +--rw mp-bgp-evpn 853 | | +--rw vpn-id? string 854 | | +--rw type? identityref 855 | +--rw t-ldp-pwe 856 | | +--rw PE-EG-list* [service-ip-lo-addr vc-id] 857 | | +--rw service-ip-lo-addr inet:ip-address 858 | | +--rw vc-id string 859 | +--rw pwe-encapsulation-type 860 | | +--rw ethernet? boolean 861 | | +--rw vlan? boolean 862 | +--rw pwe-mtu 863 | | +--rw allow-mtu-mismatch? boolean 864 | +--rw control-word 865 +--rw load-balance-options 866 | +--rw fat-pw? boolean 867 | +--rw entropy-label? boolean 868 | +--rw vxlan-source-port? string 869 +--rw enni-ports 870 +--rw enni-port* [enni-id] 871 +--rw enni-id string 872 +--rw remote-carrier-name? string 873 +--rw bearer 874 | +--rw phy-interface 875 | | +--rw port-number? uint32 876 | | +--rw port-speed? uint32 877 | | +--rw auto-neg? string 878 | | +--rw phy-mtu? uint32 879 | | +--rw flow-control? string 880 | | +--rw encapsulation-type? enumeration 881 | | +--rw ethertype? string 882 | | +--rw lldp? boolean 883 | | +--rw oam-802.3AH-link {oam-3ah}? 884 | | | +--rw enable? boolean 885 | | +--rw uni-loop-prevention? boolean 886 | +--rw LAG-interface 887 | | +--rw LAG-interface* [LAG-interface-number] 888 | | +--rw LAG-interface-number uint32 889 | | +--rw LACP 890 | | +--rw LACP-state? identityref 891 | | +--rw LACP-mode? identityref 892 | | +--rw LACP-speed? identityref 893 | | +--rw mini-link? uint32 894 | | +--rw system-priority? uint16 895 | | +--rw Micro-BFD {Micro-BFD}? 896 | | | +--rw Micro-BFD-on-off? enumeration 897 | | | +--rw bfd-interval? uint32 898 | | | +--rw bfd-hold-timer? uint32 899 | | +--rw bfd {bfd}? 900 | | | +--rw bfd-enabled? boolean 901 | | | +--rw (holdtime)? 902 | | | +--:(profile) 903 | | | | +--rw profile-name? string 904 | | | +--:(fixed) 905 | | | +--rw fixed-value? uint32 906 | | +--rw Member-link-list 907 | | | +--rw member-link* [name] 908 | | | +--rw name string 909 | | | +--rw port-speed? uint32 910 | | | +--rw auto-neg? string 911 | | | +--rw mtu? uint32 912 | | | +--rw oam-802.3AH-link {oam-3ah}? 913 | | | +--rw enable? boolean 914 | | +--rw flow-control? string 915 | | +--rw encapsulation-type? enumeration 916 | | +--rw ethertype? string 917 | | +--rw lldp? boolean 918 | +--rw interface-description? string 919 | +--rw sub-if-id? uint32 920 +--rw ethernet-connection 921 | +--rw vlan 922 | +--rw svlan-id-ethernet-tag? string 923 +--rw evc-mtu? uint32 924 +--rw mac-addr-limit 925 | +--rw exceeding-option? uint32 926 +--rw S-vlan 927 | +--rw c-vlan2evc-mapping? string 928 +--rw multihoming 929 | +--rw multihoming* [ESI] 930 | +--rw ESI string 931 | +--rw (redundancy-mode)? 932 | +--:(single-active) 933 | | +--rw single-active? boolean 934 | +--:(all-active) 935 | +--rw all-active? boolean 936 +--rw L2CP-control 937 | +--rw stp-rstp-mstp? control-mode 938 | +--rw pause? control-mode 939 | +--rw lacp-lamp? control-mode 940 | +--rw link-oam? control-mode 941 | +--rw esmc? control-mode 942 | +--rw l2cp-802.1x? control-mode 943 | +--rw e-lmi? control-mode 944 | +--rw lldp? boolean 945 | +--rw ptp-peer-delay? control-mode 946 | +--rw garp-mrp? control-mode 947 | +--rw provider-bridge-group? yang:mac-address 948 | +--rw provider-bridge-mvrp? yang:mac-address 949 +--rw service 950 | +--rw svlan-id-ethernet-tag? string 951 | +--rw cvlan-id-to-evc-map? string 952 | +--rw service-level-mac-limit? string 953 | +--rw service-level 954 | +--rw cos-identifier? identityref 955 | +--rw color-identifier? identityref 956 | +--rw ingress-bw-profile-per-evc? string 957 | +--rw ingress-bw-profile-per-cos-id? string 958 | +--rw egress-bw-profile-per-evc? string 959 | +--rw egress-bw-profile-per-cos-id? string 960 | +--rw byte-offset? uint16 961 | +--rw policing? identityref 962 | +--rw performance-tier-option? identityref 963 | +--rw COS? uint32 964 +--rw B-U-M-strom-control 965 | +--rw BUM-overall-rate? uint32 966 | +--rw BUM-rate-per-type* [type] 967 | +--rw type identityref 968 | +--rw rate? uint32 969 +--rw mac-loop-prevention 970 | +--rw frequency? uint32 971 | +--rw protection-type? identityref 972 | +--rw number-retries? uint32 973 +--rw Ethernet-Service-OAM 974 | +--rw MD-name? string 975 | +--rw MD-level? uint8 976 | +--rw cfm-802.1-ag 977 | | +--rw n2-uni-c* [MAID] 978 | | | +--rw MAID string 979 | | | +--rw mep-id? uint32 980 | | | +--rw mep-level? uint32 981 | | | +--rw mep-up-down? enumeration 982 | | | +--rw remote-mep-id? uint32 983 | | | +--rw cos-for-cfm-pdus? uint32 984 | | | +--rw ccm-interval? uint32 985 | | | +--rw ccm-holdtime? uint32 986 | | | +--rw alarm-priority-defect? identityref 987 | | | +--rw ccm-p-bits-pri? ccm-priority-type 988 | | +--rw n2-uni-n* [MAID] 989 | | +--rw MAID string 990 | | +--rw mep-id? uint32 991 | | +--rw mep-level? uint32 992 | | +--rw mep-up-down? enumeration 993 | | +--rw remote-mep-id? uint32 994 | | +--rw cos-for-cfm-pdus? uint32 995 | | +--rw ccm-interval? uint32 996 | | +--rw ccm-holdtime? uint32 997 | | +--rw alarm-priority-defect? identityref 998 | | +--rw ccm-p-bits-pri? ccm-priority-type 999 | +--rw y-1731* [MAID] 1000 | +--rw MAID string 1001 | +--rw mep-id? uint32 1002 | +--rw type? identityref 1003 | +--rw remote-mep-id? uint32 1004 | +--rw message-period? uint32 1005 | +--rw measurement-interval? uint32 1006 | +--rw cos? uint32 1007 | +--rw loss-measurement? boolean 1008 | +--rw synthethic-loss-measurement? boolean 1009 | +--rw delay-measurement 1010 | | +--rw enable-dm? boolean 1011 | | +--rw two-way? boolean 1012 | +--rw frame-size? uint32 1013 | +--rw session-type? enumeration 1014 +--rw security 1016 Figure 6 1018 5.1. Overview of Main Components of the Model 1020 The L2SM model is structured in a way that allows the provider to 1021 list multiple circuits of various service types for the same 1022 subscriber. 1024 5.1.1. Customer Information 1026 The "customer-info" container contains essential information to 1027 identify the subscriber. 1029 "customer-account-number" is an internal alphanumerical number 1030 assigned by the service provider to identify the subscriber. It MUST 1031 be unique within the service provider?s OSS/BSS system. The actual 1032 format depends on the system tool the provider uses. "customer-name" 1033 is in more readable form. 1035 Subscriber operation center and main contact number are also listed 1036 here for reference purpose. 1038 5.1.2. VPN Service Overview 1040 The "svc-type" container contains two optional leaves: one for EVC 1041 (Ethernet Virtual Connection) and the other one for OVC (Operator 1042 Virtual Connection). These two parameters are not mutually 1043 exclusive. Depending on the service-type, a Layer 2 VPN service may 1044 be identified by EVC-ID, OVC-ID, or both. 1046 E-Line and E-LAN provider shall have EVC-ID assigned to the UNI-to- 1047 UNI circuit. If the service has remote UNIs in off-net partner's 1048 network, there will be one OVC-ID for the on-net segment between 1049 local UNI to the E-NNI interconnect, and one OVC-ID for each off-net 1050 segment from E-NNI to the remote UNI. E-Access, on the other hand, 1051 is OVC-based service. The E-Access service provider will assign OVC- 1052 ID for the circuit between UNI to E-NNI. 1054 The "svc-type" container can be augmented in the future to support 1055 other new technologies. Note that the "svc-id" should be 1056 corresponding to the "svc-type". 1058 5.1.2.1. Service Type 1060 The "svc-type" container contains two cases, one for EVC (Ethernet 1061 Virtual Connection), the other for OVC (Operator Virtual Connection). 1062 It can be used to indicate the type of service pipe type. The model 1063 user also can augment the "svc-type" container with other cases to 1064 support future technologies. Notes that the "svc-id" should be 1065 corresponding to the "svc-type". 1067 5.1.2.1.1. EVC 1069 The "evc"case contains an "evc-id" leaf with boolean type. The "evc- 1070 id" leaf will be marked TRUE for E-Line and E-LAN service types. And 1071 the "svc-id" will be associated with the "evc-id". Only one "evc-id" 1072 is allowed for each "svc-id". 1074 The EVC ID is intended to be a structured string. Each service 1075 provider can decide the nomenclature in its network. For example, 1076 many carriers in North American have implemented the COMMON LANGUAGE? 1077 Special Service Circuit Codes (CLCI S/S Codes) - Serial Number 1078 Format, which is defined in defined in ANSI ATIS-0300097. 1080 5.1.2.1.2. OVC 1082 The "ovc" case contains two boolean subcases: "on-net-ovc" and "off- 1083 net-ovc". 1085 For E-Access or services with off-net UNIs, the "on-net-ovc" leaf 1086 MUST be marked TRUE. And the "on-net-ovc-id" will be specified. 1088 In case of E-Access, the "svc-id" will be associated with the "on- 1089 net-ovc-id". Only one "on-net-ovc-id" is allowed for each "svc-id". 1091 If the service is E-Line or E-LAN with remote UNIs, there will be 1092 one, and only one, "on-net-ovc-id" and a list of "off-net-ovc-id"s 1093 for the remote UNIs. However, the "svc-id" is still associated with 1094 the "evc-id". Only one "evc-id" is allowed for each "svc-id". New 1095 ovc type could be added by augmentation. 1097 5.1.2.2. ethernet-svc-type 1099 The "ethernet-svc-type" group contains all supported Ethernet service 1100 types. One, and only one, "ethernet-svc-type" must be selected for 1101 each "svc-id". 1103 The current supported Ethernet service types are listed in 1104 Section 3.2. New service types can be added in the future. 1106 5.1.2.3. Metro Network Partition 1108 Some service providers may divide their network into multiple 1109 administrative domains. And a Layer 2 VPN service may span across 1110 more than one metro network of the same service provider. The 1111 optional "metro-network-id" container is intended be used by these 1112 multi-domain providers to differentiate intra-market versus inter- 1113 market services. 1115 When the "inter-mkt-service" leaf is marked TRUE, multiple associated 1116 "metro-mkt-id"s will be listed. Otherwise, the service is intra- 1117 domain and only one "metro-mkt-id" is allowed. 1119 5.1.2.4. vpn-signaling-option 1121 The "signaling-option" container captures service-wide attributes of 1122 the L2VPN instance. 1124 Although topology discovery or network device configurations is 1125 purposely out-scoped from the L2SM model, certain VPN parameters are 1126 listed here nevertheless. The information here can then be passed to 1127 other elements in the whole automation eco-system, such as the 1128 configuration engine, which will handle the actual service 1129 provisioning function. 1131 The "signaling-option" list uses "name" and "type" combination as the 1132 key. The "name" leaf is a free-form string of the VPN instance name. 1133 The "type" leaf is for the signaling protocol: BGP-L2VPN, BGP-EVPN, 1134 or T-LDP. 1136 5.1.2.4.1. BGP L2VPN 1138 [RFC4761] and [RFC6624] describe the mechanism to auto-discover L2VPN 1139 VPLS/VPWS end points (CE-ID or VE-ID) and signal the label base and 1140 offset at the same time to allow remote PE to derive the VPN label to 1141 be used when sending packets to the advertising router. 1143 Due to the auto-discovery natural, PEs that have at least one 1144 attachment circuit associated with a particular VPN service do not 1145 need to be specified explicitly. 1147 In the L2SM model, only the target community (or communities) will be 1148 listed at the service level. 1150 The "type" leaf under "mp-bgp-l2vpn" is an identityref to specify 1151 "vpws" or "vpls" sub-types. 1153 5.1.2.4.2. BGP EVPN 1155 Defined in [RFC7432], EVPN is a new promising L2VPN technology based 1156 upon BGP MAC routing. It's considered the next generation L2VPN 1157 solution that provides similar functionality of BGP VPWS/VPLS with 1158 improvement around redundancy, multicast optimization, provisioning 1159 and simplicity. 1161 Due to the auto-discovery natural, PEs that have at least one 1162 attachment circuit associated with a particular VPN service do not 1163 need to be specified explicitly. 1165 In the L2SM model, only the target community (or communities) will be 1166 listed at the service level. 1168 The "type" leaf under "mp-bgp-evpn" is an identityref to specify 1169 "vpws" or "vpls" sub-types. 1171 5.1.2.4.3. LDP Pseudowires 1173 [RFC4762] specified the method of using targeted LDP sessions between 1174 PEs to exchange VC label information. This requires a manually 1175 define a full mesh of targeted LDP sessions between all PEs. 1177 As multiple attachment circuits may terminate on a single PE, this 1178 PE-to-PE mesh is not a per site attribute. All PEs related to the 1179 L2VPN service will be listed in the "t-ldp-pwe" with associated "vc- 1180 id". 1182 5.1.2.4.4. PWE Encapsulation Type 1184 Based on [RFC4448], there are two types of Ethernet services: "Port- 1185 to-Port Ethernet PW emulation" and "Vlan-to-Vlan Ethernet PW 1186 emulation", commonly referred to as Type 5 and Type 4 respectively. 1187 This concept applies to both BGP L2VPN VPWS/VPLS and T-LDP signaled 1188 PWE implementations. 1190 The "pwe-encapsulation-type" container contains two Boolean type 1191 leaves: "ethernet" and "ethernet-vlan", only one should be marked 1192 TRUE if "signaling-option" is "mp-bgp-l2vpn" or "t-ldp-pwe". 1194 5.1.2.4.5. PWE MTU 1196 During the signaling process of BGP-l2VPN or T-LDP pseudowire, the 1197 pwe-mtu value is exchanged and must match on both ends. By default, 1198 the pwe-mtu is derived from physical interface MTU of the attachment 1199 circuit minus the EoMPLS transport header. In some cases, however, 1200 the physical interface on both ends of the circuits may not have 1201 identical MTU settings. For example, due to 802.1ad q-in-q 1202 operation, I-NNI interface will need extra four bytes to accommodate 1203 the S-tag. The inter-carrier E-NNI link may also have a different 1204 MTU size then the internal network interfaces. 1206 [RFC4448] requires same MTU size on physical interface on both end of 1207 the pseudowire. In actual implementations, many router vendors have 1208 provided the knob to explicitly specify the pwe-mtu, which can then 1209 be decoupled from the physical interface MTU. 1211 When there's a mismatch between the physical interface MTU and 1212 configured pwe-mtu, "allow-mtu-mismatch" knob is also required in 1213 many cases. 1215 The optional "pwe-mtu" container is for this purpose. 1217 5.1.2.4.6. Control Word 1219 A control word is an optional 4-byte field located between the MPLS 1220 label stack and the Layer 2 payload in the pseudowire packet. It 1221 plays a vital role in Any Transport over MPLS (AToM). The 32-bit 1222 field carries generic and Layer 2 payload-specific information, 1223 including a C-bit which indicates whether the control word will 1224 present in the Ethernet over MPLS (EoMPLS) packets. If the C-bit is 1225 set to 1, the advertising PE expects the control word to be present 1226 in every pseudowire packet on the pseudowire that is being signaled. 1227 If the C-bit is set to 0, no control word is expected to be present. 1229 Whether to include control word in the pseudowire packets MUST match 1230 on PEs at both ends of the pseudowire and it's non-negotiable during 1231 the signaling process. 1233 Control-word applies to both BGP L2VPN VPWS/VPLS and T-LDP signaled 1234 PWE implementations. It is a routing-instance level configuration in 1235 many cases. 1237 The optional "control-word" leaf is a Boolean field in the L2SM model 1238 for the provider to explicitly specify whether control-word will be 1239 signaled for the service instance. 1241 5.1.2.5. Load Balance Option 1243 As the subscribers start to deploy more 10G or 100G Ethernet 1244 equipment in their network, the demand for high bandwidth Ethernet 1245 services increases. Along with the great revenue opportunities, 1246 these high bandwidth service requests also pose challenges on 1247 capacity planning and service delivery in the provider's network. 1248 Especially when the contractual bandwidth is at, or close to, the 1249 speed of physical link of the service provider's core network. 1250 Because of the encapsulation overhead, the provider can not deliver 1251 the throughput in the service level agreement over a single link. 1252 Although there may be bundled Nx10G or Nx100G aggregation links 1253 between core network elements, or Equal Cost Multiple Paths (ECMP) in 1254 the network, an EoMPLS PWE or VxLAN circuit is considered a single 1255 flow to a router or switch which uses the five tuples in the hashing 1256 algorithm. 1258 Without burdening the core routers with additional processing of deep 1259 inspection into the payload, the service provider now have the option 1260 of inserting flow or entropy label into the EoMPLS frames, or using 1261 different source UDP ports in case of VxLAN/EVPN, at ingress PE to 1262 facility load-balancing on the subsequent nodes along the path. The 1263 ingress PE is in a unique position to see the actual unencapsulated 1264 service frames and identify data flows based on the original Ethernet 1265 and IP header. 1267 On the other hand, not all Layer 2 Ethernet VPNs is suited for load- 1268 balancing across diverse ECMP paths. For example, a Layer 2 Ethernet 1269 service transported over a single RSVP signaled LSP will not take 1270 multiple ECMP paths. Or if the subscriber is concerned about 1271 latency/jitter then diverse path load-balance can be undesirable. 1273 The optional "load-balance-option" container is intended to capture 1274 the load-balance agreement between the subscriber and provider. If 1275 the "load-balance" Boolean leaf is marked TRUE, then one of the 1276 following load-balance methods can be selected: "fat-pw", "entropy- 1277 label", or "vxland-source-udp-port". 1279 5.1.2.6. SVLAN ID Ethernet Tag 1281 Service providers have the option of inserting an outer VLAN tag (the 1282 S-tag) into the service frames from the subscriber to improve service 1283 scalability and customer VLAN transparency. 1285 Ideally, all external interfaces (UNI and E-NNI) associated with a 1286 given service will have the same S-tag assigned. However, this may 1287 not always be the case. Traffic with all attachments using different 1288 S-tags will need to be "normalized" to a single service S-tag. (One 1289 example of this is a multipoint service involves multiple off-net 1290 OVCs terminating on the same E-NNI interface. Each of these off-net 1291 OVCs will have a distinct S-tag, which can be different from the 1292 S-tag used in the on-net part of the service.) 1294 The purpose of the optional "svlan-id-ethernet-tag" leaf is to 1295 identify the service-wide "normalized S-tag". 1297 5.1.2.7. CVLAN ID To EVC MAP 1299 When more than one services are multiplexed on the same UNI 1300 interface, ingress service frames are conditionally transmitted 1301 through one of the EVC/OVCs based upon pre-arranged customer VLAN to 1302 EVC mapping. Multiple customer VLANs can be bundled across the same 1303 EVC. 1305 "cvlan-id-to-evc-map", when applicable, contains the list of customer 1306 vlans to the service mapping in a free-form format. In most cases, 1307 this will be the VLAN access-list for the inner 802.1q tags (the 1308 C-tag). 1310 5.1.2.8. Service Level MAC Limit 1312 When multiple services are provided on the same network element, MAC 1313 address table, and RIB space for MAC-routes in case of EVPN, are 1314 shared common resource. Service providers may impose a maximum 1315 number of MAC learned from the subscriber for a single service 1316 instance, and specify the action when the upper limit is violated: 1317 drop the packet, flood the packet, or simply send a warning log 1318 message. 1320 For point-to-point services, if MAC learning is disabled then MAC 1321 limit is not necessary in this kind of implementation. 1323 The optional "service-level-mac-limit" container contains the 1324 subscriber MAC address limit and exceeding action information. 1326 5.1.2.9. Service Protection 1328 Sometimes the subscriber may desire end-to-end protection at the 1329 service level for applications with high availability requirements. 1330 There are two protection schemes to offer redundant services: 1332 o 1+1 protection: In this scheme, the primary EVC or OVC will be 1333 protected by a backup EVC or OVC, typically meet certain 1334 diversified path/fiber/site/node criteria. Both primary and 1335 protection circuits are provisioning to be in forwarding state. 1336 Subscriber may choose to send the same service frames across both 1337 circuits simultaneously. 1339 o 1:1 protection: In this scheme, a backup circuit can be 1340 provisioning to the primary circuits. Depending on the 1341 implementation agreement, the protection circuits may either 1342 always be in forwarding state, or only become active when 1343 detecting a faulty state or the primary circuit. 1345 The optional "service-protection" container hereby is to capture the 1346 desired service protection agreement between subscriber and provider. 1348 An "peer-evc-id" should be specified when the "protection-model" has 1349 value. 1351 5.1.3. site 1353 The "site" container is intended for the provider to store 1354 information of detailed implementation arrangement with either the 1355 subscriber or peer operators at each inter-connect location. 1357 We are restricting the L2SM to exterior interfaces only. All 1358 internal interfaces or the underlying topology is outside the scope 1359 of L2SM. 1361 There are possibly two types of external facing connections 1362 associated with an Ethernet VPN service: 1364 o UNI site: where a customer edge device connects to one or more VPN 1365 services. 1367 o E-NNI site: where two Ethernet service providers inter-connect 1368 with each other. 1370 These two kinds of site are presented in the L2SM model. For each 1371 site, there are sub-containers to maintain physical link attributes, 1372 service frame and Layer 2 control protocol frame disposition, 1373 Ethernet service OAM attributes, and service bandwidth profile and 1374 priority level agreement. 1376 5.1.3.1. uni-site 1378 The User Network Interface (UNI) is the physical demarcation point 1379 between the service provider and subscriber. 1381 Typically, the following characteristics of the UNI handoff needs to 1382 be documented as part of the service design: 1384 Unique identifier (site-id) : An arbitrary string to uniquely 1385 identify the site within the overall network infrastructure. The 1386 format of site-id is determined by the local administration of the 1387 VPN service. 1389 Location (location) : The site location information to allow easy 1390 retrieval on nearest available resources. 1392 Site diversity (site-diversity) : Presents some parameters to 1393 support site diversity. 1395 Management (management) : Defines the model of management of the 1396 site, for example: type, management-transport, address. 1398 UNI ports (uni-ports) : Defines the list of uni-ports to the sites 1399 and their properties. 1401 5.1.3.1.1. Site ID 1403 The "site-id" leaf contains an arbitrary string to uniquely identify 1404 the site within the overall network infrastructure. The format of 1405 the site-id is determined by the local administration of the VPN 1406 service. 1408 5.1.3.1.2. Site Management 1410 The "management" sub-container is intended for site management 1411 options, depending on the device ownership and security access 1412 control. The followings are three common management models: 1414 ce-provider-managed : The provider has the sole ownership of the CE 1415 device. Only the provider has access to the CE. The 1416 responsibility boundary between SP and customer is between CE and 1417 customer network. This is the most common use case. 1419 ce-customer-managed : The customer has the sole ownershop of the CE 1420 device. Only the customer has access to the CE. In this model, 1421 the responsibility boundary between SP and customer is between PE 1422 and CE. 1424 ce-co-managed : The provider has ownership of the CE device and 1425 responsible for managing the CE. However, the provider grant the 1426 customer accessing the CE for some configuration/monitoring 1427 purpose. In this co-managed mode the responsibility boundary is 1428 the same as the provider-managed model. 1430 The selected management mode is specified under the "type" leaf. The 1431 "address" leaf stores CE device management IP information. And " 1432 management-transport" leaf is used to identify the transport protocol 1433 for management traffic, IPv4 or IPv6. Additional security options 1434 MAY be derived based on the particular management model selected. 1436 5.1.3.1.3. Site Location 1438 The information in the "location" sub-container under a uni-site 1439 allows easy retrieval on nearest available facility for access 1440 topology planning. It may also be used by other network 1441 orchestration component to decide the targeted upstream PE. 1443 5.1.3.1.4. Site Diversity 1445 Some subscriber may request upstream PE diversity between two or more 1446 sites. These sites will share the same diversity group ID under the 1447 optional "site-diversity" sub-container. 1449 5.1.3.1.5. Site Security 1451 This sub-container is s placeholder for site-security options. It 1452 presents parameters for ingress service stream admission control and 1453 encryption profile information. 1455 5.1.3.1.6. Site Signaling Option 1457 See Section 5.1.2.4 1459 5.1.3.1.7. UNI Ports 1461 The L2SM includes a set of essential physical interface properties 1462 and Ethernet layer characteristics in the uni-port sub-container. 1463 Some of these are critical implementation arrangements that require 1464 consent from both subscriber and provider. 1466 5.1.3.1.7.1. UNI ID 1468 "uni-id" is an freeform string to identify a given UNI interface. 1469 Service provider can decide on the actual nomenclature used in the 1470 management systems. 1472 5.1.3.1.7.2. Bearer 1474 Under uni-port, there is a bearer container that presents two sets of 1475 link attributes: physical or optional LAG interface attributes. 1476 These parameters are essential for the connection between subscriber 1477 and provider edge devices to establish properly. 1479 For each physical interface, there're basic configuration parameters 1480 like port number and speed, interface face MTU, auto-negotiation and 1481 flow-control settings, etc. "encapsulation-type" is for user to 1482 select between Ethernet encapsulation (port-based) or Ethernet VLAN 1483 encapsulation (VLAN-based). All allowed ethertypes of ingress 1484 service frames can be listed under "ethertype". In addition, the 1485 subscriber and provider may decide to enable advanced features, such 1486 as lldp, 802.3AH link OAM, MAC loop detection/prevention, based on 1487 mutual agreement. 1489 Sometimes the subscriber may require multiple physical links bundled 1490 together to form single logical point-to-point LAG connection to the 1491 service provider. Typically, LACP (Link Aggregation Control 1492 Protocol) is used to dynamically manage adding or deleting member 1493 links of the aggregate group. In general, LAG allows for increased 1494 service bandwidth beyond the speed of a single physical link while 1495 providing graceful degradation as failure occurs, thus increased 1496 availability. 1498 In the L2SM, there is a set of attributes under "LAG-interface" 1499 related to link aggregation functionality. The subscriber and 1500 provider first need to decide on whether LACP PDU will be exchanged 1501 between the edge device by specifying the "LACP-state" to "On" or 1502 "Off". If LACP is to be enabled, then both parties need to further 1503 specify whether it will be running in active versus passive mode, 1504 plus the time interval and priority level of the LACP PDU. 1505 Subscriber and provider can also determine the minimum aggregate 1506 bandwidth for a LAG group to be considered valid path by specifying 1507 the optional "mini-link" attribute. To enable fast detection of 1508 faulty links, Micro-BFD runs independent UDP sessions to monitor the 1509 status of each member link. Subscriber and provider should consent 1510 to the BFD hello interval and holdtime. 1512 Each member link will be listed under the LAG interface with basic 1513 physical link properties. Certain attributes like flow-control, 1514 encapsulation type, allowed ingress ethertype and LLDP settings are 1515 at the LAG level. 1517 If the Ethernet service is enabled on a logical unit on the UNI-N to 1518 UNI-C connection, the "sub-if-id" should be specified. 1520 5.1.3.1.7.3. Ethernet Connection 1522 The "Ethernet-connection" container presents site specific (S-tag, 1523 C-tag) management options. The overall S-tag for the Ethernet 1524 circuit and C-tag to EVC mapping, if applicable, has been placed in 1525 the service container. The S-tag under UNI-port should match the 1526 S-tag in service container in most cases. However, vlan translation 1527 is required for the S-tag in certain deployment at the external 1528 facing interface or upstream PEs to "normalize" the outer VLAN tag to 1529 the service S-tag into the network and translate back to the UNI-site 1530 S-tag in the opposite direction. One example of this is, with Layer 1531 2 aggregation switch alone the path, the S-tag for the EVC has been 1532 previously assigned to another service thus can not be used by this 1533 attachment circuit. Another use case is when multiple E-access OVCs 1534 from the same E-NNI interfaces are attached to the same E-LAN 1535 service. 1537 The "svlan-id-ethernet-tag" in the "Ethernet-connection" container is 1538 either the S-tag inserted at a UNI or the outer tag of ingress 1539 packets at an E-NNI. These parameters are included in the L2SM to 1540 facilitate other management system to generate proper configuration 1541 for the network elements. 1543 "Ethernet-connection" container also contains optional site-specific 1544 C-tag to EVC mapping. 1546 5.1.3.1.7.4. Port-wide Ethernet OAM 1548 ***TBD*** Need text? 1550 5.1.3.1.7.5. EVC MTU 1552 The maximum MTU of subscriber service frames can be derived from the 1553 physical interface MTU by default, or specified under the "evc-mtu" 1554 leaf if it is different than the default number. 1556 5.1.3.1.7.6. MAC Address Limit 1558 The service provider may choose to impose a per attachment circuit 1559 "mac-addr-limit" in addition to the service-lever MAC limit, and 1560 specify the exceeding options accordingly. 1562 5.1.3.1.7.7. Multihoming 1564 EVPN supports PE geo-redundancy in the access domain. The connection 1565 between a multi-homed CE to PE is identified with a uniquely assigned 1566 ID referred as ESI (Ethernet Segment Identifier). Because of learned 1567 MAC address is propagated via BGP, it allows for multiple active 1568 paths in forwarding state and load-balancing options. 1570 The "multihoming" container contains ESI and redundancy mode 1571 attribute for EVPN multi-homing site. 1573 5.1.3.1.7.8. UNI L2CP-Control 1575 To facilitate interoperability between different MSOs, MEF has 1576 provided normative guidance on Layer 2 control protocol (L2CP) 1577 processing requirements for each service type. Subscriber and 1578 provider should make pre-arrangement on whether to allow interaction 1579 between the edge device or keep each others control plane separate on 1580 a per protocol base. 1582 The destination MAC addresses of these L2CP PDUs fall within two 1583 reserved blocks specified by IEEE 802.1 Working Group. Packet with 1584 destination MAC in these multicast ranges has special forwarding 1585 rules. 1587 o Bridge Block of Protocols: 01-80-C2-00-00-00 through 1588 01-80-C2-00-00-0F 1590 o MRP Block of Protocols: 01-80-C2-00-00-20 through 1591 01-80-C2-00-00-2F 1593 Layer 2 protocol tunneling allows service providers to pass 1594 subscriber Layer 2 control PDUs across the network without being 1595 interpreted and processed by intermediate network devices. These 1596 L2CP PDUs are transparently encapsulated across the MPLS-enabled core 1597 network in Q-in-Q fashion. 1599 The "L2CP-control" container contains the list of commonly used L2CP 1600 protocols. Service provider can specify DISCARD, PEER or TUNNEL 1601 action for each individual protocol. 1603 In addition, "provider-bridge-group" and "provider-bridge-mvrp" 1604 addresses are also listed in the L2CP container. 1606 5.1.3.1.7.9. Service Profile 1608 In MEF 23.1 ([MEF-23-1]) two types of model are defined as the 1609 following: 1611 Class-of-Service Identifier based on EVC or OVC EP (End Point): In 1612 this model, regardless of customer marking, all in-profile frames 1613 will be marked with service level in contractual agreement. 1614 Customer CoS markings are preserved throughout the provider 1615 network. The bandwidth profile consists of one set of CIR/CBS and 1616 EIR/EBS values. 1618 Class-of-Service Identifier based on Priority Code Point: Using this 1619 model, multiple classes of services can be associated with a 1620 single customer EVC, identified by dot1p bits in the C-tag. Each 1621 service level has its own individual bandwidth profile. Out-of- 1622 profile packets will be discarded. Customer CoS markings are 1623 preserved. 1625 Class-of-Service Identifier based on DSCP: Using this model, 1626 multiple classes of services can be associated with a single 1627 customer EVC, identified by DSCP bits in the IP header. Each 1628 service level has its own individual bandwidth profile. Out-of- 1629 profile packets will be discarded. Customer CoS markings are 1630 preserved. 1632 Similarly, Color-identifier can be assigned based on EVC or OVC EP, 1633 dot1p value in C-tag, or DSCP in IP header. Ingress service frames 1634 are metered against the bandwidth profile based on the cos- 1635 identifier. A "color" will be assigned to a service frame to 1636 identify its bandwidth profile conformance. A service frame is 1637 "green" if it is conformant with "committed" rate of the bandwidth 1638 profile. A Service Frame is "yellow" if it is exceeding the 1639 "committed" rate but conformant with the "excess" rate of the 1640 bandwidth profile. Finally, a service frame is "red" if it is 1641 conformant with neither the "committed" nor "excess" rates of the 1642 bandwidth profile. 1644 Ingress/egress-bandwidth-profile-per-evc presents the ingress/egress 1645 bandwidth profile per EVC, providing rate enforcement for all ingress 1646 service frames at the UNI that are associated with a particular EVC. 1648 Alternately, ingress/egress-bandwidth-profile-per-cos-id presents the 1649 ingress/egress bandwidth profile per CoS, providing rate enforcement 1650 for all service frames for a given class of service. The class of 1651 service is identified via a CoS identifier. So this bandwidth 1652 profile applies to service frames over an EVC with a particular CoS 1653 value. Multiple ingress/egress-bandwidth-profile-per-cos-id can be 1654 associated with the same EVC. 1656 The optional "byte-offset" indicates how many bytes in the service 1657 frame header are excluded from rate enforcement. 1659 5.1.3.1.7.10. BUM Strom Control 1661 For point-to-point E-LINE services, the provider only needs to 1662 deliver a single copy of each service frame to the remote PE, 1663 regardless whether the destination MAC address of the incoming frame 1664 is unicast, multicast or broadcast. Therefore, all in-profile 1665 service frames should be delivered unconditionally. 1667 B-U-M (Broadcast-UnknownUnicast-Multicast) frame forwording in 1668 multipoint-to-multipoint services, on the other hand, involves both 1669 local flooding to other attachment circuits on the same PE and remote 1670 replication to all other PEs, thus consumes additional resources and 1671 core bandwidth. Special B-U-M frame disposition rules can be 1672 implemented at external facing interfaces (UNI or E-NNI) to rate- 1673 limit the B-U-M frames, in term of number of packets per second or 1674 bits per second. 1676 The threshold can apply to all B-U-M traffic, or one for each 1677 category. 1679 5.1.3.1.7.11. MAC Loop Protection 1681 MAC address flapping between different physical ports typically 1682 indicates a bridge loop condition in the subscriber network. 1683 Misleading entries in the MAC cache table can cause service frames to 1684 circulate around the network indefinitely and saturate the links 1685 throughout the provider's network, affecting other services in the 1686 same network. In case of EVPN, it also introduces massive BGP 1687 updates and control plane instability. 1689 Service provider may opt to implement switching loop prevention 1690 mechanism at the external facing interfaces for multipoint-to- 1691 multipoint services by imposing a MAC address move threshold. 1693 The MAC move rate and prevention-type options are listed in the "mac- 1694 loop-prevention" container. 1696 5.1.3.1.7.12. Ethernet Service OAM 1698 The advent of Ethernet as wide-area network technology brings 1699 additional requirements of end-to-end service monitoring and fault 1700 management in the carrier network, particularly in the area of 1701 service availability and Mean Time To Repair (MTTR). Ethernet 1702 Service OAM in the L2SM refers to the combined protocol suites of 1703 IEEE 802.1ag ([IEEE-802-1ag]) and ITU-T Y.1731 ([ITU-T-Y-1731]). 1705 Generally speaking, Ethernet Service OAM enables service provider to 1706 perform service continuity check, fault-isolation, and packet delay/ 1707 jitter measurement at per customer per EVC granularity. The 1708 information collected from Ethernet Service OAM datasets is 1709 complementary to other higher layer IP/MPLS OSS tools to ensure the 1710 required service level agreements (SLAs) can be meet. 1712 The 802.1ag Connectivity Fault Management (CFM) functional model is 1713 structured with hierarchical maintenance domains (MD), each assigned 1714 a unique maintenance level. Higher level MD can be nested over lower 1715 level MD. However, the MD can not intersect. The scope of each MD 1716 can be solely within a subscriber's network, solely within the 1717 provider's network, interact between the subscriber-to-provider or 1718 provider-to-provider edge equipment, or tunnel over another 1719 provider's network. 1721 Depending on the use case scenario, one or more maintenance end point 1722 (MEP) can be placed on the external facing interface, sending CFM 1723 PDUs towards the core network (UP MEP) or downstream link (DOWN MEP). 1725 The "cfm-802.1-ag" sub-container under UNI-port currently presents 1726 two types of CFM maintenance association (MA): UP MEP for UNI-N to 1727 UNI-N MA and DOWN MEP for UNI-N to UNI-C MA. For each MA, user can 1728 define the maintenance domain ID (MAID), MEP level, MEP direction, 1729 remote MEP ID, CoS level of the CFM PDUs, Continuity Check Message 1730 (CCM) interval and holdtime, alarm priority defect, CCM priority- 1731 type, etc. 1733 ITU-T Y.1731 Performance Monitoring (PM) provides essential network 1734 telemetry information that includes the measurement of Ethernet 1735 service frame delay, frame delay variation, frame loss, and frame 1736 throughput. The delay/jitter measurement can be either one-way or 1737 two-way. Typically, a Y.1731 PM probe sends a small amount of 1738 synthetic frames along with service frames to measure the SLA 1739 parameters. 1741 The "y-1731" sub-container under UNI-port contains a set of 1742 parameters for use to define the PM probe information, including 1743 MAID, local and remote MEP-ID, PM PDU type, message period and 1744 measurement interval, CoS level of the PM PDUs, loss measurement by 1745 synthetic or service frame options, one-way or two-way delay 1746 measurement, PM frame size, and session type. 1748 5.1.3.2. enni-site 1750 5.1.3.2.1. Site Management 1752 5.1.3.2.2. Site Location 1754 5.1.3.2.3. Site Diversity 1756 5.1.3.2.4. Site Security 1758 5.1.3.2.5. Site Service 1760 5.1.3.2.6. Site Protection 1762 5.1.3.2.7. ENNI Signaling Options 1764 5.1.3.2.8. ENNI Port 1766 5.1.3.2.8.1. ENNI Bearer 1768 5.1.3.2.8.2. ENNI Multihoming 1770 5.1.3.2.8.3. ENNI L2CP Control 1771 5.1.3.2.8.4. ENNI Ethernet Service OAM 1773 6. Interaction with Other YANG Modules 1775 As expressed in Section 4, this service module is not intended to 1776 configure the network element, but is instantiated in a management 1777 system. 1779 The management system might follow modular design and comprise at 1780 least two different components: 1782 a. The component instantiating the service model (let's call it the 1783 service component) 1785 b. The component responsible for network element configuration 1786 (let's call it the configuration component) 1788 In some cases when the split is needed between the behavior and 1789 functions that a customer requests and the technology that the 1790 network operator has available to deliver the service [I-D.wu-opsawg- 1791 service-model-explained]. A new component can be separated out of 1792 the service component (let's call it the control component). This 1793 component is responsible for network-centric operation and is aware 1794 of many features such as topology, technology, and operator policy. 1795 As an optional component, it can use service model as input and is 1796 not required if the control component delegates its control 1797 operations to the configuration component. 1799 In Section 7 we provide some example of translation of service 1800 provisioning request to router configuration lines as an 1801 illustration. In the NETCONF/YANG ecosystem, it is expected that 1802 NETCONF and YANG will be used between the configuration component and 1803 network elements to configure the requested service on those 1804 elements. 1806 In this framework, it is expected that YANG models will be used for 1807 configuring service components on network elements. There will be a 1808 strong relationship between the abstracted view provided by this 1809 service model and the detailed configuration view that will be 1810 provided by specific configuration models for network elements such 1811 as those defined in [I-D.ietf-bess-l2vpn-yang] and 1812 [I-D.ietf-bess-evpn-yang]. Service components needing configuration 1813 on network elements in support of the service model defined in this 1814 document include: 1816 o VRF definition including VPN policy expression. 1818 o Physical interface. 1820 o Ethernet layer (VLAN ID). 1822 o QoS : classification, profiles, etc. 1824 o Routing protocols : support of configuration of all protocols 1825 listed in the document, as well as routing policies associated 1826 with these protocols. 1828 o Multicast Support. 1830 o Ethernet Service OAM Support. 1832 7. Service Model Usage Example 1834 *** TBD *** 1836 8. YANG Module 1838 file "ietf-l2vpn-svc@2016-09-29.yang" 1839 module ietf-l2vpn-svc { 1841 namespace "urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc"; 1843 prefix "l2svc"; 1845 import ietf-inet-types { 1846 prefix inet; 1847 } 1849 import ietf-yang-types { 1850 prefix yang; 1851 } 1853 organization 1854 "IETF L2SM Working Group."; 1856 contact 1857 "WG List: l3sm@ietf.org 1858 Editor: Bin_Wen@comcast.com"; 1860 description 1861 "The YANG module defines a generic service configuration 1862 model for Layer 2 VPN services common across all of the 1863 vendor implementations."; 1865 revision 2016-09-09{ 1866 description 1867 "Initial revision."; 1868 reference 1869 "draft-wen-l2sm-l2vpn-service-model-01.txt 1870 A YANG Data Model for L2VPN Service Delivery."; 1871 } 1873 /* Features */ 1875 feature oam-3ah { 1876 description 1877 "Enables support of oam 802.3ah"; 1878 } 1880 feature Micro-BFD { 1881 description 1882 "Enables support of Micro-BFD"; 1883 } 1885 feature bfd { 1886 description 1887 "Enables support of bfd"; 1888 } 1890 feature signaling-option { 1891 description 1892 "Enable support of signaling option"; 1893 } 1895 feature site-diversity { 1896 description 1897 "Enables support of site diversity constraints"; 1898 } 1900 feature encryption { 1901 description 1902 "Enables support of encryption"; 1903 } 1905 /* Typedefs */ 1907 typedef ccm-priority-type { 1908 type uint8 { 1909 range "0..7"; 1910 } 1911 description 1912 "A 3 bit priority value to be used in the VLAN tag, if present 1913 in the transmitted frame."; 1914 } 1916 typedef control-mode { 1917 type enumeration{ 1918 enum peer{ 1919 description 1920 "Peer mode"; 1921 } 1922 enum tunnel { 1923 description 1924 "Tunnel mode"; 1925 } 1926 enum discard { 1927 description 1928 "Discard mode"; 1929 } 1930 } 1931 description 1932 "Defining a type of the control mode"; 1933 } 1935 /* Identities */ 1937 identity color-id { 1938 description 1939 "Identity of color id"; 1940 } 1942 identity color-id-evc { 1943 base color-id; 1944 description 1945 "Identity of color id base on EVC"; 1946 } 1948 identity color-id-evc-cvlan { 1949 base color-id; 1950 description 1951 "Identity of color id base on EVC and CVLAN "; 1952 } 1954 identity cos-id { 1955 description 1956 "Identity of class of service id"; 1957 } 1959 identity cos-id-evc { 1960 base cos-id; 1961 description 1962 "Identity of cos id based on EVC"; 1963 } 1964 identity cos-id-ovc-ep { 1965 base cos-id; 1966 description 1967 "Identity of cos id based on OVC End Point"; 1968 } 1970 identity cos-id-evc-pcp { 1971 base cos-id; 1972 description 1973 "Identity of cos id based on EVC and PCP"; 1974 } 1976 identity cos-id-evc-dscp { 1977 base cos-id; 1978 description 1979 "Identity of cos id based on EVC and DSCP"; 1980 } 1982 identity performance-tier-option { 1983 description 1984 "Identity of performance tier option."; 1985 } 1987 identity metro { 1988 base performance-tier-option; 1989 description 1990 "Identity of metro"; 1991 } 1993 identity regional { 1994 base performance-tier-option; 1995 description 1996 "Identity of regional"; 1997 } 1999 identity continental { 2000 base performance-tier-option; 2001 description 2002 "Identity of continental"; 2003 } 2005 identity global { 2006 base performance-tier-option; 2007 description 2008 "Identity of global"; 2009 } 2011 identity policing { 2012 description 2013 "Identity of policing type"; 2014 } 2016 identity one-rate-two-color { 2017 base policing; 2018 description 2019 "Identity of one-rate, two-color (1R2C)"; 2020 } 2022 identity two-rate-three-color { 2023 base policing; 2024 description 2025 "Identity of two-rate, three-color (2R3C)"; 2026 } 2028 identity BUM-type { 2029 description 2030 "Identity of BUM type"; 2031 } 2033 identity broadcast { 2034 base BUM-type; 2035 description 2036 "Identity of broadcast"; 2037 } 2039 identity unicast { 2040 base BUM-type; 2041 description 2042 "Identity of unicast"; 2043 } 2045 identity multicast { 2046 base BUM-type; 2047 description 2048 "Identity of multicast"; 2049 } 2051 identity loop-prevention-type{ 2052 description 2053 "Identity of loop prevention"; 2054 } 2056 identity shut { 2057 base loop-prevention-type; 2058 description 2059 "Identity of shut protection"; 2061 } 2063 identity trap { 2064 base loop-prevention-type; 2065 description 2066 "Identity of trap protection"; 2067 } 2069 identity lacp-state { 2070 description 2071 "Identity of lacp state"; 2072 } 2074 identity lacp-on { 2075 base lacp-state; 2076 description 2077 "Identity of lacp on"; 2078 } 2080 identity lacp-off { 2081 base lacp-state; 2082 description 2083 "Identity of lacp off"; 2084 } 2086 identity lacp-mode { 2087 description 2088 "Identity of lacp mode"; 2089 } 2091 identity lacp-passive { 2092 base lacp-mode; 2093 description 2094 "Identity of lacp passive"; 2095 } 2097 identity lacp-active { 2098 base lacp-mode; 2099 description 2100 "Identity of lacp active"; 2101 } 2103 identity lacp-speed { 2104 description 2105 "Identity of lacp speed"; 2106 } 2108 identity lacp-fast { 2109 base lacp-speed; 2110 description 2111 "Identity of lacp fast"; 2112 } 2114 identity lacp-slow { 2115 base lacp-speed; 2116 description 2117 "Identity of lacp slow"; 2118 } 2120 identity vpn-signaling-type { 2121 description 2122 "Identity of vpn signaling types"; 2123 } 2125 identity vrf { 2126 base vpn-signaling-type; 2127 description 2128 "Virtual routing and forwarding (VRF)."; 2129 } 2131 identity vfi { 2132 base vpn-signaling-type; 2133 description 2134 "Virtual forwarder interface"; 2135 } 2137 identity evi { 2138 base vpn-signaling-type; 2139 description 2140 "Ethernet virtual interconnect."; 2141 } 2143 identity l2vpn-type { 2144 description 2145 "Layer 2 VPN types"; 2146 } 2148 identity vpws { 2149 base l2vpn-type; 2150 description 2151 "Virtual Private Wire Service"; 2152 } 2154 identity vpls { 2155 base l2vpn-type; 2156 description 2157 "Virtual Private LAN Service"; 2158 } 2160 identity evpn { 2161 base l2vpn-type; 2162 description 2163 "Ethernet VPN"; 2164 } 2166 identity management { 2167 description 2168 "Base identity for site management scheme."; 2169 } 2171 identity co-managed { 2172 base management; 2173 description 2174 "Base identity for comanaged site."; 2175 } 2177 identity customer-managed { 2178 base management; 2179 description 2180 "Base identity for customer managed site."; 2181 } 2183 identity provider-managed { 2184 base management; 2185 description 2186 "Base identity for provider managed site."; 2187 } 2189 identity address-family { 2190 description 2191 "Base identity for an address family."; 2192 } 2194 identity ipv4 { 2195 base address-family; 2196 description 2197 "Identity for IPv4 address family."; 2198 } 2200 identity ipv6 { 2201 base address-family; 2202 description 2203 "Identity for IPv6 address family."; 2204 } 2205 identity vpn-topology { 2206 description 2207 "Base identity for VPN topology."; 2208 } 2210 identity any-to-any { 2211 base vpn-topology; 2212 description 2213 "Identity for any to any VPN topology."; 2214 } 2216 identity hub-spoke { 2217 base vpn-topology; 2218 description 2219 "Identity for Hub'n'Spoke VPN topology."; 2220 } 2222 identity hub-spoke-disjoint { 2223 base vpn-topology; 2224 description 2225 "Identity for Hub'n'Spoke VPN topology 2226 where Hubs cannot talk between each other."; 2227 } 2229 identity site-role { 2230 description 2231 "Base identity for site type."; 2232 } 2234 identity any-to-any-role { 2235 base site-role; 2236 description 2237 "Site in an any to any IPVPN."; 2238 } 2240 identity spoke-role { 2241 base site-role; 2242 description 2243 "Spoke Site in a Hub & Spoke IPVPN."; 2244 } 2246 identity hub-role { 2247 base site-role; 2248 description 2249 "Hub Site in a Hub & Spoke IPVPN."; 2250 } 2252 identity pm-type { 2253 description 2254 "Performance monitor type"; 2255 } 2257 identity loss { 2258 base pm-type; 2259 description 2260 "Loss measurement"; 2261 } 2263 identity delay { 2264 base pm-type; 2265 description 2266 "Delay measurement"; 2267 } 2269 identity fault-alarm-defect-type { 2270 description 2271 "Indicating the alarm priority defect"; 2272 } 2274 identity remote-rdi { 2275 base fault-alarm-defect-type; 2276 description 2277 "Indicates the aggregate health of the remote MEPs."; 2278 } 2280 identity remote-mac-error { 2281 base fault-alarm-defect-type; 2282 description 2283 "Indicates that one or more of the remote MEPs is 2284 reporting a failure in its Port Status TLV or 2285 Interface Status TLV."; 2286 } 2288 identity remote-invalid-ccm { 2289 base fault-alarm-defect-type; 2290 description 2291 "Indicates that at least one of the Remote MEP 2292 state machines is not receiving valid CCMs 2293 from its remote MEP."; 2294 } 2296 identity invalid-ccm { 2297 base fault-alarm-defect-type; 2298 description 2299 "Indicates that one or more invalid CCMs has been 2300 received and that 3.5 times that CCMs transmission 2301 interval has not yet expired."; 2302 } 2304 identity cross-connect-ccm { 2305 base fault-alarm-defect-type; 2306 description 2307 "Indicates that one or more cross connect CCMs has been 2308 received and that 3.5 times of at least one of those 2309 CCMs transmission interval has not yet expired."; 2310 } 2312 /* Groupings */ 2314 grouping customer-info-grouping { 2315 list customer-info { 2316 key "customer-account-number customer-name"; 2317 leaf customer-account-number { 2318 type uint32; 2319 description 2320 "Customer account number"; 2321 } 2322 leaf customer-name { 2323 type string; 2324 description 2325 "Customer name"; 2326 } 2327 container customer-operation-center { 2328 leaf customer-noc-street-address { 2329 type string; 2330 description 2331 "Customer NOC street Address."; 2332 } 2333 container customer-noc-phone-number { 2334 leaf main-phone-num { 2335 type uint32; 2336 description 2337 "Main phone number."; 2338 } 2339 leaf extension-options { 2340 type uint32; 2341 description 2342 "Extension or options"; 2343 } 2345 description 2346 "Configuration of customer noc phone number"; 2347 } 2348 description 2349 "Configuration of customer operation center"; 2350 } 2351 description 2352 "List of customer information"; 2353 } 2354 description 2355 "Grouping for customer information"; 2356 } 2358 grouping site-management { 2359 container management { 2360 leaf site-name { 2361 type string; 2362 description 2363 "Site name"; 2364 } 2365 leaf address { 2366 type inet:ip-address; 2367 description 2368 "Address"; 2369 } 2370 leaf ce-device-info { 2371 type string; 2372 description 2373 "CE device info"; 2374 } 2375 leaf type { 2376 type identityref { 2377 base management; 2378 } 2379 description 2380 "Management type of the connection."; 2381 } 2382 leaf management-transport { 2383 type identityref { 2384 base address-family; 2385 } 2386 description 2387 "Transport protocol used for management."; 2388 } 2389 description 2390 "Management configuration"; 2391 } 2392 description 2393 "Management parameters for the site."; 2394 } 2396 grouping customer-location-info { 2397 container location { 2398 leaf address { 2399 type string; 2400 description 2401 "Address (number and street) of the site."; 2402 } 2403 leaf zip-code { 2404 type string; 2405 description 2406 "ZIP code of the site."; 2407 } 2408 leaf state { 2409 type string; 2410 description 2411 "State of the site. This leaf can also be used to 2412 describe a region for country who does not have 2413 states."; 2414 } 2415 leaf city { 2416 type string; 2417 description 2418 "City of the site."; 2419 } 2420 leaf country-code { 2421 type string; 2422 description 2423 "Country of the site."; 2424 } 2425 description 2426 "Location of the site."; 2427 } 2428 description 2429 "This grouping defines customer location parameters"; 2430 } 2432 grouping site-diversity { 2433 container site-diversity { 2434 if-feature site-diversity; 2435 container groups { 2436 list group { 2437 key group-id; 2438 leaf group-id { 2439 type string; 2440 description 2441 "Group-id the site is belonging to"; 2442 } 2443 description 2444 "List of group-id"; 2446 } 2447 description 2448 "Groups the site is belonging to. 2449 All site network accesses will inherit those group 2450 values."; 2451 } 2452 description 2453 "Diversity constraint type."; 2454 } 2455 description 2456 "This grouping defines site diversity parameters"; 2457 } 2459 grouping site-service{ 2460 leaf svlan-id-ethernet-tag { 2461 type string; 2462 description 2463 "SVLAN-ID/Ethernet Tag configurations"; 2464 } 2465 leaf cvlan-id-to-evc-map { 2466 type string; 2467 description 2468 "List of CVLAN-ID to EVC Map configurations"; 2469 } 2470 leaf service-level-mac-limit { 2471 type string; 2472 description 2473 "Service-level MAC-limit (E-LAN only)"; 2474 } 2475 description 2476 "This grouping defines site service parameters"; 2477 } 2479 grouping service-protection{ 2480 container service-protection { 2481 container protection-model { 2482 description 2483 "Container of protection model configurations"; 2484 } 2485 container peer-evc-id { 2486 description 2487 "Container of peer evc id configurations"; 2488 } 2489 description 2490 "Container of End-to-end Service Protection 2491 configurations"; 2492 } 2493 description 2494 "Grouping for service protection"; 2495 } 2497 grouping ethernet-service-type { 2498 choice ethernet-svc-type { 2499 case e-line { 2500 leaf epl { 2501 type boolean; 2502 description 2503 "Ethernet private line"; 2504 } 2505 leaf evpl { 2506 type boolean; 2507 description 2508 "Ethernet virtual private line"; 2509 } 2510 description 2511 "Case of e-line"; 2512 } 2514 case e-lan { 2515 leaf ep-lan { 2516 type boolean; 2517 description 2518 "Ethernet private LAN"; 2519 } 2520 leaf evp-lan { 2521 type boolean; 2522 description 2523 "Ethernet virtual private LAN"; 2524 } 2525 description 2526 "Case of e-lan"; 2527 } 2528 case e-access { 2529 leaf access-epl { 2530 type boolean; 2531 description 2532 "Access Ethernet virtual private line"; 2533 } 2534 leaf access-evpl { 2535 type boolean; 2536 description 2537 "Access Ethernet virtual private line"; 2538 } 2539 description 2540 "Case of e-access."; 2541 } 2542 description 2543 "Choice of Ethernet service type"; 2544 } 2545 description 2546 "Grouping for Ethernet service type."; 2547 } 2549 grouping signaling-option-grouping { 2550 list signaling-option { 2551 key "name type"; 2552 leaf name { 2553 type string; 2554 description 2555 "VRF/VFI/EVI Name"; 2556 } 2557 leaf type { 2558 type identityref { 2559 base vpn-signaling-type; 2560 } 2561 description 2562 "VPN signaling types"; 2563 } 2564 container mp-bgp-l2vpn { 2565 leaf vpn-id { 2566 type string; 2567 description 2568 "Identifies the target VPN"; 2569 } 2570 leaf type { 2571 type identityref { 2572 base l2vpn-type; 2573 } 2574 description 2575 "L2VPN types"; 2576 } 2577 description 2578 "Container for MP BGP l2VPN"; 2579 } 2581 container mp-bgp-evpn { 2582 leaf vpn-id { 2583 type string; 2584 description 2585 "Identifies the target VPN"; 2586 } 2587 leaf type { 2588 type identityref { 2589 base l2vpn-type; 2591 } 2592 description 2593 "L2VPN types"; 2594 } 2595 description 2596 "Container for MP BGP l2VPN"; 2597 } 2599 container t-ldp-pwe { 2600 list PE-EG-list { 2601 key "service-ip-lo-addr vc-id"; 2602 leaf service-ip-lo-addr { 2603 type inet:ip-address; 2604 description 2605 "Service ip lo address"; 2606 } 2607 leaf vc-id { 2608 type string; 2609 description 2610 "VC id"; 2611 } 2612 description 2613 "List of PE/EG"; 2614 } 2615 description 2616 "Container of T-LDP PWE configurations"; 2617 } 2619 container pwe-encapsulation-type { 2620 leaf ethernet { 2621 type boolean; 2622 description 2623 "Ethernet"; 2624 } 2625 leaf vlan { 2626 type boolean; 2627 description 2628 "VLAN"; 2629 } 2630 description 2631 "Container of PWE Encapsulation Type configurations"; 2632 } 2634 container pwe-mtu { 2635 leaf allow-mtu-mismatch { 2636 type boolean; 2637 description 2638 "Allow MTU mismatch"; 2640 } 2641 description 2642 "Container of PWE MTU configurations"; 2643 } 2645 container control-word { 2646 description 2647 "Container of control word configurations"; 2648 } 2650 description 2651 "List of VPN Signaling Option."; 2652 } 2654 description 2655 "Grouping for signaling option"; 2656 } 2658 grouping load-balance-grouping { 2659 leaf fat-pw { 2660 type boolean; 2661 description 2662 "Fat label is applied to Pseudowires across MPLS 2663 network"; 2664 } 2665 leaf entropy-label { 2666 type boolean; 2667 description 2668 "Entropy label is applied to IP forwarding, 2669 L2VPN or L3VPN across MPLS network"; 2670 } 2671 description 2672 "Grouping for load balance "; 2673 } 2675 grouping intra-mkt-grouping { 2676 list intra-mkt { 2677 key "metro-mkt-id mkt-name"; 2678 leaf metro-mkt-id { 2679 type uint32; 2680 description 2681 "Metro MKT ID"; 2682 } 2683 leaf mkt-name { 2684 type string; 2685 description 2686 "MKT Name"; 2687 } 2688 description 2689 "List of intra-MKT"; 2690 } 2691 description 2692 "Grouping for intra-MKT"; 2693 } 2695 grouping inter-mkt-service { 2696 leaf inter-mkt-service{ 2697 type boolean; 2698 description 2699 "Indicate whether service is inter market service."; 2700 } 2701 description 2702 "Grouping for inter-MKT service"; 2703 } 2705 grouping evc-id-grouping { 2706 leaf evc-id { 2707 type boolean; 2708 description 2709 "Ethernet Virtual Connection identifier"; 2710 } 2711 description 2712 "Grouping for EVC-ID"; 2713 } 2715 grouping svc-type-grouping { 2716 container svc-type { 2717 container evc { 2718 leaf evc-id { 2719 type boolean; 2720 description 2721 "Indicate whether the Ethernet virtual connection 2722 id support."; 2723 } 2724 leaf max-number-of-pe { 2725 type uint32; 2726 description 2727 "Maximum number of PEs supported per EVC."; 2728 } 2729 leaf max-number-of-site { 2730 type uint32; 2731 description 2732 "Maximum number of sites supported per EVC."; 2733 } 2734 description 2735 "Container for Ethernet virtual connection."; 2737 } 2738 container ovc { 2739 leaf on-net-ovc-id { 2740 type boolean; 2741 description 2742 "Indicate whether the on net OVC id support."; 2743 } 2744 leaf off-net-ov-id { 2745 type boolean; 2746 description 2747 "Indicate whether the off net OVC id support."; 2748 } 2749 description 2750 "Container for OVC"; 2751 } 2752 description 2753 "Container for service types."; 2754 } 2755 description 2756 "Grouping of service types."; 2757 } 2759 grouping cfm-802-grouping { 2761 leaf MAID { 2762 type string; 2763 description 2764 "MA ID"; 2765 } 2767 leaf mep-id { 2768 type uint32; 2769 description 2770 "Local MEP ID"; 2771 } 2773 leaf mep-level { 2774 type uint32; 2775 description 2776 "MEP level"; 2777 } 2779 leaf mep-up-down { 2780 type enumeration { 2781 enum up { 2782 description 2783 "MEP up"; 2784 } 2785 enum down { 2786 description 2787 "MEP down"; 2788 } 2789 } 2790 description 2791 "MEP up/down"; 2792 } 2794 leaf remote-mep-id { 2795 type uint32; 2796 description 2797 "Remote MEP ID"; 2798 } 2800 leaf cos-for-cfm-pdus { 2801 type uint32; 2802 description 2803 "COS for CFM PDUs"; 2804 } 2806 leaf ccm-interval { 2807 type uint32; 2808 description 2809 "CCM interval"; 2810 } 2812 leaf ccm-holdtime { 2813 type uint32; 2814 description 2815 "CCM hold time"; 2816 } 2818 leaf alarm-priority-defect { 2819 type identityref { 2820 base fault-alarm-defect-type; 2821 } 2822 description 2823 "The lowest priority defect that is 2824 allowed to generate a Fault Alarm. 2825 The non-existence of this leaf means 2826 that no defects are to be reported"; 2827 } 2829 leaf ccm-p-bits-pri { 2830 type ccm-priority-type; 2831 description 2832 "The priority parameter for CCMs transmitted by the MEP"; 2834 } 2836 description 2837 "Grouping for 802.1ag CFM attribute"; 2838 } 2840 grouping y-1731{ 2841 list y-1731 { 2842 key MAID; 2844 leaf MAID { 2845 type string; 2846 description 2847 "MA ID "; 2848 } 2850 leaf mep-id { 2851 type uint32; 2852 description 2853 "Local MEP ID"; 2854 } 2856 leaf type { 2857 type identityref { 2858 base pm-type; 2859 } 2860 description 2861 "Performance monitor types"; 2862 } 2864 leaf remote-mep-id { 2865 type uint32; 2866 description 2867 "Remote MEP ID"; 2868 } 2870 leaf message-period { 2871 type uint32; 2872 description 2873 "Defines the interval between OAM messages. The message 2874 period is expressed in milliseconds"; 2875 } 2877 leaf measurement-interval{ 2878 type uint32; 2879 description 2880 "Specifies the measurement interval for statistics. The 2881 measurement interval is expressed in seconds"; 2883 } 2885 leaf cos { 2886 type uint32; 2887 description 2888 "Class of service"; 2889 } 2891 leaf loss-measurement { 2892 type boolean; 2893 description 2894 "Whether enable loss measurement"; 2895 } 2897 leaf synthethic-loss-measurement { 2898 type boolean; 2899 description 2900 "Indicate whether enable synthetic loss measurement"; 2901 } 2903 container delay-measurement { 2904 leaf enable-dm { 2905 type boolean; 2906 description 2907 "Whether to enable delay measurement"; 2908 } 2909 leaf two-way { 2910 type boolean; 2911 description 2912 "Whether delay measurement is two-way (true) of one- 2913 way (false)"; 2914 } 2915 description 2916 "Container for delay measurement"; 2917 } 2919 leaf frame-size{ 2920 type uint32; 2921 description 2922 "Frame size"; 2923 } 2925 leaf session-type { 2926 type enumeration { 2927 enum proactive { 2928 description 2929 "Proactive mode"; 2930 } 2931 enum on-demand { 2932 description 2933 "On demand mode"; 2934 } 2935 } 2936 description 2937 "Session type"; 2938 } 2940 description 2941 "List for y-1731."; 2942 } 2943 description 2944 "Grouping for y.1731"; 2945 } 2947 grouping enni-site-info-grouping { 2948 container site-info { 2949 leaf site-name { 2950 type string; 2951 description 2952 "Site name"; 2953 } 2954 leaf address { 2955 type inet:ip-address; 2956 description 2957 "Address"; 2958 } 2959 leaf Edge-Gateway-Device-Info { 2960 type string; 2961 description 2962 "Edge Gateway Device Info "; 2963 } 2964 description 2965 "Container of site info configurations"; 2966 } 2967 description 2968 "Grouping for site information"; 2969 } 2971 grouping site-security { 2972 container security { 2973 description 2974 "Security parameters"; 2975 } 2976 description 2977 "This grouping defines security parameters for a site"; 2978 } 2979 grouping lacp-grouping { 2981 container LACP { 2982 leaf LACP-state { 2983 type identityref { 2984 base lacp-state; 2985 } 2986 description 2987 "LACP on/off"; 2988 } 2989 leaf LACP-mode { 2990 type identityref { 2991 base lacp-mode; 2992 } 2993 description 2994 "LACP mode"; 2995 } 2996 leaf LACP-speed { 2997 type identityref { 2998 base lacp-speed; 2999 } 3000 description 3001 "LACP speed"; 3002 } 3003 leaf mini-link { 3004 type uint32; 3005 description 3006 "Mini link"; 3007 } 3008 leaf system-priority { 3009 type uint16; 3010 description 3011 "Indicates the LACP priority for the system. 3012 The range is from 0 to 65535. 3013 The default is 32768."; 3014 } 3016 container Micro-BFD { 3017 if-feature Micro-BFD; 3018 leaf Micro-BFD-on-off { 3019 type enumeration { 3020 enum on { 3021 description 3022 "Micro-bfd on"; 3023 } 3024 enum off { 3025 description 3026 "Micro-bfd off"; 3028 } 3029 } 3030 description 3031 "Micro BFD ON/OFF"; 3032 } 3033 leaf bfd-interval { 3034 type uint32; 3035 description 3036 "BFD interval"; 3037 } 3038 leaf bfd-hold-timer { 3039 type uint32; 3040 description 3041 "BFD hold timer"; 3042 } 3043 description 3044 "Container of Micro-BFD configurations"; 3045 } 3047 container bfd { 3048 if-feature bfd; 3049 leaf bfd-enabled { 3050 type boolean; 3051 description 3052 "BFD activation"; 3053 } 3054 choice holdtime { 3055 case profile { 3056 leaf profile-name { 3057 type string; 3058 description 3059 "Service provider well 3060 known profile."; 3061 } 3062 description 3063 "Service provider well 3064 known profile."; 3065 } 3066 case fixed { 3067 leaf fixed-value { 3068 type uint32; 3069 units msec; 3070 description 3071 "Expected holdtime 3072 expressed in msec."; 3073 } 3074 } 3075 description 3076 "Choice for holdtime flavor."; 3077 } 3078 description 3079 "Container for BFD."; 3080 } 3082 container Member-link-list { 3083 list member-link { 3084 key "name"; 3085 leaf name { 3086 type string; 3087 description 3088 "Member link name"; 3089 } 3090 leaf port-speed { 3091 type uint32; 3092 description 3093 "Port speed"; 3094 } 3095 leaf auto-neg { 3096 type string; 3097 description 3098 "Auto neg"; 3099 } 3100 leaf mtu { 3101 type uint32; 3102 description 3103 "MTU"; 3104 } 3105 container oam-802.3AH-link{ 3106 if-feature oam-3ah; 3107 leaf enable { 3108 type boolean; 3109 description 3110 "Indicate whether support oam 802.3 ah 3111 link"; 3112 } 3113 description 3114 "Container for oam 802.3 ah link."; 3115 } 3116 description 3117 "Member link"; 3118 } 3119 description 3120 "Container of Member link list"; 3121 } 3123 leaf flow-control { 3124 type string; 3125 description 3126 "Flow control"; 3127 } 3129 leaf encapsulation-type { 3130 type enumeration { 3131 enum VLAN { 3132 description 3133 "VLAN"; 3134 } 3135 enum ether { 3136 description 3137 "Ethernet"; 3138 } 3139 } 3140 description 3141 "Encapsulation type"; 3142 } 3144 leaf ethertype { 3145 type string; 3146 description 3147 "Ether type"; 3148 } 3150 leaf lldp { 3151 type boolean; 3152 description 3153 "LLDP"; 3154 } 3156 description 3157 "LACP"; 3158 } 3160 description 3161 "Grouping for lacp"; 3162 } 3164 grouping phy-interface-grouping { 3165 container phy-interface { 3166 leaf port-number { 3167 type uint32; 3168 description 3169 "Port number"; 3170 } 3171 leaf port-speed { 3172 type uint32; 3173 description 3174 "Port speed"; 3175 } 3176 leaf auto-neg { 3177 type string; 3178 description 3179 "Auto neg"; 3180 } 3181 leaf phy-mtu { 3182 type uint32; 3183 description 3184 "PHY MTU"; 3185 } 3186 leaf flow-control { 3187 type string; 3188 description 3189 "Flow control"; 3190 } 3191 leaf encapsulation-type { 3192 type enumeration { 3193 enum VLAN { 3194 description 3195 "VLAN"; 3196 } 3197 enum Ethernet { 3198 description 3199 "Ethernet"; 3200 } 3201 } 3202 description 3203 "Encapsulation-type"; 3204 } 3205 leaf ethertype { 3206 type string; 3207 description 3208 "Ethertype"; 3209 } 3210 leaf lldp { 3211 type boolean; 3212 description 3213 "LLDP"; 3214 } 3215 container oam-802.3AH-link{ 3216 if-feature oam-3ah; 3217 leaf enable { 3218 type boolean; 3219 description 3220 "Indicate whether support oam 802.3 ah 3221 link"; 3222 } 3223 description 3224 "Container for oam 802.3 ah link."; 3225 } 3226 leaf uni-loop-prevention{ 3227 type boolean; 3228 description 3229 "If this leaf set to truth that the port automatically 3230 goes down when a physical loopback is detect."; 3231 } 3233 description 3234 "Container of PHY Interface Attributes configurations"; 3235 } 3236 description 3237 "Grouping for phy interface."; 3238 } 3240 grouping lag-interface-grouping{ 3241 container LAG-interface { 3242 list LAG-interface { 3243 key "LAG-interface-number"; 3244 leaf LAG-interface-number { 3245 type uint32; 3246 description 3247 "LAG interface number"; 3248 } 3249 uses lacp-grouping; 3250 description 3251 "List of LAG interfaces"; 3252 } 3253 description 3254 "Container of LAG interface attributes configuration"; 3255 } 3256 description 3257 "Grouping for LAG interface"; 3258 } 3260 grouping bearer-grouping { 3261 container bearer { 3262 uses phy-interface-grouping; 3263 uses lag-interface-grouping; 3265 leaf interface-description { 3266 type string; 3267 description 3268 "Interface description"; 3269 } 3270 leaf sub-if-id { 3271 type uint32; 3272 description 3273 "Sub-if id"; 3274 } 3276 description 3277 "Container for bearer"; 3278 } 3279 description 3280 "Grouping for bearer."; 3281 } 3283 grouping ethernet-connection-grouping { 3284 container ethernet-connection { 3285 container vlan { 3286 leaf svlan-id-ethernet-tag { 3287 type string; 3288 description 3289 "SVLAN-ID/Ethernet Tag configurations"; 3290 } 3291 description 3292 "Abstract container for VLAN"; 3293 } 3294 description 3295 "Container for Ethernet connection"; 3296 } 3297 description 3298 "Grouping for Ethernet connection"; 3299 } 3301 grouping evc-mtu-grouping { 3302 leaf evc-mtu { 3303 type uint32; 3304 description 3305 "EVC MTU"; 3306 } 3307 description 3308 "Grouping for evc mtu"; 3309 } 3311 grouping mac-addr-limit-grouping { 3312 container mac-addr-limit { 3313 leaf exceeding-option { 3314 type uint32; 3315 description 3316 "Exceeding option"; 3317 } 3318 description 3319 "Container of MAC-Addr limit configurations"; 3320 } 3321 description 3322 "Grouping for mac address limit"; 3323 } 3325 grouping s-vlan-grouping { 3326 container S-vlan { 3327 leaf c-vlan2evc-mapping { 3328 type string; 3329 description 3330 "C-VLAN to EVC mapping"; 3331 } 3332 description 3333 "Container of S-VLAN configurations"; 3334 } 3335 description 3336 "Grouping for s-vlan"; 3337 } 3339 grouping multihoming-grouping { 3340 container multihoming { 3341 list multihoming { 3342 key "ESI"; 3343 leaf ESI { 3344 type string; 3345 description 3346 "Ethernet segment id"; 3347 } 3348 choice redundancy-mode { 3349 case single-active { 3350 leaf single-active { 3351 type boolean; 3352 description 3353 "Single active"; 3354 } 3355 description 3356 "Single active case"; 3357 } 3358 case all-active { 3359 leaf all-active { 3360 type boolean; 3361 description 3362 "All active"; 3363 } 3364 description 3365 "All active case"; 3366 } 3367 description 3368 "Redundancy mode choice"; 3369 } 3370 description 3371 "List of multihomings"; 3372 } 3373 description 3374 "Container of multihoming optional configurations"; 3375 } 3376 description 3377 "Grouping for multihoming"; 3378 } 3380 grouping l2cp-grouping { 3381 container L2CP-control { 3382 leaf stp-rstp-mstp { 3383 type control-mode; 3384 description 3385 "STP/RSTP/MSTP"; 3386 } 3387 leaf pause { 3388 type control-mode; 3389 description 3390 "Pause"; 3391 } 3392 leaf lacp-lamp { 3393 type control-mode; 3394 description 3395 "LACP/LAMP"; 3396 } 3397 leaf link-oam { 3398 type control-mode; 3399 description 3400 "Link OAM"; 3401 } 3402 leaf esmc { 3403 type control-mode; 3404 description 3405 "ESMC"; 3406 } 3407 leaf l2cp-802.1x { 3408 type control-mode; 3409 description 3410 "802.x"; 3411 } 3412 leaf e-lmi { 3413 type control-mode; 3414 description 3415 "E-LMI"; 3416 } 3417 leaf lldp { 3418 type boolean; 3419 description 3420 "LLDP"; 3421 } 3422 leaf ptp-peer-delay { 3423 type control-mode; 3424 description 3425 "PTP peer delay"; 3426 } 3427 leaf garp-mrp { 3428 type control-mode; 3429 description 3430 "GARP/MARP"; 3431 } 3432 leaf provider-bridge-group { 3433 type yang:mac-address; 3434 description 3435 "Provider bridge group reserved MAC address 3436 01-80-C2-00-00-08"; 3437 } 3438 leaf provider-bridge-mvrp { 3439 type yang:mac-address; 3440 description 3441 "Provider bridge MVRP reserved MAC address 3442 01-80-C2-00-00-0D"; 3443 } 3444 description 3445 "Container of L2CP control configurations"; 3446 } 3447 description 3448 "Grouping for l2cp control"; 3449 } 3451 grouping service-level-grouping { 3452 container service-level { 3453 leaf cos-identifier { 3454 type identityref { 3455 base cos-id; 3456 } 3457 description 3458 "COS Identifier [ EVC | EVC + PCP ]"; 3459 } 3460 leaf color-identifier { 3461 type identityref { 3462 base color-id; 3463 } 3464 description 3465 "Color Identifier [ EVC | EVC + CVLAN ]"; 3466 } 3467 leaf ingress-bw-profile-per-evc { 3468 type string; 3469 description 3470 "Ingress Bandwidth Profile per EVC"; 3471 } 3472 leaf ingress-bw-profile-per-cos-id { 3473 type string; 3474 description 3475 "Ingress Bandwidth Profile per COS Identifier"; 3476 } 3477 leaf egress-bw-profile-per-evc { 3478 type string; 3479 description 3480 "Egress Bandwidth Profile per EVC"; 3481 } 3482 leaf egress-bw-profile-per-cos-id { 3483 type string; 3484 description 3485 "Egress Bandwidth Profile per COS Identifier"; 3486 } 3487 leaf byte-offset { 3488 type uint16; 3489 description 3490 "For not including extra VLAN tags in the QoS 3491 calculation"; 3492 } 3493 leaf policing { 3494 type identityref { 3495 base policing; 3496 } 3497 description 3498 "The policing can be either one-rate, 3499 two-color (1R2C) or two-rate, three-color (2R3C)"; 3500 } 3501 leaf performance-tier-option { 3502 type identityref { 3503 base performance-tier-option; 3504 } 3505 description 3506 "Performance tier option"; 3507 } 3508 leaf COS { 3509 type uint32; 3510 description 3511 "Class of Service"; 3512 } 3513 description 3514 "Container of service level configurations."; 3515 } 3516 description 3517 "Grouping for service level."; 3518 } 3520 grouping B-U-M-strom-control-grouping { 3521 container B-U-M-strom-control { 3522 leaf BUM-overall-rate { 3523 type uint32; 3524 description 3525 "overall rate for BUM"; 3526 } 3527 list BUM-rate-per-type { 3528 key "type"; 3529 leaf type { 3530 type identityref { 3531 base BUM-type; 3532 } 3533 description 3534 "BUM type"; 3535 } 3536 leaf rate { 3537 type uint32; 3538 description 3539 "Rate for BUM"; 3540 } 3541 description 3542 "List of rate per type"; 3543 } 3544 description 3545 "Container of B-U-M-strom-control configurations"; 3546 } 3547 description 3548 "Grouping for B-U-M-strom-control"; 3549 } 3551 grouping mac-loop-prevention-grouping { 3552 container mac-loop-prevention { 3553 leaf frequency { 3554 type uint32; 3555 description 3556 "Frequency"; 3557 } 3558 leaf protection-type { 3559 type identityref { 3560 base loop-prevention-type; 3561 } 3562 description 3563 "Protection type"; 3564 } 3565 leaf number-retries { 3566 type uint32; 3567 description 3568 "Number of retries"; 3569 } 3570 description 3571 "Container of MAC loop prevention."; 3572 } 3573 description 3574 "Grouping for MAC loop prevention"; 3575 } 3577 grouping ethernet-svc-oam-grouping { 3578 container Ethernet-Service-OAM { 3579 leaf MD-name { 3580 type string; 3581 description 3582 "Maintenance domain name"; 3583 } 3584 leaf MD-level { 3585 type uint8; 3586 description 3587 "Maintenance domain level"; 3588 } 3589 container cfm-802.1-ag { 3590 list n2-uni-c { 3591 key "MAID"; 3592 uses cfm-802-grouping; 3593 description 3594 "List of UNI-N to UNI-C"; 3595 } 3596 list n2-uni-n { 3597 key "MAID"; 3598 uses cfm-802-grouping; 3599 description 3600 "List of UNI-N to UNI-N"; 3601 } 3602 description 3603 "Container of 802.1ag CFM configurations."; 3605 } 3606 uses y-1731; 3607 description 3608 "Container for Ethernet service OAM."; 3609 } 3610 description 3611 "Grouping for Ethernet service OAM."; 3612 } 3614 grouping enni-management { 3615 container management { 3616 leaf site-name { 3617 type string; 3618 description 3619 "Site name"; 3620 } 3621 leaf address { 3622 type inet:ip-address; 3623 description 3624 "Address"; 3625 } 3626 leaf Edge-Gateway-Device-Info { 3627 type string; 3628 description 3629 "Edge Gateway Device Information."; 3630 } 3631 leaf type { 3632 type identityref { 3633 base management; 3634 } 3635 description 3636 "Management type of the connection."; 3637 } 3638 leaf management-transport { 3639 type identityref { 3640 base address-family; 3641 } 3642 description 3643 "Transport protocol used for management."; 3644 } 3645 description 3646 "Management configuration."; 3647 } 3648 description 3649 "Grouping for ENNI site management."; 3650 } 3652 grouping fate-sharing-group { 3653 container groups { 3654 leaf fate-sharing-group-size { 3655 type uint16; 3656 description 3657 "Fate sharing group size."; 3658 } 3659 list group { 3660 key group-id; 3661 leaf group-id { 3662 type string; 3663 description 3664 "Group-id the site network access 3665 is belonging to"; 3666 } 3667 description 3668 "List of group-id"; 3669 } 3670 description 3671 "Groups the fate sharing group member 3672 is belonging to"; 3673 } 3674 description 3675 "Grouping for Fate sharing group."; 3676 } 3678 /* MAIN L2VPN SERVICE */ 3680 container l2vpn-svc { 3682 /* CUSTOMER */ 3684 container customer-info { 3685 uses customer-info-grouping; 3686 description 3687 "Container of customer information configurations."; 3688 } 3690 /* SERVICE */ 3692 container vpn-services { 3693 list vpn-svc { 3694 key "svc-id"; 3695 leaf svc-id { 3696 type string; 3697 description 3698 "Defining a service id."; 3699 } 3700 uses svc-type-grouping; 3701 container ethernet-svc-type { 3702 uses ethernet-service-type; 3703 description 3704 "Container of Ethernet service type"; 3705 } 3706 container metro-network-id { 3707 uses inter-mkt-service; 3708 uses intra-mkt-grouping; 3709 description 3710 "Container of Metro-Network ID configurations"; 3711 } 3712 container signaling-option { 3713 uses signaling-option-grouping; 3714 description 3715 "Container for signaling option"; 3716 } 3717 container load-balance-options { 3718 uses load-balance-grouping; 3719 description 3720 "container for load balance options"; 3721 } 3722 uses site-service; 3723 uses service-protection; 3724 description 3725 "List of vpn-svc"; 3726 } 3727 description 3728 "Container of vpn-services configurations"; 3729 } 3731 /* SITE */ 3733 container site { 3734 container uni-sites { 3735 list uni-site { 3736 key "site-id"; 3737 leaf site-id { 3738 type string; 3739 description 3740 "Container of site id"; 3741 } 3742 uses site-management; 3743 uses customer-location-info; 3744 uses site-diversity; 3745 uses site-security; 3746 container signaling-option { 3747 if-feature signaling-option; 3748 uses signaling-option-grouping; 3749 description 3750 "Container for signaling option"; 3751 } 3753 container load-balance-options { 3754 uses load-balance-grouping; 3755 leaf vxlan-source-port { 3756 type string; 3757 description 3758 "Vxlan source port"; 3759 } 3760 description 3761 "Container for load balance options"; 3762 } 3764 container uni-ports { 3765 list uni-port { 3766 key "uni-id"; 3767 leaf uni-id { 3768 type string; 3769 description 3770 "UNI id"; 3771 } 3773 uses fate-sharing-group; 3774 uses bearer-grouping; 3775 uses ethernet-connection-grouping; 3776 uses evc-mtu-grouping; 3777 uses mac-addr-limit-grouping; 3778 uses s-vlan-grouping; 3779 uses multihoming-grouping; 3780 uses l2cp-grouping; 3782 container service { 3783 uses site-service; 3784 uses service-level-grouping; 3785 description 3786 "Container for site service."; 3787 } 3789 uses B-U-M-strom-control-grouping; 3790 uses mac-loop-prevention-grouping; 3791 uses ethernet-svc-oam-grouping; 3792 uses site-security; 3794 description 3795 "List of UNI ports"; 3796 } 3797 description 3798 "Container of UNI port configurations"; 3799 } 3800 description 3801 "List of UNI sites"; 3802 } 3803 description 3804 "Container of UNI site configurations"; 3805 } 3807 container enni-sites { 3808 list enni-site { 3809 key "site-id"; 3810 leaf site-id { 3811 type string; 3812 description 3813 "Container of site id"; 3814 } 3816 uses customer-location-info; 3817 uses site-diversity; 3818 uses enni-management; 3819 uses site-security; 3820 uses service-protection; 3822 container signaling-option { 3823 if-feature signaling-option; 3824 uses signaling-option-grouping; 3825 description 3826 "Container for signaling option"; 3827 } 3829 container load-balance-options { 3830 uses load-balance-grouping; 3831 leaf vxlan-source-port { 3832 type string; 3833 description 3834 "Vxlan source port"; 3835 } 3836 description 3837 "Container for load balance options"; 3838 } 3840 container enni-ports { 3841 list enni-port { 3842 key "enni-id"; 3843 leaf enni-id { 3844 type string; 3845 description 3846 "ENNI id"; 3847 } 3848 leaf remote-carrier-name{ 3849 type string; 3850 description 3851 "Remote carrier name"; 3852 } 3854 uses bearer-grouping; 3855 uses ethernet-connection-grouping; 3856 uses evc-mtu-grouping; 3857 uses mac-addr-limit-grouping; 3858 uses s-vlan-grouping; 3859 uses multihoming-grouping; 3860 uses l2cp-grouping; 3862 container service{ 3863 uses site-service; 3864 uses service-level-grouping; 3865 description 3866 "Container for site service."; 3867 } 3869 uses B-U-M-strom-control-grouping; 3870 uses mac-loop-prevention-grouping; 3871 uses ethernet-svc-oam-grouping; 3872 uses site-security; 3874 description 3875 "List of ENNI ports"; 3876 } 3877 description 3878 "Container of ENNI port configurations"; 3879 } 3880 description 3881 "List of ENNI sites"; 3882 } 3883 description 3884 "Container of ENNI site configurations"; 3885 } 3886 description 3887 "Container for site configurations"; 3888 } 3889 description 3890 "Container of l2vpn-svc configurations"; 3891 } 3892 } 3893 3895 9. Security Considerations 3897 The YANG modules defined in this document MAY be accessed via the 3898 RESTCONF protocol [I-D.ietf-netconf-restconf] or NETCONF protocol 3899 ([RFC6241]. The lowest RESTCONF or NETCONF layer requires that the 3900 transport-layer protocol provides both data integrity and 3901 confidentiality, see Section 2 in [I-D.ietf-netconf-restconf] and 3902 [RFC6241]. The client MUST carefully examine the certificate 3903 presented by the server to determine if it meets the client's 3904 expectations, and the server MUST authenticate client access to any 3905 protected resource. The client identity derived from the 3906 authentication mechanism used is subject to the NETCONF Access 3907 Control Module (NACM) ([RFC6536]). Other protocols to access this 3908 YANG module are also required to support the similar mechanism. 3910 The data nodes defined in the "ietf-l2vpn-svc" YANG module MUST be 3911 carefully created/read/updated/deleted. The entries in the lists 3912 below include customer proprietary or confidential information, 3913 therefore only authorized clients MUST access the information and the 3914 other clients MUST NOT be able to access to the information. 3916 o /l2vpn-svc/vpn-services/vpn-svc 3918 o /l2vpn-svc/sites/uni-site 3920 o /l2vpn-svc/sites/enni-site 3922 10. Acknowledgements 3924 Thanks to Qin Wu and Adrian Farrel for facilitating work on the 3925 initial revision of this document. 3927 This document has drawn on the work of the L3SM Working Group 3928 expressed in [I-D.ietf-l3sm-l3vpn-service-model]. 3930 11. IANA Considerations 3932 IANA is requested to assign a new URI from the IETF XML registry 3933 ([RFC3688]). The following URI is suggested: 3935 URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc 3936 Registrant Contact: L2SM WG 3937 XML: N/A, the requested URI is an XML namespace 3939 This document also requests a new YANG module name in the YANG Module 3940 Names registry ([RFC6020]) with the following suggestion: 3942 name: ietf-l2vpn-svc 3943 namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc 3944 prefix: l2vpn-svc 3945 reference: RFC XXXX 3947 12. References 3949 12.1. Normative References 3951 [I-D.ietf-netconf-restconf] 3952 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3953 Protocol", draft-ietf-netconf-restconf-17 (work in 3954 progress), September 2016. 3956 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3957 Requirement Levels", BCP 14, RFC 2119, 3958 DOI 10.17487/RFC2119, March 1997, 3959 . 3961 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3962 DOI 10.17487/RFC3688, January 2004, 3963 . 3965 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 3966 "Encapsulation Methods for Transport of Ethernet over MPLS 3967 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 3968 . 3970 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 3971 LAN Service (VPLS) Using BGP for Auto-Discovery and 3972 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 3973 . 3975 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 3976 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 3977 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 3978 . 3980 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 3981 the Network Configuration Protocol (NETCONF)", RFC 6020, 3982 DOI 10.17487/RFC6020, October 2010, 3983 . 3985 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3986 and A. Bierman, Ed., "Network Configuration Protocol 3987 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3988 . 3990 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 3991 Protocol (NETCONF) Access Control Model", RFC 6536, 3992 DOI 10.17487/RFC6536, March 2012, 3993 . 3995 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 3996 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 3997 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 3998 2015, . 4000 12.2. Informative References 4002 [I-D.ietf-bess-evpn-yang] 4003 Brissette, P., Sajassi, A., Shah, H., Li, Z., 4004 Tiruveedhula, K., Hussain, I., and J. Rabadan, "Yang Data 4005 Model for EVPN", draft-ietf-bess-evpn-yang-01 (work in 4006 progress), July 2016. 4008 [I-D.ietf-bess-l2vpn-yang] 4009 Shah, H., Brissette, P., Chen, I., Hussain, I., and B. 4010 Wen, "YANG Data Model for MPLS-based L2VPN", draft-ietf- 4011 bess-l2vpn-yang-00 (work in progress), June 2016. 4013 [I-D.ietf-l3sm-l3vpn-service-model] 4014 Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 4015 Model for L3VPN service delivery", draft-ietf-l3sm-l3vpn- 4016 service-model-16 (work in progress), September 2016. 4018 [I-D.wu-opsawg-service-model-explained] 4019 Wu, Q., LIU, S., and A. Farrel, "Service Models 4020 Explained", draft-wu-opsawg-service-model-explained-03 4021 (work in progress), September 2016. 4023 [IEEE-802-1ag] 4024 IEEE, "802.1ag - Connectivity Fault Management", December 4025 2007. 4027 [ITU-T-Y-1731] 4028 ITU-T, "Recommendation Y.1731 - OAM functions and 4029 mechanisms for Ethernet based networks", February 2008. 4031 [MEF-23-1] 4032 MEF Forum, "Implementation Agreement MEF 23.1 : Carrier 4033 Ethernet Class of Service - Phase 2", January 2012. 4035 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 4036 Virtual Private Networks Using BGP for Auto-Discovery and 4037 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 4038 . 4040 Authors' Addresses 4042 Bin Wen 4043 Comcast 4045 Email: Bin_Wen@comcast.com 4047 Giuseppe Fioccola 4048 Telecom Italia 4050 Email: giuseppe.fioccola@telecomitalia.it 4052 Chongfeng Xie 4053 China Telecom 4055 Email: xiechf@ctbri.com.cn 4057 Luay Jalil 4058 Verizon 4060 Email: luay.jalil@verizon.com