idnits 2.17.1 draft-ietf-opsawg-l3sm-l3nm-05.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 569 has weird spacing: '...--rw id str...' == Line 571 has weird spacing: '...--rw id str...' == Line 573 has weird spacing: '...--rw id str...' == Line 575 has weird spacing: '...--rw id str...' == Line 577 has weird spacing: '...--rw id str...' == (13 more instances...) -- The document date (October 16, 2020) is 1288 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-01 ** Downref: Normative reference to an Informational RFC: RFC 4110 == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-09 == Outdated reference: A later version (-12) exists of draft-ietf-rtgwg-qos-model-02 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). 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: April 19, 2021 M. Boucadair, Ed. 6 Orange 7 L. Munoz 8 Vodafone 9 A. Aguado 10 Nokia 11 October 16, 2020 13 A Layer 3 VPN Network YANG Model 14 draft-ietf-opsawg-l3sm-l3nm-05 16 Abstract 18 This document defines a L3VPN Network YANG Model (L3NM) that can be 19 used to manage the provisioning of Layer 3 Virtual Private Network 20 (VPN) services within a Service Provider's network. The model 21 provides a 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 April 19, 2021. 58 Copyright Notice 60 Copyright (c) 2020 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 77 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 4. L3NM Reference Architecture . . . . . . . . . . . . . . . . . 6 79 5. Relation with other YANG Models . . . . . . . . . . . . . . . 8 80 6. Sample Uses of the L3NM Data Model . . . . . . . . . . . . . 10 81 6.1. Enterprise Layer 3 VPN Services . . . . . . . . . . . . . 10 82 6.2. Multi-Domain Resource Management . . . . . . . . . . . . 10 83 6.3. Management of Multicast Services . . . . . . . . . . . . 11 84 7. Description of the L3NM YANG Module . . . . . . . . . . . . . 11 85 7.1. Overall Structure of the Module . . . . . . . . . . . . . 11 86 7.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 12 87 7.3. Modeling a Layer 3 VPN Service . . . . . . . . . . . . . 13 88 7.3.1. Service Status . . . . . . . . . . . . . . . . . . . 15 89 7.3.2. Concept of Import/Export Profiles . . . . . . . . . . 15 90 7.3.3. Underlay Transport . . . . . . . . . . . . . . . . . 16 91 7.3.4. VPN Node . . . . . . . . . . . . . . . . . . . . . . 17 92 7.3.4.1. RT/RD Assignment/auto-assignment . . . . . . . . 19 93 7.3.4.2. VPN Network Access . . . . . . . . . . . . . . . 20 94 7.3.4.2.1. Connection . . . . . . . . . . . . . . . . . 21 95 7.3.4.2.2. IP Connections . . . . . . . . . . . . . . . 23 96 7.3.4.2.3. Security . . . . . . . . . . . . . . . . . . 27 97 7.3.4.2.4. CE-PE Routing Protocols . . . . . . . . . . . 27 98 7.3.4.2.5. Services . . . . . . . . . . . . . . . . . . 36 99 7.3.4.3. Multicast . . . . . . . . . . . . . . . . . . . . 42 100 8. Layer 3 Network Model . . . . . . . . . . . . . . . . . . . . 43 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89 102 10. Security Considerations . . . . . . . . . . . . . . . . . . . 89 103 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 91 104 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 91 105 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 92 106 13.1. Normative References . . . . . . . . . . . . . . . . . . 92 107 13.2. Informative References . . . . . . . . . . . . . . . . . 93 108 Appendix A. L3VPN Examples . . . . . . . . . . . . . . . . . . . 96 109 A.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 96 110 A.2. Multicast VPN Provisioning Example . . . . . . . . . . . 100 111 Appendix B. Implementation Status . . . . . . . . . . . . . . . 104 112 B.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 104 113 B.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 104 114 B.3. Infinera Implementation . . . . . . . . . . . . . . . . . 104 115 B.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 104 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 105 118 1. Introduction 120 [RFC8299] defines a L3VPN Service YANG data Model (L3SM) that can be 121 used for communication between customers and network operators. Such 122 model is focused on describing the customer view of the Virtual 123 Private Network (VPN) services, and provides an abstracted view of 124 the customer's requested services. That approach limits the usage of 125 the L3SM module to the role of a Customer Service Model, according to 126 the terminology defined in [RFC8309]. 128 This document defined a YANG module called L3VPN Network Model 129 (L3NM). The L3NM is aimed at providing a network-centric view of 130 Layer 3 (L3) VPN Services. This data model can be used to facilitate 131 communication between the service orchestrator (or a network 132 operator) and the network controller/orchestrator by allowing for 133 more network-centric information to be included. It enables further 134 capabilities, such as resource management or to serve as a multi- 135 domain orchestration interface, where logical resources (such as 136 route targets or route distinguishers) must be synchronized. 138 This document uses the common VPN YANG module defined in 139 [I-D.ietf-opsawg-vpn-common]. 141 This document does not obsolete, but uses, the definitions in 142 [RFC8299]. These two modules are used for similar objectives but 143 with different scopes and views. 145 The L3NM YANG module is initially built with a prune and extend 146 approach, taking as a starting points the YANG module described in 147 [RFC8299]. Nevertheless, this module is not defined as an augment to 148 L3SM because a specific structure is required to meet network- 149 oriented L3 needs. 151 Some of the information captured in the L3SM can be passed by the 152 Orchestrator in the L3NM (e.g., customer) or be used to fed some of 153 the L3NM attributes (e.g., actual forwarding policies). Some of the 154 information captured in L3SM may be maintained locally within the 155 Orchestrator; which is in charge of maintaining the correspondence 156 between a Customer view and its network instantiation. Likewise, 157 some of the information captured and exposed using L3NM can fed the 158 service layer (e.g., capabilities) to derive L3SM and drive VPN 159 service order handling. 161 The L3NM does not attempt to address all deployment cases especially 162 those where the L3VPN connectivity is supported through the 163 coordination of different VPNs in different underlying networks. 164 More complex deployment scenarios involving the coordination of 165 different VPN instances and different technologies to provide end-to- 166 end VPN connectivity are addressed by a complementary YANG model 167 defined in [I-D.evenwu-opsawg-yang-composed-vpn]. 169 L3NM focuses on BGP PE-based Layer 3 VPNs as described in 170 [RFC4026][RFC4110][RFC4364] and Multicast VPNs as described in 171 [RFC6037][RFC6513][RFC7988]. 173 The YANG data model in this document conforms to the Network 174 Management Datastore Architecture (NMDA) defined in [RFC8342]. 176 2. Requirements Language 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 180 "OPTIONAL" in this document are to be interpreted as described in BCP 181 14 [RFC2119] [RFC8174] when, and only when, they appear in all 182 capitals, as shown here. 184 3. Terminology 186 This document assumes that the reader is familiar with the contents 187 of [RFC6241], [RFC7950], [RFC8299], [RFC8309], and [RFC8453] and uses 188 the terminology defined in those documents. 190 The meaning of the symbols in tree diagrams is defined in [RFC8340]. 192 The document is aimed at modeling BGP PE-based VPNs in a service 193 provider network, so the terms defined in [RFC4026] and [RFC4176] are 194 used. 196 This document makes use of the following terms: 198 o Layer 3 VPN Customer Service Model (L3SM): A YANG module that 199 describes the requirements of a L3VPN that interconnects a set of 200 sites from the point of view of the customer. The customer 201 service model does not provide details on the service provider 202 network. The L3VPN Customer Service model is defined in 203 [RFC8299]. 205 o Layer 3 VPN Service Network Model (L3NM): A YANG module that 206 describes a VPN Service in the service provider network. It 207 contains information of the Service Provider network and might 208 include allocated resources. It can be used by network 209 controllers to manage and control the VPN Service configuration in 210 the Service Provider network. The YANG module can be consumed by 211 a Service Orchestrator to request a VPN Service to a Network 212 controller. 214 o Service Orchestrator: A functional entity that interacts with the 215 customer of a L3VPN. The Service Orchestrator interacts with the 216 customer using L3SM. The Service Orchestrator is responsible of 217 the Customer Edge (CE) - the Provider Edge (PE) attachment 218 circuits, the PE selection, and requesting the VPN service to the 219 network controller. 221 o Network Orchestrator: A functional entity that is hierarchically 222 intermediate between Service Orchestrator and Network Controllers. 223 A network orchestrator can manage one or several Network 224 Controllers. 226 o Network Controller: A functional entity responsible for the 227 control and management of the service provider network. 229 o VPN node: An abstraction that represents a set of policies applied 230 on a PE and that belong to a single VPN service. A VPN service 231 involves one or more VPN nodes. As it is an abstraction, the 232 network controller will take on how to implement a VPN node. For 233 example, typically, in a BGP-based VPN, a VPN node could be mapped 234 into a Virtual Routing and Forwarding (VRF). 236 o VPN network access: An abstraction that represents the network 237 interfaces that are associated to a given VPN node. Traffic 238 coming from the VPN network access belongs to the VPN. The 239 attachment circuits (bearers) between CEs and PEs are terminated 240 in the VPN network access. A reference to the bearer is 241 maintained to allow keeping the link between L3SM and L3NM. 243 o VPN Site: A VPN customer's location that is connected to the 244 Service Provider network via a CE-PE link, which can access at 245 least one VPN [RFC4176]. 247 o VPN Service Provider (SP): A Service Provider that offers VPN- 248 related services [RFC4176]. 250 o Service Provider (SP) Network: A network that is able to provide 251 VPN-related services. 253 4. L3NM Reference Architecture 255 Figure 1 depicts the reference architecture for L3NM. The figure is 256 an expansion of the architecture presented in Section 5 of [RFC8299] 257 and decomposes the box marked "orchestration" in that figure into 258 three separate functional components called "Service Orchestration", 259 "Network Orchestration", and "Domain Orchestration". 261 Although some deployments may choose to construct a monolithic 262 orchestration component (covering both service and network matters), 263 this document advocates for a clear separation between service and 264 network orchestration components for the sake of better flexibility. 265 Such design adheres to the L3VPN reference architecture defined in 266 Section 1.3 of [RFC4176]. The above separation relies upon a 267 dedicated communication interface between these components and 268 appropriate YANG module that reflect network-related information 269 (that is hidden to customers). 271 The intelligence for translating customer-facing information into 272 network-centric one is implementation specific. 274 The terminology from [RFC8309] is introduced to show the distinction 275 between the "Customer Service Model", the "Service Delivery Model", 276 the "Network Configuration Model", and the "Device Configuration 277 Model". In that context, the "Domain Orchestration" and "Config 278 Manager" roles may be performed by "Controllers". 280 +---------------+ 281 | Customer | 282 +---------------+ 283 Customer Service Model | 284 l3vpn-svc | 285 +---------------+ 286 | Service | 287 | Orchestration | 288 +---------------+ 289 L3NM Network Model | 290 l3vpn-ntw | 291 +---------------+ 292 | Network | 293 | Orchestration | 294 +---------------+ 295 Network Configuration Model | 296 +-----------+-----------+ 297 | | 298 +---------------+ +---------------+ 299 | Domain | | Domain | 300 | Orchestration | | Orchestration | 301 +---------------+ +---------------+ 302 Device | | | 303 Configuration | | | 304 Model | | | 305 +---------+ | | 306 | Config | | | 307 | Manager | | | 308 +---------+ | | 309 | | | 310 | NETCONF/CLI.................. 311 | | | 312 +------------------------------------------------+ 313 Network 315 Figure 1: Reference Architecture 317 The L3SM and the L3NM may also be used in the context of the ACTN 318 architecture [RFC8453]. Figure 2 shows the Customer Network 319 Controller (CNC), the Multi-Domain Service Coordinator (MDSC), and 320 the Provisioning Network Controller (PNC). It also shows the 321 interfaces between these functional blocks: the CNC-MDSC Interface 322 (CMI), the MDSC-PNC Interface (MPI), and the Southbound Interface 323 (SBI). 325 +----------------------------------+ 326 | Customer | 327 | +-----------------------------+ | 328 | | CNC | | 329 | +-----------------------------+ | 330 +----:-----------------------:-----+ 331 : : 332 : L3SM : L3SM 333 : : 334 +---------:---------+ +-------------------+ 335 | MDSC : | | MDSC | 336 | +---------------+ | | (parent) | 337 | | Service | | +-------------------+ 338 | | Orchestration | | : 339 | +---------------+ | : L3NM 340 | : | : 341 | : L3NM | +-------------------+ 342 | : | | MDSC | 343 | +---------------+ | | (child) | 344 | | Network | | +-------------------+ 345 | | Orchestration | | : 346 | +---------------+ | : 347 +---------:---------+ : 348 : : 349 : Network Configuration : 350 : : 351 +------------:-------+ +---------:------------+ 352 | Domain : | | : Domain | 353 | Controller : | | : Controller | 354 | +---------+ | | +---------+ | 355 | | PNC | | | | PNC | | 356 | +---------+ | | +---------+ | 357 +------------:-------+ +---------:------------+ 358 : : 359 : Device Configuration : 360 : : 361 +--------+ +--------+ 362 | Device | | Device | 363 +--------+ +--------+ 365 Figure 2: L3SM and L3NM in the Context of ACTN 367 5. Relation with other YANG Models 369 The "ietf-vpn-common" module [I-D.ietf-opsawg-vpn-common] includes a 370 set of identities, types, and groupings that are meant to be reused 371 by VPN-related YANG modules independently of the layer (e.g., Layer 372 2, Layer 3) and the type of the module (e.g., network model, service 373 model) including future revisions of existing models (e.g., [RFC8299] 374 or [RFC8466]). The L3NM reuses these common types and grouping. 376 In order to avoid data duplication and to ease passing data between 377 layers when required (service layer to network layer and vice versa), 378 early versions of the L3NM reused many of the data nodes that are 379 defined in [RFC8299]. Nevertheless, that approach was abandoned in 380 favor of the "ietf-vpn-common" module because that design was 381 interpreted as if the deployment of L3NM depends on L3SM, while this 382 is not the case. For example, a Service Provider may decide to use 383 the L3NM to build its L3VPN services without exposing the L3SM. 385 As discussed in Section 4, the L3NM YANG module is meant to manage 386 L3VPN services within a Service Provider network. The module 387 provides a network view of the service. Such view is only visible 388 within the Service Provider and is not exposed outside (to customers, 389 for example). The following discusses how L3NM interfaces with other 390 YANG modules: 392 L3SM: L3NM is not a Customer Service Model. 394 The internal view of the service (L3NM) may be mapped to an 395 external view which is visible to Customers : L3VPN Service YANG 396 data Model (L3SM) [RFC8299]. 398 Typically, the L3NM can be fed with inputs that are requested by 399 Customers, typically, relying upon a L3SM template. Concretely, 400 some parts of the L3SM module can be directly mapped into L3NM 401 while other parts are generated as a function of the requested 402 service and local guidelines. Some other parts are local to the 403 Service Provider and do not map directly to L3SM. 405 Note that the use of L3NM within a Service Provider does not 406 assume nor preclude exposing the VPN service via L3SM. This is 407 deployment-specific. Nevertheless, the design of L3NM tries to 408 align as much as possible with the features supported by the L3SM 409 to ease grafting both L3NM and L3SM for the sake of highly 410 automated VPN service provisioning and delivery. 412 Network Topology Modules: A L3VPN involves nodes that are part of a 413 topology managed by the Service Provider Backbone network. Such 414 topology can be represented as using the network topology module 415 in [RFC8345]. 417 Device Modules: L3NM is not a device model. 419 Once a global VPN service is captured by means of L3NM, the actual 420 activation and provisioning of the VPN service will involve a 421 variety of device modules to tweak the required functions for the 422 delivery of the service. These functions are supported by the VPN 423 nodes and can be managed using device YANG modules. A non- 424 comprehensive list of such device YANG modules is provided below: 426 * Routing management [RFC8349]. 428 * BGP [I-D.ietf-idr-bgp-model]. 430 * PIM [I-D.ietf-pim-yang]. 432 * NAT management [RFC8512]. 434 * QoS management [I-D.ietf-rtgwg-qos-model]. 436 * ACLs [RFC8519]. 438 How L3NM is used to derive device-specific actions is 439 implementation-specific. 441 6. Sample Uses of the L3NM Data Model 443 6.1. Enterprise Layer 3 VPN Services 445 Enterprise L3VPNs are one of the most demanded services for carriers, 446 and therefore, L3NM can be useful to automate the tasks of 447 provisioning and maintenance of these VPNs. Templates and batch 448 processes can be built, and as a result many parameters are needed 449 for the creation from scratch of a VPN that can be abstracted to the 450 upper SDN layer and little manual intervention will be still 451 required. 453 Also common addition/removal of sites of an existing customer VPN can 454 benefit of using L3NM, by creation of workflows that either prune or 455 add nodes as required from the network data model object. 457 6.2. Multi-Domain Resource Management 459 The implementation of L3VPN services which span across 460 administratively separated domains (i.e., that are under the 461 administration of different management systems or controllers) 462 requires some network resources to be synchronized between systems. 463 Particularly, there are two resources that must be orchestrated and 464 manage to avoid asymmetric (non-functional) configuration, or the 465 usage of unavailable resources. 467 For example, RTs shall be synchronized between PEs. When every PE is 468 controlled by the same management system, RT allocation can be 469 performed by the system. In cases where the service spans across 470 multiple management systems, this task of allocating RTs has to be 471 aligned across the domains, therefore, the service model must provide 472 a way to specify RTs. In addition, RDs must also be synchronized to 473 avoid collisions in RD allocation between separate systems. An 474 incorrect allocation might lead to the same RD and IP prefixes being 475 exported by different PE routers. 477 6.3. Management of Multicast Services 479 Multicast services over L3VPN can be implemented either using dual 480 PIM MVPNs (also known as, Draft Rosen model) [RFC4364] or 481 multiprotocol BGP (MBGP)-based MVPNs[RFC6513][RFC6514]. Both methods 482 are supported and equally effective, but the main difference is that 483 MBGP-based MVPN does not require multicast configuration on the 484 service provider backbone. MBGP MVPNs employ the intra-autonomous 485 system BGP control plane and PIM sparse mode as the data plane. The 486 PIM state information is maintained between the PE routers using the 487 same architecture that is used for unicast VPNs. 489 On the other hand, Draft Rosen has limitations such as reduced 490 options for transport, control plane scalability, availability, 491 operational inconsistency, and the need of maintaining state in the 492 backbone. Because of this, MBGP MVPN is the architectural model that 493 has been taken as the base for implementing multicast service on 494 L3VPN. In this scenario, BGP auto discovery is used to discover MVPN 495 PE members and the customer PIM signaling is sent across provider 496 core through MP-BGP. The multicast traffic is transported on MPLS 497 P2MP LSPs. All of the previous information is carried in the MCAST- 498 VPN BGP NRLI. 500 7. Description of the L3NM YANG Module 502 The L3NM ('ietf-l3vpn-ntw') is defined to manage L3VPNs in a service 503 provider network. In particular, the 'ietf-l3vpn-ntw' module can be 504 used to create, modify, and retrieve L3VPN Services of a network. 506 7.1. Overall Structure of the Module 508 The 'ietf-l3vpn-ntw' module uses two main containers: 'vpn-services' 509 and 'vpn-profiles' (see Figure 3). 511 The 'vpn-services' container maintains the set of VPN services 512 managed within the service provider's network. 'vpn-service' is the 513 data structure that abstracts a VPN service (Section 7.3). 515 The 'vpn-profiles' container is used by the provider to maintain a 516 set of common VPN profiles that apply to one or several VPN services 517 (Section 7.2). 519 module: ietf-l3vpn-ntw 520 +--rw l3vpn-ntw 521 +--rw vpn-profiles 522 | ... 523 +--rw vpn-services 524 +--rw vpn-service* [vpn-id] 525 ... 527 Figure 3: Overall L3NM Tree Structure 529 7.2. VPN Profiles 531 The 'vpn-profiles' container (Figure 4) allows the network provider 532 to define and maintain a set of common VPN profiles 533 [I-D.ietf-opsawg-vpn-common] that apply to one or several VPN 534 services. The exact definition of the profiles is local to each 535 network provider. 537 This document does not make any assumption about the exact definition 538 of these profiles. How such profiles are defined is deployment 539 specific. The model only includes an identifier to these profiles to 540 ease identifying local policies when building a VPN service. As 541 shown in Figure 4, the following identifiers can be included: 543 o 'cloud-identifier': This identifier refers to a cloud service. 545 o 'encryption-profile-identifier': An encryption profile refers to a 546 set of policies related to the encryption scheme(s) and setup that 547 can be applied when building and offering a VPN service. 549 o 'qos-profile-identifier': A QoS profile refers to as set of 550 policies such as classification, marking, and actions (e.g., 551 [RFC3644]). 553 o 'bfd-profile-identifier': A Bidirectional Forwarding Detection 554 (BFD) profile refers to a set of BFD [RFC5880] policies that can 555 be invoked when building a VPN service. 557 o 'forwarding-profile-identifier': A forwarding profile refers to 558 the policies that apply to the forwarding of packets conveyed 559 within a VPN. Such policies may consist at applying Access 560 Control Lists (ACLs). 562 o 'routing-profile-identifier': A routing profile refers to a set of 563 routing policies that will be invoked (e.g., BGP policies). 565 +--rw l3vpn-ntw 566 +--rw vpn-profiles 567 | +--rw valid-provider-identifiers 568 | +--rw cloud-identifier* [id] {cloud-access}? 569 | | +--rw id string 570 | +--rw encryption-profile-identifier* [id] 571 | | +--rw id string 572 | +--rw qos-profile-identifier* [id] 573 | | +--rw id string 574 | +--rw bfd-profile-identifier* [id] 575 | | +--rw id string 576 | +--rw forwarding-profile-identifier* [id] 577 | | +--rw id string 578 | +--rw routing-profile-identifier* [id] 579 | +--rw id string 580 +--rw vpn-services 581 ... 583 Figure 4: VPN Profiles Subtree Structure 585 7.3. Modeling a Layer 3 VPN Service 587 The 'vpn-service' is the data structure that abstracts a VPN service 588 in the service provider network. Each 'vpn-service' is uniquely 589 identified by an identifier: 'vpn-id'. Such 'vpn-id' is only 590 meaningful locally within the Network controller. 592 In order to facilitate the identification of the service, 'customer- 593 name' and 'description' attributes may be provided. 595 The main 'vpn-service' parameters are: 597 o 'status': Allows the control of the operative and administrative 598 status of the service as a whole. 600 o 'vpn-id': Is an identifier that is used to uniquely identify the 601 L3VPN Service within L3NM scope. 603 o 'l3sm-vpn-id': Refers to an identifier of L3SM service. This 604 identifier allows to easily correlate the (network) service as 605 built in the network with a service order. 607 o 'vpn-service-topology': Indicates the network topology for the 608 service: Hub-Spoke, Any-to-Any, and Custom. The deployment on the 609 network is defined by the correct usage of import and export 610 profiles 612 o 'vpn-type': Indicate the VPN service signaling type. 614 o 'ie-profiles': Defines reusable import/export policies for the 615 same 'vpn-service'. More details are provided in Section 7.3.2. 617 o 'underlay-transport': Describes the preference for the transport 618 technology to carry the traffic of the VPN service 619 (Section 7.3.3). 621 The 'vpn-node' is an abstraction that represents a set of policies 622 applied to a network node and that belong to a single 'vpn-service'. 623 A VPN service is typically built by adding instances of 'vpn-node' to 624 the 'vpn-nodes' container. 626 A 'vpn-node' contains 'vpn-network-accesses', which are the 627 interfaces attached to the VPN by which the customer traffic is 628 received. Therefore, the customer sites are connected to the 'vpn- 629 network-accesses'. 631 Note that, as this is a network data model, the information about 632 customers sites is not required in the model. Such information is 633 rather relevant in the L3SM. 635 +--rw l3vpn-ntw 636 +--rw vpn-profiles 637 | ... 638 +--rw vpn-services 639 +--rw vpn-service* [vpn-id] 640 +--rw status 641 | ... 642 +--rw vpn-id vpn-common:vpn-id 643 +--rw vpn-name? string 644 +--rw vpn-description? string 645 +--rw customer-name? string 646 +--rw l3sm-vpn-id? vpn-common:vpn-id 647 +--rw vpn-type? identityref 648 +--rw vpn-service-topology? identityref 649 +--rw ie-profiles 650 | ... 651 +--rw underlay-transport 652 | ... 653 +--rw vpn-nodes 654 ... 656 Figure 5: VPN Services Subtree Structure 658 7.3.1. Service Status 660 The L3NM allows to track service status ('status') of a given VPN 661 service (Figure 6). Both operational and administrative status are 662 maintained together with a timestamp. For example, a service can be 663 created but not put into effect. 665 'admin' and 'ops' status can be used as trigger to detect service 666 anomalies. For example, a service that is declared at the service 667 layer as active but still inactive at the network layer is an 668 indication that network provision actions are needed to align the 669 observed service with the expected service status. 671 +--rw l3vpn-ntw 672 +--rw vpn-profiles 673 | ... 674 +--rw vpn-services 675 +--rw vpn-service* [vpn-id] 676 +--rw status 677 | +--rw admin-status 678 | | +--rw status? identityref 679 | | +--rw last-updated? yang:date-and-time 680 | +--ro oper-status 681 | +--ro status? identityref 682 | +--ro last-updated? yang:date-and-time 683 ... 685 Figure 6: VPN Service Status Subtree Structure 687 7.3.2. Concept of Import/Export Profiles 689 The import and export profiles construct contains a list with 690 information related with route target and distinguishers (RTs and 691 RDs), grouped and identified by 'ie-profile-id'. The identifier is 692 then referenced in one or multiple 'vpn-nodes' so the controller can 693 identify RTs and RDs to be configured for a given VRF. The subtree 694 is shown in Figure 7. 696 +--rw l3vpn-ntw 697 +--rw vpn-profiles 698 | ... 699 +--rw vpn-services 700 +--rw vpn-service* [vpn-id] 701 +--rw vpn-id vpn-common:vpn-id 702 + ... 703 +--rw ie-profiles 704 | +--rw ie-profile* [ie-profile-id] 705 | +--rw ie-profile-id string 706 | +--rw rd? union 707 | +--rw vpn-targets 708 | +--rw vpn-target* [id] 709 | | +--rw id int8 710 | | +--rw route-targets* [route-target] 711 | | | +--rw route-target rt-types:route-target 712 | | +--rw route-target-type 713 | | rt-types:route-target-type 714 | +--rw vpn-policies 715 | +--rw import-policy? string 716 | +--rw export-policy? string 717 +--rw vpn-nodes 718 +--rw vpn-node* [ne-id] 719 +--rw ne-id string 720 ... 721 +--rw vpn-targets 722 | +--rw vpn-target* [id] 723 | | +--rw id int8 724 | | +--rw route-targets* [route-target] 725 | | | +--rw route-target rt-types:route-target 726 | | +--rw route-target-type 727 | | rt-types:route-target-type 728 | +--rw vpn-policies 729 | +--rw import-policy? string 730 | +--rw export-policy? string 731 ... 733 Figure 7: Subtree Structure of Import/Export Profiles 735 7.3.3. Underlay Transport 737 The model allows to indicate a preference for the underlay transport 738 technology when activating a L3VPN service (Figure 8). This 739 preference is especially useful in networks with multiple domains and 740 NNI types. This version of the YANG module supports these options: 741 BGP, LDP, GRE, SR, SR-TE, and RSVP-TE as underlay transport 742 mechanisms. Other profiles can be defined in the future. 744 +--rw l3vpn-ntw 745 +--rw vpn-profiles 746 | ... 747 +--rw vpn-services 748 +--rw vpn-service* [vpn-id] 749 +--rw vpn-id vpn-common:vpn-id 750 + ... 751 +--rw underlay-transport 752 | +--rw type* identityref 753 +--rw vpn-nodes 754 +--rw vpn-node* [ne-id] 755 ... 757 Figure 8: Subtree Structure of the Underlying Transport 759 7.3.4. VPN Node 761 The 'vpn-node' is an abstraction that represents a set of common 762 policies applied on a given network node (tipcally, a PE) and belong 763 to one L3VPN service. In order to indicate the network nodes where 764 the 'vpn-node' applies, the 'ne-id' must be indicated. The 'vpn- 765 node' includes a parameter to indicate the network node on which it 766 is applied. In the case that the 'ne-id' points to a specific PE, 767 the 'vpn-node' will likely be mapped into a VRF in the node. 768 However, the model also allows to point to an abstract node. In this 769 case, the network controller will decide how to split the 'vpn-node' 770 into VRFs. Some 'vpn-node' parameters are listed below: 772 o local-autonomous-system: Refers to the autonomous system number 773 that is locally configured in the instance. It can be overwritten 774 for specific purposes in the CE-PE BGP session. 776 o maximum-routes: Set the maximum number of prefixes allowed in the 777 'vpn-node' instance. This value is typically set in the service 778 request. 780 o 'rd' and 'vpn-targets': For the cases the logical resources are 781 managed outside the network controller, the model allows to 782 explicitely indicate the logical resources such as Route targets 783 (RTs) and Route Distinguishers (RDs) (RT,RD). 785 o Multicast: Enable multicast traffic inside the VPN. Refer to 786 Section 7.3.4.3. 788 Under the VPN Node ('vpn-node') container, VPN Network Accesses 789 ('vpn-network-access') can be created. The VPN Network Access 790 represents the point to which sites are connected. Note that, unlike 791 in L3SM, the L3NM does not need to model the customer site, only the 792 points where the traffic from the site are received (i.e., the PE 793 side of PE-CE connections). Hence, the VPN Network access contains 794 the connectivity information between the provider's network and the 795 customer premises. The VPN profiles ('vpn-profiles') have a set of 796 routing policies than can be applied during the service creation. 798 The L3NM allows to track the status ('status') of the nodes involved 799 in a VPN service. Both operational and administrative status are 800 maintained. Mismatch between an administrative status vs. the 801 operational status can be used as trigger to detect anomalies. 803 +--rw l3vpn-ntw 804 +--rw vpn-profiles 805 | ... 806 +--rw vpn-services 807 +--rw vpn-service* [vpn-id] 808 +--rw vpn-id vpn-common:vpn-id 809 ... 810 +--rw vpn-nodes 811 +--rw vpn-node* [ne-id] 812 +--rw vpn-node-id? union 813 +--rw local-autonomous-system? inet:as-number 814 +--rw description? string 815 +--rw ne-id string 816 +--rw router-id? inet:ip-address 817 +--rw address-family? 818 | vpn-common:address-family 819 +--rw node-role? identityref 820 +--rw rd? union 821 +--rw vpn-targets 822 | +--rw vpn-target* [id] 823 | | +--rw id int8 824 | | +--rw route-targets* [route-target] 825 | | | +--rw route-target rt-types:route-target 826 | | +--rw route-target-type 827 | | rt-types:route-target-type 828 | +--rw vpn-policies 829 | +--rw import-policy? string 830 | +--rw export-policy? string 831 +--rw status 832 | +--rw admin-status 833 | | +--rw status? identityref 834 | | +--rw last-updated? yang:date-and-time 835 | +--ro oper-status 836 | +--ro status? identityref 837 | +--ro last-updated? yang:date-and-time 838 +--rw node-ie-profile? leafref 839 +--rw groups 840 | +--rw group* [group-id] 841 | +--rw group-id string 842 +--rw vpn-network-accesses 843 | +--rw vpn-network-access* [id] 844 | ... 845 +--rw maximum-routes 846 | +--rw address-family* [af] 847 | +--rw af 848 | | vpn-common:address-family 849 | +--rw maximum-routes? uint32 850 +--rw multicast {vpn-common:multicast}? 851 ... 853 Figure 9: VPN Node Subtree Structure 855 7.3.4.1. RT/RD Assignment/auto-assignment 857 For the cases the logical resources are managed outside the network 858 controller, the model allows to explicitely indicate the logical 859 resources such as Route targets (RTs) and Route Distinguishers (RDs) 860 (RT,RD). 862 Three possible behaviors are needed to fulfil the identified use 863 cases: 865 o The network controller auto-assigns logical resources (RTs, RDs). 866 This can apply for new services deployment. 868 o The Network Operator/Service orchestrator assigns explicitly the 869 RTs and RDs. This case will fit with a brownfield scenario where 870 some existing services needs to be updated by the network 871 operators. 873 o The Network Operator/Service orchestrator explicitly wants NO RT/ 874 RD to be assigned. This case will fit in VRF-Lite scenarios, CE 875 testing inside the Network or just for troubleshooting pruposes. 877 Thus a union between two yang data types are included in order to 878 support this scenarios. So, if the leaf is not created in the Yang 879 the expected behavior is the auto-assigns. If the Leaf is created 880 with a valid rd value it will be explicitly assign in the VPN Node 881 and if the leaf is created with an empty value, the RD value will not 882 be deployed in the VPN node. 884 7.3.4.2. VPN Network Access 886 A 'vpn-network-access' represents an entry point to a VPN service 887 (Figure 10). In other words, this container encloses the parameters 888 that describe the access information for the traffic that belongs to 889 a particular L3VPN. As such, every 'vpn-network-access' MUST belong 890 to one and only one 'vpn-node'. 892 A 'vpn-network-access' includes information such as the connection on 893 which the access is defined (see Section 7.3.4.2.1), the 894 encapsulation of the traffic, policies that are applied on the 895 access, etc. 897 Each 'vpn-network-access' SHOULD have a 'vpn-network-access-type' to 898 select the type of network interface to be deployed in the devices. 899 The available options are: 901 o Point-to-Point: The point-to-point type represent a direct 902 connection between the end-points. It implies the controller must 903 keep the association between a logical or physical interface on 904 the device with the 'id' of the vpn-network-access. 906 o Multipoint: This option represents a broadcast connection between 907 end-points. It implies the controller must keep the association 908 between a logical or physical interface on the device with the 909 'id' of the 'vpn-network-access'. 911 o Pseudowire: Represent a connection coming from an L2VPN service. 912 It implies the controller must keep the relationship between the 913 logical tunnels or bridges on the devices with the 'id' of the' 914 vpn-network-access'. 916 o Loopback: It represents the creation of a logical interface on the 917 devices. 919 A PNC [RFC8453] will accept VPN requests containing this construct, 920 using the enclosed data to: configure the router's interface to 921 include the parameters described at the 'vpn-network-access', include 922 the given interface into a VRF, configuring policies or schedulers 923 for processing the incoming traffic, etc. 925 ... 926 +--rw vpn-services 927 +--rw vpn-service* [vpn-id] 928 +--rw vpn-id vpn-common:vpn-id 929 + ... 930 +--rw vpn-node* [ne-id] 931 +--rw ne-id string 932 + ... 933 +--rw vpn-network-accesses 934 | +--rw vpn-network-access* [id] 935 | +--rw id 936 | | vpn-common:vpn-id 937 | +--rw port-id? 938 | | vpn-common:vpn-id 939 | +--rw description? string 940 | +--rw status 941 | | +--rw admin-enabled? boolean 942 | | +--ro oper-status? operational-type 943 | +--rw vpn-network-access-type? identityref 944 | +--rw connection 945 | | ... 946 | +--rw ip-connection 947 | | ... 948 | +--rw security 949 | | ... 950 | +--rw routing-protocols 951 | | ... 952 | +--rw service 953 | ... 954 ... 956 Figure 10: VPN Network Access Tree Structure 958 7.3.4.2.1. Connection 960 The definition of a L3VPN is commonly specified not only at the IP 961 layer, but also requires to identify parameters at the Ethernet 962 layer, such as encapsulation type (e.g., VLAN, QinQ, QinAny, VxLAN, 963 etc.). The 'connection' container represents and groups the set of 964 Layer 2 connectivity from where the traffic of the L3VPN in a 965 particular VPN Network access is coming. 967 Ethernet encapsulation description is not supported in [RFC8299]. 968 However, this parameters are mandatory to configure the PE 969 interfaces. Thus, in the L3NM, these parameters uses the connection 970 container inside the 'vpn-network-access'. This container defines 971 protocols and parameters to enable connectivity at Layer 2. 973 ... 974 +--rw vpn-services 975 +--rw vpn-service* [vpn-id] 976 +--rw vpn-id vpn-common:vpn-id 977 + ... 978 +--rw vpn-node* [ne-id] 979 +--rw ne-id string 980 + ... 981 +--rw vpn-network-accesses 982 | +--rw vpn-network-access* [id] 983 | +--rw id 984 | | vpn-common:vpn-id 985 | ... 986 | +--rw connection 987 | | +--rw encapsulation-type? identityref 988 | | +--rw logical-interface 989 | | | +--rw peer-reference? uint32 990 | | +--rw tagged-interface 991 | | | +--rw type? identityref 992 | | | +--rw dot1q-vlan-tagged 993 | | | | {vpn-common:dot1q}? 994 | | | | +--rw tag-type? identityref 995 | | | | +--rw cvlan-id? uint16 996 | | | +--rw priority-tagged 997 | | | | +--rw tag-type? identityref 998 | | | +--rw qinq {vpn-common:qinq}? 999 | | | | +--rw tag-type? identityref 1000 | | | | +--rw svlan-id uint16 1001 | | | | +--rw cvlan-id uint16 1002 | | | +--rw qinany {vpn-common:qinany}? 1003 | | | | +--rw tag-type? identityref 1004 | | | | +--rw svlan-id uint16 1005 | | | +--rw vxlan {vpn-common:vxlan}? 1006 | | | +--rw vni-id uint32 1007 | | | +--rw peer-mode? identityref 1008 | | | +--rw peer-list* [peer-ip] 1009 | | | +--rw peer-ip inet:ip-address 1010 | | +--rw bearer 1011 | | ... 1012 ... 1014 Figure 11: Encapsulation Subtree Structure 1016 Additionally, the 'bearer-reference' and the pseudowire termination 1017 are supported (see Figure 12). A site, as per [RFC4176] represents a 1018 VPN customer's location that is connected to the Service Provider 1019 network via a CE-PE link, which can access at least one VPN. The 1020 connection from the site to the Service Provider network is the 1021 bearer. Every site is associated with a list of bearers. A bearer 1022 is the layer two connections with the site. In the module it is 1023 assumed that the bearer has been allocated by the Service Provider at 1024 the service orchestration step. The bearer is associated to a 1025 network element and a port. Hence, a bearer is just a bearer- 1026 reference to allow the translation between L3SM and L3NM. 1028 ... 1029 +--rw vpn-network-accesses 1030 | +--rw vpn-network-access* [id] 1031 | +--rw id 1032 | | vpn-common:vpn-id 1033 | ... 1034 | +--rw vpn-network-access-type? identityref 1035 | +--rw connection 1036 | | ... 1037 | | +--rw bearer 1038 | | +--rw bearer-reference? string 1039 | | | {vpn-common:bearer-reference}? 1040 | | +--rw pseudowire 1041 | | | +--rw vcid? uint32 1042 | | | +--rw far-end? union 1043 | | +--rw vpls 1044 | | +--rw vcid? union 1045 | | +--rw far-end? union 1046 | ... 1048 Figure 12: Bearer Subtree Structure 1050 7.3.4.2.2. IP Connections 1052 IP connection container (Figure 13) has the parameters of the 'vpn- 1053 network-access' addressing information. The address allocated in 1054 this container would represent the PE interface address 1055 configuration. The IP connection container is designed to support 1056 both IPv4 and IPv6. It also supports three IP address assignment 1057 modes: SLAAC [RFC7527], Provider DHCP, DHCP relay, and static 1058 addressing. Only one of them is enabled for a given service. 1060 ... 1061 +--rw vpn-network-accesses 1062 | +--rw vpn-network-access* [id] 1063 | +--rw id 1064 | | vpn-common:vpn-id 1065 | ... 1066 | +--rw vpn-network-access-type? identityref 1067 | +--rw connection 1068 | | ... 1070 | +--rw ip-connection 1071 | | +--rw ipv4 {vpn-common:ipv4}? 1072 | | | +--rw address-allocation-type? 1073 | | | | identityref 1074 | | | +--rw (allocation-type)? 1075 | | | +--:(provider-dhcp) 1076 | | | | +--rw provider-address? 1077 | | | | | inet:ipv4-address 1078 | | | | +--rw prefix-length? 1079 | | | | | uint8 1080 | | | | +--rw (address-assign)? 1081 | | | | +--:(number) 1082 | | | | | +--rw number-of-dynamic-address? 1083 | | | | | uint16 1084 | | | | +--:(explicit) 1085 | | | | +--rw customer-addresses 1086 | | | | +--rw address-group* 1087 | | | | [group-id] 1088 | | | | +--rw group-id 1089 | | | | | string 1090 | | | | +--rw start-address? 1091 | | | | | inet:ipv4-address 1092 | | | | +--rw end-address? 1093 | | | | inet:ipv4-address 1094 | | | +--:(dhcp-relay) 1095 | | | | +--rw dr-provider-address? 1096 | | | | | inet:ipv4-address 1097 | | | | +--rw dr-prefix-length? 1098 | | | | | uint8 1099 | | | | +--rw customer-dhcp-servers 1100 | | | | +--rw server-ip-address* 1101 | | | | inet:ipv4-address 1102 | | | +--:(static-addresses) 1103 | | | ... 1104 | | +--rw ipv6 {vpn-common:ipv6}? 1105 | | | +--rw address-allocation-type? 1106 | | | | identityref 1107 | | | +--rw (allocation-type)? 1108 | | | +--:(provider-dhcp) 1109 | | | | +--rw (provider-dhcp)? 1110 | | | | +--:(provider-address) 1111 | | | | | +--rw provider-address? 1112 | | | | | inet:ipv6-address 1113 | | | | +--:(prefix-length) 1114 | | | | | +--rw prefix-length? 1115 | | | | | uint8 1116 | | | | +--:(address-assign) 1117 | | | | +--rw (address-assign)? 1118 | | | | +--:(number) 1119 | | | | | +--rw number-of-dynamic-address? 1120 | | | | | uint16 1121 | | | | +--:(explicit) 1122 | | | | +--rw customer-addresses 1123 | | | | +--rw address-group* 1124 | | | | [group-id] 1125 | | | | +--rw group-id 1126 | | | | | string 1127 | | | | +--rw start-address? 1128 | | | | | inet:ipv6-address 1129 | | | | +--rw end-address? 1130 | | | | inet:ipv6-address 1131 | | | +--:(dhcp-relay) 1132 | | | | +--rw dr-provider-address? 1133 | | | | | inet:ipv6-address 1134 | | | | +--rw dr-prefix-length? 1135 | | | | | uint8 1136 | | | | +--rw customer-dhcp-servers 1137 | | | | +--rw server-ip-address* 1138 | | | | inet:ipv6-address 1139 | | | +--:(static-addresses) 1140 | | | ... 1142 Figure 13: IP Connection Subtree Structure 1144 In the case of the static addressing (Figure 14), the model supports 1145 the assignment of several IP addresses in the same 'vpn-network- 1146 access'. To identify which of the addresses is the primary address 1147 of a connection ,the 'primary-address' reference MUST be set with the 1148 corresponding 'address-id'. 1150 ... 1151 +--rw vpn-network-accesses 1152 | +--rw vpn-network-access* [id] 1153 | +--rw id 1154 | | vpn-common:vpn-id 1155 | ... 1156 | +--rw vpn-network-access-type? identityref 1157 | +--rw connection 1158 | | ... 1159 | +--rw ip-connection 1160 | | +--rw ipv4 {vpn-common:ipv4}? 1161 | | | +--rw address-allocation-type? 1162 | | | | identityref 1163 | | | +--rw (allocation-type)? 1164 | | | ... 1165 | | | +--:(static-addresses) 1166 | | | +--rw primary-address? 1167 | | | | -> ../address/address-id 1168 | | | +--rw address* [address-id] 1169 | | | +--rw address-id 1170 | | | | string 1171 | | | +--rw s-provider-address? 1172 | | | | inet:ipv4-address 1173 | | | +--rw s-customer-address? 1174 | | | | inet:ipv4-address 1175 | | | +--rw s-prefix-length? 1176 | | | uint8 1177 | | +--rw ipv6 {vpn-common:ipv6}? 1178 | | | +--rw address-allocation-type? 1179 | | | | identityref 1180 | | | +--rw (allocation-type)? 1181 | | | ... 1182 | | | +--:(static-addresses) 1183 | | | +--rw s-primary-address? 1184 | | | | -> ../s-address/address-id 1185 | | | +--rw s-address* [address-id] 1186 | | | +--rw address-id 1187 | | | | string 1188 | | | +--rw provider-address? 1189 | | | | inet:ipv6-address 1190 | | | +--rw customer-address? 1191 | | | | inet:ipv6-address 1192 | | | +--rw prefix-length? uint8 1193 ... 1195 Figure 14: IP Connection Subtree Structure: Static Mode 1197 7.3.4.2.3. Security 1199 The 'security' container specifies the authentication and the 1200 encryption to be applied for a given VPN network access (Figure 15). 1202 ... 1203 +--rw vpn-network-accesses 1204 | +--rw vpn-network-access* [id] 1205 | +--rw id 1206 | | vpn-common:vpn-id 1207 | + ... 1208 | +--rw connection 1209 | | ... 1210 | +--rw ip-connection 1211 | | ... 1212 | +--rw security 1213 | | +--rw encryption {vpn-common:encryption}? 1214 | | | +--rw enabled? boolean 1215 | | | +--rw layer? enumeration 1216 | | +--rw encryption-profile 1217 | | +--rw (profile)? 1218 | | | +--:(provider-profile) 1219 | | | | +--rw profile-name? leafref 1220 | | | +--:(customer-profile) 1221 | | | +--rw algorithm? string 1222 | | +--rw (key-type)? 1223 | | +--:(psk) 1224 | | +--rw preshared-key? string 1225 | +--rw routing-protocols 1226 | | ... 1227 | +--rw service 1228 | ... 1229 | ... 1231 Figure 15: Security Subtree Structure 1233 7.3.4.2.4. CE-PE Routing Protocols 1235 The model allows the Provider to configure one or more routing 1236 protocols associated with a particular 'vpn-network-access' 1237 (Figure 16). This protocol will run between the PE and the CE. A 1238 routing protocol instance MUST have a type (e.g., bgp, ospf) and an 1239 identifier. The identifier is necessary when multiple instances of 1240 the same protocol have to be configured. 1242 ... 1243 +--rw vpn-network-accesses 1244 | +--rw vpn-network-access* [id] 1245 | +--rw id 1246 | | vpn-common:vpn-id 1247 | ... 1248 | +--rw ip-connection 1249 | | ... 1250 | +--rw routing-protocols 1251 | | +--rw routing-protocol* [id] 1252 | | +--rw id string 1253 | | +--rw type? identityref 1254 | | +--rw routing-profiles* [id] 1255 | | | +--rw id leafref 1256 | | | +--rw type? identityref 1257 | | +--rw ospf {vpn-common:rtg-ospf}? 1258 | | | ... 1259 | | +--rw bgp {vpn-common:rtg-bgp}? 1260 | | | ... 1261 | | +--rw isis {vpn-common:rtg-isis}? 1262 | | | ... 1263 | | +--rw static 1264 | | | ... 1265 | | +--rw rip {vpn-common:rtg-rip}? 1266 | | | +--rw address-family* 1267 | | | vpn-common:address-family 1268 | | +--rw vrrp {vpn-common:rtg-vrrp}? 1269 | | +--rw address-family* 1270 | | vpn-common:address-family 1271 | +--rw service 1272 | ... 1273 ... 1275 Figure 16: Routing Subtree Structure 1277 Routing configuration does not include low-level policies. These 1278 policies are low level device configurations that must not be part of 1279 an abstracted model. A provider's internal policies (such as 1280 security filters) will be implemented as part of the device 1281 configuration but does not require any input from this model. Some 1282 policies like primary/backup or load-balancing can be inferred from 1283 'access-priority'. 1285 When configuring multiple instances of the same routing protocol, 1286 this does not automatically imply that, from a device configuration 1287 perspective, there will be parallel instances (multiple processes) 1288 running. It will be up to the implementation to use the most 1289 appropriate deployment model. As an example, when multiple BGP peers 1290 need to be implemented, multiple instances of BGP must be configured 1291 as part of this model. However, from a device configuration point of 1292 view, this could be implemented as: 1294 o Multiple BGP processes with a single neighbor running in each 1295 process. 1297 o A single BGP process with multiple neighbors running. 1299 o A combination of both. 1301 To be aligned with [RFC8299], this model supports the following CE-PE 1302 routing protocols: 1304 o OSPF: The model (Figure 17) allows the user to configure OSPF to 1305 run as routing protocol on the 'vpn-network-access interface'. An 1306 OSPF instance can be bound to IPv4, IPv6 or both. When only IPv4 1307 address-family is requested, it will be up to the implementation 1308 to drive whether OSPFv2 or OSPFv3 is used. 1310 ... 1311 +--rw vpn-network-accesses 1312 | +--rw vpn-network-access* [id] 1313 | +--rw id 1314 | | vpn-common:vpn-id 1315 | ... 1316 | +--rw ip-connection 1317 | | ... 1318 | +--rw routing-protocols 1319 | | +--rw routing-protocol* [id] 1320 | | +--rw id string 1321 | | +--rw type? identityref 1322 | | +--rw routing-profiles* [id] 1323 | | | +--rw id leafref 1324 | | | +--rw type? identityref 1325 | | +--rw ospf {vpn-common:rtg-ospf}? 1326 | | | +--rw address-family* 1327 | | | | vpn-common:address-family 1328 | | | +--rw area-address 1329 | | | | yang:dotted-quad 1330 | | | +--rw metric? uint16 1331 | | | +--rw mtu? uint16 1332 | | | +--rw process-id? uint16 1333 | | | +--rw security 1334 | | | | +--rw auth-key? string 1335 | | | +--rw sham-links 1336 | | | {vpn-common:rtg-ospf-sham-link}? 1337 | | | +--rw sham-link* [target-site] 1338 | | | +--rw target-site 1339 | | | | vpn-common:vpn-id 1340 | | | +--rw metric? uint16 1341 | | +--rw bgp {vpn-common:rtg-bgp}? 1342 | | | ... 1343 | | +--rw isis {vpn-common:rtg-isis}? 1344 | | | ... 1345 | | +--rw static 1346 | | | ... 1347 | | +--rw rip {vpn-common:rtg-rip}? 1348 | | | ... 1349 | | +--rw vrrp {vpn-common:rtg-vrrp}? 1350 | | ... 1351 | +--rw service 1352 | ... 1353 ... 1355 Figure 17: OPSF Routing Subtree Structure 1357 o BGP: The model (Figure 18) allows to configure a BGP neighbor, 1358 including a set for parameters that are pertinent to be tweaked at 1359 the network level for service customization purposes. This 1360 container does not aim to include every BGP parameter; a 1361 comprehensive set of parameters belongs more to the BGP device 1362 model. The following parameters are captured in Figure 18. It is 1363 up to the implementation to drive the corresponding BGP device 1364 configuration. 1366 * 'peer-autonomous-system': This parameter conveys the Customer's 1367 AS Number (ASN). 1369 * 'local-autonomous-system': This parameter is set of AS override 1370 is activated for this peer. 1372 * 'address-family': This attribute indicates the address-family 1373 of the peer. It can be set to IPv4, IPv6, or both address- 1374 families. 1376 * 'neighbor': The module supports supplying two neighbors (each 1377 for a given address-family) or one neighbor (if 'address- 1378 family' attribute is set to both IPv4 and IPv6 address- 1379 families). A list of IP address(es) of the BGP neighbor can be 1380 then conveyed in this parameter. 1382 * 'multihop': This attribute indicates the number of allowed IP 1383 hops between a BGP peer and a PE. 1385 * 'security': The authentication type will be driven by the 1386 implementation but the module supports any authentication that 1387 uses a key as a parameter. 1389 * 'as-override': If set, this parameter indicates whether AS 1390 override is enabled, i.e., replace the ASN of the peer 1391 specified in the AS Path attribute with the ASN identified by 1392 the 'local-autonomous-system' attribute. 1394 * 'default-route': This attribute controls whether default 1395 route(s) can be advertised to the peer. 1397 * 'bgp-max-prefix': This attribute is used to control how many 1398 prefixes can be received from a neighbor. If reached, the BGP 1399 session will be teared down. 1401 * 'bgp-timer': Two timers can be captured in this container: (1) 1402 'hold-time' which is the time interval that will be used for 1403 the HoldTimer (Section 4.2 of [RFC4271]) when establishing a 1404 BGP session. (2) 'keep-alive' which is the time interval for 1405 the KeepAlive timer between a PE and a BGP peer (Section 4.4 of 1406 [RFC4271]). 1408 ... 1409 +--rw vpn-network-accesses 1410 | +--rw vpn-network-access* [id] 1411 | +--rw id 1412 | | vpn-common:vpn-id 1413 | ... 1414 | +--rw ip-connection 1415 | | ... 1416 | +--rw routing-protocols 1417 | | +--rw routing-protocol* [id] 1418 | | +--rw id string 1419 | | +--rw type? identityref 1420 | | +--rw routing-profiles* [id] 1421 | | | +--rw id leafref 1422 | | | +--rw type? identityref 1423 | | +--rw ospf {vpn-common:rtg-ospf}? 1424 | | | ... 1425 | | +--rw bgp {vpn-common:rtg-bgp}? 1426 | | | +--rw peer-autonomous-system 1427 | | | | inet:as-number 1428 | | | +--rw local-autonomous-system? 1429 | | | | inet:as-number 1430 | | | +--rw address-family* 1431 | | | | vpn-common:address-family 1432 | | | +--rw neighbor* 1433 | | | | inet:ip-address 1434 | | | +--rw multihop? uint8 1435 | | | +--rw security 1436 | | | | +--rw auth-key? string 1437 | | | +--rw status 1438 | | | | +--rw admin-status 1439 | | | | | +--rw status? identityref 1440 | | | | | +--rw last-updated? 1441 | | | | | | yang:date-and-time 1442 | | | | +--ro oper-status 1443 | | | | +--ro status? identityref 1444 | | | | +--ro last-updated? 1445 | | | | yang:date-and-time 1446 | | | +--rw description? string 1447 | | | +--rw as-override? boolean 1448 | | | +--rw default-route? boolean 1449 | | | +--rw bgp-max-prefix 1450 | | | | +--rw max-prefix? uint32 1451 | | | | +--rw warning-threshold? decimal64 1452 | | | | +--rw violate-action? enumeration 1453 | | | | +--rw restart-interval? uint16 1454 | | | +--rw bgp-timer 1455 | | | +--rw keep-alive? uint16 1456 | | | +--rw hold-time? uint16 1457 | | +--rw isis {vpn-common:rtg-isis}? 1458 | | | ... 1459 | | +--rw static 1460 | | | ... 1461 | | +--rw rip {vpn-common:rtg-rip}? 1462 | | | ... 1463 | | +--rw vrrp {vpn-common:rtg-vrrp}? 1464 | | ... 1465 | +--rw service 1466 | ... 1467 ... 1469 Figure 18: BGP Routing Subtree Structure 1471 o IS-IS: The model (Figure 19) allows the user to configure IS-IS to 1472 run on the 'vpn-network-access' interface. An IS-IS instance can 1473 run L1, L2, or both levels. 1475 ... 1476 +--rw vpn-network-accesses 1477 | +--rw vpn-network-access* [id] 1478 | +--rw id 1479 | | vpn-common:vpn-id 1480 | ... 1481 | +--rw ip-connection 1482 | | ... 1483 | +--rw routing-protocols 1484 | | +--rw routing-protocol* [id] 1485 | | +--rw id string 1486 | | +--rw type? 1487 | | | identityref 1488 | | +--rw routing-profiles* [id] 1489 | | | +--rw id leafref 1490 | | | +--rw type? identityref 1491 | | +--rw ospf {vpn-common:rtg-ospf}? 1492 | | | ... 1493 | | +--rw bgp {vpn-common:rtg-bgp}? 1494 | | | ... 1495 | | +--rw isis {vpn-common:rtg-isis}? 1496 | | | +--rw address-family* 1497 | | | | vpn-common:address-family 1498 | | | +--rw area-address 1499 | | | | yang:dotted-quad 1500 | | | +--rw level? identityref 1501 | | | +--rw metric? uint16 1502 | | | +--rw process-id? uint16 1503 | | | +--rw mode? enumeration 1504 | | | +--rw status 1505 | | | +--rw admin-status 1506 | | | | +--rw status? 1507 | | | | | identityref 1508 | | | | +--rw last-updated? 1509 | | | | yang:date-and-time 1510 | | | +--ro oper-status 1511 | | | +--ro status? 1512 | | | | identityref 1513 | | | +--ro last-updated? 1514 | | | yang:date-and-time 1515 | | +--rw static 1516 | | | ... 1517 | | +--rw rip {vpn-common:rtg-rip}? 1518 | | | ... 1519 | | +--rw vrrp {vpn-common:rtg-vrrp}? 1520 | | ... 1521 | +--rw service 1522 | ... 1523 ... 1525 Figure 19: IS-IS Routing Subtree Structure 1527 o RIP: The module covers only a list of address-family as parameter. 1529 o VRRP: The module covers only a list of address-family as 1530 parameter. 1532 The module allows a user to configure one or more IPv4 and/or IPv6 1533 static routes as depicted in Figure 20. 1535 ... 1536 +--rw vpn-network-accesses 1537 | +--rw vpn-network-access* [id] 1538 | +--rw id 1539 | | vpn-common:vpn-id 1540 | ... 1541 | +--rw ip-connection 1542 | | ... 1543 | +--rw routing-protocols 1544 | | +--rw routing-protocol* [id] 1545 | | +--rw id string 1546 | | +--rw type? identityref 1547 | | +--rw routing-profiles* [id] 1548 | | | +--rw id leafref 1549 | | | +--rw type? identityref 1550 | | +--rw ospf {vpn-common:rtg-ospf}? 1551 | | | ... 1552 | | +--rw bgp {vpn-common:rtg-bgp}? 1553 | | | ... 1554 | | +--rw isis {vpn-common:rtg-isis}? 1555 | | | ... 1556 | | +--rw static 1557 | | | +--rw cascaded-lan-prefixes 1558 | | | +--rw ipv4-lan-prefixes* 1559 | | | | [lan next-hop] 1560 | | | | {vpn-common:ipv4}? 1561 | | | | +--rw lan 1562 | | | | | inet:ipv4-prefix 1563 | | | | +--rw lan-tag? string 1564 | | | | +--rw next-hop 1565 | | | | inet:ipv4-address 1566 | | | +--rw ipv6-lan-prefixes* 1567 | | | [lan next-hop] 1568 | | | {vpn-common:ipv6}? 1569 | | | +--rw lan 1570 | | | | inet:ipv6-prefix 1571 | | | +--rw lan-tag? string 1572 | | | +--rw next-hop 1573 | | | inet:ipv6-address 1574 | | +--rw rip {vpn-common:rtg-rip}? 1575 | | | ... 1576 | | +--rw vrrp {vpn-common:rtg-vrrp}? 1577 | | ... 1578 | +--rw service 1579 | ... 1580 ... 1582 Figure 20: Static Routing Subtree Structure 1584 7.3.4.2.5. Services 1586 The 'services' container specifies the service parameters to apply 1587 for a given VPN network access (Figure 21). 1589 ... 1590 +--rw vpn-network-accesses 1591 | +--rw vpn-network-access* [id] 1592 | +--rw id 1593 | | vpn-common:vpn-id 1594 | ... 1595 | +--rw service 1596 | +--rw svc-input-bandwidth uint64 1597 | +--rw svc-output-bandwidth uint64 1598 | +--rw svc-mtu uint16 1599 | +--rw qos {vpn-common:qos}? 1600 | | +--rw qos-classification-policy 1601 | | | +--rw rule* [id] 1602 | | | +--rw id 1603 | | | | string 1604 | | | +--rw (match-type)? 1605 | | | | +--:(match-flow) 1606 | | | | | +--rw (l3)? 1607 | | | | | | +--:(ipv4) 1608 | | | | | | | ... 1609 | | | | | | +--:(ipv6) 1610 | | | | | | ... 1611 | | | | | +--rw (l4)? 1612 | | | | | +--:(tcp) 1613 | | | | | | ... 1614 | | | | | +--:(udp) 1615 | | | | | ... 1616 | | | | +--:(match-application) 1617 | | | | +--rw match-application? 1618 | | | | identityref 1619 | | | +--rw target-class-id? 1620 | | | string 1621 | | +--rw qos-profile 1622 | | +--rw qos-profile* [profile] 1623 | | +--rw profile leafref 1624 | | +--rw direction? identityref 1625 | +--rw carrierscarrier 1626 | | {vpn-common:carrierscarrier}? 1627 | | +--rw signalling-type? enumeration 1628 | +--rw multicast {vpn-common:multicast}? 1629 | +--rw site-type? enumeration 1630 | +--rw address-family? 1631 | | vpn-common:address-family 1632 | +--rw protocol-type? enumeration 1633 | +--rw remote-source? boolean 1634 ... 1636 Figure 21: Services Subtree Structure 1638 The following attributes are defined: 1640 o 'svc-input-bandwidth': Indicates the inbound bandwidth of the 1641 connection (i.e., download bandwidth from the SP to the site). 1643 o 'svc-output-bandwidth': Indicates the outbound bandwidth of the 1644 connection (i.e., upload bandwidth from the site to the SP). 1646 o 'svc-mtu': Indicates the MTU at service level. It can be the IP 1647 MTU or MPLS MTU, for example. 1649 o 'carrierscarrier': Groups a set of parameters that are used when 1650 CsC is enabled such the use of BGP for signalling purposes 1651 [RFC8277]. 1653 o 'multicast': Specifies the multicast mode and other service- 1654 related attributes such as the address-family. 1656 o 'qos': Is used to define QoS policies to apply on a given 1657 connection. Classification can be based on many criteria such as: 1659 * Layer 3: As shown in Figure 23, the model allow to classify 1660 based on any IP header field or a combination thereof. Both 1661 IPv4 and IPv6 are supported. 1663 +--rw qos {vpn-common:qos}? 1664 | +--rw qos-classification-policy 1665 | | +--rw rule* [id] 1666 | | +--rw id 1667 | | | string 1668 | | +--rw (match-type)? 1669 | | | +--:(match-flow) 1670 | | | | +--rw (l3)? 1671 | | | | | +--:(ipv4) 1672 | | | | | | ... 1673 | | | | | +--:(ipv6) 1674 | | | | | ... 1675 | | | | +--rw (l4)? 1676 | | | | +--rw (l3)? 1677 | | | | | +--:(ipv4) 1678 | | | | | | +--rw ipv4 1679 | | | | | | +--rw dscp? 1680 | | | | | | | inet:dscp 1681 | | | | | | +--rw ecn? 1682 | | | | | | | uint8 1683 | | | | | | +--rw length? 1684 | | | | | | | uint16 1685 | | | | | | +--rw ttl? 1686 | | | | | | | uint8 1687 | | | | | | +--rw protocol? 1688 | | | | | | | uint8 1689 | | | | | | +--rw ihl? 1690 | | | | | | | uint8 1691 | | | | | | +--rw flags? 1692 | | | | | | | bits 1693 | | | | | | +--rw offset? 1694 | | | | | | | uint16 1695 | | | | | | +--rw identification? 1696 | | | | | | | uint16 1697 | | | | | | +--rw (destination-network)? 1698 | | | | | | | +--:(destination-ipv4-network) 1699 | | | | | | | +--rw destination-ipv4-network? 1700 | | | | | | | inet:ipv4-prefix 1701 | | | | | | +--rw (source-network)? 1702 | | | | | | +--:(source-ipv4-network) 1703 | | | | | | +--rw source-ipv4-network? 1704 | | | | | | inet:ipv4-prefix 1705 | | | | | +--:(ipv6) 1706 | | | | | +--rw ipv6 1707 | | | | | +--rw dscp? 1708 | | | | | | inet:dscp 1709 | | | | | +--rw ecn? 1710 | | | | | | uint8 1711 | | | | | +--rw length? 1712 | | | | | | uint16 1713 | | | | | +--rw ttl? 1714 | | | | | | uint8 1715 | | | | | +--rw protocol? 1716 | | | | | | uint8 1717 | | | | | +--rw (destination-network)? 1718 | | | | | | +--:(destination-ipv6-network) 1719 | | | | | | +--rw destination-ipv6-network? 1720 | | | | | | inet:ipv6-prefix 1721 | | | | | +--rw (source-network)? 1722 | | | | | | +--:(source-ipv6-network) 1723 | | | | | | +--rw source-ipv6-network? 1724 | | | | | | inet:ipv6-prefix 1725 | | | | | +--rw flow-label? 1726 | | | | | inet:ipv6-flow-label 1727 | | | | +--rw (l4)? 1728 | | | | +--:(tcp) 1729 | | | | | ... 1730 | | | | +--:(udp) 1731 | | | | ... 1732 ... 1734 Figure 22: QoS Subtree Structure (L3) 1736 * Layer 4: As shown in Figure 23, TCP or UDP-related match 1737 crietria can be specified. 1739 +--rw qos {vpn-common:qos}? 1740 | +--rw qos-classification-policy 1741 | | +--rw rule* [id] 1742 | | +--rw id 1743 | | | string 1744 | | +--rw (match-type)? 1745 | | | +--:(match-flow) 1746 | | | | +--rw (l3)? 1747 | | | | | +--:(ipv4) 1748 | | | | | | ... 1749 | | | | | +--:(ipv6) 1750 | | | | | ... 1751 | | | | +--rw (l4)? 1752 | | | | +--:(tcp) 1753 | | | | | +--rw tcp 1754 | | | | | +--rw sequence-number? 1755 | | | | | | uint32 1756 | | | | | +--rw acknowledgement-number? 1757 | | | | | | uint32 1758 | | | | | +--rw data-offset? 1759 | | | | | | uint8 1760 | | | | | +--rw reserved? 1761 | | | | | | uint8 1762 | | | | | +--rw flags? 1763 | | | | | | bits 1764 | | | | | +--rw window-size? 1765 | | | | | | uint16 1766 | | | | | +--rw urgent-pointer? 1767 | | | | | | uint16 1768 | | | | | +--rw options? 1769 | | | | | | binary 1770 | | | | | +--rw (source-port)? 1771 | | | | | | +--:(source-port-range-or-operator) 1772 | | | | | | +--rw source-port-range-or-operator 1773 | | | | | | +--rw (port-range-or-operator)? 1774 | | | | | | +--:(range) 1775 | | | | | | | +--rw lower-port 1776 | | | | | | | | inet:port-number 1777 | | | | | | | +--rw upper-port 1778 | | | | | | | inet:port-number 1779 | | | | | | +--:(operator) 1780 | | | | | | +--rw operator? 1781 | | | | | | | operator 1782 | | | | | | +--rw port 1783 | | | | | | inet:port-number 1784 | | | | | +--rw (destination-port)? 1785 | | | | +--:(destination-port-range-or-operator) 1786 | | | | | +--rw destination-port-range-or-operator 1787 | | | | | +--rw (port-range-or-operator)? 1788 | | | | | +--:(range) 1789 | | | | | | +--rw lower-port 1790 | | | | | | | inet:port-number 1791 | | | | | | +--rw upper-port 1792 | | | | | | inet:port-number 1793 | | | | | +--:(operator) 1794 | | | | | +--rw operator? 1795 | | | | | | operator 1796 | | | | | +--rw port 1797 | | | | | inet:port-number 1798 | | | | +--:(udp) 1799 | | | | +--rw udp 1800 | | | | +--rw length? 1801 | | | | | uint16 1802 | | | | +--rw (source-port)? 1803 | | | | | +--:(source-port-range-or-operator) 1804 | | | | | +--rw source-port-range-or-operator 1805 | | | | | +--rw (port-range-or-operator)? 1806 | | | | | +--:(range) 1807 | | | | | | +--rw lower-port 1808 | | | | | | | inet:port-number 1809 | | | | | | +--rw upper-port 1810 | | | | | | inet:port-number 1811 | | | | | +--:(operator) 1812 | | | | | +--rw operator? 1813 | | | | | | operator 1814 | | | | | +--rw port 1815 | | | | | inet:port-number 1816 | | | | +--rw (destination-port)? 1817 | | | | +--:(destination-port-range-or-operator) 1818 | | | | +--rw destination-port-range-or-operator 1819 | | | | +--rw (port-range-or-operator)? 1820 | | | | +--:(range) 1821 | | | | | +--rw lower-port 1822 | | | | | | inet:port-number 1823 | | | | | +--rw upper-port 1824 | | | | | inet:port-number 1825 | | | | +--:(operator) 1826 | | | | +--rw operator? 1827 | | | | | operator 1828 | | | | +--rw port 1829 | | | | inet:port-number 1830 ... 1832 Figure 23: QoS Subtree Structure (L4) 1834 * Application match 1836 7.3.4.3. Multicast 1838 Multicast MAY be enabled for a particular vpn-network-node (see 1839 Figure 24). 1841 The model supports a single type of tree (Any-Source Multicast (ASM), 1842 Source-Specific Multicast (SSM), or bidirectional). 1844 When ASM is used, the model supports the configuration of rendez-vous 1845 points (RPs). RP discovery may be 'static', 'bsr-rp', or 'auto-rp'. 1846 When set to 'static', RP to multicast grouping mapping MUST be 1847 configured as part of the 'rp-group-mappings' container. The RP MAY 1848 be a provider node or a customer node. When the RP is a customer 1849 node, the RP address must be configured using the 'rp-address' leaf 1850 otherwise no RP address is needed. 1852 The model supports RP redundancy through the 'rp-redundancy' leaf. 1853 How the redundancy is achieved is out of scope and is up to the 1854 implementation. 1856 When a particular VPN using ASM requires a more optimal traffic 1857 delivery, 'optimal-traffic-delivery' can be set. When set to 'true', 1858 the implementation must use any mechanism to provide a more optimal 1859 traffic delivery for the customer. Anycast is one of the mechanisms 1860 to enhance RPs redundancy, resilience against failures, and to 1861 recover from failures quickly. 1863 For redundancy purposes, Multicast Source Discovery Protocol (MSDP) 1864 [RFC3618] may be enabled and used to share the state about sources 1865 between multiple RPs. The purpose of MSDP in this context is to 1866 enhance the robustness of the multicast service. MSDP may be 1867 configured on Non-RP routers, which is useful in a domain that does 1868 not support multicast sources, but does support multicast transit. 1870 ... 1871 +--rw vpn-network-accesses 1872 | +--rw vpn-network-access* [id] 1873 | +--rw id 1874 | .. 1875 +--rw multicast {vpn-common:multicast}? 1876 +--rw enabled? boolean 1877 +--rw tree-flavor* identityref 1878 +--rw rp 1879 | +--rw rp-group-mappings 1880 | | +--rw rp-group-mapping* [id] 1881 | | +--rw id uint16 1882 | | +--rw provider-managed 1883 | | | +--rw enabled? 1884 | | | | boolean 1885 | | | +--rw rp-redundancy? 1886 | | | | boolean 1887 | | | +--rw optimal-traffic-delivery? 1888 | | | | boolean 1889 | | | +--rw anycast 1890 | | | +--rw local-address? 1891 | | | | inet:ip-address 1892 | | | +--rw rp-set-address* 1893 | | | inet:ip-address 1894 | | +--rw rp-address 1895 | | | inet:ip-address 1896 | | +--rw groups 1897 | | +--rw group* [id] 1898 | | +--rw id 1899 | | | uint16 1900 | | +--rw (group-format) 1901 | | +--:(group-prefix) 1902 | | | +--rw group-address? 1903 | | | inet:ip-prefix 1904 | | +--:(startend) 1905 | | +--rw group-start? 1906 | | | inet:ip-address 1907 | | +--rw group-end? 1908 | | inet:ip-address 1909 | +--rw rp-discovery 1910 | +--rw rp-discovery-type? identityref 1911 | +--rw bsr-candidates 1912 | +--rw bsr-candidate-address* 1913 | inet:ip-address 1914 +--rw msdp {msdp}? 1915 +--rw enabled? boolean 1916 +--rw peer? inet:ip-address 1917 +--rw local-address? inet:ip-address 1919 Figure 24: Multicast Subtree Structure 1921 8. Layer 3 Network Model 1923 This module uses types defined in [RFC6991] and groupings defined in 1924 [RFC8519]. 1926 file "ietf-l3vpn-ntw@2020-10-16.yang" 1927 module ietf-l3vpn-ntw { 1928 yang-version 1.1; 1929 namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw"; 1930 prefix l3nm; 1932 import ietf-vpn-common { 1933 prefix vpn-common; 1934 reference 1935 "RFC UUUU: A Layer 2/3 VPN Common YANG Model"; 1936 } 1937 import ietf-inet-types { 1938 prefix inet; 1939 reference 1940 "Section 4 of RFC 6991"; 1941 } 1942 import ietf-yang-types { 1943 prefix yang; 1944 reference 1945 "Section 3 of RFC 6991"; 1946 } 1947 import ietf-packet-fields { 1948 prefix pf; 1949 reference 1950 "RFC 8519: YANG Data Model for Network Access 1951 Control Lists (ACLs)"; 1952 } 1954 organization 1955 "IETF OPSA (Operations and Management Area) Working Group "; 1956 contact 1957 "WG Web: 1958 WG List: 1959 Editor: Samier Barguil 1960 1961 Editor: Oscar Gonzalez de Dios 1962 1963 Editor: Mohamed Boucadair 1964 1965 Author: Luis Angel Munoz 1966 1967 Author: Alejandro Aguado 1968 1969 "; 1970 description 1971 "This YANG module defines a generic network-oriented model 1972 for the configuration of Layer 3 Virtual Private Networks. 1974 Copyright (c) 2020 IETF Trust and the persons identified as 1975 authors of the code. All rights reserved. 1977 Redistribution and use in source and binary forms, with or 1978 without modification, is permitted pursuant to, and subject to 1979 the license terms contained in, the Simplified BSD License set 1980 forth in Section 4.c of the IETF Trust's Legal Provisions 1981 Relating to IETF Documents 1982 (https://trustee.ietf.org/license-info). 1984 This version of this YANG module is part of RFC XXXX 1985 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 1986 for full legal notices."; 1988 revision 2020-10-16 { 1989 description 1990 "Initial revision."; 1991 reference 1992 "RFC XXXX: A Layer 3 VPN Network YANG Model"; 1993 } 1995 /* Features */ 1997 feature msdp { 1998 description 1999 "This feature indicates that Multicast Source 2000 Discovery Protocol (MSDP) capabilities are 2001 supported by the VPN."; 2002 reference 2003 "RFC 3618: Multicast Source Discovery Protocol (MSDP)"; 2004 } 2006 /* Typedefs */ 2008 typedef area-address { 2009 type string { 2010 pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}'; 2011 } 2012 description 2013 "This type defines the area address format."; 2014 } 2016 /* Identities */ 2018 identity address-allocation-type { 2019 description 2020 "Base identity for address-allocation-type for 2021 PE-CE link."; 2023 } 2025 identity provider-dhcp { 2026 base address-allocation-type; 2027 description 2028 "The Provider's network provides a DHCP service 2029 to the customer."; 2030 } 2032 identity provider-dhcp-relay { 2033 base address-allocation-type; 2034 description 2035 "The Provider's network provides a DHCP relay service 2036 to the customer."; 2037 } 2039 identity provider-dhcp-slaac { 2040 base address-allocation-type; 2041 description 2042 "The Provider's network provides a DHCP service to 2043 the customer, as well as IPv6 Stateless Address 2044 Autoconfiguration (SLAAC)."; 2045 reference 2046 "RFC 7527: IPv6 Stateless Address Autoconfiguration"; 2047 } 2049 identity static-address { 2050 base address-allocation-type; 2051 description 2052 "The Provider-to-customer addressing is static."; 2053 } 2055 identity slaac { 2056 base address-allocation-type; 2057 description 2058 "Use IPv6 SLAAC."; 2059 reference 2060 "RFC 7527: IPv6 Stateless Address Autoconfiguration"; 2061 } 2063 identity isis-level { 2064 description 2065 "Defines the IS-IS level for interface 2066 and system."; 2067 } 2069 identity level1 { 2070 base isis-level; 2071 description 2072 "IS-IS level 1."; 2073 } 2075 identity level2 { 2076 base isis-level; 2077 description 2078 "IS-IS level 2."; 2079 } 2081 identity level1-2 { 2082 base isis-level; 2083 description 2084 "IS-IS levels 1 and 2."; 2085 } 2087 identity bearer-inf-type { 2088 description 2089 "Identity for the bearer interface type."; 2090 } 2092 identity port-id { 2093 base bearer-inf-type; 2094 description 2095 "Identity for the priority-tagged interface."; 2096 } 2098 identity lag-id { 2099 base bearer-inf-type; 2100 description 2101 "Identity for the lag-tagged interface."; 2102 } 2104 /* Groupings */ 2106 grouping security-params { 2107 container security { 2108 leaf auth-key { 2109 type string; 2110 description 2111 "MD5 authentication password for the connection 2112 towards the customer edge."; 2113 } 2114 description 2115 "Container for aggregating any security parameter 2116 for routing sessions between a PE and a CE."; 2117 } 2118 description 2119 "Grouping to define a set of security parameters"; 2120 } 2122 grouping ports { 2123 choice source-port { 2124 container source-port-range-or-operator { 2125 uses pf:port-range-or-operator; 2126 description 2127 "Source port definition."; 2128 } 2129 description 2130 "Choice of specifying the source port or 2131 referring to a group of source port numbers."; 2132 } 2133 choice destination-port { 2134 container destination-port-range-or-operator { 2135 uses pf:port-range-or-operator; 2136 description 2137 "Destination port definition."; 2138 } 2139 description 2140 "Choice of specifying a destination port or 2141 referring to a group of destination port 2142 numbers."; 2143 } 2144 description 2145 "Choice of specifying a source or destination 2146 port numbers."; 2147 } 2149 /* Main Blocks */ 2150 /* Main l3nm */ 2152 container l3vpn-ntw { 2153 container vpn-profiles { 2154 uses vpn-common:vpn-profile-cfg; 2155 description 2156 "Contains a set of valid VPN Profiles to 2157 reference in the VPN service."; 2158 } 2159 container vpn-services { 2160 list vpn-service { 2161 key "vpn-id"; 2162 uses vpn-common:service-status; 2163 uses vpn-common:vpn-description; 2164 leaf l3sm-vpn-id { 2165 type vpn-common:vpn-id; 2166 description 2167 "Pointer to the parent L3SM service, 2168 if any."; 2169 } 2170 leaf vpn-type { 2171 type identityref { 2172 base vpn-common:vpn-signaling-type; 2173 } 2174 description 2175 "Indicates the service type"; 2176 } 2177 leaf vpn-service-topology { 2178 type identityref { 2179 base vpn-common:vpn-topology; 2180 } 2181 default "vpn-common:any-to-any"; 2182 description 2183 "VPN service topology."; 2184 } 2185 container ie-profiles { 2186 list ie-profile { 2187 key "ie-profile-id"; 2188 leaf ie-profile-id { 2189 type string; 2190 description 2191 "IE profile id."; 2192 } 2193 uses vpn-common:rt-rd; 2194 description 2195 "List for Imort/Export profile."; 2196 } 2197 description 2198 "Container for Import/Export profiles."; 2199 } 2200 uses vpn-common:svc-transport-encapsulation; 2201 container vpn-nodes { 2202 description 2203 "Container for VPN nodes."; 2204 list vpn-node { 2205 key "vpn-node-id"; 2206 leaf vpn-node-id { 2207 type union { 2208 type vpn-common:vpn-id; 2209 type uint32; 2210 } 2211 description 2212 "Type STRING or NUMBER Service-Id."; 2213 } 2214 leaf local-autonomous-system { 2215 type inet:as-number; 2216 description 2217 "Provider's AS number in case the customer 2218 requests BGP routing."; 2219 } 2220 leaf description { 2221 type string; 2222 description 2223 "Textual description of the VPN node."; 2224 } 2225 leaf ne-id { 2226 type string; 2227 description 2228 "Unique identifier of the network element 2229 where the VPN node is deployed."; 2230 } 2231 leaf router-id { 2232 type inet:ip-address; 2233 description 2234 "The router-id information can be an IPv4 2235 or IPv6 address."; 2236 } 2237 leaf address-family { 2238 type vpn-common:address-family; 2239 description 2240 "The address family used for router-id 2241 information."; 2242 } 2243 leaf node-role { 2244 type identityref { 2245 base vpn-common:role; 2246 } 2247 default "vpn-common:any-to-any-role"; 2248 description 2249 "Role of the VPN node in the IP VPN."; 2250 } 2251 uses vpn-common:rt-rd; 2252 uses vpn-common:service-status; 2253 leaf node-ie-profile { 2254 type leafref { 2255 path "/l3vpn-ntw/vpn-services/" 2256 + "vpn-service/ie-profiles/" 2257 + "ie-profile/ie-profile-id"; 2258 } 2259 description 2260 "Node's Import/Export profile."; 2261 } 2262 uses vpn-common:vpn-node-group; 2263 container vpn-network-accesses { 2264 list vpn-network-access { 2265 key "id"; 2266 leaf id { 2267 type vpn-common:vpn-id; 2268 description 2269 "Identifier for the access."; 2270 } 2271 leaf port-id { 2272 type vpn-common:vpn-id; 2273 description 2274 "Identifier for the network access."; 2275 } 2276 leaf description { 2277 type string; 2278 description 2279 "Textual description of a network access."; 2280 } 2281 uses vpn-common:service-status; 2282 leaf vpn-network-access-type { 2283 type identityref { 2284 base vpn-common:site-network-access-type; 2285 } 2286 default "vpn-common:point-to-point"; 2287 description 2288 "Describes the type of connection, e.g., 2289 point-to-point or multipoint."; 2290 } 2291 container connection { 2292 leaf encapsulation-type { 2293 type identityref { 2294 base vpn-common:encapsulation-type; 2295 } 2296 default "vpn-common:untagged-int"; 2297 description 2298 "Encapsulation type. By default, 2299 the encapsulation type is set to 2300 'untagged'."; 2301 } 2302 container logical-interface { 2303 leaf peer-reference { 2304 type uint32; 2305 description 2306 "Specify the associated logical peer 2307 interface"; 2308 } 2309 description 2310 "Reference of a logical interface 2311 type."; 2312 } 2313 container tagged-interface { 2314 leaf type { 2315 type identityref { 2316 base vpn-common:encapsulation-type; 2317 } 2318 default "vpn-common:priority-tagged"; 2319 description 2320 "Tagged interface type. By default, 2321 the type of the tagged interface is 2322 'priority-tagged'."; 2323 } 2324 container dot1q-vlan-tagged { 2325 when "derived-from-or-self(../type, " 2326 + "'vpn-common:dot1q')" { 2327 description 2328 "Only applies when the type of the 2329 tagged interface is 'dot1q'."; 2330 } 2331 if-feature "vpn-common:dot1q"; 2332 leaf tag-type { 2333 type identityref { 2334 base vpn-common:tag-type; 2335 } 2336 default "vpn-common:c-vlan"; 2337 description 2338 "Tag type. By default, the tag 2339 type is 'c-vlan'."; 2340 } 2341 leaf cvlan-id { 2342 type uint16; 2343 description 2344 "VLAN identifier."; 2345 } 2346 description 2347 "Tagged interface."; 2348 } 2349 container priority-tagged { 2350 when "derived-from-or-self(../type, " 2351 + "'vpn-common:priority-tagged')" { 2352 description 2353 "Only applies when the type of the 2354 tagged interface is 2355 'priority-tagged'."; 2356 } 2357 leaf tag-type { 2358 type identityref { 2359 base vpn-common:tag-type; 2360 } 2361 default "vpn-common:c-vlan"; 2362 description 2363 "Tag type. By default, the tag 2364 type is 'c-vlan'."; 2365 } 2366 description 2367 "Priority tagged."; 2368 } 2369 container qinq { 2370 when "derived-from-or-self(../type, " 2371 + "'vpn-common:qinq')" { 2372 description 2373 "Only applies when the type of 2374 the tagged interface is 'qinq'."; 2375 } 2376 if-feature "vpn-common:qinq"; 2377 leaf tag-type { 2378 type identityref { 2379 base vpn-common:tag-type; 2380 } 2381 default "vpn-common:c-s-vlan"; 2382 description 2383 "Tag type. By default, the tag 2384 type is 'c-s-vlan'."; 2385 } 2386 leaf svlan-id { 2387 type uint16; 2388 mandatory true; 2389 description 2390 "SVLAN identifier."; 2391 } 2392 leaf cvlan-id { 2393 type uint16; 2394 mandatory true; 2395 description 2396 "CVLAN identifier."; 2397 } 2398 description 2399 "QinQ."; 2400 } 2401 container qinany { 2402 when "derived-from-or-self(../type, " 2403 + "'vpn-common:qinany')" { 2404 description 2405 "Only applies when the type of the 2406 tagged interface is 'qinany'."; 2408 } 2409 if-feature "vpn-common:qinany"; 2410 leaf tag-type { 2411 type identityref { 2412 base vpn-common:tag-type; 2413 } 2414 default "vpn-common:s-vlan"; 2415 description 2416 "Tag type. By default, the tag type 2417 is 's-vlan'."; 2418 } 2419 leaf svlan-id { 2420 type uint16; 2421 mandatory true; 2422 description 2423 "Service VLAN ID."; 2424 } 2425 description 2426 "Container for QinAny."; 2427 } 2428 container vxlan { 2429 when "derived-from-or-self(../type, " 2430 + "'vpn-common:vxlan')" { 2431 description 2432 "Only applies when the type of the 2433 tagged interface is 'vxlan'."; 2434 } 2435 if-feature "vpn-common:vxlan"; 2436 leaf vni-id { 2437 type uint32; 2438 mandatory true; 2439 description 2440 "VXLAN Network Identifier (VNI)."; 2441 } 2442 leaf peer-mode { 2443 type identityref { 2444 base vpn-common:vxlan-peer-mode; 2445 } 2446 default "vpn-common:static-mode"; 2447 description 2448 "Specifies the VXLAN access mode. 2449 By default, the peer mode is set 2450 to 'static-mode'."; 2451 } 2452 list peer-list { 2453 key "peer-ip"; 2454 leaf peer-ip { 2455 type inet:ip-address; 2456 description 2457 "Peer IP."; 2458 } 2459 description 2460 "List of peer IP addresses."; 2461 } 2462 description 2463 "QinQ."; 2464 } 2465 description 2466 "Container for tagged interfaces."; 2467 } 2468 container bearer { 2469 leaf bearer-reference { 2470 if-feature "vpn-common:bearer-reference"; 2471 type string; 2472 description 2473 "This is an internal reference for* 2474 the SP."; 2475 } 2476 container pseudowire { 2477 leaf vcid { 2478 type uint32; 2479 description 2480 "PW or VC identifier."; 2481 } 2482 leaf far-end { 2483 type union { 2484 type uint32; 2485 type inet:ipv4-address; 2486 } 2487 description 2488 "SDP/Far End/LDP neighbour reference."; 2489 } 2490 description 2491 "Pseudowire termination parameters"; 2492 } 2493 container vpls { 2494 leaf vcid { 2495 type union { 2496 type uint32; 2497 type string; 2498 } 2499 description 2500 "VCID identifier, IRB/RVPPLs interface 2501 supported using string 2502 format."; 2503 } 2504 leaf far-end { 2505 type union { 2506 type uint32; 2507 type inet:ipv4-address; 2508 } 2509 description 2510 "SDP/Far End/LDP Neighbour reference."; 2511 } 2512 description 2513 "Pseudowire termination parameters"; 2514 } 2515 description 2516 "Defines physical properties of a site 2517 attachment."; 2518 } 2519 description 2520 "Encapsulation types"; 2521 } 2522 container ip-connection { 2523 container ipv4 { 2524 if-feature "vpn-common:ipv4"; 2525 leaf address-allocation-type { 2526 type identityref { 2527 base address-allocation-type; 2528 } 2529 must "not(derived-from-or-self(current(), " 2530 + "'slaac') or derived-from-or-self(current()," 2531 + " 'provider-dhcp-slaac'))" { 2532 error-message "SLAAC is only applicable to 2533 IPv6"; 2534 } 2535 description 2536 "Defines how addresses are allocated. 2537 If there is no value for the address 2538 allocation type, then IPv4 is not enabled."; 2539 } 2540 choice allocation-type { 2541 case provider-dhcp { 2542 when "derived-from-or-self(./address-" 2543 + "allocation-type, 'provider-dhcp')" { 2544 description 2545 "Only applies when addresses are 2546 allocated by DHCP."; 2547 } 2548 leaf provider-address { 2549 type inet:ipv4-address; 2550 description 2551 "Address of provider side. 2553 If provider-address is not specified, 2554 then prefix length should not be 2555 specified either. 2557 It also implies provider-dhcp 2558 allocation is not enabled. 2560 If provider-address is specified, 2561 then the prefix length may or 2562 may not be specified."; 2563 } 2564 leaf prefix-length { 2565 type uint8 { 2566 range "0..32"; 2567 } 2568 must '(../provider-address)' { 2569 error-message 2570 "If the prefix length is specified, 2571 provider-address must also be 2572 specified."; 2573 description 2574 "If the prefix length is specified, 2575 provider-address must also be 2576 specified."; 2577 } 2578 description 2579 "Subnet prefix length expressed in bits. 2580 If not specified, or specified as zero, 2581 this means the customer leaves the actual 2582 prefix length value to the provider."; 2583 } 2584 choice address-assign { 2585 default "number"; 2586 case number { 2587 leaf number-of-dynamic-address { 2588 type uint16; 2589 default "1"; 2590 description 2591 "Describes the number of IP 2592 addresses the customer requires."; 2593 } 2594 } 2595 case explicit { 2596 container customer-addresses { 2597 list address-group { 2598 key "group-id"; 2599 leaf group-id { 2600 type string; 2601 description 2602 "Group-id for the address range 2603 from start-address to 2604 end-address."; 2605 } 2606 leaf start-address { 2607 type inet:ipv4-address; 2608 description 2609 "First address."; 2610 } 2611 leaf end-address { 2612 type inet:ipv4-address; 2613 description 2614 "Last address."; 2615 } 2616 description 2617 "Describes IP addresses allocated by 2618 DHCP. 2620 When only start-address or only 2621 end-address is present, it 2622 represents a single address. 2623 When both start-address and 2624 end-address are specified, it 2625 implies a range inclusive of 2626 both addresses. If no address 2627 is specified, it implies customer 2628 addresses group is not supported."; 2629 } 2630 description 2631 "Container for customer addresses is 2632 allocated by DHCP."; 2633 } 2634 } 2635 description 2636 "Choice for the way to assign 2637 addresses."; 2638 } 2639 description 2640 "DHCP allocated addresses related 2641 parameters."; 2642 } 2643 case dhcp-relay { 2644 when "derived-from-or-self(./address-allocation" 2645 + "-type, 'provider-dhcp-relay')" { 2646 description 2647 "Only applies when provider is required to 2648 implement DHCP relay function."; 2650 } 2651 leaf dr-provider-address { 2652 type inet:ipv4-address; 2653 description 2654 "Address of provider side. 2656 If provider-address is 2657 not specified, then prefix length 2658 should not be specified either. 2660 It also implies provider-dhcp 2661 allocation is not enabled. 2663 If provider-address is specified, 2664 then prefix length may or may 2665 not be specified."; 2666 } 2667 leaf dr-prefix-length { 2668 type uint8 { 2669 range "0..32"; 2670 } 2671 must '(../dr-provider-address)' { 2672 error-message 2673 "If prefix length is specified, 2674 provider-address must also be 2675 specified."; 2676 description 2677 "If prefix length is specified, 2678 provider-address must also be 2679 specified."; 2680 } 2681 description 2682 "Subnet prefix length expressed in bits. 2684 If not specified, or specified as zero, 2685 this means the customer leaves the 2686 actual prefix length value 2687 to the provider."; 2688 } 2689 container customer-dhcp-servers { 2690 leaf-list server-ip-address { 2691 type inet:ipv4-address; 2692 description 2693 "IP address of customer DHCP 2694 server."; 2695 } 2696 description 2697 "Container for list of customer 2698 DHCP servers."; 2699 } 2700 description 2701 "DHCP relay provided by operator."; 2702 } 2703 case static-addresses { 2704 when "derived-from-or-self(./address-allocation" 2705 + "-type, 'static-address')" { 2706 description 2707 "Only applies when address allocation 2708 type is static."; 2709 } 2710 leaf primary-address { 2711 type leafref { 2712 path "../address/address-id"; 2713 } 2714 description 2715 "Principal address of the connection."; 2716 } 2717 list address { 2718 key "address-id"; 2719 leaf address-id { 2720 type string; 2721 description 2722 "IPv4 Address"; 2723 } 2724 leaf s-provider-address { 2725 type inet:ipv4-address; 2726 description 2727 "IPv4 Address List of the provider side. 2728 When the protocol allocation type is 2729 static, the provider address must be 2730 configured."; 2731 } 2732 leaf s-customer-address { 2733 type inet:ipv4-address; 2734 description 2735 "IPv4 Address of customer side."; 2736 } 2737 leaf s-prefix-length { 2738 type uint8 { 2739 range "0..32"; 2740 } 2741 description 2742 "Subnet prefix length expressed 2743 in bits. It is applied to both 2744 provider-address and customer-address."; 2745 } 2746 description 2747 "Describes IPv4 addresses used."; 2748 } 2749 description 2750 "Describes IPv4 addresses used."; 2751 } 2752 description 2753 "Choice the address allocation."; 2754 } 2755 description 2756 "IPv4-specific parameters."; 2757 } 2758 container ipv6 { 2759 if-feature "vpn-common:ipv6"; 2760 leaf address-allocation-type { 2761 type identityref { 2762 base address-allocation-type; 2763 } 2764 description 2765 "Defines how addresses are allocated. 2766 If there is no value for the address 2767 allocation type, then IPv6 is 2768 not enabled."; 2769 } 2770 choice allocation-type { 2771 choice provider-dhcp { 2772 when "derived-from-or-self(./address-allo" 2773 + "cation-type, 'provider-dhcp') " 2774 + "or derived-from-or-self(./address-allo" 2775 + "cation-type, 'provider-dhcp-slaac')" { 2776 description 2777 "Only applies when addresses are 2778 allocated by DHCP."; 2779 } 2780 leaf provider-address { 2781 type inet:ipv6-address; 2782 description 2783 "Address of the provider side. 2785 If provider-address is not specified, 2786 then prefix length should not be 2787 specified either. It also implies 2788 provider-dhcp allocation is not 2789 enabled. 2791 If provider-address is 2792 specified, then prefix length may 2793 or may not be specified."; 2795 } 2796 leaf prefix-length { 2797 type uint8 { 2798 range "0..128"; 2799 } 2800 must '(../provider-address)' { 2801 error-message 2802 "If prefix length is specified, 2803 provider-address 2804 must also be specified."; 2805 description 2806 "If prefix length is specified, 2807 provider-address 2808 must also be specified."; 2809 } 2810 description 2811 "Subnet prefix length expressed in 2812 bits. 2814 If not specified, or specified as 2815 zero, this means the customer leaves 2816 the actual prefix length value to 2817 the provider."; 2818 } 2819 choice address-assign { 2820 default "number"; 2821 case number { 2822 leaf number-of-dynamic-address { 2823 type uint16; 2824 default "1"; 2825 description 2826 "Describes the number of IP 2827 addresses required by the 2828 customer."; 2829 } 2830 } 2831 case explicit { 2832 container customer-addresses { 2833 list address-group { 2834 key "group-id"; 2835 leaf group-id { 2836 type string; 2837 description 2838 "Group-id for the address range 2839 from start-address to 2840 end-address."; 2841 } 2842 leaf start-address { 2843 type inet:ipv6-address; 2844 description 2845 "First address."; 2846 } 2847 leaf end-address { 2848 type inet:ipv6-address; 2849 description 2850 "Last address."; 2851 } 2852 description 2853 "Describes IP addresses allocated 2854 by DHCP. 2856 When only start-address or only 2857 end-address is present, it 2858 represents a single address. 2860 When both start-address and 2861 end-address are specified, it 2862 implies a range inclusive of 2863 both addresses. 2865 If no address is specified, it 2866 implies customer addresses group 2867 is not supported."; 2868 } 2869 description 2870 "Container for customer addresses 2871 allocated by DHCP."; 2872 } 2873 } 2874 description 2875 "Choice for the way to assign addresses."; 2876 } 2877 description 2878 "DHCP allocated addresses related 2879 parameters."; 2880 } 2881 case dhcp-relay { 2882 when "derived-from-or-self(./address-allo" 2883 + "cation-type, 'provider-dhcp-relay')" { 2884 description 2885 "Only applies when the provider is required 2886 to implement DHCP relay function."; 2887 } 2888 leaf dr-provider-address { 2889 type inet:ipv6-address; 2890 description 2891 "Address of the provider side. 2893 If provider-address is not specified, 2894 then prefix length should not be 2895 specified either. It also implies 2896 provider-dhcp allocation is not enabled. 2898 If provider address is specified, then 2899 prefix length may or may not be 2900 specified."; 2901 } 2902 leaf dr-prefix-length { 2903 type uint8 { 2904 range "0..128"; 2905 } 2906 must '(../dr-provider-address)' { 2907 error-message 2908 "If prefix length is specified, 2909 provider-address must also be 2910 specified."; 2911 description 2912 "If prefix length is specified, 2913 provider-address must also be 2914 specified."; 2915 } 2916 description 2917 "Subnet prefix length expressed in bits. 2919 If not specified, or specified as zero, 2920 this means the customer leaves the 2921 actual prefix length value to the 2922 provider."; 2923 } 2924 container customer-dhcp-servers { 2925 leaf-list server-ip-address { 2926 type inet:ipv6-address; 2927 description 2928 "This node contains the IP address of 2929 the customer DHCP server. If the DHCP 2930 relay function is implemented by the 2931 provider, this node contains the 2932 configured value."; 2933 } 2934 description 2935 "Container for list of customer DHCP 2936 servers."; 2937 } 2938 description 2939 "DHCP relay provided by operator."; 2940 } 2941 case static-addresses { 2942 when "derived-from-or-self(./address-allocation" 2943 + "-type, 'static-address')" { 2944 description 2945 "Only applies when protocol allocation type 2946 is static."; 2947 } 2948 leaf s-primary-address { 2949 type leafref { 2950 path "../s-address/address-id"; 2951 } 2952 description 2953 "Principal address of the connection"; 2954 } 2955 list s-address { 2956 key "address-id"; 2957 leaf address-id { 2958 type string; 2959 description 2960 "IPv4 Address"; 2961 } 2962 leaf provider-address { 2963 type inet:ipv6-address; 2964 description 2965 "IPv6 Address of the provider side. When 2966 the protocol allocation type is static, 2967 the provider address must be 2968 configured."; 2969 } 2970 leaf customer-address { 2971 type inet:ipv6-address; 2972 description 2973 "The IPv6 Address of the customer side."; 2974 } 2975 leaf prefix-length { 2976 type uint8 { 2977 range "0..128"; 2978 } 2979 description 2980 "Subnet prefix length expressed in bits. 2981 It is applied to both provider-address 2982 and customer-address."; 2983 } 2984 description 2985 "Describes IPv6 addresses used."; 2986 } 2987 description 2988 "IPv6-specific parameters."; 2989 } 2990 description 2991 "IPv6 allocation type."; 2992 } 2993 description 2994 "IPv6-specific parameters."; 2995 } 2996 container oam { 2997 container bfd { 2998 if-feature "vpn-common:bfd"; 2999 leaf enabled { 3000 type boolean; 3001 default "false"; 3002 description 3003 "If true, BFD activation is required."; 3004 } 3005 choice holdtime { 3006 default "fixed"; 3007 case fixed { 3008 leaf fixed-value { 3009 type uint32; 3010 units "msec"; 3011 description 3012 "Expected BFD holdtime. 3014 The customer may impose some fixed 3015 values for the holdtime period if the 3016 provider allows the customer use this 3017 function. 3019 If the provider doesn't allow the 3020 customer to use this function, 3021 the fixed-value will not be set."; 3022 } 3023 } 3024 case profile { 3025 leaf profile-name { 3026 type leafref { 3027 path "/l3vpn-ntw/vpn-profiles/" 3028 + "valid-provider-identifiers/" 3029 + "bfd-profile-identifier/id"; 3030 } 3031 description 3032 "Well-known SP profile name. 3034 The provider can propose some profiles 3035 to the customer, depending on the 3036 service level the customer wants to 3037 achieve. 3039 Profile names must be communicated to 3040 the customer."; 3041 } 3042 description 3043 "Well-known SP profile."; 3044 } 3045 description 3046 "Choice for holdtime flavor."; 3047 } 3048 description 3049 "Container for BFD."; 3050 } 3051 description 3052 "Defines the Operations, Administration, 3053 and Maintenance (OAM)mechanisms used on 3054 the connection. 3056 BFD is set as a fault detection mechanism, 3057 but the 'oam' container can easily 3058 be augmented by other mechanisms"; 3059 } 3060 description 3061 "Defines connection parameters."; 3062 } 3063 container security { 3064 container encryption { 3065 if-feature "vpn-common:encryption"; 3066 leaf enabled { 3067 type boolean; 3068 default "false"; 3069 description 3070 "If true, traffic encryption on the 3071 connection is required. It is 3072 disabled, otherwise."; 3073 } 3074 leaf layer { 3075 when "../enabled = 'true'" { 3076 description 3077 "Require a value for layer when 3078 enabled is true."; 3079 } 3080 type enumeration { 3081 enum layer2 { 3082 description 3083 "Encryption will occur at Layer 2."; 3084 } 3085 enum layer3 { 3086 description 3087 "Encryption will occur at Layer 3. 3088 For example, IPsec may be used when 3089 a customer requests Layer 3 3090 encryption."; 3091 } 3092 } 3093 description 3094 "Layer on which encryption is applied."; 3095 } 3096 description 3097 "Container for CE-PE security encryption."; 3098 } 3099 container encryption-profile { 3100 choice profile { 3101 case provider-profile { 3102 leaf profile-name { 3103 type leafref { 3104 path "/l3vpn-ntw/vpn-profiles" 3105 + "/valid-provider-identifiers" 3106 + "/encryption-profile-identifier/id"; 3107 } 3108 description 3109 "Name of the SP profile to be applied."; 3110 } 3111 } 3112 case customer-profile { 3113 leaf algorithm { 3114 type string; 3115 description 3116 "Encryption algorithm to be used."; 3117 } 3118 } 3119 description 3120 "Choice for encryption profile."; 3121 } 3122 choice key-type { 3123 default "psk"; 3124 case psk { 3125 leaf preshared-key { 3126 type string; 3127 description 3128 "Pre-Shared Key (PSK) coming from the 3129 customer."; 3130 } 3132 } 3133 description 3134 "Choice of encryption profile. 3135 The encryption profile can be the 3136 provider profile or customer profile."; 3137 } 3138 description 3139 "Container for encryption profile."; 3140 } 3141 description 3142 "Site-specific security parameters."; 3143 } 3144 container routing-protocols { 3145 list routing-protocol { 3146 key "id"; 3147 leaf id { 3148 type string; 3149 description 3150 "Unique identifier for routing protocol."; 3151 } 3152 leaf type { 3153 type identityref { 3154 base vpn-common:routing-protocol-type; 3155 } 3156 description 3157 "Type of routing protocol."; 3158 } 3159 list routing-profiles { 3160 key "id"; 3161 leaf id { 3162 type leafref { 3163 path "/l3vpn-ntw/vpn-profiles" 3164 + "/valid-provider-identifiers" 3165 + "/routing-profile-identifier/id"; 3166 } 3167 description 3168 "Routing profile to be used."; 3169 } 3170 leaf type { 3171 type identityref { 3172 base vpn-common:ie-type; 3173 } 3174 description 3175 "Import, export or both."; 3176 } 3177 description 3178 "Routing profiles."; 3179 } 3180 container ospf { 3181 when "derived-from-or-self(../type, " 3182 + "'vpn-common:ospf')" { 3183 description 3184 "Only applies when protocol is OSPF."; 3185 } 3186 if-feature "vpn-common:rtg-ospf"; 3187 leaf-list address-family { 3188 type vpn-common:address-family; 3189 min-elements 1; 3190 description 3191 "If OSPF is used on this site, this node 3192 contains a configured value. This node 3193 contains at least one address family 3194 to be activated."; 3195 } 3196 leaf area-address { 3197 type yang:dotted-quad; 3198 mandatory true; 3199 description 3200 "Area address."; 3201 } 3202 leaf metric { 3203 type uint16; 3204 default "1"; 3205 description 3206 "Metric of the PE-CE link. It is used 3207 in the routing state calculation and 3208 path selection."; 3209 } 3210 leaf mtu { 3211 type uint16; 3212 description 3213 "Maximum transmission unit for a given 3214 OSPF link."; 3215 } 3216 leaf process-id { 3217 type uint16; 3218 description 3219 "Process id of the OSPF CE-PE connection."; 3220 } 3221 uses security-params; 3222 container sham-links { 3223 if-feature "vpn-common:rtg-ospf-sham-link"; 3224 list sham-link { 3225 key "target-site"; 3226 leaf target-site { 3227 type vpn-common:vpn-id; 3228 description 3229 "Target site for the sham link connection. 3230 The site is referred to by its ID."; 3231 } 3232 leaf metric { 3233 type uint16; 3234 default "1"; 3235 description 3236 "Metric of the sham link. It is used in 3237 the routing state calculation and path 3238 selection. The default value is set 3239 to 1."; 3240 } 3241 description 3242 "Creates a sham link with another site."; 3243 } 3244 description 3245 "List of sham links."; 3246 } 3247 description 3248 "OSPF-specific configuration."; 3249 } 3250 container bgp { 3251 when "derived-from-or-self(../type, " 3252 + "'vpn-common:bgp')" { 3253 description 3254 "Only applies when protocol is BGP."; 3255 } 3256 if-feature "vpn-common:rtg-bgp"; 3257 leaf peer-autonomous-system { 3258 type inet:as-number; 3259 mandatory true; 3260 description 3261 "Indicates the Customer's AS Number (ASN) in 3262 case the Customer requests BGP routing."; 3263 } 3264 leaf local-autonomous-system { 3265 type inet:as-number; 3266 description 3267 "Is set to the ASN to override a peers' ASN 3268 if such feature is requested by the 3269 Customer."; 3270 } 3271 leaf-list address-family { 3272 type vpn-common:address-family; 3273 min-elements 1; 3274 description 3275 "This node contains at least one 3276 address-family to be activated."; 3277 } 3278 leaf-list neighbor { 3279 type inet:ip-address; 3280 description 3281 "IP address(es) of the BGP neighbor. IPv4 3282 and IPv6 neighbors may be indicated if 3283 two sessions will be used for IPv4 and 3284 IPv6."; 3285 } 3286 leaf multihop { 3287 type uint8; 3288 description 3289 "Describes the number of IP hops allowed 3290 between a given BGP neighbor and the PE."; 3291 } 3292 uses security-params; 3293 uses vpn-common:service-status; 3294 leaf description { 3295 type string; 3296 description 3297 "Includes a description of the BGP session. 3298 Such description is meant to be used for 3299 diagnosis purposes. The semantic of the 3300 description is local to an 3301 implementation."; 3302 } 3303 leaf as-override { 3304 type boolean; 3305 default "false"; 3306 description 3307 "Defines whether AS override is enabled, 3308 i.e., replace the ASN of the peer specified 3309 in the AS Path attribute with the local 3310 AS number."; 3311 } 3312 leaf default-route { 3313 type boolean; 3314 default "false"; 3315 description 3316 "Defines whether default route(s) can be 3317 advertised to its peer. If set, the 3318 default route(s) is advertised to its 3319 peer."; 3320 } 3321 container bgp-max-prefix { 3322 leaf max-prefix { 3323 type uint32; 3324 default "5000"; 3325 description 3326 "Indicates the maximimum number of BGP 3327 prefixes allowed in the BGP session. 3329 It allows to control how many prefixes 3330 can be received from a neighbor. 3332 If the limit is exceeded, the session 3333 can be teared down."; 3334 reference 3335 "RFC4271, Section 8.2.2."; 3336 } 3337 leaf warning-threshold { 3338 type decimal64 { 3339 fraction-digits 5; 3340 range "0..100"; 3341 } 3342 units "percent"; 3343 default "75"; 3344 description 3345 "When this value is reached, a warning 3346 notification will be triggered."; 3347 } 3348 leaf violate-action { 3349 type enumeration { 3350 enum warning { 3351 description 3352 "Only a warning message is sent to 3353 the peer when the limit is 3354 exceeded."; 3355 } 3356 enum discard-extra-paths { 3357 description 3358 "Discards extra paths when the 3359 limit is exceeded."; 3360 } 3361 enum restart { 3362 description 3363 "Restart after a time interval."; 3364 } 3365 } 3366 description 3367 "BGP neighbour max-prefix violate 3368 action"; 3369 } 3370 leaf restart-interval { 3371 type uint16; 3372 units "minutes"; 3373 description 3374 "Time interval (min) after which the 3375 BGP session will be reestablished."; 3376 } 3377 description 3378 "Controls the behavior when a prefix 3379 maximum is reached."; 3380 } 3381 container bgp-timer { 3382 description 3383 "Includes two BGP timers that can be 3384 customized when building a VPN service 3385 with BGP used as CE-PE routing 3386 protocol."; 3387 leaf keep-alive { 3388 type uint16 { 3389 range "0..21845"; 3390 } 3391 units "seconds"; 3392 default "30"; 3393 description 3394 "This timer indicates the KEEPALIVE 3395 messages' frequency between a PE 3396 and a BGP peer. 3398 If set to '0', it indicates KEEPALIVE 3399 messages are disabled. 3401 It is suggested that the maximum time 3402 between KEEPALIVEmessages would be 3403 one third of the Hold Time interval."; 3404 reference 3405 "Section 4.4 of RFC 4271"; 3406 } 3407 leaf hold-time { 3408 type uint16 { 3409 range "0 | 3..65535"; 3410 } 3411 units "seconds"; 3412 default "90"; 3413 description 3414 "It indicates the maximum number of 3415 seconds that may elapse between the 3416 receipt of successive KEEPALIVE 3417 and/or UPDATE messages from the peer. 3419 The Hold Time must be either zero or 3420 at least three seconds."; 3421 reference 3422 "Section 4.2 of RFC 4271"; 3423 } 3424 } 3425 description 3426 "BGP-specific configuration."; 3427 } 3428 container isis { 3429 when "derived-from-or-self(../type, " 3430 + "'vpn-common:isis')" { 3431 description 3432 "Only applies when protocol is IS-IS."; 3433 } 3434 if-feature "vpn-common:rtg-isis"; 3435 leaf-list address-family { 3436 type vpn-common:address-family; 3437 min-elements 1; 3438 description 3439 "If ISIS is used on this site, this node 3440 contains a configured value. This node 3441 contains at least one address family 3442 to be activated."; 3443 } 3444 leaf area-address { 3445 type yang:dotted-quad; 3446 mandatory true; 3447 description 3448 "Area address."; 3449 } 3450 leaf level { 3451 type identityref { 3452 base isis-level; 3453 } 3454 description 3455 "level1, level2 or level1-2"; 3456 } 3457 leaf metric { 3458 type uint16; 3459 default "1"; 3460 description 3461 "Metric of the PE-CE link. It is used 3462 in the routing state calculation and 3463 path selection."; 3464 } 3465 leaf process-id { 3466 type uint16; 3467 description 3468 "Process id of the IS-IS CE-PE 3469 connection."; 3470 } 3471 leaf mode { 3472 type enumeration { 3473 enum active { 3474 description 3475 "Interface sends or receives IS-IS 3476 protocol control packets."; 3477 } 3478 enum passive { 3479 description 3480 "Suppresses the sending of IS-IS 3481 updates through the specified 3482 interface."; 3483 } 3484 } 3485 default "active"; 3486 description 3487 "IS-IS interface mode type."; 3488 } 3489 uses vpn-common:service-status; 3490 description 3491 "IS-IS specific configuration."; 3492 } 3493 container static { 3494 when "derived-from-or-self(../type, " 3495 + "'vpn-common:static')" { 3496 description 3497 "Only applies when protocol is static. 3498 BGP activation requires the SP to know 3499 the address of the customer peer. When 3500 BGP is enabled, the 'static-address' 3501 allocation type for the IP connection 3502 must be used."; 3503 } 3504 container cascaded-lan-prefixes { 3505 list ipv4-lan-prefixes { 3506 if-feature "vpn-common:ipv4"; 3507 key "lan next-hop"; 3508 leaf lan { 3509 type inet:ipv4-prefix; 3510 description 3511 "LAN prefixes."; 3512 } 3513 leaf lan-tag { 3514 type string; 3515 description 3516 "Internal tag to be used in VPN 3517 policies."; 3518 } 3519 leaf next-hop { 3520 type inet:ipv4-address; 3521 description 3522 "Next-hop address to use on the 3523 customer side."; 3524 } 3525 description 3526 "List of LAN prefixes for the site."; 3527 } 3528 list ipv6-lan-prefixes { 3529 if-feature "vpn-common:ipv6"; 3530 key "lan next-hop"; 3531 leaf lan { 3532 type inet:ipv6-prefix; 3533 description 3534 "LAN prefixes."; 3535 } 3536 leaf lan-tag { 3537 type string; 3538 description 3539 "Internal tag to be used in VPN 3540 policies."; 3541 } 3542 leaf next-hop { 3543 type inet:ipv6-address; 3544 description 3545 "Next-hop address to use on the 3546 customer side."; 3547 } 3548 description 3549 "List of LAN prefixes for the site."; 3550 } 3551 description 3552 "LAN prefixes from the customer."; 3553 } 3554 description 3555 "Configuration specific to static routing."; 3556 } 3557 container rip { 3558 when "derived-from-or-self(../type, " 3559 + "'vpn-common:rip')" { 3560 description 3561 "Only applies when the protocol is RIP. 3562 For IPv4, the model assumes that RIP 3563 version 2 is used."; 3565 } 3566 if-feature "vpn-common:rtg-rip"; 3567 leaf-list address-family { 3568 type vpn-common:address-family; 3569 min-elements 1; 3570 description 3571 "If RIP is used on this site, this node 3572 contains a configured value. This node 3573 contains at least one address family 3574 to be activated."; 3575 } 3576 description 3577 "Configuration specific to RIP routing."; 3578 } 3579 container vrrp { 3580 when "derived-from-or-self(../type, " 3581 + "'vpn-common:vrrp')" { 3582 description 3583 "Only applies when protocol is VRRP."; 3584 } 3585 if-feature "vpn-common:rtg-vrrp"; 3586 leaf-list address-family { 3587 type vpn-common:address-family; 3588 min-elements 1; 3589 description 3590 "If VRRP is used on this site, this node 3591 contains a configured value. This node 3592 contains at least one address family to 3593 be activated."; 3594 } 3595 leaf vrrp-group { 3596 type uint8 { 3597 range "1..255"; 3598 } 3599 description 3600 "VRRP group number"; 3601 } 3602 leaf backup-peer { 3603 type inet:ip-address; 3604 description 3605 "IP address of the peer"; 3606 } 3607 leaf priority { 3608 type uint8; 3609 description 3610 "Local priority of the VRRP speaker"; 3611 } 3612 leaf ping-reply { 3613 type boolean; 3614 description 3615 "Whether the VRRP speaker should answer 3616 to ping requests"; 3617 } 3618 description 3619 "Configuration specific to VRRP."; 3620 } 3621 description 3622 "List of routing protocols used on 3623 the site. This list can be augmented."; 3624 } 3625 description 3626 "Defines routing protocols."; 3627 } 3628 container service { 3629 leaf svc-input-bandwidth { 3630 type uint64; 3631 units "bps"; 3632 mandatory true; 3633 description 3634 "From the customer site's perspective, the 3635 service input bandwidth of the connection 3636 or download bandwidth from the SP to 3637 the site."; 3638 } 3639 leaf svc-output-bandwidth { 3640 type uint64; 3641 units "bps"; 3642 mandatory true; 3643 description 3644 "From the customer site's perspective, 3645 the service output bandwidth of the 3646 connection or upload bandwidth from 3647 the site to the SP."; 3648 } 3649 leaf svc-mtu { 3650 type uint16; 3651 units "bytes"; 3652 mandatory true; 3653 description 3654 "MTU at service level. If the service is IP, 3655 it refers to the IP MTU. If CsC is enabled, 3656 the requested 'svc-mtu' leaf will refer 3657 to the MPLS MTU and not to the IP MTU."; 3658 } 3659 container qos { 3660 if-feature "vpn-common:qos"; 3661 container qos-classification-policy { 3662 list rule { 3663 key "id"; 3664 ordered-by user; 3665 leaf id { 3666 type string; 3667 description 3668 "A description identifying the 3669 qos-classification-policy rule."; 3670 } 3671 choice match-type { 3672 default "match-flow"; 3673 case match-flow { 3674 choice l3 { 3675 container ipv4 { 3676 uses pf:acl-ip-header-fields; 3677 uses pf:acl-ipv4-header-fields; 3678 description 3679 "Rule set that matches IPv4 header."; 3680 } 3681 container ipv6 { 3682 uses pf:acl-ip-header-fields; 3683 uses pf:acl-ipv6-header-fields; 3684 description 3685 "Rule set that matches IPv6 header."; 3686 } 3687 description 3688 "Either IPv4 or IPv6."; 3689 } 3690 choice l4 { 3691 container tcp { 3692 uses pf:acl-tcp-header-fields; 3693 uses ports; 3694 description 3695 "Rule set that matches TCP header."; 3696 } 3697 container udp { 3698 uses pf:acl-udp-header-fields; 3699 uses ports; 3700 description 3701 "Rule set that matches UDP header."; 3702 } 3703 description 3704 "Can be TCP or UDP"; 3705 } 3706 } 3707 case match-application { 3708 leaf match-application { 3709 type identityref { 3710 base vpn-common:customer-application; 3711 } 3712 description 3713 "Defines the application to match."; 3714 } 3715 } 3716 description 3717 "Choice for classification."; 3718 } 3719 leaf target-class-id { 3720 type string; 3721 description 3722 "Identification of the class of service. 3723 This identifier is internal to the 3724 administration."; 3725 } 3726 description 3727 "List of marking rules."; 3728 } 3729 description 3730 "Configuration of the traffic classification 3731 policy."; 3732 } 3733 container qos-profile { 3734 list qos-profile { 3735 key "profile"; 3736 description 3737 "QoS profile. 3738 Can be standard profile or customized 3739 profile."; 3740 leaf profile { 3741 type leafref { 3742 path "/l3vpn-ntw/vpn-profiles" 3743 + "/valid-provider-identifiers" 3744 + "/qos-profile-identifier/id"; 3745 } 3746 description 3747 "QoS profile to be used."; 3748 } 3749 leaf direction { 3750 type identityref { 3751 base vpn-common:qos-profile-direction; 3752 } 3753 default "vpn-common:both"; 3754 description 3755 "The direction to which the QoS profile 3756 is applied."; 3758 } 3759 } 3760 description 3761 "QoS profile configuration."; 3762 } 3763 description 3764 "QoS configuration."; 3765 } 3766 container carrierscarrier { 3767 if-feature "vpn-common:carrierscarrier"; 3768 leaf signalling-type { 3769 type enumeration { 3770 enum ldp { 3771 description 3772 "Use LDP as the signalling protocol 3773 between the PE and the CE. In this 3774 case, an IGP routing protocol must 3775 also be activated."; 3776 } 3777 enum bgp { 3778 description 3779 "Use BGP as the signalling protocol 3780 between the PE and the CE. 3781 In this case, BGP must also be configured 3782 as the routing protocol."; 3783 reference 3784 "RFC 8277: Using BGP to Bind MPLS Labels 3785 to Address Prefixes"; 3786 } 3787 } 3788 default "bgp"; 3789 description 3790 "MPLS signalling type."; 3791 } 3792 description 3793 "This container is used when the customer 3794 provides MPLS-based services. This is 3795 only used in the case of CsC (i.e., a 3796 customer builds an MPLSservice using an 3797 IP VPN to carry its traffic)."; 3798 } 3799 container multicast { 3800 if-feature "vpn-common:multicast"; 3801 leaf site-type { 3802 type enumeration { 3803 enum receiver-only { 3804 description 3805 "The site only has receivers."; 3807 } 3808 enum source-only { 3809 description 3810 "The site only has sources."; 3811 } 3812 enum source-receiver { 3813 description 3814 "The site has both sources and 3815 receivers."; 3816 } 3817 } 3818 default "source-receiver"; 3819 description 3820 "Type of multicast site."; 3821 } 3822 leaf address-family { 3823 type vpn-common:address-family; 3824 description 3825 "Address family."; 3826 } 3827 leaf protocol-type { 3828 type enumeration { 3829 enum host { 3830 description 3831 "Hosts are directly connected to the 3832 provider network. 3834 Host protocols such as IGMP or MLD are 3835 required."; 3836 } 3837 enum router { 3838 description 3839 "Hosts are behind a customer router. 3840 PIM will be implemented."; 3841 } 3842 enum both { 3843 description 3844 "Some hosts are behind a customer router, 3845 and some others are directly connected 3846 to the provider network. Both host and 3847 routing protocols must be used. 3849 Typically, IGMP and PIM will be 3850 implemented."; 3851 } 3852 } 3853 default "both"; 3854 description 3855 "Multicast protocol type to be used with 3856 the customer site."; 3857 } 3858 leaf remote-source { 3859 type boolean; 3860 default "false"; 3861 description 3862 "When true, there is no PIM adjacency on 3863 the interface."; 3864 } 3865 description 3866 "Multicast parameters for the site."; 3867 } 3868 description 3869 "Service parameters on the attachment."; 3870 } 3871 description 3872 "List of accesses for a site."; 3873 } 3874 description 3875 "List of accesses for a site."; 3876 } 3877 container maximum-routes { 3878 list address-family { 3879 key "af"; 3880 leaf af { 3881 type vpn-common:address-family; 3882 description 3883 "Indicates the address family 3884 (IPv4 or IPv6)."; 3885 } 3886 leaf maximum-routes { 3887 type uint32; 3888 description 3889 "Indicates the maximum prefixes the VRF 3890 can accept for this address family."; 3891 } 3892 description 3893 "List of address families."; 3894 } 3895 description 3896 "Defines 'maximum-routes' for the VRF."; 3897 } 3898 container multicast { 3899 if-feature "vpn-common:multicast"; 3900 leaf enabled { 3901 type boolean; 3902 default "false"; 3903 description 3904 "Enables multicast."; 3905 } 3906 leaf-list tree-flavor { 3907 type identityref { 3908 base vpn-common:multicast-tree-type; 3909 } 3910 description 3911 "Type of tree to be used."; 3912 } 3913 container rp { 3914 container rp-group-mappings { 3915 list rp-group-mapping { 3916 key "id"; 3917 leaf id { 3918 type uint16; 3919 description 3920 "Unique identifier for the mapping."; 3921 } 3922 container provider-managed { 3923 leaf enabled { 3924 type boolean; 3925 default "false"; 3926 description 3927 "Set to true if the Rendezvous Point (RP) 3928 must be a provider-managed node. Set to 3929 false if it is a customer-managed node."; 3930 } 3931 leaf rp-redundancy { 3932 type boolean; 3933 default "false"; 3934 description 3935 "If true, a redundancy mechanism for the 3936 RP is required."; 3937 } 3938 leaf optimal-traffic-delivery { 3939 type boolean; 3940 default "false"; 3941 description 3942 "If true, the SP must ensure that 3943 traffic uses an optimal path. An SP may 3944 use Anycast RP or RP-tree-to-SPT 3945 switchover architectures."; 3946 } 3947 container anycast { 3948 when "../rp-redundancy = 'true' and 3949 ../optimal-traffic-delivery = 'true'" { 3950 description 3951 "Only applicable if 3952 RP redundancy is 3953 enabled and delivery through 3954 optimal path is activated."; 3955 } 3956 leaf local-address { 3957 type inet:ip-address; 3958 description 3959 "IP local address for PIM RP. 3960 Usually, it corresponds to router 3961 ID or primary address"; 3962 } 3963 leaf-list rp-set-address { 3964 type inet:ip-address; 3965 description 3966 "Address other RP routers 3967 that share the same RP IP address."; 3968 } 3969 description 3970 "PIM Anycast-RP parameters."; 3971 } 3972 description 3973 "Parameters for a provider-managed RP."; 3974 } 3975 leaf rp-address { 3976 when "../provider-managed/enabled = 'false'" { 3977 description 3978 "Relevant when the RP is not 3979 provider-managed."; 3980 } 3981 type inet:ip-address; 3982 mandatory true; 3983 description 3984 "Defines the address of the RP. 3985 Used if the RP is customer-managed."; 3986 } 3987 container groups { 3988 list group { 3989 key "id"; 3990 leaf id { 3991 type uint16; 3992 description 3993 "Identifier for the group."; 3994 } 3995 choice group-format { 3996 mandatory true; 3997 case group-prefix { 3998 leaf group-address { 3999 type inet:ip-prefix; 4000 description 4001 "A single multicast group prefix."; 4002 } 4003 } 4004 case startend { 4005 leaf group-start { 4006 type inet:ip-address; 4007 description 4008 "The first multicast group address in 4009 the multicast group address range."; 4010 } 4011 leaf group-end { 4012 type inet:ip-address; 4013 description 4014 "The last multicast group address in 4015 the multicast group address range."; 4016 } 4017 } 4018 description 4019 "Choice for multicast group format."; 4020 } 4021 description 4022 "List of multicast groups."; 4023 } 4024 description 4025 "Multicast groups associated with the RP."; 4026 } 4027 description 4028 "List of RP-to-group mappings."; 4029 } 4030 description 4031 "RP-to-group mappings parameters."; 4032 } 4033 container rp-discovery { 4034 leaf rp-discovery-type { 4035 type identityref { 4036 base vpn-common:multicast-rp-discovery-type; 4037 } 4038 default "vpn-common:static-rp"; 4039 description 4040 "Type of RP discovery used."; 4041 } 4042 container bsr-candidates { 4043 when "derived-from-or-self(../rp-discovery-type, " 4044 + "'vpn-common:bsr-rp')" { 4045 description 4046 "Only applicable if discovery type 4047 is BSR-RP."; 4048 } 4049 leaf-list bsr-candidate-address { 4050 type inet:ip-address; 4051 description 4052 "Address of candidate Bootstrap Router 4053 (BSR)."; 4054 } 4055 description 4056 "Container for List of Customer 4057 BSR candidate's addresses."; 4058 } 4059 description 4060 "RP discovery parameters."; 4061 } 4062 description 4063 "RP parameters."; 4064 } 4065 container msdp { 4066 if-feature "msdp"; 4067 leaf enabled { 4068 type boolean; 4069 default "false"; 4070 description 4071 "If true, MSDP is activated."; 4072 } 4073 leaf peer { 4074 type inet:ip-address; 4075 description 4076 "IP address of the MSDP peer."; 4077 } 4078 leaf local-address { 4079 type inet:ip-address; 4080 description 4081 "IP address of the local end. This local 4082 address must be configured on the 4083 node."; 4084 } 4085 description 4086 "MSDP parameters."; 4087 } 4088 description 4089 "Multicast global parameters for the VPN 4090 service."; 4091 } 4092 description 4093 "List for VPN node."; 4094 } 4096 } 4097 description 4098 "List of VPN services."; 4099 } 4100 description 4101 "Top-level container for the VPN services."; 4102 } 4103 description 4104 "Main container for L3VPN services management."; 4105 } 4106 } 4107 4109 Figure 25 4111 9. IANA Considerations 4113 This document requests IANA to register the following URI in the "ns" 4114 subregistry within the "IETF XML Registry" [RFC3688]: 4116 URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw 4117 Registrant Contact: The IESG. 4118 XML: N/A; the requested URI is an XML namespace. 4120 This document requests IANA to register the following YANG module in 4121 the "YANG Module Names" subregistry [RFC6020] within the "YANG 4122 Parameters" registry. 4124 name: ietf-l3vpn-ntw 4125 namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw 4126 maintained by IANA: N 4127 prefix: l3nm 4128 reference: RFC XXXX 4130 10. Security Considerations 4132 The YANG module specified in this document defines schema for data 4133 that is designed to be accessed via network management protocols such 4134 as NETCONF [RFC6241] or RESTCONF [RFC8040] . The lowest NETCONF layer 4135 is the secure transport layer, and the mandatory-to-implement secure 4136 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 4137 is HTTPS, and the mandatory-to-implement secure transport is TLS 4138 [RFC8466]. 4140 The Network Configuration Access Control Model (NACM) [RFC8341] 4141 provides the means to restrict access for particular NETCONF or 4142 RESTCONF users to a preconfigured subset of all available NETCONF or 4143 RESTCONF protocol operations and content. 4145 The "ietf-l3vpn-ntw" module is used to manage Layer 3 VPNs in a 4146 service provider backbone network. Hence, the module can be used to 4147 request, modify, or retrieve L3VPN services. For example, the 4148 creation of a 'vpn-service' leaf instance triggers the creation of an 4149 L3VPN Service in a service provider network. 4151 Due to the foreseen use of the "ietf-l3vpn-ntw" module, there are a 4152 number of data nodes defined in the module that are 4153 writable/creatable/deletable (i.e., config true, which is the 4154 default). These data nodes MAY be considered sensitive or vulnerable 4155 in some network environments. Write operations (e.g., edit-config) 4156 and delete operations to these data nodes without proper protection 4157 or authentication can have a negative effect on network operations. 4158 These are the subtrees and data nodes and their sensitivity/ 4159 vulnerability in the "ietf-l3vpn-ntw" module: 4161 o 'vpn-service': An attacker who is able to access network nodes can 4162 undertake various attacks, such as deleting a running L3VPN 4163 Service, interrupting all the traffic of a client. In addition, 4164 an attacker may modify the attributes of a running service (e.g., 4165 QoS, bandwidth, routing protocols), leading to malfunctioning of 4166 the service and therefore to SLA violations. In addition, an 4167 attacker could attempt to create a L3VPN Service or adding a new 4168 network access. Such activity can be detected by adequately 4169 monitoring and tracking network configuration changes. 4171 Some of the readable data nodes in the "ietf-l3vpn-ntw" module may be 4172 considered sensitive or vulnerable in some network environments. It 4173 is thus important to control read access (e.g., via get, get-config, 4174 or notification) to these data nodes. These are the subtrees and 4175 data nodes and their sensitivity/vulnerability: 4177 o 'customer-name' and 'ip-connection': An attacker can retrieve 4178 privacy-related information which can be used to track a customer. 4179 Disclosing such information may be considered as a violation of 4180 the customer-provider trust relationship. 4182 The following summarizes the foreseen risks of using the "ietf-l3vpn- 4183 ntw" module can be classified into: 4185 o Malicious clients attempting to delete or modify VPN services. 4187 o Unauthorized clients attempting to create/modify/delete a VPN 4188 service. 4190 o Unauthorized clients attempting to read VPN service related 4191 information. 4193 11. Acknowledgements 4195 Thanks to Adrian Farrel and Miguel Cros for the suggestions on the 4196 document. Thanks to Philip Eardlay for the review. Lots of thanks 4197 for the discussions on opsawg mailing list and at IETF meeting. 4199 This work was supported in part by the European Commission funded 4200 H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727). 4202 12. Contributors 4204 Victor Lopez 4205 Telefonica 4206 Email: victor.lopezalvarez@telefonica.com 4208 Daniel King 4209 Old Dog Consulting 4210 Email: daniel@olddog.co.uk 4212 Daniel Voyer 4213 Bell Canada 4214 Email: daniel.voyer@bell.ca 4216 Luay Jalil 4217 Verizon 4218 Email: luay.jalil@verizon.com 4220 Qin Wu 4221 Huawei 4222 Email: bill.wu@huawei.com> 4224 Stephane Litkowski 4225 Cisco 4226 Email: slitkows@cisco.com> 4228 Manuel Julian 4229 Vodafone 4230 Email: manuel-julian.lopez@vodafone.com> 4232 Lucia Oliva Ballega 4233 Telefonica 4234 Email: lucia.olivaballega.ext@telefonica.com> 4236 Erez Segev 4237 ECI Telecom 4238 Email: erez.segev@ecitele.com> 4240 13. References 4242 13.1. Normative References 4244 [I-D.ietf-opsawg-vpn-common] 4245 barguil, s., Dios, O., Boucadair, M., and Q. WU, "A Layer 4246 2/3 VPN Common YANG Model", draft-ietf-opsawg-vpn- 4247 common-01 (work in progress), September 2020. 4249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4250 Requirement Levels", BCP 14, RFC 2119, 4251 DOI 10.17487/RFC2119, March 1997, 4252 . 4254 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 4255 DOI 10.17487/RFC3688, January 2004, 4256 . 4258 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 4259 Provider-Provisioned Virtual Private Networks (PPVPNs)", 4260 RFC 4110, DOI 10.17487/RFC4110, July 2005, 4261 . 4263 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 4264 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 4265 2006, . 4267 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 4268 the Network Configuration Protocol (NETCONF)", RFC 6020, 4269 DOI 10.17487/RFC6020, October 2010, 4270 . 4272 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 4273 and A. Bierman, Ed., "Network Configuration Protocol 4274 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 4275 . 4277 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 4278 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 4279 . 4281 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 4282 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 4283 2012, . 4285 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 4286 Encodings and Procedures for Multicast in MPLS/BGP IP 4287 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 4288 . 4290 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 4291 RFC 6991, DOI 10.17487/RFC6991, July 2013, 4292 . 4294 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 4295 RFC 7950, DOI 10.17487/RFC7950, August 2016, 4296 . 4298 [RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress 4299 Replication Tunnels in Multicast VPN", RFC 7988, 4300 DOI 10.17487/RFC7988, October 2016, 4301 . 4303 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 4304 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 4305 . 4307 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4308 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4309 May 2017, . 4311 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 4312 Access Control Model", STD 91, RFC 8341, 4313 DOI 10.17487/RFC8341, March 2018, 4314 . 4316 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 4317 Data Model for Layer 2 Virtual Private Network (L2VPN) 4318 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 4319 2018, . 4321 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 4322 "YANG Data Model for Network Access Control Lists (ACLs)", 4323 RFC 8519, DOI 10.17487/RFC8519, March 2019, 4324 . 4326 13.2. Informative References 4328 [I-D.evenwu-opsawg-yang-composed-vpn] 4329 Even, R., Bo, W., Wu, Q., and Y. Cheng, "YANG Data Model 4330 for Composed VPN Service Delivery", draft-evenwu-opsawg- 4331 yang-composed-vpn-03 (work in progress), March 2019. 4333 [I-D.ietf-idr-bgp-model] 4334 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 4335 YANG Model for Service Provider Networks", draft-ietf-idr- 4336 bgp-model-09 (work in progress), June 2020. 4338 [I-D.ietf-pim-yang] 4339 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 4340 Y., and f. hu, "A YANG Data Model for Protocol Independent 4341 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 4342 progress), May 2018. 4344 [I-D.ietf-rtgwg-qos-model] 4345 Choudhary, A., Jethanandani, M., Strahle, N., Aries, E., 4346 and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos- 4347 model-02 (work in progress), July 2020. 4349 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 4350 Discovery Protocol (MSDP)", RFC 3618, 4351 DOI 10.17487/RFC3618, October 2003, 4352 . 4354 [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. 4355 Moore, "Policy Quality of Service (QoS) Information 4356 Model", RFC 3644, DOI 10.17487/RFC3644, November 2003, 4357 . 4359 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 4360 Private Network (VPN) Terminology", RFC 4026, 4361 DOI 10.17487/RFC4026, March 2005, 4362 . 4364 [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., 4365 and A. Gonguet, "Framework for Layer 3 Virtual Private 4366 Networks (L3VPN) Operations and Management", RFC 4176, 4367 DOI 10.17487/RFC4176, October 2005, 4368 . 4370 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 4371 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 4372 DOI 10.17487/RFC4271, January 2006, 4373 . 4375 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 4376 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 4377 . 4379 [RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco 4380 Systems' Solution for Multicast in BGP/MPLS IP VPNs", 4381 RFC 6037, DOI 10.17487/RFC6037, October 2010, 4382 . 4384 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 4385 Code: The Implementation Status Section", RFC 6982, 4386 DOI 10.17487/RFC6982, July 2013, 4387 . 4389 [RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E., 4390 and W. George, "Enhanced Duplicate Address Detection", 4391 RFC 7527, DOI 10.17487/RFC7527, April 2015, 4392 . 4394 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 4395 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 4396 . 4398 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 4399 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 4400 DOI 10.17487/RFC8299, January 2018, 4401 . 4403 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 4404 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 4405 . 4407 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 4408 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 4409 . 4411 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 4412 and R. Wilton, "Network Management Datastore Architecture 4413 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 4414 . 4416 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 4417 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 4418 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 4419 2018, . 4421 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 4422 Routing Management (NMDA Version)", RFC 8349, 4423 DOI 10.17487/RFC8349, March 2018, 4424 . 4426 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 4427 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 4428 DOI 10.17487/RFC8453, August 2018, 4429 . 4431 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 4432 Vinapamula, S., and Q. Wu, "A YANG Module for Network 4433 Address Translation (NAT) and Network Prefix Translation 4434 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 4435 . 4437 Appendix A. L3VPN Examples 4439 A.1. 4G VPN Provisioning Example 4441 L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise 4442 services mainly because several traffic discrimination policies can 4443 be applied within the network to deliver to the mobile customers a 4444 service that meets the SLA requirements. 4446 As it is shown in the Figure 26, typically, an eNodeB (CE) is 4447 directly connected to the access routers of the mobile backhaul and 4448 their logical interfaces (one or many according to the Service type) 4449 are configured in a VPN that transports the packets to the mobile 4450 core platforms. In this example, a 'vpn-node' is created with two 4451 'vpn-network-accesses'. 4453 +-------------+ +------------------+ 4454 | | | PE | 4455 | | 192.0.2.2 | 10.0.0.1 | 4456 | eNodeB |>--------/------->|........... | 4457 | | Vlan 1 | | | 4458 | |>--------/------->|...... | | 4459 | | Vlan 2 | | | | 4460 | | Direct | +-------------+ | 4461 +-------------+ Routing | | vpn-node-id | | 4462 | | 44 | | 4463 | +-------------+ | 4464 | | 4465 +------------------+ 4467 Figure 26: Mobile Backhaul Example 4469 To create a L3VPN service using the L3NM model, the following sample 4470 steps can be followed: 4472 First: Create the 4G VPN Service (Figure 27). 4474 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services 4475 Host: example.com 4476 Content-Type: application/yang-data+json 4478 { 4479 "ietf-l3vpn-ntw:vpn-services": { 4480 "vpn-service": [ 4481 { 4482 "vpn-id": "4G", 4483 "customer-name": "mycustomer", 4484 "vpn-service-topology": "custom", 4485 "description": "VPN to deploy 4G services" 4486 } 4487 ] 4488 } 4489 } 4491 Figure 27: Create VPN Service 4493 Second: Create a VPN Node as depicted in Figure 28. In this type of 4494 service, the VPN Node is equivalent to the VRF configured in the 4495 physical device ('ne-id'=10.0.0.1). 4497 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ 4498 vpn-services/vpn-service=4G 4499 Host: example.com 4500 Content-Type: application/yang-data+json 4502 { 4503 "ietf-l3vpn-ntw:vpn-nodes": { 4504 "vpn-node": [ 4505 { 4506 "vpn-node-id": "44", 4507 "ne-id": "10.0.0.1", 4508 "local-autonomous-system": "65550", 4509 "rd": "0:65550:1", 4510 "vpn-targets": { 4511 "vpn-target": [ 4512 { 4513 "id": "1", 4514 "route-targets": [ 4515 "0:65550:1" 4516 ], 4517 "route-target-type": "both" 4518 } 4519 ] 4520 } 4521 } 4522 ] 4523 } 4524 } 4526 Figure 28: Create VPN Node 4528 Finally, two VPN Network Accesses are created using the same physical 4529 port ('port-id'=1/1/1). Each 'vpn-network-access' has a particular 4530 VLAN (1,2) to differentiate the traffic between: Sync and data 4531 (Figure 29). 4533 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ 4534 vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44 4535 content-type: application/yang-data+json 4537 { 4538 "ietf-l3vpn-ntw:vpn-network-accesses": { 4539 "vpn-network-access": [ 4540 { 4541 "vpn-network-access-id": "1/1/1.1", 4542 "port-id": "1/1/1", 4543 "description": "Interface SYNC to eNODE-B", 4544 "status": { 4545 "admin-enabled": "true" 4546 }, 4547 "vpn-network-access-type": "vpn-common:point-to-point", 4548 "ip-connection": { 4549 "ipv4": { 4550 "address-allocation-type": "static-address", 4551 "static-addresses": { 4552 "primary-address": "1", 4553 "address": [ 4554 { 4555 "address-id": "1", 4556 "s-provider-address": "192.0.2.1", 4557 "s-customer-address": "192.0.2.1", 4558 "s-prefix-length": 32 4559 } 4560 ] 4561 } 4562 } 4563 }, 4564 "routing-protocols": { 4565 "routing-protocol": [ 4566 { 4567 "id": "1", 4568 "type": "vpn-common:direct" 4569 } 4570 ] 4571 } 4572 }, 4573 { 4574 "vpn-network-access-id": "1/1/1.2", 4575 "port-id": "1/1/1", 4576 "description": "Interface DATA to eNODE-B", 4577 "status": { 4578 "admin-enabled": "true" 4579 }, 4580 "ip-connection": { 4581 "ipv4": { 4582 "address-allocation-type": "static-address", 4583 "static-addresses": { 4584 "primary-address": "1", 4585 "address": [ 4586 { 4587 "address-id": "1", 4588 "s-provider-address": "192.0.2.1", 4589 "s-customer-address": "192.0.2.2", 4590 "s-prefix-length": 32 4591 } 4592 ] 4594 } 4595 } 4596 }, 4597 "routing-protocols": { 4598 "routing-protocol": [ 4599 { 4600 "id": "1", 4601 "type": "vpn-common:direct" 4602 } 4603 ] 4604 } 4605 } 4606 ] 4607 } 4608 } 4610 Figure 29: Create VPN Network Access 4612 A.2. Multicast VPN Provisioning Example 4614 IPTV is mainly distributed through multicast over the LANs. In the 4615 following example, PIM-SM is enabled and functional between the PE 4616 and the CE. The PE receives multicast traffic from a CE that is 4617 directly connected to the multicast source. The signaling between PE 4618 and CE is achieved using BGP. Also, RP is statically configured for 4619 a multicast group. 4621 +-----------+ +------+ +------+ +-----------+ 4622 | Multicast |---| CE |--/--| PE |----| Backbone | 4623 | source | +------+ +------+ | IP/MPLS | 4624 +-----------+ +-----------+ 4626 Figure 30: Multicast L3VPN Service Example 4628 To configure a Multicast L3VPN service using the L3NM model the 4629 procedure and the JSON with the data structure is the following: 4631 First, the multicast service is created (see the excerpt of the 4632 request message body shown in Figure 31) 4633 { 4634 "ietf-l3vpn-ntw:vpn-services": { 4635 "vpn-service": [ 4636 { 4637 "vpn-id": "Multicast-IPTV", 4638 "customer-name": "310", 4639 "vpn-service-topology": "vpn-common:hub-spoke", 4640 "description": "Multicast IPTV VPN service" 4641 } 4642 ] 4643 } 4644 } 4646 Figure 31: Create Multicast VPN Service (Excerpt of the Message 4647 Request Body) 4649 Then, the VPN nodes are created (see the excerpt of the request 4650 message body shown in Figure 32). In this example, the VPN Node will 4651 represent VRF configured in the physical device. 4653 { 4654 "ietf-l3vpn-ntw:vpn-node": [ 4655 { 4656 "vpn-node-id": "500003105", 4657 "ne-id": "10.250.2.202", 4658 "autonomous-system": "3816", 4659 "description": "VRF_IPTV_MULTICAST", 4660 "router-id": "10.250.2.202", 4661 "address-family": "ipv4", 4662 "node-role": "vpn-common:hub-role", 4663 "rd": "3816:31050202", 4664 "multicast": { 4665 "enabled": "true", 4666 "rp": { 4667 "rp-group-mappings": { 4668 "rp-group-mapping": [ 4669 { 4670 "id": "1", 4671 "rp-address": "172.19.48.17", 4672 "groups": { 4673 "group": [ 4674 { 4675 "id": "1", 4676 "group-address": "239.130.0.0/15" 4677 } 4678 ] 4679 } 4680 } 4681 ] 4682 }, 4683 "rp-discovery": { 4684 "rp-discovery-type": "vpn-common:static-rp" 4685 } 4686 } 4687 } 4688 } 4689 ] 4690 } 4692 Figure 32: Create Multicast VPN Node (Excerpt of the Message Request 4693 Body) 4695 Finally, create the VPN Network Access with multicast enabled (see 4696 the excerpt of the request message body shown in Figure 33). 4698 { 4699 "ietf-l3vpn-ntw:vpn-network-access": { 4700 "vpn-network-access-id": "1/1/1", 4701 "description": "Connected_to_source", 4702 "status": { 4703 "admin-enabled": "true" 4704 }, 4705 "vpn-network-access-type": "vpn-common:point-to-point", 4706 "ip-connection": { 4707 "ipv4": { 4708 "address-allocation-type": "static-address", 4709 "static-addresses": { 4710 "primary-address": "1", 4711 "address": [ 4712 { 4713 "address-id": "1", 4714 "s-provider-address": "172.19.48.1", 4715 "s-prefix-length": 30 4716 } 4717 ] 4718 } 4719 } 4720 }, 4721 "routing-protocols": { 4722 "routing-protocol": [ 4723 { 4724 "id": "1", 4725 "type": "vpn-common:bgp", 4726 "bgp": { 4727 "peer-autonomous-system": "6500", 4728 "local-autonomous-system": "3816", 4729 "address-family": "ipv4", 4730 "neighbor": "172.19.48.2", 4731 "description": "Connected to CE" 4732 } 4733 } 4734 ] 4735 }, 4736 "service": { 4737 "multicast": { 4738 "multicast-site-type": "source-only", 4739 "multicast-address-family": { 4740 "ipv4": "true" 4741 }, 4742 "protocol-type": "router" 4743 } 4744 } 4745 } 4746 } 4747 Figure 33: Create VPN Network Access (Excerpt of the Message Request 4748 Body) 4750 Appendix B. Implementation Status 4752 This section records the status of known implementations of the Yang 4753 module defined by this specification at the time of posting of this 4754 Internet-Draft, and is based on a proposal described in [RFC6982]. 4755 The description of implementations in this section is intended to 4756 assist the IETF in its decision processes in progressing drafts to 4757 RFCs. Please note that the listing of any individual implementation 4758 here does not imply endorsement by the IETF. Furthermore, no effort 4759 has been spent to verify the information presented here that was 4760 supplied by IETF contributors. This is not intended as, and must not 4761 be construed to be, a catalog of available implementations or their 4762 features. Readers are advised to note that other implementations may 4763 exist. 4765 According to [RFC6982], "this will allow reviewers and working groups 4766 to assign due consideration to documents that have the benefit of 4767 running code, which may serve as evidence of valuable experimentation 4768 and feedback that have made the implemented protocols more mature. 4769 It is up to the individual working groups to use this information as 4770 they see fit". 4772 Note the RFC Editor: As per [RFC6982] guidelines, please remove this 4773 Implementation Status apendix prior publication. 4775 B.1. Nokia Implementation 4777 Details can be found at: https://github.com/IETF-OPSAWG- 4778 WG/l3nm/blob/master/Implementattion/Nokia.txt 4780 B.2. Huawei Implementation 4782 Details can be found at: https://github.com/IETF-OPSAWG- 4783 WG/l3nm/blob/master/Implementattion/Huawei.txt 4785 B.3. Infinera Implementation 4787 Details can be found at: https://github.com/IETF-OPSAWG- 4788 WG/l3nm/blob/master/Implementattion/Infinera.txt 4790 B.4. Ribbon-ECI Implementation 4792 Details can be found at: https://github.com/IETF-OPSAWG- 4793 WG/l3nm/blob/master/Implementattion/Ribbon-ECI.txt 4795 Authors' Addresses 4797 Samier Barguil 4798 Telefonica 4799 Madrid 4800 ES 4802 Email: samier.barguilgiraldo.ext@telefonica.com 4804 Oscar Gonzalez de Dios (editor) 4805 Telefonica 4806 Madrid 4807 ES 4809 Email: oscar.gonzalezdedios@telefonica.com 4811 Mohamed Boucadair (editor) 4812 Orange 4813 Rennes 35000 4814 France 4816 Email: mohamed.boucadair@orange.com 4818 Luis Angel Munoz 4819 Vodafone 4820 ES 4822 Email: luis-angel.munoz@vodafone.com 4824 Alejandro Aguado 4825 Nokia 4826 Madrid 4827 ES 4829 Email: alejandro.aguado_martin@nokia.com