idnits 2.17.1 draft-ietf-opsawg-l3sm-l3nm-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 455 has weird spacing: '...--rw id str...' == Line 457 has weird spacing: '...--rw id str...' == Line 459 has weird spacing: '...--rw id str...' == Line 461 has weird spacing: '...--rw id str...' == Line 463 has weird spacing: '...--rw id str...' == (23 more instances...) -- The document date (April 03, 2020) is 1484 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 4364' is mentioned on line 1941, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-08 == Outdated reference: A later version (-12) exists of draft-ietf-rtgwg-qos-model-00 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG S. Barguil 3 Internet-Draft O. Gonzalez de Dios, Ed. 4 Intended status: Standards Track Telefonica 5 Expires: October 5, 2020 M. Boucadair 6 Orange 7 L. Munoz 8 Vodafone 9 A. Aguado 10 Nokia 11 April 03, 2020 13 A Layer 3 VPN Network YANG Model 14 draft-ietf-opsawg-l3sm-l3nm-03 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 L3NM focuses on BGP PE-based Layer 3 VPNs as described in RFCs 4026, 29 4110 and 4364 and Multicast VPNs as described in RFCs 6037, 6513 and 30 7988. 32 Editorial Note (To be removed by RFC Editor) 34 Please update these statements within the document with the RFC 35 number to be assigned to this document: 37 o "This version of this YANG module is part of RFC XXXX;" 39 o "RFC XXXX: Layer 3 VPN Network Model"; 41 o reference: RFC XXXX 43 Also, please update the "revision" date of the YANG module. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at https://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on October 5, 2020. 62 Copyright Notice 64 Copyright (c) 2020 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (https://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 81 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 4. Reference Architecture . . . . . . . . . . . . . . . . . . . 6 83 5. Relation with other YANG Models . . . . . . . . . . . . . . . 8 84 6. Description of the L3NM YANG Module . . . . . . . . . . . . . 10 85 6.1. Overall Structure of the Module . . . . . . . . . . . . . 10 86 6.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 10 87 6.3. Modeling a Layer 3 VPN Service . . . . . . . . . . . . . 11 88 6.3.1. Service Status . . . . . . . . . . . . . . . . . . . 12 89 6.3.2. VPN Node . . . . . . . . . . . . . . . . . . . . . . 13 90 6.3.2.1. Node Status . . . . . . . . . . . . . . . . . . . 16 91 6.3.2.2. RT/RD Assignment/auto-assignment . . . . . . . . 16 92 6.3.2.3. VPN Network Access . . . . . . . . . . . . . . . 17 93 6.3.2.3.1. Connection . . . . . . . . . . . . . . . . . 18 94 6.3.2.3.2. IP Connections . . . . . . . . . . . . . . . 22 95 6.3.2.3.3. Security . . . . . . . . . . . . . . . . . . 24 96 6.3.2.3.4. CE PE Routing Protocols . . . . . . . . . . . 25 97 6.3.2.3.5. Services . . . . . . . . . . . . . . . . . . 29 98 6.3.2.4. Multicast . . . . . . . . . . . . . . . . . . . . 31 99 6.3.3. Concept of Import/Export Profiles . . . . . . . . . . 33 100 6.3.4. Underlay Transport . . . . . . . . . . . . . . . . . 33 101 7. L3NM Module Tree Structure . . . . . . . . . . . . . . . . . 33 102 8. Sample Uses of the L3NM Data Model . . . . . . . . . . . . . 43 103 8.1. Enterprise L3 VPN Services . . . . . . . . . . . . . . . 43 104 8.2. Multi-Domain Resource Management . . . . . . . . . . . . 43 105 8.3. Management of Multicast services . . . . . . . . . . . . 44 106 9. L3VPN Examples . . . . . . . . . . . . . . . . . . . . . . . 44 107 9.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 44 108 9.2. Multicast VPN Provisioning Example . . . . . . . . . . . 48 109 10. L3NM YANG Module . . . . . . . . . . . . . . . . . . . . . . 50 110 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 110 111 12. Security Considerations . . . . . . . . . . . . . . . . . . . 110 112 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 112 113 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 112 114 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 113 115 15.1. Normative References . . . . . . . . . . . . . . . . . . 113 116 15.2. Informative References . . . . . . . . . . . . . . . . . 114 117 Appendix A. Implementation Status . . . . . . . . . . . . . . . 115 118 A.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 115 119 A.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 116 120 A.3. Infinera Implementation . . . . . . . . . . . . . . . . . 119 121 A.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 120 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 122 124 1. Introduction 126 [RFC8299] defines an L3VPN Service YANG data Model (L3SM) that can be 127 used for communication between customers and network operators. Such 128 model is focused on describing the customer view of the VPN services, 129 and provides an abstracted view of the customer's requested services. 130 That approach limits the usage of the L3SM module to the role of a 131 Customer Service Model, according to the terminology defined in 132 [RFC8309]. 134 The YANG data model defined in this document is called L3VPN Network 135 Model (L3NM). The L3NM module is aimed at providing a network- 136 centric view of L3 VPN Services. The data model can be used to 137 facilitate communication between the service orchestrator (or a 138 network operator) and the network controller/orchestrator by allowing 139 for more network-centric information to be included. It enables 140 further capabilities, such as resource management or to serve as a 141 multi-domain orchestration interface, where logical resources (such 142 as route targets or route distinguishers) must be synchronized. 144 This document does not obsolete, but uses, the definitions in 145 [RFC8299]. These two modules are used for similar objectives but 146 with different scopes and views. 148 The L3NM YANG module is initially built with a prune and extend 149 approach, taking as a starting points the YANG module described in 150 [RFC8299]. Nevertheless, this module is not defined as an augment to 151 L3SM because a specific structure is required to meet network- 152 oriented L3 needs. 154 Some of the information captured in the L3SM can be passed by the 155 Orchestrator in the L3NM (e.g., customer) or be used to fed some of 156 the L3NM attributes (e.g., actual forwarding policies). Some of the 157 information captured in L3SM may be maintained locally within the 158 Orchestrator; which is supposed to maintain a "glue" between a 159 Customer view and its network instantiation. Likewise, some of the 160 information captured and exposed using L3NM can fed the service layer 161 (e.g., capabilities) to derive L3SM and drive VPN service order 162 handling. 164 The L3NM module does not attempt to address all deployment cases 165 especially those where the L3VPN connectivity is supported through 166 the coordination of different VPNs in different underlying networks. 167 More complex deployment scenarios involving the coordination of 168 different VPN instances and different technologies to provide end-to- 169 end VPN connectivity are addressed by a complementary YANG model 170 defined in [I-D.evenwu-opsawg-yang-composed-vpn]. 172 2. Requirements Language 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 176 "OPTIONAL" in this document are to be interpreted as described in BCP 177 14 [RFC2119] [RFC8174] when, and only when, they appear in all 178 capitals, as shown here. 180 3. Terminology 182 This document assumes that the reader is familiar with the contents 183 of [RFC6241], [RFC7950], [RFC8299], [RFC8309], and [RFC8453] and uses 184 the terminology defined in those documents. 186 The meaning of the symbols in tree diagrams is defined in [RFC8340]. 188 The document is aimed at modeling BGP PE-based VPNs in a Service 189 Provider Network, so the terms defined in [RFC4026] and [RFC4176] are 190 used. 192 This document makes use of the following terms: 194 o L3 VPN Customer Service Model (L3SM): Describes the requirements 195 of a L3 VPN that interconnects a set of sites from the point of 196 view of the customer. The customer service model does not provide 197 details on the Service Provider Network. The L3 VPN Customer 198 Service model is defined in [RFC8299]. 200 o L3 VPN Service Network Model (L3NM): A YANG module that describes 201 a VPN Service in the Service Provider Network. It contains 202 information of the Service Provider network and might include 203 allocated resources. It can be used by network controllers to 204 manage and control the VPN Service configuration in the Service 205 Provider network. The YANG module can be consumed by a Service 206 Orchestrator to request a VPN Service to a Network controller. 208 o Service Orchestrator: A functional entity that interacts with the 209 customer of a L3 VPN. The Service Orchestrator interacts with the 210 customer using L3SM. The Service Orchestrator is responsible of 211 the CE-PE attachment circuits, the PE selection, and requesting 212 the VPN service to the network controller. 214 o Network Controller: A functional entity responsible for the 215 control and management of the service provider network. 217 o VPN node (vpn-node): An abstraction that represents a set of 218 policies applied to a PE and that belong to a single VPN service 219 (vpn-service). A vpn-service involves one or more vpn-nodes. As 220 it is an abstraction, the network controller will take on how to 221 implement a vpn-node. For example, typically, in a BGP-based VPN, 222 a vpn-node could be mapped into a VRF. 224 o VPN network access (vpn-network-access): An abstraction that 225 represents the network interfaces that are associated to a given 226 vpn-node. Traffic coming from the vpn-network-access belongs to 227 the VPN. The attachment circuits (bearers) between CEs and PEs 228 are terminated in the vpn-network-access. A reference to the 229 bearer is maintained to allow keeping the link between L3SM and 230 L3NM. 232 o VPN Site (vpn-site): A VPN customer's location that is connected 233 to the Service Provider network via a CE-PE link, which can access 234 at least one VPN [RFC4176]. 236 o VPN Service Provider (SP): A Service Provider offers VPN-related 237 services [RFC4176]. 239 o Service Provider (SP) Network: A network able to provide VPN- 240 related services. 242 4. Reference Architecture 244 Figure 1 depicts the reference architecture for L3NM. The figure is 245 an expansion of the architecture presented in Section 5 of [RFC8299] 246 and decomposes the box marked "orchestration" in that figure into 247 three separate functional components called "Service Orchestration", 248 "Network Orchestration", and "Domain Orchestration". 250 Although some deployments may choose to construct a monolithic 251 orchestration component (covering both service and network matters), 252 this document advocates for a clear separation between service and 253 network orchestration components for the sake of better flexibility. 254 Such design adheres to the L3VPN reference architecture defined in 255 Section 1.3 of [RFC4176]. The above separation relies upon a 256 dedicated communication interface between these components and 257 appropriate YANG module that reflect network-related information 258 (that is hidden to customers). 260 The intelligence for translating customer-facing information into 261 network-centric one is implementation-specific. 263 The terminology from [RFC8309] is introduced to show the distinction 264 between the "Customer Service Model", the "Service Delivery Model", 265 the "Network Configuration Model", and the "Device Configuration 266 Model". In that context, the "Domain Orchestration" and "Config 267 Manager" roles may be performed by "Controllers". 269 +---------------+ 270 | Customer | 271 +---------------+ 272 Customer Service Model | 273 l3vpn-svc | 274 +---------------+ 275 | Service | 276 | Orchestration | 277 +---------------+ 278 L3NM Network Model | 279 l3vpn-ntw | 280 +---------------+ 281 | Network | 282 | Orchestration | 283 +---------------+ 284 Network Configuration Model | 285 __________|____________ 286 | | 287 +---------------+ +---------------+ 288 | Domain | | Domain | 289 | Orchestration | | Orchestration | 290 +---------------+ +---------------+ 291 Device | | | 292 Configuration | | | 293 Model | | | 294 +---------+ | | 295 | Config | | | 296 | Manager | | | 297 +---------+ | | 298 | | | 299 | NETCONF/CLI.................. 300 | | | 301 +------------------------------------------------+ 302 Network 304 Figure 1: L3SM and L3NM 306 The L3SM and L3NM modules may also be set in the context of the ACTN 307 architecture [RFC8453]. Figure 2 shows the Customer Network 308 Controller (CNC), the Multi-Domain Service Coordinator (MDSC), and 309 the Provisioning Network Controller (PNC). It also shows the 310 interfaces between these functional blocks: the CNC-MDSC Interface 311 (CMI), the MDSC-PNC Interface (MPI), and the Southbound Interface 312 (SBI). 314 +----------------------------------+ 315 | Customer | 316 | +-----------------------------+ | 317 | | CNC | | 318 | +-----------------------------+ | 319 +----:-----------------------:-----+ 320 : : 321 : L3SM : L3SM 322 : : 323 +---------:---------+ +-------------------+ 324 | MDSC : | | MDSC | 325 | +---------------+ | | (parent) | 326 | | Service | | +-------------------+ 327 | | Orchestration | | : 328 | +---------------+ | : L3NM 329 | : | : 330 | : L3NM | +-------------------+ 331 | : | | MDSC | 332 | +---------------+ | | (child) | 333 | | Network | | +-------------------+ 334 | | Orchestration | | : 335 | +---------------+ | : 336 ---------:--------- : 337 : : 338 : Network Configuration : 339 : : 340 +------------:-------+ +---------:------------+ 341 | Domain : | | : Domain | 342 | Controller : | | : Controller | 343 | +---------+ | | +---------+ | 344 | | PNC | | | | PNC | | 345 | +---------+ | | +---------+ | 346 +------------:-------+ +---------:------------+ 347 : : 348 : Device Configuration : 349 : : 350 +--------+ +--------+ 351 | Device | | Device | 352 +--------+ +--------+ 354 Figure 2: L3SM and L3NM in the Context of ACTN 356 5. Relation with other YANG Models 358 As discussed in the previous section, the L3NM YANG module is meant 359 to manage L3VPN Services within a Service Provider network. The 360 module provides a network-wise view of the service. Such view is 361 only visible within the Service Provider and is not exposed outside. 362 The following discusses how L3NM interfaces with other YANG modules: 364 L3SM: L3NM is not a Customer Service Model. 366 The internal view of the service (L3NM) may be mapped to an 367 external view which is visible to Customers : L3VPN Service YANG 368 data Model (L3SM) [RFC8299]. 370 Typically, the L3NM module can be fed with inputs that are 371 requested by Customers, typically, relying upon a L3SM template. 372 Concretely, some parts of the L3SM module can be directly mapped 373 into L3NM while other parts are generated as a function of the 374 requested service and local guidelines. Some other parts are 375 local to the Service Provider and do not map directly to L3SM. 377 Note that the use of L3NM within a Service Provider does assume 378 nor preclude exposing the VPN service via L3SM. This is 379 deployment-specific. Nevertheless, the design of L3NM tries to 380 align as much as possible with the features supported by the L3SM 381 to ease grafting both L3NM and L3SM for the sake of highly 382 automated VPN service provisioning and delivery. 384 Network Topology Modules: A L3VPN involves nodes that are part of a 385 topology managed by the Service Provider Backbone network. Such 386 topology can be represented as using the network topology module 387 in [RFC8345]. 389 Device Modules: L3NM is not a device model. 391 Once a global VPN service is captured by means of L3NM, the actual 392 activation and provisioning of the VPN service will involve a 393 variety of device modules to tweak the required functions for the 394 delivery of the service. These functions are supported by the VPN 395 nodes and can be managed using device YANG modules. A non- 396 comprehensive list of such device YANG modules is provided below: 398 * Routing management ([RFC8349]) 400 * BGP ([I-D.ietf-idr-bgp-model]) 402 * PIM ([I-D.ietf-pim-yang]) 404 * NAT management ([RFC8512]) 406 * QoS management ([I-D.ietf-rtgwg-qos-model]) 408 * ACL ([RFC8519]) 409 How L3NM is used to derive device-specific actions is 410 implementation-specific. 412 6. Description of the L3NM YANG Module 414 The L3NM module ('ietf-l3vpn-ntw') is meant to manage L3 VPNs in a 415 service provider network. In particular, the 'ietf-l3vpn-ntw' module 416 can be used to create, modify, and retrieve L3VPN Services of a 417 network. 419 The detailed tree structure is provided in Figure 17. 421 6.1. Overall Structure of the Module 423 The 'ietf-l3vpn-ntw' module uses two main containers: 'vpn-services' 424 and 'vpn-profiles' (see Figure 3). 426 The 'vpn-services' container maintains the set of VPN services 427 managed within the service provider's network. 'vpn-service' is the 428 data structure that abstracts a VPN service (Section 6.3). 430 The 'vpn-profiles' container is used by the provider to maintain a 431 set of common VPN profiles that apply to several VPN services 432 (Section 6.2). 434 module: ietf-l3vpn-ntw 435 +--rw l3vpn-ntw 436 +--rw vpn-profiles 437 | ... 438 +--rw vpn-services 439 +--rw vpn-service* [vpn-id] 440 ... 442 Figure 3: Overall L3NM Tree Structure 444 6.2. VPN Profiles 446 The 'vpn-profiles' containers (Figure 4) allow the network provider 447 to define and maintain a set of common VPN profiles that apply to 448 several VPN services. The exaact definition of the profiles is local 449 to each network provider. 451 +--rw l3vpn-ntw 452 +--rw vpn-profiles 453 | +--rw valid-provider-identifiers 454 | +--rw cloud-identifier* [id] {l3vpn-svc:cloud-access}? 455 | | +--rw id string 456 | +--rw encryption-profile-identifier* [id] 457 | | +--rw id string 458 | +--rw qos-profile-identifier* [id] 459 | | +--rw id string 460 | +--rw bfd-profile-identifier* [id] 461 | | +--rw id string 462 | +--rw routing-profile-identifier* [id] 463 | +--rw id string 464 +--rw vpn-services 465 +--rw vpn-service* [vpn-id] 466 ... 468 Figure 4: VPN Profiles Tree Structure 470 6.3. Modeling a Layer 3 VPN Service 472 The 'vpn-service' is the data structure that abstracts a VPN Service 473 in the Service Provider Network. Each 'vpn-service' is uniquely 474 identified by an identifier: 'vpn-id'. Such 'vpn-id' is only 475 meaningful locally within the Network controller. 477 In order to facilitate the identification of the service, 'customer- 478 name' and 'description' attributes may be provided. 480 The 'vpn-service' parameters are: 482 o 'service-status': Allows the control of the operative and 483 administrative status of the service as a whole. 485 o 'vpn-id': Is an identifier that is used to uniquely identify the 486 L3VPN Service within L3NM scope. 488 o 'l3sm-vpn-id': Refers to an identifier of L3SM service. This 489 identifier allows to easily correlate the (network) service as 490 built in the network with a service order. 492 o 'vpn-service-topology': Indicates the network topology for the 493 service: Hub-Spoke, Any-to-Any, and Custom. The deployment on the 494 network is defined by the correct usage of import and export 495 profiles 497 o 'ie-profiles': Defines reusable import/export policies for the 498 same 'vpn-service'. More details are provided in Section 6.3.3 500 o 'underlay-transport': Describes the preference for the transport 501 technology to carry the traffic of the VPN service. 503 A VPN service is typically built by adding instances of 'vpn-node' to 504 the 'vpn-nodes' container. The 'vpn-node' is an abstraction that 505 represents a set of policies applied to a network node and that 506 belong to a single 'vpn-service'. 508 A 'vpn-node' contains 'vpn-network-accesses', which are the 509 interfaces attached to the VPN by which the customer traffic is 510 received. Therefore, the customer sites are connected to the 'vpn- 511 network-accesses'. Note that, as this is a network data model, the 512 information about customers sites is not required in the model. Such 513 information, is rather relevant in the L3SM model. 515 +--rw vpn-service* [vpn-id] 516 +--rw service-status 517 | ... 518 +--rw vpn-id l3vpn-svc:svc-id 519 +--rw l3sm-vpn-id? l3vpn-svc:svc-id 520 +--rw customer-name? string 521 +--rw vpn-service-topology? identityref 522 +--rw description? string 523 +--rw ie-profiles 524 | ... 525 +--rw underlay-transport 526 | ... 528 Figure 5: vpn-service tree structure 530 6.3.1. Service Status 532 The L3NM module allows to track service status ('service-status') of 533 a given VPN service (Figure 6). Both operational and administrative 534 status are maintained together with a timestamp. For example, a 535 service can be created but not put into effect. 537 'admin' and 'ops' status can be used as trigger to detect service 538 anomalies. For example, a service that is declared at the service 539 layer as active but still inactive at the network layer is an 540 indication that network provision actions are needed to align the 541 observed service with the expected service status. 543 +--rw l3vpn-ntw 544 +--rw vpn-profiles 545 | ... 546 +--rw vpn-services 547 +--rw vpn-service* [vpn-id] 548 +--rw service-status 549 | +--rw admin 550 | | +--rw status? operational-type 551 | | +--rw timestamp? yang:date-and-time 552 | +--ro ops 553 | +--ro status? operational-type 554 | +--ro timestamp? yang:date-and-time 555 ... 557 Figure 6: VPN Service Status Tree Structure 559 6.3.2. VPN Node 561 The 'vpn-node' is an abstraction that represents a set of common 562 policies applied on a given network node (tipcally, a PE) and belong 563 to one L3 VPN service. In order to indicate the network nodes where 564 the 'vpn-node' applies, the 'ne-id' must be indicated. The 'vpn- 565 node' includes a parameter to indicate the network node on which it 566 is applied. In the case that the 'ne-id' points to a specific PE, 567 the 'vpn-node' will likely be mapped into a VRF in the node. 568 However, the model also allows to point to an abstract node. In this 569 case, the network controller will decide how to split the 'vpn-node' 570 into VRFs. Soem 'vpn-node' parameters are listed below: 572 o local-autonomous-system: Refers to the autonomous system number 573 that is locally configured in the instance. It can be overwritten 574 for specific purposes in the CE-PE BGP session. 576 o maximum-routes: Set the maximum number of prefixes allowed in the 577 'vpn-node' instance. This value is typically set in the service 578 request. 580 o 'rd' and 'vpn-targets': For the cases the logical resources are 581 managed outside the network controller, the model allows to 582 explicitely indicate the logical resources such as Route targets 583 (RTs) and Route Distinguishers (RDs) (RT,RD). 585 o Multicast: Enable multicast traffic inside the VPN. Refer to 586 Section 6.3.2.4. 588 Under the VPN Node ('vpn-node') container, VPN Network Acesses ('vpn- 589 network-access') can be created. The VPN Network Acess represents 590 the point to which sites are connected. Note that, unlike in L3SM, 591 the L3NM does not need to model the customer site, only the points 592 where the traffic from the site are received. Hence, the VPN Network 593 access contains the connectivity information between the provider's 594 network and the customer premises. The VPN profiles ('vpn-profiles') 595 have a set of routing policies than can be applied during the service 596 creation. 598 module: ietf-l3vpn-ntw 599 +--rw l3vpn-ntw 600 +--rw vpn-profiles 601 | ... 602 +--rw vpn-services 603 +--rw vpn-service* [vpn-id] 604 +--rw vpn-id l3vpn-svc:svc-id 605 + ... 606 +--rw vpn-nodes 607 +--rw vpn-node* [ne-id] 608 +--rw vpn-node-id? union 609 +--rw local-autonomous-system? inet:as-number 610 +--rw description? string 611 +--rw ne-id string 612 +--rw router-id? inet:ip-address 613 +--rw address-family? 614 | l3vpn-svc:address-family 615 +--rw node-role? identityref 616 +--rw rw rd? union 617 +--rw vpn-targets 618 | +--rw vpn-target* [id] 619 | | +--rw id int8 620 | | +--rw route-targets* [route-target] 621 | | | +--rw route-target 622 | | | rt-types:route-target 623 | | +--rw route-target-type 624 | | rt-types:route-target-type 625 | +--rw vpn-policies 626 | +--rw import-policy? leafref 627 | +--rw export-policy? leafref 628 +--rw status 629 | +--rw admin-enabled? boolean 630 | +--ro oper-status? operational-type 631 +--rw vpn-network-accesses 632 | +--rw vpn-network-access* [id] 633 | +--rw id 634 | | l3vpn-svc:svc-id 635 | ... 636 +--rw maximum-routes 637 | +--rw address-family* [af] 638 | +--rw af 639 | | l3vpn-svc:address-family 640 | +--rw maximum-routes? uint32 641 +--rw multicast {l3vpn-svc:multicast}? 642 | ... 643 +--rw node-ie-profile? leafref 645 Figure 7: VPN Node Tree Structure 647 6.3.2.1. Node Status 649 The L3NM module allows to track the status ('status') of the nodes 650 involved in a VPN service (Figure 8). Both operational and 651 administrative status are maintained. Mismatch between an 652 administrative status vs. the operational status can be used as 653 trigger to detect anomalies. 655 +--rw l3vpn-ntw 656 +--rw vpn-profiles 657 | ... 658 +--rw vpn-services 659 +--rw vpn-service* [vpn-id] 660 +--rw vpn-id l3vpn-svc:svc-id 661 ... 662 +--rw vpn-nodes 663 | +--rw vpn-node* [ne-id] 664 | +--rw ne-id string 665 | ... 666 | +--rw status 667 | | +--rw admin-enabled? boolean 668 | | +--ro oper-status? operational-type 670 Figure 8: Node Status Tree Structure 672 6.3.2.2. RT/RD Assignment/auto-assignment 674 For the cases the logical resources are managed outside the network 675 controller, the model allows to explicitely indicate the logical 676 resources such as Route targets (RTs) and Route Distinguishers (RDs) 677 (RT,RD). 679 Three possible behaviors are needed to fulfil the identified use 680 cases: 682 o The network controller auto-assigns logical resources (RTs, RDs). 683 This can apply for new services deployment. 685 o The Network Operator/Service orchestrator assigns explicitly the 686 RTs and RDs. This case will fit with a brownfield scenario where 687 some existing services needs to be updated by the network 688 operators. 690 o The Network Operator/Service orchestrator explicitly wants NO RT/ 691 RD to be assigned. This case will fit in VRF-Lite scenarios, CE 692 testing inside the Network or just for troubleshooting pruposes. 694 Thus a union between two yang data types are included in order to 695 support this scenarios. So, if the leaf is not created in the Yang 696 the expected behavior is the auto-assigns. If the Leaf is created 697 with a valid rd value it will be explicitly assign in the VPN Node 698 and if the leaf is created with an empty value, the RD value will not 699 be deployed in the VPN node. 701 6.3.2.3. VPN Network Access 703 A 'vpn-network-access' represents an entry point to a VPN service 704 (Figure 9). In other words, this container encloses the parameters 705 that describe the access information for the traffic that belongs to 706 a particular L3VPN. As such, every 'vpn-network-access' MUST belong 707 to one and only one 'vpn-node'. 709 A 'vpn-network-access' includes information such as the connection on 710 which the access is defined (see Section 6.3.2.3.1), the 711 encapsulation of the traffic, policies that are applied on the 712 access, etc. 714 A provisioning Network Controller (PNC) [RFC8453] will accept VPN 715 requests containing this construct, using the enclosed data to: 716 configure the router's interface to include the parameters described 717 at the 'vpn-network-access', include the given interface into a VRF, 718 configuring policies or schedulers for processing the incoming 719 traffic, etc. 721 module: ietf-l3vpn-ntw 722 +--rw l3vpn-ntw 723 +--rw vpn-profiles 724 | ... 725 +--rw vpn-services 726 +--rw vpn-service* [vpn-id] 727 +--rw vpn-id l3vpn-svc:svc-id 728 + ... 729 +--rw vpn-node* [ne-id] 730 +--rw ne-id string 731 + ... 732 +--rw vpn-network-accesses 733 | +--rw vpn-network-access* [id] 734 | +--rw id 735 | | l3vpn-svc:svc-id 736 | +--rw port-id? 737 | | l3vpn-svc:svc-id 738 | +--rw description? string 739 | +--rw status 740 | | +--rw admin-enabled? boolean 741 | | +--ro oper-status? operational-type 742 | +--rw vpn-network-access-type? identityref 743 | +--rw connection 744 | | ... 745 | | +--rw bearer 746 | | ... 747 | +--rw ip-connection 748 | | ... 749 | +--rw security 750 | | ... 751 | +--rw routing-protocols 752 | | ... 753 | +--rw service 754 | ... 755 | ... 757 Figure 9: VPN Network Access Tree Structure 759 6.3.2.3.1. Connection 761 The definition of a L3VPN is commonly specified not only at the IP 762 layer, but also requires to identify parameters at the Ethernet 763 layer, such as encapsulation type (e.g., VLAN, QinQ, QinAny, VxLAN, 764 etc.). The 'connection' container represents and groups the set of 765 L2 connectivity from where the traffic of the L3VPN in a particular 766 VPN Network access is coming. 768 Additionally, the bearer-reference and the pseudowire termination are 769 supported. 771 Ethernet encapsulation description is not supported in [RFC8299]. 772 However, this parameters are mandatory to configure the PE 773 interfaces. Thus, In the L3NM, these parameters uses the connection 774 container inside the vpn-network-access. This container defines 775 protocols and parameters to enable connectivity at Layer 2. 777 module: ietf-l3vpn-ntw 778 +--rw l3vpn-ntw 779 +--rw vpn-profiles 780 | ... 781 +--rw vpn-services 782 +--rw vpn-service* [vpn-id] 783 +--rw vpn-id l3vpn-svc:svc-id 784 + ... 785 +--rw vpn-node* [ne-id] 786 +--rw ne-id string 787 + ... 788 +--rw vpn-network-accesses 789 | +--rw vpn-network-access* [id] 790 | +--rw id 791 | | l3vpn-svc:svc-id 792 | + ... 793 | +--rw connection 794 | | +--rw encapsulation-type? identityref 795 | | +--rw logical-interface 796 | | | +--rw peer-reference? uint32 797 | | +--rw tagged-interface 798 | | | +--rw type? identityref 799 | | | +--rw dot1q-vlan-tagged {dot1q}? 800 | | | | +--rw tag-type? identityref 801 | | | | +--rw cvlan-id? uint16 802 | | | +--rw priority-tagged 803 | | | | +--rw tag-type? identityref 804 | | | +--rw qinq {qinq}? 805 | | | | +--rw tag-type? identityref 806 | | | | +--rw svlan-id uint16 807 | | | | +--rw cvlan-id uint16 808 | | | +--rw qinany {qinany}? 809 | | | | +--rw tag-type? identityref 810 | | | | +--rw svlan-id uint16 811 | | | +--rw vxlan {vxlan}? 812 | | | +--rw vni-id uint32 813 | | | +--rw peer-mode? identityref 814 | | | +--rw peer-list* [peer-ip] 815 | | | +--rw peer-ip inet:ip-address 816 | | +--rw bearer 817 | | ... 818 | +--rw ip-connection 819 | | ... 820 | +--rw security 821 | | ... 822 | +--rw routing-protocols 823 | | ... 824 | +--rw service 825 | ... 826 | ... 828 Figure 10: Encapsulation Tree Structure 830 Depending on the control plane implementation, different network 831 scenarios might require additional information for the L3VPN service 832 to be configured and active. For example, an L3VPN Option C service, 833 if no reflection of IPv4 VPN routes is configured via ASBR or route 834 reflector, may require additional configuration (e.g., a new BGP 835 neighbor) to be coordinated between both management systems. This 836 definition requires for every management system participant in the 837 VPN to receive not just their own sites and site-network-accesses, 838 but also to receive information about external ones, identified as an 839 external site-network-access-type. In addition, this particular 840 site-network-access is augmented to include the loopback address of 841 the far-end (remote/external) PE router. 843 module: ietf-l3vpn-ntw 844 +--rw l3vpn-ntw 845 +--rw vpn-profiles 846 | ... 847 +--rw vpn-services 848 +--rw vpn-service* [vpn-id] 849 +--rw vpn-id l3vpn-svc:svc-id 850 + ... 851 +--rw vpn-node* [ne-id] 852 +--rw ne-id string 853 + ... 854 +--rw vpn-network-accesses 855 | +--rw vpn-network-access* [id] 856 | +--rw id 857 | | l3vpn-svc:svc-id 858 | + ... 859 | +--rw connection 860 | | ... 861 | | +--rw bearer 862 | | +--rw bearer-reference? string 863 | | | {l3vpn-svc:bearer-reference}? 864 | | +--rw pseudowire 865 | | | +--rw vcid? uint32 866 | | | +--rw far-end? union 867 | | +--rw vpls 868 | | +--rw vcid? union 869 | | +--rw far-end? union 870 | +--rw ip-connection 871 | | ... 872 | +--rw security 873 | | ... 874 | +--rw routing-protocols 875 | | ... 876 | +--rw service 877 | ... 878 | ... 880 Figure 11: Bearer Tree Structure 882 A site, as per [RFC4176] represents a VPN customer's location that is 883 connected to the Service Provider network via a CE-PE link, which can 884 access at least one VPN. The connection from the site to the Service 885 Provider network is the bearer. Every site is associated with a list 886 of bearers. A bearer is the layer two connections with the site. In 887 the module it is assumed that the bearer has been allocated by the 888 Service Provider at the service orchestration step. The bearer is 889 associated to a network element and a port. Hence, a bearer is just 890 a bearer-reference to allow the translation between L3SM and L3NM. 892 6.3.2.3.2. IP Connections 894 IP connection container (Figure 12) has the parameters of the 'vpn- 895 network-access' addressing information. The address allocated in 896 this container would represent the PE interface address 897 configuration. The IP connection container is designed to support 898 both IPv4 and IPv6. It also supports three options for IP address 899 assignment: Provider DHCP, DHCP relay, and static addressing. 901 In the case of the static addressing, the model supports the 902 assignment of several IP addresses in the same 'vpn-network-access'. 903 To identify which of the addresses is the primary address of a 904 connection ,the "primary-address" reference MUST be set with the 905 corresponding 'address-id'. 907 module: ietf-l3vpn-ntw 908 +--rw l3vpn-ntw 909 +--rw vpn-profiles 910 | ... 911 +--rw vpn-services 912 +--rw vpn-service* [vpn-id] 913 +--rw vpn-id l3vpn-svc:svc-id 914 + ... 915 +--rw vpn-nodes 916 +--rw vpn-node* [ne-id] 917 +--rw ne-id string 918 + ... 919 +--rw status 920 | +--rw admin-enabled? boolean 921 | +--ro oper-status? operational-type 922 +--rw vpn-network-accesses 923 | +--rw vpn-network-access* [id] 924 | +--rw id 925 | | l3vpn-svc:svc-id 926 | + ... 927 | +--rw connection 928 | | ... 929 | +--rw ip-connection 930 | | +--rw ipv4 {l3vpn-svc:ipv4}? 931 | | | +--rw address-allocation-type? 932 | | | | identityref 933 | | | +--rw provider-dhcp 934 | | | | +--rw provider-address? 935 | | | | | inet:ipv4-address 936 | | | | +--rw prefix-length? 937 | | | | | uint8 938 | | | | +--rw (address-assign)? 939 | | | | +--:(number) 940 | | | | | +--rw number-of-dynamic-address? 941 | | | | | uint16 942 | | | | +--:(explicit) 943 | | | | +--rw customer-addresses 944 | | | | +--rw address-group* 945 | | | | [group-id] 946 | | | | +--rw group-id 947 | | | | | string 948 | | | | +--rw start-address? 949 | | | | | inet:ipv4-address 950 | | | | +--rw end-address? 951 | | | | inet:ipv4-address 952 | | | +--rw dhcp-relay 953 | | | | +--rw provider-address? 954 | | | | | inet:ipv4-address 955 | | | | +--rw prefix-length? uint8 956 | | | | +--rw customer-dhcp-servers 957 | | | | +--rw server-ip-address* 958 | | | | inet:ipv4-address 959 | | | +--rw static-addresses 960 | | | +--rw primary-address? leafref 961 | | | +--rw address* [address-id] 962 | | | +--rw address-id string 963 | | | +--rw provider-address? 964 | | | | inet:ipv4-address 965 | | | +--rw customer-address? 966 | | | | inet:ipv4-address 967 | | | +--rw prefix-length? uint8 968 | | +--rw ipv6 {l3vpn-svc:ipv6}? 969 | | | +--rw address-allocation-type? 970 | | | | identityref 971 | | | +--rw provider-dhcp 972 | | | | +--rw provider-address? 973 | | | | | inet:ipv6-address 974 | | | | +--rw prefix-length? 975 | | | | | uint8 976 | | | | +--rw (address-assign)? 977 | | | | +--:(number) 978 | | | | | +--rw number-of-dynamic-address? 979 | | | | | uint16 980 | | | | +--:(explicit) 981 | | | | +--rw customer-addresses 982 | | | | +--rw address-group* 983 | | | | [group-id] 984 | | | | +--rw group-id 985 | | | | | string 986 | | | | +--rw start-address? 987 | | | | | inet:ipv6-address 988 | | | | +--rw end-address? 989 | | | | inet:ipv6-address 990 | | | +--rw dhcp-relay 991 | | | | +--rw provider-address? 992 | | | | | inet:ipv6-address 993 | | | | +--rw prefix-length? uint8 994 | | | | +--rw customer-dhcp-servers 995 | | | | +--rw server-ip-address* 996 | | | | inet:ipv6-address 997 | | | +--rw static-addresses 998 | | | +--rw primary-address? leafref 999 | | | +--rw address* [address-id] 1000 | | | +--rw address-id string 1001 | | | +--rw provider-address? 1002 | | | | inet:ipv6-address 1003 | | | +--rw customer-address? 1004 | | | | inet:ipv6-address 1005 | | | +--rw prefix-length? uint8 1006 | | +--rw oam 1007 | | +--rw bfd {l3vpn-svc:bfd}? 1008 | | +--rw enabled? boolean 1009 | | +--rw (holdtime)? 1010 | | +--:(fixed) 1011 | | | +--rw fixed-value? uint32 1012 | | +--:(profile) 1013 | | +--rw profile-name? leafref 1014 | +--rw security 1015 | | ... 1016 | +--rw routing-protocols 1017 | | ... 1018 | +--rw service 1019 | ... 1021 Figure 12: IP Connection Tree Structure 1023 6.3.2.3.3. Security 1025 The 'security' container specifies the authentication and the 1026 encryption to be applied for a given VPN network access (Figure 13). 1028 module: ietf-l3vpn-ntw 1029 +--rw l3vpn-ntw 1030 +--rw vpn-profiles 1031 | ... 1032 +--rw vpn-services 1033 +--rw vpn-service* [vpn-id] 1034 +--rw vpn-id l3vpn-svc:svc-id 1035 + ... 1036 +--rw vpn-node* [ne-id] 1037 +--rw ne-id string 1038 + ... 1039 +--rw vpn-network-accesses 1040 | +--rw vpn-network-access* [id] 1041 | +--rw id 1042 | | l3vpn-svc:svc-id 1043 | + ... 1044 | +--rw connection 1045 | | ... 1046 | +--rw ip-connection 1047 | | ... 1048 | +--rw security 1049 | | +--rw authentication 1050 | | +--rw encryption {l3vpn-svc:encryption}? 1051 | | | +--rw enabled? boolean 1052 | | | +--rw layer? enumeration 1053 | | +--rw encryption-profile 1054 | | +--rw (profile)? 1055 | | | +--:(provider-profile) 1056 | | | | +--rw profile-name? leafref 1057 | | | +--:(customer-profile) 1058 | | | +--rw algorithm? string 1059 | | +--rw (key-type)? 1060 | | +--:(psk) 1061 | | +--rw preshared-key? string 1062 | +--rw routing-protocols 1063 | | ... 1064 | +--rw service 1065 | ... 1066 | ... 1068 Figure 13: Security Tree Structure 1070 6.3.2.3.4. CE PE Routing Protocols 1072 The model allows the Provider to configure one or more routing 1073 protocols associated with a particular 'vpn-network-access' 1074 (Figure 14). This protocol will run between the PE and the CE. A 1075 routing protocol instance MUST have a type (e.g., bgp, ospf) and an 1076 identifier. The identifier is necessary when multiple instances of 1077 the same protocol have to be configured. 1079 When configuring multiple instances of the same routing protocol, 1080 this does not automatically imply that, from a device configuration 1081 perspective, there will be parallel instances (multiple processes) 1082 running. It will be up to the implementation to use the most 1083 appropriate deployment model. As an example, when multiple BGP peers 1084 need to be implemented, multiple instances of BGP must be configured 1085 as part of this model. However, from a device configuration point of 1086 view, this could be implemented as: 1088 o Multiple BGP processes with a single neighbor running in each 1089 process. 1091 o A single BGP process with multiple neighbors running. 1093 o A combination of both. 1095 To be aligned with [RFC8299], this model supports the following 1096 protocols: 1098 o VRRP: takes only a list of address-family as parameter. VRRP 1099 instance is expected to run on the 'vpn-network-access' interface. 1101 o RIP: takes only a list of address-family as parameter. RIP 1102 instance is expected to run on the 'vpn-network-access' interface. 1104 o BGP: allows to configure a BGP neighbor including parameters like 1105 authentication using a key. The authentication type will be 1106 driven by the implementation but the module supports any 1107 authentication that uses a key as a parameter. A BGP neighbor can 1108 support IPv4, IPv6, or both address families. The module supports 1109 supplying two neighbors (each for a given address family) or one 1110 neighbor (for both IPv4 and IPv6 of "address-family" attribute is 1111 set to both). It is then up to the implementation to drive the 1112 device configuration. 1114 o OSPF: allows the user to configure OSPF to run on the vpn-network- 1115 access interface. An OSPF instance can run ipv4, ipv6 or both. 1116 When only ipv4 address-family is requested, it will be up to the 1117 implementation to drive if OSPFv2 or v3 is used. 1119 o IS-IS: allows the user to configure IS-IS to run on the vpn- 1120 network-access interface. An IS-IS instance can run L1, L2 or 1121 both levels. 1123 The module allows a user to configure one or more IPv4 and/or IPv6 1124 static routes. 1126 Routing configuration does not include low-level policies. These 1127 policies are low level device configurations that must not be part of 1128 an abstracted model. A provider's internal policies (such as 1129 security filters) will be implemented as part of the device 1130 configuration but does not require any input from this model. Some 1131 policies like primary/backup or load-balancing can be inferred from 1132 'access-priority'. 1134 module: ietf-l3vpn-ntw 1135 +--rw l3vpn-ntw 1136 +--rw vpn-profiles 1137 | ... 1138 +--rw vpn-services 1139 +--rw vpn-service* [vpn-id] 1140 +--rw vpn-id l3vpn-svc:svc-id 1141 + ... 1142 +--rw vpn-nodes 1143 +--rw vpn-node* [ne-id] 1144 +--rw ne-id string 1145 + ... 1146 +--rw status 1147 | +--rw admin-enabled? boolean 1148 | +--ro oper-status? operational-type 1149 +--rw vpn-network-accesses 1150 | +--rw vpn-network-access* [id] 1151 | +--rw id 1152 | | l3vpn-svc:svc-id 1153 | + ... 1154 | +--rw connection 1155 | | ... 1156 | +--rw ip-connection 1157 | | ... 1158 | | +--rw oam 1159 | | ... 1160 | +--rw security 1161 | | ... 1162 | +--rw routing-protocols 1163 | | +--rw routing-protocol* [id] 1164 | | +--rw id string 1165 | | +--rw type? identityref 1166 | | +--rw routing-profiles* [id] 1167 | | | +--rw id leafref 1168 | | | +--rw type? ie-type 1169 | | +--rw ospf {l3vpn-svc:rtg-ospf}? 1170 | | | +--rw address-family* 1171 | | | | l3vpn-svc:address-family 1172 | | | +--rw area-address 1173 | | | | yang:dotted-quad 1174 | | | +--rw metric? uint16 1175 | | | +--rw mtu? uint16 1176 | | | +--rw process-id? uint16 1177 | | | +--rw security 1178 | | | | +--rw auth-key? string 1179 | | | +--rw sham-links 1180 | | | {rtg-ospf-sham-link}? 1181 | | | +--rw sham-link* [target-site] 1182 | | | +--rw target-site 1183 | | | | l3vpn-svc:svc-id 1184 | | | +--rw metric? uint16 1185 | | +--rw bgp {l3vpn-svc:rtg-bgp}? 1186 | | | +--rw peer-autonomous-system 1187 | | | | inet:as-number 1188 | | | +--rw local-autonomous-system? 1189 | | | | inet:as-number 1190 | | | +--rw address-family* 1191 | | | | l3vpn-svc:address-family 1192 | | | +--rw neighbor* 1193 | | | | inet:ip-address 1194 | | | +--rw multihop? 1195 | | | | uint8 1196 | | | +--rw security 1197 | | | | +--rw auth-key? string 1198 | | | +--rw status 1199 | | | | +--rw admin-enabled? boolean 1200 | | | | +--ro oper-status? 1201 | | | | operational-type 1202 | | | +--rw description? 1203 | | | string 1204 | | +--rw isis {rtg-isis}? 1205 | | | +--rw address-family* 1206 | | | | l3vpn-svc:address-family 1207 | | | +--rw area-address area-address 1208 | | | +--rw level? isis-level 1209 | | | +--rw metric? uint16 1210 | | | +--rw process-id? uint16 1211 | | | +--rw mode? enumeration 1212 | | | +--rw status 1213 | | | +--rw admin-enabled? boolean 1214 | | | +--ro oper-status? 1215 | | | operational-type 1216 | | +--rw static 1217 | | | +--rw cascaded-lan-prefixes 1218 | | | +--rw ipv4-lan-prefixes* 1219 | | | | [lan next-hop] 1220 | | | | {l3vpn-svc:ipv4}? 1221 | | | | +--rw lan 1222 | | | | | inet:ipv4-prefix 1223 | | | | +--rw lan-tag? string 1224 | | | | +--rw next-hop 1225 | | | | inet:ipv4-address 1226 | | | +--rw ipv6-lan-prefixes* 1227 | | | [lan next-hop] 1228 | | | {l3vpn-svc:ipv6}? 1229 | | | +--rw lan 1230 | | | | inet:ipv6-prefix 1231 | | | +--rw lan-tag? string 1232 | | | +--rw next-hop 1233 | | | inet:ipv6-address 1234 | | +--rw rip {l3vpn-svc:rtg-rip}? 1235 | | | +--rw address-family* 1236 | | | l3vpn-svc:address-family 1237 | | +--rw vrrp {l3vpn-svc:rtg-vrrp}? 1238 | | +--rw address-family* 1239 | | l3vpn-svc:address-family 1240 | +--rw service 1241 | ... 1243 Figure 14: Routing Tree Structure 1245 6.3.2.3.5. Services 1247 The 'services' container specifies the service parameter to apply for 1248 a give VPN network access (Figure 15). The following attributes are 1249 defined: 1251 o TBC 1253 module: ietf-l3vpn-ntw 1254 +--rw l3vpn-ntw 1255 +--rw vpn-profiles 1256 | ... 1257 +--rw vpn-services 1258 +--rw vpn-service* [vpn-id] 1259 +--rw vpn-id l3vpn-svc:svc-id 1260 + ... 1261 +--rw vpn-node* [ne-id] 1262 +--rw ne-id string 1263 + ... 1264 +--rw vpn-network-accesses 1265 | +--rw vpn-network-access* [id] 1266 | +--rw id 1267 | | l3vpn-svc:svc-id 1268 | + ... 1269 | +--rw connection 1270 | | ... 1271 | +--rw ip-connection 1272 | | ... 1273 | +--rw security 1274 | | ... 1275 | +--rw routing-protocols 1276 | | ... 1277 | +--rw service 1278 | +--rw svc-input-bandwidth uint64 1279 | +--rw svc-output-bandwidth uint64 1280 | +--rw svc-mtu uint16 1281 | +--rw qos {l3vpn-svc:qos}? 1282 | | +--rw qos-classification-policy 1283 | | | +--rw rule* [id] 1284 | | | +--rw id 1285 | | | | string 1286 | | | +--rw (match-type)? 1287 | | | | +--:(match-flow) 1288 | | | | | +--rw (l3)? 1289 | | | | | | +--:(ipv4) 1290 | | | | | | | ... 1291 | | | | | | +--:(ipv6) 1292 | | | | | | ... 1293 | | | | | +--rw (l4)? 1294 | | | | | +--:(tcp) 1295 | | | | | | ... 1296 | | | | | +--:(udp) 1297 | | | | | ... 1298 | | | | +--:(match-application) 1299 | | | | +--rw match-application? 1300 | | | | identityref 1301 | | | +--rw target-class-id? 1302 | | | string 1303 | | +--rw qos-profile 1304 | | +--rw (qos-profile)? 1305 | | +--:(standard) 1306 | | | +--rw profile? leafref 1307 | | | +--rw direction? identityref 1308 | | +--:(custom) 1309 | | ... 1310 | +--rw carrierscarrier 1311 | | {l3vpn-svc:carrierscarrier}? 1312 | | +--rw signalling-type? enumeration 1313 | +--rw multicast {l3vpn-svc:multicast}? 1314 | +--rw site-type? enumeration 1315 | +--rw address-family 1316 | | +--rw ipv4? boolean 1317 | | | {l3vpn-svc:ipv4}? 1318 | | +--rw ipv6? boolean 1319 | | {l3vpn-svc:ipv6}? 1320 | +--rw protocol-type? enumeration 1321 | +--rw remote-source? boolean 1322 | ... 1324 Figure 15: Services Tree Structure 1326 6.3.2.4. Multicast 1328 Multicast MAY be enabled for a particular vpn-network-node (see 1329 Figure 16). 1331 The model supports a single type of tree (Any-Source Multicast (ASM), 1332 Source-Specific Multicast (SSM), or bidirectional). 1334 When ASM is used, the model supports the configuration of rendez-vous 1335 points (RPs). RP discovery may be 'static', 'bsr-rp', or 'auto-rp'. 1336 When set to 'static', RP to multicast grouping mapping MUST be 1337 configured as part of the 'rp-group-mappings' container. The RP MAY 1338 be a provider node or a customer node. When the RP is a customer 1339 node, the RP address must be configured using the 'rp-address' leaf 1340 otherwise no RP address is needed. 1342 The model supports RP redundancy through the 'rp-redundancy' leaf. 1343 How the redundancy is achieved is out of scope and is up to the 1344 implementation. 1346 When a particular VPN using ASM requires a more optimal traffic 1347 delivery, 'optimal-traffic-delivery' can be set. When set to 'true', 1348 the implementation must use any mechanism to provide a more optimal 1349 traffic delivery for the customer. Anycast is one of the mechanisms 1350 to enhance RPs redundancy, resilience against failures, and to 1351 recover from failures quickly. 1353 For redundancy purposes, Multicast Source Discovery Protocol (MSDP) 1354 may be enabled and used to share the state about sources between 1355 multiple RPs. The purpose of MSDP in this context is to enhance the 1356 robustness of the multicast service. MSDP may be configured on Non- 1357 RP routers, which is useful in a domain that does not support 1358 multicast sources, but does support multicast transit. 1360 module: ietf-l3vpn-ntw 1361 +--rw l3vpn-ntw 1362 +--rw vpn-profiles 1363 | ... 1364 +--rw vpn-service* [vpn-id] 1365 +--rw vpn-id l3vpn-svc:svc-id 1366 + .. 1367 +--rw vpn-nodes 1368 +--rw vpn-node* [ne-id] 1369 +--rw ne-id string 1370 + ... 1371 +--rw vpn-network-accesses 1372 | ... 1373 +--rw multicast {l3vpn-svc:multicast}? 1374 | +--rw enabled? boolean 1375 | +--rw tree-flavor* identityref 1376 | +--rw rp 1377 | | +--rw rp-group-mappings 1378 | | | +--rw rp-group-mapping* [id] 1379 | | | +--rw id uint16 1380 | | | +--rw provider-managed 1381 | | | | +--rw enabled? 1382 | | | | | boolean 1383 | | | | +--rw rp-redundancy? 1384 | | | | | boolean 1385 | | | | +--rw optimal-traffic-delivery? 1386 | | | | | boolean 1387 | | | | +--rw anycast 1388 | | | | +--rw local-address? 1389 | | | | | inet:ip-address 1390 | | | | +--rw rp-set-address* 1391 | | | | inet:ip-address 1392 | | | +--rw rp-address 1393 | | | | inet:ip-address 1394 | | | +--rw groups 1395 | | | +--rw group* [id] 1396 | | | +--rw id 1397 | | | | uint16 1398 | | | +--rw (group-format) 1399 | | | +--:(group-prefix) 1400 | | | | +--rw group-address? 1401 | | | | inet:ip-prefix 1402 | | | +--:(startend) 1403 | | | +--rw group-start? 1404 | | | | inet:ip-address 1405 | | | +--rw group-end? 1406 | | | inet:ip-address 1407 | | +--rw rp-discovery 1408 | | +--rw rp-discovery-type? identityref 1409 | | +--rw bsr-candidates 1410 | | +--rw bsr-candidate-address* 1411 | | inet:ip-address 1412 | +--rw msdp {msdp}? 1413 | +--rw enabled? boolean 1414 | +--rw peer? inet:ip-address 1415 | +--rw local-address? inet:ip-address 1416 + ... 1418 Figure 16: Multicast Tree Structure 1420 6.3.3. Concept of Import/Export Profiles 1422 The import and export profiles construct contains a list with 1423 information related with route target and distinguishers (RTs and 1424 RDs), grouped and identified by ie-profile-id. The identifier is 1425 then referenced in one or multiple vpn-nodes, so the PNC can identify 1426 RTs and RDs to be configured in the VRF. 1428 6.3.4. Underlay Transport 1430 The model allows to indicate a preference for the underlay transport 1431 technology when activating a L3VPN service. This preference is 1432 especially useful in networks with multiple domains and NNI types. 1433 The model supports these option: BGP, LDP, GRE, SR, SR-TE, and RSVP- 1434 TE as possible underlay transport. 1436 Other profiles can be defined in the future. 1438 This document does not make any assumption about the exact definition 1439 of these profiles. How such profiles are defined is deployment- 1440 specific. 1442 7. L3NM Module Tree Structure 1444 The L3NM Module Tree Structure is depicted in Figure 17. 1446 module: ietf-l3vpn-ntw 1447 +--rw l3vpn-ntw 1448 +--rw vpn-profiles 1449 | +--rw valid-provider-identifiers 1450 | +--rw cloud-identifier* [id] {l3vpn-svc:cloud-access}? 1451 | | +--rw id string 1452 | +--rw encryption-profile-identifier* [id] 1453 | | +--rw id string 1454 | +--rw qos-profile-identifier* [id] 1455 | | +--rw id string 1456 | +--rw bfd-profile-identifier* [id] 1457 | | +--rw id string 1458 | +--rw routing-profile-identifier* [id] 1459 | +--rw id string 1460 +--rw vpn-services 1461 +--rw vpn-service* [vpn-id] 1462 +--rw service-status 1463 | +--rw admin 1464 | | +--rw status? operational-type 1465 | | +--rw timestamp? yang:date-and-time 1466 | +--ro ops 1467 | +--ro status? operational-type 1468 | +--ro timestamp? yang:date-and-time 1469 +--rw vpn-id l3vpn-svc:svc-id 1470 +--rw l3sm-vpn-id? l3vpn-svc:svc-id 1471 +--rw customer-name? string 1472 +--rw vpn-service-topology? identityref 1473 +--rw description? string 1474 +--rw ie-profiles 1475 | +--rw ie-profile* [ie-profile-id] 1476 | +--rw ie-profile-id string 1477 | +--rw rd? rt-types:route-distinguisher 1478 | +--rw vpn-targets 1479 | +--rw vpn-target* [id] 1480 | | +--rw id int8 1481 | | +--rw route-targets* [route-target] 1482 | | | +--rw route-target 1483 | | | rt-types:route-target 1484 | | +--rw route-target-type 1485 | | rt-types:route-target-type 1486 | +--rw vpn-policies 1487 | +--rw import-policy? leafref 1488 | +--rw export-policy? leafref 1489 +--rw underlay-transport 1490 | +--rw type* protocol-type 1491 +--rw vpn-nodes 1492 +--rw vpn-node* [ne-id] 1493 +--rw vpn-node-id? union 1494 +--rw local-autonomous-system? inet:as-number 1495 +--rw description? string 1496 +--rw ne-id string 1497 +--rw router-id? inet:ip-address 1498 +--rw address-family? 1499 | l3vpn-svc:address-family 1500 +--rw node-role? identityref 1501 +--rw rd? union 1502 +--rw vpn-targets 1503 | +--rw vpn-target* [id] 1504 | | +--rw id int8 1505 | | +--rw route-targets* [route-target] 1506 | | | +--rw route-target 1507 | | | rt-types:route-target 1508 | | +--rw route-target-type 1509 | | rt-types:route-target-type 1510 | +--rw vpn-policies 1511 | +--rw import-policy? leafref 1512 | +--rw export-policy? leafref 1513 +--rw status 1514 | +--rw admin-enabled? boolean 1515 | +--ro oper-status? operational-type 1516 +--rw vpn-network-accesses 1517 | +--rw vpn-network-access* [id] 1518 | +--rw id 1519 | | l3vpn-svc:svc-id 1520 | +--rw port-id? 1521 | | l3vpn-svc:svc-id 1522 | +--rw description? string 1523 | +--rw status 1524 | | +--rw admin-enabled? boolean 1525 | | +--ro oper-status? operational-type 1526 | +--rw vpn-network-access-type? identityref 1527 | +--rw connection 1528 | | +--rw encapsulation-type? identityref 1529 | | +--rw logical-interface 1530 | | | +--rw peer-reference? uint32 1531 | | +--rw tagged-interface 1532 | | | +--rw type? identityref 1533 | | | +--rw dot1q-vlan-tagged {dot1q}? 1534 | | | | +--rw tag-type? identityref 1535 | | | | +--rw cvlan-id? uint16 1536 | | | +--rw priority-tagged 1537 | | | | +--rw tag-type? identityref 1538 | | | +--rw qinq {qinq}? 1539 | | | | +--rw tag-type? identityref 1540 | | | | +--rw svlan-id uint16 1541 | | | | +--rw cvlan-id uint16 1542 | | | +--rw qinany {qinany}? 1543 | | | | +--rw tag-type? identityref 1544 | | | | +--rw svlan-id uint16 1545 | | | +--rw vxlan {vxlan}? 1546 | | | +--rw vni-id uint32 1547 | | | +--rw peer-mode? identityref 1548 | | | +--rw peer-list* [peer-ip] 1549 | | | +--rw peer-ip inet:ip-address 1550 | | +--rw bearer 1551 | | +--rw bearer-reference? string 1552 | | | {l3vpn-svc:bearer-reference}? 1553 | | +--rw pseudowire 1554 | | | +--rw vcid? uint32 1555 | | | +--rw far-end? union 1556 | | +--rw vpls 1557 | | +--rw vcid? union 1558 | | +--rw far-end? union 1559 | +--rw ip-connection 1560 | | +--rw ipv4 {l3vpn-svc:ipv4}? 1561 | | | +--rw address-allocation-type? 1562 | | | | identityref 1563 | | | +--rw provider-dhcp 1564 | | | | +--rw provider-address? 1565 | | | | | inet:ipv4-address 1566 | | | | +--rw prefix-length? 1567 | | | | | uint8 1568 | | | | +--rw (address-assign)? 1569 | | | | +--:(number) 1570 | | | | | +--rw number-of-dynamic-address? 1571 | | | | | uint16 1572 | | | | +--:(explicit) 1573 | | | | +--rw customer-addresses 1574 | | | | +--rw address-group* 1575 | | | | [group-id] 1576 | | | | +--rw group-id 1577 | | | | | string 1578 | | | | +--rw start-address? 1579 | | | | | inet:ipv4-address 1580 | | | | +--rw end-address? 1581 | | | | inet:ipv4-address 1582 | | | +--rw dhcp-relay 1583 | | | | +--rw provider-address? 1584 | | | | | inet:ipv4-address 1585 | | | | +--rw prefix-length? uint8 1586 | | | | +--rw customer-dhcp-servers 1587 | | | | +--rw server-ip-address* 1588 | | | | inet:ipv4-address 1589 | | | +--rw static-addresses 1590 | | | +--rw primary-address? leafref 1591 | | | +--rw address* [address-id] 1592 | | | +--rw address-id string 1593 | | | +--rw provider-address? 1594 | | | | inet:ipv4-address 1595 | | | +--rw customer-address? 1596 | | | | inet:ipv4-address 1597 | | | +--rw prefix-length? uint8 1598 | | +--rw ipv6 {l3vpn-svc:ipv6}? 1599 | | | +--rw address-allocation-type? 1600 | | | | identityref 1601 | | | +--rw provider-dhcp 1602 | | | | +--rw provider-address? 1603 | | | | | inet:ipv6-address 1604 | | | | +--rw prefix-length? 1605 | | | | | uint8 1606 | | | | +--rw (address-assign)? 1607 | | | | +--:(number) 1608 | | | | | +--rw number-of-dynamic-address? 1609 | | | | | uint16 1610 | | | | +--:(explicit) 1611 | | | | +--rw customer-addresses 1612 | | | | +--rw address-group* 1613 | | | | [group-id] 1614 | | | | +--rw group-id 1615 | | | | | string 1616 | | | | +--rw start-address? 1617 | | | | | inet:ipv6-address 1618 | | | | +--rw end-address? 1619 | | | | inet:ipv6-address 1620 | | | +--rw dhcp-relay 1621 | | | | +--rw provider-address? 1622 | | | | | inet:ipv6-address 1623 | | | | +--rw prefix-length? uint8 1624 | | | | +--rw customer-dhcp-servers 1625 | | | | +--rw server-ip-address* 1626 | | | | inet:ipv6-address 1627 | | | +--rw static-addresses 1628 | | | +--rw primary-address? leafref 1629 | | | +--rw address* [address-id] 1630 | | | +--rw address-id string 1631 | | | +--rw provider-address? 1632 | | | | inet:ipv6-address 1633 | | | +--rw customer-address? 1634 | | | | inet:ipv6-address 1635 | | | +--rw prefix-length? uint8 1636 | | +--rw oam 1637 | | +--rw bfd {l3vpn-svc:bfd}? 1638 | | +--rw enabled? boolean 1639 | | +--rw (holdtime)? 1640 | | +--:(fixed) 1641 | | | +--rw fixed-value? uint32 1642 | | +--:(profile) 1643 | | +--rw profile-name? leafref 1644 | +--rw security 1645 | | +--rw authentication 1646 | | +--rw encryption {l3vpn-svc:encryption}? 1647 | | | +--rw enabled? boolean 1648 | | | +--rw layer? enumeration 1649 | | +--rw encryption-profile 1650 | | +--rw (profile)? 1651 | | | +--:(provider-profile) 1652 | | | | +--rw profile-name? leafref 1653 | | | +--:(customer-profile) 1654 | | | +--rw algorithm? string 1655 | | +--rw (key-type)? 1656 | | +--:(psk) 1657 | | +--rw preshared-key? string 1658 | +--rw routing-protocols 1659 | | +--rw routing-protocol* [id] 1660 | | +--rw id string 1661 | | +--rw type? identityref 1662 | | +--rw routing-profiles* [id] 1663 | | | +--rw id leafref 1664 | | | +--rw type? ie-type 1665 | | +--rw ospf {l3vpn-svc:rtg-ospf}? 1666 | | | +--rw address-family* 1667 | | | | l3vpn-svc:address-family 1668 | | | +--rw area-address 1669 | | | | yang:dotted-quad 1670 | | | +--rw metric? uint16 1671 | | | +--rw mtu? uint16 1672 | | | +--rw process-id? uint16 1673 | | | +--rw security 1674 | | | | +--rw auth-key? string 1675 | | | +--rw sham-links 1676 | | | {rtg-ospf-sham-link}? 1677 | | | +--rw sham-link* [target-site] 1678 | | | +--rw target-site 1679 | | | | l3vpn-svc:svc-id 1680 | | | +--rw metric? uint16 1681 | | +--rw bgp {l3vpn-svc:rtg-bgp}? 1682 | | | +--rw peer-autonomous-system 1683 | | | | inet:as-number 1684 | | | +--rw local-autonomous-system? 1685 | | | | inet:as-number 1686 | | | +--rw address-family* 1687 | | | | l3vpn-svc:address-family 1688 | | | +--rw neighbor* 1689 | | | | inet:ip-address 1690 | | | +--rw multihop? 1691 | | | | uint8 1692 | | | +--rw security 1693 | | | | +--rw auth-key? string 1694 | | | +--rw status 1695 | | | | +--rw admin-enabled? boolean 1696 | | | | +--ro oper-status? 1697 | | | | operational-type 1698 | | | +--rw description? 1699 | | | string 1700 | | +--rw isis {rtg-isis}? 1701 | | | +--rw address-family* 1702 | | | | l3vpn-svc:address-family 1703 | | | +--rw area-address area-address 1704 | | | +--rw level? isis-level 1705 | | | +--rw metric? uint16 1706 | | | +--rw process-id? uint16 1707 | | | +--rw mode? enumeration 1708 | | | +--rw status 1709 | | | +--rw admin-enabled? boolean 1710 | | | +--ro oper-status? 1711 | | | operational-type 1712 | | +--rw static 1713 | | | +--rw cascaded-lan-prefixes 1714 | | | +--rw ipv4-lan-prefixes* 1715 | | | | [lan next-hop] 1716 | | | | {l3vpn-svc:ipv4}? 1717 | | | | +--rw lan 1718 | | | | | inet:ipv4-prefix 1719 | | | | +--rw lan-tag? string 1720 | | | | +--rw next-hop 1721 | | | | inet:ipv4-address 1722 | | | +--rw ipv6-lan-prefixes* 1723 | | | [lan next-hop] 1724 | | | {l3vpn-svc:ipv6}? 1725 | | | +--rw lan 1726 | | | | inet:ipv6-prefix 1727 | | | +--rw lan-tag? string 1728 | | | +--rw next-hop 1729 | | | inet:ipv6-address 1730 | | +--rw rip {l3vpn-svc:rtg-rip}? 1731 | | | +--rw address-family* 1732 | | | l3vpn-svc:address-family 1733 | | +--rw vrrp {l3vpn-svc:rtg-vrrp}? 1734 | | +--rw address-family* 1735 | | l3vpn-svc:address-family 1736 | +--rw service 1737 | +--rw svc-input-bandwidth uint64 1738 | +--rw svc-output-bandwidth uint64 1739 | +--rw svc-mtu uint16 1740 | +--rw qos {l3vpn-svc:qos}? 1741 | | +--rw qos-classification-policy 1742 | | | +--rw rule* [id] 1743 | | | +--rw id 1744 | | | | string 1745 | | | +--rw (match-type)? 1746 | | | | +--:(match-flow) 1747 | | | | | +--rw (l3)? 1748 | | | | | | +--:(ipv4) 1749 | | | | | | | +--rw ipv4 1750 | | | | | | | +--rw dscp? 1751 | | | | | | | | inet:dscp 1752 | | | | | | | +--rw ecn? 1753 | | | | | | | | uint8 1754 | | | | | | | +--rw length? 1755 | | | | | | | | uint16 1756 | | | | | | | +--rw ttl? 1757 | | | | | | | | uint8 1758 | | | | | | | +--rw protocol? 1759 | | | | | | | | uint8 1760 | | | | | | | +--rw ihl? 1761 | | | | | | | | uint8 1762 | | | | | | | +--rw flags? 1763 | | | | | | | | bits 1764 | | | | | | | +--rw offset? 1765 | | | | | | | | uint16 1766 | | | | | | | +--rw identification? 1767 | | | | | | | | uint16 1768 | | | | | | | +--rw (dst-network)? 1769 | | | | | | | | +--:(dst-ipv4-network) 1770 | | | | | | | | +--rw dst-ipv4-network? 1771 | | | | | | | | inet:ipv4-prefix 1772 | | | | | | | +--rw (source-network)? 1773 | | | | | | | +--:(src-ipv4-network) 1774 | | | | | | | +--rw src-ipv4-network? 1775 | | | | | | | inet:ipv4-prefix 1776 | | | | | | +--:(ipv6) 1777 | | | | | | +--rw ipv6 1778 | | | | | | +--rw dscp? 1779 | | | | | | | inet:dscp 1780 | | | | | | +--rw ecn? 1781 | | | | | | | uint8 1782 | | | | | | +--rw length? 1783 | | | | | | | uint16 1784 | | | | | | +--rw ttl? 1785 | | | | | | | uint8 1786 | | | | | | +--rw protocol? 1787 | | | | | | | uint8 1788 | | | | | | +--rw (destination-network)? 1789 | | | | | | | +--:(dst-ipv6-network) 1790 | | | | | | | +--rw dst-ipv6-network? 1791 | | | | | | | inet:ipv6-prefix 1792 | | | | | | +--rw (src-network)? 1793 | | | | | | | +--:(src-ipv6-network) 1794 | | | | | | | +--rw src-ipv6-network? 1795 | | | | | | | inet:ipv6-prefix 1796 | | | | | | +--rw flow-label? 1797 | | | | | | inet:ipv6-flow-label 1798 | | | | | +--rw (l4)? 1799 | | | | | +--:(tcp) 1800 | | | | | | +--rw tcp 1801 | | | | | | +--rw sequence-number? 1802 | | | | | | | uint32 1803 | | | | | | +--rw ack-number? 1804 | | | | | | | uint32 1805 | | | | | | +--rw data-offset? 1806 | | | | | | | uint8 1807 | | | | | | +--rw reserved? 1808 | | | | | | | uint8 1809 | | | | | | +--rw flags? 1810 | | | | | | | bits 1811 | | | | | | +--rw window-size? 1812 | | | | | | | uint16 1813 | | | | | | +--rw urgent-pointer? 1814 | | | | | | | uint16 1815 | | | | | | +--rw options? 1816 | | | | | | | binary 1817 | | | | | | +--rw (source-port)? 1818 | | | | | | | ... 1819 | | | | | | +--rw (destination-port)? 1820 | | | | | | | ... 1821 | | | | | +--:(udp) 1822 | | | | | +--rw udp 1823 | | | | | +--rw length? 1824 | | | | | | uint16 1825 | | | | | +--rw (source-port)? 1826 | | | | | | ... 1827 | | | | | +--rw (destination-port)? 1828 | | | | | | ... 1829 | | | | +--:(match-application) 1830 | | | | +--rw match-application? 1831 | | | | identityref 1832 | | | +--rw target-class-id? 1833 | | | string 1834 | | +--rw qos-profile 1835 | | +--rw qos-profile* [profile] 1836 | | +--rw profile -> /l3vpn-ntw/... 1837 | | +--rw direction? identityref 1838 | +--rw carrierscarrier 1839 | | {l3vpn-svc:carrierscarrier}? 1840 | | +--rw signalling-type? enumeration 1841 | +--rw multicast {l3vpn-svc:multicast}? 1842 | +--rw site-type? enumeration 1843 | +--rw address-family 1844 | | +--rw ipv4? boolean 1845 | | | {l3vpn-svc:ipv4}? 1846 | | +--rw ipv6? boolean 1847 | | {l3vpn-svc:ipv6}? 1848 | +--rw protocol-type? enumeration 1849 | +--rw remote-source? boolean 1850 +--rw maximum-routes 1851 | +--rw address-family* [af] 1852 | +--rw af 1853 | | l3vpn-svc:address-family 1854 | +--rw maximum-routes? uint32 1855 +--rw multicast {l3vpn-svc:multicast}? 1856 | +--rw enabled? boolean 1857 | +--rw tree-flavor* identityref 1858 | +--rw rp 1859 | | +--rw rp-group-mappings 1860 | | | +--rw rp-group-mapping* [id] 1861 | | | +--rw id uint16 1862 | | | +--rw provider-managed 1863 | | | | +--rw enabled? 1864 | | | | | boolean 1865 | | | | +--rw rp-redundancy? 1866 | | | | | boolean 1867 | | | | +--rw optimal-traffic-delivery? 1868 | | | | | boolean 1869 | | | | +--rw anycast 1870 | | | | +--rw local-address? 1871 | | | | | inet:ip-address 1872 | | | | +--rw rp-set-address* 1873 | | | | inet:ip-address 1874 | | | +--rw rp-address 1875 | | | | inet:ip-address 1876 | | | +--rw groups 1877 | | | +--rw group* [id] 1878 | | | +--rw id 1879 | | | | uint16 1880 | | | +--rw (group-format) 1881 | | | +--:(group-prefix) 1882 | | | | +--rw group-address? 1883 | | | | inet:ip-prefix 1884 | | | +--:(startend) 1885 | | | +--rw group-start? 1886 | | | | inet:ip-address 1887 | | | +--rw group-end? 1888 | | | inet:ip-address 1889 | | +--rw rp-discovery 1890 | | +--rw rp-discovery-type? identityref 1891 | | +--rw bsr-candidates 1892 | | +--rw bsr-candidate-address* 1893 | | inet:ip-address 1894 | +--rw msdp {msdp}? 1895 | +--rw enabled? boolean 1896 | +--rw peer? inet:ip-address 1897 | +--rw local-address? inet:ip-address 1898 +--rw node-ie-profile? leafref 1900 Figure 17 1902 8. Sample Uses of the L3NM Data Model 1904 8.1. Enterprise L3 VPN Services 1906 Enterprise L3VPNs are one of the most demanded services for carriers, 1907 and therefore, L3NM can be useful to automate the tasks of 1908 provisioning and maintenance of these VPNs. Templates and batch 1909 processes can be built, and as a result many parameters are needed 1910 for the creation from scratch of a VPN that can be abstracted to the 1911 upper SDN layer and little manual intervention will be still 1912 required. 1914 Also common addition/removal of sites of an existing customer VPN can 1915 benefit of using L3NM, by creation of workflows that either prune or 1916 add nodes as required from the network data model object. 1918 8.2. Multi-Domain Resource Management 1920 The implementation of L3VPN services which span across 1921 administratively separated domains (i.e., that are under the 1922 administration of different management systems or controllers) 1923 requires some network resources to be synchronized between systems. 1924 Particularly, there are two resources that must be orchestrated and 1925 manage to avoid asymmetric (non-functional) configuration, or the 1926 usage of unavailable resources. 1928 For example, RTs shall be synchronized between PEs. When every PE is 1929 controlled by the same management system, RT allocation can be 1930 performed by the system. In cases where the service spans across 1931 multiple management systems, this task of allocating RTs has to be 1932 aligned across the domains, therefore, the service model must provide 1933 a way to specify RTs. In addition, RDs must also be synchronized to 1934 avoid collisions in RD allocation between separate systems. An 1935 incorrect allocation might lead to the same RD and IP prefixes being 1936 exported by different PE routers. 1938 8.3. Management of Multicast services 1940 Multicast services over L3VPN can be implemented either using dual 1941 PIM MVPNs (also known as Draft Rosen model) [RFC 4364] or 1942 multiprotocol BGP (MBGP)-based MVPNs called Next Generation Multicast 1943 VPN (ng-MVPN) [RFC 6513/6514]. Both methods are supported and 1944 equally effective, but the main difference is that MBGP-based MVPN 1945 does not require multicast configuration on the service provider 1946 backbone. Multiprotocol BGP multicast VPNs employ the intra- 1947 autonomous system (AS) next-generation BGP control plane and PIM 1948 sparse mode as the data plane. The PIM state information is 1949 maintained between the PE routers using the same architecture that is 1950 used for unicast VPNs. 1952 On the other hand, Draft Rosen has limitations such as reduced 1953 options for transport, control plane scalability, availability, 1954 operational inconsistency and the need of maintaining state in the 1955 backbone. Because of this, ng-MNPN is the architectural model that 1956 has been taken as the base for implementing multicast service on 1957 L3VPN. In this scenario, BGP auto discovery is used to discover MVPN 1958 PE members and the customer PIM signaling is sent across provider 1959 core through MP-BGP. The multicast traffic is transported on MPLS 1960 P2MP LSPs. All of the previous information is carried in the MCAST- 1961 VPN BGP NRLI. 1963 9. L3VPN Examples 1965 9.1. 4G VPN Provisioning Example 1967 L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise 1968 services mainly because several traffic discrimination policies can 1969 be applied within the network to deliver to the mobile customers a 1970 service that meets the SLA requirements. 1972 As it is shown in the Figure 18, typically, an eNodeB (CE) is 1973 directly connected to the access routers of the mobile backhaul and 1974 their logical interfaces (one or many according to the Service type) 1975 are configured in a VPN that transports the packets to the mobile 1976 core platforms. In this example, a 'vpn-node' is created with two 1977 'vpn-network-accesses'. 1979 +-------------+ +------------------+ 1980 | | | PE | 1981 | | 192.168.0.2 | 10.0.0.1 | 1982 | eNodeB |>--------/------->|........... | 1983 | | Vlan 1 | | | 1984 | |>--------/------->|...... | | 1985 | | Vlan 2 | | | | 1986 | | Direct | +-------------+ | 1987 +-------------+ Routing | | vpn-node-id | | 1988 | | 44 | | 1989 | +-------------+ | 1990 | | 1991 +------------------+ 1993 Figure 18: Mobile Backhaul Example 1995 To create a L3VPN service using the L3NM model, the following sample 1996 steps can be followed: 1998 First: Create the 4G VPN Service (Figure 19). 2000 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services 2001 Host: example.com 2002 Content-Type: application/yang-data+json 2004 { 2005 "ietf-l3vpn-ntw:vpn-services": { 2006 "vpn-service": [ 2007 "vpn-id": "4G", 2008 "customer-name": "mycustomer", 2009 "vpn-service-topology": "custom", 2010 "description": "VPN to deploy 4G services" 2011 ] 2012 } 2013 } 2015 Figure 19: Create VPN Service 2017 Second: Create a VPN Node as depicted in Figure 20. In this type of 2018 service, the VPN Node is equivalent to the VRF configured in the 2019 physical device ('ne-id'=10.0.0.1). 2021 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ 2022 vpn-services/vpn-service=4G 2023 Host: example.com 2024 Content-Type: application/yang-data+json 2026 { 2027 "ietf-l3vpn-ntw:vpn-nodes": { 2028 "vpn-node": [ 2029 "vpn-node-id": "44", 2030 "ne-id": "10.0.0.1", 2031 "local-autonomous-system": "65550", 2032 "rd": "0:65550:1", 2033 "vpn-targets": { 2034 "vpn-target": [ 2035 "id": "1", 2036 "route-targets": ["route-target": "0:65550:1"], 2037 "route-target-type": "both" 2038 } 2039 } 2040 ] 2041 } 2042 } 2044 Figure 20: Create VPN Node 2046 Finally, two VPN Network Accesses are created using the same physical 2047 port ('port-id'=1/1/1). Each 'vpn-network-access' has a particular 2048 VLAN (1,2) to differentiate the traffic between: Sync and data 2049 (Figure 21). 2051 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ 2052 vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44 2053 content-type: application/yang-data+json 2055 { 2056 "ietf-l3vpn-ntw:vpn-network-accesses": { 2057 "vpn-network-access": [ 2058 { 2059 "vpn-network-access-id": "1/1/1.1", 2060 "port-id": "1/1/1", 2061 "description": "Interface SYNC to eNODE-B", 2062 "status": {"admin-enabled": "true"}, 2063 "vpn-network-access-type": "l3vpn-svc:point-to-point", 2064 "ip-connection": { 2065 "ipv4": { 2066 "address-allocation-type": "l3vpn-svc:static-address", 2067 "static-addresses": { 2068 "primary-address": "1", 2069 "address": [ 2070 "address-id": "1", 2071 "provider-address": "192.168.0.1", 2072 "customer-address": "192.168.0.1", 2073 "prefix-length": "32" 2074 ] 2075 } 2076 } 2077 }, 2078 "routing-protocols": { 2079 "routing-protocol": [ 2080 "id": "1", 2081 "type": "l3vpn-svc:direct" 2082 ] 2083 } 2084 }, 2085 { 2086 "vpn-network-access-id": "1/1/1.2", 2087 "port-id": "1/1/1", 2088 "description": "Interface DATA to eNODE-B", 2089 "status": {"admin-enabled": "true"}, 2090 "ip-connection": { 2091 "ipv4": { 2092 "static-addresses": { 2093 "primary-address": "1", 2094 "address": [ 2095 "address-id": "1", 2096 "provider-address": "192.168.1.1", 2097 "customer-address": "192.168.1.2", 2098 "prefix-length": "32" 2099 ] 2100 } 2101 } 2102 }, 2103 "routing-protocols": { 2104 "routing-protocol": [ 2105 "id": "1", 2106 "type": "l3vpn-svc:direct" 2107 ] 2108 } 2109 } 2110 ] 2111 } 2112 } 2114 Figure 21: Create VPN Network Access 2116 9.2. Multicast VPN Provisioning Example 2118 IPTV is mainly distributed through multicast over the LANs. In the 2119 following example, PIM-SM is enabled and functional between the PE 2120 and the CE. The PE receives multicast traffic from a CE that is 2121 directly connected to the multicast source. The signaling between PE 2122 and CE is achieved using BGP. Also, RP is statically configured for 2123 a multicast group. 2125 +-----------+ +------+ +------+ +-----------+ 2126 | Multicast |---| CE |--/--| PE |----| Backbone | 2127 | source | +------+ +------+ | IP/MPLS | 2128 +-----------+ +-----------+ 2130 Figure 22: Multicast L3VPN Service Example 2132 To configure a Multicast L3VPN service using the L3NM model the 2133 procedure and the JSON with the data structure is the following: 2135 First, the multicast service is created (see the excerpt of the 2136 request message body shown in Figure 23) 2138 "vpn-services": { 2139 "vpn-service": { 2140 "vpn-id": "Multicast_IPTV", 2141 "customer-name": "310", 2142 "vpn-service-topology": "hub-spoke", 2143 "description": "Multicast IPTV VPN service" 2144 } 2145 } 2147 Figure 23: Create Multicast VPN Service (Excerpt of the Message 2148 Request Body) 2150 Then, the VPN nodes are created (see the excerpt of the request 2151 message body shown in Figure 24). In this example, the VPN Node will 2152 represent VRF configured in the physical device. 2154 "vpn-node": [ 2155 "vpn-node-id": "500003105", 2156 "ne-id": "10.250.2.202", 2157 "autonomous-system": "3816", 2158 "description": "VRF_IPTV_MULTICAST", 2159 "router-id": "10.250.2.202", 2160 "address-family": "ipv4", 2161 "node-role": { 2162 "l3vpn-svc:hub-role" 2163 }, 2164 "rd": "3816:31050202", 2165 "multicast": { 2166 "enabled": "true", 2167 "rp": { 2168 "rp-group-mappings": { 2169 "rp-group-mapping": { 2170 "id": "1", 2171 "rp-address": "172.19.48.17", 2172 "groups": { 2173 "group": { 2174 "id": "1", 2175 "group-address": "239.130.0.0/15" 2176 } 2177 } 2178 } 2179 }, 2180 "rp-discovery": { 2181 "rp-discovery-type": { 2182 "l3vpn-svc:static-rp" 2183 } 2184 } 2185 } 2186 } 2187 ] 2189 Figure 24: Create Multicast VPN Node (Excerpt of the Message Request 2190 Body) 2192 Finally, create the VPN Network Access with Multicast enabled (see 2193 the excerpt of the request message body shown in Figure 25) 2195 "vpn-network-access": { 2196 "vpn-network-access-id": "1/1/1", 2197 "description": "Connected_to_source", 2198 "status": { "admin-enabled": "true" }, 2199 "vpn-network-access-type": { 2200 "l3vpn-svc:point-to-point" 2201 }, 2202 "ip-connection": { 2203 "ipv4": { 2204 "address-allocation-type": { 2205 "l3vpn-svc:static-address" 2206 }, 2207 "static-addresses": { 2208 "primary-address": "1", 2209 "address": { 2210 "address-id": "1", 2211 "provider-address": "172.19.48.1", 2212 "prefix-length": "30" 2213 } 2214 } 2215 } 2216 }, 2217 "routing-protocols": { 2218 "routing-protocol": { 2219 "id": "1", 2220 "type": { 2221 "l3vpn-svc:bgp" 2222 }, 2223 "bgp": { 2224 "peer-autonomous-system": "6500", 2225 "local-autonomous-system": "3816", 2226 "address-family": "ipv4", 2227 "neighbor": "172.19.48.2", 2228 "description": "Connected_to_CE" 2229 } 2230 } 2231 }, 2232 "service": { 2233 "multicast": { 2234 "multicast-site-type": "source-only", 2235 "multicast-address-family": { "ipv4": "true" }, 2236 "protocol-type": "router" 2237 } 2238 } 2239 } 2241 Figure 25: Create VPN Network Access (Excerpt of the Message Request 2242 Body) 2244 10. L3NM YANG Module 2246 file "ietf-l3vpn-ntw@2020-03.09.yang" 2247 module ietf-l3vpn-ntw { 2248 yang-version 1.1; 2249 namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw"; 2250 prefix l3vpn-ntw; 2252 import ietf-inet-types { 2253 prefix inet; 2254 reference 2255 "Section 4 of RFC 6991"; 2256 } 2257 import ietf-yang-types { 2258 prefix yang; 2259 reference 2260 "Section 3 of RFC 6991"; 2261 } 2262 import ietf-netconf-acm { 2263 prefix nacm; 2264 reference 2265 "RFC 8341: Network Configuration Access Control Model"; 2266 } 2267 import ietf-routing-types { 2268 prefix rt-types; 2269 reference 2270 "RFC 8294: Common YANG Data Types for the Routing Area"; 2271 } 2272 import ietf-l3vpn-svc { 2273 prefix l3vpn-svc; 2274 reference 2275 "RFC 8299: YANG Data Model for L3VPN Service Delivery"; 2276 } 2277 import ietf-packet-fields { 2278 prefix packet-fields; 2279 reference 2280 "RFC 8519: YANG Data Model for Network Access 2281 Control Lists (ACLs)"; 2282 } 2284 organization 2285 "IETF OPSA (Operations and Management Area) Working Group "; 2286 contact 2287 "WG Web: 2288 WG List: 2289 Author: Samier Barguil 2290 2291 Editor: Oscar Gonzalez de Dios 2292 2293 Author: Mohamed Boucadair 2294 2295 Author: Luis Angel Munoz 2296 2298 Author: Alejandro Aguado 2299 2300 "; 2301 description 2302 "This YANG module defines a generic network-oriented model 2303 for the configuration of Layer 3 Virtual Private Networks. 2304 Copyright (c) 2020 IETF Trust and the persons identified as 2305 authors of the code. All rights reserved. 2307 Redistribution and use in source and binary forms, with or 2308 without modification, is permitted pursuant to, and subject to 2309 the license terms contained in, the Simplified BSD License set 2310 forth in Section 4.c of the IETF Trust's Legal Provisions 2311 Relating to IETF Documents 2312 (https://trustee.ietf.org/license-info). 2314 This version of this YANG module is part of RFC XXXX 2315 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 2316 for full legal notices."; 2318 revision 2020-04-03 { 2319 description 2320 "Initial revision."; 2321 reference 2322 "RFC XXXX: A Layer 3 VPN Network YANG Model"; 2323 // RFC Ed.: replace XXXX with actual RFC number and remove 2324 // this note 2325 } 2327 /* Features */ 2329 feature msdp { 2330 description 2331 "This feature indicates that msdp capabilities 2332 are supported by the VPN."; 2333 } 2335 feature rtg-isis { 2336 description 2337 "This features indicates the support of the ISIS 2338 routing protocol."; 2339 } 2341 feature rtg-ospf-sham-link { 2342 description 2343 "This feature indicates the support of OSPF sham links."; 2344 } 2345 feature input-bw { 2346 description 2347 "This feature indicates the support of 2348 the 'input-bw' limit."; 2349 } 2351 feature dot1q { 2352 description 2353 "This feature indicates the support of 2354 the 'dot1q' encapsulation."; 2355 } 2357 feature qinq { 2358 description 2359 "This feature indicates the support of 2360 the 'qinq' encapsulation."; 2361 } 2363 feature qinany { 2364 description 2365 "This feature indicates the support of 2366 the 'qinany' encapsulation."; 2367 } 2369 feature vxlan { 2370 description 2371 "This feature indicates the support of 2372 the 'vxlan' encapsulation."; 2373 } 2375 /* Typedefs */ 2377 typedef protocol-type { 2378 type enumeration { 2379 enum GRE { 2380 value 0; 2381 description 2382 "Transport based on GRE."; 2383 } 2384 enum LDP { 2385 value 1; 2386 description 2387 "Transport based on LDP."; 2388 } 2389 enum BGP { 2390 value 2; 2391 description 2392 "Transport based on BGP."; 2394 } 2395 enum SR { 2396 value 3; 2397 description 2398 "Transport based on Segment Routing (SR)"; 2399 } 2400 enum SR-TE { 2401 value 4; 2402 description 2403 "Transport based on SR for Traffic Engineering."; 2404 } 2405 enum RSVP-TE { 2406 value 5; 2407 description 2408 "Transport based on RSVP for Traffic Engineering"; 2409 } 2410 enum unknown { 2411 value 6; 2412 description 2413 "Transport UNKNOWN"; 2414 } 2415 } 2416 description 2417 "These attributes are used to identify underlying 2418 protocols when activating an L3VPN service."; 2419 } 2421 typedef area-address { 2422 type string { 2423 pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}'; 2424 } 2425 description 2426 "This type defines the area address format."; 2427 } 2429 typedef isis-level { 2430 type enumeration { 2431 enum level1 { 2432 value 0; 2433 description 2434 "ISIS level 1"; 2435 } 2436 enum level2 { 2437 value 1; 2438 description 2439 "ISIS level 2"; 2440 } 2441 enum level1-2 { 2442 value 2; 2443 description 2444 "ISIS level 1 and 2"; 2445 } 2446 } 2447 description 2448 "Defines the ISIS level for interface and system."; 2449 } 2451 typedef ie-type { 2452 type enumeration { 2453 enum import { 2454 value 0; 2455 description 2456 "Import a routing profile."; 2457 } 2458 enum export { 2459 value 1; 2460 description 2461 "Export a routing profile."; 2462 } 2463 enum both { 2464 value 2; 2465 description 2466 "Import/Export a routing profile."; 2467 } 2468 } 2469 description 2470 "Defines Import-Export routing profiles. 2471 Those profiles can be reused between VPN nodes."; 2472 } 2474 typedef operational-type { 2475 type enumeration { 2476 enum up { 2477 value 0; 2478 description 2479 "Operational status UP/Enabled."; 2480 } 2481 enum down { 2482 value 1; 2483 description 2484 "Operational status DOWN/Disabled."; 2485 } 2486 enum unknown { 2487 value 2; 2488 description 2489 "Operational status UNKNOWN."; 2491 } 2492 } 2493 description 2494 "This attribute is used to determine the 2495 status of a particular element."; 2496 } 2498 /* Identities */ 2500 identity vpn-topology { 2501 description 2502 "Base identity for VPN topology."; 2503 } 2505 identity any-to-any { 2506 base vpn-topology; 2507 description 2508 "Identity for any-to-any VPN topology."; 2509 } 2511 identity hub-spoke { 2512 base vpn-topology; 2513 description 2514 "Identity for Hub-and-Spoke VPN topology."; 2515 } 2517 identity hub-spoke-disjoint { 2518 base vpn-topology; 2519 description 2520 "Identity for Hub-and-Spoke VPN topology 2521 where Hubs cannot communicate with each other."; 2522 } 2524 identity custom { 2525 base vpn-topology; 2526 description 2527 "Identity for CUSTOM VPN topology 2528 where Hubs can act as Spoke for certain part of 2529 the network or Spokes as Hubs."; 2530 } 2532 identity isis { 2533 base l3vpn-svc:routing-protocol-type; 2534 description 2535 "Identity for ISIS protocol type."; 2536 } 2538 identity pseudowire { 2539 base l3vpn-svc:site-network-access-type; 2540 description 2541 "Identity for pseudowire connections."; 2542 } 2544 identity loopback { 2545 base l3vpn-svc:site-network-access-type; 2546 description 2547 "Identity for loopback connections."; 2548 } 2550 identity encapsulation-type { 2551 description 2552 "Identity for the encapsulation type."; 2553 } 2555 identity untagged-int { 2556 base encapsulation-type; 2557 description 2558 "Identity for Ethernet type."; 2559 } 2561 identity tagged-int { 2562 base encapsulation-type; 2563 description 2564 "Identity for the VLAN type."; 2565 } 2567 identity eth-inf-type { 2568 description 2569 "Identity of the Ethernet interface type."; 2570 } 2572 identity tagged { 2573 base eth-inf-type; 2574 description 2575 "Identity of the tagged interface type."; 2576 } 2578 identity untagged { 2579 base eth-inf-type; 2580 description 2581 "Identity of the untagged interface type."; 2582 } 2584 identity lag { 2585 base eth-inf-type; 2586 description 2587 "Identity of the LAG interface type."; 2588 } 2590 identity bearer-inf-type { 2591 description 2592 "Identity for the bearer interface type."; 2593 } 2595 identity port-id { 2596 base bearer-inf-type; 2597 description 2598 "Identity for the priority-tagged interface."; 2599 } 2601 identity lag-id { 2602 base bearer-inf-type; 2603 description 2604 "Identity for the priority-tagged interface."; 2605 } 2607 identity tagged-inf-type { 2608 description 2609 "Identity for the tagged interface type."; 2610 } 2612 identity priority-tagged { 2613 base tagged-inf-type; 2614 description 2615 "Identity for the priority-tagged interface."; 2616 } 2618 identity qinq { 2619 base tagged-inf-type; 2620 description 2621 "Identity for the QinQ tagged interface."; 2622 } 2624 identity dot1q { 2625 base tagged-inf-type; 2626 description 2627 "Identity for the dot1Q VLAN tagged interface."; 2628 } 2630 identity qinany { 2631 base tagged-inf-type; 2632 description 2633 "Identity for the QinAny tagged interface."; 2634 } 2635 identity vxlan { 2636 base tagged-inf-type; 2637 description 2638 "Identity for the VXLAN tagged interface."; 2639 } 2641 identity tag-type { 2642 description 2643 "Base identity from which all tag types are derived."; 2644 } 2646 identity c-vlan { 2647 base tag-type; 2648 description 2649 "A CVLAN tag, normally using the 0x8100 Ethertype."; 2650 } 2652 identity s-vlan { 2653 base tag-type; 2654 description 2655 "An SVLAN tag."; 2656 } 2658 identity c-s-vlan { 2659 base tag-type; 2660 description 2661 "Using both a CVLAN tag and an SVLAN tag."; 2662 } 2664 identity vxlan-peer-mode { 2665 description 2666 "Base identity for the VXLAN peer mode."; 2667 } 2669 identity static-mode { 2670 base vxlan-peer-mode; 2671 description 2672 "Identity for VXLAN access in the static mode."; 2673 } 2675 identity bgp-mode { 2676 base vxlan-peer-mode; 2677 description 2678 "Identity for VXLAN access using BGP EVPN."; 2679 } 2681 identity bw-direction { 2682 description 2683 "Identity for the bandwidth direction."; 2684 } 2686 identity input-bw { 2687 base bw-direction; 2688 description 2689 "Identity for the input bandwidth."; 2690 } 2692 identity output-bw { 2693 base bw-direction; 2694 description 2695 "Identity for the output bandwidth."; 2696 } 2698 identity bw-type { 2699 description 2700 "Identity of the bandwidth type."; 2701 } 2703 identity bw-per-cos { 2704 base bw-type; 2705 description 2706 "Bandwidth is per CoS."; 2707 } 2709 identity bw-per-port { 2710 base bw-type; 2711 description 2712 "Bandwidth is per site network access."; 2713 } 2715 identity bw-per-site { 2716 base bw-type; 2717 description 2718 "Bandwidth is per site. It is applicable to 2719 all the site network accesses within a site."; 2720 } 2722 identity bw-per-svc { 2723 base bw-type; 2724 description 2725 "Bandwidth is per VPN service."; 2726 } 2728 /* Groupings */ 2730 grouping svc-transport-encapsulation { 2731 container underlay-transport { 2732 leaf-list type { 2733 type protocol-type; 2734 ordered-by user; 2735 description 2736 "Protocols used to deliver an L3VPN service."; 2737 } 2738 description 2739 "Container for the Transport Underlay."; 2740 } 2741 description 2742 "This grouping defines the type of underlay transport 2743 for VPN service."; 2744 } 2746 grouping multicast-rp-group-cfg { 2747 choice group-format { 2748 mandatory true; 2749 case group-prefix { 2750 leaf group-address { 2751 type inet:ip-prefix; 2752 description 2753 "A single multicast group prefix."; 2754 } 2755 } 2756 case startend { 2757 leaf group-start { 2758 type inet:ip-address; 2759 description 2760 "The first multicast group address in 2761 the multicast group address range."; 2762 } 2763 leaf group-end { 2764 type inet:ip-address; 2765 description 2766 "The last multicast group address in 2767 the multicast group address range."; 2768 } 2769 } 2770 description 2771 "Choice for multicast group format."; 2772 } 2773 description 2774 "This grouping defines multicast group or 2775 multicast groups for RP-to-group mapping."; 2776 } 2778 grouping vpn-service-multicast { 2779 container multicast { 2780 if-feature "l3vpn-svc:multicast"; 2781 leaf enabled { 2782 type boolean; 2783 default "false"; 2784 description 2785 "Enables multicast."; 2786 } 2787 leaf-list tree-flavor { 2788 type identityref { 2789 base l3vpn-svc:multicast-tree-type; 2790 } 2791 description 2792 "Type of tree to be used."; 2793 } 2794 container rp { 2795 container rp-group-mappings { 2796 list rp-group-mapping { 2797 key "id"; 2798 leaf id { 2799 type uint16; 2800 description 2801 "Unique identifier for the mapping."; 2802 } 2803 container provider-managed { 2804 leaf enabled { 2805 type boolean; 2806 default "false"; 2807 description 2808 "Set to true if the Rendezvous Point (RP) 2809 must be a provider-managed node. Set to false 2810 if it is a customer-managed node."; 2811 } 2812 leaf rp-redundancy { 2813 type boolean; 2814 default "false"; 2815 description 2816 "If true, a redundancy mechanism for the RP 2817 is required."; 2818 } 2819 leaf optimal-traffic-delivery { 2820 type boolean; 2821 default "false"; 2822 description 2823 "If true, the SP must ensure that 2824 traffic uses an optimal path. An SP may use 2825 Anycast RP or RP-tree-to-SPT switchover 2826 architectures."; 2828 } 2829 container anycast { 2830 when "../rp-redundancy = 'true' and 2831 ../optimal-traffic-delivery = 'true'" { 2832 description 2833 "Only applicable if 2834 RP redundancy is 2835 enabled and delivery through 2836 optimal path is activated."; 2837 } 2838 leaf local-address { 2839 type inet:ip-address; 2840 description 2841 "IP local address for PIM RP. 2842 Usually, it corresponds to router 2843 ID or primary address"; 2844 } 2845 leaf-list rp-set-address { 2846 type inet:ip-address; 2847 description 2848 "Address other RP routers 2849 that share the same RP IP address."; 2850 } 2851 description 2852 "PIM Anycast-RP parameters."; 2853 } 2854 description 2855 "Parameters for a provider-managed RP."; 2856 } 2857 leaf rp-address { 2858 when "../provider-managed/enabled = 'false'" { 2859 description 2860 "Relevant when the RP is not provider-managed."; 2861 } 2862 type inet:ip-address; 2863 mandatory true; 2864 description 2865 "Defines the address of the RP. 2866 Used if the RP is customer-managed."; 2867 } 2868 container groups { 2869 list group { 2870 key "id"; 2871 leaf id { 2872 type uint16; 2873 description 2874 "Identifier for the group."; 2875 } 2876 uses multicast-rp-group-cfg; 2877 description 2878 "List of multicast groups."; 2879 } 2880 description 2881 "Multicast groups associated with the RP."; 2882 } 2883 description 2884 "List of RP-to-group mappings."; 2885 } 2886 description 2887 "RP-to-group mappings parameters."; 2888 } 2889 container rp-discovery { 2890 leaf rp-discovery-type { 2891 type identityref { 2892 base l3vpn-svc:multicast-rp-discovery-type; 2893 } 2894 default "l3vpn-svc:static-rp"; 2895 description 2896 "Type of RP discovery used."; 2897 } 2898 container bsr-candidates { 2899 when "derived-from-or-self(../rp-discovery-type, " 2900 + "'l3vpn-svc:bsr-rp')" { 2901 description 2902 "Only applicable if discovery type 2903 is BSR-RP."; 2904 } 2905 leaf-list bsr-candidate-address { 2906 type inet:ip-address; 2907 description 2908 "Address of candidate Bootstrap Router (BSR)."; 2909 } 2910 description 2911 "Container for List of Customer 2912 BSR candidate's addresses."; 2913 } 2914 description 2915 "RP discovery parameters."; 2916 } 2917 description 2918 "RP parameters."; 2919 } 2920 container msdp { 2921 if-feature "msdp"; 2922 leaf enabled { 2923 type boolean; 2924 default "false"; 2925 description 2926 "If true, Multicast Source Discovery Protocol (MSDP) 2927 protocol is activated."; 2928 } 2929 leaf peer { 2930 type inet:ip-address; 2931 description 2932 "IP address of the MSDP peer."; 2933 } 2934 leaf local-address { 2935 type inet:ip-address; 2936 description 2937 "IP address of the local end. This local address 2938 must be configured on the node."; 2939 } 2940 description 2941 "MSDP parameters."; 2942 } 2943 description 2944 "Multicast global parameters for the VPN service."; 2945 } 2946 description 2947 "Grouping for multicast VPN definition."; 2948 } 2950 grouping vpn-service-mpls { 2951 leaf carrierscarrier { 2952 if-feature "l3vpn-svc:carrierscarrier"; 2953 type boolean; 2954 default "false"; 2955 description 2956 "The VPN is using CsC, and so MPLS is required."; 2957 } 2958 description 2959 "Grouping for MPLS Carriers'Carrier definition."; 2960 } 2962 grouping operational-requirements { 2963 leaf requested-site-start { 2964 type yang:date-and-time; 2965 description 2966 "Optional leaf indicating requested date and 2967 time when the service at a particular site is 2968 expected to start."; 2969 } 2970 leaf requested-site-stop { 2971 type yang:date-and-time; 2972 description 2973 "Optional leaf indicating requested date and 2974 time when the service at a particular site is 2975 expected to stop."; 2976 } 2977 description 2978 "This grouping defines some operational 2979 parameters."; 2980 } 2982 grouping status-timestamp { 2983 leaf status { 2984 type operational-type; 2985 description 2986 "Operations status"; 2987 } 2988 leaf timestamp { 2989 type yang:date-and-time; 2990 description 2991 "Indicates the actual date and time when 2992 the service actually started (UP) or 2993 stopped (DOWN)."; 2994 } 2995 description 2996 "This grouping defines some operational 2997 parameters for the service."; 2998 } 3000 grouping service-status { 3001 container service-status { 3002 container admin { 3003 uses status-timestamp; 3004 description 3005 "Administrative service status."; 3006 } 3007 container ops { 3008 config false; 3009 uses status-timestamp; 3010 description 3011 "Operational service status."; 3012 } 3013 description 3014 "Service status."; 3015 } 3016 description 3017 "Service status grouping. Reused in 3018 vpn-node and vpn-network-access."; 3019 } 3020 grouping site-service-basic { 3021 leaf svc-input-bandwidth { 3022 type uint64; 3023 units "bps"; 3024 mandatory true; 3025 description 3026 "From the customer site's perspective, the service 3027 input bandwidth of the connection or download 3028 bandwidth from the SP to the site."; 3029 } 3030 leaf svc-output-bandwidth { 3031 type uint64; 3032 units "bps"; 3033 mandatory true; 3034 description 3035 "From the customer site's perspective, the service 3036 output bandwidth of the connection or upload 3037 bandwidth from the site to the SP."; 3038 } 3039 leaf svc-mtu { 3040 type uint16; 3041 units "bytes"; 3042 mandatory true; 3043 description 3044 "MTU at service level. If the service is IP, 3045 it refers to the IP MTU. If CsC is enabled, 3046 the requested 'svc-mtu' leaf will refer to the 3047 MPLS MTU and not to the IP MTU."; 3048 } 3049 description 3050 "Defines basic service parameters for a site."; 3051 } 3053 grouping site-protection { 3054 container traffic-protection { 3055 if-feature "l3vpn-svc:fast-reroute"; 3056 leaf enabled { 3057 type boolean; 3058 default "false"; 3059 description 3060 "Enables traffic protection of access link."; 3061 } 3062 description 3063 "Fast Reroute service parameters for the site."; 3064 } 3065 description 3066 "Defines protection service parameters for a site."; 3067 } 3068 grouping site-service-mpls { 3069 container carrierscarrier { 3070 if-feature "l3vpn-svc:carrierscarrier"; 3071 leaf signalling-type { 3072 type enumeration { 3073 enum ldp { 3074 description 3075 "Use LDP as the signalling protocol 3076 between the PE and the CE. In this case, 3077 an IGP routing protocol must also be activated."; 3078 } 3079 enum bgp { 3080 description 3081 "Use BGP as the signalling protocol 3082 between the PE and the CE. 3083 In this case, BGP must also be configured as 3084 the routing protocol."; 3085 reference 3086 "RFC 8277: Using BGP to Bind MPLS Labels to 3087 Address Prefixes"; 3088 } 3089 } 3090 default "bgp"; 3091 description 3092 "MPLS signalling type."; 3093 } 3094 description 3095 "This container is used when the customer provides 3096 MPLS-based services. This is only used in the case 3097 of CsC (i.e., a customer builds an MPLS service using 3098 an IP VPN to carry its traffic)."; 3099 } 3100 description 3101 "Defines MPLS service parameters for a site."; 3102 } 3104 grouping ports { 3105 choice source-port { 3106 container source-port-range-or-operator { 3107 uses packet-fields:port-range-or-operator; 3108 description 3109 "Source port definition."; 3110 } 3111 description 3112 "Choice of specifying the source port or referring to 3113 a group of source port numbers."; 3114 } 3115 choice destination-port { 3116 container destination-port-range-or-operator { 3117 uses packet-fields:port-range-or-operator; 3118 description 3119 "Destination port definition."; 3120 } 3121 description 3122 "Choice of specifying a destination port or referring 3123 to a group of destination port numbers."; 3124 } 3125 description 3126 "Choice of specifying a source or destination port numbers."; 3127 } 3129 grouping site-service-qos-profile { 3130 container qos { 3131 if-feature "l3vpn-svc:qos"; 3132 container qos-classification-policy { 3133 list rule { 3134 key "id"; 3135 ordered-by user; 3136 leaf id { 3137 type string; 3138 description 3139 "A description identifying the 3140 qos-classification-policy rule."; 3141 } 3142 choice match-type { 3143 default "match-flow"; 3144 case match-flow { 3145 //uses l3vpn-svc:flow-definition; 3146 choice l3 { 3147 container ipv4 { 3148 uses packet-fields:acl-ip-header-fields; 3149 uses packet-fields:acl-ipv4-header-fields; 3150 description 3151 "Rule set that matches IPv4 header."; 3152 } 3153 container ipv6 { 3154 uses packet-fields:acl-ip-header-fields; 3155 uses packet-fields:acl-ipv6-header-fields; 3156 description 3157 "Rule set that matches IPv6 header."; 3158 } 3159 description 3160 "Either IPv4 or IPv6."; 3161 } 3162 choice l4 { 3163 container tcp { 3164 uses packet-fields:acl-tcp-header-fields; 3165 uses ports; 3166 description 3167 "Rule set that matches TCP header."; 3168 } 3169 container udp { 3170 uses packet-fields:acl-udp-header-fields; 3171 uses ports; 3172 description 3173 "Rule set that matches UDP header."; 3174 } 3175 description 3176 "Can be TCP or UDP"; 3177 } 3178 } 3179 case match-application { 3180 leaf match-application { 3181 type identityref { 3182 base l3vpn-svc:customer-application; 3183 } 3184 description 3185 "Defines the application to match."; 3186 } 3187 } 3188 description 3189 "Choice for classification."; 3190 } 3191 leaf target-class-id { 3192 type string; 3193 description 3194 "Identification of the class of service. 3195 This identifier is internal to the administration."; 3196 } 3197 description 3198 "List of marking rules."; 3199 } 3200 description 3201 "Configuration of the traffic classification policy."; 3202 } 3203 container qos-profile { 3204 list qos-profile { 3205 key profile; 3206 description 3207 "QoS profile. 3208 Can be standard profile or customized profile."; 3209 leaf profile { 3210 type leafref { 3211 path "/l3vpn-ntw/vpn-profiles/" 3212 + "valid-provider-identifiers" 3213 + "/qos-profile-identifier/id"; 3214 } 3215 description 3216 "QoS profile to be used."; 3217 } 3218 leaf direction { 3219 type identityref { 3220 base l3vpn-svc:qos-profile-direction; 3221 } 3222 default "l3vpn-svc:both"; 3223 description 3224 "The direction to which the QoS profile 3225 is applied."; 3226 } 3227 } 3228 description 3229 "QoS profile configuration."; 3230 } 3231 description 3232 "QoS configuration."; 3233 } 3234 description 3235 "This grouping defines QoS parameters for a site."; 3236 } 3238 grouping site-security-authentication { 3239 container authentication { 3240 description 3241 "Authentication parameters."; 3242 } 3243 description 3244 "This grouping defines authentication parameters 3245 for a site."; 3246 } 3248 grouping site-security-encryption { 3249 container encryption { 3250 if-feature "l3vpn-svc:encryption"; 3251 leaf enabled { 3252 type boolean; 3253 default "false"; 3254 description 3255 "If true, traffic encryption on the connection 3256 is required. It is disabled, otherwise."; 3257 } 3258 leaf layer { 3259 when "../enabled = 'true'" { 3260 description 3261 "Require a value for layer when enabled 3262 is true."; 3263 } 3264 type enumeration { 3265 enum layer2 { 3266 description 3267 "Encryption will occur at Layer 2."; 3268 } 3269 enum layer3 { 3270 description 3271 "Encryption will occur at Layer 3. 3272 For example, IPsec may be used when 3273 a customer requests Layer 3 encryption."; 3274 } 3275 } 3276 description 3277 "Layer on which encryption is applied."; 3278 } 3279 description 3280 "Container for CE-PE security encryption."; 3281 } 3282 container encryption-profile { 3283 choice profile { 3284 case provider-profile { 3285 leaf profile-name { 3286 type leafref { 3287 path "/l3vpn-ntw/vpn-profiles/" 3288 + "valid-provider-identifiers" 3289 + "/encryption-profile-identifier/id"; 3290 } 3291 description 3292 "Name of the SP profile to be applied."; 3293 } 3294 } 3295 case customer-profile { 3296 leaf algorithm { 3297 type string; 3298 description 3299 "Encryption algorithm to be used."; 3300 } 3301 } 3302 description 3303 "Choice for encryption profile."; 3304 } 3305 choice key-type { 3306 default "psk"; 3307 case psk { 3308 leaf preshared-key { 3309 type string; 3310 description 3311 "Pre-Shared Key (PSK) coming from the customer."; 3312 } 3313 } 3314 description 3315 "Choice of encryption profile. 3316 The encryption profile can be the provider profile 3317 or customer profile."; 3318 } 3319 description 3320 "Container for encryption profile."; 3321 } 3322 description 3323 "This grouping defines encryption parameters for 3324 a site."; 3325 } 3327 grouping site-routing { 3328 container routing-protocols { 3329 list routing-protocol { 3330 key "id"; 3331 leaf id { 3332 type string; 3333 description 3334 "Unique identifier for routing protocol."; 3335 } 3336 leaf type { 3337 type identityref { 3338 base l3vpn-svc:routing-protocol-type; 3339 } 3340 description 3341 "Type of routing protocol."; 3342 } 3343 list routing-profiles { 3344 key "id"; 3345 leaf id { 3346 type leafref { 3347 path "/l3vpn-ntw/vpn-profiles/" 3348 + "valid-provider-identifiers" 3349 + "/routing-profile-identifier/id"; 3350 } 3351 description 3352 "Routing profile to be used."; 3353 } 3354 leaf type { 3355 type ie-type; 3356 description 3357 "Import, export or both."; 3358 } 3359 description 3360 "Import or Export profile reference"; 3361 } 3362 container ospf { 3363 when "derived-from-or-self(../type, 'l3vpn-svc:ospf')" { 3364 description 3365 "Only applies when protocol is OSPF."; 3366 } 3367 if-feature "l3vpn-svc:rtg-ospf"; 3368 leaf-list address-family { 3369 type l3vpn-svc:address-family; 3370 min-elements 1; 3371 description 3372 "If OSPF is used on this site, this node 3373 contains a configured value. This node 3374 contains at least one address family 3375 to be activated."; 3376 } 3377 leaf area-address { 3378 type yang:dotted-quad; 3379 mandatory true; 3380 description 3381 "Area address."; 3382 } 3383 leaf metric { 3384 type uint16; 3385 default "1"; 3386 description 3387 "Metric of the PE-CE link. It is used 3388 in the routing state calculation and 3389 path selection."; 3390 } 3391 /* Extension */ 3392 leaf mtu { 3393 type uint16; 3394 description 3395 "Maximum transmission unit for a given 3396 OSPF link."; 3397 } 3398 leaf process-id { 3399 type uint16; 3400 description 3401 "Process id of the OSPF CE-PE connection."; 3402 } 3403 uses security-params; 3404 /* End of Extension */ 3405 container sham-links { 3406 if-feature "rtg-ospf-sham-link"; 3407 list sham-link { 3408 key "target-site"; 3409 leaf target-site { 3410 type l3vpn-svc:svc-id; 3411 description 3412 "Target site for the sham link connection. 3413 The site is referred to by its ID."; 3414 } 3415 leaf metric { 3416 type uint16; 3417 default "1"; 3418 description 3419 "Metric of the sham link. It is used in 3420 the routing state calculation and path 3421 selection. The default value is set 3422 to 1."; 3423 } 3424 description 3425 "Creates a sham link with another site."; 3426 } 3427 description 3428 "List of sham links."; 3429 } 3430 description 3431 "OSPF-specific configuration."; 3432 } 3433 container bgp { 3434 when "derived-from-or-self(../type, 'l3vpn-svc:bgp')" { 3435 description 3436 "Only applies when protocol is BGP."; 3437 } 3438 if-feature "l3vpn-svc:rtg-bgp"; 3439 leaf peer-autonomous-system { 3440 type inet:as-number; 3441 mandatory true; 3442 description 3443 "Customer AS number in case the customer 3444 requests BGP routing."; 3445 } 3446 leaf local-autonomous-system { 3447 type inet:as-number; 3448 description 3449 "Local-AS overwrite."; 3450 } 3451 leaf-list address-family { 3452 type l3vpn-svc:address-family; 3453 min-elements 1; 3454 description 3455 "If BGP is used on this site, this node 3456 contains a configured value. This node 3457 contains at least one address family 3458 to be activated."; 3459 } 3460 /* Extension */ 3461 leaf-list neighbor { 3462 type inet:ip-address; 3463 description 3464 "IP address(es) of the BGP neighbor. An IPv4 3465 and IPv6 neighbors may be indicated if 3466 two sessions will be used for IPv4 and IPv6."; 3467 } 3468 leaf multihop { 3469 type uint8; 3470 description 3471 "Describes the number of hops allowed between 3472 a given BGP neighbor and the PE router."; 3473 } 3474 uses security-params; 3475 uses status-params; 3476 leaf description { 3477 type string; 3478 description 3479 "Includes a description of the BGP session. 3480 Such description is meant to be used for 3481 diagnosis purposes. The semantic of the description 3482 is local to an implementation."; 3483 } 3484 /* End- Extension */ 3485 description 3486 "BGP-specific configuration."; 3487 } 3488 container isis { 3489 when "derived-from-or-self(../type, 'l3vpn-ntw:isis')" { 3490 description 3491 "Only applies when protocol is ISIS."; 3492 } 3493 if-feature "rtg-isis"; 3494 leaf-list address-family { 3495 type l3vpn-svc:address-family; 3496 min-elements 1; 3497 description 3498 "If ISIS is used on this site, this node 3499 contains a configured value. This node 3500 contains at least one address family 3501 to be activated."; 3502 } 3503 leaf area-address { 3504 type area-address; 3505 mandatory true; 3506 description 3507 "Area address."; 3508 } 3509 leaf level { 3510 type isis-level; 3511 description 3512 "level1, level2 or level1-2"; 3513 } 3514 leaf metric { 3515 type uint16; 3516 default "1"; 3517 description 3518 "Metric of the PE-CE link. It is used 3519 in the routing state calculation and 3520 path selection."; 3521 } 3522 leaf process-id { 3523 type uint16; 3524 description 3525 "Process id of the ISIS CE-PE connection."; 3526 } 3527 leaf mode { 3528 type enumeration { 3529 enum active { 3530 description 3531 "Interface sends or receives ISIS protocol 3532 control packets."; 3533 } 3534 enum passive { 3535 description 3536 "Suppresses the sending of ISIS routing updates 3537 through the specified interface."; 3538 } 3539 } 3540 default "active"; 3541 description 3542 "ISIS interface mode type."; 3543 } 3544 uses status-params; 3545 description 3546 "ISIS-specific configuration."; 3547 } 3548 container static { 3549 when "derived-from-or-self(../type, 'l3vpn-svc:static')" { 3550 description 3551 "Only applies when protocol is static. 3552 BGP activation requires the SP to know 3553 the address of the customer peer. When 3554 BGP is enabled, the 'static-address' 3555 allocation type for the IP connection 3556 MUST be used."; 3557 } 3558 container cascaded-lan-prefixes { 3559 list ipv4-lan-prefixes { 3560 if-feature "l3vpn-svc:ipv4"; 3561 key "lan next-hop"; 3562 leaf lan { 3563 type inet:ipv4-prefix; 3564 description 3565 "LAN prefixes."; 3566 } 3567 leaf lan-tag { 3568 type string; 3569 description 3570 "Internal tag to be used in VPN policies."; 3571 } 3572 leaf next-hop { 3573 type inet:ipv4-address; 3574 description 3575 "Next-hop address to use on the customer side."; 3576 } 3577 description 3578 "List of LAN prefixes for the site."; 3579 } 3580 list ipv6-lan-prefixes { 3581 if-feature "l3vpn-svc:ipv6"; 3582 key "lan next-hop"; 3583 leaf lan { 3584 type inet:ipv6-prefix; 3585 description 3586 "LAN prefixes."; 3587 } 3588 leaf lan-tag { 3589 type string; 3590 description 3591 "Internal tag to be used in VPN policies."; 3592 } 3593 leaf next-hop { 3594 type inet:ipv6-address; 3595 description 3596 "Next-hop address to use on the customer side."; 3597 } 3598 description 3599 "List of LAN prefixes for the site."; 3600 } 3601 description 3602 "LAN prefixes from the customer."; 3603 } 3604 description 3605 "Configuration specific to static routing."; 3606 } 3607 container rip { 3608 when "derived-from-or-self(../type, 'l3vpn-svc:rip')" { 3609 description 3610 "Only applies when the protocol is RIP. For IPv4, 3611 the model assumes that RIP version 2 is used."; 3612 } 3613 if-feature "l3vpn-svc:rtg-rip"; 3614 leaf-list address-family { 3615 type l3vpn-svc:address-family; 3616 min-elements 1; 3617 description 3618 "If RIP is used on this site, this node 3619 contains a configured value. This node 3620 contains at least one address family 3621 to be activated."; 3622 } 3623 description 3624 "Configuration specific to RIP routing."; 3625 } 3626 container vrrp { 3627 when "derived-from-or-self(../type, 'l3vpn-svc:vrrp')" { 3628 description 3629 "Only applies when protocol is VRRP."; 3630 } 3631 if-feature "l3vpn-svc:rtg-vrrp"; 3632 leaf-list address-family { 3633 type l3vpn-svc:address-family; 3634 min-elements 1; 3635 description 3636 "If VRRP is used on this site, this node 3637 contains a configured value. This node contains 3638 at least one address family to be activated."; 3639 } 3640 description 3641 "Configuration specific to VRRP routing."; 3642 } 3643 description 3644 "List of routing protocols used on 3645 the site. This list can be augmented."; 3646 } 3647 description 3648 "Defines routing protocols."; 3649 } 3650 description 3651 "Grouping for routing protocols."; 3652 } 3654 grouping site-attachment-ip-connection { 3655 container ip-connection { 3656 container ipv4 { 3657 if-feature "l3vpn-svc:ipv4"; 3658 leaf address-allocation-type { 3659 type identityref { 3660 base l3vpn-svc:address-allocation-type; 3661 } 3662 must "not(derived-from-or-self(current(), 'l3vpn-svc:slaac')" 3663 + " or derived-from-or-self(current(), " 3664 + "'l3vpn-svc:provider-dhcp-slaac'))" { 3665 error-message "SLAAC is only applicable to IPv6"; 3666 } 3667 description 3668 "Defines how addresses are allocated. 3669 If there is no value for the address 3670 allocation type, then IPv4 is not enabled."; 3671 } 3672 container provider-dhcp { 3673 when "derived-from-or-self(../address-allocation-type, " 3674 + "'l3vpn-svc:provider-dhcp')" { 3675 description 3676 "Only applies when addresses are allocated by DHCP."; 3677 } 3678 leaf provider-address { 3679 type inet:ipv4-address; 3680 description 3681 "Address of provider side. If provider-address is not 3682 specified, then prefix length should not be specified 3683 either. It also implies provider-dhcp allocation is 3684 not enabled. If provider-address is specified, then 3685 the prefix length may or may not be specified."; 3686 } 3687 leaf prefix-length { 3688 type uint8 { 3689 range "0..32"; 3690 } 3691 must '(../provider-address)' { 3692 error-message 3693 "If the prefix length is specified, provider-address 3694 must also be specified."; 3695 description 3696 "If the prefix length is specified, provider-address 3697 must also be specified."; 3698 } 3699 description 3700 "Subnet prefix length expressed in bits. 3701 If not specified, or specified as zero, 3702 this means the customer leaves the actual 3703 prefix length value to the provider."; 3704 } 3705 choice address-assign { 3706 default "number"; 3707 case number { 3708 leaf number-of-dynamic-address { 3709 type uint16; 3710 default "1"; 3711 description 3712 "Describes the number of IP addresses 3713 the customer requires."; 3714 } 3715 } 3716 case explicit { 3717 container customer-addresses { 3718 list address-group { 3719 key "group-id"; 3720 leaf group-id { 3721 type string; 3722 description 3723 "Group-id for the address range from 3724 start-address to end-address."; 3725 } 3726 leaf start-address { 3727 type inet:ipv4-address; 3728 description 3729 "First address."; 3730 } 3731 leaf end-address { 3732 type inet:ipv4-address; 3733 description 3734 "Last address."; 3735 } 3736 description 3737 "Describes IP addresses allocated by DHCP. 3738 When only start-address or only end-address 3739 is present, it represents a single address. 3741 When both start-address and end-address are 3742 specified, it implies a range inclusive of both 3743 addresses. If no address is specified, it implies 3744 customer addresses group is not supported."; 3745 } 3746 description 3747 "Container for customer addresses is allocated by 3748 DHCP."; 3749 } 3750 } 3751 description 3752 "Choice for the way to assign addresses."; 3753 } 3754 description 3755 "DHCP allocated addresses related parameters."; 3756 } 3757 container dhcp-relay { 3758 when "derived-from-or-self(../address-allocation-type, " 3759 + "'l3vpn-svc:provider-dhcp-relay')" { 3760 description 3761 "Only applies when provider is required to implement 3762 DHCP relay function."; 3763 } 3764 leaf provider-address { 3765 type inet:ipv4-address; 3766 description 3767 "Address of provider side. If provider-address is not 3768 specified, then prefix length should not be specified 3769 either. It also implies provider-dhcp allocation is 3770 not enabled. If provider-address is specified, then 3771 prefix length may or may not be specified."; 3772 } 3773 leaf prefix-length { 3774 type uint8 { 3775 range "0..32"; 3776 } 3777 must '(../provider-address)' { 3778 error-message 3779 "If prefix length is specified, provider-address 3780 must also be specified."; 3781 description 3782 "If prefix length is specified, provider-address 3783 must also be specified."; 3784 } 3785 description 3786 "Subnet prefix length expressed in bits. If not 3787 specified, or specified as zero, this means the 3788 customer leaves the actual prefix length value 3789 to the provider."; 3790 } 3791 container customer-dhcp-servers { 3792 leaf-list server-ip-address { 3793 type inet:ipv4-address; 3794 description 3795 "IP address of customer DHCP server."; 3796 } 3797 description 3798 "Container for list of customer DHCP servers."; 3799 } 3800 description 3801 "DHCP relay provided by operator."; 3802 } 3803 container static-addresses { 3804 when "derived-from-or-self(../address-allocation-type, " 3805 + "'l3vpn-svc:static-address')" { 3806 description 3807 "Only applies when protocol allocation type is static."; 3808 } 3809 leaf primary-address { 3810 type leafref { 3811 path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/" 3812 + "vpn-node/vpn-network-accesses/vpn-network-access/" 3813 + "ip-connection/ipv4/static-addresses/address/" 3814 + "address-id"; 3815 } 3816 description 3817 "Principal address of the connection."; 3818 } 3819 list address { 3820 key "address-id"; 3821 leaf address-id { 3822 type string; 3823 description 3824 "IPv4 Address"; 3825 } 3826 leaf provider-address { 3827 type inet:ipv4-address; 3828 description 3829 "IPv4 Address List of the provider side. 3830 When the protocol allocation type is static, 3831 the provider address must be configured."; 3832 } 3833 leaf customer-address { 3834 type inet:ipv4-address; 3835 description 3836 "IPv4 Address of customer side."; 3838 } 3839 leaf prefix-length { 3840 type uint8 { 3841 range "0..32"; 3842 } 3843 description 3844 "Subnet prefix length expressed in bits. 3845 It is applied to both provider-address 3846 and customer-address."; 3847 } 3848 description 3849 "Describes IPv4 addresses used."; 3850 } 3851 description 3852 "Describes IPv4 addresses used."; 3853 } 3854 description 3855 "IPv4-specific parameters."; 3856 } 3857 container ipv6 { 3858 if-feature "l3vpn-svc:ipv6"; 3859 leaf address-allocation-type { 3860 type identityref { 3861 base l3vpn-svc:address-allocation-type; 3862 } 3863 description 3864 "Defines how addresses are allocated. 3865 If there is no value for the address 3866 allocation type, then IPv6 is 3867 not enabled."; 3868 } 3869 container provider-dhcp { 3870 when "derived-from-or-self(../address-allocation-type, " 3871 + "'l3vpn-svc:provider-dhcp') " 3872 + "or derived-from-or-self(../address-allocation-type, " 3873 + "'l3vpn-svc:provider-dhcp-slaac')" { 3874 description 3875 "Only applies when addresses are allocated by DHCP."; 3876 } 3877 leaf provider-address { 3878 type inet:ipv6-address; 3879 description 3880 "Address of the provider side. If provider-address 3881 is not specified, then prefix length should not be 3882 specified either. It also implies provider-dhcp 3883 allocation is not enabled. If provider-address is 3884 specified, then prefix length may or may 3885 not be specified."; 3887 } 3888 leaf prefix-length { 3889 type uint8 { 3890 range "0..128"; 3891 } 3892 must '(../provider-address)' { 3893 error-message 3894 "If prefix length is specified, provider-address 3895 must also be specified."; 3896 description 3897 "If prefix length is specified, provider-address 3898 must also be specified."; 3899 } 3900 description 3901 "Subnet prefix length expressed in bits. If not 3902 specified, or specified as zero, this means the 3903 customer leaves the actual prefix length value 3904 to the provider."; 3905 } 3906 choice address-assign { 3907 default "number"; 3908 case number { 3909 leaf number-of-dynamic-address { 3910 type uint16; 3911 default "1"; 3912 description 3913 "Describes the number of IP addresses the customer 3914 requires."; 3915 } 3916 } 3917 case explicit { 3918 container customer-addresses { 3919 list address-group { 3920 key "group-id"; 3921 leaf group-id { 3922 type string; 3923 description 3924 "Group-id for the address range from 3925 start-address to end-address."; 3926 } 3927 leaf start-address { 3928 type inet:ipv6-address; 3929 description 3930 "First address."; 3931 } 3932 leaf end-address { 3933 type inet:ipv6-address; 3934 description 3935 "Last address."; 3936 } 3937 description 3938 "Describes IP addresses allocated by DHCP. 3939 When only start-address or only end-address 3940 is present, it represents a single address. 3941 When both start-addressand end-address are 3942 specified, it implies a range 3943 inclusive of both addresses. 3944 If no address is specified, it implies 3945 customer addresses group is 3946 not supported."; 3947 } 3948 description 3949 "Container for customer addresses allocated 3950 by DHCP."; 3951 } 3952 } 3953 description 3954 "Choice for the way to assign addresses."; 3955 } 3956 description 3957 "DHCP allocated addresses related parameters."; 3958 } 3959 container dhcp-relay { 3960 when "derived-from-or-self(../address-allocation-type, " 3961 + "'l3vpn-svc:provider-dhcp-relay')" { 3962 description 3963 "Only applies when the provider is required 3964 to implement DHCP relay function."; 3965 } 3966 leaf provider-address { 3967 type inet:ipv6-address; 3968 description 3969 "Address of the provider side. If provider-address 3970 is not specified, then prefix length should not be 3971 specified either. It also implies provider-dhcp 3972 allocation is not enabled. If provider address 3973 is specified, then prefix length may or may 3974 not be specified."; 3975 } 3976 leaf prefix-length { 3977 type uint8 { 3978 range "0..128"; 3979 } 3980 must '(../provider-address)' { 3981 error-message 3982 "If prefix length is specified, provider-address 3983 must also be specified."; 3984 description 3985 "If prefix length is specified, provider-address 3986 must also be specified."; 3987 } 3988 description 3989 "Subnet prefix length expressed in bits. If not 3990 specified, or specified as zero, this means the 3991 customer leaves the actual prefix length value 3992 to the provider."; 3993 } 3994 container customer-dhcp-servers { 3995 leaf-list server-ip-address { 3996 type inet:ipv6-address; 3997 description 3998 "This node contains the IP address of 3999 the customer DHCP server. If the DHCP relay 4000 function is implemented by the 4001 provider, this node contains the 4002 configured value."; 4003 } 4004 description 4005 "Container for list of customer DHCP servers."; 4006 } 4007 description 4008 "DHCP relay provided by operator."; 4009 } 4010 container static-addresses { 4011 when "derived-from-or-self(../address-allocation-type, " 4012 + "'l3vpn-svc:static-address')" { 4013 description 4014 "Only applies when protocol allocation type is static."; 4015 } 4016 leaf primary-address { 4017 type leafref { 4018 path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/" 4019 + "vpn-node/vpn-network-accesses/vpn-network-access/" 4020 + "ip-connection/ipv6/static-addresses/address/" 4021 + "address-id"; 4022 } 4023 description 4024 "Principal address of the connection"; 4025 } 4026 list address { 4027 key "address-id"; 4028 leaf address-id { 4029 type string; 4030 description 4031 "IPv4 Address"; 4032 } 4033 leaf provider-address { 4034 type inet:ipv6-address; 4035 description 4036 "IPv6 Address of the provider side. When the protocol 4037 allocation type is static, the provider address 4038 must be configured."; 4039 } 4040 leaf customer-address { 4041 type inet:ipv6-address; 4042 description 4043 "The IPv6 Address of the customer side."; 4044 } 4045 leaf prefix-length { 4046 type uint8 { 4047 range "0..128"; 4048 } 4049 description 4050 "Subnet prefix length expressed in bits. 4051 It is applied to both provider-address and 4052 customer-address."; 4053 } 4054 description 4055 "Describes IPv6 addresses used."; 4056 } 4057 description 4058 "IPv6-specific parameters."; 4059 } 4060 description 4061 "IPv6-specific parameters."; 4062 } 4063 container oam { 4064 container bfd { 4065 if-feature "l3vpn-svc:bfd"; 4066 leaf enabled { 4067 type boolean; 4068 default "false"; 4069 description 4070 "If true, BFD activation is required."; 4071 } 4072 choice holdtime { 4073 default "fixed"; 4074 case fixed { 4075 leaf fixed-value { 4076 type uint32; 4077 units "msec"; 4078 description 4079 "Expected BFD holdtime expressed in msec. The customer 4080 may impose some fixed values for the holdtime period 4081 if the provider allows the customer use this function. 4082 If the provider doesn't allow the customer to use this 4083 function, the fixed-value will not be set."; 4084 } 4085 } 4086 case profile { 4087 leaf profile-name { 4088 type leafref { 4089 path "/l3vpn-ntw/vpn-profiles/" 4090 + "valid-provider-identifiers/" 4091 + "bfd-profile-identifier/id"; 4092 } 4093 description 4094 "Well-known SP profile name. The provider can propose 4095 some profiles to the customer, depending on the 4096 service level the customer wants to achieve. 4097 Profile names must be communicated to the customer."; 4098 } 4099 description 4100 "Well-known SP profile."; 4101 } 4102 description 4103 "Choice for holdtime flavor."; 4104 } 4105 description 4106 "Container for BFD."; 4107 } 4108 description 4109 "Defines the Operations, Administration, and Maintenance (OAM) 4110 mechanisms used on the connection. BFD is set as a fault 4111 detection mechanism, but the 'oam' container can easily 4112 be augmented by other mechanisms"; 4113 } 4114 description 4115 "Defines connection parameters."; 4116 } 4117 description 4118 "This grouping defines IP connection parameters."; 4119 } 4121 grouping site-service-multicast { 4122 container multicast { 4123 if-feature "l3vpn-svc:multicast"; 4124 leaf site-type { 4125 type enumeration { 4126 enum receiver-only { 4127 description 4128 "The site only has receivers."; 4129 } 4130 enum source-only { 4131 description 4132 "The site only has sources."; 4133 } 4134 enum source-receiver { 4135 description 4136 "The site has both sources and receivers."; 4137 } 4138 } 4139 default "source-receiver"; 4140 description 4141 "Type of multicast site."; 4142 } 4143 container address-family { 4144 leaf ipv4 { 4145 if-feature "l3vpn-svc:ipv4"; 4146 type boolean; 4147 default "false"; 4148 description 4149 "Enables IPv4 multicast."; 4150 } 4151 leaf ipv6 { 4152 if-feature "l3vpn-svc:ipv6"; 4153 type boolean; 4154 default "false"; 4155 description 4156 "Enables IPv6 multicast."; 4157 } 4158 description 4159 "Defines protocol to carry multicast."; 4160 } 4161 leaf protocol-type { 4162 type enumeration { 4163 enum host { 4164 description 4165 "Hosts are directly connected to the provider network. 4166 Host protocols such as IGMP or MLD are required."; 4167 } 4168 enum router { 4169 description 4170 "Hosts are behind a customer router. 4171 PIM will be implemented."; 4172 } 4173 enum both { 4174 description 4175 "Some hosts are behind a customer router, and 4176 some others are directly connected to the 4177 provider network. Both host and routing protocols 4178 must be used. Typically, IGMP and PIM will be 4179 implemented."; 4180 } 4181 } 4182 default "both"; 4183 description 4184 "Multicast protocol type to be used with the customer site."; 4185 } 4186 leaf remote-source { 4187 type boolean; 4188 default "false"; 4189 description 4190 "When true, there is no PIM adjacency on the interface."; 4191 } 4192 description 4193 "Multicast parameters for the site."; 4194 } 4195 description 4196 "Multicast parameters for the site."; 4197 } 4199 grouping site-maximum-routes { 4200 container maximum-routes { 4201 list address-family { 4202 key "af"; 4203 leaf af { 4204 type l3vpn-svc:address-family; 4205 description 4206 "Address family."; 4207 } 4208 leaf maximum-routes { 4209 type uint32; 4210 description 4211 "Maximum prefixes the VRF can accept 4212 for this address family."; 4213 } 4214 description 4215 "List of address families."; 4216 } 4217 description 4218 "Defines 'maximum-routes' for the VRF."; 4219 } 4220 description 4221 "Defines 'maximum-routes' for the site."; 4222 } 4223 grouping site-security { 4224 container security { 4225 uses site-security-authentication; 4226 uses site-security-encryption; 4227 description 4228 "Site-specific security parameters."; 4229 } 4230 description 4231 "Grouping for security parameters."; 4232 } 4234 grouping network-access-service { 4235 container service { 4236 uses site-service-basic; 4237 /* Extension */ 4238 /* uses svc-bandwidth-params; */ 4239 /* EoExt */ 4240 uses site-service-qos-profile; 4241 uses site-service-mpls; 4242 uses site-service-multicast; 4243 description 4244 "Service parameters on the attachment."; 4245 } 4246 description 4247 "Grouping for service parameters."; 4248 } 4250 grouping vpn-extranet { 4251 container extranet-vpns { 4252 if-feature "l3vpn-svc:extranet-vpn"; 4253 list extranet-vpn { 4254 key "vpn-id"; 4255 leaf vpn-id { 4256 type l3vpn-svc:svc-id; 4257 description 4258 "Identifies the target VPN the local VPN want to access."; 4259 } 4260 leaf local-sites-role { 4261 type identityref { 4262 base l3vpn-svc:site-role; 4263 } 4264 default "l3vpn-svc:any-to-any-role"; 4265 description 4266 "This describes the role of the 4267 local sites in the target VPN topology. 4268 In the any-to-any VPN service topology, 4269 the local sites must have the same role, which 4270 will be 'any-to-any-role'. In the Hub-and-Spoke 4271 VPN service topology or the Hub-and-Spoke 4272 disjoint VPN service topology, 4273 the local sites must have a Hub role or a Spoke role."; 4274 } 4275 description 4276 "List of extranet VPNs or target VPNs the local VPN is 4277 attached to."; 4278 } 4279 description 4280 "Container for extranet VPN configuration."; 4281 } 4282 description 4283 "Grouping for extranet VPN configuration. 4284 This provides an easy way to interconnect 4285 all sites from two VPNs."; 4286 } 4288 grouping vpn-profile-cfg { 4289 container valid-provider-identifiers { 4290 list cloud-identifier { 4291 if-feature "l3vpn-svc:cloud-access"; 4292 key "id"; 4293 leaf id { 4294 type string; 4295 description 4296 "Identification of cloud service. 4297 Local administration meaning."; 4298 } 4299 description 4300 "List for Cloud Identifiers."; 4301 } 4302 list encryption-profile-identifier { 4303 key "id"; 4304 leaf id { 4305 type string; 4306 description 4307 "Identification of the SP encryption profile 4308 to be used. Local administration meaning."; 4309 } 4310 description 4311 "List for encryption profile identifiers."; 4312 } 4313 list qos-profile-identifier { 4314 key "id"; 4315 leaf id { 4316 type string; 4317 description 4318 "Identification of the QoS Profile to be used. 4320 Local administration meaning."; 4321 } 4322 description 4323 "List for QoS Profile Identifiers."; 4324 } 4325 list bfd-profile-identifier { 4326 key "id"; 4327 leaf id { 4328 type string; 4329 description 4330 "Identification of the SP BFD Profile to be used. 4331 Local administration meaning."; 4332 } 4333 description 4334 "List for BFD Profile identifiers."; 4335 } 4336 list routing-profile-identifier { 4337 key "id"; 4338 leaf id { 4339 type string; 4340 description 4341 "Identification of the routing Profile to be used 4342 by the routing-protocols within sites, vpn- 4343 network-accesses or vpn-nodes for refering 4344 vrf-import/export policies. 4345 This identifier has a local meaning."; 4346 } 4347 description 4348 "List for Routing Profile Identifiers."; 4349 } 4350 nacm:default-deny-write; 4351 description 4352 "Container for Valid Provider Identifies."; 4353 } 4354 description 4355 "Grouping for VPN Profile configuration."; 4356 } 4358 grouping vpn-svc-cfg { 4359 leaf vpn-id { 4360 type l3vpn-svc:svc-id; 4361 description 4362 "VPN identifier. 4363 This identifier has a local meaning."; 4364 } 4365 leaf l3sm-vpn-id { 4366 type l3vpn-svc:svc-id; 4367 description 4368 "Pointer to the L3SM service."; 4369 } 4370 leaf customer-name { 4371 type string; 4372 description 4373 "Name of the customer that actually uses the VPN service. 4374 In the case that any intermediary (e.g., Tier-2 provider 4375 or partner) sells the VPN service to their end user 4376 on behalf of the original service provider (e.g., Tier-1 4377 provider), the original service provider may require the 4378 customer name to provide smooth activation/commissioning 4379 and operation for the service."; 4380 } 4381 leaf vpn-service-topology { 4382 type identityref { 4383 base vpn-topology; 4384 } 4385 default "any-to-any"; 4386 description 4387 "VPN service topology."; 4388 } 4389 leaf description { 4390 type string; 4391 description 4392 "Textual description of a VPN service."; 4393 } 4394 uses ie-profiles-params; 4395 uses svc-transport-encapsulation; 4396 uses vpn-nodes-params; 4397 /* uses vpn-service-multicast; */ 4398 /* uses vpn-service-mpls; */ 4399 /* uses vpn-extranet;*/ 4400 description 4401 "Grouping for VPN service configuration."; 4402 } 4404 grouping site-network-access-top-level-cfg { 4405 uses status-params; 4406 leaf vpn-network-access-type { 4407 type identityref { 4408 base l3vpn-svc:site-network-access-type; 4409 } 4410 default "l3vpn-svc:point-to-point"; 4411 description 4412 "Describes the type of connection, e.g., 4413 point-to-point or multipoint."; 4414 } 4415 uses ethernet-params; 4416 uses site-attachment-ip-connection; 4417 uses site-security; 4418 uses site-routing; 4419 uses network-access-service; 4420 description 4421 "Grouping for site network access top-level configuration."; 4422 } 4424 /* Bearers in a site */ 4426 grouping site-bearer-params { 4427 container site-bearers { 4428 list bearer { 4429 key "bearer-id"; 4430 leaf bearer-id { 4431 type string; 4432 description 4433 ""; 4434 } 4435 leaf BearerType { 4436 type identityref { 4437 base bearer-inf-type; 4438 } 4439 description 4440 "Request for an Bearer access type. 4441 Choose between port or lag connection type."; 4442 } 4443 leaf ne-id { 4444 type string; 4445 description 4446 "NE-id reference."; 4447 } 4448 leaf port-id { 4449 type string; 4450 description 4451 "Reference to the Port-id. 4452 The semantic of the Port-Id depends on the vendor's 4453 semantic. i.e ge-X/Y/Z , xe-X/Y/Z , et-X/Y/Z,AeXXX.YYY, 4454 aeXXX,GigabitEthernetX/Y/Z"; 4455 } 4456 leaf lag-id { 4457 type string; 4458 description 4459 "lag-id in format id."; 4460 } 4461 description 4462 "Parameters used to identify each bearer"; 4463 } 4464 description 4465 "Grouping to reuse the site bearer assigment"; 4466 } 4467 description 4468 "Grouping to reuse the site bearer assigment"; 4469 } 4471 /* UNUSED */ 4473 grouping svc-bandwidth-params { 4474 container svc-bandwidth { 4475 if-feature "input-bw"; 4476 list bandwidth { 4477 key "direction type"; 4478 leaf direction { 4479 type identityref { 4480 base bw-direction; 4481 } 4482 description 4483 "Indicates the bandwidth direction. It can be 4484 the bandwidth download direction from the SP to 4485 the site or the bandwidth upload direction from 4486 the site to the SP."; 4487 } 4488 leaf type { 4489 type identityref { 4490 base bw-type; 4491 } 4492 description 4493 "Bandwidth type. By default, the bandwidth type 4494 is set to 'bw-per-cos'."; 4495 } 4496 leaf cos-id { 4497 when "derived-from-or-self(../type, " 4498 + "'l3vpn-ntw:bw-per-cos')" { 4499 description 4500 "Relevant when the bandwidth type is set to 4501 'bw-per-cos'."; 4502 } 4503 type uint8; 4504 description 4505 "Identifier of the CoS, indicated by DSCP or a 4506 CE-VLAN CoS (802.1p) value in the service frame. 4507 If the bandwidth type is set to 'bw-per-cos', 4508 the CoS ID MUST also be specified."; 4509 } 4510 leaf vpn-id { 4511 when "derived-from-or-self(../type, " 4512 + "'l3vpn-ntw:bw-per-svc')" { 4513 description 4514 "Relevant when the bandwidth type is 4515 set as bandwidth per VPN service."; 4516 } 4517 type l3vpn-svc:svc-id; 4518 description 4519 "Identifies the target VPN. If the bandwidth 4520 type is set as bandwidth per VPN service, the 4521 vpn-id MUST be specified."; 4522 } 4523 leaf cir { 4524 type uint64; 4525 units "bps"; 4526 mandatory true; 4527 description 4528 "Committed Information Rate. The maximum number 4529 of bits that a port can receive or send over 4530 an interface in one second."; 4531 } 4532 leaf cbs { 4533 type uint64; 4534 units "bps"; 4535 mandatory true; 4536 description 4537 "Committed Burst Size (CBS). Controls the bursty 4538 nature of the traffic. Traffic that does not 4539 use the configured Committed Information Rate 4540 (CIR) accumulates credits until the credits 4541 reach the configured CBS."; 4542 } 4543 leaf eir { 4544 type uint64; 4545 units "bps"; 4546 description 4547 "Excess Information Rate (EIR), i.e., excess frame 4548 delivery allowed that is not subject to an SLA. 4549 The traffic rate can be limited by the EIR."; 4550 } 4551 leaf ebs { 4552 type uint64; 4553 units "bps"; 4554 description 4555 "Excess Burst Size (EBS). The bandwidth available 4556 for burst traffic from the EBS is subject to the 4557 amount of bandwidth that is accumulated during 4558 periods when traffic allocated by the EIR 4559 policy is not used."; 4561 } 4562 leaf pir { 4563 type uint64; 4564 units "bps"; 4565 description 4566 "Peak Information Rate, i.e., maximum frame 4567 delivery allowed. It is equal to or less 4568 than the sum of the CIR and the EIR."; 4569 } 4570 leaf pbs { 4571 type uint64; 4572 units "bps"; 4573 description 4574 "Peak Burst Size. It is measured in bytes per 4575 second."; 4576 } 4577 description 4578 "List of bandwidth values (e.g., per CoS, 4579 per vpn-id)."; 4580 } 4581 description 4582 "From the customer site's perspective, the service 4583 input/output bandwidth of the connection or 4584 download/upload bandwidth from the SP/site 4585 to the site/SP."; 4586 } 4587 description 4588 " "; 4589 } 4591 grouping status-params { 4592 container status { 4593 leaf admin-enabled { 4594 type boolean; 4595 description 4596 "Administrative Status UP/DOWN"; 4597 } 4598 leaf oper-status { 4599 type operational-type; 4600 config false; 4601 description 4602 "Operations status"; 4603 } 4604 description 4605 "Container for status parameters."; 4606 } 4607 description 4608 "Grouping used to join operational and administrative status 4609 is re used in the Site Network Acess and in the VPN-Node"; 4610 } 4612 /* Parameters related to vpn-nodes (VRF config.) */ 4614 grouping vpn-nodes-params { 4615 container vpn-nodes { 4616 description 4617 "Container for VPN nodes."; 4618 list vpn-node { 4619 key "ne-id"; 4620 leaf vpn-node-id { 4621 type union { 4622 type l3vpn-svc:svc-id; 4623 type uint32; 4624 } 4625 description 4626 "Type STRING or NUMBER Serivice-Id"; 4627 } 4628 leaf local-autonomous-system { 4629 type inet:as-number; 4630 description 4631 "Provider AS number in case the customer 4632 requests BGP routing."; 4633 } 4634 leaf description { 4635 type string; 4636 description 4637 "Textual description of the VPN node."; 4638 } 4639 leaf ne-id { 4640 type string; 4641 description 4642 "Unique identifier of the network element 4643 where the vpn-node is deployed."; 4644 } 4645 leaf router-id { 4646 type inet:ip-address; 4647 description 4648 "router-id information can be ipv4/6 addresses"; 4649 } 4650 leaf address-family { 4651 type l3vpn-svc:address-family; 4652 description 4653 "Address family used for router-id information."; 4654 } 4655 leaf node-role { 4656 type identityref { 4657 base l3vpn-svc:site-role; 4658 } 4659 default "l3vpn-svc:any-to-any-role"; 4660 description 4661 "Role of the vpn-node in the IP VPN."; 4662 } 4663 uses rt-rd; 4664 uses status-params; 4665 uses net-acc; 4666 uses site-maximum-routes; 4667 uses vpn-service-multicast; 4668 leaf node-ie-profile { 4669 type leafref { 4670 path "/l3vpn-ntw/vpn-services/" 4671 + "vpn-service/ie-profiles/ie-profile/ie-profile-id"; 4672 } 4673 description 4674 "node Import/Export profile."; 4675 } 4676 description 4677 "List for VPN node."; 4678 } 4679 } 4680 description 4681 "Grouping to define VRF-specific configuration."; 4682 } 4684 /* Parameters related to import and export profiles (RTs RDs.) */ 4686 grouping ie-profiles-params { 4687 container ie-profiles { 4688 list ie-profile { 4689 key "ie-profile-id"; 4690 leaf ie-profile-id { 4691 type string; 4692 description 4693 "IE profile id."; 4694 } 4695 uses rt-rd; 4696 description 4697 "List for Imort/Export profile."; 4698 } 4699 description 4700 "Container for Import/Export profiles."; 4701 } 4702 description 4703 "Grouping to specify rules for route import and export"; 4704 } 4705 grouping pseudowire-params { 4706 container pseudowire { 4707 /*leaf far-end {*/ 4708 /* description "IP of the remote peer of the pseudowire.";*/ 4709 /* type inet:ip-address;*/ 4710 /*}*/ 4711 leaf vcid { 4712 type uint32; 4713 description 4714 "PW or VC identifier."; 4715 } 4716 leaf far-end { 4717 type union { 4718 type uint32; 4719 type inet:ipv4-address; 4720 } 4721 description 4722 "SDP/Far End/LDP Neighbour reference."; 4723 } 4724 description 4725 "Pseudowire termination parameters"; 4726 } 4727 container vpls { 4728 leaf vcid { 4729 type union { 4730 type uint32; 4731 type string; 4732 } 4733 description 4734 "VCID identifier,IRB/RVPPLs interface 4735 supported using string 4736 format."; 4737 } 4738 leaf far-end { 4739 type union { 4740 type uint32; 4741 type inet:ipv4-address; 4742 } 4743 description 4744 "SDP/Far End/LDP Neighbour reference."; 4745 } 4746 description 4747 "Pseudowire termination parameters"; 4748 } 4749 description 4750 "Grouping pseudowire termination parameters"; 4751 } 4752 grouping security-params { 4753 container security { 4754 leaf auth-key { 4755 type string; 4756 description 4757 "MD5 authentication password for the connection towards the 4758 customer edge."; 4759 } 4760 description 4761 "Container for aggregating any security parameter for routing 4762 sessions between a PE and a CE."; 4763 } 4764 description 4765 "Grouping to define security parameters"; 4766 } 4768 grouping ethernet-params { 4769 container connection { 4770 leaf encapsulation-type { 4771 type identityref { 4772 base encapsulation-type; 4773 } 4774 default "untagged-int"; 4775 description 4776 "Encapsulation type. By default, the 4777 encapsulation type is set to 'untagged'."; 4778 } 4779 container logical-interface { 4780 leaf peer-reference { 4781 type uint32; 4782 description 4783 "Specify the associated logical peer 4784 interface"; 4785 } 4786 description 4787 "Reference of a logical interface type."; 4788 } 4789 container tagged-interface { 4790 leaf type { 4791 type identityref { 4792 base tagged-inf-type; 4793 } 4794 default "priority-tagged"; 4795 description 4796 "Tagged interface type. By default, 4797 the type of the tagged interface is 4798 'priority-tagged'."; 4799 } 4800 container dot1q-vlan-tagged { 4801 when "derived-from-or-self(../type, " 4802 + "'l3vpn-ntw:dot1q')" { 4803 description 4804 "Only applies when the type of the tagged 4805 interface is 'dot1q'."; 4806 } 4807 if-feature "dot1q"; 4808 leaf tag-type { 4809 type identityref { 4810 base tag-type; 4811 } 4812 default "c-vlan"; 4813 description 4814 "Tag type. By default, the tag type is 4815 'c-vlan'."; 4816 } 4817 leaf cvlan-id { 4818 type uint16; 4819 description 4820 "VLAN identifier."; 4821 } 4822 description 4823 "Tagged interface."; 4824 } 4825 container priority-tagged { 4826 when "derived-from-or-self(../type, " 4827 + "'l3vpn-ntw:priority-tagged')" { 4828 description 4829 "Only applies when the type of the tagged 4830 interface is 'priority-tagged'."; 4831 } 4832 leaf tag-type { 4833 type identityref { 4834 base tag-type; 4835 } 4836 default "c-vlan"; 4837 description 4838 "Tag type. By default, the tag type is 4839 'c-vlan'."; 4840 } 4841 description 4842 "Priority tagged."; 4843 } 4844 container qinq { 4845 when "derived-from-or-self(../type, " 4846 + "'l3vpn-ntw:qinq')" { 4847 description 4848 "Only applies when the type of the tagged 4849 interface is 'qinq'."; 4850 } 4851 if-feature "qinq"; 4852 leaf tag-type { 4853 type identityref { 4854 base tag-type; 4855 } 4856 default "c-s-vlan"; 4857 description 4858 "Tag type. By default, the tag type is 4859 'c-s-vlan'."; 4860 } 4861 leaf svlan-id { 4862 type uint16; 4863 mandatory true; 4864 description 4865 "SVLAN identifier."; 4866 } 4867 leaf cvlan-id { 4868 type uint16; 4869 mandatory true; 4870 description 4871 "CVLAN identifier."; 4872 } 4873 description 4874 "QinQ."; 4875 } 4876 container qinany { 4877 when "derived-from-or-self(../type, " 4878 + "'l3vpn-ntw:qinany')" { 4879 description 4880 "Only applies when the type of the tagged 4881 interface is 'qinany'."; 4882 } 4883 if-feature "qinany"; 4884 leaf tag-type { 4885 type identityref { 4886 base tag-type; 4887 } 4888 default "s-vlan"; 4889 description 4890 "Tag type. By default, the tag type is 4891 's-vlan'."; 4892 } 4893 leaf svlan-id { 4894 type uint16; 4895 mandatory true; 4896 description 4897 "Service VLAN ID."; 4898 } 4899 description 4900 "Container for QinAny."; 4901 } 4902 container vxlan { 4903 when "derived-from-or-self(../type, " 4904 + "'l3vpn-ntw:vxlan')" { 4905 description 4906 "Only applies when the type of the tagged 4907 interface is 'vxlan'."; 4908 } 4909 if-feature "vxlan"; 4910 leaf vni-id { 4911 type uint32; 4912 mandatory true; 4913 description 4914 "VXLAN Network Identifier (VNI)."; 4915 } 4916 leaf peer-mode { 4917 type identityref { 4918 base vxlan-peer-mode; 4919 } 4920 default "static-mode"; 4921 description 4922 "Specifies the VXLAN access mode. By default, 4923 the peer mode is set to 'static-mode'."; 4924 } 4925 list peer-list { 4926 key "peer-ip"; 4927 leaf peer-ip { 4928 type inet:ip-address; 4929 description 4930 "Peer IP."; 4931 } 4932 description 4933 "List of peer IP addresses."; 4934 } 4935 description 4936 "QinQ."; 4937 } 4938 description 4939 "Container for tagged interfaces."; 4940 } 4941 container bearer { 4942 leaf bearer-reference { 4943 if-feature "l3vpn-svc:bearer-reference"; 4944 type string; 4945 description 4946 "This is an internal reference for the SP."; 4947 } 4948 uses pseudowire-params; 4949 description 4950 "Defines physical properties of a site attachment."; 4951 } 4952 description 4953 "Encapsulation types"; 4954 } 4955 description 4956 "Grouping to define encapsulation types"; 4957 } 4959 grouping rt-rd { 4960 leaf rd { 4961 type union { 4962 type rt-types:route-distinguisher; 4963 type empty; 4964 } 4965 description 4966 "Route distinguisher value. If this leaf has not been 4967 configured, the server will auto-assign a route 4968 distinguisher value and use that value operationally. 4969 This calculated value is available in the operational 4970 state. Use the empty type to indicate rd has no value 4971 and is not to be aouto-assigned"; 4972 } 4973 container vpn-targets { 4974 description 4975 "Set of route-targets to match for import and export routes 4976 to/from VRF"; 4977 //uses rt-types:vpn-route-targets; 4978 uses vpn-route-targets; 4979 } 4980 description 4981 "Grouping for RT and RD."; 4982 } 4984 grouping vpn-route-targets { 4985 description 4986 "A grouping that specifies Route Target import-export rules 4987 used in a BGP-enabled VPN."; 4988 list vpn-target { 4989 key "id"; 4990 leaf id { 4991 type int8; 4992 description 4993 "Identifies each VPN Target"; 4994 } 4995 list route-targets { 4996 key "route-target"; 4997 leaf route-target { 4998 type rt-types:route-target; 4999 description 5000 "Route Target value"; 5001 } 5002 description 5003 "List of Route Targets."; 5004 } 5005 leaf route-target-type { 5006 type rt-types:route-target-type; 5007 mandatory true; 5008 description 5009 "Import/export type of the Route Target."; 5010 } 5011 description 5012 "l3vpn route targets. AND/OR Operations are available 5013 based on the RTs assigment"; 5014 } 5015 reference 5016 "RFC4364: BGP/MPLS IP Virtual Private Networks (VPNs) 5017 RFC4664: Framework for Layer 2 Virtual Private Networks 5018 (L2VPNs)"; 5019 container vpn-policies { 5020 description 5021 ""; 5022 leaf import-policy { 5023 type leafref { 5024 path "/l3vpn-ntw/vpn-profiles/valid-provider-identifiers/" 5025 + "routing-profile-identifier/id"; 5026 } 5027 description 5028 "Reference to a VRF import policy."; 5029 } 5030 leaf export-policy { 5031 type leafref { 5032 path "/l3vpn-ntw/vpn-profiles/valid-provider-identifiers/" 5033 + "routing-profile-identifier/id"; 5034 } 5035 description 5036 "Reference to a VRF export policy."; 5037 } 5038 } 5039 } 5040 grouping net-acc { 5041 container vpn-network-accesses { 5042 list vpn-network-access { 5043 key "id"; 5044 leaf id { 5045 type l3vpn-svc:svc-id; 5046 description 5047 "Identifier for the access."; 5048 } 5049 leaf port-id { 5050 type l3vpn-svc:svc-id; 5051 description 5052 "Identifier for the network access."; 5053 } 5054 leaf description { 5055 type string; 5056 description 5057 "Textual description of a VPN service."; 5058 } 5059 uses site-network-access-top-level-cfg; 5060 description 5061 "List of accesses for a site."; 5062 } 5063 description 5064 "List of accesses for a site."; 5065 } 5066 description 5067 "Main block of the Network Access."; 5068 } 5070 /* Main Blocks */ 5072 container l3vpn-ntw { 5073 container vpn-profiles { 5074 uses vpn-profile-cfg; 5075 description 5076 "Container for VPN Profiles."; 5077 } 5078 container vpn-services { 5079 list vpn-service { 5080 key "vpn-id"; 5081 uses service-status; 5082 uses vpn-svc-cfg; 5083 description 5084 "List of VPN services."; 5085 } 5086 description 5087 "Top-level container for the VPN services."; 5089 } 5090 description 5091 "Main container for L3VPN services management."; 5092 } 5093 } 5094 5096 Figure 26 5098 11. IANA Considerations 5100 This document requests IANA to register the following URI in the "ns" 5101 subregistry within the "IETF XML Registry" [RFC3688]: 5103 URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw 5105 Registrant Contact: The IESG. 5107 XML: N/A; the requested URI is an XML namespace. 5109 This document requests IANA to register the following YANG module in 5110 the "YANG Module Names" subregistry [RFC6020] within the "YANG 5111 Parameters" registry. 5113 name: ietf-l3vpn-ntw 5115 namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw 5117 maintained by IANA: N 5119 prefix: l3nm 5121 reference: RFC XXXX 5123 12. Security Considerations 5125 The YANG module specified in this document defines a schema for data 5126 that is designed to be accessed via network management protocols such 5127 as NETCONF [RFC6241] or RESTCONF [RFC8040] . The lowest NETCONF layer 5128 is the secure transport layer, and the mandatory-to-implement secure 5129 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 5130 is HTTPS, and the mandatory-to-implement secure transport is TLS 5131 [RFC8466]. 5133 The Network Configuration Access Control Model (NACM) [RFC8341] 5134 provides the means to restrict access for particular NETCONF or 5135 RESTCONF users to a preconfigured subset of all available NETCONF or 5136 RESTCONF protocol operations and content. 5138 The ietf-l3vpn-ntw module is used to manage L3 VPNs in a service 5139 provider backbone network. Hence, the module can be used to request, 5140 modify, or retrieve L3VPN services. For example, the creation of a 5141 vpn-service leaf instance triggers the creation of an L3 VPN Service 5142 in a Service Provider Network. 5144 Due to the foreseen use of the YANG module, there are a number of 5145 data nodes defined in this YANG module that are writable/creatable/ 5146 deletable (i.e., config true, which is the default). These data 5147 nodes MAY be considered sensitive or vulnerable in some network 5148 environments. Write operations (e.g., edit-config) and delete 5149 operations to these data nodes without proper protection or 5150 authentication can have a negative effect on network operations. 5151 These are the subtrees and data nodes and their sensitivity/ 5152 vulnerability in the ietf-l3vpn-ntw module: 5154 o vpn-service: An attacker who is able to access network nodes can 5155 undertake various attacks, such as deleting a running L3 VPN 5156 Service, interrupting all the traffic of a client. In addition, 5157 an attacker may modify the attributes of a running service (e.g., 5158 QoS, bandwidth, routing protocols), leading to malfunctioning of 5159 the service and therefore to SLA violations. In addition, an 5160 attacker could attempt to create a L3 VPN Service. Such activity 5161 can be detected by monitoring and tracking network configuration 5162 changes. 5164 o COMPLETE rest of critical data nodes and subtrees 5166 Some of the readable data nodes in this YANG module may be considered 5167 sensitive or vulnerable in some network environments. It is thus 5168 important to control read access (e.g., via get, get-config, or 5169 notification) to these data nodes. These are the subtrees and data 5170 nodes and their sensitivity/vulnerability: 5172 o customer-name and ip-connection: An attacker can retrieve privacy- 5173 related information which can be used to track a customer. 5174 Disclosing such information may be considered as a violation of 5175 the customer-provider trust relationship. 5177 Summing up, the foreseen risks of using the l3vpn-ntw module can be 5178 clasified into: 5180 o Malicious clients attempting to delete or modify services 5182 o Unauthorized clients attempting to create/modify/delete a service 5184 o Unauthorized clients attempting to read service information 5186 13. Acknowledgements 5188 Thanks to Adrian Farrel and Miguel Cros for the suggestions on the 5189 document. Thanks to Philip Eardlay for the review. Lots of thanks 5190 for the discussions on opsawg mailing list and at IETF meeting. 5192 This work was supported in part by the European Commission funded 5193 H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727). 5195 14. Contributors 5197 Victor Lopez 5198 Telefonica 5199 Email: victor.lopezalvarez@telefonica.com 5201 Daniel King 5202 Old Dog Consulting 5203 Email: daniel@olddog.co.uk 5205 Daniel Voyer 5206 Bell Canada 5207 Email: daniel.voyer@bell.ca 5209 Luay Jalil 5210 Verizon 5211 Email: luay.jalil@verizon.com 5213 Qin Wu 5214 Huawei 5215 Email: bill.wu@huawei.com> 5217 Stephane Litkowski 5218 Cisco 5219 Email: slitkows@cisco.com> 5221 Manuel Julian 5222 Vodafone 5223 Email: manuel-julian.lopez@vodafone.com> 5225 Lucia Oliva Ballega 5226 Telefonica 5227 Email: lucia.olivaballega.ext@telefonica.com> 5229 Erez Segev 5230 ECI Telecom 5231 Email: erez.segev@ecitele.com> 5233 15. References 5235 15.1. Normative References 5237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5238 Requirement Levels", BCP 14, RFC 2119, 5239 DOI 10.17487/RFC2119, March 1997, 5240 . 5242 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 5243 DOI 10.17487/RFC3688, January 2004, 5244 . 5246 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 5247 the Network Configuration Protocol (NETCONF)", RFC 6020, 5248 DOI 10.17487/RFC6020, October 2010, 5249 . 5251 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 5252 and A. Bierman, Ed., "Network Configuration Protocol 5253 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 5254 . 5256 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 5257 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 5258 . 5260 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 5261 RFC 7950, DOI 10.17487/RFC7950, August 2016, 5262 . 5264 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 5265 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 5266 . 5268 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5269 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5270 May 2017, . 5272 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 5273 Access Control Model", STD 91, RFC 8341, 5274 DOI 10.17487/RFC8341, March 2018, 5275 . 5277 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 5278 Data Model for Layer 2 Virtual Private Network (L2VPN) 5279 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 5280 2018, . 5282 15.2. Informative References 5284 [I-D.evenwu-opsawg-yang-composed-vpn] 5285 Even, R., Bo, W., Wu, Q., and Y. Cheng, "YANG Data Model 5286 for Composed VPN Service Delivery", draft-evenwu-opsawg- 5287 yang-composed-vpn-03 (work in progress), March 2019. 5289 [I-D.ietf-idr-bgp-model] 5290 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 5291 YANG Model for Service Provider Networks", draft-ietf-idr- 5292 bgp-model-08 (work in progress), February 2020. 5294 [I-D.ietf-pim-yang] 5295 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 5296 Y., and f. hu, "A YANG Data Model for Protocol Independent 5297 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 5298 progress), May 2018. 5300 [I-D.ietf-rtgwg-qos-model] 5301 Choudhary, A., Jethanandani, M., Strahle, N., Aries, E., 5302 and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos- 5303 model-00 (work in progress), October 2019. 5305 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 5306 Private Network (VPN) Terminology", RFC 4026, 5307 DOI 10.17487/RFC4026, March 2005, 5308 . 5310 [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., 5311 and A. Gonguet, "Framework for Layer 3 Virtual Private 5312 Networks (L3VPN) Operations and Management", RFC 4176, 5313 DOI 10.17487/RFC4176, October 2005, 5314 . 5316 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 5317 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 5318 DOI 10.17487/RFC8299, January 2018, 5319 . 5321 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 5322 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 5323 . 5325 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 5326 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 5327 . 5329 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 5330 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 5331 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 5332 2018, . 5334 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 5335 Routing Management (NMDA Version)", RFC 8349, 5336 DOI 10.17487/RFC8349, March 2018, 5337 . 5339 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 5340 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 5341 DOI 10.17487/RFC8453, August 2018, 5342 . 5344 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 5345 Vinapamula, S., and Q. Wu, "A YANG Module for Network 5346 Address Translation (NAT) and Network Prefix Translation 5347 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 5348 . 5350 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 5351 "YANG Data Model for Network Access Control Lists (ACLs)", 5352 RFC 8519, DOI 10.17487/RFC8519, March 2019, 5353 . 5355 Appendix A. Implementation Status 5357 A.1. Nokia Implementation 5359 Nokia has a draft implementation of the IETF L3NM model. 5361 The implementation is a prototype and is currently being planned for 5362 production. 5364 Nokia NSP (Network Services Platform) supports integration of 5365 standard models with the Intent Manager framework. NSP platform 5366 provides hot pluggable model definitions and implementations which 5367 would enable defining models where standardization is in progress or 5368 non-existent. With pluggable architecture for model and 5369 implementation injections, NSP also serves as a Multi-Layer, Multi- 5370 Domain controller. 5372 The Nokia implementation of L3NM covers, the following 5374 a) RESTConf support 5375 b) Configuration of L3 IP VPN Services. Create/Get/Query/Delete 5376 supported on the following operations. 5378 * Site 5380 * Site-Bearer 5382 * VpnService 5384 * IEProfile 5386 * VpnNode 5388 * Site Network Access 5390 * Site Attachments 5392 c) Supports translations to the Device Model (Standard / 5393 Properietary) 5395 draft-ietf-opsawg-l3sm-l3nm-00 5397 The current implementation is proprietary, so under no terms the 5398 current implementation can be used. 5400 Contact information: Sriram Krishnamurthy 5401 (sriram.krishnamurthy@nokia.com) 5403 A.2. Huawei Implementation 5405 The organization responsible for the implementation, if any. 5407 Huawei Technologies Co.,Ltd. 5409 The implementation's name and/or a link to a web page where the 5410 implementation or a description of it can be found. 5412 NCE V1R19C00 5414 A brief general description. 5416 This section provides an implementation report summary for Layer 3 5417 VPN Network Model. Layer 3 VPN Network Model is available at: 5418 https://tools.ietf.org/html/draft-ietf-opsawg-l3sm-l3nm-00 5420 The implementation's level of maturity: research, prototype, alpha, 5421 beta, production, widely used, etc. 5423 Right now, the data model is still subject to change, therefore it is 5424 still a Prototype, not put into production yet. 5426 Coverage: which parts of the protocol specification are implemented. 5428 We have implemented pruned L3NM model with the following parameters 5430 module: ietf-l3vpn-ntw 5431 +--rw l3vpn-ntw 5432 +--rw vpn-profiles 5433 | +--rw valid-provider-identifiers 5434 | +--rw qos-profile-identifier* [id] 5435 | | +--rw id string 5436 +--rw vpn-services 5437 | +--rw vpn-service* [vpn-id] 5438 | +--rw vpn-id svc-id 5439 | +--rw vpn-service-topology? identityref 5440 | +--rw description? string 5441 | +--rw vpn-nodes 5442 | | +--rw vpn-node* [vpn-node-id ne-id] 5443 | | +--rw vpn-node-id string 5444 | | +--rw description? string 5445 | | +--rw ne-id string 5446 | | +--rw node-role? identityref 5447 | | +--rw rd? rt-types:route-distinguisher 5448 | | +--rw vpn-targets 5449 | | +--rw maximum-routes 5450 | | | +--rw address-family* [af] 5451 | | | +--rw af address-family 5452 | | | +--rw maximum-routes? uint32 5453 +--rw sites 5454 +--rw site* [site-id] 5455 +--rw site-id svc-id 5456 +--rw locations 5457 | +--rw location* [location-id] 5458 | +--rw location-id svc-id 5459 +--rw site-bearers 5460 | +--rw bearer* [bearer-id] 5461 | +--rw bearer-id string 5462 | +--rw ne-id? string 5463 | +--rw port-id? string 5464 +--rw site-network-accesses 5465 +--rw site-network-access* [site-network-access-id] 5466 +--rw site-network-access-id svc-id 5467 +--rw site-network-access-type? ref 5468 +--rw bearer 5469 | +--rw bearer-reference? {bearer-reference}? 5470 | +--rw connection 5471 | | +--rw encapsulation-type? identityref 5472 | | +--rw tagged-interface 5473 | | +--rw type? identityref 5474 | | +--rw dot1q-vlan-tagged {dot1q}? 5475 | | | +--rw cvlan-id uint16 5476 | | +--rw qinq {qinq}? 5477 | | | +--rw svlan-id uint16 5478 | | | +--rw cvlan-id uint16 5479 +--rw ip-connection 5480 | +--rw ipv4 {ipv4}? 5481 | | +--rw dhcp-relay 5482 | | | +--rw customer-dhcp-servers 5483 | | | +--rw server-ip-address* inet 5484 | | +--rw addresses 5485 | | +--rw provider-address? inet:ipv4-address 5486 | | +--rw customer-address? inet:ipv4-address 5487 | | +--rw prefix-length? uint8 5488 +--rw service 5489 | +--rw qos {qos}? 5490 | | +--rw qos-profile 5491 | | +--rw (qos-profile)? 5492 | | +--:(standard) 5493 | | | +--rw profile? leafreaf 5494 +--rw routing-protocols 5495 | +--rw routing-protocol* [type] 5496 | +--rw type identityref 5497 | +--rw ospf {rtg-ospf}? 5498 | | +--rw address-family* address-family 5499 | | +--rw area-address yang:dotted-quad 5500 | | +--rw metric? uint16 5501 | | +--rw security 5502 | | | +--rw auth-key? string 5503 | +--rw bgp {rtg-bgp}? 5504 | | +--rw autonomous-system uint32 5505 | | +--rw address-family* address-family 5506 | | +--rw neighbor? inet:ip-address 5507 | | +--rw multihop? uint8 5508 | | +--rw security 5509 | | +--rw auth-key? string 5510 | +--rw static 5511 | | +--rw cascaded-lan-prefixes 5512 | | +--rw ipv4-lan-prefixes* {ipv4}? 5513 | | | +--rw lan inet:ipv4-prefix 5514 | | | +--rw lan-tag? string 5515 | | | +--rw next-hop inet:ipv4-address 5516 +--rw node-id? leafreaf 5517 +--rw service-id? leafreaf 5518 +--rw access-group-id? yang:uuid 5519 Figure 27 5521 Use Cases we have implemented include: 5523 (a).Create VPN 5525 (b).Create Site 5527 (c).Create/add bearers to an existing Site 5529 (d).Create/Include Site Network Access into VPN nodes. 5531 Version compatibility: what version/versions of the Internet-Draft 5532 are known to be implemented. 5534 draft-ietf-opsawg-l3sm-l3nm-00 5536 Licensing: the terms under which the implementation can be used. For 5537 example: proprietary, royalty licensing, freely distributable with 5538 acknowledgement (BSD style), freely distributable with requirement to 5539 redistribute source (General Public License (GPL) style), and other 5540 (specify). 5542 Not available yet. 5544 Implementation experience: any useful information the implementers 5545 want to share with the community. 5547 Contact information: ideally a person's name and email address, but 5548 possibly just a URL or mailing list. 5550 Qin Wu (bill.wu@huawei.com) 5552 The date when information about this particular implementation was 5553 last updated. 5555 2019-09-30 5557 List other implementations that have been tested for 5558 interoperability. 5560 Nokia 5562 A.3. Infinera Implementation 5564 Infinera has a draft implementation of the IETF L3NM model. The 5565 implementation is in beta state and is currently being tested and 5566 integrated with other suppliers controllers supporting this same 5567 model. Infinera is supporting the L3NM model in its Transcend 5568 Maestro Multi-layer, Multi-domain Controller. 5570 The Infinera implementation of L3NM covers discovery and 5571 configuration of IP VPN services, and is supporting both North-Bound 5572 (server) and South-Bound (client) functionality. Versions 01 and 02 5573 of the model are supported. 5575 The current implementation is proprietary, so under no terms the 5576 current implementation can be used. 5578 Contact information: Janne Karvonen (JKarvonen@infinera.com) 5580 26 October is the date when information about this particular 5581 implementation was last updated. 5583 A.4. Ribbon-ECI Implementation 5585 Ribbon-ECI Controller (Muse) has multilayer provisioning abilities 5586 from the optical layer up to the IP layer. With respect to ATCN 5587 hierarchy model, Ribbon-ECI controller can be placed in at the level 5588 of MDSC and serve as a service orchestrator or at the level of PNC as 5589 a SDN controller. Additional information can be found at 5590 https://www.ecitele.com/muse-network-service-apps/ The L3VPN 5591 Fulfillment component, which is currently in beta maturity level, is 5592 designed to support L3SM (RFC8299) for L3VPN service creation and 5593 activation, is implemented with a data model similar to the L3NM and 5594 translates it to the device model (ietf-routing-instance and ietf- 5595 interfaces). 5597 In addition, the L3VPN Fulfillment component interface include REST 5598 API with the following methods: 5600 o Create service 5602 o Edit service 5604 o Get service details 5606 o Delete service 5608 o Notification (registration based) 5610 L3NM model coverage (several augmentations and deviations applied): 5612 o vpn-service 5614 o vpn-id 5615 o uuid 5617 o vpn-service-topology 5619 o customer-name 5621 o description 5623 o slice-id 5625 o service-status 5627 o vpn-nodes 5629 o ne-id 5631 o vpn-node-id 5633 o uuid 5635 o autonomous-system 5637 o rd 5639 o vpn-targets 5641 o vpn-network-accesses 5643 o tunnel-policy 5645 o export-policy 5647 o routing protocol 5649 o bgp 5651 o static 5653 o vpn-network-access 5655 o vpn-network-access-id 5657 o uuid 5659 o statu 5661 o connection 5662 o tagged-interface 5664 o cvlan-id 5666 o ip-connection 5668 o dhcp-relay 5670 o static-addresses 5672 o service 5674 o qos-profile 5676 o bw-profile 5678 Authors' Addresses 5680 Samier Barguil 5681 Telefonica 5682 Madrid 5683 ES 5685 Email: samier.barguilgiraldo.ext@telefonica.com 5687 Oscar Gonzalez de Dios (editor) 5688 Telefonica 5689 Madrid 5690 ES 5692 Email: oscar.gonzalezdedios@telefonica.com 5694 Mohamed Boucadair 5695 Orange 5696 France 5698 Email: "mohamed.boucadair@orange.com 5700 Luis Angel Munoz 5701 Vodafone 5702 ES 5704 Email: luis-angel.munoz@vodafone.com 5705 Alejandro Aguado 5706 Nokia 5707 Madrid 5708 ES 5710 Email: alejandro.aguado_martin@nokia.com