idnits 2.17.1 draft-ietf-opsawg-l2nm-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 499 has weird spacing: '...face-id str...' == Line 641 has weird spacing: '...--rw id str...' == Line 643 has weird spacing: '...--rw id str...' == Line 645 has weird spacing: '...--rw id str...' == Line 647 has weird spacing: '...--rw id str...' == (11 more instances...) -- The document date (2 June 2022) is 695 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-BGP-L2' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-PW-Types' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802-1ag' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.1Qcp-2018' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T-Y-1731' ** Downref: Normative reference to an Informational RFC: RFC 4026 ** Downref: Normative reference to an Informational RFC: RFC 6624 == Outdated reference: A later version (-13) exists of draft-ietf-bess-evpn-pref-df-08 == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-13 == Outdated reference: A later version (-15) exists of draft-ietf-opsawg-sap-07 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-10 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-10 == Outdated reference: A later version (-15) exists of draft-ietf-teas-te-service-mapping-yang-10 -- Obsolete informational reference (is this intentional?): RFC 5143 (Obsoleted by RFC 4842) Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG M. Boucadair, Ed. 3 Internet-Draft Orange 4 Intended status: Standards Track O. Gonzalez de Dios, Ed. 5 Expires: 4 December 2022 S. Barguil 6 Telefonica 7 L. Munoz 8 Vodafone 9 2 June 2022 11 A YANG Network Data Model for Layer 2 VPNs 12 draft-ietf-opsawg-l2nm-19 14 Abstract 16 This document defines an L2VPN Network YANG Model (L2NM) which can be 17 used to manage the provisioning of Layer 2 Virtual Private Network 18 services within a network (e.g., service provider network). The L2NM 19 complements the Layer 2 Service Model (L2SM) by providing a network- 20 centric view of the service that is internal to a service provider. 21 The L2NM is particularly meant to be used by a network controller to 22 derive the configuration information that will be sent to relevant 23 network devices. 25 Also, this document defines a YANG module to manage Ethernet segments 26 and the initial versions of two IANA-maintained modules that include 27 a set of identities of BGP Layer 2 encapsulation types and pseudowire 28 types. 30 Editorial Note (To be removed by RFC Editor) 32 Please update these statements within the document with the RFC 33 number to be assigned to this document: 35 * "This version of this YANG module is part of RFC XXXX;" 37 * "RFC XXXX: A YANG Network Data Model for Layer 2 VPNs"; 39 * reference: RFC XXXX 41 Also, please update the "revision" date of the YANG modules. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at https://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on 4 December 2022. 60 Copyright Notice 62 Copyright (c) 2022 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 67 license-info) in effect on the date of publication of this document. 68 Please review these documents carefully, as they describe your rights 69 and restrictions with respect to this document. Code Components 70 extracted from this document must include Revised BSD License text as 71 described in Section 4.e of the Trust Legal Provisions and are 72 provided without warranty as described in the Revised BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . . 6 79 4. Reference Architecture . . . . . . . . . . . . . . . . . . . 6 80 5. Relationship to Other YANG Data Models . . . . . . . . . . . 11 81 6. Description of the Ethernet Segment YANG Module . . . . . . . 12 82 7. Description of the L2NM YANG Module . . . . . . . . . . . . . 15 83 7.1. Overall Structure of the Module . . . . . . . . . . . . . 15 84 7.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 16 85 7.3. VPN Services . . . . . . . . . . . . . . . . . . . . . . 17 86 7.4. Global Parameters Profiles . . . . . . . . . . . . . . . 21 87 7.5. VPN Nodes . . . . . . . . . . . . . . . . . . . . . . . . 25 88 7.5.1. BGP Auto-Discovery . . . . . . . . . . . . . . . . . 28 89 7.5.2. Signaling Options . . . . . . . . . . . . . . . . . . 29 90 7.5.2.1. BGP . . . . . . . . . . . . . . . . . . . . . . . 31 91 7.5.2.2. LDP . . . . . . . . . . . . . . . . . . . . . . . 33 92 7.5.2.3. L2TP . . . . . . . . . . . . . . . . . . . . . . 34 93 7.6. VPN Network Accesses . . . . . . . . . . . . . . . . . . 34 94 7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 36 95 7.6.2. EVPN-VPWS Service Instance . . . . . . . . . . . . . 39 96 7.6.3. Ethernet OAM . . . . . . . . . . . . . . . . . . . . 41 97 7.6.4. Services . . . . . . . . . . . . . . . . . . . . . . 42 98 8. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 48 99 8.1. IANA-Maintained Module for BGP Layer 2 Encapsulation 100 Types . . . . . . . . . . . . . . . . . . . . . . . . . . 48 101 8.2. IANA-Maintained Module for Pseudowire Types . . . . . . . 54 102 8.3. Ethernet Segments . . . . . . . . . . . . . . . . . . . . 61 103 8.4. L2NM . . . . . . . . . . . . . . . . . . . . . . . . . . 69 104 9. Security Considerations . . . . . . . . . . . . . . . . . . . 123 105 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124 106 10.1. Registering YANG Modules . . . . . . . . . . . . . . . . 124 107 10.2. BGP Layer 2 Encapsulation Types . . . . . . . . . . . . 126 108 10.3. Pseudowire Types . . . . . . . . . . . . . . . . . . . . 126 109 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 127 110 11.1. Normative References . . . . . . . . . . . . . . . . . . 127 111 11.2. Informative References . . . . . . . . . . . . . . . . . 130 112 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 136 113 A.1. BGP-based VPLS . . . . . . . . . . . . . . . . . . . . . 136 114 A.2. BGP-based VPWS with LDP Signaling . . . . . . . . . . . . 142 115 A.3. LDP-based VPLS . . . . . . . . . . . . . . . . . . . . . 145 116 A.4. VPWS-EVPN Service Instance . . . . . . . . . . . . . . . 149 117 A.5. Automatic ESI Assignment . . . . . . . . . . . . . . . . 155 118 A.6. VPN Network Access Precedence . . . . . . . . . . . . . . 158 119 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 161 120 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 161 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 162 123 1. Introduction 125 [RFC8466] defines an L2VPN Service Model (L2SM) YANG data model that 126 can be used between customers and service providers for ordering 127 Layer 2 Virtual Private Network (L2VPN) services. This document 128 complements the L2SM by creating a network-centric view of the 129 service: the L2VPN Network Model (L2NM). 131 Also, this document defines the initial versions of two IANA- 132 maintained modules that define a set of identities of BGP Layer 2 133 encapsulation types (Section 8.1) and pseudowire types (Section 8.2). 134 These types are used in the L2NM to identify a Layer 2 encapsulation 135 type as a function of the signalling option used to deliver an L2VPN 136 service. Relying upon these IANA-maintained modules is meant to 137 provide more flexibility in handling new types rather than being 138 limited by a set of identities defined in the L2NM itself. 139 Section 8.3 defines another YANG module to manage Ethernet Segments 140 (ESes) that are required for instantiating Ethernet VPNs (EVPNs). 141 References to Ethernet segments that are created using the module in 142 Section 8.3 can be included in the L2NM for EVPNs. 144 The L2NM (Section 8.4) can be exposed, for example, by a network 145 controller to a service controller within the service provider's 146 network. In particular, the model can be used in the communication 147 interface between the entity that interacts directly with the 148 customer (i.e., the service orchestrator) and the entity in charge of 149 network orchestration and control (a.k.a., network controller/ 150 orchestrator) by allowing for more network-centric information to be 151 included. 153 The L2NM supports capabilities, such as exposing operational 154 parameters, transport protocols selection, and precedence. It can 155 also serve as a multi-domain orchestration interface. 157 The L2NM is scoped for a variety of Layer 2 Virtual Private Networks, 158 such as: 160 * Virtual Private LAN Service (VPLS) [RFC4761][RFC4762] 161 * Virtual Private Wire Service (VPWS) (Section 3.1.1 of [RFC4664]) 162 * Various flavors of EVPNs: 163 - VPWS EVPN [RFC8214], 164 - Provider Backbone Bridging Ethernet VPNs (PBB EVPNs) [RFC7623], 165 - EVPN over MPLS [RFC7432], and 166 - EVPN over Virtual eXtensible Local Area Network (VXLAN) 167 [RFC8365]. 169 The L2NM is designed to easily support future Layer 2 VPN flavors and 170 procedures (e.g., advanced configuration such as pseudowires 171 resilience or Multi-Segment pseudowires [RFC7267]). A set of 172 examples to illustrate the use of the L2NM are provided in 173 Appendix A. 175 This document uses the common Virtual Private Network (VPN) YANG 176 module defined in [RFC9181]. 178 The YANG data models in this document conforms to the Network 179 Management Datastore Architecture (NMDA) defined in [RFC8342]. 181 2. Terminology 183 This document assumes that the reader is familiar with [RFC6241], 184 [RFC7950], [RFC8466], [RFC4026], and [RFC8309]. This document uses 185 terminology from those documents. 187 This document uses the term "network model" as defined in Section 2.1 188 of [RFC8969]. 190 The meanings of the symbols in YANG tree diagrams is defined in 191 [RFC8340]. 193 This document makes use of the following terms: 195 Ethernet segment (ES): Refers to the set of the Ethernet links that 196 are used by a customer site (device or network) to connect to one 197 or more Provider Edges (PEs). 199 Layer 2 VPN Service Model (L2SM): Describes the service 200 characterization of an L2VPN that interconnects a set of sites 201 from the customer's perspective. The customer service model does 202 not provide details on the service provider network. An L2VPN 203 customer service model is defined in [RFC8466]. 205 Layer 2 VPN Network Model (L2NM): Refers to the YANG data model that 206 describes an L2VPN service with a network-centric view. It 207 contains information on the service provider network and might 208 include allocated resources. Network controllers can use it to 209 manage the Layer 2 VPN service configuration in the service 210 provider's network. The corresponding YANG module can be used by 211 a service orchestrator to request a VPN service to a network 212 controller or to expose the list of active L2VPN services. The 213 L2NM can also be used to retrieve a set of L2VPN-related state 214 information (including OAM). 216 MAC-VRF: Refers to a Virtual Routing and Forwarding (VRF) table for 217 Media Access Control (MAC) addresses on a PE. 219 Network controller: Denotes a functional entity responsible for the 220 management of the service provider network. 222 Service orchestrator: Refers to a functional entity that interacts 223 with the customer of an L2VPN relying upon, e.g., the L2SM. The 224 service orchestrator is responsible for the Customer Edge - to 225 Provider Edge (CE-PE) attachment circuits, the PE selection, and 226 requesting the activation of the L2VPN service to a network 227 controller. 229 Service provider network: Is a network able to provide L2VPN-related 230 services. 232 VPN node: Is an abstraction that represents a set of policies 233 applied on a PE and belonging to a single VPN service. A VPN 234 service involves one or more VPN nodes. The VPN node will 235 identify the service providers' node on which the VPN is deployed. 237 VPN network access: Is an abstraction that represents the network 238 interfaces that are associated with a given VPN node. Traffic 239 coming from the VPN network access belongs to the VPN. The 240 attachment circuits (bearers) between Customer Edges (CEs) and 241 Provider Edges (PEs) are terminated in the VPN network access. 243 VPN service provider: Is a service provider that offers L2VPN- 244 related services. 246 3. Acronyms and Abbreviations 248 The following acronyms and abbreviations are used in this document: 250 ACL Access Control List 251 BGP Border Gateway Protocol 252 BUM Broadcast, unknown unicast, or multicast 253 CE Customer Edge 254 ES Ethernet Segment 255 ESI Ethernet Segment Identifier 256 EVPN Ethernet VPN 257 L2VPN Layer 2 Virtual Private Network 258 L2SM L2VPN Service Model 259 L2NM L2VPN Network Model 260 MAC Media Access Control 261 PBB Provider Backbone Bridging 262 PCP Priority Code Point 263 PE Provider Edge 264 QoS Quality of Service 265 RD Route Distinguisher 266 RT Route Target 267 VPLS Virtual Private LAN Service 268 VPN Virtual Private Network 269 VPWS Virtual Private Wire Service 270 VRF Virtual Routing and Forwarding 272 4. Reference Architecture 274 Figure 1 illustrates how the L2NM is used. As a reminder, this 275 figure is an expansion of the architecture presented in Section 3 of 276 [RFC8466] and decomposes the box marked "orchestration" in that 277 figure into three separate functional components called "Service 278 Orchestration", "Network Orchestration", and "Domain Orchestration". 280 Similar to Section 3 of [RFC8466], CE to PE attachment is achieved 281 through a bearer with a Layer 2 connection on top. The bearer refers 282 to properties of the attachment that are below Layer 2, while the 283 connection refers to Layer 2 protocol-oriented properties. 285 The reader may refer to [RFC8309] for the distinction between the 286 "Customer Service Model", the "Service Delivery Model", the "Network 287 Configuration Model", and the "Device Configuration Model". The 288 "Domain Orchestration" and "Config Manager" roles may be performed by 289 "SDN Controllers". 291 +---------------+ 292 | Customer | 293 +-------+-------+ 294 Customer Service Model | 295 e.g., l2vpn-svc | 296 +-------+-------+ 297 | Service | 298 | Orchestration | 299 +-------+-------+ 300 Network Model | 301 l2vpn-ntw + l2vpn-es | 302 +-------+-------+ 303 | Network | 304 | Orchestration | 305 +-------+-------+ 306 Network Configuration Model | 307 +-----------+-----------+ 308 | | 309 +--------+------+ +--------+------+ 310 | Domain | | Domain | 311 | Orchestration | | Orchestration | 312 +---+-----------+ +--------+------+ 313 Device | | | 314 Configuration | | | 315 Model | | | 316 +----+----+ | | 317 | Config | | | 318 | Manager | | | 319 +----+----+ | | 320 | | | 321 | NETCONF/CLI.................. 322 | | | 323 +--------------------------------+ 324 \ Network / 325 \ / 326 +----+ Bearer +----+ +----+ +----+ 327 |CE A+ ---------- +PE A+ +PE B+ ------- +CE B| 328 +----+ Connection +----+ +----+ +----+ 330 Site A Site B 332 NETCONF: Network Configuration Protocol 333 CLI: Command-Line Interface 335 Figure 1: L2SM and L2NM Interaction 337 The customer may use various means to request a service that may 338 trigger the instantiation of an L2NM. The customer may use the L2SM 339 or may rely upon more abstract models to request a service that 340 relies upon an L2VPN service. For example, the customer may supply 341 an IP Connectivity Provisioning Profile (CPP) that characterizes the 342 requested service [RFC7297], an enhanced VPN (VPN+) service 343 [I-D.ietf-teas-enhanced-vpn], or an IETF network slice service 344 [I-D.ietf-teas-ietf-network-slices]. 346 Note also that both the L2SM and the L2NM may be used in the context 347 of the Abstraction and Control of TE Networks (ACTN) framework 348 [RFC8453]. Figure 2 shows the Customer Network Controller (CNC), the 349 Multi-Domain Service Coordinator (MDSC), and the Provisioning Network 350 Controller (PNC). 352 +----------------------------------+ 353 | Customer | 354 | +-----------------------------+ | 355 | | CNC | | 356 | +-----------------------------+ | 357 +----+-----------------------+-----+ 358 | | 359 | L2SM | L2SM 360 | | 361 +---------+---------+ +---------+---------+ 362 | MDSC | | MDSC | 363 | +---------------+ | | (parent) | 364 | | Service | | +---------+---------+ 365 | | Orchestration | | | 366 | +-------+-------+ | | L2NM 367 | | | | 368 | | L2NM | +---------+---------+ 369 | | | | MDSC | 370 | +-------+-------+ | | (child) | 371 | | Network | | +---------+---------+ 372 | | Orchestration | | | 373 | +---------------+ | | 374 +---------+---------+ | 375 | | 376 | Network Configuration | 377 | | 378 +------------+-------+ +---------+------------+ 379 | Domain | | Domain | 380 | Controller | | Controller | 381 | +---------+ | | +---------+ | 382 | | PNC | | | | PNC | | 383 | +---------+ | | +---------+ | 384 +------------+-------+ +---------+------------+ 385 | | 386 | Device Configuration | 387 | | 388 +----+---+ +----+---+ 389 | Device | | Device | 390 +--------+ +--------+ 392 Figure 2: L2SM and L2NM in the Context of ACTN 394 5. Relationship to Other YANG Data Models 396 The "ietf-vpn-common" module [RFC9181] includes a set of identities, 397 types, and groupings that are meant to be reused by VPN-related YANG 398 modules independently of the layer (e.g., Layer 2, Layer 3) and the 399 type of the module (e.g., network model, service model) including 400 future revisions of existing models (e.g., [RFC8466]). The L2NM 401 reuses these common types and groupings. 403 Also, the L2NM uses the IANA-maintained modules "iana-bgp-l2-encaps" 404 (Section 8.1) and "iana-pseudowire-types" (Section 8.2) to identify 405 Layer 2 encapsulation and pseudowire types. More details are 406 provided in Sections 7.5.2.1 and 7.5.2.3. 408 For the particular case of EVPN, the L2NM includes a name that refers 409 to an Ethernet segment that is created using the "ietf-ethernet- 410 segment" module (Section 8.3). Some ES-related examples are provided 411 in Appendices A.4 and A.5. 413 As discussed in Section 4, the L2NM is used to manage L2VPN services 414 within a service provider network. The module provides a network 415 view of the L2VPN service. Such a view is only visible to the 416 service provider and is not exposed outside (to customers, for 417 example). The following discusses how the L2NM interfaces with other 418 YANG modules: 420 L2SM: The L2NM is not a customer service model. 422 The internal view of the service (i.e., the L2NM) may be mapped to 423 an external view which is visible to customers: L2VPN Service 424 Model (L2SM) [RFC8466]. 426 The L2NM can be fed with inputs that are requested by customers, 427 typically, relying upon an L2SM template. Concretely, some parts 428 of the L2SM module can be directly mapped into the L2NM while 429 other parts are generated as a function of the requested service 430 and local guidelines. Finally, there are parts local to the 431 service provider and do not map directly to the L2SM. 433 Note that using the L2NM within a service provider does not 434 assume, nor does it preclude, exposing the VPN service via the 435 L2SM. This is deployment specific. Nevertheless, the design of 436 L2NM tries to align as much as possible with the features 437 supported by the L2SM to ease the grafting of both the L2NM and 438 the L2SM for the sake of highly automated VPN service provisioning 439 and delivery. 441 Network Topology Modules: An L2VPN involves nodes that are part of a 442 topology managed by the service provider network. Such a topology 443 can be represented using the network topology module in [RFC8345] 444 or its extension, such as a network YANG module for Service 445 Attachment Points (SAPs) [I-D.ietf-opsawg-sap]. 447 Device Modules: The L2NM is not a device model. 449 Once a global VPN service is captured by means of the L2NM, the 450 actual activation and provisioning of the VPN service will involve 451 a variety of device modules to tweak the required functions for 452 the delivery of the service. These functions are supported by the 453 VPN nodes and can be managed using device YANG modules. A non- 454 comprehensive list of such device YANG modules is provided below: 456 * Interfaces [RFC8343]. 458 * BGP [I-D.ietf-idr-bgp-model]. 460 * MPLS [RFC8960]. 462 * Access Control Lists (ACLs) [RFC8519]. 464 How the L2NM is used to derive device-specific actions is 465 implementation specific. 467 6. Description of the Ethernet Segment YANG Module 469 The 'ietf-ethernet-segment' module (Figure 3) is used to manage a set 470 of Ethernet segments in the context of an EVPN service. 472 module: ietf-ethernet-segment 473 +--rw ethernet-segments 474 +--rw ethernet-segment* [name] 475 +--rw name string 476 +--rw esi-type? identityref 477 +--rw (esi-choice)? 478 | +--:(directly-assigned) 479 | | +--rw ethernet-segment-identifier? yang:hex-string 480 | +--:(auto-assigned) 481 | +--rw esi-auto 482 | +--rw (auto-mode)? 483 | | +--:(from-pool) 484 | | | +--rw esi-pool-name? string 485 | | +--:(full-auto) 486 | | +--rw auto? empty 487 | +--ro auto-ethernet-segment-identifier? 488 | yang:hex-string 489 +--rw esi-redundancy-mode? identityref 490 +--rw df-election 491 | +--rw df-election-method? identityref 492 | +--rw revertive? boolean 493 | +--rw election-wait-time? uint32 494 +--rw split-horizon-filtering? boolean 495 +--rw pbb 496 | +--rw backbone-src-mac? yang:mac-address 497 +--rw member* [ne-id interface-id] 498 +--rw ne-id string 499 +--rw interface-id string 501 Figure 3: Ethernet Segments Tree Structure 503 The descriptions of the data nodes depicted in Figure 3 are as 504 follows: 506 'name': Sets a name to uniquely identify an ES within a service 507 provider network. In order to ease referencing ESes by their name 508 in other modules, "es-ref" typedef is defined. 510 This typedef is used in the VPN network access level of the L2NM 511 to reference an ES (Section 7.6). An example to illustrate such a 512 use in the L2NM is provided in Appendix A.4. 514 'esi-type': Indicates the Ethernet Segment Identifier (ESI) type as 515 discussed in Section 5 of [RFC7432]. ESIs can be automatically 516 assigned either with or without indicating a pool from which an 517 ESI should be taken ('esi-pool-name'). The following types are 518 supported: 520 'esi-type-0-operator': The ESI is directly configured by the VPN 521 service provider. The configured value is provided in 522 'ethernet-segment-identifier'. 524 'esi-type-1-lacp': The ESI is auto-generated from the IEEE 525 802.1AX Link Aggregation Control Protocol (LACP) [IEEE802.1AX]. 527 'esi-type-2-bridge': The ESI is auto-generated and determined 528 based on the Layer 2 bridge protocol. 530 'esi-type-3-mac': The ESI is a MAC-based ESI value that can be 531 auto-generated or configured by the VPN service provider. 533 'esi-type-4-router-id': The ESI is auto-generated or configured 534 by the VPN service provider based on the Router ID. The 535 'router-id' supplied in Section 7.5 can be used to auto-derive 536 an ESI when this type is used. 538 'esi-type-5-asn': The ESI is auto-generated or configured by the 539 VPN service provider based on the Autonomous System (AS) 540 number. The 'local-autonomous-system' supplied in Section 7.4 541 can be used to auto-derive an ESI when this type is used. 543 Auto-generated values can be retrieved using 'auto-ethernet- 544 segment-identifier'. 546 'esi-redundancy-mode': Specifies the EVPN redundancy mode for a 547 given ES. The following modes are supported: Single-Active 548 (Section 14.1.1 of [RFC7432]) or All-Active (Section 14.1.2 of 549 [RFC7432]). 551 'df-election': Specifies a set of parameters related to the 552 Designated Forwarder (DF) election (Section 8.5 of [RFC7432]). 553 For example, this data node can be used to indicate an election 554 method (e.g., [RFC8584] or [I-D.ietf-bess-evpn-pref-df]). If no 555 election method is indicated, the default method defined in 556 Section 8.5 of [RFC7432] is used. 558 As discussed in Section 1.3.2 of [RFC8584], the default behavior 559 is to trigger the DF election procedure when a DF fails (e.g., 560 link failure). The former DF will take over when it is available 561 again. Such a mode is called revertive. The behavior can be 562 overridden by setting the 'revertive' leaf to 'false'. 564 Also, this data node can be used to configure a DF Wait timer 565 ('election-wait-time') (Section 2.1 of [RFC8584]). 567 'split-horizon-filtering': Controls the activation of the split- 568 horizon filtering for an ES (Section 8.3 of [RFC7432]). 570 'pbb': Indicates data nodes that are specific to PBB [IEEE-802-1ah]: 572 'backbone-src-mac': Associates a Provider Backbone MAC (B-MAC) 573 address with an ES. This is particularly useful for All-Active 574 multihomed ESes (Section 9.1 of [RFC7623]). 576 'member': Lists the members of an ES in a service provider network. 578 7. Description of the L2NM YANG Module 580 The L2NM ('ietf-l2vpn-ntw', Section 8.4) is used to manage L2VPNs 581 within a service provider network. In particular, the 'ietf-l2vpn- 582 ntw' module can be used to create, modify, delete and retrieve L2VPN 583 services in a network controller. The module is designed to minimize 584 the amount of customer-related information. 586 The full tree diagram of the module can be generated using the 587 "pyang" tool [PYANG]. That tree is not included here because it is 588 too long (Section 3.3 of [RFC8340]). Instead, subtrees are provided 589 for the reader's convenience. 591 Note that the following subsections introduce some data nodes that 592 enclose textual descriptions (e.g., VPN service (Section 7.3), VPN 593 node (Section 7.5), or VPN network access (Section 7.6)). Such 594 descriptions are not intended for random end users but for 595 network/system/software engineers that use their local context to 596 provide and interpret such information. Therefore, no mechanism for 597 language tagging is needed. 599 7.1. Overall Structure of the Module 601 The 'ietf-l2vpn-ntw' module uses two main containers: 'vpn-profiles' 602 and 'vpn-services' (see Figure 4). 604 The 'vpn-profiles' container is used by the provider to define and 605 maintain a set of common VPN profiles that apply to VPN services 606 (Section 7.2). 608 The 'vpn-services' container maintains the set of L2VPN services 609 managed in the service provider network. The module allows creating 610 a new L2VPN service by adding a new instance of 'vpn-service'. The 611 'vpn-service' is the data structure that abstracts the VPN service 612 (Section 7.3). 614 module: ietf-l2vpn-ntw 615 +--rw l2vpn-ntw 616 +--rw vpn-profiles 617 | ... 618 +--rw vpn-services 619 +--rw vpn-service* [vpn-id] 620 ... 621 +--rw vpn-nodes 622 +--rw vpn-node* [vpn-node-id] 623 ... 624 +--rw vpn-network-accesses 625 +--rw vpn-network-access* [id] 626 ... 628 Figure 4: Overall L2NM Tree Structure 630 7.2. VPN Profiles 632 The 'vpn-profiles' container (Figure 5) is used by a VPN service 633 provider to define and maintain a set of VPN profiles [RFC9181] that 634 apply to one or several VPN services. 636 +--rw l2vpn-ntw 637 +--rw vpn-profiles 638 | +--rw valid-provider-identifiers 639 | +--rw external-connectivity-identifier* [id] 640 | | {external-connectivity}? 641 | | +--rw id string 642 | +--rw encryption-profile-identifier* [id] 643 | | +--rw id string 644 | +--rw qos-profile-identifier* [id] 645 | | +--rw id string 646 | +--rw bfd-profile-identifier* [id] 647 | | +--rw id string 648 | +--rw forwarding-profile-identifier* [id] 649 | | +--rw id string 650 | +--rw routing-profile-identifier* [id] 651 | +--rw id string 652 +--rw vpn-services 653 ... 655 Figure 5: VPN Profiles Subtree Structure 657 The exact definition of these profiles is local to each VPN service 658 provider. The model only includes an identifier for these profiles 659 in order to ease identifying and binding local policies when building 660 a VPN service. As shown in Figure 5, the following identifiers can 661 be included: 663 'external-connectivity-identifier': This identifier refers to a 664 profile that defines the external connectivity provided to a VPN 665 service (or a subset of VPN sites). External connectivity may be 666 access to the Internet or restricted connectivity, such as access 667 to a public/private cloud. 669 'encryption-profile-identifier': An encryption profile refers to a 670 set of policies related to the encryption schemes and setup that 671 can be applied when building and offering a VPN service. 673 'qos-profile-identifier': A Quality of Service (QoS) profile refers 674 to as set of policies, such as classification, marking, and 675 actions (e.g., [RFC3644]). 677 'bfd-profile-identifier': A Bidirectional Forwarding Detection (BFD) 678 profile refers to a set of BFD policies [RFC5880] that can be 679 invoked when building a VPN service. 681 'forwarding-profile-identifier': A forwarding profile refers to the 682 policies that apply to the forwarding of packets conveyed within a 683 VPN. Such policies may consist, for example, of applying ACLs. 685 'routing-profile-identifier': A routing profile refers to a set of 686 routing policies that will be invoked (e.g., BGP policies) when 687 delivering the VPN service. 689 7.3. VPN Services 691 The 'vpn-service' is the data structure that abstracts an L2VPN 692 service in the service provider network. Each 'vpn-service' is 693 uniquely identified by an identifier: 'vpn-id'. Such a 'vpn-id' is 694 only meaningful locally within the network controller. The subtree 695 of the 'vpn-services' is shown in Figure 6. 697 +--rw vpn-services 698 +--rw vpn-service* [vpn-id] 699 +--rw vpn-id vpn-common:vpn-id 700 +--rw vpn-name? string 701 +--rw vpn-description? string 702 +--rw customer-name? string 703 +--rw parent-service-id? vpn-common:vpn-id 704 +--rw vpn-type? identityref 705 +--rw vpn-service-topology? identityref 706 +--rw bgp-ad-enabled? boolean 707 +--rw signaling-type? identityref 708 +--rw global-parameters-profiles 709 | ... 710 +--rw underlay-transport 711 | +--rw (type)? 712 | +--:(abstract) 713 | | +--rw transport-instance-id? string 714 | | +--rw instance-type? identityref 715 | +--:(protocol) 716 | +--rw protocol* identityref 717 +--rw status 718 | +--rw admin-status 719 | | +--rw status? identityref 720 | | +--rw last-change? yang:date-and-time 721 | +--ro oper-status 722 | +--ro status? identityref 723 | +--ro last-change? yang:date-and-time 724 +--rw vpn-nodes 725 ... 727 Figure 6: VPN Services Subtree 729 The descriptions of the VPN service data nodes that are depicted in 730 Figure 6 are as follows: 732 'vpn-id': An identifier that is used to uniquely identify the L2VPN 733 service within the L2NM scope. 735 'vpn-name': Associates a name with the service in order to 736 facilitate the identification of the service. 738 'vpn-description': Includes a textual description of the service. 740 The internal structure of a VPN description is local to each VPN 741 service provider. 743 'customer-name': Indicates the name of the customer who ordered the 744 service. 746 'parent-service-id': Refers to an identifier of the parent service 747 (e.g., the L2SM, IETF network slice, VPN+) that triggered the 748 creation of the L2VPN service. This identifier is used to easily 749 correlate the (network) service as built in the network with a 750 service order. A controller can use that correlation to enrich or 751 populate some fields (e.g., description fields) as a function of 752 local deployments. 754 'vpn-type': Indicates the L2VPN type. The following types, defined 755 in [RFC9181], can be used for the L2NM: 757 'vpls': Virtual Private LAN Service (VPLS) as defined in 758 [RFC4761] or [RFC4762]. This type is also used for 759 hierarchical VPLS (H-VPLS) (Section 10 of [RFC4762]). 761 'vpws': Virtual Private Wire Service (VPWS) as defined in 762 Section 3.1.1 of [RFC4664]. 764 'vpws-evpn': VPWS as defined in [RFC8214]. 766 'pbb-evpn': Provider Backbone Bridging (PBB) EVPNs as defined in 767 [RFC7623]. 769 'mpls-evpn': MPLS-based EVPNs [RFC7432]. 771 'vxlan-evpn': VXLAN based EVPNs [RFC8365]. 773 The type is used as a condition for the presence of some data 774 nodes in the L2NM. 776 'vpn-service-topology': Indicates the network topology for the 777 service: hub-spoke, any-to-any, or custom. These types are 778 defined in [RFC9181]. 780 'bgp-ad-enabled': Controls whether BGP auto-discovery is enabled. 781 If so, additional data nodes are included (Section 7.5.1). 783 'signaling-type': Indicates the signaling that is used for setting 784 up pseudowires. Signaling type values are taken from [RFC9181]. 785 The following signaling options are supported: 787 'bgp-signaling': The L2NM supports two flavors of BGP-signaled 788 L2VPNs: 790 'l2vpn-bgp': The service is a Multipoint VPLS that uses a BGP 791 control plane as described in [RFC4761] and [RFC6624]. 793 'evpn-bgp': The service is a Multipoint VPLS that uses also a 794 BGP control plane, but also includes the additional EVPN 795 features and related parameters [RFC7432] and [RFC7209]. 797 'ldp-signaling': A Multipoint VPLS that uses a mesh of LDP- 798 signaled Pseudowires [RFC6074]. 800 'l2tp-signaling': The L2NM uses L2TP-signaled Pseudowires as 801 described in [RFC6074]. 803 Table 1 summarizes the allowed signaling types for each VPN 804 service type ('vpn-type'). See Section 7.5.2 for more details. 806 +============+================================+ 807 | VPN Type | Signaling Options | 808 +============+================================+ 809 | vpls | l2tp-signaling, ldp-signaling, | 810 | | bgp-signaling (l2vpn-bgp) | 811 +------------+--------------------------------+ 812 | vpws | l2tp-signaling, ldp-signaling, | 813 | | bgp-signaling (l2vpn-bgp) | 814 +------------+--------------------------------+ 815 | vpws-evpn | bgp-signaling (evpn-bgp) | 816 +------------+--------------------------------+ 817 | pbb-evpn | bgp-signaling (evpn-bgp) | 818 +------------+--------------------------------+ 819 | mpls-evpn | bgp-signaling (evpn-bgp) | 820 +------------+--------------------------------+ 821 | vxlan-evpn | bgp-signaling (evpn-bgp) | 822 +------------+--------------------------------+ 824 Table 1: Signaling Options per VPN 825 Service Type 827 'global-parameters-profiles': Defines reusable parameters for the 828 same L2VPN service. 830 More details are provided in Section 7.4. 832 'underlay-transport': Describes the preference for the transport 833 technology to carry the traffic of the VPN service. This 834 preference is especially useful in networks with multiple domains 835 and Network-to-Network Interface (NNI) types. The underlay 836 transport can be expressed as an abstract transport instance 837 (e.g., an identifier of a VPN+ instance, a virtual network 838 identifier, or a network slice name) or as an ordered list of the 839 actual protocols to be enabled in the network. 841 A rich set of protocol identifiers that can be used to refer to an 842 underlay transport (or how such an underlay is set up) are defined 843 in [RFC9181]. 845 The model defined in Section 6.3.2 of 846 [I-D.ietf-teas-te-service-mapping-yang] may be used if specific 847 protection and availability requirements are needed between PEs. 849 'status': Used to track the overall status of a given VPN service. 850 Both operational and administrative status are maintained together 851 with a timestamp. For example, a service can be created, but not 852 put into effect. 854 Administrative and operational status can be used as a trigger to 855 detect service anomalies. For example, a service that is declared 856 at the service layer as being created but still inactive at the 857 network layer is an indication that network provisioning actions 858 are needed to align the observed service status with the expected 859 service status. 861 'vpn-node': An abstraction that represents a set of policies applied 862 to a network node and belonging to a single 'vpn-service'. An 863 L2VPN service is typically built by adding instances of 'vpn-node' 864 to the 'vpn-nodes' container. 866 A 'vpn-node' contains 'vpn-network-accesses', which are the 867 interfaces attached to the VPN by which the customer traffic is 868 received. Therefore, the customer sites are connected to the 869 'vpn-network-accesses'. 871 Note that, as this is a network data model, the information about 872 customers sites is not required in the model. Such information is 873 rather relevant in the L2SM. Whether that information is included 874 in the L2NM, e.g., to populate the various 'description' data 875 nodes is implementation specific. 877 More details are provided in Section 7.5. 879 7.4. Global Parameters Profiles 881 The 'global-parameters-profile' defines reusable parameters for the 882 same L2VPN service instance ('vpn-service'). Global parameters 883 profiles are defined at the VPN service level, activated at the VPN 884 node level, and then an activated VPN profile may be used at the VPN 885 network access level. Each VPN instance profile is identified by 886 'profile-id'. Some of the data nodes can be adjusted at the VPN node 887 or VPN network access levels. These adjusted values take precedence 888 over the global values. The subtree of 'global-parameters-profile' 889 is depicted in Figure 7. 891 ... 892 +--rw vpn-services 893 +--rw vpn-service* [vpn-id] 894 ... 895 +--rw global-parameters-profiles 896 | +--rw global-parameters-profile* [profile-id] 897 | +--rw profile-id string 898 | +--rw (rd-choice)? 899 | | +--:(directly-assigned) 900 | | | +--rw rd? 901 | | | rt-types:route-distinguisher 902 | | +--:(directly-assigned-suffix) 903 | | | +--rw rd-suffix? uint16 904 | | +--:(auto-assigned) 905 | | | +--rw rd-auto 906 | | | +--rw (auto-mode)? 907 | | | | +--:(from-pool) 908 | | | | | +--rw rd-pool-name? string 909 | | | | +--:(full-auto) 910 | | | | +--rw auto? empty 911 | | | +--ro auto-assigned-rd? 912 | | | rt-types:route-distinguisher 913 | | +--:(auto-assigned-suffix) 914 | | | +--rw rd-auto-suffix 915 | | | +--rw (auto-mode)? 916 | | | | +--:(from-pool) 917 | | | | | +--rw rd-pool-name? string 918 | | | | +--:(full-auto) 919 | | | | +--rw auto? empty 920 | | | +--ro auto-assigned-rd-suffix? uint16 921 | | +--:(no-rd) 922 | | +--rw no-rd? empty 923 | +--rw vpn-target* [id] 924 | | +--rw id uint8 925 | | +--rw route-targets* [route-target] 926 | | | +--rw route-target rt-types:route-target 927 | | +--rw route-target-type 928 | | rt-types:route-target-type 929 | +--rw vpn-policies 930 | | +--rw import-policy? string 931 | | +--rw export-policy? string 932 | +--rw local-autonomous-system? inet:as-number 933 | +--rw svc-mtu? uint32 934 | +--rw ce-vlan-preservation? boolean 935 | +--rw ce-vlan-cos-preservation? boolean 936 | +--rw control-word-negotiation? boolean 937 | +--rw mac-policies 938 | | +--rw mac-addr-limit 939 | | | +--rw limit-number? uint16 940 | | | +--rw time-interval? uint32 941 | | | +--rw action? identityref 942 | | +--rw mac-loop-prevention 943 | | +--rw window? uint32 944 | | +--rw frequency? uint32 945 | | +--rw retry-timer? uint32 946 | | +--rw protection-type? identityref 947 | +--rw multicast {vpn-common:multicast}? 948 | +--rw enabled? boolean 949 | +--rw customer-tree-flavors 950 | +--rw tree-flavor* identityref 951 ... 953 Figure 7: Global Parameters Profiles Subtree 955 The description of the global parameters profile is as follows: 957 'profile-id': Uniquely identifies a global parameter profile in the 958 context of an L2VPN service. 960 'rd': As defined in [RFC9181], these RD assignment modes are 961 supported: direct assignment, automatic assignment from a given 962 pool, full automatic assignment, and no assignment. 964 Also, the module accommodates deployments where only the Assigned 965 Number subfield of RDs is assigned from a pool while the 966 Administrator subfield is set to, e.g., the Router ID that is 967 assigned to a VPN node. The module supports these modes for 968 managing the Assigned Number subfield: explicit assignment, auto- 969 assignment from a pool, and full auto-assignment. 971 'vpn-targets': Specifies RT import/export rules for the VPN service. 973 'local-autonomous-system': Indicates the Autonomous System Number 974 (ASN) that is configured for the VPN node. The ASN can be used to 975 auto-derive some other attributes such as RDs or Ethernet Segment 976 Identifiers (ESIs). 978 'svc-mtu': Is the service MTU for an L2VPN service (i.e., Layer 2 979 MTU including L2 frame header/trailer). It is also known as the 980 maximum transmission unit or maximum frame size. It is expressed 981 in bytes. 983 'ce-vlan-preservation': Is set to preserve the Customer Edge VLAN 984 IDs (CE-VLAN IDs) from ingress to egress, i.e., CE-VLAN tag of the 985 egress frame are identical to those of the ingress frame that 986 yielded this egress service frame. If all-to-one bundling within 987 a site is enabled, then preservation applies to all ingress 988 service frames. If all-to-one bundling is disabled, then 989 preservation applies to tagged Ingress service frames having CE- 990 VLAN ID 1 through 4094. 992 'ce-vlan-cos-preservation': Controls the CE VLAN CoS preservation. 993 When set, Priority Code Point (PCP) bits in the CE-VLAN tag of the 994 egress frame are identical to those of the ingress frame that 995 yielded this egress service frame. 997 'control-word-negotiation': Controls whether control-word 998 negotiation is enabled (if set to true) or not (if set to false). 999 Refer to Section 7 of [RFC8077] for more details. 1001 'mac-policies': Includes a set of MAC policies that apply to the 1002 service: 1004 'mac-addr-limit': Is a container of MAC address limit 1005 configuration. It includes the following data nodes: 1007 'limit-number': Maximum number of MAC addresses learned from 1008 the customer for a single service instance. 1010 'time-interval': The aging time of the MAC address. 1012 'action': Specifies the action when the upper limit is 1013 exceeded: drop the packet, flood the packet, or simply send 1014 a warning message. 1016 'mac-loop-prevention': Container for MAC loop prevention. 1018 'window': The time interval over which a MAC mobility event is 1019 detected and checked. 1021 'frequency': The number of times to detect MAC duplication, 1022 where a 'duplicate MAC address' situation has occurred 1023 within the 'window' time interval, and the duplicate MAC 1024 address has been added to a list of duplicate MAC addresses. 1026 'retry-timer': The retry timer. When the retry timer expires, 1027 the duplicate MAC address will be flushed from the MAC-VRF. 1029 'protection-type': It defines the loop prevention type (e.g., 1030 shut). 1032 'multicast': Controls whether multicast is allowed in the service. 1034 7.5. VPN Nodes 1036 The 'vpn-node' (Figure 8) is an abstraction that represents a set of 1037 policies/configurations applied to a network node and that belong to 1038 a single 'vpn-service'. A 'vpn-node' contains 'vpn-network- 1039 accesses', which are the interfaces involved in the creation of the 1040 VPN. The customer sites are connected to the 'vpn-network-accesses'. 1042 +--rw l2vpn-ntw 1043 +--rw vpn-profiles 1044 | ... 1045 +--rw vpn-services 1046 +--rw vpn-service* [vpn-id] 1047 ... 1048 +--rw vpn-nodes 1049 +--rw vpn-node* [vpn-node-id] 1050 +--rw vpn-node-id vpn-common:vpn-id 1051 +--rw description? string 1052 +--rw ne-id? string 1053 +--rw role? identityref 1054 +--rw router-id? rt-types:router-id 1055 +--rw active-global-parameters-profiles 1056 | +--rw global-parameters-profile* [profile-id] 1057 | +--rw profile-id leafref 1058 | +--rw local-autonomous-system? 1059 | | inet:as-number 1060 | +--rw svc-mtu? uint32 1061 | +--rw ce-vlan-preservation? boolean 1062 | +--rw ce-vlan-cos-preservation? boolean 1063 | +--rw control-word-negotiation? boolean 1064 | +--rw mac-policies 1065 | | +--rw mac-addr-limit 1066 | | | +--rw limit-number? uint16 1067 | | | +--rw time-interval? uint32 1068 | | | +--rw action? identityref 1069 | | +--rw mac-loop-prevention 1070 | | +--rw window? uint32 1071 | | +--rw frequency? uint32 1072 | | +--rw retry-timer? uint32 1073 | | +--rw protection-type? identityref 1074 | +--rw multicast {vpn-common:multicast}? 1075 | +--rw enabled? boolean 1076 | +--rw customer-tree-flavors 1077 | +--rw tree-flavor* identityref 1078 +--rw status 1079 | ... 1080 +--rw bgp-auto-discovery 1081 | ... 1082 +--rw signaling-option 1083 | ... 1084 +--rw vpn-network-accesses 1085 ... 1087 Figure 8: VPN Nodes Subtree 1089 The descriptions of VPN node data nodes are as follows: 1091 'vpn-node-id': Used to uniquely identify a node that enables a VPN 1092 network access. 1094 'description': Provides a textual description of the VPN node. 1096 'ne-id': Includes an identifier of the network element where the VPN 1097 node is deployed. 1099 'role': Indicates the role of the VPN instance profile in the VPN. 1100 Role values are defined in [RFC9181] (e.g., 'any-to-any-role', 1101 'spoke-role', 'hub-role'). 1103 'router-id': Indicates a 32-bit number that is used to uniquely 1104 identify a router within an Autonomous System (AS). 1106 'active-global-parameters-profiles': Lists the set of active global 1107 VPN parameters profiles for this VPN node. Concretely, one or 1108 more global profiles that are defined at the VPN service level 1109 (i.e., under 'l2vpn-ntw/vpn-services/vpn-service' level) can be 1110 activated at the VPN node level; each of these profiles is 1111 uniquely identified by means of 'profile-id'. The structure of 1112 'active-global-parameters-profiles' uses the same data nodes as 1113 Section 7.4 except RD and RT related data nodes. 1115 Values defined in 'active-global-parameters-profiles' overrides 1116 the values defined in the VPN service level. 1118 'status': Tracks the status of a node involved in a VPN service. 1119 Both operational and administrative status are maintained. A 1120 mismatch between the administrative status vs. the operational 1121 status can be used as a trigger to detect anomalies. 1123 'bgp-auto-discovery': See Section 7.5.1. 1125 'signaling-option': See Section 7.5.2. 1127 'vpn-network-accesses': Represents the point to which sites are 1128 connected. 1130 Note that, unlike the L2SM, the L2NM does not need to model the 1131 customer site -- only the points that receive traffic from the 1132 site are covered (i.e., the PE side of Provider Edge to Customer 1133 Edge (PE-CE) connections). Hence, the VPN network access contains 1134 the connectivity information between the provider's network and 1135 the customer premises. The VPN profiles ('vpn-profiles') have a 1136 set of routing policies that can be applied during the service 1137 creation. 1139 See Section 7.6 for more details. 1141 7.5.1. BGP Auto-Discovery 1143 The 'bgp-auto-discovery' container (Figure 9) includes the required 1144 information for the activation of BGP auto-discovery 1145 [RFC4761][RFC6624]. 1147 +--rw l2vpn-ntw 1148 +--rw vpn-profiles 1149 | ... 1150 +--rw vpn-services 1151 +--rw vpn-service* [vpn-id] 1152 ... 1153 +--rw vpn-nodes 1154 +--rw vpn-node* [vpn-node-id] 1155 ... 1156 +--rw bgp-auto-discovery 1157 | +--rw (bgp-type)? 1158 | | +--:(l2vpn-bgp) 1159 | | | +--rw vpn-id? 1160 | | | vpn-common:vpn-id 1161 | | +--:(evpn-bgp) 1162 | | +--rw evpn-type? leafref 1163 | | +--rw auto-rt-enable? boolean 1164 | | +--ro auto-route-target? 1165 | | rt-types:route-target 1166 | +--rw (rd-choice)? 1167 | | +--:(directly-assigned) 1168 | | | +--rw rd? 1169 | | | rt-types:route-distinguisher 1170 | | +--:(directly-assigned-suffix) 1171 | | | +--rw rd-suffix? uint16 1172 | | +--:(auto-assigned) 1173 | | | +--rw rd-auto 1174 | | | +--rw (auto-mode)? 1175 | | | | +--:(from-pool) 1176 | | | | | +--rw rd-pool-name? string 1177 | | | | +--:(full-auto) 1178 | | | | +--rw auto? empty 1179 | | | +--ro auto-assigned-rd? 1180 | | | rt-types:route-distinguisher 1181 | | +--:(auto-assigned-suffix) 1182 | | | +--rw rd-auto-suffix 1183 | | | +--rw (auto-mode)? 1184 | | | | +--:(from-pool) 1185 | | | | | +--rw rd-pool-name? string 1186 | | | | +--:(full-auto) 1187 | | | | +--rw auto? empty 1188 | | | +--ro auto-assigned-rd-suffix? uint16 1189 | | +--:(no-rd) 1190 | | +--rw no-rd? empty 1191 | +--rw vpn-target* [id] 1192 | | +--rw id uint8 1193 | | +--rw route-targets* [route-target] 1194 | | | +--rw route-target rt-types:route-target 1195 | | +--rw route-target-type 1196 | | rt-types:route-target-type 1197 | +--rw vpn-policies 1198 | +--rw import-policy? string 1199 | +--rw export-policy? string 1200 +--rw signaling-option 1201 | ... 1202 +--rw vpn-network-accesses 1203 ... 1205 Figure 9: BGP Auto-Discovery Subtree 1207 As discussed in Section 1 of [RFC6624], all of BGP-based methods 1208 include the notion of a VPN identifier that serves to unify 1209 components of a given VPN and the concept of auto-discovery; hence 1210 the support of the data node 'vpn-id'. 1212 For the particular case of EVPN, the L2NM supports RT auto-derivation 1213 based on the Ethernet Tag ID specified in Section 7.10.1 of 1214 [RFC7432]. A VPN service provider can enable/disable this 1215 functionality by means of 'auto-rt-enable'. The assigned RT can be 1216 retrieved using 'auto-route-target'. 1218 For all BGP-based L2VPN flavors, other data nodes such as RD and RT 1219 are used. These data nodes have the same structure as the one 1220 discussed in Section 7.4. 1222 7.5.2. Signaling Options 1224 The 'signaling-option' container (Figure 10) defines a set of data 1225 nodes for a given signaling protocol that is used for an L2VPN 1226 service. As discussed in Section 7.3, several signaling options to 1227 exchange membership information between PEs of an L2VPN are 1228 supported. The signaling type to be used for an L2VPN service is 1229 controlled at the VPN service level by means of 'signaling-type'. 1231 ... 1232 +--rw vpn-nodes 1233 +--rw vpn-node* [vpn-node-id] 1234 ... 1235 +--rw signaling-option 1236 | +--rw advertise-mtu? boolean 1237 | +--rw mtu-allow-mismatch? boolean 1238 | +--rw signaling-type? leafref 1239 | +--rw (signaling-option)? 1240 | +--:(bgp) 1241 | | ... 1242 | +--:(ldp-or-l2tp) 1243 | +--rw ldp-or-l2tp 1244 | ... 1245 | +--rw (ldp-or-l2tp)? 1246 | +--:(ldp) 1247 | | ... 1248 | +--:(l2tp) 1249 | ... 1251 Figure 10: Signaling Option Overall Subtree 1253 The following signaling data nodes are supported: 1255 'advertise-mtu': Controls whether MTU is advertised when setting a 1256 pseudowire (e.g., Section 4.3 of [RFC4667], Section 5.1 of 1257 [RFC6624], or Section 6.1 of [RFC4762]). 1259 'mtu-allow-mismatch': When set to true, it allows MTU mismatch for a 1260 pseudowire (see, e.g., Section 4.3 of [RFC4667]). 1262 'signaling-type': Indicates the signaling type. This type inherits 1263 the value of 'signaling-type' defined at the service level 1264 (Section 7.3). 1266 'bgp': Is provided when BGP is used for L2VPN signaling. Refer to 1267 Section 7.5.2.1 for more details. 1269 'ldp': The model supports the configuration of the parameters that 1270 are discussed in Section 6 of [RFC4762]. Refer to Section 7.5.2.2 1271 for more details. 1273 'l2tp': The model supports the configuration of the parameters that 1274 are discussed in Section 4 of [RFC4667]. Refer to Section 7.5.2.3 1275 for more details. 1277 Note that LDP and L2TP choices are bundled ("ldp-or-l2tp") because 1278 they share a set of common parameters that are further detailed in 1279 Sections 7.5.2.2 and 7.5.2.3. 1281 7.5.2.1. BGP 1283 The structure of the BGP-related data nodes is provided in Figure 11. 1285 ... 1286 | +--rw (signaling-option)? 1287 | ... 1288 | +--:(bgp) 1289 | | +--rw (bgp-type)? 1290 | | +--:(l2vpn-bgp) 1291 | | | +--rw ce-range? uint16 1292 | | | +--rw pw-encapsulation-type? 1293 | | | | identityref 1294 | | | +--rw vpls-instance 1295 | | | +--rw vpls-edge-id? uint16 1296 | | | +--rw vpls-edge-id-range? uint16 1297 | | +--:(evpn-bgp) 1298 | | +--rw evpn-type? leafref 1299 | | +--rw service-interface-type? 1300 | | | identityref 1301 | | +--rw evpn-policies 1302 | | +--rw mac-learning-mode? 1303 | | | identityref 1304 | | +--rw ingress-replication? 1305 | | | boolean 1306 | | +--rw p2mp-replication? 1307 | | | boolean 1308 | | +--rw arp-proxy {vpn-common:ipv4}? 1309 | | | +--rw enable? boolean 1310 | | | +--rw arp-suppression? 1311 | | | | boolean 1312 | | | +--rw ip-mobility-threshold? 1313 | | | | uint16 1314 | | | +--rw duplicate-ip-detection-interval? 1315 | | | uint16 1316 | | +--rw nd-proxy {vpn-common:ipv6}? 1317 | | | +--rw enable? boolean 1318 | | | +--rw nd-suppression? 1319 | | | | boolean 1320 | | | +--rw ip-mobility-threshold? 1321 | | | | uint16 1322 | | | +--rw duplicate-ip-detection-interval? 1323 | | | uint16 1324 | | +--rw underlay-multicast? 1325 | | | boolean 1326 | | +--rw flood-unknown-unicast-supression? 1327 | | | boolean 1328 | | +--rw vpws-vlan-aware? boolean 1329 | | +--rw bum-management 1330 | | | +--rw discard-broadcast? 1331 | | | | boolean 1332 | | | +--rw discard-unknown-multicast? 1333 | | | | boolean 1334 | | | +--rw discard-unknown-unicast? 1335 | | | boolean 1336 | | +--rw pbb 1337 | | +--rw backbone-src-mac? 1338 | | yang:mac-address 1339 | +--:(ldp-or-l2tp) 1340 | ... 1342 Figure 11: Signaling Option Subtree (BGP) 1344 Remote CEs that are entitled to connect to the same VPN should fit 1345 with the CE range ('ce-range') as discussed in Section 2.2.3 of 1346 [RFC6624]. 'pw-encapsulation-type' is used to control the pseudowire 1347 encapsulation type (Section 3 of [RFC6624]). The value of the 'pw- 1348 encapsulation-type' are taken from the IANA-maintained "iana-bgp- 1349 l2-encaps" module (Section 8.1). 1351 For the specific case of VPLS, the VPLS Edge ID (VE ID, 'vpls-edge- 1352 id') and a VE ID range ('vpls-edge-id-range') are provided as per 1353 Section 3.2 of [RFC4761]. If different VE IDs are required (e.g., 1354 multihoming as per Section 3.5 of [RFC4761]), these IDs are 1355 configured at the VPN network access level (under 'signaling-option' 1356 in Section 7.6). 1358 For EVPN-related L2VPNs, 'service-interface-type' indicates whether 1359 this is a VLAN-based, VLAN bundle, or VLAN-aware bundle service 1360 interface (Section 6 of [RFC7432]). Moreover, a set of policies can 1361 be provided such as MAC address learning mode (Section 9 of 1362 [RFC7432]), ingress replication (Section 12.1 of [RFC7432]), Address 1363 Resolution Protocol (ARP) and Nighbor Discovery (ND) proxy 1364 (Section 10 of [RFC7432]), processing of Broadcast, unknown unicast, 1365 or multicast (BUM) (Section 12 of [RFC7432]), etc. 1367 7.5.2.2. LDP 1369 The model supports the configuration of the parameters that are 1370 discussed in Section 6 of [RFC4762]. Such parameters include an 1371 Attachment Group Identifier (AGI) (a.k.a., VPLS-id), a Source 1372 Attachment Individual Identifier (SAII), a list of peers that are 1373 associated with a Target Attachment Individual Identifier (TAII), a 1374 pseudowire type, and a pseudowire description (Figure 12). Unlike 1375 BGP, only Ethernet and Ethernet tagged mode are supported. The AGI, 1376 SAII, and TAII are encoded following the types defined in Section 3.4 1377 of [RFC4446]. 1379 ... 1380 | +--rw (signaling-option)? 1381 | ... 1382 | +--:(bgp) 1383 | | ... 1384 | +--:(ldp-or-l2tp) 1385 | +--rw ldp-or-l2tp 1386 | +--rw agi? 1387 | | rt-types:route-distinguisher 1388 | +--rw saii? uint32 1389 | +--rw remote-targets* [taii] 1390 | | +--rw taii uint32 1391 | | +--rw peer-addr inet:ip-address 1392 | +--rw (ldp-or-l2tp)? 1393 | +--:(ldp) 1394 | | +--rw t-ldp-pw-type? 1395 | | | identityref 1396 | | +--rw pw-type? identityref 1397 | | +--rw pw-description? string 1398 | | +--rw mac-addr-withdraw? boolean 1399 | | +--rw pw-peer-list* 1400 | | | [peer-addr vc-id] 1401 | | | +--rw peer-addr 1402 | | | | inet:ip-address 1403 | | | +--rw vc-id string 1404 | | | +--rw pw-priority? uint32 1405 | | +--rw qinq 1406 | | +--rw s-tag dot1q-types:vlanid 1407 | | +--rw c-tag dot1q-types:vlanid 1408 | +--:(l2tp) 1409 | ... 1410 ... 1412 Figure 12: Signaling Option Subtree (LDP) 1414 7.5.2.3. L2TP 1416 The model supports the configuration of the parameters that are 1417 discussed in Section 4 of [RFC4667]. Such parameters include a 1418 Router ID that is used to uniquely identify a PE, a pseudowire type, 1419 an AGI, an SAII, and a list of peers that are associated with a TAII 1420 (Figure 13). The pseudowire type ('pseudowire-type') value is taken 1421 from the IANA-maintained "iana-pseudowire-types" module 1422 (Section 8.2). 1424 ... 1425 | +--rw (signaling-option)? 1426 | ... 1427 | +--:(bgp) 1428 | | ... 1429 | +--:(ldp-or-l2tp) 1430 | +--rw ldp-or-l2tp 1431 | +--rw agi? 1432 | | rt-types:route-distinguisher 1433 | +--rw saii? uint32 1434 | +--rw remote-targets* [taii] 1435 | | +--rw taii uint32 1436 | | +--rw peer-addr inet:ip-address 1437 | +--rw (ldp-or-l2tp)? 1438 | +--:(ldp) 1439 | | ... 1440 | +--:(l2tp) 1441 | +--rw router-id? 1442 | | rt-types:router-id 1443 | +--rw pseudowire-type? 1444 | identityref 1445 ... 1447 Figure 13: Signaling Option Subtree (L2TP) 1449 7.6. VPN Network Accesses 1451 A 'vpn-network-access' (Figure 14) represents an entry point to a VPN 1452 service. In other words, this container encloses the parameters that 1453 describe the access information for the traffic that belongs to a 1454 particular L2VPN. 1456 A 'vpn-network-access' includes information such as the connection on 1457 which the access is defined, the specific Layer 2 service 1458 requirements, etc. 1460 ... 1461 +--rw vpn-nodes 1462 +--rw vpn-node* [vpn-node-id] 1463 ... 1464 +--rw vpn-network-accesses 1465 +--rw vpn-network-access* [id] 1466 +--rw id vpn-common:vpn-id 1467 +--rw description? string 1468 +--rw interface-id? string 1469 +--rw active-vpn-node-profile? leafref 1470 +--rw status 1471 | ... 1472 +--rw connection 1473 | ... 1474 +--rw (signaling-option)? 1475 | +--:(bgp) 1476 | +--rw (bgp-type)? 1477 | +--:(l2vpn-bgp) 1478 | | +--rw ce-id? uint16 1479 | | +--rw remote-ce-id? uint16 1480 | | +--rw vpls-instance 1481 | | +--rw vpls-edge-id? uint16 1482 | +--:(evpn-bgp) 1483 | +--rw df-preference? uint16 1484 | +--rw vpws-service-instance 1485 | ... 1486 +--rw group* [group-id] 1487 | +--rw group-id string 1488 | +--rw precedence? identityref 1489 | +--rw ethernet-segment-identifier? 1490 | l2vpn-es:es-ref 1491 +--rw ethernet-service-oam 1492 | ... 1493 +--rw service 1494 ... 1496 Figure 14: VPN Network Access Subtree 1498 The VPN network access comprises: 1500 'id': Includes an identifier of the VPN network access. 1502 'description': Includes a textual description of the VPN network 1503 access. 1505 'interface-id': Indicates the interface on which the VPN network 1506 access is bound. 1508 'active-vpn-node-profile': Provides a pointer to an active 'global- 1509 parameters-profile' at the VPN node level. Referencing an active 1510 'global-parameters-profile' implies that all associated data nodes 1511 will be inherited by the VPN network access. However, some of the 1512 inherited data nodes (e.g., ACL policies) can be overridden at the 1513 VPN network access level. In such case, adjusted values take 1514 precedence over inherited values. 1516 'status': Indicates the administrative and operational status of the 1517 VPN network access. 1519 'connection': Represents and groups the set of Layer 2 connectivity 1520 from where the traffic of the L2VPN in a particular VPN Network 1521 access is coming. See Section 7.6.1. 1523 'signaling-option': Indicates a set of signaling options that are 1524 specific to a given VPN network access, e.g., a CE ID ('ce-id' 1525 identifying the CE within the VPN) and a remote CE ID as discussed 1526 in Section 2.2.2 of [RFC6624]. 1528 It can also include a set of data nodes that are required for the 1529 configuration of a VPWS-EVPN [RFC8214]. See Section 7.6.2. 1531 'group': Is used for grouping VPN network accesses by assigning the 1532 same identifier to these accesses. The precedence attribute is 1533 used to differentiate the primary and secondary accesses for a 1534 service with multiple accesses. An example to illustrate the use 1535 of this container for redundancy purposes is provided in 1536 Appendix A.6. This container is also used to identify the link of 1537 an ES by allocating the same ESI. An example to illustrate this 1538 functionality is provided in Appendices A.4 and A.5. 1540 'ethernet-service-oam': Carries information about the service OAM. 1541 See Section 7.6.3. 1543 'service': Specifies the service parameters (e.g., QoS, multicast) 1544 to apply for a given VPN network access. See Section 7.6.4. 1546 7.6.1. Connection 1548 The 'connection' container (Figure 15) is used to configure the 1549 relevant properties of the interface to which the L2VPN instance is 1550 attached to (e.g., encapsulation type, Link Aggregation Group (LAG) 1551 interfaces, split-horizon). The L2NM supports tag manipulation 1552 operations (e.g., tag rewrite). 1554 Note that the 'connection' container does not include the physical- 1555 specific configuration as this is assumed to be directly handled 1556 using device modules (e.g., interfaces module). Moreover, this 1557 design is also meant to avoid manipulated global parameters at the 1558 service level and lower the risk of impacting other services sharing 1559 the same physical interface. 1561 A reference to the bearer is maintained to allow keeping the link 1562 between the L2SM and the L2NM when both data models are used in a 1563 given deployment. 1565 Some consistency checks should be ensured by implementations 1566 (typically, network controllers) for LAG interface as the same 1567 information (e.g., LACP system-id) should be provided to the involved 1568 nodes. 1570 The L2NM inherits the 'member-link-list' structure from the L2SM 1571 (including indication of OAM 802.3ah support [IEEE-802-3ah]). 1573 ... 1574 +--rw vpn-nodes 1575 +--rw vpn-node* [vpn-node-id] 1576 ... 1577 +--rw vpn-network-accesses 1578 +--rw vpn-network-access* [id] 1579 ... 1580 +--rw connection 1581 | +--rw l2-termination-point? 1582 | | string 1583 | +--rw local-bridge-reference? 1584 | | string 1585 | +--rw bearer-reference? string 1586 | | {vpn-common:bearer-reference}? 1587 | +--rw encapsulation 1588 | | +--rw encap-type? identityref 1589 | | +--rw dot1q 1590 | | | +--rw tag-type? identityref 1591 | | | +--rw cvlan-id? 1592 | | | | dot1q-types:vlanid 1593 | | | +--rw tag-operations 1594 | | | +--rw (op-choice)? 1595 | | | | +--:(pop) 1596 | | | | | +--rw pop? empty 1597 | | | | +--:(push) 1598 | | | | | +--rw push? empty 1599 | | | | +--:(translate) 1600 | | | | +--rw translate? empty 1601 | | | +--rw tag-1? 1602 | | | | dot1q-types:vlanid 1603 | | | +--rw tag-1-type? 1604 | | | | dot1q-types:dot1q-tag-type 1605 | | | +--rw tag-2? 1606 | | | | dot1q-types:vlanid 1607 | | | +--rw tag-2-type? 1608 | | | dot1q-types:dot1q-tag-type 1609 | | +--rw priority-tagged 1610 | | | +--rw tag-type? identityref 1611 | | +--rw qinq 1612 | | +--rw tag-type? identityref 1613 | | +--rw svlan-id 1614 | | | dot1q-types:vlanid 1615 | | +--rw cvlan-id 1616 | | | dot1q-types:vlanid 1617 | | +--rw tag-operations 1618 | | +--rw (op-choice)? 1619 | | | +--:(pop) 1620 | | | | +--rw pop? uint8 1621 | | | +--:(push) 1622 | | | | +--rw push? empty 1623 | | | +--:(translate) 1624 | | | +--rw translate? empty 1625 | | +--rw tag-1? 1626 | | | dot1q-types:vlanid 1627 | | +--rw tag-1-type? 1628 | | | dot1q-types:dot1q-tag-type 1629 | | +--rw tag-2? 1630 | | | dot1q-types:vlanid 1631 | | +--rw tag-2-type? 1632 | | dot1q-types:dot1q-tag-type 1633 | +--rw lag-interface 1634 | | {vpn-common:lag-interface}? 1635 | +--rw lag-interface-id? string 1636 | +--rw lacp 1637 | | +--rw lacp-state? boolean 1638 | | +--rw mode? identityref 1639 | | +--rw speed? uint32 1640 | | +--rw mini-link-num? uint32 1641 | | +--rw system-id? 1642 | | | yang:mac-address 1643 | | +--rw admin-key? uint16 1644 | | +--rw system-priority? uint16 1645 | | +--rw member-link-list 1646 | | | +--rw member-link* [name] 1647 | | | +--rw name string 1648 | | | +--rw speed? uint32 1649 | | | +--rw mode? identityref 1650 | | | +--rw link-mtu? uint32 1651 | | | +--rw oam-802.3ah-link 1652 | | | | {oam-3ah}? 1653 | | | +--rw enable? boolean 1654 | | +--rw flow-control? boolean 1655 | | +--rw lldp? boolean 1656 | +--rw split-horizon 1657 | +--rw group-name? string 1658 ... 1660 Figure 15: Connection Subtree 1662 7.6.2. EVPN-VPWS Service Instance 1664 The 'vpws-service-instance' provides the local and remote VPWS 1665 Service Instance (VSI) [RFC8214]. This container is only present 1666 when the 'vpn-type' is VPWS-EVPN. As shown in Figure 16, the VSIs 1667 can be configured by a VPN service provider or auto-generated. 1669 An example to illustrate the use of the L2NM to configure VPWS-EVPN 1670 instances is provided in Appendix A.4. 1672 ... 1673 +--rw vpn-nodes 1674 +--rw vpn-node* [vpn-node-id] 1675 ... 1676 +--rw vpn-network-accesses 1677 +--rw vpn-network-access* [id] 1678 ... 1679 +--rw (signaling-option)? 1680 | +--:(bgp) 1681 | +--rw (bgp-type)? 1682 | +--:(l2vpn-bgp) 1683 | | ... 1684 | +--:(evpn-bgp) 1685 | +--rw df-preference? uint16 1686 | +--rw vpws-service-instance 1687 | +--rw (local-vsi-choice)? 1688 | | +--:(directly-assigned) 1689 | | | +--rw local-vpws-service-instance? 1690 | | | uint32 1691 | | +--:(auto-assigned) 1692 | | +--rw local-vsi-auto 1693 | | +--rw (auto-mode)? 1694 | | | +--:(from-pool) 1695 | | | | +--rw vsi-pool-name? 1696 | | | | string 1697 | | | +--:(full-auto) 1698 | | | +--rw auto? empty 1699 | | +--ro auto-local-vsi? uint32 1700 | +--rw (remote-vsi-choice)? 1701 | +--:(directly-assigned) 1702 | | +--rw remote-vpws-service-instance? 1703 | | uint32 1704 | +--:(auto-assigned) 1705 | +--rw remote-vsi-auto 1706 | +--rw (auto-mode)? 1707 | | +--:(from-pool) 1708 | | | +--rw vsi-pool-name? 1709 | | | string 1710 | | +--:(full-auto) 1711 | | +--rw auto? empty 1712 | +--ro auto-remote-vsi? uint32 1713 ... 1715 Figure 16: EVPN-VPWS Service Instance Subtree 1717 7.6.3. Ethernet OAM 1719 Ethernet OAM refers to both [IEEE-802-1ag] and [ITU-T-Y-1731]. 1721 As shown in Figure 17, the L2NM inherits the same structure as in 1722 Section 5.3.2.2.6 of [RFC8466] for OAM matters. 1724 +--rw l2vpn-ntw 1725 +--rw vpn-profiles 1726 | ... 1727 +--rw vpn-services 1728 +--rw vpn-service* [vpn-id] 1729 ... 1730 +--rw vpn-nodes 1731 +--rw vpn-node* [vpn-node-id] 1732 ... 1733 +--rw vpn-network-accesses 1734 +--rw vpn-network-access* [id] 1735 ... 1736 +--rw ethernet-service-oam 1737 | +--rw md-name? string 1738 | +--rw md-level? uint8 1739 | +--rw cfm-802.1-ag 1740 | | +--rw n2-uni-c* [maid] 1741 | | | +--rw maid string 1742 | | | +--rw mep-id? uint32 1743 | | | +--rw mep-level? uint32 1744 | | | +--rw mep-up-down? 1745 | | | | enumeration 1746 | | | +--rw remote-mep-id? uint32 1747 | | | +--rw cos-for-cfm-pdus? uint32 1748 | | | +--rw ccm-interval? uint32 1749 | | | +--rw ccm-holdtime? uint32 1750 | | | +--rw ccm-p-bits-pri? 1751 | | | ccm-priority-type 1752 | | +--rw n2-uni-n* [maid] 1753 | | +--rw maid string 1754 | | +--rw mep-id? uint32 1755 | | +--rw mep-level? uint32 1756 | | +--rw mep-up-down? 1757 | | | enumeration 1758 | | +--rw remote-mep-id? uint32 1759 | | +--rw cos-for-cfm-pdus? uint32 1760 | | +--rw ccm-interval? uint32 1761 | | +--rw ccm-holdtime? uint32 1762 | | +--rw ccm-p-bits-pri? 1763 | | ccm-priority-type 1764 | +--rw y-1731* [maid] 1765 | +--rw maid string 1766 | +--rw mep-id? uint32 1767 | +--rw pm-type? identityref 1768 | +--rw remote-mep-id? uint32 1769 | +--rw message-period? uint32 1770 | +--rw measurement-interval? uint32 1771 | +--rw cos? uint32 1772 | +--rw loss-measurement? boolean 1773 | +--rw synthethic-loss-measurement? 1774 | | boolean 1775 | +--rw delay-measurement 1776 | | +--rw enable-dm? boolean 1777 | | +--rw two-way? boolean 1778 | +--rw frame-size? uint32 1779 | +--rw session-type? enumeration 1780 ... 1782 Figure 17: OAM Subtree 1784 7.6.4. Services 1786 The 'service' container (Figure 18) provides a set of service- 1787 specific configuration such as Quality of Service (QoS). 1789 +--rw l2vpn-ntw 1790 +--rw vpn-profiles 1791 | ... 1792 +--rw vpn-services 1793 +--rw vpn-service* [vpn-id] 1794 ... 1795 +--rw vpn-nodes 1796 +--rw vpn-node* [vpn-node-id] 1797 ... 1798 +--rw vpn-network-accesses 1799 +--rw vpn-network-access* [id] 1800 ... 1801 +--rw service 1802 +--rw mtu? uint32 1803 +--rw svc-pe-to-ce-bandwidth 1804 | {vpn-common:inbound-bw}? 1805 | ... 1806 +--rw svc-ce-to-pe-bandwidth 1807 | {vpn-common:outbound-bw}? 1808 | ... 1809 +--rw qos {vpn-common:qos}? 1810 | ... 1811 +--rw mac-policies 1812 | ... 1813 +--rw broadcast-unknown-unicast-multicast 1814 ... 1816 Figure 18: Service Overall Subtree 1818 The description of the service data nodes is as follows: 1820 'mtu': Specifies the Layer 2 MTU, in bytes, for the VPN network 1821 access. 1823 'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth': Specify the 1824 service bandwidth for the L2VPN service. 1826 'svc-pe-to-ce-bandwidth' indicates the inbound bandwidth of the 1827 connection (i.e., download bandwidth from the service provider to 1828 the site). 1830 'svc-ce-to-pe-bandwidth' indicates the outbound bandwidth of the 1831 connection (i.e., upload bandwidth from the site to the service 1832 provider). 1834 'svc-pe-to-ce-bandwidth' and 'svc-ce-to-pe-bandwidth' can be 1835 represented using the Committed Information Rate (CIR), the Excess 1836 Information Rate (EIR), or the Peak Information Rate (PIR). 1838 As shown in Figure 19, the structure of service bandwidth data 1839 nodes is inherited from the L2SM [RFC8466]. The following types, 1840 defined in [RFC9181], can be used to indicate the bandwidth type: 1842 'bw-per-cos': The bandwidth is per Class of Service (CoS). 1844 'bw-per-port': The bandwidth is per VPN network access. 1846 'bw-per-site': The bandwidth is to all VPN network accesses that 1847 belong to the same site. 1849 'bw-per-service': The bandwidth is per L2VPN service. 1851 +--rw service 1852 ... 1853 +--rw svc-pe-to-ce-bandwidth 1854 | {vpn-common:inbound-bw}? 1855 | +--rw pe-to-ce-bandwidth* [bw-type] 1856 | +--rw bw-type identityref 1857 | +--rw (type)? 1858 | +--:(per-cos) 1859 | | +--rw cos* [cos-id] 1860 | | +--rw cos-id uint8 1861 | | +--rw cir? uint64 1862 | | +--rw cbs? uint64 1863 | | +--rw eir? uint64 1864 | | +--rw ebs? uint64 1865 | | +--rw pir? uint64 1866 | | +--rw pbs? uint64 1867 | +--:(other) 1868 | +--rw cir? uint64 1869 | +--rw cbs? uint64 1870 | +--rw eir? uint64 1871 | +--rw ebs? uint64 1872 | +--rw pir? uint64 1873 | +--rw pbs? uint64 1874 +--rw svc-ce-to-pe-bandwidth 1875 | {vpn-common:outbound-bw}? 1876 | +--rw ce-to-pe-bandwidth* [bw-type] 1877 | +--rw bw-type identityref 1878 | +--rw (type)? 1879 | +--:(per-cos) 1880 | | +--rw cos* [cos-id] 1881 | | +--rw cos-id uint8 1882 | | +--rw cir? uint64 1883 | | +--rw cbs? uint64 1884 | | +--rw eir? uint64 1885 | | +--rw ebs? uint64 1886 | | +--rw pir? uint64 1887 | | +--rw pbs? uint64 1888 | +--:(other) 1889 | +--rw cir? uint64 1890 | +--rw cbs? uint64 1891 | +--rw eir? uint64 1892 | +--rw ebs? uint64 1893 | +--rw pir? uint64 1894 | +--rw pbs? uint64 1895 ... 1897 Figure 19: Service Bandwidth Subtree 1899 'qos': Is used to define a set of QoS policies to apply on a given 1900 VPN network access (Figure 20). The QoS classification can be 1901 based on many criteria such as source MAC address, destination MAC 1902 address, etc. See also Section 5.10.2.1 of [RFC8466] for more 1903 discussion of QoS classification including the use of color types. 1905 +--rw service 1906 ... 1907 +--rw qos {vpn-common:qos}? 1908 | +--rw qos-classification-policy 1909 | | +--rw rule* [id] 1910 | | +--rw id string 1911 | | +--rw (match-type)? 1912 | | | +--:(match-flow) 1913 | | | | +--rw match-flow 1914 | | | | +--rw dscp? inet:dscp 1915 | | | | +--rw dot1q? uint16 1916 | | | | +--rw pcp? uint8 1917 | | | | +--rw src-mac-address? 1918 | | | | | yang:mac-address 1919 | | | | +--rw dst-mac-address? 1920 | | | | | yang:mac-address 1921 | | | | +--rw color-type? 1922 | | | | | identityref 1923 | | | | +--rw any? empty 1924 | | | +--:(match-application) 1925 | | | +--rw match-application? 1926 | | | identityref 1927 | | +--rw target-class-id? string 1928 | +--rw qos-profile 1929 | +--rw qos-profile* [profile] 1930 | +--rw profile leafref 1931 | +--rw direction? identityref 1932 ... 1934 Figure 20: QoS Subtree 1936 'mac-policies': Lists a set of MAC-related policies such as MAC 1937 ACLs. Similar to [RFC8519], an ACL match can be based upon source 1938 MAC address, source MAC address mask, destination MAC address, 1939 destination MAC address mask, or a combination thereof. 1941 A data frame that matches an ACL can be dropped, flooded, or 1942 trigger an alarm. A rate-limit policy can be defined for handling 1943 frames that match an ACL entry with 'flood' action. 1945 When 'mac-loop-prevention' or 'mac-addr-limit' data nodes are 1946 provided, they take precedence over the ones inlcuded in the 1947 'global-parameters-profile' at the VPN service or VPN node levels. 1949 +--rw service 1950 ... 1951 +--rw mac-policies 1952 | +--rw access-control-list* [name] 1953 | | +--rw name string 1954 | | +--rw src-mac-address* 1955 | | | yang:mac-address 1956 | | +--rw src-mac-address-mask* 1957 | | | yang:mac-address 1958 | | +--rw dst-mac-address* 1959 | | | yang:mac-address 1960 | | +--rw dst-mac-address-mask* 1961 | | | yang:mac-address 1962 | | +--rw action? identityref 1963 | | +--rw rate-limit? decimal64 1964 | +--rw mac-loop-prevention 1965 | | +--rw window? uint32 1966 | | +--rw frequency? uint32 1967 | | +--rw retry-timer? uint32 1968 | | +--rw protection-type? identityref 1969 | +--rw mac-addr-limit 1970 | +--rw limit-number? uint16 1971 | +--rw time-interval? uint32 1972 | +--rw action? identityref 1973 ... 1975 Figure 21: MAC Policies Subtree 1977 'broadcast-unknown-unicast-multicast': Defines the type of site in 1978 the customer multicast service topology: source, receiver, or 1979 both. It is also used to define multicast group-to-port mappings. 1981 +--rw service 1982 ... 1983 +--rw broadcast-unknown-unicast-multicast 1984 +--rw multicast-site-type? 1985 | enumeration 1986 +--rw multicast-gp-address-mapping* [id] 1987 | +--rw id uint16 1988 | +--rw vlan-id uint32 1989 | +--rw mac-gp-address 1990 | | yang:mac-address 1991 | +--rw port-lag-number? uint32 1992 +--rw bum-overall-rate? uint64 1994 Figure 22: BUM Subtree 1996 8. YANG Modules 1998 8.1. IANA-Maintained Module for BGP Layer 2 Encapsulation Types 2000 The "iana-bgp-l2-encaps" YANG module echoes the registry available at 2001 [IANA-BGP-L2]. 2003 This module references [RFC3032], [RFC4446], [RFC4448], [RFC4553], 2004 [RFC4618], [RFC4619], [RFC4717], [RFC4761], [RFC4816], [RFC4842], and 2005 [RFC5086]. 2007 2008 file "iana-bgp-l2-encaps@2021-07-05.yang" 2009 module iana-bgp-l2-encaps { 2010 yang-version 1.1; 2011 namespace "urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps"; 2012 prefix iana-bgp-l2-encaps; 2014 organization 2015 "IANA"; 2016 contact 2017 "Internet Assigned Numbers Authority 2019 Postal: ICANN 2020 12025 Waterfront Drive, Suite 300 2021 Los Angeles, CA 90094-2536 2022 United States of America 2023 Tel: +1 310 301 5800 2024 "; 2025 description 2026 "This module contains a collection of IANA-maintained YANG 2027 data types that are used for referring to BGP Layer 2 2028 encapsulation types. 2030 Copyright (c) 2022 IETF Trust and the persons identified as 2031 authors of the code. All rights reserved. 2033 Redistribution and use in source and binary forms, with or 2034 without modification, is permitted pursuant to, and subject 2035 to the license terms contained in, the Revised BSD License 2036 set forth in Section 4.c of the IETF Trust's Legal Provisions 2037 Relating to IETF Documents 2038 (https://trustee.ietf.org/license-info). 2040 This version of this YANG module is part of RFC XXXX; see 2041 the RFC itself for full legal notices."; 2043 revision 2021-07-05 { 2044 description 2045 "First revision."; 2046 reference 2047 "RFC XXXX: A YANG Network Data Model for Layer 2 VPNs."; 2048 } 2050 identity bgp-l2-encaps-type { 2051 description 2052 "Base BGP Layer 2 encapsulation type."; 2053 reference 2054 "RFC 6624: Layer 2 Virtual Private Networks Using BGP for 2055 Auto-Discovery and Signaling"; 2056 } 2058 identity frame-relay { 2059 base bgp-l2-encaps-type; 2060 description 2061 "Frame Relay."; 2062 reference 2063 "RFC 4446: IANA Allocations for Pseudowire Edge 2064 to Edge Emulation (PWE3)"; 2065 } 2067 identity atm-aal5 { 2068 base bgp-l2-encaps-type; 2069 description 2070 "ATM AAL5 SDU VCC transport."; 2071 reference 2072 "RFC 4446: IANA Allocations for Pseudowire Edge 2073 to Edge Emulation (PWE3)"; 2074 } 2076 identity atm-cell { 2077 base bgp-l2-encaps-type; 2078 description 2079 "ATM transparent cell transport."; 2080 reference 2081 "RFC 4816: Pseudowire Emulation Edge-to-Edge (PWE3) 2082 Asynchronous Transfer Mode (ATM) Transparent 2083 Cell Transport Service"; 2084 } 2086 identity ethernet-tagged-mode { 2087 base bgp-l2-encaps-type; 2088 description 2089 "Ethernet (VLAN) Tagged Mode."; 2090 reference 2091 "RFC 4448: Encapsulation Methods for Transport of Ethernet 2092 over MPLS Networks"; 2093 } 2095 identity ethernet-raw-mode { 2096 base bgp-l2-encaps-type; 2097 description 2098 "Ethernet Raw Mode."; 2099 reference 2100 "RFC 4448: Encapsulation Methods for Transport of Ethernet 2101 over MPLS Networks"; 2102 } 2104 identity hdlc { 2105 base bgp-l2-encaps-type; 2106 description 2107 "Cisco HDLC."; 2108 reference 2109 "RFC 4618: Encapsulation Methods for Transport of 2110 PPP/High-Level Data Link Control (HDLC) 2111 over MPLS Networks"; 2112 } 2114 identity ppp { 2115 base bgp-l2-encaps-type; 2116 description 2117 "PPP."; 2118 reference 2119 "RFC 4618: Encapsulation Methods for Transport of 2120 PPP/High-Level Data Link Control (HDLC) 2121 over MPLS Networks"; 2122 } 2124 identity circuit-emulation { 2125 base bgp-l2-encaps-type; 2126 description 2127 "SONET/SDH Circuit Emulation Service."; 2128 reference 2129 "RFC 4842: Synchronous Optical Network/Synchronous Digital 2130 Hierarchy (SONET/SDH) Circuit Emulation over Packet 2131 (CEP)"; 2132 } 2134 identity atm-to-vcc { 2135 base bgp-l2-encaps-type; 2136 description 2137 "ATM n-to-one VCC cell transport."; 2138 reference 2139 "RFC 4717: Encapsulation Methods for Transport of 2140 Asynchronous Transfer Mode (ATM) over MPLS 2141 Networks"; 2142 } 2144 identity atm-to-vpc { 2145 base bgp-l2-encaps-type; 2146 description 2147 "ATM n-to-one VPC cell transport."; 2148 reference 2149 "RFC 4717: Encapsulation Methods for Transport of 2150 Asynchronous Transfer Mode (ATM) over MPLS 2151 Networks"; 2152 } 2154 identity layer-2-transport { 2155 base bgp-l2-encaps-type; 2156 description 2157 "IP Layer 2 Transport."; 2158 reference 2159 "RFC 3032: MPLS Label Stack Encoding"; 2160 } 2162 identity fr-port-mode { 2163 base bgp-l2-encaps-type; 2164 description 2165 "Frame Relay Port mode."; 2166 reference 2167 "RFC 4619: Encapsulation Methods for Transport of Frame Relay 2168 over Multiprotocol Label Switching (MPLS) 2169 Networks"; 2170 } 2172 identity e1 { 2173 base bgp-l2-encaps-type; 2174 description 2175 "Structure-agnostic E1 over packet."; 2176 reference 2177 "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) 2178 over Packet (SAToP)"; 2179 } 2181 identity t1 { 2182 base bgp-l2-encaps-type; 2183 description 2184 "Structure-agnostic T1 (DS1) over packet."; 2186 reference 2187 "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) 2188 over Packet (SAToP)"; 2189 } 2191 identity vpls { 2192 base bgp-l2-encaps-type; 2193 description 2194 "VPLS."; 2195 reference 2196 "RFC 4761: Virtual Private LAN Service (VPLS) 2197 Using BGP for Auto-Discovery and Signaling"; 2198 } 2200 identity t3 { 2201 base bgp-l2-encaps-type; 2202 description 2203 "Structure-agnostic T3 (DS3) over packet."; 2204 reference 2205 "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) 2206 over Packet (SAToP)"; 2207 } 2209 identity structure-aware { 2210 base bgp-l2-encaps-type; 2211 description 2212 "Nx64kbit/s Basic Service using Structure-aware."; 2213 reference 2214 "RFC 5086: Structure-Aware Time Division Multiplexed (TDM) 2215 Circuit Emulation Service over Packet Switched 2216 Network (CESoPSN)"; 2217 } 2219 identity dlci { 2220 base bgp-l2-encaps-type; 2221 description 2222 "Frame Relay DLCI."; 2223 reference 2224 "RFC 4619: Encapsulation Methods for Transport of Frame Relay 2225 over Multiprotocol Label Switching (MPLS) 2226 Networks"; 2227 } 2229 identity e3 { 2230 base bgp-l2-encaps-type; 2231 description 2232 "Structure-agnostic E3 over packet."; 2233 reference 2234 "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) 2235 over Packet (SAToP)"; 2236 } 2238 identity ds1 { 2239 base bgp-l2-encaps-type; 2240 description 2241 "Octet-aligned payload for Structure-agnostic DS1 circuits."; 2242 reference 2243 "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) 2244 over Packet (SAToP)"; 2245 } 2247 identity cas { 2248 base bgp-l2-encaps-type; 2249 description 2250 "E1 Nx64kbit/s with CAS using Structure-aware."; 2251 reference 2252 "RFC 5086: Structure-Aware Time Division Multiplexed (TDM) 2253 Circuit Emulation Service over Packet Switched 2254 Network (CESoPSN)"; 2255 } 2257 identity esf { 2258 base bgp-l2-encaps-type; 2259 description 2260 "DS1 (ESF) Nx64kbit/s with CAS using Structure-aware."; 2261 reference 2262 "RFC 5086: Structure-Aware Time Division Multiplexed (TDM) 2263 Circuit Emulation Service over Packet Switched 2264 Network (CESoPSN)"; 2265 } 2267 identity sf { 2268 base bgp-l2-encaps-type; 2269 description 2270 "DS1 (SF) Nx64kbit/s with CAS using Structure-aware."; 2271 reference 2272 "RFC 5086: Structure-Aware Time Division Multiplexed (TDM) 2273 Circuit Emulation Service over Packet Switched 2274 Network (CESoPSN)"; 2275 } 2276 } 2277 2279 8.2. IANA-Maintained Module for Pseudowire Types 2281 The initial version of the "iana-pseudowire-types" YANG module echoes 2282 the registry available at [IANA-PW-Types]. 2284 This module references [MFA], [RFC2507], [RFC2508], [RFC3032], 2285 [RFC3545], [RFC4448], [RFC4618], [RFC4619], [RFC4717], [RFC4842], 2286 [RFC4863], [RFC4901], [RFC5086], [RFC5087], [RFC5143], [RFC5795], and 2287 [RFC6307]. 2289 2290 file "iana-pseudowire-types@2021-07-05.yang" 2291 module iana-pseudowire-types { 2292 yang-version 1.1; 2293 namespace "urn:ietf:params:xml:ns:yang:iana-pseudowire-types"; 2294 prefix iana-pw-types; 2296 organization 2297 "IANA"; 2298 contact 2299 "Internet Assigned Numbers Authority 2301 Postal: ICANN 2302 12025 Waterfront Drive, Suite 300 2303 Los Angeles, CA 90094-2536 2304 United States of America 2305 Tel: +1 310 301 5800 2306 "; 2307 description 2308 "This module contains a collection of IANA-maintained YANG 2309 data types that are used for referring to Pseudowire Types. 2311 Copyright (c) 2022 IETF Trust and the persons identified as 2312 authors of the code. All rights reserved. 2314 Redistribution and use in source and binary forms, with or 2315 without modification, is permitted pursuant to, and subject 2316 to the license terms contained in, the Revised BSD License 2317 set forth in Section 4.c of the IETF Trust's Legal Provisions 2318 Relating to IETF Documents 2319 (https://trustee.ietf.org/license-info). 2321 This version of this YANG module is part of RFC XXXX; see 2322 the RFC itself for full legal notices."; 2324 revision 2021-07-05 { 2325 description 2326 "First revision."; 2328 reference 2329 "RFC XXXX: A YANG Network Data Model for Layer 2 VPNs."; 2330 } 2332 identity iana-pw-types { 2333 description 2334 "Base Pseudowire Layer 2 encapsulation type."; 2335 } 2337 identity frame-relay { 2338 base iana-pw-types; 2339 description 2340 "Frame Relay DLCI (Martini Mode)."; 2341 reference 2342 "RFC 4619: Encapsulation Methods for Transport of Frame Relay 2343 over Multiprotocol Label Switching (MPLS) 2344 Networks"; 2345 } 2347 identity atm-aal5 { 2348 base iana-pw-types; 2349 description 2350 "ATM AAL5 SDU VCC transport."; 2351 reference 2352 "RFC 4717: Encapsulation Methods for Transport of 2353 Asynchronous Transfer Mode (ATM) over MPLS 2354 Networks"; 2355 } 2357 identity atm-cell { 2358 base iana-pw-types; 2359 description 2360 "ATM transparent cell transport."; 2361 reference 2362 "RFC 4717: Encapsulation Methods for Transport of 2363 Asynchronous Transfer Mode (ATM) over MPLS 2364 Networks"; 2365 } 2367 identity ethernet-tagged-mode { 2368 base iana-pw-types; 2369 description 2370 "Ethernet (VLAN) Tagged Mode."; 2371 reference 2372 "RFC 4448: Encapsulation Methods for Transport of Ethernet 2373 over MPLS Networks"; 2374 } 2375 identity ethernet { 2376 base iana-pw-types; 2377 description 2378 "Ethernet."; 2379 reference 2380 "RFC 4448: Encapsulation Methods for Transport of Ethernet 2381 over MPLS Networks"; 2382 } 2384 identity hdlc { 2385 base iana-pw-types; 2386 description 2387 "HDLC."; 2388 reference 2389 "RFC 4618: Encapsulation Methods for Transport of 2390 PPP/High-Level Data Link Control (HDLC) 2391 over MPLS Networks"; 2392 } 2394 identity ppp { 2395 base iana-pw-types; 2396 description 2397 "PPP."; 2398 reference 2399 "RFC 4618: Encapsulation Methods for Transport of 2400 PPP/High-Level Data Link Control (HDLC) 2401 over MPLS Networks"; 2402 } 2404 identity circuit-emulation-mpls { 2405 base iana-pw-types; 2406 description 2407 "SONET/SDH Circuit Emulation Service Over MPLS Encapsulation."; 2408 reference 2409 "RFC 5143: Synchronous Optical Network/Synchronous Digital 2410 Hierarchy (SONET/SDH) Circuit Emulation Service over 2411 MPLS (CEM) Encapsulation"; 2412 } 2414 identity atm-to-vcc { 2415 base iana-pw-types; 2416 description 2417 "ATM n-to-one VCC cell transport."; 2418 reference 2419 "RFC 4717: Encapsulation Methods for Transport of 2420 Asynchronous Transfer Mode (ATM) over MPLS 2421 Networks"; 2422 } 2423 identity atm-to-vpc { 2424 base iana-pw-types; 2425 description 2426 "ATM n-to-one VPC cell transport."; 2427 reference 2428 "RFC 4717: Encapsulation Methods for Transport of 2429 Asynchronous Transfer Mode (ATM) over MPLS 2430 Networks"; 2431 } 2433 identity layer-2-transport { 2434 base iana-pw-types; 2435 description 2436 "IP Layer2 Transport."; 2437 reference 2438 "RFC 3032: MPLS Label Stack Encoding"; 2439 } 2441 identity atm-one-to-one-vcc { 2442 base iana-pw-types; 2443 description 2444 "ATM one-to-one VCC Cell Mode."; 2445 reference 2446 "RFC 4717: Encapsulation Methods for Transport of 2447 Asynchronous Transfer Mode (ATM) over MPLS 2448 Networks"; 2449 } 2451 identity atm-one-to-one-vpc { 2452 base iana-pw-types; 2453 description 2454 "ATM one-to-one VPC Cell Mode."; 2455 reference 2456 "RFC 4717: Encapsulation Methods for Transport of 2457 Asynchronous Transfer Mode (ATM) over MPLS 2458 Networks"; 2459 } 2461 identity atm-aal5-vcc { 2462 base iana-pw-types; 2463 description 2464 "ATM AAL5 PDU VCC transport."; 2465 reference 2466 "RFC 4717: Encapsulation Methods for Transport of 2467 Asynchronous Transfer Mode (ATM) over MPLS 2468 Networks"; 2469 } 2470 identity fr-port-mode { 2471 base iana-pw-types; 2472 description 2473 "Frame-Relay Port mode."; 2474 reference 2475 "RFC 4619: Encapsulation Methods for Transport of Frame Relay 2476 over Multiprotocol Label Switching (MPLS) 2477 Networks"; 2478 } 2480 identity circuit-emulation-packet { 2481 base iana-pw-types; 2482 description 2483 "SONET/SDH Circuit Emulation over Packet."; 2484 reference 2485 "RFC 4842: Synchronous Optical Network/Synchronous Digital 2486 Hierarchy (SONET/SDH) Circuit Emulation over Packet 2487 (CEP)"; 2488 } 2490 identity e1 { 2491 base iana-pw-types; 2492 description 2493 "Structure-agnostic E1 over Packet."; 2494 reference 2495 "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) 2496 over Packet (SAToP)"; 2497 } 2499 identity t1 { 2500 base iana-pw-types; 2501 description 2502 "Structure-agnostic T1 (DS1) over Packet."; 2503 reference 2504 "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) 2505 over Packet (SAToP)"; 2506 } 2508 identity e3 { 2509 base iana-pw-types; 2510 description 2511 "Structure-agnostic E3 over Packet."; 2512 reference 2513 "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) 2514 over Packet (SAToP)"; 2515 } 2517 identity t3 { 2518 base iana-pw-types; 2519 description 2520 "Structure-agnostic T3 (DS3) over Packet."; 2521 reference 2522 "RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) 2523 over Packet (SAToP)"; 2524 } 2526 identity ces-over-psn { 2527 base iana-pw-types; 2528 description 2529 "CESoPSN basic mode."; 2530 reference 2531 "RFC 5086: Structure-Aware Time Division Multiplexed (TDM) 2532 Circuit Emulation Service over Packet Switched 2533 Network (CESoPSN)"; 2534 } 2536 identity tdm-over-ip-aal1 { 2537 base iana-pw-types; 2538 description 2539 "TDMoIP AAL1 Mode."; 2540 reference 2541 "RFC 5087: Time Division Multiplexing over IP (TDMoIP)"; 2542 } 2544 identity ces-over-psn-cas { 2545 base iana-pw-types; 2546 description 2547 "CESoPSN TDM with CAS."; 2548 reference 2549 "RFC 5086: Structure-Aware Time Division Multiplexed (TDM) 2550 Circuit Emulation Service over Packet Switched 2551 Network (CESoPSN)"; 2552 } 2554 identity tdm-over-ip-aal2 { 2555 base iana-pw-types; 2556 description 2557 "TDMoIP AAL2 Mode."; 2558 reference 2559 "RFC 5087: Time Division Multiplexing over IP (TDMoIP)"; 2560 } 2562 identity dlci { 2563 base iana-pw-types; 2564 description 2565 "Frame Relay DLCI."; 2567 reference 2568 "RFC 4619: Encapsulation Methods for Transport of Frame Relay 2569 over Multiprotocol Label Switching (MPLS) 2570 Networks"; 2571 } 2573 identity rohc { 2574 base iana-pw-types; 2575 description 2576 "ROHC Transport Header-compressed Packets."; 2577 reference 2578 "RFC 5795: The RObust Header Compression (ROHC) Framework 2579 RFC 4901: Protocol Extensions for Header Compression over 2580 MPLS"; 2581 } 2583 identity ecrtp { 2584 base iana-pw-types; 2585 description 2586 "ECRTP Transport Header-compressed Packets."; 2587 reference 2588 "RFC 3545: Enhanced Compressed RTP (CRTP) for Links with High 2589 Delay, Packet Loss and Reordering 2590 RFC 4901: Protocol Extensions for Header Compression over 2591 MPLS"; 2592 } 2594 identity iphc { 2595 base iana-pw-types; 2596 description 2597 "IPHC Transport Header-compressed Packets."; 2598 reference 2599 "RFC 2507: IP Header Compression 2600 RFC 4901: Protocol Extensions for Header Compression over 2601 MPLS"; 2602 } 2604 identity crtp { 2605 base iana-pw-types; 2606 description 2607 "cRTP Transport Header-compressed Packets."; 2608 reference 2609 "RFC 2508: Compressing IP/UDP/RTP Headers for Low-Speed Serial 2610 Links 2611 RFC 4901: Protocol Extensions for Header Compression over 2612 MPLS"; 2613 } 2614 identity atm-vp-virtual-trunk { 2615 base iana-pw-types; 2616 description 2617 "ATM VP Virtual Trunk."; 2618 reference 2619 "MFA Forum: The Use of Virtual Trunks for ATM/MPLS 2620 Control Plane Interworking Specification"; 2621 } 2623 identity fc-port-mode { 2624 base iana-pw-types; 2625 description 2626 "FC Port Mode."; 2627 reference 2628 "RFC 6307: Encapsulation Methods for Transport of 2629 Fibre Channel Traffic over MPLS Networks"; 2630 } 2632 identity wildcard { 2633 base iana-pw-types; 2634 description 2635 "Wildcard."; 2636 reference 2637 "RFC 4863: Wildcard Pseudowire Type"; 2638 } 2639 } 2640 2642 8.3. Ethernet Segments 2644 The "ietf-ethernet-segment" YANG module uses types defined in 2645 [RFC6991]. 2647 2648 file "ietf-ethernet-segment@2022-05-25.yang" 2649 module ietf-ethernet-segment { 2650 yang-version 1.1; 2651 namespace "urn:ietf:params:xml:ns:yang:ietf-ethernet-segment"; 2652 prefix l2vpn-es; 2654 import ietf-yang-types { 2655 prefix yang; 2656 reference 2657 "RFC 6991: Common YANG Data Types, Section 3"; 2658 } 2660 organization 2661 "IETF OPSA (Operations and Management Area) Working Group"; 2663 contact 2664 "WG Web: 2665 WG List: 2667 Editor: Mohamed Boucadair 2668 2669 Editor: Samier Barguil 2670 2671 Author: Oscar Gonzalez de Dios 2672 "; 2673 description 2674 "This YANG module defines a model for Ethernet Segments. 2676 Copyright (c) 2021 IETF Trust and the persons identified as 2677 authors of the code. All rights reserved. 2679 Redistribution and use in source and binary forms, with or 2680 without modification, is permitted pursuant to, and subject 2681 to the license terms contained in, the Revised BSD License 2682 set forth in Section 4.c of the IETF Trust's Legal Provisions 2683 Relating to IETF Documents 2684 (https://trustee.ietf.org/license-info). 2686 This version of this YANG module is part of RFC XXXX; see 2687 the RFC itself for full legal notices."; 2689 revision 2022-05-25 { 2690 description 2691 "Initial version."; 2692 reference 2693 "RFC XXXX: A YANG Network Data Model for Layer 2 VPNs."; 2694 } 2696 /* Typedefs */ 2698 typedef es-ref { 2699 type leafref { 2700 path "/l2vpn-es:ethernet-segments/l2vpn-es:ethernet-segment" 2701 + "/l2vpn-es:name"; 2702 } 2703 description 2704 "Defines a type for referencing an Ethernet segment in 2705 other modules."; 2706 } 2708 /* Identities */ 2710 identity esi-type { 2711 description 2712 "T-(Ethernet Segment Identifier (ESI) Type) is a 1-octet field 2713 (most significant octet) that specifies the format of the 2714 remaining 9 octets (ESI Value)."; 2715 reference 2716 "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 5"; 2717 } 2719 identity esi-type-0-operator { 2720 base esi-type; 2721 description 2722 "This type indicates an arbitrary 9-octet ESI value, 2723 which is managed and configured by the operator."; 2724 } 2726 identity esi-type-1-lacp { 2727 base esi-type; 2728 description 2729 "When IEEE 802.1AX Link Aggregation Control Protocol (LACP) 2730 is used between the Provider Edge (PE) and Customer Edge (CE) 2731 devices, this ESI type indicates an auto-generated ESI value 2732 determined from LACP."; 2733 reference 2734 "IEEE Std. 802.1AX: Link Aggregation"; 2735 } 2737 identity esi-type-2-bridge { 2738 base esi-type; 2739 description 2740 "The ESI value is auto-generated and determined based 2741 on the Layer 2 bridge protocol."; 2742 } 2744 identity esi-type-3-mac { 2745 base esi-type; 2746 description 2747 "This type indicates a MAC-based ESI value that can be 2748 auto-generated or configured by the operator."; 2749 } 2751 identity esi-type-4-router-id { 2752 base esi-type; 2753 description 2754 "This type indicates a Router ID ESI value that can be 2755 auto-generated or configured by the operator."; 2756 } 2758 identity esi-type-5-asn { 2759 base esi-type; 2760 description 2761 "This type indicates an Autonomous System (AS)-based ESI value 2762 that can be auto-generated or configured by the operator."; 2763 } 2765 identity df-election-methods { 2766 description 2767 "Base Identity Designated Forwarder (DF) election method."; 2768 } 2770 identity default-7432 { 2771 base df-election-methods; 2772 description 2773 "The default DF election method. 2775 The default procedure for DF election at the granularity of 2776 for VLAN-based service or for 2777 VLAN-(aware) bundle service is referred to as 2778 'service carving'."; 2779 reference 2780 "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 8.5"; 2781 } 2783 identity highest-random-weight { 2784 base df-election-methods; 2785 description 2786 "The highest random weight (HRW) method."; 2787 reference 2788 "RFC 8584: Framework for Ethernet VPN Designated 2789 Forwarder Election Extensibility, Section 3"; 2790 } 2792 identity preference { 2793 base df-election-methods; 2794 description 2795 "The preference based method. PEs are assigned with 2796 preferences to become the DF in the Ethernet Segment (ES). 2797 The exact preference-based algorithm (e.g., lowest-preference 2798 algorithm, highest-preference algorithm) to use is 2799 signaled at the control plane."; 2800 } 2802 identity es-redundancy-mode { 2803 description 2804 "Base identity for ES redundancy modes."; 2805 } 2806 identity single-active { 2807 base es-redundancy-mode; 2808 description 2809 "Indicates Single-Active redundancy mode for a given ES."; 2810 reference 2811 "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1.1"; 2812 } 2814 identity all-active { 2815 base es-redundancy-mode; 2816 description 2817 "Indicates All-Active redundancy mode for a given ES."; 2818 reference 2819 "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1.2"; 2820 } 2822 /* Main Ethernet Segment Container */ 2824 container ethernet-segments { 2825 description 2826 "Top container for the Ethernet Segment Identifier (ESI)."; 2827 list ethernet-segment { 2828 key "name"; 2829 description 2830 "Top list for ESIs."; 2831 leaf name { 2832 type string; 2833 description 2834 "Includes the name of the Ethernet Segment (ES) that 2835 is used to unambiguously identify an ES."; 2836 } 2837 leaf esi-type { 2838 type identityref { 2839 base esi-type; 2840 } 2841 default "esi-type-0-operator"; 2842 description 2843 "T-(ESI Type) is a 1-octet field (most significant 2844 octet) that specifies the format of the remaining 2845 9 octets (ESI Value)."; 2846 reference 2847 "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 5"; 2848 } 2849 choice esi-choice { 2850 description 2851 "Ethernet segment choice between several types. 2852 For ESI Type 0: The esi is directly configured by the 2853 operator. 2855 For ESI Type 1: The auto-mode must be used. 2856 For ESI Type 2: The auto-mode must be used. 2857 For ESI Type 3: The directly-assigned or auto-mode must 2858 be used. 2859 For ESI Type 4: The directly-assigned or auto-mode must 2860 be used. 2861 For ESI Type 5: The directly-assigned or auto-mode must 2862 be used."; 2863 case directly-assigned { 2864 description 2865 "Explicitly assign an ESI value."; 2866 leaf ethernet-segment-identifier { 2867 type yang:hex-string { 2868 length "29"; 2869 } 2870 description 2871 "10-octet ESI."; 2872 } 2873 } 2874 case auto-assigned { 2875 description 2876 "The ESI is auto-assigned."; 2877 container esi-auto { 2878 description 2879 "The ESI is auto-assigned."; 2880 choice auto-mode { 2881 description 2882 "Indicates the auto-assignment mode. ESI can be 2883 automatically assigned either with or without 2884 indicating a pool from which the ESI should be 2885 taken. 2887 For both cases, the server will auto-assign an 2888 ESI value 'auto-assigned-ESI' and use that value 2889 operationally."; 2890 case from-pool { 2891 leaf esi-pool-name { 2892 type string; 2893 description 2894 "The auto-assignment will be made from the 2895 pool identified by the ESI-pool-name."; 2896 } 2897 } 2898 case full-auto { 2899 leaf auto { 2900 type empty; 2901 description 2902 "Indicates an ESI is fully auto-assigned."; 2904 } 2905 } 2906 } 2907 leaf auto-ethernet-segment-identifier { 2908 type yang:hex-string { 2909 length "29"; 2910 } 2911 config false; 2912 description 2913 "The value of the auto-assigned ESI."; 2914 } 2915 } 2916 } 2917 } 2918 leaf esi-redundancy-mode { 2919 type identityref { 2920 base es-redundancy-mode; 2921 } 2922 description 2923 "Indicates the ES redundancy mode."; 2924 reference 2925 "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 14.1"; 2926 } 2927 container df-election { 2928 description 2929 "Top container for the DF election method properties."; 2930 leaf df-election-method { 2931 type identityref { 2932 base df-election-methods; 2933 } 2934 default "default-7432"; 2935 description 2936 "Specifies the DF election method."; 2937 reference 2938 "RFC 8584: Framework for Ethernet VPN Designated 2939 Forwarder Election Extensibility"; 2940 } 2941 leaf revertive { 2942 when "derived-from-or-self(../df-election-method, " 2943 + "'preference')" { 2944 description 2945 "The revertive value is only applicable 2946 to the preference method."; 2947 } 2948 type boolean; 2949 default "true"; 2950 description 2951 "The default behavior is that the DF election 2952 procedure is triggered upon PE failures following 2953 configured preference values. Such a mode is called 2954 the revertive mode. This mode may not be suitable in 2955 some scenarios where, e.g., an operator may want to 2956 maintain the new DF even if the former DF recovers. 2957 Such a mode is called the 'non-revertive' mode. 2959 The non-revertive mode can be configured by 2960 setting 'revertive' leaf to 'false'."; 2961 reference 2962 "RFC 8584: Framework for Ethernet VPN Designated 2963 Forwarder Election Extensibility, 2964 Section 1.3.2"; 2965 } 2966 leaf election-wait-time { 2967 type uint32; 2968 units "seconds"; 2969 default "3"; 2970 description 2971 "Election wait timer."; 2972 reference 2973 "RFC 8584: Framework for Ethernet VPN Designated 2974 Forwarder Election Extensibility"; 2975 } 2976 } 2977 leaf split-horizon-filtering { 2978 type boolean; 2979 description 2980 "Controls split-horizon filtering. It is enabled 2981 when set to 'true'. 2983 In order to achieve split-horizon filtering, every 2984 Broadcast, unknown unicast, or multicast (BUM) 2985 packet originating from a non-DF PE is encapsulated 2986 with an MPLS label that identifies the origin ES."; 2987 reference 2988 "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 8.3"; 2989 } 2990 container pbb { 2991 description 2992 "Provider Backbone Bridging (PBB) parameters ."; 2993 reference 2994 "IEEE 802.1ah: Provider Backbone Bridge"; 2995 leaf backbone-src-mac { 2996 type yang:mac-address; 2997 description 2998 "The PEs connected to the same CE must share the 2999 same Provider Backbone (B-MAC) address in 3000 All-Active mode."; 3001 reference 3002 "RFC 7623: Provider Backbone Bridging Combined with 3003 Ethernet VPN (PBB-EVPN), Section 6.2.1.1"; 3004 } 3005 } 3006 list member { 3007 key "ne-id interface-id"; 3008 description 3009 "Includes a list of ES members."; 3010 leaf ne-id { 3011 type string; 3012 description 3013 "An identifier of the network element where the ES 3014 is configured within a service provider network."; 3015 } 3016 leaf interface-id { 3017 type string; 3018 description 3019 "Identifier of a node interface."; 3020 } 3021 } 3022 } 3023 } 3024 } 3025 3027 8.4. L2NM 3029 The "ietf-l2vpn-ntw" YANG module uses types defined in [RFC6991], 3030 [RFC9181], [RFC8294], and [IEEE802.1Qcp-2018]. 3032 3033 file "ietf-l2vpn-ntw@2022-05-25.yang" 3034 module ietf-l2vpn-ntw { 3035 yang-version 1.1; 3036 namespace "urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw"; 3037 prefix l2vpn-ntw; 3039 import ietf-inet-types { 3040 prefix inet; 3041 reference 3042 "RFC 6991: Common YANG Data Types, Section 4"; 3043 } 3044 import ietf-yang-types { 3045 prefix yang; 3046 reference 3047 "RFC 6991: Common YANG Data Types, Section 3"; 3049 } 3050 import ietf-vpn-common { 3051 prefix vpn-common; 3052 reference 3053 "RFC 9181: A Common YANG for Data Model for Layer 2 3054 and Layer 3 VPNs"; 3055 } 3056 import iana-bgp-l2-encaps { 3057 prefix iana-bgp-l2-encaps; 3058 reference 3059 "RFC XXXX: A YANG Network Data Model for Layer 2 VPNs."; 3060 } 3061 import iana-pseudowire-types { 3062 prefix iana-pw-types; 3063 reference 3064 "RFC XXXX: A YANG Network Data Model for Layer 2 VPNs."; 3065 } 3066 import ietf-ethernet-segment { 3067 prefix l2vpn-es; 3068 reference 3069 "RFC XXXX: A YANG Network Data Model for Layer 2 VPNs."; 3070 } 3071 import ietf-routing-types { 3072 prefix rt-types; 3073 reference 3074 "RFC 8294: Common YANG Data Types for the Routing Area"; 3075 } 3076 import ieee802-dot1q-types { 3077 prefix dot1q-types; 3078 reference 3079 "IEEE Std 802.1Qcp-2018: Bridges and Bridged Networks - 3080 Amendment: YANG Data Model"; 3081 } 3083 organization 3084 "IETF OPSA (Operations and Management Area) Working Group"; 3085 contact 3086 "WG Web: 3087 WG List: 3089 Editor: Mohamed Boucadair 3090 3091 Editor: Samier Barguil 3092 3093 Author: Oscar Gonzalez de Dios 3094 "; 3095 description 3096 "This YANG module defines a network model for Layer 2 VPN 3097 services. 3099 Copyright (c) 2022 IETF Trust and the persons identified as 3100 authors of the code. All rights reserved. 3102 Redistribution and use in source and binary forms, with or 3103 without modification, is permitted pursuant to, and subject 3104 to the license terms contained in, the Revised BSD License 3105 set forth in Section 4.c of the IETF Trust's Legal Provisions 3106 Relating to IETF Documents 3107 (https://trustee.ietf.org/license-info). 3109 This version of this YANG module is part of RFC XXXX; see 3110 the RFC itself for full legal notices."; 3112 revision 2022-05-25 { 3113 description 3114 "Initial version."; 3115 reference 3116 "RFC XXXX: A YANG Network Data Model for Layer 2 VPNs."; 3117 } 3119 /* Features */ 3121 feature oam-3ah { 3122 description 3123 "Indicates the support of OAM 802.3ah."; 3124 reference 3125 "IEEE Std 802.3ah: Media Access Control Parameters, Physical 3126 Layers, and Management Parameters for 3127 Subscriber Access Networks"; 3128 } 3130 /* Identities */ 3132 identity evpn-service-interface-type { 3133 description 3134 "Base identity for EVPN service interface type."; 3135 } 3137 identity vlan-based-service-interface { 3138 base evpn-service-interface-type; 3139 description 3140 "VLAN-Based Service Interface."; 3141 reference 3142 "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.1"; 3143 } 3144 identity vlan-bundle-service-interface { 3145 base evpn-service-interface-type; 3146 description 3147 "VLAN Bundle Service Interface."; 3148 reference 3149 "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.2"; 3150 } 3152 identity vlan-aware-bundle-service-interface { 3153 base evpn-service-interface-type; 3154 description 3155 "VLAN-Aware Bundle Service Interface."; 3156 reference 3157 "RFC 7432: BGP MPLS-Based Ethernet VPN, Section 6.3"; 3158 } 3160 identity mapping-type { 3161 base vpn-common:multicast-gp-address-mapping; 3162 description 3163 "Identity for multicast group mapping type."; 3164 } 3166 identity loop-prevention-type { 3167 description 3168 "Identity of loop prevention."; 3169 } 3171 identity shut { 3172 base loop-prevention-type; 3173 description 3174 "Shut protection type."; 3175 } 3177 identity trap { 3178 base loop-prevention-type; 3179 description 3180 "Trap protection type."; 3181 } 3183 identity color-type { 3184 description 3185 "Identity of color types. A type is assigned to a service frame 3186 to identify its QoS profile conformance."; 3187 } 3189 identity green { 3190 base color-type; 3191 description 3192 "'green' color type. A service frame is 'green' if it is 3193 conformant with the committed rate of the bandwidth profile."; 3194 } 3196 identity yellow { 3197 base color-type; 3198 description 3199 "'yellow' color type. A service frame is 'yellow' if it exceeds 3200 the committed rate but is conformant with the excess rate 3201 of the bandwidth profile."; 3202 } 3204 identity red { 3205 base color-type; 3206 description 3207 "'red' color type. A service famre is 'red' if it is not 3208 conformant with both the committed and excess rates of the 3209 bandwidth profile."; 3210 } 3212 identity t-ldp-pw-type { 3213 description 3214 "Identity for t-ldp-pw-type."; 3215 } 3217 identity vpws-type { 3218 base t-ldp-pw-type; 3219 description 3220 "Virtual Private Wire Service (VPWS) t-ldp-pw-type."; 3221 reference 3222 "RFC 4664: Framework for Layer 2 Virtual Private Networks 3223 (L2VPNs), Section 3.3"; 3224 } 3226 identity vpls-type { 3227 base t-ldp-pw-type; 3228 description 3229 "Virtual Private LAN Service (VPLS) t-ldp-pw-type."; 3230 reference 3231 "RFC 4762: Virtual Private LAN Service (VPLS) Using 3232 Label Distribution Protocol (LDP) 3233 Signaling, Section 6.1"; 3234 } 3236 identity hvpls { 3237 base t-ldp-pw-type; 3238 description 3239 "Identity for Hierarchical Virtual Private LAN Service (H-VPLS) 3240 t-ldp-pw-type."; 3241 reference 3242 "RFC 4762: Virtual Private LAN Service (VPLS) Using 3243 Label Distribution Protocol (LDP) 3244 Signaling, Section 10"; 3245 } 3247 identity lacp-mode { 3248 description 3249 "Identity of the LACP mode."; 3250 } 3252 identity lacp-active { 3253 base lacp-mode; 3254 description 3255 "LACP active mode. 3257 This mode refers to the mode where auto-speed negotiation 3258 is initiated followed by an establishment of an 3259 Ethernet channel with the other end."; 3260 } 3262 identity lacp-passive { 3263 base lacp-mode; 3264 description 3265 "LACP passive mode. 3267 This mode refers to the LACP mode where an endpoint does 3268 not initiate the negotiation, but only responds to LACP 3269 packets initiated by the other end (e.g., full duplex 3270 or half duplex)"; 3271 } 3273 identity pm-type { 3274 description 3275 "Identity for performance monitoring type."; 3276 } 3278 identity loss { 3279 base pm-type; 3280 description 3281 "Loss measurement is the performance monitoring type."; 3282 } 3284 identity delay { 3285 base pm-type; 3286 description 3287 "Delay measurement is the performance monitoring type."; 3289 } 3291 identity mac-learning-mode { 3292 description 3293 "Media Access Control (MAC) learning mode."; 3294 } 3296 identity data-plane { 3297 base mac-learning-mode; 3298 description 3299 "User MAC addresses are learned through ARP broadcast."; 3300 } 3302 identity control-plane { 3303 base mac-learning-mode; 3304 description 3305 "User MAC addresses are advertised through EVPN-BGP."; 3306 } 3308 identity mac-action { 3309 description 3310 "Base identity for a MAC action."; 3311 } 3313 identity drop { 3314 base mac-action; 3315 description 3316 "Dropping a packet as the MAC action."; 3317 } 3319 identity flood { 3320 base mac-action; 3321 description 3322 "Packet flooding as the MAC action."; 3323 } 3325 identity warning { 3326 base mac-action; 3327 description 3328 "Log a warning message as the MAC action."; 3329 } 3331 identity precedence-type { 3332 description 3333 "Redundancy type. The service can be created 3334 with primary and secondary signalization."; 3335 } 3336 identity primary { 3337 base precedence-type; 3338 description 3339 "Identifies the main VPN network access."; 3340 } 3342 identity secondary { 3343 base precedence-type; 3344 description 3345 "Identifies the secondary VPN network access."; 3346 } 3348 identity ldp-pw-type { 3349 description 3350 "Identity for allowed LDP-based pseudowire (PW) type."; 3351 reference 3352 "RFC 4762: Virtual Private LAN Service (VPLS) Using 3353 Label Distribution Protocol (LDP) 3354 Signaling, Section 6.1.1"; 3355 } 3357 identity ethernet { 3358 base ldp-pw-type; 3359 description 3360 "PW Ethernet type."; 3361 } 3363 identity ethernet-tagged { 3364 base ldp-pw-type; 3365 description 3366 "PW Ethernet tagged mode type."; 3367 } 3369 /* Typedefs */ 3371 typedef ccm-priority-type { 3372 type uint8 { 3373 range "0..7"; 3374 } 3375 description 3376 "A 3-bit priority value to be used in the VLAN tag, 3377 if present in the transmitted frame. A larger value 3378 indicates a higher priority."; 3379 } 3381 /* Groupings */ 3383 grouping cfm-802 { 3384 description 3385 "Grouping for 802.1ag Connectivity Fault Management (CFM) 3386 attributes."; 3387 reference 3388 "IEEE Std 802-1ag: Virtual Bridged Local Area Networks 3389 Amendment 5: Connectivity Fault Management"; 3390 leaf maid { 3391 type string; 3392 description 3393 "Maintenance Association Identifier (MAID)."; 3394 } 3395 leaf mep-id { 3396 type uint32; 3397 description 3398 "Local Maintenance Entity Group End Point (MEP) ID."; 3399 } 3400 leaf mep-level { 3401 type uint32; 3402 description 3403 "MEP level."; 3404 } 3405 leaf mep-up-down { 3406 type enumeration { 3407 enum up { 3408 description 3409 "MEP is up."; 3410 } 3411 enum down { 3412 description 3413 "MEP is down."; 3414 } 3415 } 3416 default "up"; 3417 description 3418 "MEP up/down."; 3419 } 3420 leaf remote-mep-id { 3421 type uint32; 3422 description 3423 "Remote MEP ID."; 3424 } 3425 leaf cos-for-cfm-pdus { 3426 type uint32; 3427 description 3428 "Class of service for CFM PDUs."; 3429 } 3430 leaf ccm-interval { 3431 type uint32; 3432 units "milliseconds"; 3433 default "10000"; 3434 description 3435 "Continuity Check Message (CCM) interval."; 3436 } 3437 leaf ccm-holdtime { 3438 type uint32; 3439 units "milliseconds"; 3440 default "35000"; 3441 description 3442 "CCM hold time."; 3443 } 3444 leaf ccm-p-bits-pri { 3445 type ccm-priority-type; 3446 description 3447 "The priority parameter for Continuity Check Messages (CCMs) 3448 transmitted by the MEP."; 3449 } 3450 } 3452 grouping y-1731 { 3453 description 3454 "Grouping for Y-1731"; 3455 reference 3456 "ITU-T Y-1731: Operations, administration and maintenance 3457 (OAM) functions and mechanisms for 3458 Ethernet-based networks"; 3459 list y-1731 { 3460 key "maid"; 3461 description 3462 "List of configured Y-1731 instances."; 3463 leaf maid { 3464 type string; 3465 description 3466 "MAID."; 3467 } 3468 leaf mep-id { 3469 type uint32; 3470 description 3471 "Local MEP ID."; 3472 } 3473 leaf pm-type { 3474 type identityref { 3475 base pm-type; 3476 } 3477 default "delay"; 3478 description 3479 "Performance monitor types."; 3481 } 3482 leaf remote-mep-id { 3483 type uint32; 3484 description 3485 "Remote MEP ID."; 3486 } 3487 leaf message-period { 3488 type uint32; 3489 units "milliseconds"; 3490 default "10000"; 3491 description 3492 "Defines the interval between OAM messages."; 3493 } 3494 leaf measurement-interval { 3495 type uint32; 3496 units "seconds"; 3497 description 3498 "Specifies the measurement interval for statistics."; 3499 } 3500 leaf cos { 3501 type uint32; 3502 description 3503 "Identifies the Class of Service."; 3504 } 3505 leaf loss-measurement { 3506 type boolean; 3507 default "false"; 3508 description 3509 "Controls whether loss measurement is ('true') or 3510 disabled ('false')."; 3511 } 3512 leaf synthethic-loss-measurement { 3513 type boolean; 3514 default "false"; 3515 description 3516 "Indicates whether synthetic loss measurement is enabled 3517 ('true') or disabled ('false')."; 3518 } 3519 container delay-measurement { 3520 description 3521 "Container for delay measurement"; 3522 leaf enable-dm { 3523 type boolean; 3524 default "false"; 3525 description 3526 "Controls whether delay measurement is enabled ('true') 3527 or disabled ('false')."; 3528 } 3529 leaf two-way { 3530 type boolean; 3531 default "false"; 3532 description 3533 "Whether delay measurement is two-way ('true') of one- 3534 way ('false')."; 3535 } 3536 } 3537 leaf frame-size { 3538 type uint32; 3539 units "bytes"; 3540 description 3541 "Indicates the frame size."; 3542 } 3543 leaf session-type { 3544 type enumeration { 3545 enum proactive { 3546 description 3547 "Proactive mode."; 3548 } 3549 enum on-demand { 3550 description 3551 "On-demand mode."; 3552 } 3553 } 3554 default "on-demand"; 3555 description 3556 "Specifies the session type."; 3557 } 3558 } 3559 } 3561 grouping parameters-profile { 3562 description 3563 "Container for per-service parameters."; 3564 leaf local-autonomous-system { 3565 type inet:as-number; 3566 description 3567 "Indicates a local AS Number (ASN)."; 3568 } 3569 leaf svc-mtu { 3570 type uint32; 3571 units "bytes"; 3572 description 3573 "Layer 2 service MTU. 3574 It is also known as the maximum transmission 3575 unit or maximum frame size."; 3576 } 3577 leaf ce-vlan-preservation { 3578 type boolean; 3579 description 3580 "Preserve the CE-VLAN ID from ingress to egress, i.e., 3581 CE-VLAN tag of the egress frame is identical to 3582 that of the ingress frame that yielded this egress 3583 service frame. If all-to-one bundling within a site 3584 is enabled, then preservation applies to all ingress 3585 service frames. If all-to-one bundling is disabled, 3586 then preservation applies to tagged ingress service 3587 frames having CE-VLAN ID 1 through 4094."; 3588 } 3589 leaf ce-vlan-cos-preservation { 3590 type boolean; 3591 description 3592 "CE VLAN CoS preservation. Priority Code Point (PCP) bits 3593 in the CE-VLAN tag of the egress frame are identical to 3594 those of the ingress frame that yielded this egress 3595 service frame."; 3596 } 3597 leaf control-word-negotiation { 3598 type boolean; 3599 description 3600 "Controls whether Control-word negotiation is enabled 3601 (if set to true) or not (if set to false)."; 3602 reference 3603 "RFC 8077: Pseudowire Setup and Maintenance 3604 Using the Label Distribution Protocol (LDP), 3605 Section 7"; 3606 } 3607 container mac-policies { 3608 description 3609 "Container of MAC policies."; 3610 container mac-addr-limit { 3611 description 3612 "Container of MAC address limit configuration."; 3613 leaf limit-number { 3614 type uint16; 3615 description 3616 "Maximum number of MAC addresses learned from 3617 the customer for a single service instance. 3618 The default value is '2' when this grouping 3619 is used at the service level."; 3620 } 3621 leaf time-interval { 3622 type uint32; 3623 units "milliseconds"; 3624 description 3625 "The aging time of the mac address. 3626 The default value is '300' when this grouping 3627 is used at the service level."; 3628 } 3629 leaf action { 3630 type identityref { 3631 base mac-action; 3632 } 3633 description 3634 "Specifies the action when the upper limit is 3635 exceeded: drop the packet, flood the packet, 3636 or log a warning message (without dropping 3637 the packet). 3638 The default value is 'warning' when this 3639 grouping is used at the service level."; 3640 } 3641 } 3642 container mac-loop-prevention { 3643 description 3644 "Container for MAC loop prevention."; 3645 leaf window { 3646 type uint32; 3647 units "seconds"; 3648 description 3649 "The time interval over which a MAC mobility event 3650 is detected and checked. 3651 The default value is '180' when this grouping 3652 is used at the service level."; 3653 } 3654 leaf frequency { 3655 type uint32; 3656 description 3657 "The number of times to detect MAC duplication, where 3658 a 'duplicate MAC address' situation has occurred 3659 within the 'window' time interval and the duplicate 3660 MAC address has been added to a list of duplicate 3661 MAC addresses. 3662 The default value is '5' when this grouping is 3663 called at the service level."; 3664 } 3665 leaf retry-timer { 3666 type uint32; 3667 units "seconds"; 3668 description 3669 "The retry timer. When the retry timer expires, 3670 the duplicate MAC address will be flushed from 3671 the MAC-VRF."; 3672 } 3673 leaf protection-type { 3674 type identityref { 3675 base loop-prevention-type; 3676 } 3677 description 3678 "Protection type. 3679 The default value is 'trap' when this grouping 3680 is used at the service level."; 3681 } 3682 } 3683 } 3684 container multicast { 3685 if-feature "vpn-common:multicast"; 3686 description 3687 "Multicast container."; 3688 leaf enabled { 3689 type boolean; 3690 default "false"; 3691 description 3692 "Enables multicast."; 3693 } 3694 container customer-tree-flavors { 3695 description 3696 "Type of trees used by the customer."; 3697 leaf-list tree-flavor { 3698 type identityref { 3699 base vpn-common:multicast-tree-type; 3700 } 3701 description 3702 "Type of multicast tree to be used."; 3703 } 3704 } 3705 } 3706 } 3708 grouping bandwidth-parameters { 3709 description 3710 "A grouping for bandwidth parameters."; 3711 leaf cir { 3712 type uint64; 3713 units "bps"; 3714 description 3715 "Committed Information Rate. The maximum 3716 number of bits that a port can receive or 3717 send during one-second over an 3718 interface."; 3719 } 3720 leaf cbs { 3721 type uint64; 3722 units "bytes"; 3723 description 3724 "Committed Burst Size. CBS controls the 3725 bursty nature of the traffic. Traffic 3726 that does not use the configured CIR 3727 accumulates credits until the credits 3728 reach the configured CBS."; 3729 } 3730 leaf eir { 3731 type uint64; 3732 units "bps"; 3733 description 3734 "Excess Information Rate, i.e., excess 3735 frame delivery allowed not subject to 3736 SLA. The traffic rate can be limited 3737 by EIR."; 3738 } 3739 leaf ebs { 3740 type uint64; 3741 units "bytes"; 3742 description 3743 "Excess Burst Size. The bandwidth 3744 available for burst traffic from the 3745 EBS is subject to the amount of 3746 bandwidth that is accumulated during 3747 periods when traffic allocated by the 3748 EIR policy is not used."; 3749 } 3750 leaf pir { 3751 type uint64; 3752 units "bps"; 3753 description 3754 "Peak Information Rate, i.e., maximum 3755 frame delivery allowed. It is equal 3756 to or less than sum of CIR and EIR."; 3757 } 3758 leaf pbs { 3759 type uint64; 3760 units "bytes"; 3761 description 3762 "Peak Burst Size."; 3763 } 3764 } 3766 /* Main L2NM Container */ 3768 container l2vpn-ntw { 3769 description 3770 "Container for the L2NM."; 3771 container vpn-profiles { 3772 description 3773 "Container for VPN profiles."; 3774 uses vpn-common:vpn-profile-cfg; 3775 } 3776 container vpn-services { 3777 description 3778 "Container for L2VPN services."; 3779 list vpn-service { 3780 key "vpn-id"; 3781 description 3782 "Container of a VPN service."; 3783 uses vpn-common:vpn-description; 3784 leaf parent-service-id { 3785 type vpn-common:vpn-id; 3786 description 3787 "Pointer to the parent service that 3788 triggered the L2NM."; 3789 } 3790 leaf vpn-type { 3791 type identityref { 3792 base vpn-common:service-type; 3793 } 3794 must "not(derived-from-or-self(current(), " 3795 + "'vpn-common:l3vpn'))" { 3796 error-message "L3VPN is only applicable in L3NM."; 3797 } 3798 description 3799 "Service type."; 3800 } 3801 leaf vpn-service-topology { 3802 type identityref { 3803 base vpn-common:vpn-topology; 3804 } 3805 description 3806 "Defining service topology, such as 3807 any-to-any, hub-spoke, etc."; 3808 } 3809 leaf bgp-ad-enabled { 3810 type boolean; 3811 description 3812 "Indicates whether BGP auto-discovery is enabled 3813 or disabled."; 3814 } 3815 leaf signaling-type { 3816 type identityref { 3817 base vpn-common:vpn-signaling-type; 3818 } 3819 description 3820 "VPN signaling type."; 3821 } 3822 container global-parameters-profiles { 3823 description 3824 "Container for a list of global parameters 3825 profiles."; 3826 list global-parameters-profile { 3827 key "profile-id"; 3828 description 3829 "List of global parameters profiles."; 3830 leaf profile-id { 3831 type string; 3832 description 3833 "The identifier of the global parameters profile."; 3834 } 3835 uses vpn-common:route-distinguisher; 3836 uses vpn-common:vpn-route-targets; 3837 uses parameters-profile; 3838 } 3839 } 3840 container underlay-transport { 3841 description 3842 "Container for the underlay transport."; 3843 uses vpn-common:underlay-transport; 3844 } 3845 uses vpn-common:service-status; 3846 container vpn-nodes { 3847 description 3848 "Set of VPN nodes that are involved in the L2NM."; 3849 list vpn-node { 3850 key "vpn-node-id"; 3851 description 3852 "Container of the VPN nodes."; 3853 leaf vpn-node-id { 3854 type vpn-common:vpn-id; 3855 description 3856 "Sets the identifier of the VPN node."; 3857 } 3858 leaf description { 3859 type string; 3860 description 3861 "Textual description of a VPN node."; 3862 } 3863 leaf ne-id { 3864 type string; 3865 description 3866 "An identifier of the network element where 3867 the VPN node is deployed. This identifier 3868 uniquely identifies the network element within 3869 an administrative domain."; 3870 } 3871 leaf role { 3872 type identityref { 3873 base vpn-common:role; 3874 } 3875 default "vpn-common:any-to-any-role"; 3876 description 3877 "Role of the VPN node in the VPN."; 3878 } 3879 leaf router-id { 3880 type rt-types:router-id; 3881 description 3882 "A 32-bit number in the dotted-quad format that is 3883 used to uniquely identify a node within an 3884 autonomous system (AS)."; 3885 } 3886 container active-global-parameters-profiles { 3887 description 3888 "Container for a list of global parameters 3889 profiles."; 3890 list global-parameters-profile { 3891 key "profile-id"; 3892 description 3893 "List of active global parameters profiles."; 3894 leaf profile-id { 3895 type leafref { 3896 path "../../../../../global-parameters-profiles" 3897 + "/global-parameters-profile/profile-id"; 3898 } 3899 description 3900 "Points to a global profile defined at the 3901 service level."; 3902 } 3903 uses parameters-profile; 3904 } 3905 } 3906 uses vpn-common:service-status; 3907 container bgp-auto-discovery { 3908 when "../../../bgp-ad-enabled = 'true'" { 3909 description 3910 "Only applies when BGP auto-discovery is enabled."; 3911 } 3912 description 3913 "BGP is used for auto-discovery."; 3914 choice bgp-type { 3915 description 3916 "Choice for the BGP type."; 3917 case l2vpn-bgp { 3918 description 3919 "Container for BGP L2VPN."; 3920 leaf vpn-id { 3921 type vpn-common:vpn-id; 3922 description 3923 "VPN Identifier. This identifier serves to 3924 unify components of a given VPN for the 3925 sake of auto-discovery."; 3926 reference 3927 "RFC 6624: Layer 2 Virtual Private Networks 3928 Using BGP for Auto-Discovery and 3929 Signaling"; 3930 } 3931 } 3932 case evpn-bgp { 3933 description 3934 "EVPN case."; 3935 leaf evpn-type { 3936 type leafref { 3937 path "../../../../vpn-type"; 3938 } 3939 description 3940 "EVPN type."; 3941 } 3942 leaf auto-rt-enable { 3943 type boolean; 3944 default "false"; 3945 description 3946 "Enables/disabled RT auto-derivation based on 3947 the ASN and Ethernet Tag ID."; 3948 reference 3949 "RFC 7432: BGP MPLS-Based Ethernet VPN, 3950 Section 7.10.1"; 3951 } 3952 leaf auto-route-target { 3953 when "../auto-rt-enable = 'true'" { 3954 description 3955 "Can only be used when auto-RD is enabled."; 3956 } 3957 type rt-types:route-target; 3958 config false; 3959 description 3960 "The value of the auto-assigned RT."; 3962 } 3963 } 3964 } 3965 uses vpn-common:route-distinguisher; 3966 uses vpn-common:vpn-route-targets; 3967 } 3968 container signaling-option { 3969 description 3970 "Container for the L2VPN signaling."; 3971 leaf advertise-mtu { 3972 type boolean; 3973 description 3974 "Controls whether MTU is advertised."; 3975 reference 3976 "RFC 4667: Layer 2 Virtual Private Network (L2VPN) 3977 Extensions for Layer 2 Tunneling 3978 Protocol (L2TP), Section 4.3"; 3979 } 3980 leaf mtu-allow-mismatch { 3981 type boolean; 3982 description 3983 "When set to true, it allows MTU mismatch."; 3984 reference 3985 "RFC 4667: Layer 2 Virtual Private Network (L2VPN) 3986 Extensions for Layer 2 Tunneling 3987 Protocol (L2TP), Section 4.3"; 3988 } 3989 leaf signaling-type { 3990 type leafref { 3991 path "../../../../signaling-type"; 3992 } 3993 description 3994 "VPN signaling type."; 3995 } 3996 choice signaling-option { 3997 description 3998 "Choice for the signaling-option."; 3999 case bgp { 4000 description 4001 "BGP is used as the signaling protocol."; 4002 choice bgp-type { 4003 description 4004 "Choice for the BGP type."; 4005 case l2vpn-bgp { 4006 description 4007 "Container for BGP L2VPN."; 4008 leaf ce-range { 4009 type uint16; 4010 description 4011 "Determines the number of remote CEs with 4012 which a given CE can communicate in the 4013 context of a VPN."; 4014 reference 4015 "RFC 6624: Layer 2 Virtual Private Networks 4016 Using BGP for Auto-Discovery and 4017 Signaling"; 4018 } 4019 leaf pw-encapsulation-type { 4020 type identityref { 4021 base iana-bgp-l2-encaps:bgp-l2-encaps-type; 4022 } 4023 description 4024 "PW encapsulation type."; 4025 } 4026 container vpls-instance { 4027 when "derived-from-or-self(../../../../" 4028 + "vpn-type, 'vpn-common:vpls')" { 4029 description 4030 "Only applies for VPLS."; 4031 } 4032 description 4033 "VPLS instance."; 4034 leaf vpls-edge-id { 4035 type uint16; 4036 description 4037 "VPLS Edge Identifier (VE ID). This is 4038 used when the same VE ID is configured 4039 for the PE."; 4040 reference 4041 "RFC 4761: Virtual Private LAN Service 4042 (VPLS) Using BGP for Auto- 4043 Discovery and Signaling, 4044 Section 3.5"; 4045 } 4046 leaf vpls-edge-id-range { 4047 type uint16; 4048 description 4049 "Specifies the size of the range of 4050 VE ID in a VPLS service. The range 4051 controls the size of the label 4052 block advertised in the context of 4053 a VPLS instance."; 4054 reference 4055 "RFC 4761: Virtual Private LAN Service 4056 (VPLS) Using BGP for Auto- 4057 Discovery and Signaling"; 4059 } 4060 } 4061 } 4062 case evpn-bgp { 4063 description 4064 "Used for EVPN."; 4065 leaf evpn-type { 4066 type leafref { 4067 path "../../bgp-auto-discovery/evpn-type"; 4068 } 4069 description 4070 "EVPN type."; 4071 } 4072 leaf service-interface-type { 4073 type identityref { 4074 base evpn-service-interface-type; 4075 } 4076 description 4077 "EVPN service interface type."; 4078 } 4079 container evpn-policies { 4080 description 4081 "Includes a set of EVPN policies such 4082 as those related to handling MAC 4083 addresses."; 4084 leaf mac-learning-mode { 4085 type identityref { 4086 base mac-learning-mode; 4087 } 4088 description 4089 "Indicates through which plane MAC 4090 addresses are advertised."; 4091 } 4092 leaf ingress-replication { 4093 type boolean; 4094 description 4095 "Controls whether ingress replication is 4096 enabled ('true') or disabled ('false')."; 4097 reference 4098 "RFC 7432: BGP MPLS-Based Ethernet VPN, 4099 Section 8.3.1.1"; 4100 } 4101 leaf p2mp-replication { 4102 type boolean; 4103 description 4104 "Controles whether P2MP replication is 4105 enabled ('true') or disabled ('false')"; 4106 reference 4107 "RFC 7432: BGP MPLS-Based Ethernet VPN, 4108 Section 8.3.1.2"; 4109 } 4110 container arp-proxy { 4111 if-feature "vpn-common:ipv4"; 4112 description 4113 "Top container for the ARP proxy."; 4114 leaf enable { 4115 type boolean; 4116 default "false"; 4117 description 4118 "Enables (when set to 'true') or 4119 disables (when set to 'false') 4120 ARP proxy."; 4121 reference 4122 "RFC 7432: BGP MPLS-Based Ethernet VPN, 4123 Section 10"; 4124 } 4125 leaf arp-suppression { 4126 type boolean; 4127 default "false"; 4128 description 4129 "Enables (when set to 'true') or 4130 disables (when set to 'false') ARP 4131 suppression."; 4132 reference 4133 "RFC 7432: BGP MPLS-Based Ethernet 4134 VPN"; 4135 } 4136 leaf ip-mobility-threshold { 4137 type uint16; 4138 description 4139 "It is possible for a given host (as 4140 defined by its IP address) to move 4141 from one ES to another. 4142 IP mobility threshold specifies the 4143 number of IP mobility events 4144 that are detected for a given IP 4145 address within the 4146 detection-threshold before it 4147 is identified as a duplicate IP 4148 address. 4149 Once the detection threshold is 4150 reached, updates for the IP address 4151 are suppressed."; 4152 } 4153 leaf duplicate-ip-detection-interval { 4154 type uint16; 4155 units "seconds"; 4156 description 4157 "The time interval used in detecting a 4158 duplicate IP address. Duplicate IP 4159 address detection number of host moves 4160 are allowed within this interval 4161 period."; 4162 } 4163 } 4164 container nd-proxy { 4165 if-feature "vpn-common:ipv6"; 4166 description 4167 "Top container for the ND proxy."; 4168 leaf enable { 4169 type boolean; 4170 default "false"; 4171 description 4172 "Enables (when set to 'true') or 4173 disables (when set to 'false') ND 4174 proxy."; 4175 reference 4176 "RFC 7432: BGP MPLS-Based Ethernet VPN, 4177 Section 10"; 4178 } 4179 leaf nd-suppression { 4180 type boolean; 4181 default "false"; 4182 description 4183 "Enables (when set to 'true') or 4184 disables (when set to 'false') 4185 Neighbor Discovery (ND) message 4186 suppression. 4187 ND suppression is a technique that 4188 is used to reduce the amount of ND 4189 packets flooding within individual 4190 segments, that is between hosts 4191 connected to the same logical 4192 switch."; 4193 } 4194 leaf ip-mobility-threshold { 4195 type uint16; 4196 description 4197 "It is possible for a given host (as 4198 defined by its IP address) to move 4199 from one ES to another. 4200 IP mobility threshold specifies the 4201 number of IP mobility events 4202 that are detected for a given IP 4203 address within the 4204 detection-threshold before it 4205 is identified as a duplicate IP 4206 address. 4207 Once the detection threshold is 4208 reached, updates for the IP address 4209 are suppressed."; 4210 } 4211 leaf duplicate-ip-detection-interval { 4212 type uint16; 4213 units "seconds"; 4214 description 4215 "The time interval used in detecting a 4216 duplicate IP address. Duplicate IP 4217 address detection number of host moves 4218 are allowed within this interval 4219 period."; 4220 } 4221 } 4222 leaf underlay-multicast { 4223 type boolean; 4224 default "false"; 4225 description 4226 "Enables (when set to 'true') or disables 4227 (when set to 'false') underlay 4228 multicast."; 4229 } 4230 leaf flood-unknown-unicast-supression { 4231 type boolean; 4232 default "false"; 4233 description 4234 "Enables (when set to 'true') or disables 4235 (when set to 'false') unknown flood 4236 unicast suppression."; 4237 } 4238 leaf vpws-vlan-aware { 4239 type boolean; 4240 default "false"; 4241 description 4242 "Enables (when set to 'true') or disables 4243 (when set to 'false') VPWS VLAN-aware."; 4244 } 4245 container bum-management { 4246 description 4247 "Broadcast-unknown-unicast-multicast 4248 management."; 4249 leaf discard-broadcast { 4250 type boolean; 4251 default "false"; 4252 description 4253 "Discards broadcast, when enabled."; 4254 } 4255 leaf discard-unknown-multicast { 4256 type boolean; 4257 default "false"; 4258 description 4259 "Discards unknown multicast, when 4260 enabled."; 4261 } 4262 leaf discard-unknown-unicast { 4263 type boolean; 4264 default "false"; 4265 description 4266 "Discards unknown unicast, when 4267 enabled."; 4268 } 4269 } 4270 container pbb { 4271 when "derived-from-or-self(" 4272 + "../../evpn-type, 'pbb-evpn')" { 4273 description 4274 "Only applies for PBB EVPN."; 4275 } 4276 description 4277 "PBB parameters container."; 4278 reference 4279 "IEEE 802.1ah: Provider Backbone Bridge"; 4280 leaf backbone-src-mac { 4281 type yang:mac-address; 4282 description 4283 "Includes provider backbone MAC (B-MAC) 4284 address."; 4285 reference 4286 "RFC 7623: Provider Backbone Bridging 4287 Combined with Ethernet VPN 4288 (PBB-EVPN), Section 8.1"; 4289 } 4290 } 4291 } 4292 } 4293 } 4294 } 4295 container ldp-or-l2tp { 4296 description 4297 "Container for LDP or L2TP-signaled PWs 4298 choice."; 4300 leaf agi { 4301 type rt-types:route-distinguisher; 4302 description 4303 "Attachment Group Identifier. Also, called 4304 VPLS-Id."; 4305 reference 4306 "RFC 4667: Layer 2 Virtual Private Network 4307 (L2VPN) Extensions for Layer 2 4308 Tunneling Protocol (L2TP), 4309 Section 4.3 4310 RFC 4762: Virtual Private LAN Service (VPLS) 4311 Using Label Distribution Protocol 4312 (LDP) Signaling, Section 6.1.1"; 4313 } 4314 leaf saii { 4315 type uint32; 4316 description 4317 "Source Attachment Individual Identifier 4318 (SAII)."; 4319 reference 4320 "RFC 4667: Layer 2 Virtual Private Network 4321 (L2VPN) Extensions for Layer 2 4322 Tunneling Protocol (L2TP), 4323 Section 3"; 4324 } 4325 list remote-targets { 4326 key "taii"; 4327 description 4328 "List of allowed target Attachment Individual 4329 Identifier (AII) and peers."; 4330 reference 4331 "RFC 4667: Layer 2 Virtual Private Network 4332 (L2VPN) Extensions for Layer 2 4333 Tunneling Protocol (L2TP), 4334 Section 5"; 4335 leaf taii { 4336 type uint32; 4337 description 4338 "Target Attachment Individual Identifier."; 4339 reference 4340 "RFC 4667: Layer 2 Virtual Private Network 4341 (L2VPN) Extensions for Layer 2 4342 Tunneling Protocol (L2TP), 4343 Section 3"; 4344 } 4345 leaf peer-addr { 4346 type inet:ip-address; 4347 description 4348 "Indicates the peer forwarder's IP address."; 4349 } 4350 } 4351 choice ldp-or-l2tp { 4352 description 4353 "Choice of LDP or L2TP-signaled PWs."; 4354 case ldp { 4355 description 4356 "Container for T-LDP PW configurations."; 4357 leaf t-ldp-pw-type { 4358 type identityref { 4359 base t-ldp-pw-type; 4360 } 4361 description 4362 "T-LDP PW type."; 4363 } 4364 leaf pw-type { 4365 type identityref { 4366 base ldp-pw-type; 4367 } 4368 description 4369 "PW encapsulation type."; 4370 reference 4371 "RFC 4762: Virtual Private LAN Service 4372 (VPLS) Using Label Distribution 4373 Protocol (LDP) Signaling, 4374 Section 6.1.1"; 4375 } 4376 leaf pw-description { 4377 type string; 4378 description 4379 "Includes a human-readable description 4380 of the interface. This may be used when 4381 communicating with a remote peer."; 4382 reference 4383 "RFC 4762: Virtual Private LAN Service 4384 (VPLS) Using Label Distribution 4385 Protocol (LDP) Signaling, 4386 Section 6.1.1"; 4387 } 4388 leaf mac-addr-withdraw { 4389 type boolean; 4390 description 4391 "If set to 'true', then MAC address 4392 withdrawal is enabled. If 'false', 4393 then MAC address withdrawal is 4394 disabled."; 4395 reference 4396 "RFC 4762: Virtual Private LAN Service 4397 (VPLS) Using Label Distribution 4398 Protocol (LDP) Signaling, 4399 Section 6.2"; 4400 } 4401 list pw-peer-list { 4402 key "peer-addr vc-id"; 4403 description 4404 "List of AC and PW bindings."; 4405 leaf peer-addr { 4406 type inet:ip-address; 4407 description 4408 "Indicates the peer's IP address."; 4409 } 4410 leaf vc-id { 4411 type string; 4412 description 4413 "VC label used to identify a PW."; 4414 } 4415 leaf pw-priority { 4416 type uint32; 4417 description 4418 "Defines the priority for the PW. 4419 The higher the pw-priority value, the 4420 higher the preference of the PW will 4421 be."; 4422 } 4423 } 4424 container qinq { 4425 when "derived-from-or-self(" 4426 + "../t-ldp-pw-type, 'hvpls')" { 4427 description 4428 "Only applies when t-ldp pw type 4429 is h-vpls."; 4430 } 4431 description 4432 "Container for QinQ."; 4433 leaf s-tag { 4434 type dot1q-types:vlanid; 4435 mandatory true; 4436 description 4437 "S-TAG."; 4438 } 4439 leaf c-tag { 4440 type dot1q-types:vlanid; 4441 mandatory true; 4442 description 4443 "C-TAG."; 4445 } 4446 } 4447 } 4448 case l2tp { 4449 description 4450 "Container for L2TP PWs."; 4451 leaf router-id { 4452 type rt-types:router-id; 4453 description 4454 "A 32-bit number in the dotted-quad format 4455 that is used to uniquely identify a node 4456 within a service provider network."; 4457 reference 4458 "RFC 4667: Layer 2 Virtual Private Network 4459 (L2VPN) Extensions for Layer 2 4460 Tunneling Protocol (L2TP), 4461 Section 4.2"; 4462 } 4463 leaf pseudowire-type { 4464 type identityref { 4465 base iana-pw-types:iana-pw-types; 4466 } 4467 description 4468 "Encapsulation type."; 4469 reference 4470 "RFC 4667: Layer 2 Virtual Private Network 4471 (L2VPN) Extensions for Layer 2 4472 Tunneling Protocol (L2TP), 4473 Section 4.2"; 4474 } 4475 } 4476 } 4477 } 4478 } 4479 } 4480 container vpn-network-accesses { 4481 description 4482 "Main container for VPN network accesses."; 4483 list vpn-network-access { 4484 key "id"; 4485 description 4486 "List of VPN network accesses."; 4487 leaf id { 4488 type vpn-common:vpn-id; 4489 description 4490 "Identifier of the network access"; 4491 } 4492 leaf description { 4493 type string; 4494 description 4495 "A textual description of the VPN network 4496 access."; 4497 } 4498 leaf interface-id { 4499 type string; 4500 description 4501 "Refers to a physical or logical interface."; 4502 } 4503 leaf active-vpn-node-profile { 4504 type leafref { 4505 path "../../.." 4506 + "/active-global-parameters-profiles" 4507 + "/global-parameters-profile/profile-id"; 4508 } 4509 description 4510 "An identifier of an active VPN instance 4511 profile."; 4512 } 4513 uses vpn-common:service-status; 4514 container connection { 4515 description 4516 "Container for the bearer and AC."; 4517 leaf l2-termination-point { 4518 type string; 4519 description 4520 "Specifies a reference to a local Layer 2 4521 termination point such as a Layer 2 4522 sub-interface."; 4523 } 4524 leaf local-bridge-reference { 4525 type string; 4526 description 4527 "Specifies a local bridge reference to 4528 accommodate, for example, implementations 4529 that require internal bridging. 4530 A reference may be a local bridge domain."; 4531 } 4532 leaf bearer-reference { 4533 if-feature "vpn-common:bearer-reference"; 4534 type string; 4535 description 4536 "This is an internal reference for the service 4537 provider to identify the bearer associated 4538 with this VPN."; 4539 } 4540 container encapsulation { 4541 description 4542 "Container for Layer 2 encapsulation."; 4543 leaf encap-type { 4544 type identityref { 4545 base vpn-common:encapsulation-type; 4546 } 4547 default "vpn-common:priority-tagged"; 4548 description 4549 "Tagged interface type. By default, the 4550 type of the tagged interface is 4551 'priority-tagged'."; 4552 } 4553 container dot1q { 4554 when "derived-from-or-self(../encap-type, " 4555 + "'vpn-common:dot1q')" { 4556 description 4557 "Only applies when the type of the 4558 tagged interface is 'dot1q'."; 4559 } 4560 description 4561 "Tagged interface."; 4562 leaf tag-type { 4563 type identityref { 4564 base vpn-common:tag-type; 4565 } 4566 default "vpn-common:c-vlan"; 4567 description 4568 "Tag type. By default, the tag type is 4569 'c-vlan'."; 4570 } 4571 leaf cvlan-id { 4572 type dot1q-types:vlanid; 4573 description 4574 "VLAN identifier."; 4575 } 4576 container tag-operations { 4577 description 4578 "Sets the tag manipulation policy for this 4579 VPN network access. It defines a set of 4580 tag manipulations that allow for the 4581 insertion, removal, or rewriting 4582 of 802.1Q VLAN tags. These operations are 4583 indicated for the CE-PE direction. 4584 By default, tag operations are symmetric. 4585 As such, the reverse tag operation is 4586 assumed on the PE-CE direction."; 4587 choice op-choice { 4588 description 4589 "Selects the tag rewriting policy for a 4590 VPN network access."; 4591 leaf pop { 4592 type empty; 4593 description 4594 "Pop the outer tag."; 4595 } 4596 leaf push { 4597 type empty; 4598 description 4599 "Push one or two tags defined by the 4600 tag-1 and tag-2 leaves. It is 4601 assumed that, absent any policy, the 4602 default value of 0 will be used for 4603 PCP setting."; 4604 } 4605 leaf translate { 4606 type empty; 4607 description 4608 "Translate the outer tag to one or two 4609 tags. PCP bits are preserved."; 4610 } 4611 } 4612 leaf tag-1 { 4613 when 'not(../pop)'; 4614 type dot1q-types:vlanid; 4615 description 4616 "A first tag to be used for push or 4617 translate operations. This tag will be 4618 used as the outermost tag as a result 4619 of the tag operation."; 4620 } 4621 leaf tag-1-type { 4622 type dot1q-types:dot1q-tag-type; 4623 default "dot1q-types:s-vlan"; 4624 description 4625 "Specifies a specific 802.1Q tag type 4626 of tag-1."; 4627 } 4628 leaf tag-2 { 4629 when '(../translate)'; 4630 type dot1q-types:vlanid; 4631 description 4632 "A second tag to be used for 4633 translation."; 4634 } 4635 leaf tag-2-type { 4636 type dot1q-types:dot1q-tag-type; 4637 default "dot1q-types:c-vlan"; 4638 description 4639 "Specifies a specific 802.1Q tag type 4640 of tag-2."; 4641 } 4642 } 4643 } 4644 container priority-tagged { 4645 when "derived-from-or-self(../encap-type, " 4646 + "'vpn-common:priority-tagged')" { 4647 description 4648 "Only applies when the type of the 4649 tagged interface is 'priority-tagged'."; 4650 } 4651 description 4652 "Priority tagged container."; 4653 leaf tag-type { 4654 type identityref { 4655 base vpn-common:tag-type; 4656 } 4657 default "vpn-common:c-vlan"; 4658 description 4659 "Tag type. By default, the tag type is 4660 'c-vlan'."; 4661 } 4662 } 4663 container qinq { 4664 when "derived-from-or-self(../encap-type, " 4665 + "'vpn-common:qinq')" { 4666 description 4667 "Only applies when the type of the tagged 4668 interface is QinQ."; 4669 } 4670 description 4671 "Includes QinQ parameters."; 4672 leaf tag-type { 4673 type identityref { 4674 base vpn-common:tag-type; 4675 } 4676 default "vpn-common:s-c-vlan"; 4677 description 4678 "Tag type. By default, the tag type is 4679 's-c-vlan'."; 4680 } 4681 leaf svlan-id { 4682 type dot1q-types:vlanid; 4683 mandatory true; 4684 description 4685 "S-VLAN identifier."; 4686 } 4687 leaf cvlan-id { 4688 type dot1q-types:vlanid; 4689 mandatory true; 4690 description 4691 "C-VLAN identifier."; 4692 } 4693 container tag-operations { 4694 description 4695 "Sets the tag manipulation policy for this 4696 VPN network access. It defines a set of 4697 tag manipulations that allow for the 4698 insertion, removal, or rewriting 4699 of 802.1Q VLAN tags. These operations are 4700 indicated for the CE-PE direction. 4701 By default, tag operations are symmetric. 4702 As such, the reverse tag operation is 4703 assumed on the PE-CE direction."; 4704 choice op-choice { 4705 description 4706 "Selects the tag rewriting policy for a 4707 VPN network access."; 4708 leaf pop { 4709 type uint8 { 4710 range "1|2"; 4711 } 4712 description 4713 "Pop one or two tags as a function 4714 of the indicated pop value."; 4715 } 4716 leaf push { 4717 type empty; 4718 description 4719 "Push one or two tags defined by the 4720 tag-1 and tag-2 leaves. It is 4721 assumed that, absent any policy, the 4722 default value of 0 will be used for 4723 PCP setting."; 4724 } 4725 leaf translate { 4726 type uint8 { 4727 range "1|2"; 4728 } 4729 description 4730 "Translate one or two outer tags. PCP 4731 bits are preserved. 4733 The following operations are 4734 supported: 4736 - translate 1 with tag-1 leaf is 4737 provided: only the outermost tag is 4738 translated to the value in tag-1. 4740 - translate 2 with both tag-1 and 4741 tag-2 leaves are provided: both 4742 outer and inner tags are translated 4743 to the values in tag-1 and tag-2, 4744 respectively. 4746 - translate 2 with tag-1 leaf is 4747 provided: the outer tag is popped 4748 while the inner tag is translated 4749 to the value in tag-1."; 4750 } 4751 } 4752 leaf tag-1 { 4753 when 'not(../pop)'; 4754 type dot1q-types:vlanid; 4755 description 4756 "A first tag to be used for push or 4757 translate operations. This tag will be 4758 used as the outermost tag as a result 4759 of the tag operation."; 4760 } 4761 leaf tag-1-type { 4762 type dot1q-types:dot1q-tag-type; 4763 default "dot1q-types:s-vlan"; 4764 description 4765 "Specifies a specific 802.1Q tag type 4766 of tag-1."; 4767 } 4768 leaf tag-2 { 4769 when 'not(../pop)'; 4770 type dot1q-types:vlanid; 4771 description 4772 "A second tag to be used for push or 4773 translate operations."; 4774 } 4775 leaf tag-2-type { 4776 type dot1q-types:dot1q-tag-type; 4777 default "dot1q-types:c-vlan"; 4778 description 4779 "Specifies a specific 802.1Q tag type 4780 of tag-2."; 4782 } 4783 } 4784 } 4785 } 4786 container lag-interface { 4787 if-feature "vpn-common:lag-interface"; 4788 description 4789 "Container of LAG interface attributes 4790 configuration."; 4791 leaf lag-interface-id { 4792 type string; 4793 description 4794 "LAG interface identifier."; 4795 } 4796 container lacp { 4797 description 4798 "Container for LACP."; 4799 leaf lacp-state { 4800 type boolean; 4801 default "false"; 4802 description 4803 "Controls whether LACP is enabled."; 4804 } 4805 leaf mode { 4806 type identityref { 4807 base lacp-mode; 4808 } 4809 description 4810 "Indicates the LACP mode."; 4811 } 4812 leaf speed { 4813 type uint32; 4814 units "mbps"; 4815 default "10"; 4816 description 4817 "LACP speed. This low default value 4818 is inherited from the L2SM."; 4819 } 4820 leaf mini-link-num { 4821 type uint32; 4822 description 4823 "Defines the minimum number of links that 4824 must be active before the aggregating 4825 link is put into service."; 4826 } 4827 leaf system-id { 4828 type yang:mac-address; 4829 description 4830 "Indicates the System ID used by LACP."; 4831 } 4832 leaf admin-key { 4833 type uint16; 4834 description 4835 "Indicates the value of the key used for 4836 the aggregate interface."; 4837 } 4838 leaf system-priority { 4839 type uint16 { 4840 range "0..65535"; 4841 } 4842 default "32768"; 4843 description 4844 "Indicates the LACP priority for the 4845 system."; 4846 } 4847 container member-link-list { 4848 description 4849 "Container of Member link list."; 4850 list member-link { 4851 key "name"; 4852 description 4853 "Member link."; 4854 leaf name { 4855 type string; 4856 description 4857 "Member link name."; 4858 } 4859 leaf speed { 4860 type uint32; 4861 units "mbps"; 4862 default "10"; 4863 description 4864 "Port speed."; 4865 } 4866 leaf mode { 4867 type identityref { 4868 base vpn-common:neg-mode; 4869 } 4870 description 4871 "Negotiation mode."; 4872 } 4873 leaf link-mtu { 4874 type uint32; 4875 units "bytes"; 4876 description 4877 "Link MTU size."; 4879 } 4880 container oam-802.3ah-link { 4881 if-feature "oam-3ah"; 4882 description 4883 "Container for oam 802.3ah link."; 4884 leaf enable { 4885 type boolean; 4886 default "false"; 4887 description 4888 "Indicates support of OAM 802.3ah 4889 link."; 4890 } 4891 } 4892 } 4893 } 4894 leaf flow-control { 4895 type boolean; 4896 default "false"; 4897 description 4898 "Indicates whether flow control is 4899 supported."; 4900 } 4901 leaf lldp { 4902 type boolean; 4903 default "false"; 4904 description 4905 "Indicates whether Link Layer Discovery 4906 Protocol (LLDP) is supported."; 4907 } 4908 } 4909 container split-horizon { 4910 description 4911 "Configuration with split horizon enabled."; 4912 leaf group-name { 4913 type string; 4914 description 4915 "Group name of the Split Horizon."; 4916 } 4917 } 4918 } 4919 } 4920 choice signaling-option { 4921 description 4922 "Choice for the signaling-option."; 4923 case bgp { 4924 description 4925 "BGP is used as the signaling protocol."; 4926 choice bgp-type { 4927 description 4928 "Choice for the BGP type."; 4929 case l2vpn-bgp { 4930 description 4931 "Container for BGP L2VPN."; 4932 leaf ce-id { 4933 type uint16; 4934 description 4935 "Identifies the CE within the VPN."; 4936 reference 4937 "RFC 6624: Layer 2 Virtual Private 4938 Networks Using BGP for 4939 Auto-Discovery and 4940 Signaling"; 4941 } 4942 leaf remote-ce-id { 4943 type uint16; 4944 description 4945 "Indicates the identifier of the remote 4946 CE."; 4947 } 4948 container vpls-instance { 4949 when "derived-from-or-self(../../../../../" 4950 + "vpn-type, 'vpn-common:vpls')" { 4951 description 4952 "Only applies for VPLS."; 4953 } 4954 description 4955 "VPLS instance."; 4956 leaf vpls-edge-id { 4957 type uint16; 4958 description 4959 "VPLS Edge Identifier (VE ID)."; 4960 reference 4961 "RFC 4761: Virtual Private LAN Service 4962 (VPLS) Using BGP for Auto- 4963 Discovery and Signaling, 4964 Section 3.2.1"; 4965 } 4966 } 4967 } 4968 case evpn-bgp { 4969 description 4970 "Used for EVPN."; 4971 leaf df-preference { 4972 type uint16; 4973 default "32767"; 4974 description 4975 "Defines a 2-octet value that indicates 4976 the PE preference to become the DF in 4977 the ES. 4979 The preference value is only applicable 4980 to the preference based method."; 4981 reference 4982 "RFC 8584: Framework for Ethernet VPN 4983 Designated Forwarder Election 4984 Extensibility"; 4985 } 4986 container vpws-service-instance { 4987 when "derived-from-or-self(../../../../../" 4988 + "vpn-type, 'vpn-common:vpws-evpn')" { 4989 description 4990 "Only applies for EVPN-VPWS."; 4991 } 4992 description 4993 "Local and remote VPWS Service Instance 4994 (VSI)"; 4995 reference 4996 "RFC 8214: Virtual Private Wire Service 4997 Support in Ethernet VPN"; 4998 choice local-vsi-choice { 4999 description 5000 "Choices for assigning local VSI."; 5001 case directly-assigned { 5002 description 5003 "Explicitly assign a local VSI."; 5004 leaf local-vpws-service-instance { 5005 type uint32 { 5006 range "1..16777215"; 5007 } 5008 description 5009 "Indicates the assigned local 5010 VSI."; 5011 } 5012 } 5013 case auto-assigned { 5014 description 5015 "The local VSI is auto-assigned."; 5016 container local-vsi-auto { 5017 description 5018 "The local VSI is auto-assigned."; 5019 choice auto-mode { 5020 description 5021 "Indicates the auto-assignment 5022 mode of local VSI. VSI can be 5023 automatically assigned either 5024 with or without indicating a 5025 pool from which the VSI 5026 should be taken. 5028 For both cases, the server 5029 will auto-assign a local VSI 5030 value and use that value."; 5031 case from-pool { 5032 leaf vsi-pool-name { 5033 type string; 5034 description 5035 "The auto-assignment will be 5036 made from this pool."; 5037 } 5038 } 5039 case full-auto { 5040 leaf auto { 5041 type empty; 5042 description 5043 "Indicates that a local VSI 5044 is fully auto-assigned."; 5045 } 5046 } 5047 } 5048 leaf auto-local-vsi { 5049 type uint32 { 5050 range "1..16777215"; 5051 } 5052 config false; 5053 description 5054 "The value of the auto-assigned 5055 local VSI."; 5056 } 5057 } 5058 } 5059 } 5060 choice remote-vsi-choice { 5061 description 5062 "Choice for assigning the remote VSI."; 5063 case directly-assigned { 5064 description 5065 "Explicitly assign a remote VSI."; 5066 leaf remote-vpws-service-instance { 5067 type uint32 { 5068 range "1..16777215"; 5069 } 5070 description 5071 "Indicates the value of the remote 5072 VSI."; 5073 } 5074 } 5075 case auto-assigned { 5076 description 5077 "The remote VSI is auto-assigned."; 5078 container remote-vsi-auto { 5079 description 5080 "The remote VSI is auto-assigned."; 5081 choice auto-mode { 5082 description 5083 "Indicates the auto-assignment 5084 mode of remote VSI. VSI can be 5085 automatically assigned either 5086 with or without indicating a 5087 pool from which the VSI 5088 should be taken. 5090 For both cases, the server 5091 will auto-assign a remote VSI 5092 value and use that value."; 5093 case from-pool { 5094 leaf vsi-pool-name { 5095 type string; 5096 description 5097 "The auto-assignment will be 5098 made from this pool."; 5099 } 5100 } 5101 case full-auto { 5102 leaf auto { 5103 type empty; 5104 description 5105 "Indicates that a remote VSI 5106 is fully auto-assigned."; 5107 } 5108 } 5109 } 5110 leaf auto-remote-vsi { 5111 type uint32 { 5112 range "1..16777215"; 5113 } 5114 config false; 5115 description 5116 "The value of the auto-assigned 5117 remote VSI."; 5118 } 5120 } 5121 } 5122 } 5123 } 5124 } 5125 } 5126 } 5127 } 5128 list group { 5129 key "group-id"; 5130 description 5131 "List of group-ids."; 5132 leaf group-id { 5133 type string; 5134 description 5135 "Indicates the group-id to which the network 5136 access belongs to."; 5137 } 5138 leaf precedence { 5139 type identityref { 5140 base precedence-type; 5141 } 5142 description 5143 "Defining service redundancy in transport 5144 network."; 5145 } 5146 leaf ethernet-segment-identifier { 5147 type l2vpn-es:es-ref; 5148 description 5149 "Reference to the ESI associated with the VPN 5150 network access."; 5151 } 5152 } 5153 container ethernet-service-oam { 5154 description 5155 "Container for Ethernet service OAM."; 5156 leaf md-name { 5157 type string; 5158 description 5159 "Maintenance domain name."; 5160 } 5161 leaf md-level { 5162 type uint8; 5163 description 5164 "Maintenance domain level."; 5165 } 5166 container cfm-802.1-ag { 5167 description 5168 "Container of 802.1ag CFM configurations."; 5169 list n2-uni-c { 5170 key "maid"; 5171 description 5172 "List of UNI-N to UNI-C."; 5173 uses cfm-802; 5174 } 5175 list n2-uni-n { 5176 key "maid"; 5177 description 5178 "List of UNI-N to UNI-N."; 5179 uses cfm-802; 5180 } 5181 } 5182 uses y-1731; 5183 } 5184 container service { 5185 description 5186 "Container for service"; 5187 leaf mtu { 5188 type uint32; 5189 units "bytes"; 5190 description 5191 "Layer 2 MTU, it is also known as the maximum 5192 transmission unit or maximum frame size."; 5193 } 5194 container svc-pe-to-ce-bandwidth { 5195 if-feature "vpn-common:inbound-bw"; 5196 description 5197 "From the customer site's perspective, the 5198 service inbound bandwidth of the connection 5199 or download bandwidth from the service 5200 provider the site. Note that the L2SM uses 5201 'input-bandwidth' to refer to the same 5202 concept."; 5203 list pe-to-ce-bandwidth { 5204 key "bw-type"; 5205 description 5206 "List for PE-to-CE bandwidth data nodes."; 5207 leaf bw-type { 5208 type identityref { 5209 base vpn-common:bw-type; 5210 } 5211 description 5212 "Indicates the bandwidth type."; 5213 } 5214 choice type { 5215 description 5216 "Choice based upon bandwidth type."; 5217 case per-cos { 5218 description 5219 "Bandwidth per CoS."; 5220 list cos { 5221 key "cos-id"; 5222 description 5223 "List of class of services."; 5224 leaf cos-id { 5225 type uint8; 5226 description 5227 "Identifier of the CoS, indicated by 5228 DSCP or a CE-CLAN CoS (802.1p) value 5229 in the service frame."; 5230 reference 5231 "IEEE Std 802.1Q: Bridges and Bridged 5232 Networks"; 5233 } 5234 uses bandwidth-parameters; 5235 } 5236 } 5237 case other { 5238 description 5239 "Other bandwidth types."; 5240 uses bandwidth-parameters; 5241 } 5242 } 5243 } 5244 } 5245 container svc-ce-to-pe-bandwidth { 5246 if-feature "vpn-common:outbound-bw"; 5247 description 5248 "From the customer site's perspective, 5249 the service outbound bandwidth of the 5250 connection or upload bandwidth from 5251 the CE to the PE. Note that the L2SM uses 5252 'output-bandwidth' to refer to the same 5253 concept."; 5254 list ce-to-pe-bandwidth { 5255 key "bw-type"; 5256 description 5257 "List for CE-to-PE bandwidth."; 5258 leaf bw-type { 5259 type identityref { 5260 base vpn-common:bw-type; 5261 } 5262 description 5263 "Indicates the bandwidth type."; 5265 } 5266 choice type { 5267 description 5268 "Choice based upon bandwidth type."; 5269 case per-cos { 5270 description 5271 "Bandwidth per CoS."; 5272 list cos { 5273 key "cos-id"; 5274 description 5275 "List of class of services."; 5276 leaf cos-id { 5277 type uint8; 5278 description 5279 "Identifier of the CoS, indicated by 5280 DSCP or a CE-CLAN CoS (802.1p) value 5281 in the service frame."; 5282 reference 5283 "IEEE Std 802.1Q: Bridges and Bridged 5284 Networks"; 5285 } 5286 uses bandwidth-parameters; 5287 } 5288 } 5289 case other { 5290 description 5291 "Other non CoS-aware bandwidth types."; 5292 uses bandwidth-parameters; 5293 } 5294 } 5295 } 5296 } 5297 container qos { 5298 if-feature "vpn-common:qos"; 5299 description 5300 "QoS configuration."; 5301 container qos-classification-policy { 5302 description 5303 "Configuration of the traffic classification 5304 policy."; 5305 list rule { 5306 key "id"; 5307 ordered-by user; 5308 description 5309 "List of classification rules."; 5310 leaf id { 5311 type string; 5312 description 5313 "A description identifying the QoS 5314 classification policy rule."; 5315 } 5316 choice match-type { 5317 default "match-flow"; 5318 description 5319 "Choice for classification."; 5320 case match-flow { 5321 container match-flow { 5322 description 5323 "Describes flow-matching criteria."; 5324 leaf dscp { 5325 type inet:dscp; 5326 description 5327 "DSCP value."; 5328 } 5329 leaf dot1q { 5330 type uint16; 5331 description 5332 "802.1Q matching. It is a VLAN tag 5333 added into a frame."; 5334 reference 5335 "IEEE Std 802.1Q: Bridges and 5336 Bridged 5337 Networks"; 5338 } 5339 leaf pcp { 5340 type uint8 { 5341 range "0..7"; 5342 } 5343 description 5344 "Priority Code Point (PCP) value."; 5345 } 5346 leaf src-mac-address { 5347 type yang:mac-address; 5348 description 5349 "Source MAC address."; 5350 } 5351 leaf dst-mac-address { 5352 type yang:mac-address; 5353 description 5354 "Destination MAC address."; 5355 } 5356 leaf color-type { 5357 type identityref { 5358 base color-type; 5359 } 5360 description 5361 "Color type."; 5362 } 5363 leaf any { 5364 type empty; 5365 description 5366 "Allows all."; 5367 } 5368 } 5369 } 5370 case match-application { 5371 leaf match-application { 5372 type identityref { 5373 base vpn-common:customer-application; 5374 } 5375 description 5376 "Defines the application to match."; 5377 } 5378 } 5379 } 5380 leaf target-class-id { 5381 type string; 5382 description 5383 "Identification of the CoS. 5384 This identifier is internal to the 5385 administration."; 5386 } 5387 } 5388 } 5389 container qos-profile { 5390 description 5391 "QoS profile configuration."; 5392 list qos-profile { 5393 key "profile"; 5394 description 5395 "QoS profile. 5396 Can be standard profile or customized 5397 profile."; 5398 leaf profile { 5399 type leafref { 5400 path "/l2vpn-ntw/vpn-profiles" 5401 + "/valid-provider-identifiers" 5402 + "/qos-profile-identifier/id"; 5403 } 5404 description 5405 "QoS profile to be used."; 5406 } 5407 leaf direction { 5408 type identityref { 5409 base vpn-common:qos-profile-direction; 5410 } 5411 default "vpn-common:both"; 5412 description 5413 "The direction to which the QoS profile 5414 is applied."; 5415 } 5416 } 5417 } 5418 } 5419 container mac-policies { 5420 description 5421 "Container for MAC-related policies."; 5422 list access-control-list { 5423 key "name"; 5424 description 5425 "Container for access control List."; 5426 leaf name { 5427 type string; 5428 description 5429 "Specifies the name of the ACL."; 5430 } 5431 leaf-list src-mac-address { 5432 type yang:mac-address; 5433 description 5434 "Specifies the source MAC address."; 5435 } 5436 leaf-list src-mac-address-mask { 5437 type yang:mac-address; 5438 description 5439 "Specifies the source MAC address mask."; 5440 } 5441 leaf-list dst-mac-address { 5442 type yang:mac-address; 5443 description 5444 "Specifies the destination MAC address."; 5445 } 5446 leaf-list dst-mac-address-mask { 5447 type yang:mac-address; 5448 description 5449 "Specifies the destination MAC address 5450 mask."; 5451 } 5452 leaf action { 5453 type identityref { 5454 base mac-action; 5455 } 5456 default "drop"; 5457 description 5458 "Specifies the filtering action."; 5459 } 5460 leaf rate-limit { 5461 when "derived-from-or-self(../action, " 5462 + "'flood')" { 5463 description 5464 "Rate-limit is valid only when the action 5465 is to accept the matching frame."; 5466 } 5467 type decimal64 { 5468 fraction-digits 2; 5469 } 5470 units "bytes per second"; 5471 description 5472 "Specifies how to rate-limit the traffic."; 5473 } 5474 } 5475 container mac-loop-prevention { 5476 description 5477 "Container of MAC loop prevention."; 5478 leaf window { 5479 type uint32; 5480 units "seconds"; 5481 default "180"; 5482 description 5483 "The timer when a MAC mobility event is 5484 detected."; 5485 } 5486 leaf frequency { 5487 type uint32; 5488 default "5"; 5489 description 5490 "The number of times to detect MAC 5491 duplication, where a 'duplicate MAC 5492 address' situation has occurred and 5493 the duplicate MAC address has been 5494 added to a list of duplicate MAC 5495 addresses."; 5496 } 5497 leaf retry-timer { 5498 type uint32; 5499 units "seconds"; 5500 description 5501 "The retry timer. When the retry timer 5502 expires, the duplicate MAC address will 5503 be flushed from the MAC-VRF."; 5504 } 5505 leaf protection-type { 5506 type identityref { 5507 base loop-prevention-type; 5508 } 5509 default "trap"; 5510 description 5511 "Protection type"; 5512 } 5513 } 5514 container mac-addr-limit { 5515 description 5516 "Container of MAC-Addr limit configurations"; 5517 leaf limit-number { 5518 type uint16; 5519 default "2"; 5520 description 5521 "Maximum number of MAC addresses learned 5522 from the subscriber for a single service 5523 instance."; 5524 } 5525 leaf time-interval { 5526 type uint32; 5527 units "milliseconds"; 5528 default "300"; 5529 description 5530 "The aging time of the mac address."; 5531 } 5532 leaf action { 5533 type identityref { 5534 base mac-action; 5535 } 5536 default "warning"; 5537 description 5538 "Specifies the action when the upper limit 5539 is exceeded: drop the packet, flood the 5540 packet, or log a warning message (without 5541 dropping the packet)."; 5542 } 5543 } 5544 } 5545 container broadcast-unknown-unicast-multicast { 5546 description 5547 "Container of broadcast, unknown unicast, and 5548 multicast configurations"; 5549 leaf multicast-site-type { 5550 type enumeration { 5551 enum receiver-only { 5552 description 5553 "The site only has receivers."; 5554 } 5555 enum source-only { 5556 description 5557 "The site only has sources."; 5558 } 5559 enum source-receiver { 5560 description 5561 "The site has both sources and 5562 receivers."; 5563 } 5564 } 5565 default "source-receiver"; 5566 description 5567 "Type of the multicast site."; 5568 } 5569 list multicast-gp-address-mapping { 5570 key "id"; 5571 description 5572 "List of Port to group mappings."; 5573 leaf id { 5574 type uint16; 5575 description 5576 "Unique identifier for the mapping."; 5577 } 5578 leaf vlan-id { 5579 type uint32; 5580 mandatory true; 5581 description 5582 "The VLAN ID of the multicast group."; 5583 } 5584 leaf mac-gp-address { 5585 type yang:mac-address; 5586 mandatory true; 5587 description 5588 "The MAC address of the multicast group."; 5589 } 5590 leaf port-lag-number { 5591 type uint32; 5592 description 5593 "The port/LAG belonging to the multicast 5594 group."; 5595 } 5596 } 5597 leaf bum-overall-rate { 5598 type uint64; 5599 units "bps"; 5600 description 5601 "Overall rate for BUM."; 5602 } 5603 } 5604 } 5605 } 5606 } 5607 } 5608 } 5609 } 5610 } 5611 } 5612 } 5613 5615 9. Security Considerations 5617 The YANG modules specified in this document defines schemas for data 5618 that are designed to be accessed via network management protocols 5619 such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF 5620 layer is the secure transport layer, and the mandatory-to-implement 5621 secure transport is Secure Shell (SSH) [RFC6242]. The lowest 5622 RESTCONF layer is HTTPS, and the mandatory-to-implement secure 5623 transport is TLS [RFC8446]. 5625 The Network Configuration Access Control Model (NACM) [RFC8341] 5626 provides the means to restrict access for particular NETCONF or 5627 RESTCONF users to a preconfigured subset of all available NETCONF or 5628 RESTCONF protocol operations and content. 5630 There are a number of data nodes defined in "ietf-l2vpn-ntw" and 5631 "ietf-ethernet-segment" YANG modules that are writable/creatable/ 5632 deletable (i.e., config true, which is the default). These data 5633 nodes may be considered sensitive or vulnerable in some network 5634 environments. Write operations (e.g., edit-config) and delete 5635 operations to these data nodes without proper protection or 5636 authentication can have a negative effect on network operations. 5637 These are the subtrees and data nodes and their sensitivity/ 5638 vulnerability in the "ietf-l2vpn-ntw" and "ietf-ethernet-segment" 5639 modules: 5641 * 'vpn-profiles': This container includes a set of sensitive data 5642 that influence how the L3VPN service is delivered. For example, 5643 an attacker who has access to these data nodes may be able to 5644 manipulate routing policies, QoS policies, or encryption 5645 properties. These data nodes are defined with "nacm:default-deny- 5646 write" tagging [RFC9181]. 5648 * 'ethernet-segments' and 'vpn-services': An attacker who is able to 5649 access network nodes can undertake various attacks, such as 5650 deleting a running L2VPN service, interrupting all the traffic of 5651 a client. In addition, an attacker may modify the attributes of a 5652 running service (e.g., QoS, bandwidth) or an ES, leading to 5653 malfunctioning of the service and therefore to SLA violations. In 5654 addition, an attacker could attempt to create an L2VPN service, 5655 add a new network access, or intercept/redirect the traffic to a 5656 non-authorized node. In addition to using NACM to prevent 5657 authorized access, such activity can be detected by adequately 5658 monitoring and tracking network configuration changes. 5660 Some of the readable data nodes in the "ietf-l2vpn-ntw" YANG module 5661 may be considered sensitive or vulnerable in some network 5662 environments. It is thus important to control read access (e.g., via 5663 get, get-config, or notification) to these data nodes. These are the 5664 subtrees and data nodes and their sensitivity/vulnerability: 5666 * 'customer-name' and 'ip-connection': An attacker can retrieve 5667 privacy-related information which can be used to track a customer. 5668 Disclosing such information may be considered as a violation of 5669 the customer-provider trust relationship. 5671 Both "iana-bgp-l2-encaps" and "iana-pseudowire-types" modules define 5672 YANG identities for encapsulation/pseudowires types. These 5673 identities are intended to be referenced by other YANG modules, and 5674 by themselves do not expose any nodes which are writable, contain 5675 read-only state, or RPCs. 5677 10. IANA Considerations 5679 10.1. Registering YANG Modules 5681 This document requests IANA to register the following URIs in the 5682 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 5684 URI: urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps 5685 Registrant Contact: The IESG. 5686 XML: N/A; the requested URI is an XML namespace. 5688 URI: urn:ietf:params:xml:ns:yang:iana-pseudowire-types 5689 Registrant Contact: The IESG. 5690 XML: N/A; the requested URI is an XML namespace. 5692 URI: urn:ietf:params:xml:ns:yang:ietf-ethernet-segment 5693 Registrant Contact: The IESG. 5694 XML: N/A; the requested URI is an XML namespace. 5696 URI: urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw 5697 Registrant Contact: The IESG. 5698 XML: N/A; the requested URI is an XML namespace. 5700 This document requests IANA to register the following YANG modules in 5701 the "YANG Module Names" subregistry [RFC6020] within the "YANG 5702 Parameters" registry: 5704 name: iana-bgp-l2-encaps 5705 namespace: urn:ietf:params:xml:ns:yang:iana-bgp-l2-encaps 5706 maintained by IANA: Y 5707 prefix: iana-bgp-l2-encaps 5708 reference: RFC XXXX 5710 name: iana-pseudowire-types 5711 namespace: urn:ietf:params:xml:ns:yang:iana-pseudowire-types 5712 maintained by IANA: Y 5713 prefix: iana-pw-types 5714 reference: RFC XXXX 5716 name: ietf-ethernet-segment 5717 namespace: urn:ietf:params:xml:ns:yang:ietf-ethernet-segment 5718 maintained by IANA: N 5719 prefix: l2vpn-es 5720 reference: RFC XXXX 5722 name: ietf-l2vpn-ntw 5723 namespace: urn:ietf:params:xml:ns:yang:ietf-l2vpn-ntw 5724 maintained by IANA: N 5725 prefix: l2vpn-ntw 5726 reference: RFC XXXX 5728 10.2. BGP Layer 2 Encapsulation Types 5730 This document defines the initial version of the IANA-maintained 5731 "iana-bgp-l2-encaps" YANG module (Section 8.1). IANA is requested to 5732 add this note to the registry: 5734 BGP Layer 2 encapsulation types must not be directly added to the 5735 "iana-bgp-l2-encaps" YANG module. They must instead be added to 5736 the "BGP Layer 2 Encapsulation Types" registry [IANA-BGP-L2]. 5738 When a Layer 2 encapsulation type is added to the "BGP Layer 2 5739 Encapsulation Types" registry, a new "identity" statement must be 5740 added to the "iana-bgp-l2-encaps" YANG module. The name of the 5741 "identity" is a lower-case version of the encapsulation name provided 5742 in the description. The "identity" statement should have the 5743 following sub-statements defined: 5745 "base": Contains 'bgp-l2-encaps-type'. 5747 "description": Replicates the description from the registry. 5749 "reference": Replicates the reference from the registry with the 5750 title of the document added. 5752 Unassigned or reserved values are not present in the module. 5754 When the "iana-bgp-l2-encaps" YANG module is updated, a new 5755 "revision" statement with a unique revision date must be added in 5756 front of the existing revision statements. 5758 IANA is requested to add this note to [IANA-BGP-L2]: 5760 When this registry is modified, the YANG module "iana-bgp- 5761 l2-encaps" must be updated as defined in RFCXXXX. 5763 10.3. Pseudowire Types 5765 This document defines the initial version of the IANA-maintained 5766 "iana-pseudowire-types" YANG module (Section 8.2). IANA is requested 5767 to add this note to the registry: 5769 MPLS pseudowire types must not be directly added to the "iana-bgp- 5770 l2-encaps" YANG module. They must instead be added to the "MPLS 5771 Pseudowire Types" registry [IANA-PW-Types]. 5773 When a pseudowire type is added to the "iana-pseudowire-types" 5774 registry, a new "identity" statement must be added to the "iana- 5775 pseudowire-types" YANG module. The name of the "identity" is a 5776 lower-case version of the encapsulation name provided in the 5777 description. The "identity" statement should have the following sub- 5778 statements defined: 5780 "base": Contains 'iana-pw-types'. 5782 "description": Replicates the description from the registry. 5784 "reference": Replicates the reference from the registry with the 5785 title of the document added 5787 Unassigned or reserved values are not present in the module. 5789 When the "iana-pseudowire-types" YANG module is updated, a new 5790 "revision" statement with a unique revision date must be added in 5791 front of the existing revision statements. 5793 IANA is requested to add this note to [IANA-PW-Types]: 5795 When this registry is modified, the YANG module "iana-pseudowire- 5796 types" must be updated as defined in RFCXXXX. 5798 11. References 5800 11.1. Normative References 5802 [IANA-BGP-L2] 5803 IANA, "BGP Layer 2 Encapsulation Types", 5804 . 5807 [IANA-PW-Types] 5808 IANA, "MPLS Pseudowire Types Registry", 5809 . 5812 [IEEE-802-1ag] 5813 IEEE, "802.1ag - 2007 - IEEE Standard for Local and 5814 Metropolitan Area Networks - Virtual Bridged Local Area 5815 Networks Amendment 5: Connectivity Fault Management", 5816 2007, . 5818 [IEEE802.1Qcp-2018] 5819 IEEE, "IEEE Standard for Local and metropolitan area 5820 networks--Bridges and Bridged Networks--Amendment 30: YANG 5821 Data Model", September 2018, 5822 . 5824 [ITU-T-Y-1731] 5825 Union, I. T., "Operations, administration and maintenance 5826 (OAM) functions and mechanisms for Ethernet-based 5827 networks", August 2015, 5828 . 5830 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 5831 DOI 10.17487/RFC3688, January 2004, 5832 . 5834 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 5835 Private Network (VPN) Terminology", RFC 4026, 5836 DOI 10.17487/RFC4026, March 2005, 5837 . 5839 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 5840 Emulation (PWE3)", BCP 116, RFC 4446, 5841 DOI 10.17487/RFC4446, April 2006, 5842 . 5844 [RFC4667] Luo, W., "Layer 2 Virtual Private Network (L2VPN) 5845 Extensions for Layer 2 Tunneling Protocol (L2TP)", 5846 RFC 4667, DOI 10.17487/RFC4667, September 2006, 5847 . 5849 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 5850 LAN Service (VPLS) Using BGP for Auto-Discovery and 5851 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 5852 . 5854 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 5855 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 5856 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 5857 . 5859 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 5860 the Network Configuration Protocol (NETCONF)", RFC 6020, 5861 DOI 10.17487/RFC6020, October 2010, 5862 . 5864 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 5865 "Provisioning, Auto-Discovery, and Signaling in Layer 2 5866 Virtual Private Networks (L2VPNs)", RFC 6074, 5867 DOI 10.17487/RFC6074, January 2011, 5868 . 5870 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 5871 and A. Bierman, Ed., "Network Configuration Protocol 5872 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 5873 . 5875 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 5876 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 5877 . 5879 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 5880 Virtual Private Networks Using BGP for Auto-Discovery and 5881 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 5882 . 5884 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 5885 RFC 6991, DOI 10.17487/RFC6991, July 2013, 5886 . 5888 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 5889 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 5890 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 5891 2015, . 5893 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 5894 Henderickx, "Provider Backbone Bridging Combined with 5895 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 5896 September 2015, . 5898 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 5899 RFC 7950, DOI 10.17487/RFC7950, August 2016, 5900 . 5902 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 5903 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 5904 . 5906 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 5907 Maintenance Using the Label Distribution Protocol (LDP)", 5908 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 5909 . 5911 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 5912 Rabadan, "Virtual Private Wire Service Support in Ethernet 5913 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 5914 . 5916 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 5917 "Common YANG Data Types for the Routing Area", RFC 8294, 5918 DOI 10.17487/RFC8294, December 2017, 5919 . 5921 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 5922 Access Control Model", STD 91, RFC 8341, 5923 DOI 10.17487/RFC8341, March 2018, 5924 . 5926 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 5927 and R. Wilton, "Network Management Datastore Architecture 5928 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 5929 . 5931 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 5932 Uttaro, J., and W. Henderickx, "A Network Virtualization 5933 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 5934 DOI 10.17487/RFC8365, March 2018, 5935 . 5937 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 5938 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 5939 . 5941 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 5942 Data Model for Layer 2 Virtual Private Network (L2VPN) 5943 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 5944 2018, . 5946 [RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, 5947 J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet 5948 VPN Designated Forwarder Election Extensibility", 5949 RFC 8584, DOI 10.17487/RFC8584, April 2019, 5950 . 5952 [RFC9181] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., 5953 Ed., and Q. Wu, "A Common YANG Data Model for Layer 2 and 5954 Layer 3 VPNs", RFC 9181, DOI 10.17487/RFC9181, February 5955 2022, . 5957 11.2. Informative References 5959 [I-D.ietf-bess-evpn-pref-df] 5960 Rabadan, J., Sathappan, S., Przygienda, T., Lin, W., 5961 Drake, J., Sajassi, A., and S. Mohanty, "Preference-based 5962 EVPN DF Election", Work in Progress, Internet-Draft, 5963 draft-ietf-bess-evpn-pref-df-08, 23 September 2021, 5964 . 5967 [I-D.ietf-bess-evpn-yang] 5968 Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., 5969 and J. Rabadan, "Yang Data Model for EVPN", Work in 5970 Progress, Internet-Draft, draft-ietf-bess-evpn-yang-07, 11 5971 March 2019, . 5974 [I-D.ietf-idr-bgp-model] 5975 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 5976 YANG Model for Service Provider Networks", Work in 5977 Progress, Internet-Draft, draft-ietf-idr-bgp-model-13, 6 5978 March 2022, . 5981 [I-D.ietf-opsawg-sap] 5982 Boucadair, M., Dios, O. G. D., Barguil, S., Wu, Q., and V. 5983 Lopez, "A Network YANG Model for Service Attachment Points 5984 (SAPs)", Work in Progress, Internet-Draft, draft-ietf- 5985 opsawg-sap-07, 20 May 2022, 5986 . 5989 [I-D.ietf-teas-enhanced-vpn] 5990 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 5991 Framework for Enhanced Virtual Private Network (VPN+) 5992 Services", Work in Progress, Internet-Draft, draft-ietf- 5993 teas-enhanced-vpn-10, 6 March 2022, 5994 . 5997 [I-D.ietf-teas-ietf-network-slices] 5998 Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, 5999 K., Contreras, L. M., and J. Tantsura, "Framework for IETF 6000 Network Slices", Work in Progress, Internet-Draft, draft- 6001 ietf-teas-ietf-network-slices-10, 27 March 2022, 6002 . 6005 [I-D.ietf-teas-te-service-mapping-yang] 6006 Lee, Y., Dhody, D., Fioccola, G., Wu, Q., Ceccarelli, D., 6007 and J. Tantsura, "Traffic Engineering (TE) and Service 6008 Mapping YANG Model", Work in Progress, Internet-Draft, 6009 draft-ietf-teas-te-service-mapping-yang-10, 7 March 2022, 6010 . 6013 [IEEE-802-1ah] 6014 IEEE, "IEEE Standard for Local and metropolitan area 6015 networks -- Virtual Bridged Local Area Networks Amendment 6016 7: Provider Backbone Bridges", IEEE Std 801.3AH-2008, 6017 2008, 6018 . 6020 [IEEE-802-3ah] 6021 IEEE, "802.3ah - 2004 - IEEE Standard for Information 6022 technology-- Local and metropolitan area networks-- Part 6023 3: CSMA/CD Access Method and Physical Layer Specifications 6024 Amendment: Media Access Control Parameters, Physical 6025 Layers, and Management Parameters for Subscriber Access 6026 Networks", IEEE Std 802.3AH-2004, 2004, . 6029 [IEEE802.1AX] 6030 "Link Aggregation", IEEE Std 802.1AX-2020, 2020. 6032 [IEEE802.1Q] 6033 "Bridges and Bridged Networks", IEEE Std 802.1Q-2018, 6 6034 July 2018, . 6036 [MFA] "The Use of Virtual Trunks for ATM/MPLS Control Plane 6037 Interworking Specification", MFA Forum 9.0.0 , February 6038 2006. 6040 [PYANG] "pyang", November 2020, 6041 . 6043 [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header 6044 Compression", RFC 2507, DOI 10.17487/RFC2507, February 6045 1999, . 6047 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 6048 Headers for Low-Speed Serial Links", RFC 2508, 6049 DOI 10.17487/RFC2508, February 1999, 6050 . 6052 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 6053 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 6054 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 6055 . 6057 [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and 6058 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 6059 High Delay, Packet Loss and Reordering", RFC 3545, 6060 DOI 10.17487/RFC3545, July 2003, 6061 . 6063 [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. 6064 Moore, "Policy Quality of Service (QoS) Information 6065 Model", RFC 3644, DOI 10.17487/RFC3644, November 2003, 6066 . 6068 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 6069 "Encapsulation Methods for Transport of Ethernet over MPLS 6070 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 6071 . 6073 [RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure- 6074 Agnostic Time Division Multiplexing (TDM) over Packet 6075 (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006, 6076 . 6078 [RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, 6079 "Encapsulation Methods for Transport of PPP/High-Level 6080 Data Link Control (HDLC) over MPLS Networks", RFC 4618, 6081 DOI 10.17487/RFC4618, September 2006, 6082 . 6084 [RFC4619] Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed., 6085 "Encapsulation Methods for Transport of Frame Relay over 6086 Multiprotocol Label Switching (MPLS) Networks", RFC 4619, 6087 DOI 10.17487/RFC4619, September 2006, 6088 . 6090 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 6091 2 Virtual Private Networks (L2VPNs)", RFC 4664, 6092 DOI 10.17487/RFC4664, September 2006, 6093 . 6095 [RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., 6096 Brayley, J., and G. Koleyni, "Encapsulation Methods for 6097 Transport of Asynchronous Transfer Mode (ATM) over MPLS 6098 Networks", RFC 4717, DOI 10.17487/RFC4717, December 2006, 6099 . 6101 [RFC4816] Malis, A., Martini, L., Brayley, J., and T. Walsh, 6102 "Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous 6103 Transfer Mode (ATM) Transparent Cell Transport Service", 6104 RFC 4816, DOI 10.17487/RFC4816, February 2007, 6105 . 6107 [RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, 6108 "Synchronous Optical Network/Synchronous Digital Hierarchy 6109 (SONET/SDH) Circuit Emulation over Packet (CEP)", 6110 RFC 4842, DOI 10.17487/RFC4842, April 2007, 6111 . 6113 [RFC4863] Martini, L. and G. Swallow, "Wildcard Pseudowire Type", 6114 RFC 4863, DOI 10.17487/RFC4863, May 2007, 6115 . 6117 [RFC4901] Ash, J., Ed., Hand, J., Ed., and A. Malis, Ed., "Protocol 6118 Extensions for Header Compression over MPLS", RFC 4901, 6119 DOI 10.17487/RFC4901, June 2007, 6120 . 6122 [RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and 6123 P. Pate, "Structure-Aware Time Division Multiplexed (TDM) 6124 Circuit Emulation Service over Packet Switched Network 6125 (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007, 6126 . 6128 [RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, 6129 "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, 6130 DOI 10.17487/RFC5087, December 2007, 6131 . 6133 [RFC5143] Malis, A., Brayley, J., Shirron, J., Martini, L., and S. 6134 Vogelsang, "Synchronous Optical Network/Synchronous 6135 Digital Hierarchy (SONET/SDH) Circuit Emulation Service 6136 over MPLS (CEM) Encapsulation", RFC 5143, 6137 DOI 10.17487/RFC5143, February 2008, 6138 . 6140 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 6141 Header Compression (ROHC) Framework", RFC 5795, 6142 DOI 10.17487/RFC5795, March 2010, 6143 . 6145 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 6146 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 6147 . 6149 [RFC6307] Black, D., Ed., Dunbar, L., Ed., Roth, M., and R. Solomon, 6150 "Encapsulation Methods for Transport of Fibre Channel 6151 Traffic over MPLS Networks", RFC 6307, 6152 DOI 10.17487/RFC6307, April 2012, 6153 . 6155 [RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., 6156 Henderickx, W., and A. Isaac, "Requirements for Ethernet 6157 VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014, 6158 . 6160 [RFC7267] Martini, L., Ed., Bocci, M., Ed., and F. Balus, Ed., 6161 "Dynamic Placement of Multi-Segment Pseudowires", 6162 RFC 7267, DOI 10.17487/RFC7267, June 2014, 6163 . 6165 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 6166 Connectivity Provisioning Profile (CPP)", RFC 7297, 6167 DOI 10.17487/RFC7297, July 2014, 6168 . 6170 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 6171 RFC 7951, DOI 10.17487/RFC7951, August 2016, 6172 . 6174 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 6175 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 6176 . 6178 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 6179 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 6180 . 6182 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 6183 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 6184 . 6186 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 6187 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 6188 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 6189 2018, . 6191 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 6192 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 6193 DOI 10.17487/RFC8453, August 2018, 6194 . 6196 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 6197 "YANG Data Model for Network Access Control Lists (ACLs)", 6198 RFC 8519, DOI 10.17487/RFC8519, March 2019, 6199 . 6201 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, 6202 "Handling Long Lines in Content of Internet-Drafts and 6203 RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, 6204 . 6206 [RFC8960] Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A 6207 YANG Data Model for MPLS Base", RFC 8960, 6208 DOI 10.17487/RFC8960, December 2020, 6209 . 6211 [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and 6212 L. Geng, "A Framework for Automating Service and Network 6213 Management with YANG", RFC 8969, DOI 10.17487/RFC8969, 6214 January 2021, . 6216 Appendix A. Examples 6218 This section includes a non-exhaustive list of examples to illustrate 6219 the use of the L2NM. 6221 In the following subsections, only the content of the message bodies 6222 is shown using JSON notations [RFC7951]. 6224 The examples use the folding defined in [RFC8792] for long lines. 6226 A.1. BGP-based VPLS 6228 This section provides an example to illustrate how the L2NM can be 6229 used to manage BGP-based VPLS. We consider the sample VPLS service 6230 delivered using the architecture depicted in Figure 23. In 6231 accordance with [RFC4761], we assume that a full mesh is established 6232 between all PEs. The details about such full mesh are not detailed 6233 here. 6235 +-----+ +--------------+ +-----+ 6236 +----+ | PE1 |===| |===| PE3 | +----+ 6237 | CE1+-------+ | | | | +-------+ CE3| 6238 +----+ +-----+ | | +-----+ +----+ 6239 | Core | 6240 +----+ +-----+ | | +-----+ +----+ 6241 |CE2 +-------+ | | | | +-------+ CE4| 6242 +----+ | PE2 |===| |===| PE4 | +----+ 6243 +-----+ +--------------+ +-----+ 6245 Figure 23: An Example of VPLS 6247 Figure 24 show an example of a message body used to configure a VPLS 6248 instance using the L2NM. In this example, BGP is used for both auto- 6249 discovery and signaling. The 'signaling-type' data node is set to 6250 'vpn-common:bgp-signaling'. 6252 =============== NOTE: '\' line wrapping per RFC 8792 ================ 6254 { 6255 "ietf-l2vpn-ntw:l2vpn-ntw": { 6256 "vpn-services": { 6257 "vpn-service": [ 6258 { 6259 "vpn-id": "vpls7714825356", 6260 "vpn-description": "Sample BGP-based VPLS", 6261 "customer-name": "customer-7714825356", 6262 "vpn-type": "ietf-vpn-common:vpls", 6263 "bgp-ad-enabled": true, 6264 "signaling-type": "ietf-vpn-common:bgp-signaling", 6265 "global-parameters-profiles": { 6266 "global-parameters-profile": [ 6267 { 6268 "profile-id": "simple-profile", 6269 "local-autonomous-system": 65535, 6270 "svc-mtu": 1518, 6271 "rd-suffix": 1, 6272 "vpn-target": [ 6273 { 6274 "id": 1, 6275 "route-targets": [ 6276 { 6277 "route-target": "0:65535:1" 6278 } 6279 ], 6280 "route-target-type": "both" 6281 } 6282 ] 6284 } 6285 ] 6286 }, 6287 "vpn-nodes": { 6288 "vpn-node": [ 6289 { 6290 "vpn-node-id": "pe1", 6291 "ne-id": "198.51.100.1", 6292 "active-global-parameters-profiles": { 6293 "global-parameters-profile": [ 6294 { 6295 "profile-id": "simple-profile" 6296 } 6297 ] 6298 }, 6299 "bgp-auto-discovery": { 6300 "vpn-id": "1" 6301 }, 6302 "signaling-option": { 6303 "pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet\ 6304 -tagged-mode", 6305 "vpls-instance": { 6306 "vpls-edge-id": 1, 6307 "vpls-edge-id-range": 100 6308 } 6309 }, 6310 "vpn-network-accesses": { 6311 "vpn-network-access": [ 6312 { 6313 "id": "1/1/1.1", 6314 "interface-id": "1/1/1", 6315 "description": "Interface to CE1", 6316 "active-vpn-node-profile": "simple-profile", 6317 "status": { 6318 "admin-status": { 6319 "status": "ietf-vpn-common:admin-up" 6320 } 6321 }, 6322 "connection": { 6323 "encapsulation": { 6324 "encap-type": "ietf-vpn-common:dot1q", 6325 "dot1q": { 6326 "cvlan-id": 1 6327 } 6328 } 6329 } 6330 } 6331 ] 6333 } 6334 }, 6335 { 6336 "vpn-node-id": "pe2", 6337 "ne-id": "198.51.100.2", 6338 "active-global-parameters-profiles": { 6339 "global-parameters-profile": [ 6340 { 6341 "profile-id": "simple-profile" 6342 } 6343 ] 6344 }, 6345 "bgp-auto-discovery": { 6346 "vpn-id": "1" 6347 }, 6348 "signaling-option": { 6349 "pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet\ 6350 -tagged-mode", 6351 "vpls-instance": { 6352 "vpls-edge-id": 2, 6353 "vpls-edge-id-range": 100 6354 } 6355 }, 6356 "vpn-network-accesses": { 6357 "vpn-network-access": [ 6358 { 6359 "id": "1/1/1.1", 6360 "interface-id": "1/1/1", 6361 "description": "Interface to CE2", 6362 "active-vpn-node-profile": "simple-profile", 6363 "status": { 6364 "admin-status": { 6365 "status": "ietf-vpn-common:admin-up" 6366 } 6367 }, 6368 "connection": { 6369 "encapsulation": { 6370 "encap-type": "ietf-vpn-common:dot1q", 6371 "dot1q": { 6372 "cvlan-id": 1 6373 } 6374 } 6375 } 6376 } 6377 ] 6378 } 6379 }, 6380 { 6381 "vpn-node-id": "pe3", 6382 "ne-id": "198.51.100.3", 6383 "active-global-parameters-profiles": { 6384 "global-parameters-profile": [ 6385 { 6386 "profile-id": "simple-profile" 6387 } 6388 ] 6389 }, 6390 "bgp-auto-discovery": { 6391 "vpn-id": "1" 6392 }, 6393 "signaling-option": { 6394 "pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet\ 6395 -tagged-mode", 6396 "vpls-instance": { 6397 "vpls-edge-id": 3, 6398 "vpls-edge-id-range": 100 6399 } 6400 }, 6401 "vpn-network-accesses": { 6402 "vpn-network-access": [ 6403 { 6404 "id": "1/1/1.1", 6405 "interface-id": "1/1/1", 6406 "description": "Interface to CE3", 6407 "active-vpn-node-profile": "simple-profile", 6408 "status": { 6409 "admin-status": { 6410 "status": "ietf-vpn-common:admin-up" 6411 } 6412 }, 6413 "connection": { 6414 "encapsulation": { 6415 "encap-type": "ietf-vpn-common:dot1q", 6416 "dot1q": { 6417 "cvlan-id": 1 6418 } 6419 } 6420 } 6421 } 6422 ] 6423 } 6424 }, 6425 { 6426 "vpn-node-id": "pe4", 6427 "ne-id": "198.51.100.4", 6428 "active-global-parameters-profiles": { 6429 "global-parameters-profile": [ 6430 { 6431 "profile-id": "simple-profile" 6432 } 6433 ] 6434 }, 6435 "bgp-auto-discovery": { 6436 "vpn-id": "1" 6437 }, 6438 "signaling-option": { 6439 "pw-encapsulation-type": "iana-bgp-l2-encaps:ethernet\ 6440 -tagged-mode", 6441 "vpls-instance": { 6442 "vpls-edge-id": 4, 6443 "vpls-edge-id-range": 100 6444 } 6445 }, 6446 "vpn-network-accesses": { 6447 "vpn-network-access": [ 6448 { 6449 "id": "1/1/1.1", 6450 "interface-id": "1/1/1", 6451 "description": "Interface to CE4", 6452 "active-vpn-node-profile": "simple-profile", 6453 "status": { 6454 "admin-status": { 6455 "status": "ietf-vpn-common:admin-up" 6456 } 6457 }, 6458 "connection": { 6459 "encapsulation": { 6460 "encap-type": "ietf-vpn-common:dot1q", 6461 "dot1q": { 6462 "cvlan-id": 1 6463 } 6464 } 6465 } 6466 } 6467 ] 6468 } 6469 } 6470 ] 6471 } 6472 } 6473 ] 6474 } 6475 } 6476 } 6477 Figure 24: Example of L2NM Message Body to Configure a BGP-based VPLS 6479 A.2. BGP-based VPWS with LDP Signaling 6481 Let's consider the simple architecture depicted in Figure 25 to offer 6482 a VPWS between CE1 and CE2. The service uses BGP for auto-discovery 6483 and LDP for signaling. 6485 +-----+ +--------------+ +-----+ 6486 +----+ | PE1 |===| |===| PE2 | +----+ 6487 | CE1+-------+ | | Core | | +-------+ CE2| 6488 +----+ +-----+ +--------------+ +-----+ +----+ 6489 site1 site2 6491 Figure 25: An Example of VPLS 6493 { 6494 "ietf-l2vpn-ntw:l2vpn-ntw": { 6495 "vpn-services": { 6496 "vpn-service": [ 6497 { 6498 "vpn-id": "vpws12345", 6499 "vpn-description": "Sample VPWS", 6500 "customer-name": "customer-12345", 6501 "vpn-type": "ietf-vpn-common:vpws", 6502 "bgp-ad-enabled": true, 6503 "signaling-type": "ietf-vpn-common:ldp-signaling", 6504 "global-parameters-profiles": { 6505 "global-parameters-profile": [ 6506 { 6507 "profile-id": "simple-profile", 6508 "local-autonomous-system": 65550, 6509 "rd-auto": { 6510 "auto": [ 6511 null 6512 ] 6513 }, 6514 "vpn-target": [ 6515 { 6516 "id": 1, 6517 "route-targets": [ 6518 { 6519 "route-target": "0:65535:1" 6520 } 6521 ], 6522 "route-target-type": "both" 6524 } 6525 ] 6526 } 6527 ] 6528 }, 6529 "vpn-nodes": { 6530 "vpn-node": [ 6531 { 6532 "vpn-node-id": "pe1", 6533 "ne-id": "2001:db8:100::1", 6534 "active-global-parameters-profiles": { 6535 "global-parameters-profile": [ 6536 { 6537 "profile-id": "simple-profile" 6538 } 6539 ] 6540 }, 6541 "bgp-auto-discovery": { 6542 "vpn-id": "587" 6543 }, 6544 "signaling-option": { 6545 "advertise-mtu": true, 6546 "ldp-or-l2tp": { 6547 "saii": 1, 6548 "remote-targets": [ 6549 { 6550 "taii": 2 6551 } 6552 ], 6553 "t-ldp-pw-type": "ethernet" 6554 } 6555 }, 6556 "vpn-network-accesses": { 6557 "vpn-network-access": [ 6558 { 6559 "id": "1/1/1.1", 6560 "interface-id": "1/1/1", 6561 "description": "Interface to CE1", 6562 "active-vpn-node-profile": "simple-profile", 6563 "status": { 6564 "admin-status": { 6565 "status": "ietf-vpn-common:admin-up" 6566 } 6567 } 6568 } 6569 ] 6570 } 6571 }, 6572 { 6573 "vpn-node-id": "pe2", 6574 "ne-id": "2001:db8:200::1", 6575 "active-global-parameters-profiles": { 6576 "global-parameters-profile": [ 6577 { 6578 "profile-id": "simple-profile" 6579 } 6580 ] 6581 }, 6582 "bgp-auto-discovery": { 6583 "vpn-id": "587" 6584 }, 6585 "signaling-option": { 6586 "advertise-mtu": true, 6587 "ldp-or-l2tp": { 6588 "saii": 2, 6589 "remote-targets": [ 6590 { 6591 "taii": 1 6592 } 6593 ], 6594 "t-ldp-pw-type": "ethernet" 6595 } 6596 }, 6597 "vpn-network-accesses": { 6598 "vpn-network-access": [ 6599 { 6600 "id": "5/1/1.1", 6601 "interface-id": "5/1/1", 6602 "description": "Interface to CE2", 6603 "active-vpn-node-profile": "simple-profile", 6604 "status": { 6605 "admin-status": { 6606 "status": "ietf-vpn-common:admin-up" 6607 } 6608 } 6609 } 6610 ] 6611 } 6612 } 6613 ] 6614 } 6615 } 6616 ] 6617 } 6618 } 6619 } 6620 Figure 26: Example of L2NM Message Body to Configure a BGP-based 6621 VPWS with LDP Signaling 6623 A.3. LDP-based VPLS 6625 This section provides an example to illustrate how the L2NM can be 6626 used to manage a VPLS with LDP signaling. The connectivity between 6627 the CE and the PE is direct using Dot1q encapsulation [IEEE802.1Q]. 6628 We consider the sample service delivered using the architecture 6629 depicted in Figure 27. 6631 +---------- VPLS "1543" ----------+ 6633 +-----+ +--------------+ +-----+ 6634 +----+ | PE1 |===| |===| PE2 | +----+ 6635 | CE1 +-----+"450"| | MPLS | |"451"+-------+ CE2| 6636 +----+ +-----+ | | +-----+ +----+ 6637 | Core | 6638 +--------------+ 6640 Figure 27: An Example of VPLS topology 6642 Figure 28 shows how the L2NM is used to instruct both PE1 and PE2 to 6643 use the targeted LDP session between them to establish the VPLS 6644 "1543" between the ends. A single VPN service is created for this 6645 purpose. Additionally, two VPN Nodes and each with a corresponding 6646 VPN network access is also created. 6648 =============== NOTE: '\' line wrapping per RFC 8792 ================ 6650 { 6651 "ietf-l2vpn-ntw:l2vpn-ntw": { 6652 "vpn-services": { 6653 "vpn-service": [ 6654 { 6655 "vpn-id": "450", 6656 "vpn-name": "CORPO-EXAMPLE", 6657 "vpn-description": "SEDE_CENTRO_450", 6658 "customer-name": "EXAMPLE", 6659 "vpn-type": "ietf-vpn-common:vpls", 6660 "vpn-service-topology": "ietf-vpn-common:hub-spoke", 6661 "bgp-ad-enabled": false, 6662 "signaling-type": "ietf-vpn-common:ldp-signaling", 6663 "global-parameters-profiles": { 6664 "global-parameters-profile": [ 6665 { 6666 "profile-id": "simple-profile", 6667 "ce-vlan-preservation": true, 6668 "ce-vlan-cos-preservation": true 6669 } 6670 ] 6671 }, 6672 "vpn-nodes": { 6673 "vpn-node": [ 6674 { 6675 "vpn-node-id": "450", 6676 "description": "SEDE_CENTRO_450", 6677 "ne-id": "2001:db8:5::1", 6678 "role": "ietf-vpn-common:hub-role", 6679 "status": { 6680 "admin-status": { 6681 "status": "ietf-vpn-common:admin-up" 6682 } 6683 }, 6684 "active-global-parameters-profiles": { 6685 "global-parameters-profile": [ 6686 { 6687 "profile-id": "simple-profile" 6688 } 6689 ] 6690 }, 6691 "signaling-option": { 6692 "ldp-or-l2tp": { 6693 "t-ldp-pw-type": "vpls-type", 6694 "pw-peer-list": [ 6695 { 6696 "peer-addr": "2001:db8:50::1", 6697 "vc-id": "1543" 6698 } 6699 ] 6700 } 6701 }, 6702 "vpn-network-accesses": { 6703 "vpn-network-access": [ 6704 { 6705 "id": "4508671287", 6706 "description": "VPN_450_SNA", 6707 "interface-id": "gigabithethernet0/0/1", 6708 "status": { 6709 "admin-status": { 6710 "status": "ietf-vpn-common:admin-up" 6711 } 6712 }, 6713 "connection": { 6714 "l2-termination-point": "550", 6715 "encapsulation": { 6716 "encap-type": "ietf-vpn-common:dot1q", 6717 "dot1q": { 6718 "tag-type": "ietf-vpn-common:c-vlan", 6719 "cvlan-id": 550 6720 } 6721 } 6722 }, 6723 "service": { 6724 "mtu": 1550, 6725 "svc-pe-to-ce-bandwidth": { 6726 "pe-to-ce-bandwidth": [ 6727 { 6728 "bw-type": "ietf-vpn-common:bw-per-port", 6729 "cir": "20480000" 6730 } 6731 ] 6732 }, 6733 "svc-ce-to-pe-bandwidth": { 6734 "ce-to-pe-bandwidth": [ 6735 { 6736 "bw-type": "ietf-vpn-common:bw-per-port", 6737 "cir": "20480000" 6738 } 6739 ] 6740 }, 6741 "qos": { 6742 "qos-profile": { 6743 "qos-profile": [ 6744 { 6745 "profile": "QoS_Profile_A", 6746 "direction": "ietf-vpn-common:both" 6747 } 6748 ] 6749 } 6750 } 6751 } 6752 } 6753 ] 6754 } 6755 }, 6756 { 6757 "vpn-node-id": "451", 6758 "description": "SEDE_CHAPINERO_451", 6759 "ne-id": "2001:db8:50::1", 6760 "role": "ietf-vpn-common:spoke-role", 6761 "status": { 6762 "admin-status": { 6763 "status": "ietf-vpn-common:admin-up" 6764 } 6765 }, 6766 "active-global-parameters-profiles": { 6767 "global-parameters-profile": [ 6768 { 6769 "profile-id": "simple-profile" 6770 } 6771 ] 6772 }, 6773 "signaling-option": { 6774 "ldp-or-l2tp": { 6775 "t-ldp-pw-type": "vpls-type", 6776 "pw-peer-list": [ 6777 { 6778 "peer-addr": "2001:db8:5::1", 6779 "vc-id": "1543" 6780 } 6781 ] 6782 } 6783 }, 6784 "vpn-network-accesses": { 6785 "vpn-network-access": [ 6786 { 6787 "id": "4508671288", 6788 "description": "VPN_450_SNA", 6789 "interface-id": "gigabithethernet0/0/1", 6790 "status": { 6791 "admin-status": { 6792 "status": "ietf-vpn-common:admin-up" 6793 } 6794 }, 6795 "connection": { 6796 "l2-termination-point": "550", 6797 "encapsulation": { 6798 "encap-type": "ietf-vpn-common:dot1q", 6799 "dot1q": { 6800 "tag-type": "ietf-vpn-common:c-vlan", 6801 "cvlan-id": 550 6802 } 6803 } 6804 }, 6805 "service": { 6806 "mtu": 1550, 6807 "svc-pe-to-ce-bandwidth": { 6808 "pe-to-ce-bandwidth": [ 6809 { 6810 "bw-type": "ietf-vpn-common:bw-per-port", 6811 "cir": "20480000" 6812 } 6813 ] 6814 }, 6815 "svc-ce-to-pe-bandwidth": { 6816 "ce-to-pe-bandwidth": [ 6817 { 6818 "bw-type": "ietf-vpn-common:bw-per-port", 6819 "cir": "20480000" 6820 } 6821 ] 6822 }, 6823 "qos": { 6824 "qos-profile": { 6825 "qos-profile": [ 6826 { 6827 "profile": "QoS_Profile_A", 6828 "direction": "ietf-vpn-common:both" 6829 } 6830 ] 6831 } 6832 } 6833 } 6834 } 6835 ] 6836 } 6837 } 6838 ] 6839 } 6840 } 6841 ] 6842 } 6843 } 6844 } 6846 Figure 28: Example of L2NM Message Body for LDP-based VPLS 6848 A.4. VPWS-EVPN Service Instance 6850 Figure 29 depicts a sample architecture to offer VPWS-EVPN service 6851 between CE1 and CE2. Both CEs are multi-homed. BGP sessions are 6852 maintained between these PEs as per [RFC8214]. In this EVPN 6853 instance, an All-Active redundancy mode is used. 6855 |<-------- EVPN Instance --------->| 6856 | | 6857 ESI1 V V ESI2 6858 | +-----+ +--------------+ +-----+ | 6859 +----+ | | PE1 |===| |===| PE3 | | +----+ 6860 | +-------+ | | | | +-------+ | 6861 | | | +-----+ | | +-----+ | | | 6862 | CE1| | | Core | | |CE2 | 6863 | | | +-----+ | | +-----+ | | | 6864 | +-------+ | | | | +-------+ | 6865 +----+ | | PE2 |===| |===| PE4 | | +----+ 6866 ^ | +-----+ +--------------+ +-----+ | ^ 6867 | ESI1 ESI2 | 6868 |<-------------- Emulated Service ---------------->| 6870 Figure 29: An Example of VPWS-EVPN 6872 Let's first suppose that the following ES was created (Figure 30). 6874 =============== NOTE: '\' line wrapping per RFC 8792 ================ 6876 { 6877 "ietf-ethernet-segment:ethernet-segments": { 6878 "ethernet-segment": [ 6879 { 6880 "name": "esi1", 6881 "ethernet-segment-identifier": "00:11:11:11:11:11:11:\ 6882 11:11:11", 6883 "esi-redundancy-mode": "all-active" 6884 }, 6885 { 6886 "name": "esi2", 6887 "ethernet-segment-identifier": "00:22:22:22:22:22:22:\ 6888 22:22:22", 6889 "esi-redundancy-mode": "all-active" 6890 } 6891 ] 6892 } 6893 } 6895 Figure 30: Example of L2NM Message Body to Configure an Ethernet 6896 Segment 6898 Figure 29 shows a simplified configuration to illustrate the use of 6899 the L2NM to configured VPWS-EVPN instance. 6901 { 6902 "ietf-l2vpn-ntw:l2vpn-ntw": { 6903 "vpn-services": { 6904 "vpn-service": [ 6905 { 6906 "vpn-id": "vpws15432855", 6907 "vpn-description": "Sample VPWS-EVPN", 6908 "customer-name": "customer_15432855", 6909 "vpn-type": "ietf-vpn-common:vpws-evpn", 6910 "bgp-ad-enabled": true, 6911 "signaling-type": "ietf-vpn-common:bgp-signaling", 6912 "global-parameters-profiles": { 6913 "global-parameters-profile": [ 6914 { 6915 "profile-id": "simple-profile", 6916 "local-autonomous-system": 65535, 6917 "rd-suffix": 1, 6918 "vpn-target": [ 6919 { 6920 "id": 1, 6921 "route-targets": [ 6922 { 6923 "route-target": "0:65535:1" 6924 } 6925 ], 6926 "route-target-type": "both" 6927 } 6928 ] 6929 } 6930 ] 6931 }, 6932 "vpn-nodes": { 6933 "vpn-node": [ 6934 { 6935 "vpn-node-id": "pe1", 6936 "ne-id": "198.51.100.1", 6937 "active-global-parameters-profiles": { 6938 "global-parameters-profile": [ 6939 { 6940 "profile-id": "simple-profile" 6941 } 6942 ] 6943 }, 6944 "vpn-network-accesses": { 6945 "vpn-network-access": [ 6946 { 6947 "id": "1/1/1.1", 6948 "interface-id": "1/1/1", 6949 "description": "Interface to CE1", 6950 "active-vpn-node-profile": "simple-profile", 6951 "status": { 6952 "admin-status": { 6953 "status": "ietf-vpn-common:admin-up" 6954 } 6955 }, 6956 "connection": { 6957 "encapsulation": { 6958 "encap-type": "ietf-vpn-common:dot1q", 6959 "dot1q": { 6960 "cvlan-id": 1 6961 } 6962 } 6963 }, 6964 "vpws-service-instance": { 6965 "local-vpws-service-instance": 1111, 6966 "remote-vpws-service-instance": 1112 6967 }, 6968 "group": [ 6969 { 6970 "group-id": "gr1", 6971 "ethernet-segment-identifier": "esi1" 6972 } 6973 ] 6974 } 6975 ] 6976 } 6977 }, 6978 { 6979 "vpn-node-id": "pe2", 6980 "ne-id": "198.51.100.2", 6981 "active-global-parameters-profiles": { 6982 "global-parameters-profile": [ 6983 { 6984 "profile-id": "simple-profile" 6985 } 6986 ] 6987 }, 6988 "vpn-network-accesses": { 6989 "vpn-network-access": [ 6990 { 6991 "id": "1/1/1.1", 6992 "interface-id": "1/1/1", 6993 "description": "Interface to CE1", 6994 "active-vpn-node-profile": "simple-profile", 6995 "status": { 6996 "admin-status": { 6997 "status": "ietf-vpn-common:admin-up" 6998 } 6999 }, 7000 "connection": { 7001 "encapsulation": { 7002 "encap-type": "ietf-vpn-common:dot1q", 7003 "dot1q": { 7004 "cvlan-id": 1 7005 } 7006 } 7007 }, 7008 "vpws-service-instance": { 7009 "local-vpws-service-instance": 1111, 7010 "remote-vpws-service-instance": 1112 7011 }, 7012 "group": [ 7013 { 7014 "group-id": "gr1", 7015 "ethernet-segment-identifier": "esi1" 7016 } 7017 ] 7018 } 7019 ] 7020 } 7021 }, 7022 { 7023 "vpn-node-id": "pe3", 7024 "ne-id": "198.51.100.3", 7025 "active-global-parameters-profiles": { 7026 "global-parameters-profile": [ 7027 { 7028 "profile-id": "simple-profile" 7029 } 7030 ] 7031 }, 7032 "vpn-network-accesses": { 7033 "vpn-network-access": [ 7034 { 7035 "id": "1/1/1.1", 7036 "interface-id": "1/1/1", 7037 "description": "Interface to CE2", 7038 "active-vpn-node-profile": "simple-profile", 7039 "status": { 7040 "admin-status": { 7041 "status": "ietf-vpn-common:admin-up" 7042 } 7043 }, 7044 "connection": { 7045 "encapsulation": { 7046 "encap-type": "ietf-vpn-common:dot1q", 7047 "dot1q": { 7048 "cvlan-id": 1 7049 } 7050 } 7051 }, 7052 "vpws-service-instance": { 7053 "local-vpws-service-instance": 1112, 7054 "remote-vpws-service-instance": 1111 7055 }, 7056 "group": [ 7057 { 7058 "group-id": "gr1", 7059 "ethernet-segment-identifier": "esi2" 7060 } 7061 ] 7062 } 7063 ] 7064 } 7065 }, 7066 { 7067 "vpn-node-id": "pe4", 7068 "ne-id": "198.51.100.4", 7069 "active-global-parameters-profiles": { 7070 "global-parameters-profile": [ 7071 { 7072 "profile-id": "simple-profile" 7073 } 7074 ] 7075 }, 7076 "vpn-network-accesses": { 7077 "vpn-network-access": [ 7078 { 7079 "id": "1/1/1.1", 7080 "interface-id": "1/1/1", 7081 "description": "Interface to CE2", 7082 "active-vpn-node-profile": "simple-profile", 7083 "status": { 7084 "admin-status": { 7085 "status": "ietf-vpn-common:admin-up" 7086 } 7087 }, 7088 "connection": { 7089 "encapsulation": { 7090 "encap-type": "ietf-vpn-common:dot1q", 7091 "dot1q": { 7092 "cvlan-id": 1 7094 } 7095 } 7096 }, 7097 "vpws-service-instance": { 7098 "local-vpws-service-instance": 1112, 7099 "remote-vpws-service-instance": 1111 7100 }, 7101 "group": [ 7102 { 7103 "group-id": "gr1", 7104 "ethernet-segment-identifier": "esi2" 7105 } 7106 ] 7107 } 7108 ] 7109 } 7110 } 7111 ] 7112 } 7113 } 7114 ] 7115 } 7116 } 7117 } 7119 Figure 31: Example of L2NM Message Body to Configure a VPWS-EVPN 7120 Instance 7122 A.5. Automatic ESI Assignment 7124 This section provides an example to illustrate how the L2NM can be 7125 used to manage ESI auto-assignment. We consider the sample EVPN 7126 service delivered using the architecture depicted in Figure 32. 7128 ES 7129 | +-----+ +--------------+ +-----+ 7130 +----+ | | PE1 |======| |===| PE3 | +----+ 7131 | +-------+ | | | | +-------+ CE3| 7132 | | | +-----+ | | +-----+ +----+ 7133 | CE1| | | Core | 7134 | | | +-----+ | | +-----+ +----+ 7135 | +-------+ | | | | +-------+ CE2| 7136 +----+ | | PE2 |======| |===| PE4 | +----+ 7137 | +-----+ +--------------+ +-----+ 7138 LACP 7140 Figure 32: An Example of Automatic ESI Assignment 7142 Figure 33 and Figure 34 show how the L2NM is used to instruct both 7143 PE1 and PE2 to auto-assign the ESI to identify the ES used with CE1. 7144 In this example, we suppose that LACP is enabled and that a Type 1 7145 (T=0x01) is used as per Section 5 of [RFC7432]. Note that this 7146 example does not include all the details to configure the EVPN 7147 service, but focuses only on the ESI management part. 7149 { 7150 "ietf-ethernet-segment:ethernet-segments": { 7151 "ethernet-segment": [ 7152 { 7153 "name": "esi1", 7154 "esi-type": "esi-type-1-lacp", 7155 "esi-redundancy-mode": "all-active" 7156 } 7157 ] 7158 } 7159 } 7161 Figure 33: Example of L2NM Message Body to Auto-Assign Ethernet 7162 Segment Identifiers 7164 { 7165 "ietf-l2vpn-ntw:l2vpn-ntw": { 7166 "ietf-l2vpn-ntw:vpn-services": { 7167 "vpn-service": [ 7168 { 7169 "vpn-id": "auto-esi-lacp", 7170 "vpn-description": "Sample to illustrate auto-ESI", 7171 "vpn-type": "ietf-vpn-common:vpws-evpn", 7172 "vpn-nodes": { 7173 "vpn-node": [ 7174 { 7175 "vpn-node-id": "pe1", 7176 "ne-id": "198.51.100.1", 7177 "vpn-network-accesses": { 7178 "vpn-network-access": [ 7179 { 7180 "id": "1/1/1.1", 7181 "interface-id": "1/1/1", 7182 "description": "Interface to CE1", 7183 "status": { 7184 "admin-status": { 7185 "status": "ietf-vpn-common:admin-up" 7186 } 7187 }, 7188 "connection": { 7189 "lag-interface": { 7190 "lag-interface-id": "1", 7191 "lacp": { 7192 "lacp-state": true, 7193 "system-id": "11:00:11:00:11:11", 7194 "admin-key": 154 7195 } 7196 } 7197 }, 7198 "group": [ 7199 { 7200 "group-id": "gr1", 7201 "ethernet-segment-identifier": "esi1" 7202 } 7203 ] 7204 } 7205 ] 7206 } 7207 }, 7208 { 7209 "vpn-node-id": "pe2", 7210 "ne-id": "198.51.100.2", 7211 "vpn-network-accesses": { 7212 "vpn-network-access": [ 7213 { 7214 "id": "2/2/2.5", 7215 "interface-id": "2/2/2", 7216 "description": "Interface to CE1", 7217 "status": { 7218 "admin-status": { 7219 "status": "ietf-vpn-common:admin-up" 7220 } 7221 }, 7222 "connection": { 7223 "lag-interface": { 7224 "lag-interface-id": "1", 7225 "lacp": { 7226 "lacp-state": true, 7227 "system-id": "11:00:11:00:11:11", 7228 "admin-key": 154 7229 } 7230 } 7231 }, 7232 "group": [ 7233 { 7234 "group-id": "gr1", 7235 "ethernet-segment-identifier": "esi1" 7237 } 7238 ] 7239 } 7240 ] 7241 } 7242 } 7243 ] 7244 } 7245 } 7246 ] 7247 } 7248 } 7249 } 7251 Figure 34: An Example of L2NM Message Body for ESI Auto-Assignment 7253 The auto-assigned ESI can be retrieved using, e.g., a GET RESTCONF 7254 method. The assigned value will be then returned as shown in the 7255 'esi-auto' data node in Figure 35. 7257 =============== NOTE: '\' line wrapping per RFC 8792 ================ 7259 { 7260 "ietf-ethernet-segment:ethernet-segments": { 7261 "ethernet-segment": [ 7262 { 7263 "name": "esi1", 7264 "ethernet-segment-identifier": "esi-type-1-lacp", 7265 "esi-auto": { 7266 "auto-ethernet-segment-identifier": "01:11:00:11:00:11:\ 7267 11:9a:00:00" 7268 }, 7269 "esi-redundancy-mode": "all-active" 7270 } 7271 ] 7272 } 7273 } 7275 Figure 35: An Example of L2NM Message Body to Retrieve the 7276 Assigned ESI 7278 A.6. VPN Network Access Precedence 7280 In reference to the example depicted in Figure 36, an L2VPN service 7281 involves two VPN network accesses to sites that belong to the same 7282 customer. 7284 +--------------+ 7285 |VPN-NODE | 7286 | +--+-------+ 7287 | | NET-ACC-1| Primary 7288 | | +------------------ 7289 | +--+-------+ 7290 | | 7291 | +--+-------+ 7292 | | NET-ACC-2| Secondary 7293 | | +------------------ 7294 | +--+-------+ 7295 | | 7296 +--------------+ 7298 Figure 36: Example of Multiple VPN Network Accesses 7300 In order to tag one of these VPN network accesses as "primary" and 7301 the other one as "secondary", Figure 37 shows an excerpt of the 7302 corresponding L2NM configuration. In such a configuration, both 7303 accesses are bound to the same "group-id" and the "precedence" data 7304 node set as function of the intended role of each access (primary or 7305 secondary). 7307 { 7308 "ietf-l2vpn-ntw:l2vpn-ntw": { 7309 "vpn-services": { 7310 "vpn-service": [ 7311 { 7312 "vpn-id": "Sample-Service", 7313 "vpn-nodes": { 7314 "vpn-node": [ 7315 { 7316 "vpn-node-id": "VPN-NODE", 7317 "vpn-network-accesses": { 7318 "vpn-network-access": [ 7319 { 7320 "id": "NET-ACC-1", 7321 "connection": { 7322 "bearer-reference": "br1" 7323 }, 7324 "group": [ 7325 { 7326 "group-id": "1", 7327 "precedence": "primary" 7328 } 7329 ] 7330 }, 7331 { 7332 "id": "NET-ACC-2", 7333 "connection": { 7334 "bearer-reference": "br2" 7335 }, 7336 "group": [ 7337 { 7338 "group-id": "1", 7339 "precedence": "secondary" 7340 } 7341 ] 7342 } 7343 ] 7344 } 7345 } 7346 ] 7347 } 7348 } 7349 ] 7350 } 7351 } 7352 } 7353 Figure 37: Example of Message Body to Associate Priority Levels 7354 with VPN Network Accesses 7356 Acknowledgements 7358 During the discussions of this work, helpful comments, suggestions, 7359 and reviews were received from: Sergio Belotti, Italo Busi, Miguel 7360 Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque Gagliano, 7361 Christian Jacquenet, Kireeti Kompella, Julian Lucek, Moti 7362 Morgenstern, Erez Segev, and Tom Petch. Many thanks to them. 7364 Luay Jalil, Jichun Ma, Daniel King, and Zhang Guiyu contributed to an 7365 early version of this document. 7367 Thanks to Yingzhen Qu and Himanshu Shah for the rtgdir reviews, 7368 Ladislav Lhotka for the yangdoctors review, Chris Lonvick for the 7369 secdir review, and Dale Worley for the gen-art review. Special 7370 thanks to Adrian Farrel for the careful Shepherd review. 7372 Thanks to Robert Wilton for the careful AD review and various 7373 suggestions to enhance the model. 7375 Thanks to Lars Eggert, Erik Kline, Roman Danyliw, Francesca 7376 Palombini, Zaheduzzaman Sarker, and Eric Vyncke for the IESG review. 7378 A YANG module for Ethernet segments was first defined in the context 7379 of the EVPN device module [I-D.ietf-bess-evpn-yang]. 7381 This work is partially supported by the European Commission under 7382 Horizon 2020 grant agreement number 101015857 Secured autonomic 7383 traffic management for a Tera of SDN flows (Teraflow). 7385 Contributors 7387 Victor Lopez 7388 Nokia 7389 Email: victor.lopez@nokia.com 7391 Qin Wu 7392 Huawei 7393 Email: bill.wu@huawei.com 7395 Raul Arco 7396 Nokia 7397 Email: raul.arco@nokia.com 7399 Authors' Addresses 7401 Mohamed Boucadair (editor) 7402 Orange 7403 Rennes 7404 France 7405 Email: mohamed.boucadair@orange.com 7407 Oscar Gonzalez de Dios (editor) 7408 Telefonica 7409 Madrid 7410 Spain 7411 Email: oscar.gonzalezdedios@telefonica.com 7413 Samier Barguil 7414 Telefonica 7415 Madrid 7416 Spain 7417 Email: samier.barguilgiraldo.ext@telefonica.com 7419 Luis Angel Munoz 7420 Vodafone 7421 Spain 7422 Email: luis-angel.munoz@vodafone.com