idnits 2.17.1 draft-ietf-opsawg-l3sm-l3nm-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 630 has weird spacing: '...--rw id str...' == Line 632 has weird spacing: '...--rw id str...' == Line 634 has weird spacing: '...--rw id str...' == Line 636 has weird spacing: '...--rw id str...' == Line 638 has weird spacing: '...--rw id str...' == (11 more instances...) -- The document date (February 22, 2021) is 1131 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) == Outdated reference: A later version (-12) exists of draft-ietf-opsawg-vpn-common-03 == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-10 == Outdated reference: A later version (-12) exists of draft-ietf-rtgwg-qos-model-02 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-06 == Outdated reference: A later version (-01) exists of draft-ietf-teas-ietf-network-slice-definition-00 Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG S. Barguil 3 Internet-Draft O. Gonzalez de Dios, Ed. 4 Intended status: Standards Track Telefonica 5 Expires: August 26, 2021 M. Boucadair, Ed. 6 Orange 7 L. Munoz 8 Vodafone 9 A. Aguado 10 Nokia 11 February 22, 2021 13 A Layer 3 VPN Network YANG Model 14 draft-ietf-opsawg-l3sm-l3nm-06 16 Abstract 18 This document defines a L3VPN Network YANG Model (L3NM) that can be 19 used for the provisioning of Layer 3 Virtual Private Network (VPN) 20 services within a service provider network. The model provides a 21 network-centric view of L3VPN services. 23 L3NM is meant to be used by a network controller to derive the 24 configuration information that will be sent to relevant network 25 devices. The model can also facilitate the communication between a 26 service orchestrator and a network controller/orchestrator. 28 Editorial Note (To be removed by RFC Editor) 30 Please update these statements within the document with the RFC 31 number to be assigned to this document: 33 o "This version of this YANG module is part of RFC XXXX;" 35 o "RFC XXXX: Layer 3 VPN Network Model"; 37 o reference: RFC XXXX 39 Also, please update the "revision" date of the YANG module. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on August 26, 2021. 58 Copyright Notice 60 Copyright (c) 2021 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 4. L3NM Reference Architecture . . . . . . . . . . . . . . . . . 7 79 5. Relation with other YANG Models . . . . . . . . . . . . . . . 10 80 6. Sample Uses of the L3NM Data Model . . . . . . . . . . . . . 11 81 6.1. Enterprise Layer 3 VPN Services . . . . . . . . . . . . . 11 82 6.2. Multi-Domain Resource Management . . . . . . . . . . . . 11 83 6.3. Management of Multicast Services . . . . . . . . . . . . 12 84 7. Description of the L3NM YANG Module . . . . . . . . . . . . . 12 85 7.1. Overall Structure of the Module . . . . . . . . . . . . . 13 86 7.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 13 87 7.3. VPN Services . . . . . . . . . . . . . . . . . . . . . . 14 88 7.4. Import/Export Profiles . . . . . . . . . . . . . . . . . 17 89 7.5. VPN Nodes . . . . . . . . . . . . . . . . . . . . . . . . 19 90 7.6. VPN Network Access . . . . . . . . . . . . . . . . . . . 23 91 7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 24 92 7.6.2. IP Connections . . . . . . . . . . . . . . . . . . . 26 93 7.6.3. CE-PE Routing Protocols . . . . . . . . . . . . . . . 29 94 7.6.4. OAM . . . . . . . . . . . . . . . . . . . . . . . . . 40 95 7.6.5. Security . . . . . . . . . . . . . . . . . . . . . . 41 96 7.6.6. Services . . . . . . . . . . . . . . . . . . . . . . 42 97 7.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 47 98 8. L3NM YANG Module . . . . . . . . . . . . . . . . . . . . . . 52 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 103 100 10. Security Considerations . . . . . . . . . . . . . . . . . . . 103 101 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 104 102 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 105 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 105 104 13.1. Normative References . . . . . . . . . . . . . . . . . . 105 105 13.2. Informative References . . . . . . . . . . . . . . . . . 108 106 Appendix A. L3VPN Examples . . . . . . . . . . . . . . . . . . . 112 107 A.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 112 108 A.2. Multicast VPN Provisioning Example . . . . . . . . . . . 118 109 Appendix B. Implementation Status . . . . . . . . . . . . . . . 122 110 B.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 122 111 B.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 122 112 B.3. Infinera Implementation . . . . . . . . . . . . . . . . . 123 113 B.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 123 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 123 116 1. Introduction 118 [RFC8299] defines a Layer 3 Virtual Private Network Service YANG data 119 Model (L3SM) that can be used for communication between customers and 120 network operators. Such model is focused on describing the customer 121 view of the Virtual Private Network (VPN) services and provides an 122 abstracted view of the customer's requested services. That approach 123 limits the usage of the L3SM to the role of a Customer Service Model 124 (as per [RFC8309]). 126 This document defines a YANG module called L3VPN Network Model 127 (L3NM). The L3NM is aimed at providing a network-centric view of 128 Layer 3 (L3) VPN services. This data model can be used to facilitate 129 communication between the service orchestrator (or a network 130 operator) and the network controller/orchestrator by allowing for 131 more network-centric information to be included. It enables further 132 capabilities, such as resource management or to serve as a multi- 133 domain orchestration interface, where logical resources (such as 134 route targets or route distinguishers) must be coordinated. 136 This document uses the common VPN YANG module defined in 137 [I-D.ietf-opsawg-vpn-common]. 139 This document does not obsolete [RFC8299]. These two modules are 140 used for similar objectives but with different scopes and views. 142 The L3NM YANG module is initially built with a prune and extend 143 approach, taking as a starting points the YANG module described in 145 [RFC8299]. Nevertheless, the L3NM is not defined as an augment to 146 L3SM because a specific structure is required to meet network- 147 oriented L3 needs. 149 Some of the information captured in the L3SM can be passed by the 150 Orchestrator in the L3NM (e.g., customer) or be used to fed some of 151 the L3NM attributes (e.g., actual forwarding policies). Some of the 152 information captured in L3SM may be maintained locally within the 153 Orchestrator; which is in charge of maintaining the correspondence 154 between a customer view and its network instantiation. Likewise, 155 some of the information captured and exposed using the L3NM can feed 156 the service layer (e.g., capabilities) to drive VPN service order 157 handling, and thus the L3SM. 159 Section 5.1 of [RFC8969] illustrates how the L3NM can be used within 160 the network management automation architecture. 162 The L3NM does not attempt to address all deployment cases especially 163 those where the L3VPN connectivity is supported through the 164 coordination of different VPNs in different underlying networks. 165 More complex deployment scenarios involving the coordination of 166 different VPN instances and different technologies to provide an end- 167 to-end VPN connectivity are addressed by complementary YANG modules, 168 e.g., [I-D.evenwu-opsawg-yang-composed-vpn]. 170 L3NM focuses on BGP Provider Edge (PE) based Layer 3 VPNs as 171 described in [RFC4026][RFC4110][RFC4364] and Multicast VPNs as 172 described in [RFC6037][RFC6513][RFC7988]. 174 The YANG data model in this document conforms to the Network 175 Management Datastore Architecture (NMDA) defined in [RFC8342]. 177 2. Terminology 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 181 "OPTIONAL" in this document are to be interpreted as described in BCP 182 14 [RFC2119] [RFC8174] when, and only when, they appear in all 183 capitals, as shown here. 185 This document assumes that the reader is familiar with the contents 186 of [RFC6241], [RFC7950], [RFC8299], [RFC8309], and [RFC8453] and uses 187 the terminology defined in those documents. 189 This document uses the term "network model" defined in Section 2.1 of 190 [RFC8969]. 192 The meaning of the symbols in the tree diagrams is defined in 193 [RFC8340]. 195 This document makes use of the following terms: 197 Layer 3 VPN Customer Service Model (L3SM): A YANG module that 198 describes the service requirements of a L3VPN that interconnects a 199 set of sites from the point of view of the customer. The customer 200 service model does not provide details on the service provider 201 network. The L3VPN Customer Service model is defined in 202 [RFC8299]. 204 Layer 3 VPN Service Network Model (L3NM): A YANG module that 205 describes a VPN service in the service provider network. It 206 contains information of the service provider network and might 207 include allocated resources. It can be used by network 208 controllers to manage and control the VPN service configuration in 209 the service provider network. The YANG module can be consumed by 210 a service orchestrator to request a VPN service to a Network 211 Controller. 213 Service orchestrator: A functional entity that interacts with the 214 customer of a L3VPN. The service orchestrator interacts with the 215 customer using the L3SM. The service orchestrator is responsible 216 of the Customer Edge (CE) - Provider Edge (PE) attachment 217 circuits, the PE selection, and requesting the VPN service to the 218 Network Controller. 220 Network orchestrator: A functional entity that is hierarchically 221 intermediate between a service orchestrator and network 222 nontrollers. A network orchestrator can manage one or several 223 network nontrollers. 225 Network controller: A functional entity responsible for the control 226 and management of the service provider network. 228 VPN node: An abstraction that represents a set of policies applied 229 on a PE and that belong to a single VPN service. A VPN service 230 involves one or more VPN nodes. As it is an abstraction, the 231 network controller will take on how to implement a VPN node. For 232 example, typically, in a BGP-based VPN, a VPN node could be mapped 233 into a Virtual Routing and Forwarding (VRF). 235 VPN network access: An abstraction that represents the network 236 interfaces that are associated to a given VPN node. Traffic 237 coming from the VPN network access belongs to the VPN. The 238 attachment circuits (bearers) between CEs and PEs are terminated 239 in the VPN network access. A reference to the bearer is 240 maintained to allow keeping the link between L3SM and L3NM. 242 VPN site: A VPN customer's location that is connected to the 243 service provider network via a CE-PE link, which can access at 244 least one VPN [RFC4176]. 246 VPN service provider: A service provider that offers VPN-related 247 services [RFC4176]. 249 Service provider network: A network that is able to provide VPN- 250 related services. 252 The document is aimed at modeling BGP PE-based VPNs in a service 253 provider network, so the terms defined in [RFC4026] and [RFC4176] are 254 used. 256 3. Acronyms 258 The following acronyms are used in the document: 260 ACL Access Control List 261 AS Autonomous System 262 ASM Any-Source Multicast 263 ASN AS Number 264 BSR Bootstrap Router 265 BFD Bidirectional Forwarding Detection 266 BGP Border Gateway Protocol 267 CE Customer Edge 268 IGMP nternet Group Management Protocol 269 L3VPN Layer 3 Virtual Private Network 270 L3SM L3VPN Service Model 271 L3NM L3VPN Network Model 272 MLD Multicast Listener Discovery 273 MSDP Multicast Source Discovery Protocol 274 MVPN Multicast VPN 275 NAT Network Address Translation 276 OAM Operations, Administration, and Maintenance 277 OSPF Open Shortest Path First 278 PE Provider Edge 279 PIM Protocol Independent Multicast 280 QoS Quality of Service 281 RD Route Distinguisher 282 RP Rendez-vous Point 283 RT Route Target 284 SA Security Association 285 SSM Source-Specific Multicast 286 VPN Virtual Private Network 287 VRF Virtual Routing and Forwarding 289 4. L3NM Reference Architecture 291 Figure 1 depicts the reference architecture for the L3NM. The figure 292 is an expansion of the architecture presented in Section 5 of 293 [RFC8299]; it decomposes the box marked "orchestration" in that 294 section into three separate functional components: Service 295 Orchestration, Network Orchestration, and Domain Orchestration. 297 Although some deployments may choose to construct a monolithic 298 orchestration component (covering both service and network matters), 299 this document advocates for a clear separation between service and 300 network orchestration components for the sake of better flexibility. 301 Such design adheres to the L3VPN reference architecture defined in 302 Section 1.3 of [RFC4176]. This separation relies upon a dedicated 303 communication interface between these components and appropriate YANG 304 module that reflect network-related information (that is hidden to 305 customers). 307 The intelligence for translating customer-facing information into 308 network-centric one is implementation specific. 310 The terminology from [RFC8309] is introduced to show the distinction 311 between the customer service model, the service delivery model, the 312 network configuration model, and the device configuration model. In 313 that context, the "Domain Orchestration" and "Config Manager" roles 314 may be performed by "Controllers". 316 +---------------+ 317 | Customer | 318 +---------------+ 319 Customer Service Model | 320 e.g., l3vpn-svc | 321 +---------------+ 322 | Service | 323 | Orchestration | 324 +---------------+ 325 Network Model | 326 l3vpn-ntw | 327 +---------------+ 328 | Network | 329 | Orchestration | 330 +---------------+ 331 Network Configuration Model | 332 +-----------+-----------+ 333 | | 334 +---------------+ +---------------+ 335 | Domain | | Domain | 336 | Orchestration | | Orchestration | 337 +---------------+ +---------------+ 338 Device | | | 339 Configuration | | | 340 Model | | | 341 +---------+ | | 342 | Config | | | 343 | Manager | | | 344 +---------+ | | 345 | | | 346 | NETCONF/CLI.................. 347 | | | 348 +------------------------------------------------+ 349 Network 351 Figure 1: L3NM Reference Architecture 353 The customer may use a variety of means to request a service that may 354 trigger the instantiation of a L3NM. The customer may use the L3SM 355 or may rely upon more abstract models to request a service that 356 relies upon an L3VPN service. For example, the customer may supply 357 an IP Connectivity Provisioning Profile (CPP) [RFC7297], an enhanced 358 VPN (VPN+) service [I-D.ietf-teas-enhanced-vpn], an IETF network 359 slice [I-D.ietf-teas-ietf-network-slice-definition], or Abstraction 360 and Control of TE Networks (ACTN) [RFC8453]. 362 Note also that both the L3SM and the L3NM may be used in the context 363 of the ACTN architecture. Figure 2 shows the Customer Network 364 Controller (CNC), the Multi-Domain Service Coordinator (MDSC), and 365 the Provisioning Network Controller (PNC). 367 +----------------------------------+ 368 | Customer | 369 | +-----------------------------+ | 370 | | CNC | | 371 | +-----------------------------+ | 372 +----:-----------------------:-----+ 373 : : 374 : L3SM : L3SM 375 : : 376 +---------:---------+ +-------------------+ 377 | MDSC : | | MDSC | 378 | +---------------+ | | (parent) | 379 | | Service | | +-------------------+ 380 | | Orchestration | | : 381 | +---------------+ | : L3NM 382 | : | : 383 | : L3NM | +-------------------+ 384 | : | | MDSC | 385 | +---------------+ | | (child) | 386 | | Network | | +-------------------+ 387 | | Orchestration | | : 388 | +---------------+ | : 389 +---------:---------+ : 390 : : 391 : Network Configuration : 392 : : 393 +------------:-------+ +---------:------------+ 394 | Domain : | | : Domain | 395 | Controller : | | : Controller | 396 | +---------+ | | +---------+ | 397 | | PNC | | | | PNC | | 398 | +---------+ | | +---------+ | 399 +------------:-------+ +---------:------------+ 400 : : 401 : Device Configuration : 402 : : 403 +--------+ +--------+ 404 | Device | | Device | 405 +--------+ +--------+ 407 Figure 2: L3SM and L3NM in the Context of ACTN 409 5. Relation with other YANG Models 411 The "ietf-vpn-common" module [I-D.ietf-opsawg-vpn-common] includes a 412 set of identities, types, and groupings that are meant to be reused 413 by VPN-related YANG modules independently of the layer (e.g., Layer 414 2, Layer 3) and the type of the module (e.g., network model, service 415 model) including future revisions of existing models (e.g., [RFC8299] 416 or [RFC8466]). The L3NM reuses these common types and groupings. 418 In order to avoid data duplication and to ease passing data between 419 layers when required (service layer to network layer and vice versa), 420 early versions of the L3NM reused many of the data nodes that are 421 defined in [RFC8299]. Nevertheless, that approach was abandoned in 422 favor of the "ietf-vpn-common" module because that initial design was 423 interpreted as if the deployment of L3NM depends on L3SM, while this 424 is not the case. For example, a service provider may decide to use 425 the L3NM to build its L3VPN services without exposing the L3SM. 427 As discussed in Section 4, the L3NM is meant to manage L3VPN services 428 within a service provider network. The module provides a network 429 view of the service. Such view is only visible within the service 430 provider and is not exposed outside (to customers, for example). The 431 following discusses how L3NM interfaces with other YANG modules: 433 L3SM: L3NM is not a customer service model. 435 The internal view of the service (i.e., L3NM) may be mapped to an 436 external view which is visible to customers: L3VPN Service YANG 437 data Model (L3SM) [RFC8299]. 439 The L3NM can be fed with inputs that are requested by customers, 440 typically, relying upon a L3SM template. Concretely, some parts 441 of the L3SM module can be directly mapped into L3NM while other 442 parts are generated as a function of the requested service and 443 local guidelines. Some other parts are local to the service 444 provider and do not map directly to L3SM. 446 Note that the use of L3NM within a service provider does not 447 assume nor preclude exposing the VPN service via the L3SM. This 448 is deployment-specific. Nevertheless, the design of L3NM tries to 449 align as much as possible with the features supported by the L3SM 450 to ease grafting both L3NM and L3SM for the sake of highly 451 automated VPN service provisioning and delivery. 453 Network Topology Modules: A L3VPN involves nodes that are part of a 454 topology managed by the service provider network. Such topology 455 can be represented as using the network topology module in 456 [RFC8345]. 458 Device Modules: L3NM is not a device model. 460 Once a global VPN service is captured by means of L3NM, the actual 461 activation and provisioning of the VPN service will involve a 462 variety of device modules to tweak the required functions for the 463 delivery of the service. These functions are supported by the VPN 464 nodes and can be managed using device YANG modules. A non- 465 comprehensive list of such device YANG modules is provided below: 467 * Routing management [RFC8349]. 469 * BGP [I-D.ietf-idr-bgp-model]. 471 * PIM [I-D.ietf-pim-yang]. 473 * NAT management [RFC8512]. 475 * QoS management [I-D.ietf-rtgwg-qos-model]. 477 * ACLs [RFC8519]. 479 How L3NM is used to derive device-specific actions is 480 implementation-specific. 482 6. Sample Uses of the L3NM Data Model 484 This section provides a non-exhaustive list of examples to illustrate 485 contexts where the L3NM can be used. 487 6.1. Enterprise Layer 3 VPN Services 489 Enterprise L3VPNs are one of the most demanded services for carriers, 490 and therefore, L3NM can be useful to automate the provisioning and 491 maintenance of these VPNs. Templates and batch processes can be 492 built, and as a result many parameters are needed for the creation 493 from scratch of a VPN that can be abstracted to the upper Software- 494 Defined Networking (SDN) [RFC7149][RFC7426] layer and little manual 495 intervention will be still required. 497 Also common addition and/or removal of sites of an existing customer 498 VPN can benefit of using L3NM by creation of workflows that either 499 prune or add nodes as required from the network data mode. 501 6.2. Multi-Domain Resource Management 503 The implementation of L3VPN services which span across 504 administratively separated domains (i.e., that are under the 505 administration of different management systems or controllers) 506 requires some network resources to be synchronized between systems. 507 Particularly, there are two resources that must be orchestrated and 508 manage to avoid asymmetric (non-functional) configuration, or the 509 usage of unavailable resources. 511 For example, route targets (RTs) shall be synchronized between PEs. 512 When all PEs are controlled by the same management system, RT 513 allocation can be performed by that management system. In cases 514 where the service spans across multiple management systems, the task 515 of allocating RTs has to be aligned across the domains, therefore, 516 the service model must provide a way to specify RTs. In addition, 517 route distinguishers (RDs) must also be synchronized to avoid 518 collisions in RD allocation between separate management systems. An 519 incorrect allocation might lead to the same RD and IP prefixes being 520 exported by different PEs. 522 6.3. Management of Multicast Services 524 Multicast services over L3VPN can be implemented using dual PIM MVPNs 525 (also known as, Draft Rosen model) [RFC4364] or Multiprotocol BGP 526 (MP-BGP)-based MVPNs [RFC6513][RFC6514]. Both methods are supported 527 and equally effective, but the main difference is that MBGP-based 528 MVPN does not require multicast configuration on the service provider 529 network. MBGP MVPNs employ the intra-autonomous system BGP control 530 plane and PIM sparse mode as the data plane. The PIM state 531 information is maintained between PEs using the same architecture 532 that is used for unicast VPNs. 534 On the other hand, [RFC4364] has limitations such as reduced options 535 for transport, control plane scalability, availability, operational 536 inconsistency, and the need of maintaining state in the backbone. 537 Because of these limitations, MBGP MVPN is the architectural model 538 that has been taken as the base for implementing multicast service in 539 L3VPNs. In this scenario, BGP auto discovery is used to discover 540 MVPN PE members and the customer PIM signaling is sent across the 541 provider's core through MP-BGP. The multicast traffic is transported 542 on MPLS P2MP LSPs. 544 7. Description of the L3NM YANG Module 546 The L3NM ('ietf-l3vpn-ntw') is defined to manage L3VPNs in a service 547 provider network. In particular, the 'ietf-l3vpn-ntw' module can be 548 used to create, modify, and retrieve L3VPN services of a network. 550 The full tree diagram of the module can be generated using the 551 "pyang" tool [PYANG]. That tree is not included here because it is 552 too long (Section 3.3 of [RFC8340]). Instead, subtrees are provided 553 for the reader's convenience. 555 7.1. Overall Structure of the Module 557 The 'ietf-l3vpn-ntw' module uses two main containers: 'vpn-services' 558 and 'vpn-profiles' (see Figure 3). 560 The 'vpn-profiles' container is used by the provider to maintain a 561 set of common VPN profiles that apply to one or several VPN services 562 (Section 7.2). 564 The 'vpn-services' container maintains the set of VPN services 565 managed within the service provider network. 'vpn-service' is the 566 data structure that abstracts a VPN service (Section 7.3). 568 module: ietf-l3vpn-ntw 569 +--rw l3vpn-ntw 570 +--rw vpn-profiles 571 | ... 572 +--rw vpn-services 573 +--rw vpn-service* [vpn-id] 574 ... 575 +--rw vpn-nodes 576 +--rw vpn-node* [vpn-node-id] 577 ... 578 +--rw vpn-network-accesses 579 +--rw vpn-network-access* [id] 580 ... 582 Figure 3: Overall L3NM Tree Structure 584 7.2. VPN Profiles 586 The 'vpn-profiles' container (Figure 4) allows the VPN service 587 provider to define and maintain a set of VPN profiles 588 [I-D.ietf-opsawg-vpn-common] that apply to one or several VPN 589 services. 591 This document does not make any assumption about the exact definition 592 of these profiles. The exact definition of the profiles is local to 593 each VPN service provider. The model only includes an identifier to 594 these profiles in order to ease identifying and binding local 595 policies when building a VPN service. As shown in Figure 4, the 596 following identifiers can be included: 598 'external-connectivity-identifier': This identifier refers to a 599 profile that defines the external connectivity provided to a VPN 600 service (or a subset of VPN sites). An external connectivity may 601 be an access to the Internet or a restricted connectivity such as 602 access to a public/private cloud. 604 'encryption-profile-identifier': An encryption profile refers to a 605 set of policies related to the encryption scheme(s) and setup that 606 can be applied when building and offering a VPN service. 608 'qos-profile-identifier': A Quality of Service (QoS) profile refers 609 to as set of policies such as classification, marking, and actions 610 (e.g., [RFC3644]). 612 'bfd-profile-identifier': A Bidirectional Forwarding Detection (BFD) 613 profile refers to a set of BFD [RFC5880] policies that can be 614 invoked when building a VPN service. 616 'forwarding-profile-identifier': A forwarding profile refers to the 617 policies that apply to the forwarding of packets conveyed within a 618 VPN. Such policies may consist, for example, at applying Access 619 Control Lists (ACLs). 621 'routing-profile-identifier': A routing profile refers to a set of 622 routing policies that will be invoked (e.g., BGP policies) when 623 delivering the VPN service. 625 +--rw l3vpn-ntw 626 +--rw vpn-profiles 627 | +--rw valid-provider-identifiers 628 | +--rw external-connectivity-identifier* [id] 629 | | {external-connectivity}? 630 | | +--rw id string 631 | +--rw encryption-profile-identifier* [id] 632 | | +--rw id string 633 | +--rw qos-profile-identifier* [id] 634 | | +--rw id string 635 | +--rw bfd-profile-identifier* [id] 636 | | +--rw id string 637 | +--rw forwarding-profile-identifier* [id] 638 | | +--rw id string 639 | +--rw routing-profile-identifier* [id] 640 | +--rw id string 641 +--rw vpn-services 642 ... 644 Figure 4: VPN Profiles Subtree Structure 646 7.3. VPN Services 648 The 'vpn-service' is the data structure that abstracts a VPN service 649 in the service provider network. Each 'vpn-service' is uniquely 650 identified by an identifier: 'vpn-id'. Such 'vpn-id' is only 651 meaningful locally within the network controller. The subtree of the 652 'vpn-services' is shown in Figure 5. 654 +--rw l3vpn-ntw 655 +--rw vpn-profiles 656 | ... 657 +--rw vpn-services 658 +--rw vpn-service* [vpn-id] 659 +--rw vpn-id vpn-id 660 +--rw vpn-name? string 661 +--rw vpn-description? string 662 +--rw customer-name? string 663 +--rw parent-service-id? vpn-common:vpn-id 664 +--rw vpn-type? identityref 665 +--rw vpn-service-topology? identityref 666 +--rw status 667 | +--rw admin-status 668 | | +--rw status? identityref 669 | | +--rw last-updated? yang:date-and-time 670 | +--ro oper-status 671 | +--ro status? identityref 672 | +--ro last-updated? yang:date-and-time 673 +--rw ie-profiles 674 | ... 675 +--rw underlay-transport 676 | +-- (type)? 677 | +--:(abstract) 678 | | +-- transport-instance-id? string 679 | +--:(protocol) 680 | +-- protocol* identityref 681 +--rw external-connectivity 682 | {external-connectivity} 683 | +--rw (profile)? 684 | +--:(profile) 685 | +--rw profile-name? leafref 686 +--rw vpn-nodes 687 ... 689 Figure 5: VPN Services Subtree Structure 691 The description of the VPN service data nodes that are depicted in 692 Figure 5 are as follows: 694 'vpn-id': Is an identifier that is used to uniquely identify the 695 L3VPN service within L3NM scope. 697 'vpn-name': Associates a name with the service in order to 698 facilitate the identification of the service. 700 'vpn-description': Includes a textual description of the service. 702 The internal structure of a VPN description is local to each VPN 703 service provider. 705 'customer-name': Indicates the name of the customer who ordered the 706 service. 708 'parent-service-id': Refers to an identifier of the parent service 709 (e.g, L3SM, IETF network slice, VPN+) that triggered the creation 710 of the VPN service. This identifier is used to easily correlate 711 the (network) service as built in the network with a service 712 order. A controller can use that correlation to enrich or 713 populate some fields (e.g., description fields) as a function of 714 local deployments. 716 'vpn-type': Indicates the VPN type. The values are taken from 717 [I-D.ietf-opsawg-vpn-common]. For the L3NM, this is typically set 718 to BGP/MPLS L3VPN. 720 'vpn-service-topology': Indicates the network topology for the 721 service: hub-spoke, any-to-any, or custom. The network 722 implementation of this attribute is defined by the correct usage 723 of import and export profiles (Section 4.3.5 of [RFC4364]). 725 'status': Is used to track the service status of a given VPN 726 service. Both operational and administrative status are 727 maintained together with a timestamp. For example, a service can 728 be created, but not put into effect. 730 Administrative and operational status can be used as a trigger to 731 detect service anomalies. For example, a service that is declared 732 at the service layer as being active but still inactive at the 733 network layer is an indication that network provision actions are 734 needed to align the observed service status with the expected 735 service status. 737 'ie-profiles': Defines reusable import/export policies for the same 738 'vpn-service'. 740 More details are provided in Section 7.4. 742 'underlay-transport': Describes the preference for the transport 743 technology to carry the traffic of the VPN service. This 744 preference is especially useful in networks with multiple domains 745 and Network-to-Network Interface (NNI) types. The underlay 746 transport can be expressed as an abstract transport instance 747 (e.g., an identifier of a VPN+ instance, a virtual network 748 identifier, or a network slice name) or as an ordered list of the 749 actual protocols to be enabled in the network. 751 A rich set of protocol identifiers that can be used to refer to an 752 underlay transport are defined in [I-D.ietf-opsawg-vpn-common]. 754 'external-connectivity': Indicates whether/how external connectivity 755 is provided to the VPN service. For example, a service provider 756 may provide an external connectivity to a VPN customer (e.g., to a 757 public cloud). Such service may involve tweaking both filtering 758 and NAT rules (e.g., bind a Virtual Routing and Forwarding (VRF) 759 interface with a NAT instance as discussed in Section 2.10 of 760 [RFC8512]). These added value features may be bound to all or a 761 subset of network accesses. Some of these added value features 762 may be implemented in a PE or in other nodes than PEs (e.g., a P 763 node or event a dedicated node that hosts the NAT function). 765 Only a pointer to a local profile that defines the external 766 connectivity feature is supported in this document. 768 'vpn-node': Is an abstraction that represents a set of policies 769 applied to a network node and that belong to a single 'vpn- 770 service'. A VPN service is typically built by adding instances of 771 'vpn-node' to the 'vpn-nodes' container. 773 A 'vpn-node' contains 'vpn-network-accesses', which are the 774 interfaces attached to the VPN by which the customer traffic is 775 received. Therefore, the customer sites are connected to the 776 'vpn-network-accesses'. 778 Note that, as this is a network data model, the information about 779 customers sites is not required in the model. Such information is 780 rather relevant in the L3SM. Whether that information is included 781 in the L3NM, e.g., to populate the various 'description' data node 782 is implementation specific. 784 More details are provided in Section 7.5. 786 7.4. Import/Export Profiles 788 The import and export profiles construct contains a list with 789 information related with route targets and distinguishers (RTs and 790 RDs), grouped and identified by 'ie-profile-id'. The identifier is 791 then referenced in one or multiple 'vpn-nodes' (Section 7.5) so that 792 the controller can identify RTs and RDs to be configured for a given 793 VRF. The subtree of 'ie-profiles' is shown in Figure 6. 795 The following modes are supported in: 797 'full-autoasigned': The network controller auto-assigns logical 798 resources (RTs, RDs). This can apply for the deployment of new 799 services. 801 'rd-from-pool': A variant of the previous one is to indicate a pool 802 from where the RD values can be auto-assigned. 804 'directly-assigned': The VPN service provider (service orchestrator) 805 assigns explicitly the RTs and RDs. This case will fit with a 806 brownfield scenario where some existing services need to be 807 updated by the VPN service provider. 809 'no-rd': The (service orchestrator) explicitly wants no RT/RD to be 810 assigned. This case can be used for CE testing within the network 811 or for troubleshooting proposes. 813 +--rw l3vpn-ntw 814 +--rw vpn-profiles 815 | ... 816 +--rw vpn-services 817 +--rw vpn-service* [vpn-id] 818 +--rw vpn-id vpn-common:vpn-id 819 + ... 820 +--rw ie-profiles 821 | +--rw ie-profile* [ie-profile-id] 822 | +--rw ie-profile-id string 823 | +--rw (rd-choice)? 824 | | +--:(directly-assigned) 825 | | | +--rw rd? 826 | | | rt-types:route-distinguisher 827 | | +--:(pool-assigned) 828 | | | +--rw rd-pool-name? string 829 | | | +--ro rd-from-pool? 830 | | | rt-types:route-distinguisher 831 | | +--:(full-autoasigned) 832 | | | +--rw auto? empty 833 | | | +--ro rd-auto? 834 | | | rt-types:route-distinguisher 835 | | +--:(no-rd) 836 | | +--rw no-rd? empty 837 | +--rw vpn-targets 838 | +--rw vpn-target* [id] 839 | | +--rw id int8 840 | | +--rw route-targets* [route-target] 841 | | | +--rw route-target rt-types:route-target 842 | | +--rw route-target-type 843 | | rt-types:route-target-type 844 | +--rw vpn-policies 845 | +--rw import-policy? string 846 | +--rw export-policy? string 847 +--rw vpn-nodes 848 +--rw vpn-node* [ne-id] 849 +--rw ne-id string 850 ... 851 +--rw node-ie-profile? leafref 852 ... 854 Figure 6: Subtree Structure of Import/Export Profiles 856 7.5. VPN Nodes 858 The 'vpn-node' is an abstraction that represents a set of common 859 policies applied on a given network node (typically, a PE) and belong 860 to one L3VPN service. The 'vpn-node' includes a parameter to 861 indicate the network node on which it is applied. In the case that 862 the 'ne-id' points to a specific PE, the 'vpn-node' will likely be 863 mapped into a VRF in the node. However, the model also allows to 864 point to an abstract node. In this case, the network controller will 865 decide how to split the 'vpn-node' into VRFs. 867 +--rw l3vpn-ntw 868 +--rw vpn-profiles 869 | ... 870 +--rw vpn-services 871 +--rw vpn-service* [vpn-id] 872 ... 873 +--rw vpn-nodes 874 +--rw vpn-node* [vpn-node-id] 875 +--rw vpn-node-id union 876 +--rw description? string 877 +--rw ne-id? string 878 +--rw node-role? identityref 879 +--rw local-autonomous-system? inet:as-number 880 | {vpn-common:rtg-bgp}? 881 +--rw address-family? identityref 882 +--rw router-id? inet:ip-address 883 +--rw (rd-choice)? 884 | +--:(directly-assigned) 885 | | +--rw rd? 886 | | rt-types:route-distinguisher 887 | +--:(pool-assigned) 888 | | +--rw rd-pool-name? string 889 | | +--ro rd-from-pool? 890 | | rt-types:route-distinguisher 891 | +--:(full-autoasigned) 892 | | +--rw auto? empty 893 | | +--ro rd-auto? 894 | | rt-types:route-distinguisher 895 | +--:(no-rd) 896 | +--rw no-rd? empty 897 +--rw vpn-targets 898 | +--rw vpn-target* [id] 899 | | +--rw id int8 900 | | +--rw route-targets* [route-target] 901 | | | +--rw route-target 902 | | | rt-types:route-target 903 | | +--rw route-target-type 904 | | rt-types:route-target-type 905 | +--rw vpn-policies 906 | +--rw import-policy? string 907 | +--rw export-policy? string 908 +--rw node-ie-profile? leafref 909 +--rw maximum-routes 910 | +--rw selector* [address-family protocol] 911 | +--rw address-family identityref 912 | +--rw protocol identityref 913 | +--rw maximum-routes? uint32 914 +--rw groups 915 | +--rw group* [group-id] 916 | +--rw group-id string 917 +--rw multicast {vpn-common:multicast}? 918 | ... 919 +--rw status 920 | +--rw admin-status 921 | | +--rw status? identityref 922 | | +--rw last-updated? yang:date-and-time 923 | +--ro oper-status 924 | +--ro status? identityref 925 | +--ro last-updated? yang:date-and-time 926 +--rw vpn-network-accesses 927 ... 929 Figure 7: VPN Node Subtree Structure 931 In reference to the subtree shown in Figure 7, the description of VPN 932 node data nodes is as follows: 934 'vpn-node-id': Is an identifier that uniquely identifies a node that 935 enable a VPN network access. 937 'description': Providers a textual description of the VPN node. 939 'ne-id': Includes a unique identifier of the network element where 940 the VPN node is deployed. 942 'node-role': Indicates the role of the VPN node in the VPN. Roles 943 values are defines defined in [I-D.ietf-opsawg-vpn-common] (e.g., 944 any-to-any-role, spoke-role, hub-role). 946 'local-autonomous-system': Indicates the BGP Autonomous System 947 Number (ASN) that is configured for the VPN node. 949 'address-family': Is used to identify the address family used for 950 the Router ID. It can be set to IPv4 or IPv6. 952 'router-id': Indicates a unique Router ID information. It can be an 953 IPv4 or IPv6 address as a function of the enclosed address-family. 955 'rd': If the logical resources are managed outside the network 956 controller, the model allows to explicitly indicate the logical 957 resources such as RTs and RDs. 959 As defined in [I-D.ietf-opsawg-vpn-common] and recalled in 960 Section 7.4, RDs can be explicitly configured or automatically 961 assigned. RD auto- assignment can also constrained by indicating 962 an RD pool name ('rd- pool-name'). 964 'vpn-targets': Specifies RT import/export rules for the VPN service. 966 'node-ie-profile': Refer to Section 7.4. 968 'maximum-routes': Indicates the maximum prefixes that the VPN node 969 can accept for a given address family and routing protocol. If 970 'protocol' is set to 'any', this means that the maximum value 971 applies to any active routing protocol. 973 'groups': Lists the groups to which a VPN node belongs to 974 [I-D.ietf-opsawg-vpn-common]. The 'group-id' is used to 975 associate, e.g., redundancy or protection constraints with VPN 976 nodes. 978 'multicast': Enables multicast traffic in the VPN. Refer to 979 Section 7.7. 981 'status': Tracks the status of a node involved in a VPN service. 982 Both operational and administrative status are maintained. A 983 mismatch between the administrative status vs. the operational 984 status can be used as a trigger to detect anomalies. 986 'vpn-network-accesses': Represents the point to which sites are 987 connected. 989 Note that, unlike in L3SM, the L3NM does not need to model the 990 customer site, only the points where the traffic from the site are 991 received (i.e., the PE side of PE-CE connections). Hence, the VPN 992 network access contains the connectivity information between the 993 provider's network and the customer premises. The VPN profiles 994 ('vpn-profiles') have a set of routing policies that can be 995 applied during the service creation. 997 See Section 7.6 for more details. 999 7.6. VPN Network Access 1001 The 'vpn-network-access' includes a set of data nodes that describe 1002 the access information for the traffic that belongs to a particular 1003 L3VPN (Figure 8). 1005 ... 1006 +--rw vpn-nodes 1007 +--rw vpn-node* [vpn-node-id] 1008 ... 1009 +--rw vpn-network-accesses 1010 +--rw vpn-network-access* [id] 1011 +--rw id vpn-common:vpn-id 1012 +--rw port-id? vpn-common:vpn-id 1013 +--rw description? string 1014 +--rw vpn-network-access-type? identityref 1015 +--rw status 1016 | +--rw admin-status 1017 | | +--rw status? identityref 1018 | | +--rw last-updated? yang:date-and-time 1019 | +--ro oper-status 1020 | +--ro status? identityref 1021 | +--ro last-updated? yang:date-and-time 1022 +--rw connection 1023 | ... 1024 +--rw ip-connection 1025 | ... 1026 +--rw oam 1027 | ... 1028 +--rw security 1029 | ... 1030 +--rw routing-protocols 1031 | ... 1032 +--rw service 1033 ... 1035 Figure 8: VPN Network Access Subtree Structure 1037 In reference to the subtree depicted in Figure 8, a 'vpn-network- 1038 access' includes the following data nodes: 1040 'id': Is an identifier of the VPN network access. 1042 'port-id': Indicates the physical port on which the VPN network 1043 access is bound. 1045 'description': Includes a textual description of the VPN network 1046 access. 1048 'vpn-network-access-type': Is used to select the type of network 1049 interface to be deployed in the devices. The available options 1050 are: 1052 Point-to-Point: Represents a direct connection between the end- 1053 points. It implies that the controller must keep the 1054 association between a logical or physical interface on the 1055 device with the 'id' of the 'vpn-network-access'. 1057 Multipoint: Represents a broadcast connection between the end- 1058 points. It implies that the controller must keep the 1059 association between a logical or physical interface on the 1060 device with the 'id' of the 'vpn-network-access'. 1062 Pseudowire: Represents a connection coming from an L2VPN service. 1063 It implies that the controller must keep the relationship 1064 between the logical tunnels or bridges on the devices with the 1065 'id' of the' vpn-network-access'. 1067 Loopback: Represents the creation of a logical interface on a 1068 device. An example to illustrate how loopback interfaces can 1069 be created is provided in Figure 35. 1071 'status': Indicates both operational and administrative status of a 1072 VPN network access. 1074 'connection': Represents and groups the set of Layer 2 connectivity 1075 from where the traffic of the L3VPN in a particular VPN Network 1076 access is coming. See Section 7.6.1. 1078 'ip-connection': Contains the IP addressing information of a VPN 1079 network access. See Section 7.6.2. 1081 'routing-protocols': Represents and groups the set of Layer 2 1082 connectivity from where the traffic of the L3VPN in a particular 1083 VPN Network access is coming. See Section 7.6.3. 1085 'security': Specifies the authentication and the encryption to be 1086 applied for a given VPN network access. See Section 7.6.5. 1088 'service': Specifies the service parameters (e.g., QoS, multicast) 1089 to apply for a given VPN network access. See Section 7.6.6. 1091 7.6.1. Connection 1093 The definition of a L3VPN is commonly specified not only at the IP 1094 layer, but also requires to provide parameters at the Ethernet layer, 1095 such as specifying an encapsulation type (e.g., VLAN, QinQ, QinAny, 1096 VxLAN, etc.). The L3NM uses the 'connection' container to specify 1097 such parameters. 1099 A site, as per [RFC4176] represents a VPN customer's location that is 1100 connected to the service provider network via a CE-PE link, which can 1101 access at least one VPN. The connection from the site to the service 1102 provider network is the bearer. Every site is associated with a list 1103 of bearers. A bearer is the layer two connections with the site. In 1104 the L3NM, it is assumed that the bearer has been allocated by the 1105 service provider at the service orchestration stage. The bearer is 1106 associated to a network element and a port. Hence, a bearer is just 1107 a bearer-reference to allow the translation between a service request 1108 (e.g., L3SM) and L3NM. 1110 As shown in Figure 9, the 'connection' container defines protocols 1111 and parameters to enable connectivity at Layer 2. 1113 ... 1114 +--rw connection 1115 | +--rw encapsulation-type? identityref 1116 | +--rw logical-interface 1117 | | +--rw peer-reference? uint32 1118 | +--rw tagged-interface 1119 | | +--rw type? identityref 1120 | | +--rw dot1q-vlan-tagged {vpn-common:dot1q}? 1121 | | | +--rw tag-type? identityref 1122 | | | +--rw cvlan-id? uint16 1123 | | +--rw priority-tagged 1124 | | | +--rw tag-type? identityref 1125 | | +--rw qinq {vpn-common:qinq}? 1126 | | | +--rw tag-type? identityref 1127 | | | +--rw svlan-id uint16 1128 | | | +--rw cvlan-id uint16 1129 | | +--rw qinany {vpn-common:qinany}? 1130 | | | +--rw tag-type? identityref 1131 | | | +--rw svlan-id uint16 1132 | | +--rw vxlan {vpn-common:vxlan}? 1133 | | +--rw vni-id uint32 1134 | | +--rw peer-mode? identityref 1135 | | +--rw peer-list* [peer-ip] 1136 | | +--rw peer-ip inet:ip-address 1137 | +--rw bearer 1138 | +--rw bearer-reference? string 1139 | | {vpn-common:bearer-reference}? 1140 | +--rw pseudowire 1141 | | +--rw vcid? uint32 1142 | | +--rw far-end? union 1143 | +--rw vpls 1144 | +--rw vcid? union 1145 | +--rw far-end? union 1146 ... 1148 Figure 9: Connection Subtree Structure 1150 7.6.2. IP Connections 1152 This container is used to group the IP addressing information of a 1153 VPN network access. The allocated address represents the PE 1154 interface address configuration. As shown in Figure 10, this 1155 container can include IPv4, IPv6, or both information if dual-stack 1156 is enabled. 1158 ... 1159 +--rw vpn-network-accesses 1160 +--rw vpn-network-access* [id] 1161 ... 1162 +--rw ip-connection 1163 | +--rw ipv4 {vpn-common:ipv4}? 1164 | | ... 1165 | +--rw ipv6 {vpn-common:ipv6}? 1166 | ... 1167 ... 1169 Figure 10: IP Connection Subtree Structure 1171 For both IPv4 and IPv6, the IP connection supports three IP address 1172 assignment modes for customer addresses: provider DHCP, DHCP relay, 1173 and static addressing. Only one mode is enabled for a given service. 1174 Note that for the IPv6 cases, SLAAC [RFC7527] can be used. 1176 Figure 11 shows the structure of the dynamic IPv4 address assignment. 1178 ... 1179 +--rw ip-connection 1180 | +--rw ipv4 {vpn-common:ipv4}? 1181 | | +--rw local-address? inet:ipv4-prefix 1182 | | +--rw address-allocation-type? identityref 1183 | | +--rw (allocation-type)? 1184 | | +--:(provider-dhcp) 1185 | | | +--rw dhcp-server-enable? boolean 1186 | | | +--rw (address-assign)? 1187 | | | +--:(number) 1188 | | | | +--rw number-of-dynamic-address? uint16 1189 | | | +--:(explicit) 1190 | | | +--rw customer-addresses 1191 | | | +--rw address-group* [group-id] 1192 | | | +--rw group-id string 1193 | | | +--rw start-address? inet:ipv4-address 1194 | | | +--rw end-address? inet:ipv4-address 1195 | | +--:(dhcp-relay) 1196 | | | +--rw dhcp-relay-enable? boolean 1197 | | | +--rw customer-dhcp-servers 1198 | | | +--rw server-ip-address* inet:ipv4-address 1199 | | +--:(static-addresses) 1200 | | ... 1201 ... 1203 Figure 11: IP Connection Subtree Structure (IPv4) 1205 Figure 12 shows the structure of the dynamic IPv6 address assignment. 1207 ... 1208 +--rw ip-connection 1209 | +--rw ipv4 {vpn-common:ipv4}? 1210 | | ... 1211 | +--rw ipv6 {vpn-common:ipv6}? 1212 | +--rw local-address? inet:ipv6-prefix 1213 | +--rw address-allocation-type? identityref 1214 | +--rw (allocation-type)? 1215 | +--:(provider-dhcp) 1216 | | +--rw dhcp-server-enable? boolean 1217 | | +--rw (address-assign)? 1218 | | +--:(number) 1219 | | | +--rw number-of-dynamic-address? uint16 1220 | | +--:(explicit) 1221 | | +--rw customer-addresses 1222 | | +--rw address-group* [group-id] 1223 | | +--rw group-id string 1224 | | +--rw start-address? inet:ipv6-address 1225 | | +--rw end-address? inet:ipv6-address 1226 | +--:(dhcp-relay) 1227 | | +--rw dhcp-relay-enable? boolean 1228 | | +--rw customer-dhcp-servers 1229 | | +--rw server-ip-address* inet:ipv6-address 1230 | +--:(static-addresses) 1231 | ... 1232 ... 1234 Figure 12: IP Connection Subtree Structure (IPv6) 1236 In the case of the static addressing (Figure 13), the model supports 1237 the assignment of several IP addresses in the same 'vpn-network- 1238 access'. To identify which of the addresses is the primary address 1239 of a connection ,the 'primary-address' reference MUST be set with the 1240 corresponding 'address-id'. 1242 ... 1243 +--rw ip-connection 1244 | +--rw ipv4 {vpn-common:ipv4}? 1245 | | +--rw address-allocation-type? identityref 1246 | | +--rw (allocation-type)? 1247 | | ... 1248 | | +--:(static-addresses) 1249 | | +--rw primary-address? -> ../address/address-id 1250 | | +--rw address* [address-id] 1251 | | +--rw address-id string 1252 | | +--rw customer-address? inet:ipv4-address 1253 | +--rw ipv6 {vpn-common:ipv6}? 1254 | +--rw address-allocation-type? identityref 1255 | +--rw (allocation-type)? 1256 | ... 1257 | +--:(static-addresses) 1258 | +--rw primary-address? -> ../address/prefix-id 1259 | +--rw address* [address-id] 1260 | +--rw prefix-id string 1261 | +--rw customer-prefix? inet:ipv6-prefix 1262 ... 1264 Figure 13: IP Connection Subtree Structure (Static Mode) 1266 7.6.3. CE-PE Routing Protocols 1268 A VPN service provider can configure one or more routing protocols 1269 associated with a particular 'vpn-network-access'. Such routing 1270 protocol is enabled between the PE and the CE. Each instance is 1271 uniquely identified to accommodate scenarios where multiple instances 1272 of the same routing protocol have to be configured on the same link. 1274 The subtree of the 'routing-protocols' is shown in Figure 14. 1276 ... 1277 +--rw vpn-network-accesses 1278 +--rw vpn-network-access* [id] 1279 ... 1280 +--rw routing-protocols 1281 | +--rw routing-protocol* [id] 1282 | +--rw id string 1283 | +--rw type? identityref 1284 | +--rw routing-profiles* [id] 1285 | | +--rw id leafref 1286 | | +--rw type? identityref 1287 | +--rw static 1288 | | ... 1289 | +--rw bgp {vpn-common:rtg-bgp}? 1290 | | ... 1291 | +--rw ospf {vpn-common:rtg-ospf}? 1292 | | ... 1293 | +--rw isis {vpn-common:rtg-isis}? 1294 | | ... 1295 | +--rw rip {vpn-common:rtg-rip}? 1296 | | ... 1297 | +--rw vrrp {vpn-common:rtg-vrrp}? 1298 | ... 1299 +--rw security 1300 ... 1302 Figure 14: Routing Subtree Structure 1304 Multiple routing instances can be defined; each uniquely identified 1305 by an 'id'. The type of a routing instance is indicated in 'type'. 1306 The values of this attributes are those defined in 1307 [I-D.ietf-opsawg-vpn-common] ('routing-protocol-type' identity). 1309 Configuring multiple instances of the same routing protocol does not 1310 automatically imply that, from a device configuration perspective, 1311 there will be parallel instances (e.g., multiple processes) running 1312 on the PE-CE link. It is up to each implementation to decide about 1313 the appropriate configuration as a function of underlying 1314 capabilities and service provider operational guidelines. As an 1315 example, when multiple BGP peers need to be implemented, multiple 1316 instances of BGP must be configured as part of this model. However, 1317 from a device configuration point of view, this could be implemented 1318 as: 1320 o Multiple BGP processes with a single neighbor running in each 1321 process. 1323 o A single BGP process with multiple neighbors running. 1325 o A combination thereof. 1327 Routing configuration does not include low-level policies. Such 1328 policies are handed at the device configuration level. Local 1329 policies of a service provider (e.g., filtering) will be implemented 1330 as part of the device configuration; these are not captured in the 1331 L3NM, but the model allows to associate local profiles with routing 1332 instances ('routing-profiles'). 1334 The L3NM supports the configuration of one or more IPv4/IPv6 static 1335 routes. Since the same structure is used for both IPv4 and IPv6, it 1336 was considered to have one single container to group both static 1337 entries independently of their address family, but that design was 1338 abandoned to ease the mapping with the structure in [RFC8299]. As 1339 depicted in Figure 15, the following data nodes can be defined for a 1340 given IP prefix: 1342 'lan-tag': Indicates a local tag (e.g., "myfavourite-lan") that is 1343 used to enforce local policies. 1345 'next-hop': Indicates the next-hop to be used for the static route. 1346 It can be identified by an IP address, an interface, etc. 1348 'bfd-enable': Indicates whether BFD is enabled or disabled for this 1349 static route entry. 1351 'metric': Indicates the metric associated with the static route 1352 entry. 1354 'preference': Indicates the preference associated with the static 1355 route entry. This preference is used to selecting a preferred 1356 route among routes to the same destination prefix. 1358 'status': Used to convey the status of a static route entry. This 1359 data node is used to control the (de)activation of individual 1360 static route entries. 1362 ... 1363 +--rw routing-protocols 1364 | +--rw routing-protocol* [id] 1365 | ... 1366 | +--rw static 1367 | | +--rw cascaded-lan-prefixes 1368 | | +--rw ipv4-lan-prefixes* 1369 | | | [lan next-hop] 1370 | | | {vpn-common:ipv4}? 1371 | | | +--rw lan inet:ipv4-prefix 1372 | | | +--rw lan-tag? string 1373 | | | +--rw next-hop union 1374 | | | +--rw bfd-enable? boolean 1375 | | | +--rw metric? uint32 1376 | | | +--rw preference? uint32 1377 | | | +--rw status 1378 | | | +--rw admin-status 1379 | | | | +--rw status? identityref 1380 | | | | +--rw last-updated? yang:date-and-time 1381 | | | +--ro oper-status 1382 | | | +--ro status? identityref 1383 | | | +--ro last-updated? yang:date-and-time 1384 | | +--rw ipv6-lan-prefixes* 1385 | | [lan next-hop] 1386 | | {vpn-common:ipv6}? 1387 | | +--rw lan inet:ipv6-prefix 1388 | | +--rw lan-tag? string 1389 | | +--rw next-hop union 1390 | | +--rw bfd-enable? boolean 1391 | | +--rw metric? uint32 1392 | | +--rw preference? uint32 1393 | | +--rw status 1394 | | +--rw admin-status 1395 | | | +--rw status? identityref 1396 | | | +--rw last-updated? yang:date-and-time 1397 | | +--ro oper-status 1398 | | +--ro status? identityref 1399 | | +--ro last-updated? yang:date-and-time 1400 ... 1402 Figure 15: Static Routing Subtree Structure 1404 In addition, the L3NM supports the following CE-PE routing protocols: 1406 BGP: The L3NM allows to configure a BGP neighbor, including a set 1407 for parameters that are pertinent to be tweaked at the network 1408 level for service customization purposes. 1410 This container does not aim to include every BGP parameter; a 1411 comprehensive set of parameters belongs more to the BGP device 1412 model. 1414 The following data nodes are captured in Figure 16. It is up to 1415 the implementation to derive the corresponding BGP device 1416 configuration: 1418 'description': Includes a description of the BGP session. 1420 'local-autonomous-system': Is set to the AS Number (ASN) to 1421 override a customer ASN if such feature is requested by the 1422 customer. 1424 'peer-autonomous-system': Conveys the customer's ASN. 1426 'address-family': Indicates the address-family of the peer. It 1427 can be set to IPv4, IPv6, or dual-stack. 1429 'neighbor': Can indicate two neighbors (each for a given address- 1430 family) or one neighbor (if 'address-family' attribute is set 1431 to dual-stack). A list of IP address(es) of the BGP neighbors 1432 can be then conveyed in this data node. 1434 'multihop': Indicates the number of allowed IP hops between a PE 1435 and its BGP peer. 1437 'as-override': If set, this parameter indicates whether ASN 1438 override is enabled, i.e., replace the ASN of the customer 1439 specified in the AS_PATH BGP attribute with the ASN identified 1440 in the 'local-autonomous-system' attribute. 1442 'default-route': Controls whether default route(s) can be 1443 advertised to the peer. 1445 'site-of-origin': Is meant to uniquely identify the set of routes 1446 learned from a site via a particular CE/PE connection and is 1447 used to prevent routing loops (Section 7 of [RFC4364]). The 1448 Site of Origin attribute is encoded as a Route Origin Extended 1449 Community. 1451 'ipv6-site-of-origin': Carries an IPv6 Address Specific BGP 1452 Extended that is used to indicate the Site of Origin for VRF 1453 information [RFC5701]. It is used to prevent routing loops. 1455 'bgp-max-prefix': Controls the behavior when a prefix maximum is 1456 reached. 1458 'max-prefix': Indicates the maximum number of BGP prefixes 1459 allowed in the BGP session. If such limit is reached, the 1460 action indicated in 'action-violate' will be followed. 1462 'warning-threshold':a warning 1463 notification will be triggered' 1464 A warning notification is triggered when this limit is reached. 1466 'violate-action': Indicates which action to execute when the maximum 1467 number of BGP prefixes is reached. Examples of such actions are: 1468 send a warning message, discard extra paths from the peer, or 1469 restart the session. 1471 'bgp-timers': Two timers can be captured in this container: (1) 1472 'hold-time' which is the time interval that will be used for 1473 the HoldTimer (Section 4.2 of [RFC4271]) when establishing a 1474 BGP session. (2) 'keep-alive' which is the time interval for 1475 the KeepAlive timer between a PE and a BGP peer (Section 4.4 of 1476 [RFC4271]). 1478 'security': The module adheres to the recommendations in 1479 Section 13.2 of [RFC4364] as it allows to enable TCP-AO 1480 [RFC5925] and accommodates the installed base that make use of 1481 MD5. In addition, the module includes a provision for the use 1482 of IPsec. 1484 'status': Indicates the status of the BGP routing instance. 1486 ... 1487 +--rw routing-protocols 1488 | +--rw routing-protocol* [id] 1489 | ... 1490 | +--rw bgp {vpn-common:rtg-bgp}? 1491 | | +--rw description? string 1492 | | +--rw local-autonomous-system? inet:as-number 1493 | | +--rw peer-autonomous-system inet:as-number 1494 | | +--rw address-family? identityref 1495 | | +--rw neighbor* inet:ip-address 1496 | | +--rw multihop? uint8 1497 | | +--rw as-override? boolean 1498 | | +--rw default-route? boolean 1499 | | +--rw site-of-origin? rt-types:route-origin 1500 | | +--rw ipv6-site-of-origin? rt-types:ipv6-route-origin 1501 | | +--rw bgp-max-prefix 1502 | | | +--rw max-prefix? uint32 1503 | | | +--rw warning-threshold? decimal64 1504 | | | +--rw violate-action? enumeration 1505 | | | +--rw restart-interval? uint16 1506 | | +--rw bgp-timers 1507 | | | +--rw keep-alive? uint16 1508 | | | +--rw hold-time? uint16 1509 | | +--rw security 1510 | | | +--rw enable? boolean 1511 | | | +--rw keying-material 1512 | | | +--rw (option)? 1513 | | | +--:(tcp-ao) 1514 | | | | +--rw enable-tcp-ao? boolean 1515 | | | | +--rw ao-keychain? key-chain:key-chain-ref 1516 | | | +--:(md5) 1517 | | | | +--rw md5-keychain? key-chain:key-chain-ref 1518 | | | +--:(explicit) 1519 | | | | +--rw key-id? uint32 1520 | | | | +--rw key? string 1521 | | | | +--rw crypto-algorithm? identityref 1522 | | | +--:(ipsec) 1523 | | | +--rw sa? string 1524 | | +--rw status 1525 | | +--rw admin-status 1526 | | | +--rw status? identityref 1527 | | | +--rw last-updated? yang:date-and-time 1528 | | +--ro oper-status 1529 | | +--ro status? identityref 1530 | | +--ro last-updated? yang:date-and-time 1531 ... 1533 Figure 16: BGP Routing Subtree Structure 1535 OSPF: OSPF can be configured to run as a routing protocol on the 1536 'vpn-network-access' [RFC4577][RFC6565]. The following data nodes 1537 are captured in Figure 17: 1539 'address-family': Indicates whether IPv4, IPv6, or both address 1540 families are to be activated. 1542 When only the IPv4 address-family is requested, it will be up 1543 to the implementation to decide whether OSPFv2 [RFC2328] or 1544 OSPFv3 [RFC5340] is used. 1546 'area-id': Indicates the OSPF Area ID. 1548 'metric': Associates a metric with OSPF routes. 1550 'sham-links': Is used to create OSPF sham links between two VPN 1551 network accesses sharing the same area and having a backdoor 1552 link (Section 4.2.7 of [RFC4577]). 1554 'max-lsa': Sets the maximum number of LSAs that the OSPF instance 1555 will accept. 1557 'security': Controls the authentication schemes to be enabled for 1558 the OSPF instance. The following options are supported: IPsec 1559 for OSPFv3 authentication [RFC4552], authentication trailer for 1560 OSPFv2 [RFC5709] [RFC7474] and OSPFv3 [RFC7166]. 1562 'status': Indicates the status of the OSPF routing instance. 1564 ... 1565 +--rw routing-protocols 1566 | +--rw routing-protocol* [id] 1567 | ... 1568 | +--rw ospf {vpn-common:rtg-ospf}? 1569 | | +--rw address-family? identityref 1570 | | +--rw area-id yang:dotted-quad 1571 | | +--rw metric? uint16 1572 | | +--rw sham-links {vpn-common:rtg-ospf-sham-link}? 1573 | | | +--rw sham-link* [target-site] 1574 | | | +--rw target-site 1575 | | | | vpn-common:vpn-id 1576 | | | +--rw metric? uint16 1577 | | +--rw max-lsa? uint32 1578 | | +--rw security 1579 | | | +--rw enable? boolean 1580 | | | +--rw keying-material 1581 | | | +--rw (option)? 1582 | | | +--:(md5) 1583 | | | | +--rw md5-keychain? 1584 | | | | kc:key-chain-ref 1585 | | | +--:(ipsec) 1586 | | | +--rw sa? string 1587 | | +--rw status 1588 | | +--rw admin-status 1589 | | | +--rw status? identityref 1590 | | | +--rw last-updated? yang:date-and-time 1591 | | +--ro oper-status 1592 | | +--ro status? identityref 1593 | | +--ro last-updated? yang:date-and-time 1594 ... 1596 Figure 17: OPSF Routing Subtree Structure 1598 IS-IS: The model (Figure 18) allows the user to configure IS-IS to 1599 run on the 'vpn-network-access' interface. The following IS-IS 1600 data nodes are supported: 1602 'address-family': Indicates whether IPv4, IPv6, or both address 1603 families are to be activated. 1605 'area-address': Indicates the IS-IS area address. 1607 'level': Indicates the IS-IS level: Level 1, Level2, or both. 1609 'metric': Associates a metric with IS-IS routes. 1611 'mode': Indicates the IS-IS interface mode type. It can be set 1612 to 'active' (that is, send or receive IS-IS protocol control 1613 packets) or 'passive' (that is, suppress the sending of IS-IS 1614 updates through the interface). 1616 'security': Controls the authentication schemes to be enabled for 1617 the IS-IS instance. 1619 'status': Indicates the status of the OSPF routing instance. 1621 ... 1622 +--rw routing-protocols 1623 | +--rw routing-protocol* [id] 1624 | ... 1625 | +--rw isis {vpn-common:rtg-isis}? 1626 | | +--rw address-family? identityref 1627 | | +--rw area-address yang:dotted-quad 1628 | | +--rw level? identityref 1629 | | +--rw metric? uint16 1630 | | +--rw mode? enumeration 1631 | | +--rw security 1632 | | | +--rw enable? boolean 1633 | | | +--rw keying-material 1634 | | | +--rw (option)? 1635 | | | +--:(auth-key-chain) 1636 | | | | +--rw key-chain? key-chain:key-chain-ref 1637 | | | +--:(auth-key-explicit) 1638 | | | +--rw key-id? uint32 1639 | | | +--rw key? string 1640 | | | +--rw crypto-algorithm? identityref 1641 | | +--rw status 1642 | | +--rw admin-status 1643 | | | +--rw status? identityref 1644 | | | +--rw last-updated? yang:date-and-time 1645 | | +--ro oper-status 1646 | | +--ro status? identityref 1647 | | +--ro last-updated? yang:date-and-time 1648 ... 1650 Figure 18: IS-IS Routing Subtree Structure 1652 RIP: The module covers only a list of address-family and status as 1653 shown in Figure 19. The meaning of these data nodes is similar to 1654 the other routing protocols. 1656 ... 1657 +--rw routing-protocols 1658 | +--rw routing-protocol* [id] 1659 | ... 1660 | +--rw rip {vpn-common:rtg-rip}? 1661 | | +--rw address-family* identityref 1662 | | +--rw status 1663 | | +--rw admin-status 1664 | | | +--rw status? identityref 1665 | | | +--rw last-updated? yang:date-and-time 1666 | | +--ro oper-status 1667 | | +--ro status? identityref 1668 | | +--ro last-updated? yang:date-and-time 1669 ... 1671 Figure 19: RIP Subtree Structure 1673 VRRP: The model (Figure 20) allows to enable VRRP on the 'vpn- 1674 network-access' interface. The following data nodes are 1675 supported: 1677 'address-family': Indicates whether IPv4, IPv6, or both address 1678 families are to be activated. Note that VRRP version 3 1679 [RFC5798] supports both IPv4 and IPv6. 1681 'vrrp-group': Is used to identify the VRRP group. 1683 'backup-peer': Carries the IP address of the peer 1685 'priority': Assigns the VRRP election priority for the backup 1686 virtual router. 1688 'ping-reply': Controls whether ping requests can be replied to. 1690 'status': Indicates the status of the VRRP instance. 1692 Note that no security data node is included for VRRP as there 1693 isn't currently any type of VRRP authentication (see Section 9 of 1694 [RFC5798]). 1696 ... 1697 +--rw routing-protocols 1698 | +--rw routing-protocol* [id] 1699 | ... 1700 | +--rw vrrp {vpn-common:rtg-vrrp}? 1701 | +--rw address-family* identityref 1702 | +--rw vrrp-group? uint8 1703 | +--rw backup-peer? inet:ip-address 1704 | +--rw priority? uint8 1705 | +--rw ping-reply? boolean 1706 | +--rw status 1707 | +--rw admin-status 1708 | | +--rw status? identityref 1709 | | +--rw last-updated? yang:date-and-time 1710 | +--ro oper-status 1711 | +--ro status? identityref 1712 | +--ro last-updated? yang:date-and-time 1713 ... 1715 Figure 20: VRRP Subtree Structure 1717 7.6.4. OAM 1719 This container (Figure 21) defines the Operations, Administration, 1720 and Maintenance (OAM) mechanisms used for a VPN network access. In 1721 the current version of the L3NM, only BFD is supported. The current 1722 data nodes can be specified: 1724 holdtime': Is used to indicate the expected BFD holddown time. The 1725 value can be set by the customer or selected from a profile. 1727 'security': Includes the required information to enable the BFD 1728 authentication modes discussed in Section 6.7 of [RFC5880]. In 1729 particular 'meticulous' controls the activation of the meticulous 1730 mode discussed in Sections 6.7.3 and 6.7.4 of [RFC5880]. 1732 'status': Indicates the status of BFD. 1734 ... 1735 +--rw oam 1736 | +--rw bfd {vpn-common:bfd}? 1737 | +--rw (holdtime)? 1738 | | +--:(fixed) 1739 | | | +--rw fixed-value? uint32 1740 | | +--:(profile) 1741 | | | +--rw profile-name? leafref 1742 | +--rw authentication! 1743 | | +--rw key-chain? key-chain:key-chain-ref 1744 | | +--rw meticulous? boolean 1745 | +--rw status 1746 | +--rw admin-status 1747 | | +--rw status? identityref 1748 | | +--rw last-updated? yang:date-and-time 1749 | +--ro oper-status 1750 | +--ro status? identityref 1751 | +--ro last-updated? yang:date-and-time 1752 ... 1754 Figure 21: IP Connection Subtree Structure (OAM) 1756 7.6.5. Security 1758 The 'security' container specifies the authentication and the 1759 encryption to be applied for a given VPN network access traffic. As 1760 depicted in the subtree shown in Figure 22, the L3NM can be used to 1761 directly control the encryption to put in place (e.g., Layer 2 or 1762 Layer 3 encryption) or invoke a local encryption profile. 1764 ... 1765 +--rw vpn-services 1766 +--rw vpn-service* [vpn-id] 1767 ... 1768 +--rw vpn-nodes 1769 +--rw vpn-node* [vpn-node-id] 1770 ... 1771 +--rw vpn-network-accesses 1772 +--rw vpn-network-access* [id] 1773 ... 1774 +--rw security 1775 | +--rw encryption {vpn-common:encryption}? 1776 | | +--rw enabled? boolean 1777 | | +--rw layer? enumeration 1778 | +--rw encryption-profile 1779 | +--rw (profile)? 1780 | +--:(provider-profile) 1781 | | +--rw profile-name? leafref 1782 | +--:(customer-profile) 1783 | +--rw customer-key-chain? 1784 | kc:key-chain-ref 1785 +--rw service 1786 ... 1788 Figure 22: Security Subtree Structure 1790 7.6.6. Services 1792 The 'services' container specifies the service parameters to apply 1793 for a given VPN network access (Figure 23). 1795 ... 1796 +--rw vpn-network-accesses 1797 +--rw vpn-network-access* [id] 1798 ... 1799 +--rw service 1800 +--rw input-bandwidth uint64 1801 +--rw output-bandwidth uint64 1802 +--rw mtu uint16 1803 +--rw qos {vpn-common:qos}? 1804 | ... 1805 +--rw carrierscarrier 1806 | {vpn-common:carrierscarrier}? 1807 | +--rw signalling-type? enumeration 1808 +--rw multicast {vpn-common:multicast}? 1809 ... 1811 Figure 23: Services Subtree Structure 1813 The following data nodes are defined: 1815 'input-bandwidth': Indicates the inbound bandwidth of the connection 1816 (i.e., download bandwidth from the SP to the site). 1818 'output-bandwidth': Indicates the outbound bandwidth of the 1819 connection (i.e., upload bandwidth from the site to the SP). 1821 'mtu': Indicates the MTU at service level. It can be the IP MTU or 1822 MPLS MTU, for example. 1824 'qos': Is used to define a set of QoS policies to apply on a given 1825 connection (Figure 24). 1827 ... 1828 +--rw qos {vpn-common:qos}? 1829 | +--rw qos-classification-policy 1830 | | +--rw rule* [id] 1831 | | +--rw id string 1832 | | +--rw (match-type)? 1833 | | | +--:(match-flow) 1834 | | | | +--rw (l3)? 1835 | | | | | +--:(ipv4) 1836 | | | | | | ... 1837 | | | | | +--:(ipv6) 1838 | | | | | ... 1839 | | | | +--rw (l4)? 1840 | | | | +--:(tcp) 1841 | | | | | ... 1842 | | | | +--:(udp) 1843 | | | | ... 1844 | | | +--:(match-application) 1845 | | | +--rw match-application? 1846 | | | identityref 1847 | | +--rw target-class-id? 1848 | | string 1849 | +--rw qos-profile 1850 | +--rw qos-profile* [profile] 1851 | +--rw profile leafref 1852 | +--rw direction? identityref 1853 ... 1855 Figure 24: Services Subtree Structure 1857 Classification can be based on many criteria such as: 1859 Layer 3: As shown in Figure 26, classification can be based on 1860 any IP header field or a combination thereof. Both IPv4 and 1861 IPv6 are supported. 1863 +--rw qos {vpn-common:qos}? 1864 | +--rw qos-classification-policy 1865 | | +--rw rule* [id] 1866 | | +--rw id string 1867 | | +--rw (match-type)? 1868 | | | +--:(match-flow) 1869 | | | | +--rw (l3)? 1870 | | | | | +--:(ipv4) 1871 | | | | | | +--rw ipv4 1872 | | | | | | +--rw dscp? inet:dscp 1873 | | | | | | +--rw ecn? uint8 1874 | | | | | | +--rw length? uint16 1875 | | | | | | +--rw ttl? uint8 1876 | | | | | | +--rw protocol? uint8 1877 | | | | | | +--rw ihl? uint8 1878 | | | | | | +--rw flags? bits 1879 | | | | | | +--rw offset? uint16 1880 | | | | | | +--rw identification? uint16 1881 | | | | | | +--rw (destination-network)? 1882 | | | | | | | +--:(destination-ipv4-network) 1883 | | | | | | | +--rw destination-ipv4-network? 1884 | | | | | | | inet:ipv4-prefix 1885 | | | | | | +--rw (source-network)? 1886 | | | | | | +--:(source-ipv4-network) 1887 | | | | | | +--rw source-ipv4-network? 1888 | | | | | | inet:ipv4-prefix 1889 | | | | | +--:(ipv6) 1890 | | | | | +--rw ipv6 1891 | | | | | +--rw dscp? inet:dscp 1892 | | | | | +--rw ecn? uint8 1893 | | | | | +--rw length? uint16 1894 | | | | | +--rw ttl? uint8 1895 | | | | | +--rw protocol? uint8 1896 | | | | | +--rw (destination-network)? 1897 | | | | | | +--:(destination-ipv6-network) 1898 | | | | | | +--rw destination-ipv6-network? 1899 | | | | | | inet:ipv6-prefix 1900 | | | | | +--rw (source-network)? 1901 | | | | | | +--:(source-ipv6-network) 1902 | | | | | | +--rw source-ipv6-network? 1903 | | | | | | inet:ipv6-prefix 1904 | | | | | +--rw flow-label? 1905 | | | | | inet:ipv6-flow-label 1906 ... 1908 Figure 25: QoS Subtree Structure (L3) 1910 Layer 4: As shown in Figure 26, TCP or UDP-related match crietria 1911 can be specified in the L3NM. 1913 +--rw qos {vpn-common:qos}? 1914 | +--rw qos-classification-policy 1915 | | +--rw rule* [id] 1916 | | +--rw id string 1917 | | +--rw (match-type)? 1918 | | | +--:(match-flow) 1919 | | | | +--rw (l3)? 1920 | | | | | ... 1921 | | | | +--rw (l4)? 1922 | | | | +--:(tcp) 1923 | | | | | +--rw tcp 1924 | | | | | +--rw sequence-number? uint32 1925 | | | | | +--rw acknowledgement-number? uint32 1926 | | | | | +--rw data-offset? uint8 1927 | | | | | +--rw reserved? uint8 1928 | | | | | +--rw flags? bits 1929 | | | | | +--rw window-size? uint16 1930 | | | | | +--rw urgent-pointer? uint16 1931 | | | | | +--rw options? binary 1932 | | | | | +--rw (source-port)? 1933 | | | | | | +--:(source-port-range-or-operator) 1934 | | | | | | +--rw source-port-range-or-operator 1935 | | | | | | +--rw (port-range-or-operator)? 1936 | | | | | | +--:(range) 1937 | | | | | | | +--rw lower-port 1938 | | | | | | | | inet:port-number 1939 | | | | | | | +--rw upper-port 1940 | | | | | | | inet:port-number 1941 | | | | | | +--:(operator) 1942 | | | | | | +--rw operator? operator 1943 | | | | | | +--rw port 1944 | | | | | | inet:port-number 1945 | | | | | +--rw (destination-port)? 1946 | | | | +--:(destination-port-range-or-operator) 1947 | | | | | +--rw destination-port-range-or-operator 1948 | | | | | +--rw (port-range-or-operator)? 1949 | | | | | +--:(range) 1950 | | | | | | +--rw lower-port 1951 | | | | | | | inet:port-number 1952 | | | | | | +--rw upper-port 1953 | | | | | | inet:port-number 1954 | | | | | +--:(operator) 1955 | | | | | +--rw operator? operator 1956 | | | | | +--rw port 1957 | | | | | inet:port-number 1958 | | | | +--:(udp) 1959 | | | | +--rw udp 1960 | | | | +--rw length? uint16 1961 | | | | +--rw (source-port)? 1962 | | | | | +--:(source-port-range-or-operator) 1963 | | | | | +--rw source-port-range-or-operator 1964 | | | | | +--rw (port-range-or-operator)? 1965 | | | | | +--:(range) 1966 | | | | | | +--rw lower-port 1967 | | | | | | | inet:port-number 1968 | | | | | | +--rw upper-port 1969 | | | | | | inet:port-number 1970 | | | | | +--:(operator) 1971 | | | | | +--rw operator? operator 1972 | | | | | +--rw port 1973 | | | | | inet:port-number 1974 | | | | +--rw (destination-port)? 1975 | | | | +--:(destination-port-range-or-operator) 1976 | | | | +--rw destination-port-range-or-operator 1977 | | | | +--rw (port-range-or-operator)? 1978 | | | | +--:(range) 1979 | | | | | +--rw lower-port 1980 | | | | | | inet:port-number 1981 | | | | | +--rw upper-port 1982 | | | | | inet:port-number 1983 | | | | +--:(operator) 1984 | | | | +--rw operator? operator 1985 | | | | +--rw port 1986 | | | | inet:port-number 1987 ... 1989 Figure 26: QoS Subtree Structure (L4) 1991 Application match: Relies upon application-specific 1992 classification. 1994 'carrierscarrier': Groups a set of parameters that are used when CsC 1995 is enabled such the use of BGP for signalling purposes [RFC8277]. 1997 'multicast': Specifies the multicast mode and other data nodes such 1998 as the address-family. Refer to Section 7.7. 2000 7.7. Multicast 2002 Multicast may be enabled for a particular VPN at the VPN node and VPN 2003 network access levels (see Figure 27). Some data nodes (e.g., max- 2004 groups) can be controlled at the VPN node level or at the VPN network 2005 access. 2007 ... 2008 +--rw vpn-nodes 2009 +--rw vpn-node* [vpn-node-id] 2010 ... 2011 +--rw multicast {vpn-common:multicast}? 2012 | ... 2013 +--rw vpn-network-accesses 2014 +--rw vpn-network-access* [id] 2015 ... 2016 +--rw service 2017 ... 2018 +--rw multicast {vpn-common:multicast}? 2019 ... 2021 Figure 27: Overall Multicast Subtree Structure 2023 Multicast-related data nodes at the VPN node level are shown in 2024 Figure 29. Disabling multicast at the VPN node level will have an 2025 effect to disable it also at the VPN network access level. For IGMP, 2026 MLD, and PIM, Global data nodes that are defined at the VPN node 2027 level are applicable to all VPN network accesses whose corresponding 2028 nodes are not provided at the VPN network access level. 2030 ... 2031 +--rw vpn-nodes 2032 +--rw vpn-node* [vpn-node-id] 2033 ... 2034 +--rw multicast {vpn-common:multicast}? 2035 | +--rw status 2036 | | +--rw admin-status 2037 | | | +--rw status? identityref 2038 | | | +--rw last-updated? yang:date-and-time 2039 | | +--ro oper-status 2040 | | +--ro status? identityref 2041 | | +--ro last-updated? yang:date-and-time 2042 | +--rw tree-flavor* identityref 2043 | +--rw rp 2044 | | +--rw rp-group-mappings 2045 | | | +--rw rp-group-mapping* [id] 2046 | | | +--rw id uint16 2047 | | | +--rw provider-managed 2048 | | | | +--rw enabled? boolean 2049 | | | | +--rw rp-redundancy? boolean 2050 | | | | +--rw optimal-traffic-delivery? boolean 2051 | | | | +--rw anycast 2052 | | | | +--rw local-address? inet:ip-address 2053 | | | | +--rw rp-set-address* inet:ip-address 2054 | | | +--rw rp-address inet:ip-address 2055 | | | +--rw groups 2056 | | | +--rw group* [id] 2057 | | | +--rw id uint16 2058 | | | +--rw (group-format) 2059 | | | +--:(group-prefix) 2060 | | | | +--rw group-address? inet:ip-prefix 2061 | | | +--:(startend) 2062 | | | +--rw group-start? inet:ip-address 2063 | | | +--rw group-end? inet:ip-address 2064 | | +--rw rp-discovery 2065 | | +--rw rp-discovery-type? identityref 2066 | | +--rw bsr-candidates 2067 | | +--rw bsr-candidate-address* inet:ip-address 2068 | +--rw msdp {msdp}? 2069 | | +--rw peer? inet:ip-address 2070 | | +--rw local-address? inet:ip-address 2071 | | +--rw status 2072 | | +--rw admin-status 2073 | | | +--rw status? identityref 2074 | | | +--rw last-updated? yang:date-and-time 2075 | | +--ro oper-status 2076 | | +--ro status? identityref 2077 | | +--ro last-updated? yang:date-and-time 2078 | +--rw igmp {vpn-common:igmp and vpn-common:ipv4}? 2079 | | +--rw static-group* [group-addr] 2080 | | | +--rw group-addr 2081 | | | rt-types:ipv4-multicast-group-address 2082 | | | +--rw source-addr? 2083 | | | rt-types:ipv4-multicast-source-address 2084 | | +--rw max-groups? uint32 2085 | | +--rw max-entries? uint32 2086 | | +--rw version? identityref 2087 | | +--rw status 2088 | | +--rw admin-status 2089 | | | +--rw status? identityref 2090 | | | +--rw last-updated? yang:date-and-time 2091 | | +--ro oper-status 2092 | | +--ro status? identityref 2093 | | +--ro last-updated? yang:date-and-time 2094 | +--rw mld {vpn-common:mld and vpn-common:ipv6}? 2095 | | +--rw static-group* [group-addr] 2096 | | | +--rw group-addr 2097 | | | rt-types:ipv6-multicast-group-address 2098 | | | +--rw source-addr? 2099 | | | rt-types:ipv6-multicast-source-address 2100 | | +--rw max-groups? uint32 2101 | | +--rw max-entries? uint32 2102 | | +--rw version? identityref 2103 | | +--rw status 2104 | | +--rw admin-status 2105 | | | +--rw status? identityref 2106 | | | +--rw last-updated? yang:date-and-time 2107 | | +--ro oper-status 2108 | | +--ro status? identityref 2109 | | +--ro last-updated? yang:date-and-time 2110 | +--rw pim {vpn-common:pim}? 2111 | +--rw hello-interval? uint8 2112 | +--rw dr-priority? uint16 2113 | +--rw status 2114 | +--rw admin-status 2115 | | +--rw status? identityref 2116 | | +--rw last-updated? yang:date-and-time 2117 | +--ro oper-status 2118 | +--ro status? identityref 2119 | +--ro last-updated? yang:date-and-time 2120 ... 2122 Figure 28: Multicast Subtree Structure (VPN Node Level) 2124 Multicast-related data nodes at the VPN network access level are 2125 shown in Figure 29. Except the 'status' node, the value configured 2126 at the VPN network access level overrides the value configured for 2127 the corresponding data node at the VPN node level. 2129 ... 2130 +--rw vpn-network-accesses 2131 +--rw vpn-network-access* [id] 2132 ... 2133 +--rw service 2134 ... 2135 +--rw multicast {vpn-common:multicast}? 2136 +--rw access-type? enumeration 2137 +--rw address-family? identityref 2138 +--rw protocol-type? enumeration 2139 +--rw remote-source? boolean 2140 +--rw igmp {vpn-common:igmp}? 2141 | +--rw static-group* [group-addr] 2142 | | +--rw group-addr 2143 | | rt-types:ipv4-multicast-group-address 2144 | | +--rw source-addr? 2145 | | rt-types:ipv4-multicast-source-address 2146 | +--rw max-groups? uint32 2147 | +--rw max-entries? uint32 2148 | +--rw max-group-sources? uint32 2149 | +--rw version? identityref 2150 | +--rw status 2151 | +--rw admin-status 2152 | | +--rw status? identityref 2153 | | +--rw last-updated? yang:date-and-time 2154 | +--ro oper-status 2155 | +--ro status? identityref 2156 | +--ro last-updated? yang:date-and-time 2157 +--rw mld {vpn-common:mld}? 2158 | +--rw static-group* [group-addr] 2159 | | +--rw group-addr 2160 | | rt-types:ipv6-multicast-group-address 2161 | | +--rw source-addr? 2162 | | rt-types:ipv6-multicast-source-address 2163 | +--rw max-groups? uint32 2164 | +--rw max-entries? uint32 2165 | +--rw max-group-sources? uint32 2166 | +--rw version? identityref 2167 | +--rw status 2168 | +--rw admin-status 2169 | | +--rw status? identityref 2170 | | +--rw last-updated? yang:date-and-time 2171 | +--ro oper-status 2172 | +--ro status? identityref 2173 | +--ro last-updated? yang:date-and-time 2174 +--rw pim {vpn-common:pim}? 2175 +--rw priority? uint8 2176 +--rw hello-interval? uint8 2177 +--rw dr-priority? uint16 2178 +--rw status 2179 +--rw admin-status 2180 | +--rw status? identityref 2181 | +--rw last-updated? yang:date-and-time 2182 +--ro oper-status 2183 +--ro status? identityref 2184 +--ro last-updated? yang:date-and-time 2186 Figure 29: Multicast Subtree Structure (VPN Network Access Level) 2188 The model supports a single type of tree: Any-Source Multicast (ASM), 2189 Source-Specific Multicast (SSM), or bidirectional. 2191 When ASM is used, the model supports the configuration of rendez-vous 2192 points (RPs). RP discovery may be 'static', 'bsr-rp', or 'auto-rp'. 2193 When set to 'static', RP to multicast grouping mapping MUST be 2194 configured as part of the 'rp-group-mappings' container. The RP MAY 2195 be a provider node or a customer node. When the RP is a customer 2196 node, the RP address must be configured using the 'rp-address' leaf 2197 otherwise no RP address is needed. 2199 The model supports RP redundancy through the 'rp-redundancy' leaf. 2200 How the redundancy is achieved is out of scope and is up to the 2201 implementation. 2203 When a particular VPN using ASM requires a more optimal traffic 2204 delivery, 'optimal-traffic-delivery' can be set. When set to 'true', 2205 the implementation must use any mechanism to provide a more optimal 2206 traffic delivery for the customer. For example, anycast is one of 2207 the mechanisms to enhance RPs redundancy, resilience against 2208 failures, and to recover from failures quickly. 2210 For redundancy purposes, Multicast Source Discovery Protocol (MSDP) 2211 [RFC3618] may be enabled and used to share the state about sources 2212 between multiple RPs. The purpose of MSDP in this context is to 2213 enhance the robustness of the multicast service. MSDP may be 2214 configured on non-RP routers, which is useful in a domain that does 2215 not support multicast sources, but does support multicast transit. 2217 8. L3NM YANG Module 2219 This module uses types defined in [RFC6991] and groupings defined in 2220 [RFC8519], [RFC8177], and [RFC8294]. 2222 file "ietf-l3vpn-ntw@2021-02-19.yang" 2223 module ietf-l3vpn-ntw { 2224 yang-version 1.1; 2225 namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw"; 2226 prefix l3nm; 2228 import ietf-vpn-common { 2229 prefix vpn-common; 2230 reference 2231 "RFC UUUU: A Layer 2/3 VPN Common YANG Model"; 2232 } 2233 import ietf-inet-types { 2234 prefix inet; 2235 reference 2236 "Section 4 of RFC 6991"; 2237 } 2238 import ietf-yang-types { 2239 prefix yang; 2240 reference 2241 "Section 3 of RFC 6991"; 2242 } 2243 import ietf-key-chain { 2244 prefix key-chain; 2245 reference 2246 "RFC 8177: YANG Key Chain."; 2248 } 2249 import ietf-routing-types { 2250 prefix rt-types; 2251 reference 2252 "RFC 8294: Common YANG Data Types for the Routing Area"; 2253 } 2255 organization 2256 "IETF OPSA (Operations and Management Area) Working Group "; 2257 contact 2258 "WG Web: 2259 WG List: 2261 Editor: Samier Barguil 2262 2263 Editor: Oscar Gonzalez de Dios 2264 2265 Editor: Mohamed Boucadair 2266 2267 Author: Luis Angel Munoz 2268 2269 Author: Alejandro Aguado 2270 2271 "; 2272 description 2273 "This YANG module defines a generic network-oriented model 2274 for the configuration of Layer 3 Virtual Private Networks. 2276 Copyright (c) 2021 IETF Trust and the persons identified as 2277 authors of the code. All rights reserved. 2279 Redistribution and use in source and binary forms, with or 2280 without modification, is permitted pursuant to, and subject to 2281 the license terms contained in, the Simplified BSD License set 2282 forth in Section 4 of the IETF Trust's Legal Provisions 2283 Relating to IETF Documents 2284 (https://trustee.ietf.org/license-info). 2286 This version of this YANG module is part of RFC XXXX 2287 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 2288 for full legal notices."; 2290 revision 2021-02-19 { 2291 description 2292 "Initial revision."; 2293 reference 2294 "RFC XXXX: A Layer 3 VPN Network YANG Model"; 2295 } 2296 /* Features */ 2298 feature msdp { 2299 description 2300 "This feature indicates that Multicast Source Discovery Protocol 2301 (MSDP) capabilities are supported by the VPN."; 2302 reference 2303 "RFC 3618: Multicast Source Discovery Protocol (MSDP)"; 2304 } 2306 /* Identities */ 2308 identity address-allocation-type { 2309 description 2310 "Base identity for address allocation type in the 2311 Provider Edge (PE)-Customer Edge (CE) link."; 2312 } 2314 identity provider-dhcp { 2315 base address-allocation-type; 2316 description 2317 "The Provider's network provides a DHCP service to the customer."; 2318 } 2320 identity provider-dhcp-relay { 2321 base address-allocation-type; 2322 description 2323 "The Provider's network provides a DHCP relay service to the 2324 customer."; 2325 } 2327 identity provider-dhcp-slaac { 2328 base address-allocation-type; 2329 description 2330 "The Provider's network provides a DHCP service to the customer 2331 as well as IPv6 Stateless Address Autoconfiguration (SLAAC)."; 2332 reference 2333 "RFC 7527: IPv6 Stateless Address Autoconfiguration"; 2334 } 2336 identity static-address { 2337 base address-allocation-type; 2338 description 2339 "The Provider-to-customer addressing is static."; 2340 } 2342 identity slaac { 2343 if-feature "vpn-common:ipv6"; 2344 base address-allocation-type; 2345 description 2346 "Use IPv6 SLAAC."; 2347 reference 2348 "RFC 7527: IPv6 Stateless Address Autoconfiguration"; 2349 } 2351 identity bearer-inf-type { 2352 description 2353 "Identity for the bearer interface type."; 2354 } 2356 identity port-id { 2357 base bearer-inf-type; 2358 description 2359 "Identity for the priority-tagged interface."; 2360 } 2362 identity lag-id { 2363 base bearer-inf-type; 2364 description 2365 "Identity for the lag-tagged interface."; 2366 } 2368 identity local-defined-next-hop { 2369 description 2370 "Defines a base identity type of local defined 2371 next-hops."; 2372 } 2374 identity discard { 2375 base local-defined-next-hop; 2376 description 2377 "Indicates an action to discard traffic for the 2378 corresponding destination. 2379 For example, this can be used to blackhole traffic."; 2380 } 2382 identity local-link { 2383 base local-defined-next-hop; 2384 description 2385 "Treat traffic towards addresses within the specified next-hop 2386 prefix as though they are connected to a local link."; 2387 } 2389 typedef predefined-next-hop { 2390 type identityref { 2391 base local-defined-next-hop; 2393 } 2394 description 2395 "Pre-defined next-hop designation for locally generated routes."; 2396 } 2398 /* Typedefs */ 2400 typedef area-address { 2401 type string { 2402 pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}'; 2403 } 2404 description 2405 "This type defines the area address format."; 2406 } 2408 /* Main Blocks */ 2409 /* Main l3vpn-ntw */ 2411 container l3vpn-ntw { 2412 description 2413 "Main container for L3VPN services management."; 2414 container vpn-profiles { 2415 description 2416 "Contains a set of valid VPN Profiles to reference in the VPN 2417 service."; 2418 uses vpn-common:vpn-profile-cfg; 2419 } 2420 container vpn-services { 2421 description 2422 "Top-level container for the VPN services."; 2423 list vpn-service { 2424 key "vpn-id"; 2425 description 2426 "List of VPN services."; 2427 uses vpn-common:vpn-description; 2428 leaf parent-service-id { 2429 type vpn-common:vpn-id; 2430 description 2431 "Pointer to the parent service, if any. 2432 A parent service can an L3SM, a slice request, a VPN+ 2433 service, etc."; 2434 } 2435 leaf vpn-type { 2436 type identityref { 2437 base vpn-common:service-type; 2438 } 2439 description 2440 "Indicates the service type."; 2442 } 2443 leaf vpn-service-topology { 2444 type identityref { 2445 base vpn-common:vpn-topology; 2446 } 2447 default "vpn-common:any-to-any"; 2448 description 2449 "VPN service topology."; 2450 } 2451 uses vpn-common:service-status; 2452 container ie-profiles { 2453 description 2454 "Container for Import/Export profiles."; 2455 list ie-profile { 2456 key "ie-profile-id"; 2457 description 2458 "List for Imort/Export profile."; 2459 leaf ie-profile-id { 2460 type string; 2461 description 2462 "IE profile id."; 2463 } 2464 uses vpn-common:rt-rd; 2465 } 2466 } 2467 container underlay-transport { 2468 description 2469 "Container for underlay transport."; 2470 uses vpn-common:underlay-transport; 2471 } 2472 container external-connectivity { 2473 if-feature "vpn-common:external-connectivity"; 2474 description 2475 "Container for external connectivity."; 2476 choice profile { 2477 description 2478 "Choice for the external connectivity profile."; 2479 case profile { 2480 leaf profile-name { 2481 type leafref { 2482 path "/l3vpn-ntw/vpn-profiles" 2483 + "/valid-provider-identifiers" 2484 + "/external-connectivity-identifier/id"; 2485 } 2486 description 2487 "Name of the service provider's profile to be applied 2488 at the VPN service level."; 2489 } 2491 } 2492 } 2493 } 2494 container vpn-nodes { 2495 description 2496 "Container for VPN nodes."; 2497 list vpn-node { 2498 key "vpn-node-id"; 2499 description 2500 "List for VPN node."; 2501 leaf vpn-node-id { 2502 type union { 2503 type vpn-common:vpn-id; 2504 type uint32; 2505 } 2506 description 2507 "Type STRING or NUMBER identifier."; 2508 } 2509 leaf description { 2510 type string; 2511 description 2512 "Textual description of the VPN node."; 2513 } 2514 leaf ne-id { 2515 type string; 2516 description 2517 "Unique identifier of the network element where the VPN 2518 node is deployed."; 2519 } 2520 leaf node-role { 2521 type identityref { 2522 base vpn-common:role; 2523 } 2524 default "vpn-common:any-to-any-role"; 2525 description 2526 "Role of the VPN node in the IP VPN."; 2527 } 2528 leaf local-autonomous-system { 2529 if-feature "vpn-common:rtg-bgp"; 2530 type inet:as-number; 2531 description 2532 "Provider's AS number in case the customer requests BGP 2533 routing."; 2534 } 2535 leaf address-family { 2536 type identityref { 2537 base vpn-common:address-family; 2538 } 2539 description 2540 "The address family used for router-id information."; 2541 } 2542 leaf router-id { 2543 type inet:ip-address; 2544 description 2545 "The router-id information can be an IPv4 or IPv6 2546 address."; 2547 } 2548 uses vpn-common:rt-rd; 2549 leaf node-ie-profile { 2550 type leafref { 2551 path "/l3vpn-ntw/vpn-services/vpn-service" 2552 + "/ie-profiles/ie-profile/ie-profile-id"; 2553 } 2554 description 2555 "Node's Import/Export profile."; 2556 } 2557 container maximum-routes { 2558 description 2559 "Defines maximum routes for the VRF."; 2560 list selector { 2561 key "address-family protocol"; 2562 description 2563 "List of address families."; 2564 leaf address-family { 2565 type identityref { 2566 base vpn-common:address-family; 2567 } 2568 description 2569 "Indicates the address family (IPv4 or IPv6)."; 2570 } 2571 leaf protocol { 2572 type identityref { 2573 base vpn-common:routing-protocol-type; 2574 } 2575 description 2576 "Indicates the routing protocol. 'any' value can 2577 be used to identify a limit that will apply for 2578 any active routing protocol."; 2579 } 2580 leaf maximum-routes { 2581 type uint32; 2582 description 2583 "Indicates the maximum prefixes the VRF can accept 2584 for this address family and protocol."; 2585 } 2586 } 2588 } 2589 uses vpn-common:vpn-components-group; 2590 container multicast { 2591 if-feature "vpn-common:multicast"; 2592 description 2593 "Global multicast parameters."; 2594 uses vpn-common:service-status; 2595 leaf-list tree-flavor { 2596 type identityref { 2597 base vpn-common:multicast-tree-type; 2598 } 2599 description 2600 "Type of tree to be used."; 2601 } 2602 container rp { 2603 description 2604 "RP parameters."; 2605 container rp-group-mappings { 2606 description 2607 "RP-to-group mappings parameters."; 2608 list rp-group-mapping { 2609 key "id"; 2610 description 2611 "List of RP-to-group mappings."; 2612 leaf id { 2613 type uint16; 2614 description 2615 "Unique identifier for the mapping."; 2616 } 2617 container provider-managed { 2618 description 2619 "Parameters for a provider-managed RP."; 2620 leaf enabled { 2621 type boolean; 2622 default "false"; 2623 description 2624 "Set to true if the Rendezvous Point (RP) 2625 must be a provider-managed node. Set to 2626 false if it is a customer-managed node."; 2627 } 2628 leaf rp-redundancy { 2629 type boolean; 2630 default "false"; 2631 description 2632 "If true, a redundancy mechanism for the 2633 RP is required."; 2634 } 2635 leaf optimal-traffic-delivery { 2636 type boolean; 2637 default "false"; 2638 description 2639 "If true, the SP must ensure that 2640 traffic uses an optimal path. An SP may 2641 use Anycast RP or RP-tree-to-SPT 2642 switchover architectures."; 2643 } 2644 container anycast { 2645 when "../rp-redundancy = 'true' and 2646 ../optimal-traffic-delivery = 'true'" { 2647 description 2648 "Only applicable if RP redundancy is enabled 2649 and delivery through optimal path is 2650 activated."; 2651 } 2652 description 2653 "PIM Anycast-RP parameters."; 2654 leaf local-address { 2655 type inet:ip-address; 2656 description 2657 "IP local address for PIM RP. Usually, it 2658 corresponds to router ID or primary 2659 address"; 2660 } 2661 leaf-list rp-set-address { 2662 type inet:ip-address; 2663 description 2664 "Address other RP routers that share the 2665 same RP IP address."; 2666 } 2667 } 2668 } 2669 leaf rp-address { 2670 when "../provider-managed/enabled = 'false'" { 2671 description 2672 "Relevant when the RP is not 2673 provider-managed."; 2674 } 2675 type inet:ip-address; 2676 mandatory true; 2677 description 2678 "Defines the address of the RP. 2679 Used if the RP is customer-managed."; 2680 } 2681 container groups { 2682 description 2683 "Multicast groups associated with the RP."; 2685 list group { 2686 key "id"; 2687 description 2688 "List of multicast groups."; 2689 leaf id { 2690 type uint16; 2691 description 2692 "Identifier for the group."; 2693 } 2694 choice group-format { 2695 mandatory true; 2696 description 2697 "Choice for multicast group format."; 2698 case group-prefix { 2699 leaf group-address { 2700 type inet:ip-prefix; 2701 description 2702 "A single multicast group prefix."; 2703 } 2704 } 2705 case startend { 2706 leaf group-start { 2707 type inet:ip-address; 2708 description 2709 "The first multicast group address in 2710 the multicast group address range."; 2711 } 2712 leaf group-end { 2713 type inet:ip-address; 2714 description 2715 "The last multicast group address in 2716 the multicast group address range."; 2717 } 2718 } 2719 } 2720 } 2721 } 2722 } 2723 } 2724 container rp-discovery { 2725 description 2726 "RP discovery parameters."; 2727 leaf rp-discovery-type { 2728 type identityref { 2729 base vpn-common:multicast-rp-discovery-type; 2730 } 2731 default "vpn-common:static-rp"; 2732 description 2733 "Type of RP discovery used."; 2734 } 2735 container bsr-candidates { 2736 when "derived-from-or-self(../rp-discovery-type, " 2737 + "'vpn-common:bsr-rp')" { 2738 description 2739 "Only applicable if discovery type is BSR-RP."; 2740 } 2741 description 2742 "Container for List of Customer BSR candidate's 2743 addresses."; 2744 leaf-list bsr-candidate-address { 2745 type inet:ip-address; 2746 description 2747 "Specifies the address of candidate Bootstrap 2748 Router (BSR)."; 2749 } 2750 } 2751 } 2752 } 2753 container msdp { 2754 if-feature "msdp"; 2755 description 2756 "Includes MSDP-related parameters."; 2757 leaf peer { 2758 type inet:ip-address; 2759 description 2760 "Indicates the IP address of the MSDP peer."; 2761 } 2762 leaf local-address { 2763 type inet:ip-address; 2764 description 2765 "Indicates the IP address of the local end. 2766 This local address must be configured on 2767 the node."; 2768 } 2769 uses vpn-common:service-status; 2770 } 2771 container igmp { 2772 if-feature "vpn-common:igmp and vpn-common:ipv4"; 2773 description 2774 "Includes IGMP-related parameters."; 2775 list static-group { 2776 key "group-addr"; 2777 description 2778 "Multicast static source/group associated to the 2779 IGMP session"; 2780 leaf group-addr { 2781 type rt-types:ipv4-multicast-group-address; 2782 description 2783 "Multicast group IPv4 addresss."; 2784 } 2785 leaf source-addr { 2786 type rt-types:ipv4-multicast-source-address; 2787 description 2788 "Multicast source IPv4 addresss."; 2789 } 2790 } 2791 leaf max-groups { 2792 type uint32; 2793 description 2794 "Indicates the maximum groups."; 2795 } 2796 leaf max-entries { 2797 type uint32; 2798 description 2799 "Indicates the maximum IGMP entries."; 2800 } 2801 leaf version { 2802 type identityref { 2803 base vpn-common:igmp-version; 2804 } 2805 default "vpn-common:igmpv2"; 2806 description 2807 "Version of the IGMP."; 2808 } 2809 uses vpn-common:service-status; 2810 } 2811 container mld { 2812 if-feature "vpn-common:mld and vpn-common:ipv6"; 2813 description 2814 "Includes MLD-related parameters."; 2815 list static-group { 2816 key "group-addr"; 2817 description 2818 "Multicast static source/group associated to the 2819 MLD session"; 2820 leaf group-addr { 2821 type rt-types:ipv6-multicast-group-address; 2822 description 2823 "Multicast group IPv6 addresss."; 2824 } 2825 leaf source-addr { 2826 type rt-types:ipv6-multicast-source-address; 2827 description 2828 "Multicast source IPv6 addresss."; 2830 } 2831 } 2832 leaf max-groups { 2833 type uint32; 2834 description 2835 "Indicates the maximum groups."; 2836 } 2837 leaf max-entries { 2838 type uint32; 2839 description 2840 "Indicates the maximum MLD entries."; 2841 } 2842 leaf version { 2843 type identityref { 2844 base vpn-common:mld-version; 2845 } 2846 default "vpn-common:mldv2"; 2847 description 2848 "Version of the MLD protocol."; 2849 } 2850 uses vpn-common:service-status; 2851 } 2852 container pim { 2853 if-feature "vpn-common:pim"; 2854 description 2855 "Only applies when protocol type is PIM."; 2856 leaf hello-interval { 2857 type uint8; 2858 units "seconds"; 2859 default "30"; 2860 description 2861 "PIM hello-messages interval."; 2862 } 2863 leaf dr-priority { 2864 type uint16; 2865 description 2866 "Value to increase or decrease the 2867 chances of a given DR being elected."; 2868 } 2869 uses vpn-common:service-status; 2870 } 2871 } 2872 uses vpn-common:service-status; 2873 container vpn-network-accesses { 2874 description 2875 "List of network accesses."; 2876 list vpn-network-access { 2877 key "id"; 2878 description 2879 "List of network accesses."; 2880 leaf id { 2881 type vpn-common:vpn-id; 2882 description 2883 "Identifier for the network access."; 2884 } 2885 leaf port-id { 2886 type vpn-common:vpn-id; 2887 description 2888 "Identifier for the interface."; 2889 } 2890 leaf description { 2891 type string; 2892 description 2893 "Textual description of the network access."; 2894 } 2895 leaf vpn-network-access-type { 2896 type identityref { 2897 base vpn-common:site-network-access-type; 2898 } 2899 default "vpn-common:point-to-point"; 2900 description 2901 "Describes the type of connection, e.g., 2902 point-to-point or multipoint."; 2903 } 2904 uses vpn-common:service-status; 2905 container connection { 2906 description 2907 "Encapsulation types."; 2908 leaf encapsulation-type { 2909 type identityref { 2910 base vpn-common:encapsulation-type; 2911 } 2912 default "vpn-common:untagged-int"; 2913 description 2914 "Encapsulation type. By default, the encapsulation 2915 type is set to 'untagged'."; 2916 } 2917 container logical-interface { 2918 description 2919 "Reference of a logical interface 2920 type."; 2921 leaf peer-reference { 2922 type uint32; 2923 description 2924 "Specifies the associated logical peer 2925 interface."; 2927 } 2928 } 2929 container tagged-interface { 2930 description 2931 "Container for tagged interfaces."; 2932 leaf type { 2933 type identityref { 2934 base vpn-common:encapsulation-type; 2935 } 2936 default "vpn-common:priority-tagged"; 2937 description 2938 "Tagged interface type. By default, the type of 2939 the tagged interface is 'priority-tagged'."; 2940 } 2941 container dot1q-vlan-tagged { 2942 when "derived-from-or-self(../type, " 2943 + "'vpn-common:dot1q')" { 2944 description 2945 "Only applies when the type of the 2946 tagged interface is 'dot1q'."; 2947 } 2948 if-feature "vpn-common:dot1q"; 2949 description 2950 "Tagged interface."; 2951 leaf tag-type { 2952 type identityref { 2953 base vpn-common:tag-type; 2954 } 2955 default "vpn-common:c-vlan"; 2956 description 2957 "Tag type. By default, the tag type is 2958 'c-vlan'."; 2959 } 2960 leaf cvlan-id { 2961 type uint16; 2962 description 2963 "VLAN identifier."; 2964 } 2965 } 2966 container priority-tagged { 2967 when "derived-from-or-self(../type, " 2968 + "'vpn-common:priority-tagged')" { 2969 description 2970 "Only applies when the type of the 2971 tagged interface is 'priority-tagged'."; 2972 } 2973 description 2974 "Priority tagged."; 2976 leaf tag-type { 2977 type identityref { 2978 base vpn-common:tag-type; 2979 } 2980 default "vpn-common:c-vlan"; 2981 description 2982 "Tag type. By default, the tag type is 2983 'c-vlan'."; 2984 } 2985 } 2986 container qinq { 2987 when "derived-from-or-self(../type, " 2988 + "'vpn-common:qinq')" { 2989 description 2990 "Only applies when the type of the tagged 2991 interface is 'qinq'."; 2992 } 2993 if-feature "vpn-common:qinq"; 2994 description 2995 "QinQ."; 2996 leaf tag-type { 2997 type identityref { 2998 base vpn-common:tag-type; 2999 } 3000 default "vpn-common:c-s-vlan"; 3001 description 3002 "Tag type. By default, the tag type is 3003 'c-s-vlan'."; 3004 } 3005 leaf svlan-id { 3006 type uint16; 3007 mandatory true; 3008 description 3009 "SVLAN identifier."; 3010 } 3011 leaf cvlan-id { 3012 type uint16; 3013 mandatory true; 3014 description 3015 "CVLAN identifier."; 3016 } 3017 } 3018 container qinany { 3019 when "derived-from-or-self(../type, " 3020 + "'vpn-common:qinany')" { 3021 description 3022 "Only applies when the type of the 3023 tagged interface is 'qinany'."; 3025 } 3026 if-feature "vpn-common:qinany"; 3027 description 3028 "Container for QinAny."; 3029 leaf tag-type { 3030 type identityref { 3031 base vpn-common:tag-type; 3032 } 3033 default "vpn-common:s-vlan"; 3034 description 3035 "Tag type. By default, the tag type is 3036 's-vlan'."; 3037 } 3038 leaf svlan-id { 3039 type uint16; 3040 mandatory true; 3041 description 3042 "Service VLAN ID."; 3043 } 3044 } 3045 container vxlan { 3046 when "derived-from-or-self(../type, " 3047 + "'vpn-common:vxlan')" { 3048 description 3049 "Only applies when the type of the 3050 tagged interface is 'vxlan'."; 3051 } 3052 if-feature "vpn-common:vxlan"; 3053 description 3054 "QinQ."; 3055 leaf vni-id { 3056 type uint32; 3057 mandatory true; 3058 description 3059 "VXLAN Network Identifier (VNI)."; 3060 } 3061 leaf peer-mode { 3062 type identityref { 3063 base vpn-common:vxlan-peer-mode; 3064 } 3065 default "vpn-common:static-mode"; 3066 description 3067 "Specifies the VXLAN access mode. By default, 3068 the peer mode is set to 'static-mode'."; 3069 } 3070 list peer-list { 3071 key "peer-ip"; 3072 description 3073 "List of peer IP addresses."; 3074 leaf peer-ip { 3075 type inet:ip-address; 3076 description 3077 "Peer IP address."; 3078 } 3079 } 3080 } 3081 } 3082 container bearer { 3083 description 3084 "Defines physical properties of a site 3085 attachment."; 3086 leaf bearer-reference { 3087 if-feature "vpn-common:bearer-reference"; 3088 type string; 3089 description 3090 "This is an internal reference for the service 3091 provider."; 3092 } 3093 container pseudowire { 3094 description 3095 "Pseudowire termination parameters"; 3096 leaf vcid { 3097 type uint32; 3098 description 3099 "Indicates a PW or VC identifier."; 3100 } 3101 leaf far-end { 3102 type union { 3103 type uint32; 3104 type inet:ip-address; 3105 } 3106 description 3107 "SDP/Far End/LDP neighbour reference."; 3108 } 3109 } 3110 container vpls { 3111 description 3112 "Pseudowire termination parameters"; 3113 leaf vcid { 3114 type union { 3115 type uint32; 3116 type string; 3117 } 3118 description 3119 "VCID identifier, IRB/RVPPLs interface 3120 supported using string format."; 3122 } 3123 leaf far-end { 3124 type union { 3125 type uint32; 3126 type inet:ip-address; 3127 } 3128 description 3129 "SDP/Far End/LDP Neighbour reference."; 3130 } 3131 } 3132 } 3133 } 3134 container ip-connection { 3135 description 3136 "Defines connection parameters."; 3137 container ipv4 { 3138 if-feature "vpn-common:ipv4"; 3139 description 3140 "IPv4-specific parameters."; 3141 leaf local-address { 3142 type inet:ipv4-prefix; 3143 description 3144 "This address is used at provider side."; 3145 } 3146 leaf address-allocation-type { 3147 type identityref { 3148 base address-allocation-type; 3149 } 3150 must "not(derived-from-or-self(current(), " 3151 + "'slaac') or derived-from-or-self(current()," 3152 + " 'provider-dhcp-slaac'))" { 3153 error-message "SLAAC is only applicable to 3154 IPv6."; 3155 } 3156 description 3157 "Defines how addresses are allocated to the 3158 peer site. 3160 If there is no value for the address 3161 allocation type, then IPv4 is not enabled."; 3162 } 3163 choice allocation-type { 3164 description 3165 "Choice of the IPv4 address allocation."; 3166 case provider-dhcp { 3167 when "derived-from-or-self(./address-" 3168 + "allocation-type, 'provider-dhcp')" { 3169 description 3170 "Only applies when addresses are allocated 3171 by DHCP."; 3172 } 3173 description 3174 "DHCP allocated addresses related 3175 parameters."; 3176 leaf dhcp-server-enable { 3177 type boolean; 3178 default "true"; 3179 description 3180 "Enables a DHCP service on this access. 3181 The following information are passed to 3182 the provider's DHCP server."; 3183 } 3184 choice address-assign { 3185 default "number"; 3186 description 3187 "Choice for how IPv4 addresses are 3188 assigned."; 3189 case number { 3190 leaf number-of-dynamic-address { 3191 type uint16; 3192 default "1"; 3193 description 3194 "Specifies the number of IP addresses 3195 to be assigned to the customer on this 3196 access."; 3197 } 3198 } 3199 case explicit { 3200 container customer-addresses { 3201 description 3202 "Container for customer addresses to be 3203 allocated using DHCP."; 3204 list address-group { 3205 key "group-id"; 3206 description 3207 "Describes IP addresses to be 3208 allocated by DHCP. 3210 When only start-address or only 3211 end-address is present, it 3212 represents a single address. 3214 When both start-address and 3215 end-address are specified, it 3216 implies a range inclusive of 3217 both addresses. If no address 3218 is specified, it implies customer 3219 addresses group is not supported."; 3220 leaf group-id { 3221 type string; 3222 description 3223 "Group-id for the address range from 3224 start-address to end-address."; 3225 } 3226 leaf start-address { 3227 type inet:ipv4-address; 3228 description 3229 "Indicates the first address in 3230 the group."; 3231 } 3232 leaf end-address { 3233 type inet:ipv4-address; 3234 description 3235 "Indicates the last address in the 3236 group."; 3237 } 3238 } 3239 } 3240 } 3241 } 3242 } 3243 case dhcp-relay { 3244 when "derived-from-or-self(./address-allocation" 3245 + "-type, 'provider-dhcp-relay')" { 3246 description 3247 "Only applies when the provider is required 3248 to implement DHCP relay function."; 3249 } 3250 description 3251 "DHCP relay provided by operator."; 3252 leaf dhcp-relay-enable { 3253 type boolean; 3254 default "true"; 3255 description 3256 "Enables the DHCP relay function for this 3257 access."; 3258 } 3259 container customer-dhcp-servers { 3260 description 3261 "Container for list of customer 3262 DHCP servers."; 3263 leaf-list server-ip-address { 3264 type inet:ipv4-address; 3265 description 3266 "IP address of customer DHCP server."; 3267 } 3268 } 3269 } 3270 case static-addresses { 3271 when "derived-from-or-self(./address-allocation" 3272 + "-type, 'static-address')" { 3273 description 3274 "Only applies when address allocation 3275 type is static."; 3276 } 3277 description 3278 "Describes IPv4 addresses used."; 3279 leaf primary-address { 3280 type leafref { 3281 path "../address/address-id"; 3282 } 3283 description 3284 "Primary address of the connection."; 3285 } 3286 list address { 3287 key "address-id"; 3288 description 3289 "Describes IPv4 addresses used."; 3290 leaf address-id { 3291 type string; 3292 description 3293 "Used static IPv4 address."; 3294 } 3295 leaf customer-address { 3296 type inet:ipv4-address; 3297 description 3298 "IPv4 address at the customer side."; 3299 } 3300 } 3301 } 3302 } 3303 } 3304 container ipv6 { 3305 if-feature "vpn-common:ipv6"; 3306 description 3307 "IPv6-specific parameters."; 3308 leaf local-address { 3309 type inet:ipv6-prefix; 3310 description 3311 "Address of the provider side."; 3312 } 3313 leaf address-allocation-type { 3314 type identityref { 3315 base address-allocation-type; 3316 } 3317 description 3318 "Defines how addresses are allocated. 3319 If there is no value for the address 3320 allocation type, then IPv6 is 3321 not enabled."; 3322 } 3323 choice allocation-type { 3324 description 3325 "IPv6 allocation type."; 3326 case provider-dhcp { 3327 when "derived-from-or-self(./address-allo" 3328 + "cation-type, 'provider-dhcp') " 3329 + "or derived-from-or-self(./address-allo" 3330 + "cation-type, 'provider-dhcp-slaac')" { 3331 description 3332 "Only applies when addresses are 3333 allocated by DHCPv6."; 3334 } 3335 description 3336 "DHCPv6 allocated addresses related 3337 parameters."; 3338 leaf dhcp-server-enable { 3339 type boolean; 3340 default "true"; 3341 description 3342 "Enables DHCPv6 service for this access."; 3343 } 3344 choice address-assign { 3345 default "number"; 3346 description 3347 "Choice for the way to assign IPv6 3348 prefixes."; 3349 case number { 3350 leaf number-of-dynamic-address { 3351 type uint16; 3352 default "1"; 3353 description 3354 "Describes the number of IPv6 prefixes 3355 that are allocated to the customer 3356 on this access."; 3357 } 3358 } 3359 case explicit { 3360 container customer-addresses { 3361 description 3362 "Container for customer IPv6 addresses 3363 allocated by DHCPv6."; 3364 list address-group { 3365 key "group-id"; 3366 description 3367 "Describes IPv6 addresses allocated 3368 by DHCPv6. 3370 When only start-address or only 3371 end-address is present, it 3372 represents a single address. 3374 When both start-address and 3375 end-address are specified, it 3376 implies a range inclusive of 3377 both addresses. 3379 If no address is specified, it 3380 implies customer addresses group 3381 is not supported."; 3382 leaf group-id { 3383 type string; 3384 description 3385 "Group-id for the address range 3386 from identified by start-address 3387 and end-address."; 3388 } 3389 leaf start-address { 3390 type inet:ipv6-address; 3391 description 3392 "Indicates the first address."; 3393 } 3394 leaf end-address { 3395 type inet:ipv6-address; 3396 description 3397 "Indicates the last address."; 3398 } 3399 } 3400 } 3401 } 3402 } 3403 } 3404 case dhcp-relay { 3405 when "derived-from-or-self(./address-allo" 3406 + "cation-type, 'provider-dhcp-relay')" { 3407 description 3408 "Only applies when the provider is required 3409 to implement DHCP relay function."; 3411 } 3412 description 3413 "DHCP relay provided by operator."; 3414 leaf dhcp-relay-enable { 3415 type boolean; 3416 default "true"; 3417 description 3418 "Enables the DHCP relay function for this 3419 access."; 3420 } 3421 container customer-dhcp-servers { 3422 description 3423 "Container for list of customer DHCP 3424 servers."; 3425 leaf-list server-ip-address { 3426 type inet:ipv6-address; 3427 description 3428 "This node contains the IP address of 3429 the customer DHCP server. If the DHCP 3430 relay function is implemented by the 3431 provider, this node contains the 3432 configured value."; 3433 } 3434 } 3435 } 3436 case static-addresses { 3437 when "derived-from-or-self(./address-allocation" 3438 + "-type, 'static-address')" { 3439 description 3440 "Only applies when protocol allocation type 3441 is static."; 3442 } 3443 description 3444 "IPv6-specific parameters for static 3445 allocation."; 3446 leaf primary-address { 3447 type leafref { 3448 path "../address/prefix-id"; 3449 } 3450 description 3451 "Principal address of the connection"; 3452 } 3453 list address { 3454 key "prefix-id"; 3455 description 3456 "Describes IPv6 prefixes used."; 3457 leaf prefix-id { 3458 type string; 3459 description 3460 "An identifier of an IPv6 prefix."; 3461 } 3462 leaf customer-prefix { 3463 type inet:ipv6-prefix; 3464 description 3465 "An IPv6 prefix of the customer side."; 3466 } 3467 } 3468 } 3469 } 3470 } 3471 } 3472 container routing-protocols { 3473 description 3474 "Defines routing protocols."; 3475 list routing-protocol { 3476 key "id"; 3477 description 3478 "List of routing protocols used on 3479 the CE/PE link. This list can be augmented."; 3480 leaf id { 3481 type string; 3482 description 3483 "Unique identifier for routing protocol."; 3484 } 3485 leaf type { 3486 type identityref { 3487 base vpn-common:routing-protocol-type; 3488 } 3489 description 3490 "Type of routing protocol."; 3491 } 3492 list routing-profiles { 3493 key "id"; 3494 description 3495 "Routing profiles."; 3496 leaf id { 3497 type leafref { 3498 path "/l3vpn-ntw/vpn-profiles" 3499 + "/valid-provider-identifiers" 3500 + "/routing-profile-identifier/id"; 3501 } 3502 description 3503 "Routing profile to be used."; 3504 } 3505 leaf type { 3506 type identityref { 3507 base vpn-common:ie-type; 3508 } 3509 description 3510 "Import, export or both."; 3511 } 3512 } 3513 container static { 3514 when "derived-from-or-self(../type, " 3515 + "'vpn-common:static')" { 3516 description 3517 "Only applies when protocol is static."; 3518 } 3519 description 3520 "Configuration specific to static routing."; 3521 container cascaded-lan-prefixes { 3522 description 3523 "LAN prefixes from the customer."; 3524 list ipv4-lan-prefixes { 3525 if-feature "vpn-common:ipv4"; 3526 key "lan next-hop"; 3527 description 3528 "List of LAN prefixes for the site."; 3529 leaf lan { 3530 type inet:ipv4-prefix; 3531 description 3532 "LAN prefixes."; 3533 } 3534 leaf lan-tag { 3535 type string; 3536 description 3537 "Internal tag to be used in VPN 3538 policies."; 3539 } 3540 leaf next-hop { 3541 type union { 3542 type inet:ip-address; 3543 type predefined-next-hop; 3544 } 3545 description 3546 "The next-hop that is to be used 3547 for the static route. This may be 3548 specified as an IP address, an interface, 3549 or a pre-defined next-hop type (e.g., 3550 discard or local-link)."; 3551 } 3552 leaf bfd-enable { 3553 if-feature "vpn-common:bfd"; 3554 type boolean; 3555 description 3556 "Enables BFD."; 3557 } 3558 leaf metric { 3559 type uint32; 3560 description 3561 "Indicates the metric associated with 3562 the static route."; 3563 } 3564 leaf preference { 3565 type uint32; 3566 description 3567 "Indicates the preference of the static 3568 routes."; 3569 } 3570 uses vpn-common:service-status; 3571 } 3572 list ipv6-lan-prefixes { 3573 if-feature "vpn-common:ipv6"; 3574 key "lan next-hop"; 3575 description 3576 "List of LAN prefixes for the site."; 3577 leaf lan { 3578 type inet:ipv6-prefix; 3579 description 3580 "LAN prefixes."; 3581 } 3582 leaf lan-tag { 3583 type string; 3584 description 3585 "Internal tag to be used in VPN 3586 policies."; 3587 } 3588 leaf next-hop { 3589 type union { 3590 type inet:ip-address; 3591 type predefined-next-hop; 3592 } 3593 description 3594 "The next-hop that is to be used for the 3595 static route. This may be specified as 3596 an IP address, an interface, or a 3597 pre-defined next-hop type (e.g., 3598 discard or local-link)."; 3599 } 3600 leaf bfd-enable { 3601 if-feature "vpn-common:bfd"; 3602 type boolean; 3603 description 3604 "Enables BFD."; 3605 } 3606 leaf metric { 3607 type uint32; 3608 description 3609 "Indicates the metric associated with 3610 the static route."; 3611 } 3612 leaf preference { 3613 type uint32; 3614 description 3615 "Indicates the preference associated 3616 with the static route."; 3617 } 3618 uses vpn-common:service-status; 3619 } 3620 } 3621 } 3622 container bgp { 3623 when "derived-from-or-self(../type, " 3624 + "'vpn-common:bgp')" { 3625 description 3626 "Only applies when protocol is BGP."; 3627 } 3628 if-feature "vpn-common:rtg-bgp"; 3629 description 3630 "BGP-specific configuration."; 3631 leaf description { 3632 type string; 3633 description 3634 "Includes a description of the BGP session. 3636 Such description is meant to be used for 3637 diagnosis purposes. The semantic of the 3638 description is local to an 3639 implementation."; 3640 } 3641 leaf local-autonomous-system { 3642 type inet:as-number; 3643 description 3644 "Is set to the ASN to override a peers' ASN 3645 if such feature is requested by the 3646 Customer."; 3647 } 3648 leaf peer-autonomous-system { 3649 type inet:as-number; 3650 mandatory true; 3651 description 3652 "Indicates the Customer's AS Number (ASN) in 3653 case the Customer requests BGP routing."; 3654 } 3655 leaf address-family { 3656 type identityref { 3657 base vpn-common:address-family; 3658 } 3659 description 3660 "This node contains the address families to be 3661 activated. Dual-stack means that both IPv4 3662 and IPv6 will be activated."; 3663 } 3664 leaf-list neighbor { 3665 type inet:ip-address; 3666 description 3667 "IP address(es) of the BGP neighbor. IPv4 3668 and IPv6 neighbors may be indicated if 3669 two sessions will be used for IPv4 and 3670 IPv6."; 3671 } 3672 leaf multihop { 3673 type uint8; 3674 description 3675 "Describes the number of IP hops allowed 3676 between a given BGP neighbor and the PE."; 3677 } 3678 leaf as-override { 3679 type boolean; 3680 default "false"; 3681 description 3682 "Defines whether AS override is enabled, 3683 i.e., replace the ASN of the customer 3684 specified in the AS Path attribute with 3685 the local ASN."; 3686 } 3687 leaf default-route { 3688 type boolean; 3689 default "false"; 3690 description 3691 "Defines whether default route(s) can be 3692 advertised to its peer. If set, the 3693 default route(s) is advertised to its 3694 peer."; 3695 } 3696 leaf site-of-origin { 3697 when "../address-family = 'vpn-common:ipv4' or " 3698 + "'vpn-common:dual-stack'" { 3700 description 3701 "Only applies if IPv4 is activated."; 3702 } 3703 type rt-types:route-origin; 3704 description 3705 "The Site of Origin attribute is encoded as 3706 a Route Origin Extended Community. It is 3707 meant to uniquely identify the set of routes 3708 learned from a site via a particular CE/PE 3709 connection and is used to prevent routing 3710 loops."; 3711 reference 3712 "RFC4364, Section 7"; 3713 } 3714 leaf ipv6-site-of-origin { 3715 when "../address-family = 'vpn-common:ipv6' or " 3716 + "'vpn-common:dual-stack'" { 3717 description 3718 "Only applies if IPv6 is activated."; 3719 } 3720 type rt-types:ipv6-route-origin; 3721 description 3722 "IPv6 Route Origins are IPv6 Address Specific 3723 BGP Extended that are meant to the Site of 3724 Origin for VRF information."; 3725 reference 3726 "RFC 5701: IPv6 Address Specific BGP Extended 3727 Community Attribute"; 3728 } 3729 container bgp-max-prefix { 3730 description 3731 "Controls the behavior when a prefix 3732 maximum is reached."; 3733 leaf max-prefix { 3734 type uint32; 3735 default "5000"; 3736 description 3737 "Indicates the maximum number of BGP 3738 prefixes allowed in the BGP session. 3740 It allows to control how many prefixes 3741 can be received from a neighbor. 3743 If the limit is exceeded, the action 3744 indicated in violate-action will be 3745 followed."; 3746 reference 3747 "RFC4271, Section 8.2.2."; 3749 } 3750 leaf warning-threshold { 3751 type decimal64 { 3752 fraction-digits 5; 3753 range "0..100"; 3754 } 3755 units "percent"; 3756 default "75"; 3757 description 3758 "When this value is reached, a warning 3759 notification will be triggered."; 3760 } 3761 leaf violate-action { 3762 type enumeration { 3763 enum warning { 3764 description 3765 "Only a warning message is sent to 3766 the peer when the limit is 3767 exceeded."; 3768 } 3769 enum discard-extra-paths { 3770 description 3771 "Discards extra paths when the 3772 limit is exceeded."; 3773 } 3774 enum restart { 3775 description 3776 "Restarts after a time interval."; 3777 } 3778 } 3779 description 3780 "BGP neighbour max-prefix violate 3781 action"; 3782 } 3783 leaf restart-interval { 3784 type uint16; 3785 units "minutes"; 3786 description 3787 "Time interval (min) after which the 3788 BGP session will be reestablished."; 3789 } 3790 } 3791 container bgp-timers { 3792 description 3793 "Includes two BGP timers that can be 3794 customized when building a VPN service 3795 with BGP used as CE-PE routing 3796 protocol."; 3798 leaf keep-alive { 3799 type uint16 { 3800 range "0..21845"; 3801 } 3802 units "seconds"; 3803 default "30"; 3804 description 3805 "This timer indicates the KEEPALIVE 3806 messages' frequency between a PE 3807 and a BGP peer. 3809 If set to '0', it indicates KEEPALIVE 3810 messages are disabled. 3812 It is suggested that the maximum time 3813 between KEEPALIVEmessages would be 3814 one third of the Hold Time interval."; 3815 reference 3816 "Section 4.4 of RFC 4271"; 3817 } 3818 leaf hold-time { 3819 type uint16 { 3820 range "0 | 3..65535"; 3821 } 3822 units "seconds"; 3823 default "90"; 3824 description 3825 "It indicates the maximum number of 3826 seconds that may elapse between the 3827 receipt of successive KEEPALIVE 3828 and/or UPDATE messages from the peer. 3830 The Hold Time must be either zero or 3831 at least three seconds."; 3832 reference 3833 "Section 4.2 of RFC 4271"; 3834 } 3835 } 3836 container security { 3837 description 3838 "Container for BGP security parameters 3839 between a PE and a CE."; 3840 leaf enable { 3841 type boolean; 3842 default "false"; 3843 description 3844 "Enables or disables authentication."; 3845 } 3846 container keying-material { 3847 when "../enable = 'true'"; 3848 description 3849 "Container for describing how a BGP routing 3850 session is to be secured between a PE and 3851 a CE."; 3852 choice option { 3853 description 3854 "Choice of authentication options."; 3855 case tcp-ao { 3856 description 3857 "Uses TCP-Authentication Option 3858 (TCP-AO)."; 3859 reference 3860 "RFC 5925: The TCP Authentication 3861 Option."; 3862 leaf enable-tcp-ao { 3863 type boolean; 3864 description 3865 "Enables TCP-AO."; 3866 } 3867 leaf ao-keychain { 3868 type key-chain:key-chain-ref; 3869 description 3870 "Reference to the TCP-AO key chain."; 3871 reference 3872 "RFC 8177: YANG Key Chain."; 3873 } 3874 } 3875 case md5 { 3876 description 3877 "Uses MD5 to secure the session."; 3878 reference 3879 "Section 13.2 of RFC 4364"; 3880 leaf md5-keychain { 3881 type key-chain:key-chain-ref; 3882 description 3883 "Reference to the MD5 key chain."; 3884 reference 3885 "RFC 8177: YANG Key Chain."; 3886 } 3887 } 3888 case explicit { 3889 leaf key-id { 3890 type uint32; 3891 description 3892 "Key Identifier"; 3893 } 3894 leaf key { 3895 type string; 3896 description 3897 "OSPF authentication key."; 3898 } 3899 leaf crypto-algorithm { 3900 type identityref { 3901 base key-chain:crypto-algorithm; 3902 } 3903 description 3904 "Indicates the cryptographic algorithm 3905 associated with the key."; 3906 } 3907 } 3908 case ipsec { 3909 description 3910 "Specifies a reference to an IKE 3911 Security Association (SA)."; 3912 leaf sa { 3913 type string; 3914 description 3915 "Indicates the name of the SA."; 3916 } 3917 } 3918 } 3919 } 3920 } 3921 uses vpn-common:service-status; 3922 } 3923 container ospf { 3924 when "derived-from-or-self(../type, " 3925 + "'vpn-common:ospf')" { 3926 description 3927 "Only applies when protocol is OSPF."; 3928 } 3929 if-feature "vpn-common:rtg-ospf"; 3930 description 3931 "OSPF-specific configuration."; 3932 leaf address-family { 3933 type identityref { 3934 base vpn-common:address-family; 3935 } 3936 description 3937 "Indicates whether IPv4, IPv6, or 3938 both are to be activated."; 3939 } 3940 leaf area-id { 3941 type yang:dotted-quad; 3942 mandatory true; 3943 description 3944 "Area ID."; 3945 } 3946 leaf metric { 3947 type uint16; 3948 default "1"; 3949 description 3950 "Metric of the PE-CE link. It is used 3951 in the routing state calculation and 3952 path selection."; 3953 } 3954 container sham-links { 3955 if-feature "vpn-common:rtg-ospf-sham-link"; 3956 description 3957 "List of sham links."; 3958 list sham-link { 3959 key "target-site"; 3960 description 3961 "Creates a sham link with another site."; 3962 leaf target-site { 3963 type vpn-common:vpn-id; 3964 description 3965 "Target site for the sham link connection. 3966 The site is referred to by its ID."; 3967 } 3968 leaf metric { 3969 type uint16; 3970 default "1"; 3971 description 3972 "Metric of the sham link. It is used in 3973 the routing state calculation and path 3974 selection. The default value is set 3975 to 1."; 3976 } 3977 } 3978 } 3979 leaf max-lsa { 3980 type uint32 { 3981 range "1..4294967294"; 3982 } 3983 description 3984 "Maximum number of allowed LSAs OSPF."; 3985 } 3986 container security { 3987 description 3988 "Authentication configuration."; 3989 leaf enable { 3990 type boolean; 3991 default "false"; 3992 description 3993 "Enables or disables authentication."; 3994 } 3995 container keying-material { 3996 when "../enable = 'true'"; 3997 description 3998 "Container for describing how an OSPF 3999 session is to be secured between a CE 4000 and a PE."; 4001 choice option { 4002 description 4003 "Options for OSPF authentication."; 4004 case auth-key-chain { 4005 leaf key-chain { 4006 type key-chain:key-chain-ref; 4007 description 4008 "key-chain name."; 4009 } 4010 } 4011 case auth-key-explicit { 4012 leaf key-id { 4013 type uint32; 4014 description 4015 "Key Identifier"; 4016 } 4017 leaf key { 4018 type string; 4019 description 4020 "OSPF authentication key."; 4021 } 4022 leaf crypto-algorithm { 4023 type identityref { 4024 base key-chain:crypto-algorithm; 4025 } 4026 description 4027 "Indicates the cryptographic algorithm 4028 associated with the key."; 4029 } 4030 } 4031 case ipsec { 4032 leaf sa { 4033 type string; 4034 description 4035 "Indicates the name of the SA."; 4036 } 4037 } 4039 } 4040 } 4041 } 4042 uses vpn-common:service-status; 4043 } 4044 container isis { 4045 when "derived-from-or-self(../type, " 4046 + "'vpn-common:isis')" { 4047 description 4048 "Only applies when protocol is IS-IS."; 4049 } 4050 if-feature "vpn-common:rtg-isis"; 4051 description 4052 "IS-IS specific configuration."; 4053 leaf address-family { 4054 type identityref { 4055 base vpn-common:address-family; 4056 } 4057 description 4058 "Indicates whether IPv4, IPv6, or both 4059 are to be activated."; 4060 } 4061 leaf area-address { 4062 type yang:dotted-quad; 4063 mandatory true; 4064 description 4065 "Area address."; 4066 } 4067 leaf level { 4068 type identityref { 4069 base vpn-common:isis-level; 4070 } 4071 description 4072 "Can be level1, level2, or level1-2."; 4073 } 4074 leaf metric { 4075 type uint16; 4076 default "1"; 4077 description 4078 "Metric of the PE-CE link. It is used 4079 in the routing state calculation and 4080 path selection."; 4081 } 4082 leaf mode { 4083 type enumeration { 4084 enum active { 4085 description 4086 "Interface sends or receives IS-IS 4087 protocol control packets."; 4088 } 4089 enum passive { 4090 description 4091 "Suppresses the sending of IS-IS 4092 updates through the specified 4093 interface."; 4094 } 4095 } 4096 default "active"; 4097 description 4098 "IS-IS interface mode type."; 4099 } 4100 container security { 4101 description 4102 "Authentication configuration."; 4103 leaf enable { 4104 type boolean; 4105 default "false"; 4106 description 4107 "Enables or disables authentication."; 4108 } 4109 container keying-material { 4110 when "../enable = 'true'"; 4111 description 4112 "Container for describing how an IS-IS 4113 session is to be secured between a CE 4114 and a PE."; 4115 choice option { 4116 description 4117 "Options for IS-IS authentication."; 4118 case auth-key-chain { 4119 leaf key-chain { 4120 type key-chain:key-chain-ref; 4121 description 4122 "key-chain name."; 4123 } 4124 } 4125 case auth-key-explicit { 4126 leaf key-id { 4127 type uint32; 4128 description 4129 "Key Identifier"; 4130 } 4131 leaf key { 4132 type string; 4133 description 4134 "IS-IS authentication key."; 4136 } 4137 leaf crypto-algorithm { 4138 type identityref { 4139 base key-chain:crypto-algorithm; 4140 } 4141 description 4142 "Indicates the cryptographic algorithm 4143 associated with the key."; 4144 } 4145 } 4146 } 4147 } 4148 } 4149 uses vpn-common:service-status; 4150 } 4151 container rip { 4152 when "derived-from-or-self(../type, " 4153 + "'vpn-common:rip')" { 4154 description 4155 "Only applies when the protocol is RIP. 4156 For IPv4, the model assumes that RIP 4157 version 2 is used."; 4158 } 4159 if-feature "vpn-common:rtg-rip"; 4160 description 4161 "Configuration specific to RIP routing."; 4162 leaf address-family { 4163 type identityref { 4164 base vpn-common:address-family; 4165 } 4166 description 4167 "Indicates whether IPv4, IPv6, or both 4168 address families are to be activated."; 4169 } 4170 uses vpn-common:service-status; 4171 } 4172 container vrrp { 4173 when "derived-from-or-self(../type, " 4174 + "'vpn-common:vrrp')" { 4175 description 4176 "Only applies when protocol is VRRP."; 4177 } 4178 if-feature "vpn-common:rtg-vrrp"; 4179 description 4180 "Configuration specific to VRRP."; 4181 leaf address-family { 4182 type identityref { 4183 base vpn-common:address-family; 4185 } 4186 description 4187 "Indicates whether IPv4, IPv6, or both 4188 address families are to be enabled."; 4189 } 4190 leaf vrrp-group { 4191 type uint8 { 4192 range "1..255"; 4193 } 4194 description 4195 "Includes the VRRP group identifier."; 4196 } 4197 leaf backup-peer { 4198 type inet:ip-address; 4199 description 4200 "Indicates the IP address of the peer."; 4201 } 4202 leaf priority { 4203 type uint8 { 4204 range "1..254"; 4205 } 4206 default "100"; 4207 description 4208 "Sets the local priority of the VRRP 4209 speaker."; 4210 } 4211 leaf ping-reply { 4212 type boolean; 4213 description 4214 "Controls whether the VRRP speaker should 4215 answer to ping requests."; 4216 } 4217 uses vpn-common:service-status; 4218 } 4219 } 4220 } 4221 container oam { 4222 description 4223 "Defines the Operations, Administration, 4224 and Maintenance (OAM) mechanisms used. 4226 BFD is set as a fault detection mechanism, 4227 but other mechanisms can be defined in the 4228 future."; 4229 container bfd { 4230 if-feature "vpn-common:bfd"; 4231 description 4232 "Container for BFD."; 4234 choice holdtime { 4235 default "fixed"; 4236 description 4237 "Choice for holdtime flavor."; 4238 case fixed { 4239 leaf fixed-value { 4240 type uint32; 4241 units "msec"; 4242 description 4243 "Expected BFD holdtime. 4245 The customer may impose some fixed 4246 values for the holdtime period if the 4247 provider allows the customer use this 4248 function. 4250 If the provider doesn't allow the 4251 customer to use this function, 4252 the fixed-value will not be set."; 4253 } 4254 } 4255 case profile { 4256 description 4257 "Well-known SP profile."; 4258 leaf profile-name { 4259 type leafref { 4260 path "/l3vpn-ntw/vpn-profiles" 4261 + "/valid-provider-identifiers" 4262 + "/bfd-profile-identifier/id"; 4263 } 4264 description 4265 "Well-known service provider profile name. 4267 The provider can propose some profiles 4268 to the customer, depending on the 4269 service level the customer wants to 4270 achieve."; 4271 } 4272 } 4273 } 4274 container authentication { 4275 presence "Enables BFD authentication"; 4276 description 4277 "Parameters for BFD authentication."; 4278 leaf key-chain { 4279 type key-chain:key-chain-ref; 4280 description 4281 "Name of the key-chain."; 4283 } 4284 leaf meticulous { 4285 type boolean; 4286 description 4287 "Enables meticulous mode."; 4288 reference 4289 "Section 6.7 of RFC 5880"; 4290 } 4291 } 4292 uses vpn-common:service-status; 4293 } 4294 } 4295 container security { 4296 description 4297 "Site-specific security parameters."; 4298 container encryption { 4299 if-feature "vpn-common:encryption"; 4300 description 4301 "Container for CE-PE security encryption."; 4302 leaf enabled { 4303 type boolean; 4304 default "false"; 4305 description 4306 "If true, traffic encryption on the 4307 connection is required. It is 4308 disabled, otherwise."; 4309 } 4310 leaf layer { 4311 when "../enabled = 'true'" { 4312 description 4313 "Indicates the layer on which encryption 4314 is enabled."; 4315 } 4316 type enumeration { 4317 enum layer2 { 4318 description 4319 "Encryption occurs at Layer 2."; 4320 } 4321 enum layer3 { 4322 description 4323 "Encryption occurs at Layer 3. 4324 For example, IPsec may be used when 4325 a customer requests Layer 3 4326 encryption."; 4327 } 4328 } 4329 description 4330 "Indicates the layer on which encryption 4331 is applied."; 4332 } 4333 } 4334 container encryption-profile { 4335 when "../encryption/enabled = 'true'" { 4336 description 4337 "Indicates the layer on which encryption 4338 is enabled."; 4339 } 4340 description 4341 "Container for encryption profile."; 4342 choice profile { 4343 description 4344 "Choice for the encryption profile."; 4345 case provider-profile { 4346 leaf profile-name { 4347 type leafref { 4348 path "/l3vpn-ntw/vpn-profiles" 4349 + "/valid-provider-identifiers" 4350 + "/encryption-profile-identifier/id"; 4351 } 4352 description 4353 "Name of the service provider's profile 4354 to be applied."; 4355 } 4356 } 4357 case customer-profile { 4358 leaf customer-key-chain { 4359 type key-chain:key-chain-ref; 4360 description 4361 "Customer-supplied key chain."; 4362 } 4363 } 4364 } 4365 } 4366 } 4367 container service { 4368 description 4369 "Service parameters on the attachment."; 4370 leaf input-bandwidth { 4371 type uint64; 4372 units "bps"; 4373 mandatory true; 4374 description 4375 "From the customer site's perspective, the 4376 service input bandwidth of the connection 4377 or download bandwidth from the SP to 4378 the site."; 4380 } 4381 leaf output-bandwidth { 4382 type uint64; 4383 units "bps"; 4384 mandatory true; 4385 description 4386 "From the customer site's perspective, 4387 the service output bandwidth of the 4388 connection or upload bandwidth from 4389 the site to the SP."; 4390 } 4391 leaf mtu { 4392 type uint16; 4393 units "bytes"; 4394 mandatory true; 4395 description 4396 "MTU at service level. If the service is IP, 4397 it refers to the IP MTU. If CsC is enabled, 4398 the requested MTU will refer 4399 to the MPLS MTU and not to the IP MTU."; 4400 } 4401 container qos { 4402 if-feature "vpn-common:qos"; 4403 description 4404 "QoS configuration."; 4405 container qos-classification-policy { 4406 description 4407 "Configuration of the traffic classification 4408 policy."; 4409 uses vpn-common:qos-classification-policy; 4410 } 4411 container qos-profile { 4412 description 4413 "QoS profile configuration."; 4414 list qos-profile { 4415 key "profile"; 4416 description 4417 "QoS profile. 4418 Can be standard profile or customized 4419 profile."; 4420 leaf profile { 4421 type leafref { 4422 path "/l3vpn-ntw/vpn-profiles" 4423 + "/valid-provider-identifiers" 4424 + "/qos-profile-identifier/id"; 4425 } 4426 description 4427 "QoS profile to be used."; 4429 } 4430 leaf direction { 4431 type identityref { 4432 base vpn-common:qos-profile-direction; 4433 } 4434 default "vpn-common:both"; 4435 description 4436 "The direction to which the QoS profile 4437 is applied."; 4438 } 4439 } 4440 } 4441 } 4442 container carrierscarrier { 4443 if-feature "vpn-common:carrierscarrier"; 4444 description 4445 "This container is used when the customer 4446 provides MPLS-based services. This is 4447 only used in the case of CsC (i.e., a 4448 customer builds an MPLSservice using an 4449 IP VPN to carry its traffic)."; 4450 leaf signalling-type { 4451 type enumeration { 4452 enum ldp { 4453 description 4454 "Use LDP as the signalling protocol 4455 between the PE and the CE. In this 4456 case, an IGP routing protocol must 4457 also be activated."; 4458 } 4459 enum bgp { 4460 description 4461 "Use BGP as the signalling protocol 4462 between the PE and the CE. 4463 In this case, BGP must also be configured 4464 as the routing protocol."; 4465 reference 4466 "RFC 8277: Using BGP to Bind MPLS Labels 4467 to Address Prefixes"; 4468 } 4469 } 4470 default "bgp"; 4471 description 4472 "MPLS signalling type."; 4473 } 4474 } 4475 container multicast { 4476 if-feature "vpn-common:multicast"; 4477 description 4478 "Multicast parameters for the network 4479 access."; 4480 leaf access-type { 4481 type enumeration { 4482 enum receiver-only { 4483 description 4484 "The peer site only has receivers."; 4485 } 4486 enum source-only { 4487 description 4488 "The peer site only has sources."; 4489 } 4490 enum source-receiver { 4491 description 4492 "The peer site has both sources and 4493 receivers."; 4494 } 4495 } 4496 default "source-receiver"; 4497 description 4498 "Type of multicast site."; 4499 } 4500 leaf address-family { 4501 type identityref { 4502 base vpn-common:address-family; 4503 } 4504 description 4505 "Indicates the address family."; 4506 } 4507 leaf protocol-type { 4508 type enumeration { 4509 enum host { 4510 description 4511 "Hosts are directly connected to the 4512 provider network. 4514 Host protocols such as IGMP or MLD are 4515 required."; 4516 } 4517 enum router { 4518 description 4519 "Hosts are behind a customer router. 4520 PIM will be implemented."; 4521 } 4522 enum both { 4523 description 4524 "Some hosts are behind a customer router, 4525 and some others are directly connected 4526 to the provider network. Both host and 4527 routing protocols must be used. 4529 Typically, IGMP and PIM will be 4530 implemented."; 4531 } 4532 } 4533 default "both"; 4534 description 4535 "Multicast protocol type to be used with 4536 the customer site."; 4537 } 4538 leaf remote-source { 4539 type boolean; 4540 default "false"; 4541 description 4542 "When true, there is no PIM adjacency on 4543 the interface."; 4544 } 4545 container igmp { 4546 when "../protocol-type = 'host' and " 4547 + "../address-family = 'vpn-common:ipv4' or " 4548 + "'vpn-common:dual-stack'"; 4549 if-feature "vpn-common:igmp"; 4550 description 4551 "Includes IGMP-related parameters."; 4552 list static-group { 4553 key "group-addr"; 4554 description 4555 "Multicast static source/group associated to 4556 to IGMP session"; 4557 leaf group-addr { 4558 type rt-types:ipv4-multicast-group-address; 4559 description 4560 "Multicast group IPv4 addresss."; 4561 } 4562 leaf source-addr { 4563 type rt-types:ipv4-multicast-source-address; 4564 description 4565 "Multicast source IPv4 addresss."; 4566 } 4567 } 4568 leaf max-groups { 4569 type uint32; 4570 description 4571 "Indicates the maximum groups."; 4572 } 4573 leaf max-entries { 4574 type uint32; 4575 description 4576 "Indicates the maximum IGMP entries."; 4577 } 4578 leaf max-group-sources { 4579 type uint32; 4580 description 4581 "The maximum number of group sources."; 4582 } 4583 leaf version { 4584 type identityref { 4585 base vpn-common:igmp-version; 4586 } 4587 default "vpn-common:igmpv2"; 4588 description 4589 "Version of the IGMP."; 4590 } 4591 uses vpn-common:service-status; 4592 } 4593 container mld { 4594 when "../protocol-type = 'host' and " 4595 + "../address-family = 'vpn-common:ipv6' or " 4596 + "'vpn-common:dual-stack'"; 4597 if-feature "vpn-common:mld"; 4598 description 4599 "Includes MLD-related parameters."; 4600 list static-group { 4601 key "group-addr"; 4602 description 4603 "Multicast static source/group associated to 4604 the MLD session"; 4605 leaf group-addr { 4606 type rt-types:ipv6-multicast-group-address; 4607 description 4608 "Multicast group IPv6 addresss."; 4609 } 4610 leaf source-addr { 4611 type rt-types:ipv6-multicast-source-address; 4612 description 4613 "Multicast source IPv6 addresss."; 4614 } 4615 } 4616 leaf max-groups { 4617 type uint32; 4618 description 4619 "Indicates the maximum groups."; 4620 } 4621 leaf max-entries { 4622 type uint32; 4623 description 4624 "Indicates the maximum MLD entries."; 4625 } 4626 leaf max-group-sources { 4627 type uint32; 4628 description 4629 "The maximum number of group sources."; 4630 } 4631 leaf version { 4632 type identityref { 4633 base vpn-common:mld-version; 4634 } 4635 default "vpn-common:mldv2"; 4636 description 4637 "Version of the MLD protocol."; 4638 } 4639 uses vpn-common:service-status; 4640 } 4641 container pim { 4642 when "../protocol-type = 'router'"; 4643 if-feature "vpn-common:pim"; 4644 description 4645 "Only applies when protocol type is PIM."; 4646 leaf priority { 4647 type uint8; 4648 description 4649 "PIM priority definition."; 4650 } 4651 leaf hello-interval { 4652 type uint8; 4653 units "seconds"; 4654 default "30"; 4655 description 4656 "PIM hello-messages interval."; 4657 } 4658 leaf dr-priority { 4659 type uint16; 4660 description 4661 "Value to increase or decrease the 4662 chances of a given DR being elected."; 4663 } 4664 uses vpn-common:service-status; 4665 } 4666 } 4667 } 4668 } 4670 } 4671 } 4672 } 4673 } 4674 } 4675 } 4676 } 4677 4679 9. IANA Considerations 4681 This document requests IANA to register the following URI in the "ns" 4682 subregistry within the "IETF XML Registry" [RFC3688]: 4684 URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw 4685 Registrant Contact: The IESG. 4686 XML: N/A; the requested URI is an XML namespace. 4688 This document requests IANA to register the following YANG module in 4689 the "YANG Module Names" subregistry [RFC6020] within the "YANG 4690 Parameters" registry. 4692 name: ietf-l3vpn-ntw 4693 namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw 4694 maintained by IANA: N 4695 prefix: l3nm 4696 reference: RFC XXXX 4698 10. Security Considerations 4700 The YANG module specified in this document defines schema for data 4701 that is designed to be accessed via network management protocols such 4702 as NETCONF [RFC6241] or RESTCONF [RFC8040] . The lowest NETCONF layer 4703 is the secure transport layer, and the mandatory-to-implement secure 4704 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 4705 is HTTPS, and the mandatory-to-implement secure transport is TLS 4706 [RFC8466]. 4708 The Network Configuration Access Control Model (NACM) [RFC8341] 4709 provides the means to restrict access for particular NETCONF or 4710 RESTCONF users to a preconfigured subset of all available NETCONF or 4711 RESTCONF protocol operations and content. 4713 The "ietf-l3vpn-ntw" module is used to manage Layer 3 VPNs in a 4714 service provider backbone network. Hence, the module can be used to 4715 request, modify, or retrieve L3VPN services. For example, the 4716 creation of a 'vpn-service' leaf instance triggers the creation of an 4717 L3VPN Service in a service provider network. 4719 Due to the foreseen use of the "ietf-l3vpn-ntw" module, there are a 4720 number of data nodes defined in the module that are 4721 writable/creatable/deletable (i.e., config true, which is the 4722 default). These data nodes MAY be considered sensitive or vulnerable 4723 in some network environments. Write operations (e.g., edit-config) 4724 and delete operations to these data nodes without proper protection 4725 or authentication can have a negative effect on network operations. 4726 These are the subtrees and data nodes and their sensitivity/ 4727 vulnerability in the "ietf-l3vpn-ntw" module: 4729 o 'vpn-service': An attacker who is able to access network nodes can 4730 undertake various attacks, such as deleting a running L3VPN 4731 Service, interrupting all the traffic of a client. In addition, 4732 an attacker may modify the attributes of a running service (e.g., 4733 QoS, bandwidth, routing protocols), leading to malfunctioning of 4734 the service and therefore to SLA violations. In addition, an 4735 attacker could attempt to create a L3VPN Service or adding a new 4736 network access. Such activity can be detected by adequately 4737 monitoring and tracking network configuration changes. 4739 Some of the readable data nodes in the "ietf-l3vpn-ntw" module may be 4740 considered sensitive or vulnerable in some network environments. It 4741 is thus important to control read access (e.g., via get, get-config, 4742 or notification) to these data nodes. These are the subtrees and 4743 data nodes and their sensitivity/vulnerability: 4745 o 'customer-name' and 'ip-connection': An attacker can retrieve 4746 privacy-related information which can be used to track a customer. 4747 Disclosing such information may be considered as a violation of 4748 the customer-provider trust relationship. 4750 The following summarizes the foreseen risks of using the "ietf-l3vpn- 4751 ntw" module can be classified into: 4753 o Malicious clients attempting to delete or modify VPN services. 4755 o Unauthorized clients attempting to create/modify/delete a VPN 4756 service. 4758 o Unauthorized clients attempting to read VPN service related 4759 information. 4761 11. Acknowledgements 4763 During the discussions of this work, helpful comments, suggestions, 4764 and reviews were received from (listed alphabetically): Raul Arco, 4765 Miguel Cros Cecilia, Joe Clarke, Adrian Farrel, Roque Gagliano, 4766 Christian Jacquenet, Kireeti Kompella, and Julian Lucek. Many thanks 4767 to them. Thanks to Philip Eardly for the review of an early version 4768 of the document. 4770 Daniel King, Daniel Voyer, Luay Jalil, and Stephane Litkowski 4771 contributed to early version of the individual submission. 4773 This work was supported in part by the European Commission funded 4774 H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727). 4776 12. Contributors 4778 Victor Lopez 4779 Telefonica 4780 Email: victor.lopezalvarez@telefonica.com 4782 Qin Wu 4783 Huawei 4784 Email: bill.wu@huawei.com> 4786 Manuel Julian 4787 Vodafone 4788 Email: manuel-julian.lopez@vodafone.com> 4790 Lucia Oliva Ballega 4791 Telefonica 4792 Email: lucia.olivaballega.ext@telefonica.com> 4794 Erez Segev 4795 ECI Telecom 4796 Email: erez.segev@ecitele.com> 4798 13. References 4800 13.1. Normative References 4802 [I-D.ietf-opsawg-vpn-common] 4803 barguil, s., Dios, O., Boucadair, M., and Q. WU, "A Layer 4804 2/3 VPN Common YANG Model", draft-ietf-opsawg-vpn- 4805 common-03 (work in progress), January 2021. 4807 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4808 Requirement Levels", BCP 14, RFC 2119, 4809 DOI 10.17487/RFC2119, March 1997, 4810 . 4812 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 4813 DOI 10.17487/RFC2328, April 1998, 4814 . 4816 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 4817 DOI 10.17487/RFC3688, January 2004, 4818 . 4820 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 4821 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 4822 DOI 10.17487/RFC4271, January 2006, 4823 . 4825 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 4826 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 4827 2006, . 4829 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 4830 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 4831 . 4833 [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the 4834 Provider/Customer Edge Protocol for BGP/MPLS IP Virtual 4835 Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, 4836 June 2006, . 4838 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 4839 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 4840 . 4842 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community 4843 Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, 4844 . 4846 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 4847 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 4848 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 4849 2009, . 4851 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 4852 Version 3 for IPv4 and IPv6", RFC 5798, 4853 DOI 10.17487/RFC5798, March 2010, 4854 . 4856 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 4857 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 4858 . 4860 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 4861 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 4862 June 2010, . 4864 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 4865 the Network Configuration Protocol (NETCONF)", RFC 6020, 4866 DOI 10.17487/RFC6020, October 2010, 4867 . 4869 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 4870 and A. Bierman, Ed., "Network Configuration Protocol 4871 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 4872 . 4874 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 4875 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 4876 . 4878 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 4879 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 4880 2012, . 4882 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 4883 Encodings and Procedures for Multicast in MPLS/BGP IP 4884 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 4885 . 4887 [RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and 4888 M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge 4889 (PE-CE) Routing Protocol", RFC 6565, DOI 10.17487/RFC6565, 4890 June 2012, . 4892 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 4893 RFC 6991, DOI 10.17487/RFC6991, July 2013, 4894 . 4896 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 4897 Authentication Trailer for OSPFv3", RFC 7166, 4898 DOI 10.17487/RFC7166, March 2014, 4899 . 4901 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 4902 "Security Extension for OSPFv2 When Using Manual Key 4903 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 4904 . 4906 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 4907 RFC 7950, DOI 10.17487/RFC7950, August 2016, 4908 . 4910 [RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress 4911 Replication Tunnels in Multicast VPN", RFC 7988, 4912 DOI 10.17487/RFC7988, October 2016, 4913 . 4915 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 4916 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 4917 . 4919 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4920 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4921 May 2017, . 4923 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 4924 Zhang, "YANG Data Model for Key Chains", RFC 8177, 4925 DOI 10.17487/RFC8177, June 2017, 4926 . 4928 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 4929 "Common YANG Data Types for the Routing Area", RFC 8294, 4930 DOI 10.17487/RFC8294, December 2017, 4931 . 4933 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 4934 Access Control Model", STD 91, RFC 8341, 4935 DOI 10.17487/RFC8341, March 2018, 4936 . 4938 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 4939 Data Model for Layer 2 Virtual Private Network (L2VPN) 4940 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 4941 2018, . 4943 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 4944 "YANG Data Model for Network Access Control Lists (ACLs)", 4945 RFC 8519, DOI 10.17487/RFC8519, March 2019, 4946 . 4948 13.2. Informative References 4950 [I-D.evenwu-opsawg-yang-composed-vpn] 4951 Even, R., Bo, W., Wu, Q., and Y. Cheng, "YANG Data Model 4952 for Composed VPN Service Delivery", draft-evenwu-opsawg- 4953 yang-composed-vpn-03 (work in progress), March 2019. 4955 [I-D.ietf-idr-bgp-model] 4956 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 4957 YANG Model for Service Provider Networks", draft-ietf-idr- 4958 bgp-model-10 (work in progress), November 2020. 4960 [I-D.ietf-pim-yang] 4961 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 4962 Y., and f. hu, "A YANG Data Model for Protocol Independent 4963 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 4964 progress), May 2018. 4966 [I-D.ietf-rtgwg-qos-model] 4967 Choudhary, A., Jethanandani, M., Strahle, N., Aries, E., 4968 and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos- 4969 model-02 (work in progress), July 2020. 4971 [I-D.ietf-teas-enhanced-vpn] 4972 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 4973 Framework for Enhanced Virtual Private Networks (VPN+) 4974 Service", draft-ietf-teas-enhanced-vpn-06 (work in 4975 progress), July 2020. 4977 [I-D.ietf-teas-ietf-network-slice-definition] 4978 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 4979 Tantsura, "Definition of IETF Network Slices", draft-ietf- 4980 teas-ietf-network-slice-definition-00 (work in progress), 4981 January 2021. 4983 [PYANG] "pyang", November 2020, 4984 . 4986 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 4987 Discovery Protocol (MSDP)", RFC 3618, 4988 DOI 10.17487/RFC3618, October 2003, 4989 . 4991 [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. 4992 Moore, "Policy Quality of Service (QoS) Information 4993 Model", RFC 3644, DOI 10.17487/RFC3644, November 2003, 4994 . 4996 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 4997 Private Network (VPN) Terminology", RFC 4026, 4998 DOI 10.17487/RFC4026, March 2005, 4999 . 5001 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 5002 Provider-Provisioned Virtual Private Networks (PPVPNs)", 5003 RFC 4110, DOI 10.17487/RFC4110, July 2005, 5004 . 5006 [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., 5007 and A. Gonguet, "Framework for Layer 3 Virtual Private 5008 Networks (L3VPN) Operations and Management", RFC 4176, 5009 DOI 10.17487/RFC4176, October 2005, 5010 . 5012 [RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco 5013 Systems' Solution for Multicast in BGP/MPLS IP VPNs", 5014 RFC 6037, DOI 10.17487/RFC6037, October 2010, 5015 . 5017 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 5018 Networking: A Perspective from within a Service Provider 5019 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 5020 . 5022 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 5023 Connectivity Provisioning Profile (CPP)", RFC 7297, 5024 DOI 10.17487/RFC7297, July 2014, 5025 . 5027 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 5028 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 5029 Defined Networking (SDN): Layers and Architecture 5030 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 5031 2015, . 5033 [RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E., 5034 and W. George, "Enhanced Duplicate Address Detection", 5035 RFC 7527, DOI 10.17487/RFC7527, April 2015, 5036 . 5038 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 5039 Code: The Implementation Status Section", BCP 205, 5040 RFC 7942, DOI 10.17487/RFC7942, July 2016, 5041 . 5043 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 5044 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 5045 . 5047 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 5048 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 5049 DOI 10.17487/RFC8299, January 2018, 5050 . 5052 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 5053 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 5054 . 5056 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 5057 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 5058 . 5060 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 5061 and R. Wilton, "Network Management Datastore Architecture 5062 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 5063 . 5065 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 5066 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 5067 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 5068 2018, . 5070 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 5071 Routing Management (NMDA Version)", RFC 8349, 5072 DOI 10.17487/RFC8349, March 2018, 5073 . 5075 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 5076 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 5077 DOI 10.17487/RFC8453, August 2018, 5078 . 5080 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 5081 Vinapamula, S., and Q. Wu, "A YANG Module for Network 5082 Address Translation (NAT) and Network Prefix Translation 5083 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 5084 . 5086 [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and 5087 L. Geng, "A Framework for Automating Service and Network 5088 Management with YANG", RFC 8969, DOI 10.17487/RFC8969, 5089 January 2021, . 5091 Appendix A. L3VPN Examples 5093 A.1. 4G VPN Provisioning Example 5095 L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise 5096 services mainly because several traffic discrimination policies can 5097 be applied within the network to deliver to the mobile customers a 5098 service that meets the SLA requirements. 5100 As it is shown in the Figure 30, typically, an eNodeB (CE) is 5101 directly connected to the access routers of the mobile backhaul and 5102 their logical interfaces (one or many according to the Service type) 5103 are configured in a VPN that transports the packets to the mobile 5104 core platforms. In this example, a 'vpn-node' is created with two 5105 'vpn-network-accesses'. 5107 +-------------+ +------------------+ 5108 | | | PE | 5109 | | 192.0.2.2 | 198.51.100.1 | 5110 | eNodeB |>--------/------->|........... | 5111 | | Vlan 1 | | | 5112 | |>--------/------->|...... | | 5113 | | Vlan 2 | | | | 5114 | | Direct | +-------------+ | 5115 +-------------+ Routing | | vpn-node-id | | 5116 | | 44 | | 5117 | +-------------+ | 5118 | | 5119 +------------------+ 5121 Figure 30: Mobile Backhaul Example 5123 To create a L3VPN service using the L3NM, the following sample steps 5124 can be followed: 5126 First: Create the 4G VPN service (Figure 31). 5128 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services 5129 Host: example.com 5130 Content-Type: application/yang-data+json 5132 { 5133 "ietf-l3vpn-ntw:vpn-services": { 5134 "vpn-service": [ 5135 { 5136 "vpn-id": "4G", 5137 "customer-name": "mycustomer", 5138 "vpn-service-topology": "custom", 5139 "description": "VPN to deploy 4G services" 5140 } 5141 ] 5142 } 5143 } 5145 Figure 31: Create VPN Service 5147 Second: Create a VPN node as depicted in Figure 32. In this type of 5148 service, the VPN node is equivalent to the VRF configured in the 5149 physical device ('ne-id'=198.51.100.1). 5151 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ 5152 vpn-services/vpn-service=4G 5153 Host: example.com 5154 Content-Type: application/yang-data+json 5156 { 5157 "ietf-l3vpn-ntw:vpn-nodes": { 5158 "vpn-node": [ 5159 { 5160 "vpn-node-id": "44", 5161 "ne-id": "198.51.100.1", 5162 "local-autonomous-system": "65550", 5163 "rd": "0:65550:1", 5164 "vpn-targets": { 5165 "vpn-target": [ 5166 { 5167 "id": "1", 5168 "route-targets": [ 5169 "0:65550:1" 5170 ], 5171 "route-target-type": "both" 5172 } 5173 ] 5174 } 5175 } 5176 ] 5177 } 5178 } 5180 Figure 32: Create VPN Node 5182 Finally, two VPN network accesses are created using the same physical 5183 port ('port-id'=1/1/1). Each 'vpn-network-access' has a particular 5184 VLAN (1,2) to differentiate the traffic between: Sync and data 5185 (Figure 33). 5187 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ 5188 vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44 5189 content-type: application/yang-data+json 5191 { 5192 "ietf-l3vpn-ntw:vpn-network-accesses": { 5193 "vpn-network-access": [ 5194 { 5195 "vpn-network-access-id": "1/1/1.1", 5196 "port-id": "1/1/1", 5197 "description": "Interface SYNC to eNODE-B", 5198 "admin-status": { 5199 "status": "vpn-common:administrative-state-up" 5200 }, 5201 "vpn-network-access-type": "vpn-common:point-to-point", 5202 "ip-connection": { 5203 "ipv4": { 5204 "local-address": "192.0.2.1/32", 5205 "address-allocation-type": "static-address", 5206 "static-addresses": { 5207 "primary-address": "1", 5208 "address": [ 5209 { 5210 "address-id": "1", 5211 "s-customer-address": "192.0.2.2" 5212 } 5213 ] 5214 } 5215 } 5216 }, 5217 "routing-protocols": { 5218 "routing-protocol": [ 5219 { 5220 "id": "1", 5221 "type": "vpn-common:direct" 5222 } 5223 ] 5224 } 5225 }, 5226 { 5227 "vpn-network-access-id": "1/1/1.2", 5228 "port-id": "1/1/1", 5229 "description": "Interface DATA to eNODE-B", 5230 "admin-status": { 5231 "status": "vpn-common:administrative-state-up" 5232 }, 5233 "ip-connection": { 5234 "ipv4": { 5235 "local-address": "192.0.2.1/32", 5236 "address-allocation-type": "static-address", 5237 "static-addresses": { 5238 "primary-address": "1", 5239 "address": [ 5240 { 5241 "address-id": "1", 5242 "customer-address": "192.0.2.2" 5243 } 5244 ] 5245 } 5246 } 5248 }, 5249 "routing-protocols": { 5250 "routing-protocol": [ 5251 { 5252 "id": "1", 5253 "type": "vpn-common:direct" 5254 } 5255 ] 5256 } 5257 } 5258 ] 5259 } 5260 } 5262 Figure 33: Create VPN Network Access 5264 Similar actions can be followed when IPv6 is supported in a VPN. For 5265 example, Figure 34 illustrates how to create a VPN node that is 5266 identified with an 'ne-id' set to 2001:db8::1. 5268 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ 5269 vpn-services/vpn-service=4G 5270 Host: example.com 5271 Content-Type: application/yang-data+json 5273 { 5274 "ietf-l3vpn-ntw:vpn-nodes": { 5275 "vpn-node": [ 5276 { 5277 "vpn-node-id": "44", 5278 "ne-id": "2001:db8::1", 5279 "local-autonomous-system": "65550", 5280 "rd": "0:65550:1", 5281 "vpn-targets": { 5282 "vpn-target": [ 5283 { 5284 "id": "1", 5285 "route-targets": [ 5286 "0:65550:1" 5287 ], 5288 "route-target-type": "both" 5289 } 5290 ] 5291 } 5292 } 5293 ] 5294 } 5295 } 5297 Figure 34: Create VPN Node (IPv6) 5299 An example of creating a loopback interface is depicted in . 5301 { 5302 "ietf-l3vpn-ntw:vpn-network-accesses": { 5303 "vpn-network-access": [ 5304 { 5305 "vpn-network-access-id": "Loopback1", 5306 "port-id": "Loopback1", 5307 "description": "An example of loopback interface.", 5308 "admin-status": { 5309 "status": "vpn-common:administrative-state-up" 5310 }, 5311 "vpn-network-access-type": "vpn-common:loopback", 5312 "ip-connection": { 5313 "ipv6": { 5314 "local-address": "2001:db8::1/128" 5315 } 5316 } 5317 } 5318 ] 5319 } 5320 } 5322 Figure 35: Create a Loopback Interface 5324 A.2. Multicast VPN Provisioning Example 5326 IPTV is mainly distributed through multicast over the LANs. In the 5327 following example, PIM-SM is enabled and functional between the PE 5328 and the CE. The PE receives multicast traffic from a CE that is 5329 directly connected to the multicast source. The signaling between PE 5330 and CE is achieved using BGP. Also, RP is statically configured for 5331 a multicast group. 5333 +-----------+ +------+ +------+ +-----------+ 5334 | Multicast |---| CE |--/--| PE |----| Backbone | 5335 | source | +------+ +------+ | IP/MPLS | 5336 +-----------+ +-----------+ 5338 Figure 36: Multicast L3VPN Service Example 5340 To configure a Multicast L3VPN service using the L3NM model the 5341 procedure and the JSON with the data structure is the following: 5343 First, the multicast service is created (see the excerpt of the 5344 request message body shown in Figure 37) 5345 { 5346 "ietf-l3vpn-ntw:vpn-services": { 5347 "vpn-service": [ 5348 { 5349 "vpn-id": "Multicast-IPTV", 5350 "customer-name": "310", 5351 "vpn-service-topology": "vpn-common:hub-spoke", 5352 "description": "Multicast IPTV VPN service" 5353 } 5354 ] 5355 } 5356 } 5358 Figure 37: Create Multicast VPN Service (Excerpt of the Message 5359 Request Body) 5361 Then, the VPN nodes are created (see the excerpt of the request 5362 message body shown in Figure 38). In this example, the VPN Node will 5363 represent VRF configured in the physical device. 5365 { 5366 "ietf-l3vpn-ntw:vpn-node": [ 5367 { 5368 "vpn-node-id": "500003105", 5369 "description": "VRF-IPTV-MULTICAST", 5370 "ne-id": "198.51.100.10", 5371 "node-role": "vpn-common:hub-role", 5372 "local-autonomous-system": "3816", 5373 "address-family": "vpn-common:ipv4", 5374 "router-id": "198.51.100.10", 5375 "rd": "3816:31050202", 5376 "multicast": { 5377 "status": { 5378 "admin-status": { 5379 "status": "vpn-common:administrative-state-up" 5380 } 5381 }, 5382 "rp": { 5383 "rp-group-mappings": { 5384 "rp-group-mapping": [ 5385 { 5386 "id": "1", 5387 "rp-address": "203.0.113.17", 5388 "groups": { 5389 "group": [ 5390 { 5391 "id": "1", 5392 "group-address": "239.130.0.0/15" 5393 } 5394 ] 5395 } 5396 } 5397 ] 5398 }, 5399 "rp-discovery": { 5400 "rp-discovery-type": "vpn-common:static-rp" 5401 } 5402 } 5403 } 5404 } 5405 ] 5406 } 5408 Figure 38: Create Multicast VPN Node (Excerpt of the Message Request 5409 Body) 5411 Finally, create the VPN Network Access with multicast enabled (see 5412 the excerpt of the request message body shown in Figure 39). 5414 { 5415 "ietf-l3vpn-ntw:vpn-network-access": { 5416 "vpn-network-access-id": "1/1/1", 5417 "description": "Connected_to_source", 5418 "status": { 5419 "admin-status": { 5420 "status": "vpn-common:administrative-state-up" 5421 }, 5422 "vpn-network-access-type": "vpn-common:point-to-point", 5423 "ip-connection": { 5424 "ipv4": { 5425 "local-address": "203.0.113.1/32", 5426 "address-allocation-type": "static-address", 5427 "static-addresses": { 5428 "primary-address": "1", 5429 "address": [ 5430 { 5431 "address-id": "1", 5432 "customer-address": "203.0.113.2" 5433 } 5434 ] 5435 } 5436 } 5437 }, 5438 "routing-protocols": { 5439 "routing-protocol": [ 5440 { 5441 "id": "1", 5442 "type": "vpn-common:bgp", 5443 "bgp": { 5444 "description": "Connected to CE" 5445 "local-autonomous-system": "3816", 5446 "peer-autonomous-system": "6500", 5447 "address-family": "vpn-common:ipv4", 5448 "neighbor": "203.0.113.2", 5449 } 5450 } 5451 ] 5452 }, 5453 "service": { 5454 "multicast": { 5455 "multicast-site-type": "source-only", 5456 "address-family": "vpn-common:ipv4", 5457 "protocol-type": "router", 5458 "pim": { 5459 "hello-interval": 30, 5460 "status": { 5461 "admin-status": { 5462 "status": "vpn-common:administrative-state-up" 5463 } 5464 } 5465 } 5466 } 5467 } 5468 } 5469 } 5471 Figure 39: Create VPN Network Access (Excerpt of the Message Request 5472 Body) 5474 Appendix B. Implementation Status 5476 This section records the status of known implementations of the Yang 5477 module defined by this specification at the time of posting of this 5478 Internet-Draft, and is based on a proposal described in [RFC7942]. 5479 The description of implementations in this section is intended to 5480 assist the IETF in its decision processes in progressing drafts to 5481 RFCs. Please note that the listing of any individual implementation 5482 here does not imply endorsement by the IETF. Furthermore, no effort 5483 has been spent to verify the information presented here that was 5484 supplied by IETF contributors. This is not intended as, and must not 5485 be construed to be, a catalog of available implementations or their 5486 features. Readers are advised to note that other implementations may 5487 exist. 5489 According to [RFC7942], "this will allow reviewers and working groups 5490 to assign due consideration to documents that have the benefit of 5491 running code, which may serve as evidence of valuable experimentation 5492 and feedback that have made the implemented protocols more mature. 5493 It is up to the individual working groups to use this information as 5494 they see fit". 5496 Note the RFC Editor: As per [RFC7942] guidelines, please remove this 5497 Implementation Status apendix prior publication. 5499 B.1. Nokia Implementation 5501 Details can be found at: https://github.com/IETF-OPSAWG- 5502 WG/l3nm/blob/master/Implementattion/Nokia.txt 5504 B.2. Huawei Implementation 5506 Details can be found at: https://github.com/IETF-OPSAWG- 5507 WG/l3nm/blob/master/Implementattion/Huawei.txt 5509 B.3. Infinera Implementation 5511 Details can be found at: https://github.com/IETF-OPSAWG- 5512 WG/l3nm/blob/master/Implementattion/Infinera.txt 5514 B.4. Ribbon-ECI Implementation 5516 Details can be found at: https://github.com/IETF-OPSAWG- 5517 WG/l3nm/blob/master/Implementattion/Ribbon-ECI.txt 5519 Authors' Addresses 5521 Samier Barguil 5522 Telefonica 5523 Madrid 5524 ES 5526 Email: samier.barguilgiraldo.ext@telefonica.com 5528 Oscar Gonzalez de Dios (editor) 5529 Telefonica 5530 Madrid 5531 ES 5533 Email: oscar.gonzalezdedios@telefonica.com 5535 Mohamed Boucadair (editor) 5536 Orange 5537 Rennes 35000 5538 France 5540 Email: mohamed.boucadair@orange.com 5542 Luis Angel Munoz 5543 Vodafone 5544 ES 5546 Email: luis-angel.munoz@vodafone.com 5547 Alejandro Aguado 5548 Nokia 5549 Madrid 5550 ES 5552 Email: alejandro.aguado_martin@nokia.com