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