idnits 2.17.1 draft-ietf-opsawg-l3sm-l3nm-09.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 7 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 634 has weird spacing: '...--rw id str...' == Line 636 has weird spacing: '...--rw id str...' == Line 638 has weird spacing: '...--rw id str...' == Line 640 has weird spacing: '...--rw id str...' == Line 642 has weird spacing: '...--rw id str...' == (8 more instances...) -- The document date (May 19, 2021) is 1066 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-opsawg-vpn-common-07 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-10 == Outdated reference: A later version (-12) exists of draft-ietf-rtgwg-qos-model-03 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-07 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-00 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG S. Barguil 3 Internet-Draft O. Gonzalez de Dios, Ed. 4 Intended status: Standards Track Telefonica 5 Expires: November 20, 2021 M. Boucadair, Ed. 6 Orange 7 L. Munoz 8 Vodafone 9 A. Aguado 10 Nokia 11 May 19, 2021 13 A Layer 3 VPN Network YANG Model 14 draft-ietf-opsawg-l3sm-l3nm-09 16 Abstract 18 This document defines an L3VPN Network YANG Model (L3NM) that can be 19 used for the provisioning of Layer 3 Virtual Private Network (VPN) 20 services within a service provider network. The model provides a 21 network-centric view of L3VPN services. 23 L3NM is meant to be used by a network controller to derive the 24 configuration information that will be sent to relevant network 25 devices. The model can also facilitate the communication between a 26 service orchestrator and a network controller/orchestrator. 28 Editorial Note (To be removed by RFC Editor) 30 Please update these statements within the document with the RFC 31 number to be assigned to this document: 33 o "This version of this YANG module is part of RFC XXXX;" 35 o "RFC XXXX: Layer 3 VPN Network Model"; 37 o reference: RFC XXXX 39 Please update "RFC UUUU" to the RFC number to be assigned to I- 40 D.ietf-opsawg-vpn-common. 42 Also, please update the "revision" date of the YANG module. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on November 20, 2021. 61 Copyright Notice 63 Copyright (c) 2021 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (https://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 4. L3NM Reference Architecture . . . . . . . . . . . . . . . . . 7 82 5. Relation with other YANG Models . . . . . . . . . . . . . . . 10 83 6. Sample Uses of the L3NM Data Model . . . . . . . . . . . . . 11 84 6.1. Enterprise Layer 3 VPN Services . . . . . . . . . . . . . 11 85 6.2. Multi-Domain Resource Management . . . . . . . . . . . . 12 86 6.3. Management of Multicast Services . . . . . . . . . . . . 12 87 7. Description of the L3NM YANG Module . . . . . . . . . . . . . 12 88 7.1. Overall Structure of the Module . . . . . . . . . . . . . 13 89 7.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 13 90 7.3. VPN Services . . . . . . . . . . . . . . . . . . . . . . 15 91 7.4. VPN Instance Profiles . . . . . . . . . . . . . . . . . . 18 92 7.5. VPN Nodes . . . . . . . . . . . . . . . . . . . . . . . . 20 93 7.6. VPN Network Access . . . . . . . . . . . . . . . . . . . 23 94 7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 26 95 7.6.2. IP Connection . . . . . . . . . . . . . . . . . . . . 27 96 7.6.3. CE-PE Routing Protocols . . . . . . . . . . . . . . . 31 97 7.6.4. OAM . . . . . . . . . . . . . . . . . . . . . . . . . 43 98 7.6.5. Security . . . . . . . . . . . . . . . . . . . . . . 44 99 7.6.6. Services . . . . . . . . . . . . . . . . . . . . . . 45 100 7.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 51 101 8. L3NM YANG Module . . . . . . . . . . . . . . . . . . . . . . 55 102 9. Security Considerations . . . . . . . . . . . . . . . . . . . 116 103 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 118 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 118 105 11.1. Normative References . . . . . . . . . . . . . . . . . . 118 106 11.2. Informative References . . . . . . . . . . . . . . . . . 122 107 Appendix A. L3VPN Examples . . . . . . . . . . . . . . . . . . . 126 108 A.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 126 109 A.2. Loopback Interface . . . . . . . . . . . . . . . . . . . 131 110 A.3. Multicast VPN Provisioning Example . . . . . . . . . . . 131 111 Appendix B. Implementation Status . . . . . . . . . . . . . . . 136 112 B.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 136 113 B.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 136 114 B.3. Infinera Implementation . . . . . . . . . . . . . . . . . 136 115 B.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 136 116 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 137 117 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 137 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 137 120 1. Introduction 122 [RFC8299] defines a Layer 3 Virtual Private Network Service YANG data 123 Model (L3SM) that can be used for communication between customers and 124 network operators. Such model is focused on describing the customer 125 view of the Virtual Private Network (VPN) services and provides an 126 abstracted view of the customer's requested services. That approach 127 limits the usage of the L3SM to the role of a customer service model 128 (as per [RFC8309]). 130 This document defines a YANG module called L3VPN Network Model 131 (L3NM). The L3NM is aimed at providing a network-centric view of 132 Layer 3 (L3) VPN services. This data model can be used to facilitate 133 communication between the service orchestrator and the network 134 controller/orchestrator by allowing for more network-centric 135 information to be included. It enables further capabilities such as 136 resource management or serves as a multi-domain orchestration 137 interface, where logical resources (such as route targets or route 138 distinguishers) must be coordinated. 140 This document uses the common VPN YANG module defined in 141 [I-D.ietf-opsawg-vpn-common]. 143 This document does not obsolete [RFC8299]. These two modules are 144 used for similar objectives but with different scopes and views. 146 The L3NM YANG module was initially built with a prune and extend 147 approach, taking as a starting points the YANG module described in 148 [RFC8299]. Nevertheless, the L3NM is not defined as an augment to 149 L3SM because a specific structure is required to meet network- 150 oriented L3 needs. 152 Some of the information captured in the L3SM can be passed by the 153 orchestrator in the L3NM (e.g., customer) or be used to feed some of 154 the L3NM attributes (e.g., actual forwarding policies). Some of the 155 information captured in L3SM may be maintained locally within the 156 orchestrator; which is in charge of maintaining the correspondence 157 between a customer view and its network instantiation. Likewise, 158 some of the information captured and exposed using the L3NM can feed 159 the service layer (e.g., capabilities) to drive VPN service order 160 handling, and thus the L3SM. 162 Section 5.1 of [RFC8969] illustrates how the L3NM can be used within 163 the network management automation architecture. 165 The L3NM does not attempt to address all deployment cases especially 166 those where the L3VPN connectivity is supported through the 167 coordination of different VPNs in different underlying networks. 168 More complex deployment scenarios involving the coordination of 169 different VPN instances and different technologies to provide an end- 170 to-end VPN connectivity are addressed by complementary YANG modules, 171 e.g., [I-D.evenwu-opsawg-yang-composed-vpn]. 173 L3NM focuses on BGP Provider Edge (PE) based Layer 3 VPNs as 174 described in [RFC4026][RFC4110][RFC4364] and Multicast VPNs as 175 described in [RFC6037][RFC6513]. 177 The YANG data model in this document conforms to the Network 178 Management Datastore Architecture (NMDA) defined in [RFC8342]. 180 2. Terminology 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 184 "OPTIONAL" in this document are to be interpreted as described in BCP 185 14 [RFC2119] [RFC8174] when, and only when, they appear in all 186 capitals, as shown here. 188 This document assumes that the reader is familiar with the contents 189 of [RFC6241], [RFC7950], [RFC8299], [RFC8309], and [RFC8453] and uses 190 the terminology defined in those documents. 192 This document uses the term "network model" defined in Section 2.1 of 193 [RFC8969]. 195 The meaning of the symbols in the tree diagrams is defined in 196 [RFC8340]. 198 This document makes use of the following terms: 200 Layer 3 VPN Customer Service Model (L3SM): A YANG module that 201 describes the service requirements of an L3VPN that interconnects 202 a set of sites from the point of view of the customer. The 203 customer service model does not provide details on the service 204 provider network. The L3VPN customer service model is defined in 205 [RFC8299]. 207 Layer 3 VPN Service Network Model (L3NM): A YANG module that 208 describes a VPN service in the service provider network. It 209 contains information of the service provider network and might 210 include allocated resources. It can be used by network 211 controllers to manage and control the VPN service configuration in 212 the service provider network. The YANG module can be consumed by 213 a service orchestrator to request a VPN service to a network 214 controller. 216 Service orchestrator: A functional entity that interacts with the 217 customer of an L3VPN. The service orchestrator interacts with the 218 customer using the L3SM. The service orchestrator is responsible 219 of the Customer Edge (CE) - Provider Edge (PE) attachment 220 circuits, the PE selection, and requesting the VPN service to the 221 network controller. 223 Network orchestrator: A functional entity that is hierarchically 224 intermediate between a service orchestrator and network 225 controllers. A network orchestrator can manage one or several 226 network controllers. 228 Network controller: A functional entity responsible for the control 229 and management of the service provider network. 231 VPN node: An abstraction that represents a set of policies applied 232 on a PE and that belong to a single VPN service. A VPN service 233 involves one or more VPN nodes. As it is an abstraction, the 234 network controller will take on how to implement a VPN node. For 235 example, typically, in a BGP-based VPN, a VPN node could be mapped 236 into a Virtual Routing and Forwarding (VRF). 238 VPN network access: An abstraction that represents the network 239 interfaces that are associated to a given VPN node. Traffic 240 coming from the VPN network access belongs to the VPN. The 241 attachment circuits (bearers) between CEs and PEs are terminated 242 in the VPN network access. A reference to the bearer is 243 maintained to allow keeping the link between L3SM and L3NM when 244 both models are used in a given deployment. 246 VPN site: A VPN customer's location that is connected to the 247 service provider network via a CE-PE link, which can access at 248 least one VPN [RFC4176]. 250 VPN service provider: A service provider that offers VPN-related 251 services [RFC4176]. 253 Service provider network: A network that is able to provide VPN- 254 related services. 256 The document is aimed at modeling BGP PE-based VPNs in a service 257 provider network, so the terms defined in [RFC4026] and [RFC4176] are 258 used. 260 3. Acronyms 262 The following acronyms are used in the document: 264 ACL Access Control List 265 AS Autonomous System 266 ASM Any-Source Multicast 267 ASN AS Number 268 BSR Bootstrap Router 269 BFD Bidirectional Forwarding Detection 270 BGP Border Gateway Protocol 271 CE Customer Edge 272 IGMP Internet Group Management Protocol 273 L3VPN Layer 3 Virtual Private Network 274 L3SM L3VPN Service Model 275 L3NM L3VPN Network Model 276 MLD Multicast Listener Discovery 277 MSDP Multicast Source Discovery Protocol 278 MVPN Multicast VPN 279 NAT Network Address Translation 280 OAM Operations, Administration, and Maintenance 281 OSPF Open Shortest Path First 282 PE Provider Edge 283 PIM Protocol Independent Multicast 284 QoS Quality of Service 285 RD Route Distinguisher 286 RP Rendez-vous Point 287 RT Route Target 288 SA Security Association 289 SSM Source-Specific Multicast 290 VPN Virtual Private Network 291 VRF Virtual Routing and Forwarding 293 4. L3NM Reference Architecture 295 Figure 1 depicts the reference architecture for the L3NM. The figure 296 is an expansion of the architecture presented in Section 5 of 297 [RFC8299]; it decomposes the box marked "orchestration" in that 298 section into three separate functional components: Service 299 Orchestration, Network Orchestration, and Domain Orchestration. 301 Although some deployments may choose to construct a monolithic 302 orchestration component (covering both service and network matters), 303 this document advocates for a clear separation between service and 304 network orchestration components for the sake of better flexibility. 305 Such design adheres to the L3VPN reference architecture defined in 306 Section 1.3 of [RFC4176]. This separation relies upon a dedicated 307 communication interface between these components and appropriate YANG 308 modules that reflect network-related information. Such information 309 is hidden to customers. 311 The intelligence for translating customer-facing information into 312 network-centric one (and vice versa) is implementation specific. 314 The terminology from [RFC8309] is introduced to show the distinction 315 between the customer service model, the service delivery model, the 316 network configuration model, and the device configuration model. In 317 that context, the "Domain Orchestration" and "Config Manager" roles 318 may be performed by "Controllers". 320 +---------------+ 321 | Customer | 322 +-------+-------+ 323 Customer Service Model | 324 e.g., l3vpn-svc | 325 +-------+-------+ 326 | Service | 327 | Orchestration | 328 +-------+-------+ 329 Network Model | 330 l3vpn-ntw | 331 +-------+-------+ 332 | Network | 333 | Orchestration | 334 +-------+-------+ 335 Network Configuration Model | 336 +-----------+-----------+ 337 | | 338 +--------+------+ +--------+------+ 339 | Domain | | Domain | 340 | Orchestration | | Orchestration | 341 +---+-----------+ +--------+------+ 342 Device | | | 343 Configuration | | | 344 Model | | | 345 +----+----+ | | 346 | Config | | | 347 | Manager | | | 348 +----+----+ | | 349 | | | 350 | NETCONF/CLI.................. 351 | | | 352 +------------------------------------------------+ 353 Network 355 Figure 1: L3NM Reference Architecture 357 The customer may use a variety of means to request a service that may 358 trigger the instantiation of an L3NM. The customer may use the L3SM 359 or more abstract models to request a service that relies upon an 360 L3VPN service. For example, the customer may supply an IP 361 Connectivity Provisioning Profile (CPP) [RFC7297], an enhanced VPN 362 (VPN+) service [I-D.ietf-teas-enhanced-vpn], or an IETF network slice 363 service [I-D.ietf-teas-ietf-network-slices]. 365 Note also that both the L3SM and the L3NM may be used in the context 366 of the Abstraction and Control of TE Networks (ACTN) [RFC8453]. 367 Figure 2 shows the Customer Network Controller (CNC), the Multi- 368 Domain Service Coordinator (MDSC), and the Provisioning Network 369 Controller (PNC) components and the interfaces where L3SM/L3NM are 370 used. 372 +----------------------------------+ 373 | Customer | 374 | +-----------------------------+ | 375 | | CNC | | 376 | +-----------------------------+ | 377 +----+-----------------------+-----+ 378 | | 379 | L3SM | L3SM 380 | | 381 +---------+---------+ +---------+---------+ 382 | MDSC | | MDSC | 383 | +---------------+ | | (parent) | 384 | | Service | | +---------+---------+ 385 | | Orchestration | | | 386 | +-------+-------+ | | L3NM 387 | | | | 388 | | L3NM | +---------+---------+ 389 | | | | MDSC | 390 | +-------+-------+ | | (child) | 391 | | Network | | +---------+---------+ 392 | | Orchestration | | | 393 | +---------------+ | | 394 +---------+---------+ | 395 | | 396 | Network Configuration | 397 | | 398 +------------+-------+ +---------+------------+ 399 | Domain | | Domain | 400 | Controller | | Controller | 401 | +---------+ | | +---------+ | 402 | | PNC | | | | PNC | | 403 | +---------+ | | +---------+ | 404 +------------+-------+ +---------+------------+ 405 | | 406 | Device Configuration | 407 | | 408 +----+---+ +----+---+ 409 | Device | | Device | 410 +--------+ +--------+ 412 Figure 2: L3SM and L3NM in the Context of ACTN 414 5. Relation with other YANG Models 416 The "ietf-vpn-common" module [I-D.ietf-opsawg-vpn-common] includes a 417 set of identities, types, and groupings that are meant to be reused 418 by VPN-related YANG modules independently of the layer (e.g., Layer 419 2, Layer 3) and the type of the module (e.g., network model, service 420 model) including future revisions of existing models (e.g., [RFC8299] 421 or [RFC8466]). The L3NM reuses these common types and groupings. 423 In order to avoid data duplication and to ease passing data between 424 layers when required (service layer to network layer and vice versa), 425 early versions of the L3NM reused many of the data nodes that are 426 defined in [RFC8299]. Nevertheless, that approach was abandoned in 427 favor of the "ietf-vpn-common" module because that initial design was 428 interpreted as if the deployment of L3NM depends on L3SM, while this 429 is not the case. For example, a service provider may decide to use 430 the L3NM to build its L3VPN services without exposing the L3SM. 432 As discussed in Section 4, the L3NM is meant to manage L3VPN services 433 within a service provider network. The module provides a network 434 view of the service. Such a view is only visible within the service 435 provider and is not exposed outside (to customers, for example). The 436 following discusses how L3NM interfaces with other YANG modules: 438 L3SM: L3NM is not a customer service model. 440 The internal view of the service (i.e., L3NM) may be mapped to an 441 external view which is visible to customers: L3VPN Service YANG 442 data Model (L3SM) [RFC8299]. 444 The L3NM can be fed with inputs that are requested by customers, 445 typically, relying upon an L3SM template. Concretely, some parts 446 of the L3SM module can be directly mapped into L3NM while other 447 parts are generated as a function of the requested service and 448 local guidelines. Some other parts are local to the service 449 provider and do not map directly to L3SM. 451 Note that the use of L3NM within a service provider does not 452 assume nor preclude exposing the VPN service via the L3SM. This 453 is deployment-specific. Nevertheless, the design of L3NM tries to 454 align as much as possible with the features supported by the L3SM 455 to ease grafting both L3NM and L3SM for the sake of highly 456 automated VPN service provisioning and delivery. 458 Network Topology Modules: An L3VPN involves nodes that are part of a 459 topology managed by the service provider network. Such topology 460 can be represented using the network topology module in [RFC8345]. 462 Device Modules: L3NM is not a device model. 464 Once a global VPN service is captured by means of L3NM, the actual 465 activation and provisioning of the VPN service will involve a 466 variety of device modules to tweak the required functions for the 467 delivery of the service. These functions are supported by the VPN 468 nodes and can be managed using device YANG modules. A non- 469 comprehensive list of such device YANG modules is provided below: 471 * Routing management [RFC8349]. 473 * BGP [I-D.ietf-idr-bgp-model]. 475 * PIM [I-D.ietf-pim-yang]. 477 * NAT management [RFC8512]. 479 * QoS management [I-D.ietf-rtgwg-qos-model]. 481 * ACLs [RFC8519]. 483 How L3NM is used to derive device-specific actions is 484 implementation-specific. 486 6. Sample Uses of the L3NM Data Model 488 This section provides a non-exhaustive list of examples to illustrate 489 contexts where the L3NM can be used. 491 6.1. Enterprise Layer 3 VPN Services 493 Enterprise L3VPNs are one of the most demanded services for carriers, 494 and therefore, L3NM can be useful to automate the provisioning and 495 maintenance of these VPNs. Templates and batch processes can be 496 built, and as a result many parameters are needed for the creation 497 from scratch of a VPN that can be abstracted to the upper Software- 498 Defined Networking (SDN) [RFC7149][RFC7426] layer and little manual 499 intervention will be still required. 501 A common function that is supported by VPNs is the addition or 502 removal of customer sites. Workflows can use the L3NM in these 503 scenarios to add or prune nodes from the network data model as 504 required. 506 6.2. Multi-Domain Resource Management 508 The implementation of L3VPN services which span across 509 administratively separated domains (i.e., that are under the 510 administration of different management systems or controllers) 511 requires some network resources to be synchronized between systems. 512 Particularly, resources must be adequately managed in each domain to 513 avoid broken configuration. 515 For example, route targets (RTs) shall be synchronized between PEs. 516 When all PEs are controlled by the same management system, RT 517 allocation can be performed by that management system. In cases 518 where the service spans across multiple management systems, the task 519 of allocating RTs has to be aligned across the domains, therefore, 520 the service model must provide a way to specify RTs. In addition, 521 route distinguishers (RDs) must also be synchronized to avoid 522 collisions in RD allocation between separate management systems. An 523 incorrect allocation might lead to the same RD and IP prefixes being 524 exported by different PEs. 526 6.3. Management of Multicast Services 528 Multicast services over L3VPN can be implemented using dual PIM MVPNs 529 (also known as, Draft Rosen model) [RFC6037] or Multiprotocol BGP 530 (MP-BGP)-based MVPNs [RFC6513][RFC6514]. Both methods are supported 531 and equally effective, but the main difference is that MBGP-based 532 MVPN does not require multicast configuration on the service provider 533 network. MBGP MVPNs employ the intra-autonomous system BGP control 534 plane and PIM sparse mode as the data plane. The PIM state 535 information is maintained between PEs using the same architecture 536 that is used for unicast VPNs. 538 On the other hand, [RFC6037] has limitations such as reduced options 539 for transport, control plane scalability, availability, operational 540 inconsistency, and the need of maintaining state in the backbone. 541 Because of these limitations, MBGP MVPN is the architectural model 542 that has been taken as the base for implementing multicast service in 543 L3VPNs. In this scenario, BGP is used to auto-discover MVPN PE 544 members and the customer PIM signaling is sent across the provider's 545 core through MP-BGP. The multicast traffic is transported on MPLS 546 P2MP LSPs. 548 7. Description of the L3NM YANG Module 550 The L3NM ('ietf-l3vpn-ntw') is defined to manage L3VPNs in a service 551 provider network. In particular, the 'ietf-l3vpn-ntw' module can be 552 used to create, modify, and retrieve L3VPN services of a network. 554 The full tree diagram of the module can be generated using the 555 "pyang" tool [PYANG]. That tree is not included here because it is 556 too long (Section 3.3 of [RFC8340]). Instead, subtrees are provided 557 for the reader's convenience. 559 7.1. Overall Structure of the Module 561 The 'ietf-l3vpn-ntw' module uses two main containers: 'vpn-services' 562 and 'vpn-profiles' (see Figure 3). 564 The 'vpn-profiles' container is used by the provider to maintain a 565 set of common VPN profiles that apply to one or several VPN services 566 (Section 7.2). 568 The 'vpn-services' container maintains the set of VPN services 569 managed within the service provider network. 'vpn-service' is the 570 data structure that abstracts a VPN service (Section 7.3). 572 module: ietf-l3vpn-ntw 573 +--rw l3vpn-ntw 574 +--rw vpn-profiles 575 | ... 576 +--rw vpn-services 577 +--rw vpn-service* [vpn-id] 578 ... 579 +--rw vpn-nodes 580 +--rw vpn-node* [vpn-node-id] 581 ... 582 +--rw vpn-network-accesses 583 +--rw vpn-network-access* [id] 584 ... 586 Figure 3: Overall L3NM Tree Structure 588 7.2. VPN Profiles 590 The 'vpn-profiles' container (Figure 4) allows the VPN service 591 provider to define and maintain a set of VPN profiles 592 [I-D.ietf-opsawg-vpn-common] that apply to one or several VPN 593 services. 595 This document does not make any assumption about the exact definition 596 of these profiles. The exact definition of the profiles is local to 597 each VPN service provider. The model only includes an identifier to 598 these profiles in order to ease identifying and binding local 599 policies when building a VPN service. As shown in Figure 4, the 600 following identifiers can be included: 602 'external-connectivity-identifier': This identifier refers to a 603 profile that defines the external connectivity provided to a VPN 604 service (or a subset of VPN sites). An external connectivity may 605 be an access to the Internet or a restricted connectivity such as 606 access to a public/private cloud. 608 'encryption-profile-identifier': An encryption profile refers to a 609 set of policies related to the encryption schemes and setup that 610 can be applied when building and offering a VPN service. 612 'qos-profile-identifier': A Quality of Service (QoS) profile refers 613 to as set of policies such as classification, marking, and actions 614 (e.g., [RFC3644]). 616 'bfd-profile-identifier': A Bidirectional Forwarding Detection (BFD) 617 profile refers to a set of BFD [RFC5880] policies that can be 618 invoked when building a VPN service. 620 'forwarding-profile-identifier': A forwarding profile refers to the 621 policies that apply to the forwarding of packets conveyed within a 622 VPN. Such policies may consist, for example, at applying Access 623 Control Lists (ACLs). 625 'routing-profile-identifier': A routing profile refers to a set of 626 routing policies that will be invoked (e.g., BGP policies) when 627 delivering the VPN service. 629 +--rw l3vpn-ntw 630 +--rw vpn-profiles 631 | +--rw valid-provider-identifiers 632 | +--rw external-connectivity-identifier* [id] 633 | | {external-connectivity}? 634 | | +--rw id string 635 | +--rw encryption-profile-identifier* [id] 636 | | +--rw id string 637 | +--rw qos-profile-identifier* [id] 638 | | +--rw id string 639 | +--rw bfd-profile-identifier* [id] 640 | | +--rw id string 641 | +--rw forwarding-profile-identifier* [id] 642 | | +--rw id string 643 | +--rw routing-profile-identifier* [id] 644 | +--rw id string 645 +--rw vpn-services 646 ... 648 Figure 4: VPN Profiles Subtree Structure 650 7.3. VPN Services 652 The 'vpn-service' is the data structure that abstracts a VPN service 653 in the service provider network. Each 'vpn-service' is uniquely 654 identified by an identifier: 'vpn-id'. Such 'vpn-id' is only 655 meaningful locally within the network controller. The subtree of the 656 'vpn-services' is shown in Figure 5. 658 +--rw l3vpn-ntw 659 +--rw vpn-profiles 660 | ... 661 +--rw vpn-services 662 +--rw vpn-service* [vpn-id] 663 +--rw vpn-id vpn-common:vpn-id 664 +--rw vpn-name? string 665 +--rw vpn-description? string 666 +--rw customer-name? string 667 +--rw parent-service-id? vpn-common:vpn-id 668 +--rw vpn-type? identityref 669 +--rw vpn-service-topology? identityref 670 +--rw status 671 | +--rw admin-status 672 | | +--rw status? identityref 673 | | +--rw last-updated? yang:date-and-time 674 | +--ro oper-status 675 | +--ro status? identityref 676 | +--ro last-updated? yang:date-and-time 677 +--rw vpn-instance-profiles 678 | ... 679 +--rw underlay-transport 680 | +-- (type)? 681 | +--:(abstract) 682 | | +-- transport-instance-id? string 683 | +--:(protocol) 684 | +-- protocol* identityref 685 +--rw external-connectivity 686 | {external-connectivity} 687 | +--rw (profile)? 688 | +--:(profile) 689 | +--rw profile-name? leafref 690 +--rw vpn-nodes 691 ... 693 Figure 5: VPN Services Subtree Structure 695 The description of the VPN service data nodes that are depicted in 696 Figure 5 are as follows: 698 'vpn-id': Is an identifier that is used to uniquely identify the 699 L3VPN service within L3NM scope. 701 'vpn-name': Associates a name with the service in order to 702 facilitate the identification of the service. 704 'vpn-description': Includes a textual description of the service. 706 The internal structure of a VPN description is local to each VPN 707 service provider. 709 'customer-name': Indicates the name of the customer who ordered the 710 service. 712 'parent-service-id': Refers to an identifier of the parent service 713 (e.g, L3SM, IETF network slice, VPN+) that triggered the creation 714 of the VPN service. This identifier is used to easily correlate 715 the (network) service as built in the network with a service 716 order. A controller can use that correlation to enrich or 717 populate some fields (e.g., description fields) as a function of 718 local deployments. 720 'vpn-type': Indicates the VPN type. The values are taken from 721 [I-D.ietf-opsawg-vpn-common]. For the L3NM, this is typically set 722 to BGP/MPLS L3VPN, but other values may be defined in the future 723 to support specific Layer 3 VPN capabilities (e.g., 724 [I-D.ietf-bess-evpn-prefix-advertisement]). 726 'vpn-service-topology': Indicates the network topology for the 727 service: hub-spoke, any-to-any, or custom. The network 728 implementation of this attribute is defined by the correct usage 729 of import and export profiles (Section 4.3.5 of [RFC4364]). 731 'status': Is used to track the service status of a given VPN 732 service. Both operational and administrative status are 733 maintained together with a timestamp. For example, a service can 734 be created, but not put into effect. 736 Administrative and operational status can be used as a trigger to 737 detect service anomalies. For example, a service that is declared 738 at the service layer as being active but still inactive at the 739 network layer is an indication that network provision actions are 740 needed to align the observed service status with the expected 741 service status. 743 'vpn-instance-profiles': Defines reusable parameters for the same 744 'vpn-service'. 746 More details are provided in Section 7.4. 748 'underlay-transport': Describes the preference for the transport 749 technology to carry the traffic of the VPN service. This 750 preference is especially useful in networks with multiple domains 751 and Network-to-Network Interface (NNI) types. The underlay 752 transport can be expressed as an abstract transport instance 753 (e.g., an identifier of a VPN+ instance, a virtual network 754 identifier, or a network slice name) or as an ordered list of the 755 actual protocols to be enabled in the network. 757 A rich set of protocol identifiers that can be used to refer to an 758 underlay transport are defined in [I-D.ietf-opsawg-vpn-common]. 760 'external-connectivity': Indicates whether/how external connectivity 761 is provided to the VPN service. For example, a service provider 762 may provide an external connectivity to a VPN customer (e.g., to a 763 public cloud). Such service may involve tweaking both filtering 764 and NAT rules (e.g., bind a Virtual Routing and Forwarding (VRF) 765 interface with a NAT instance as discussed in Section 2.10 of 766 [RFC8512]). These added value features may be bound to all or a 767 subset of network accesses. Some of these added value features 768 may be implemented in a PE or in other nodes than PEs (e.g., a P 769 node or event a dedicated node that hosts the NAT function). 771 Only a pointer to a local profile that defines the external 772 connectivity feature is supported in this document. 774 'vpn-node': Is an abstraction that represents a set of policies 775 applied to a network node and that belong to a single 'vpn- 776 service'. A VPN service is typically built by adding instances of 777 'vpn-node' to the 'vpn-nodes' container. 779 A 'vpn-node' contains 'vpn-network-accesses', which are the 780 interfaces attached to the VPN by which the customer traffic is 781 received. Therefore, the customer sites are connected to the 782 'vpn-network-accesses'. 784 Note that, as this is a network data model, the information about 785 customers sites is not required in the model. Such information is 786 rather relevant in the L3SM. Whether that information is included 787 in the L3NM, e.g., to populate the various 'description' data node 788 is implementation specific. 790 More details are provided in Section 7.5. 792 7.4. VPN Instance Profiles 794 VPN instance profiles are meant to factorize data nodes that are used 795 at many levels of the model. Generic VPN instance profiles are 796 defined at the VPN service level and then called at the VPN node and 797 VPN network access levels. Each VPN instance profile is identified 798 by 'profile-id'. This identifier is then referenced for one or 799 multiple VPN nodes (Section 7.5) so that the controller can identify 800 generic resources (e.g., RTs and RDs) to be configured for a given 801 VRF. 803 The subtree of 'vpn-instance-profile' is shown in Figure 6. 805 +--rw l3vpn-ntw 806 +--rw vpn-profiles 807 | ... 808 +--rw vpn-services 809 +--rw vpn-service* [vpn-id] 810 +--rw vpn-id vpn-common:vpn-id 811 ... 812 +--rw vpn-instance-profiles 813 | +--rw vpn-instance-profile* [profile-id] 814 | +--rw profile-id string 815 | +--rw role? identityref 816 | +--rw local-autonomous-system? inet:as-number 817 | | {vpn-common:rtg-bgp}? 818 | +--rw (rd-choice)? 819 | | +--:(directly-assigned) 820 | | | +--rw rd? 821 | | | rt-types:route-distinguisher 822 | | +--:(directly-assigned-suffix) 823 | | | +--rw rd-suffix? uint16 824 | | +--:(auto-assigned) 825 | | | +--rw rd-auto 826 | | | +--rw (auto-mode)? 827 | | | | +--:(from-pool) 828 | | | | | +--rw rd-pool-name? string 829 | | | | +--:(full-auto) 830 | | | | +--rw auto? empty 831 | | | +--ro auto-assigned-rd? 832 | | | rt-types:route-distinguisher 833 | | +--:(auto-assigned-suffix) 834 | | | +--rw rd-auto-suffix 835 | | | +--rw (auto-mode)? 836 | | | | +--:(from-pool) 837 | | | | | +--rw rd-pool-name? string 838 | | | | +--:(full-auto) 839 | | | | +--rw auto? empty 840 | | | +--ro auto-assigned-rd-suffix? uint16 841 | | +--:(no-rd) 842 | | +--rw no-rd? empty 843 | +--rw address-family* [address-family] 844 | | +--rw address-family identityref 845 | | +--rw vpn-targets 846 | | | +--rw vpn-target* [id] 847 | | | | +--rw id int8 848 | | | | +--rw route-targets* [route-target] 849 | | | | | +--rw route-target 850 | | | | | rt-types:route-target 851 | | | | +--rw route-target-type 852 | | | | rt-types:route-target-type 853 | | | +--rw vpn-policies 854 | | | +--rw import-policy? string 855 | | | +--rw export-policy? string 856 | | +--rw maximum-routes* [protocol] 857 | | +--rw protocol identityref 858 | | +--rw maximum-routes? uint32 859 | +--rw multicast {vpn-common:multicast}? 860 | ... 862 Figure 6: Subtree Structure of VPN Instance Profiles 864 The description of the listed data nodes is as follows: 866 'profile-id': Is used to uniquely identify a VPN instance profile. 868 'role': Indicates the role of the VPN instance profile in the VPN. 869 Role values are defined in [I-D.ietf-opsawg-vpn-common] (e.g., 870 any-to-any-role, spoke-role, hub-role). 872 'local-autonomous-system': Indicates the Autonomous System Number 873 (ASN) that is configured for the VPN node. 875 'rd': As defined in [I-D.ietf-opsawg-vpn-common], these RD 876 assignment modes are supported: direct assignment, automatic 877 assignment from a given pool, automatic assignment, and no 878 assignment. For illustration purposes, the following modes can be 879 used in the deployment cases: 881 'directly-assigned': The VPN service provider (service 882 orchestrator) assigns explicitly RDs. This case will fit with 883 a brownfield scenario where some existing services need to be 884 updated by the VPN service provider. 886 'full-auto': The network controller auto-assigns RDs. This can 887 apply for the deployment of new services. 889 'no-rd': The VPN service provider (service orchestrator) 890 explicitly wants no RD to be assigned. This case can be used 891 for CE testing within the network or for troubleshooting 892 proposes. 894 Also, the module accommodates deployments where only the Assigned 895 Number subfield of RDs (Section 4.2 of [RFC4364]) is assigned from 896 a pool while the Administrator subfield is set to, e.g., the 897 Router ID that is assigned to a VPN node. The module supports 898 these modes for managing the Assigned Number subfield: explicit 899 assignment, auto-assignment from a pool, and full auto-assignment. 901 'address-family': Includes a set of per-address family data nodes: 903 'address-family': Identifies the address family. It can be set 904 to IPv4, IPv6, or dual-stack. 906 'vpn-targets': Specifies RT import/export rules for the VPN 907 service (Section 4.3 of [RFC4364]). 909 'maximum-routes': Indicates the maximum prefixes that the VPN 910 node can accept for a given routing protocol. If 'protocol' is 911 set to 'any', this means that the maximum value applies to each 912 active routing protocol. 914 'multicast': Enables multicast traffic in the VPN service. Refer to 915 Section 7.7. 917 7.5. VPN Nodes 919 The 'vpn-node' is an abstraction that represents a set of common 920 policies applied on a given network node (typically, a PE) and belong 921 to one L3VPN service. The 'vpn-node' includes a parameter to 922 indicate the network node on which it is applied. In the case that 923 the 'ne-id' points to a specific PE, the 'vpn-node' will likely be 924 mapped into a VRF in the node. However, the model also allows to 925 point to an abstract node. In this case, the network controller will 926 decide how to split the 'vpn-node' into VRFs. 928 +--rw l3vpn-ntw 929 +--rw vpn-profiles 930 | ... 931 +--rw vpn-services 932 +--rw vpn-service* [vpn-id] 933 ... 934 +--rw vpn-nodes 935 +--rw vpn-node* [vpn-node-id] 936 +--rw vpn-node-id vpn-common:vpn-id 937 +--rw description? string 938 +--rw ne-id? string 939 +--rw local-autonomous-system? inet:as-number 940 | {vpn-common:rtg-bgp}? 941 +--rw router-id? rt-types:router-id 942 +--rw active-vpn-instance-profiles 943 | +--rw vpn-instance-profile* [profile-id] 944 | +--rw profile-id leafref 945 | +--rw router-id* [address-family] 946 | | +--rw address-family identityref 947 | | +--rw router-id? inet:ip-address 948 | +--rw local-autonomous-system? inet:as-number 949 | | {vpn-common:rtg-bgp}? 950 | +--rw (rd-choice)? 951 | | .... 952 | +--rw address-family* [address-family] 953 | | +--rw address-family identityref 954 | | | ... 955 | | +--rw vpn-targets 956 | | | ... 957 | | +--rw maximum-routes* [protocol] 958 | | ... 959 | +--rw multicast {vpn-common:multicast}? 960 | ... 961 +--rw msdp {msdp}? 962 | +--rw peer? inet:ipv4-address 963 | +--rw local-address? inet:ipv4-address 964 | +--rw status 965 | +--rw admin-status 966 | | +--rw status? identityref 967 | | +--rw last-updated? yang:date-and-time 968 | +--ro oper-status 969 | +--ro status? identityref 970 | +--ro last-updated? yang:date-and-time 971 +--rw groups 972 | +--rw group* [group-id] 973 | +--rw group-id string 974 +--rw status 975 | +--rw admin-status 976 | | +--rw status? identityref 977 | | +--rw last-updated? yang:date-and-time 978 | +--ro oper-status 979 | +--ro status? identityref 980 | +--ro last-updated? yang:date-and-time 981 +--rw vpn-network-accesses 982 ... 984 Figure 7: VPN Node Subtree Structure 986 In reference to the subtree shown in Figure 7, the description of VPN 987 node data nodes is as follows: 989 'vpn-node-id': Is an identifier that uniquely identifies a node that 990 enables a VPN network access. 992 'description': Provides a textual description of the VPN node. 994 'ne-id': Includes a unique identifier of the network element where 995 the VPN node is deployed. 997 'local-autonomous-system': Indicates the ASN that is configured for 998 the VPN node. 1000 'router-id': Indicates a 32-bit number that is used to uniquely 1001 identify a router within an Autonomous System. 1003 'active-vpn-instance-profiles': Lists the set of active VPN instance 1004 profiles for this VPN node. Concretely, one or more VPN instance 1005 profiles that are defined at the VPN service level can be enabled 1006 at the VPN node level; each of these profiles is uniquely 1007 identified by means of 'profile-id'. The structure of 'active- 1008 vpn-instance-profiles' is the same as the one discussed in 1009 Section 7.4 with the exception of 'router-id'. Indeed, Router IDs 1010 can be configured per address family. This capability can be 1011 used, for example, to configure an IPv6 address as a Router ID 1012 when such capability is supported by involved routers. 1014 Values defined in 'active-vpn-instance-profiles' overrides the 1015 ones defined in the VPN service level. 1017 'msdp': For redundancy purposes, Multicast Source Discovery Protocol 1018 (MSDP) [RFC3618] may be enabled and used to share the state about 1019 sources between multiple rendez-vous points (RPs). The purpose of 1020 MSDP in this context is to enhance the robustness of the multicast 1021 service. MSDP may be configured on non-RP routers, which is 1022 useful in a domain that does not support multicast sources, but 1023 does support multicast transit. 1025 'groups': Lists the groups to which a VPN node belongs to 1026 [I-D.ietf-opsawg-vpn-common]. The 'group-id' is used to 1027 associate, e.g., redundancy or protection constraints with VPN 1028 nodes. 1030 'status': Tracks the status of a node involved in a VPN service. 1031 Both operational and administrative status are maintained. A 1032 mismatch between the administrative status vs. the operational 1033 status can be used as a trigger to detect anomalies. 1035 'vpn-network-accesses': Represents the point to which sites are 1036 connected. 1038 Note that, unlike in L3SM, the L3NM does not need to model the 1039 customer site, only the points where the traffic from the site are 1040 received (i.e., the PE side of PE-CE connections). Hence, the VPN 1041 network access contains the connectivity information between the 1042 provider's network and the customer premises. The VPN profiles 1043 ('vpn-profiles') have a set of routing policies that can be 1044 applied during the service creation. 1046 See Section 7.6 for more details. 1048 7.6. VPN Network Access 1050 The 'vpn-network-access' includes a set of data nodes that describe 1051 the access information for the traffic that belongs to a particular 1052 L3VPN (Figure 8). 1054 ... 1055 +--rw vpn-nodes 1056 +--rw vpn-node* [vpn-node-id] 1057 ... 1058 +--rw vpn-network-accesses 1059 +--rw vpn-network-access* [id] 1060 +--rw id vpn-common:vpn-id 1061 +--rw port-id? vpn-common:vpn-id 1062 +--rw description? string 1063 +--rw vpn-network-access-type? identityref 1064 +--rw vpn-instance-profile? leafref 1065 +--rw status 1066 | +--rw admin-status 1067 | | +--rw status? identityref 1068 | | +--rw last-updated? yang:date-and-time 1069 | +--ro oper-status 1070 | +--ro status? identityref 1071 | +--ro last-updated? yang:date-and-time 1072 +--rw connection 1073 | ... 1074 +--rw ip-connection 1075 | ... 1076 +--rw routing-protocols 1077 | ... 1078 +--rw oam 1079 | ... 1080 +--rw security 1081 | ... 1082 +--rw service 1083 ... 1085 Figure 8: VPN Network Access Subtree Structure 1087 In reference to the subtree depicted in Figure 8, a 'vpn-network- 1088 access' includes the following data nodes: 1090 'id': Is an identifier of the VPN network access. 1092 'port-id': Indicates the port on which the VPN network access is 1093 bound. 1095 'description': Includes a textual description of the VPN network 1096 access. 1098 'vpn-network-access-type': Is used to select the type of network 1099 interface to be deployed in the devices. The available defined 1100 values are: 1102 'point-to-point': Represents a direct connection between the 1103 endpoints. The controller must keep the association between a 1104 logical or physical interface on the device with the 'id' of 1105 the 'vpn-network-access'. 1107 'multipoint': Represents a broadcast connection between the 1108 endpoints. The controller must keep the association between a 1109 logical or physical interface on the device with the 'id' of 1110 the 'vpn-network-access'. 1112 'irb': Represents a connection coming from an L2VPN service. An 1113 identifier of such service ('l2vpn-id') may be included in the 1114 'connection' container as depicted in Figure 9. The controller 1115 must keep the relationship between the logical tunnels or 1116 bridges on the devices with the 'id' of the' vpn-network- 1117 access'. 1119 'loopback': Represents the creation of a logical interface on a 1120 device. An example to illustrate how a loopback interface can 1121 be used in the L3NM is provided in Appendix A.2. 1123 'vpn-instance-profile': Provides a pointer to an active VPN instance 1124 profile at the VPN node level. Referencing an active VPN instance 1125 profile implies that all associated data nodes will be inherited 1126 by the VPN network access. However, some of the inherited data 1127 nodes (e.g., multicast) can be refined at the VPN network access 1128 level. In such case, refined values take precedence over 1129 inherited ones. 1131 'status': Indicates both operational and administrative status of a 1132 VPN network access. 1134 'connection': Represents and groups the set of Layer 2 connectivity 1135 from where the traffic of the L3VPN in a particular VPN Network 1136 access is coming. See Section 7.6.1. 1138 'ip-connection': Contains Layer 3 connectivity information of a VPN 1139 network access (e.g., IP addressing). See Section 7.6.2. 1141 'routing-protocols': Includes the CE-PE rouing configuration 1142 information. See Section 7.6.3. 1144 'oam': Specifies the Operations, Administration, and Maintenance 1145 (OAM) mechanisms used for a VPN network access. See 1146 Section 7.6.4. 1148 'security': Specifies the authentication and the encryption to be 1149 applied for a given VPN network access. See Section 7.6.5. 1151 'service': Specifies the service parameters (e.g., QoS, multicast) 1152 to apply for a given VPN network access. See Section 7.6.6. 1154 7.6.1. Connection 1156 The 'connection' container represents the layer 2 connectivity to the 1157 L3VPN for a particular VPN network access. As shown in the tree 1158 depicted in Figure 9, the 'connection' container defines protocols 1159 and parameters to enable such connectivity at layer 2. 1161 The traffic can enter the VPN with or without encapsulation (e.g., 1162 VLAN, QinQ). The 'encapsulation' container specifies the layer 2 1163 encapsulation to use (if any) and allows to configure the relevant 1164 tags. 1166 The interface that is attached to the L3VPN is identified by the 1167 'port-id' at the 'vpn-network-access' level. From a network model 1168 perspective, it is expected that the 'port-id' is sufficient to 1169 identify the interface. However, specific layer 2 sub-interfaces may 1170 be required to be configured in some implementations/deployments. 1171 Such a layer 2 specific interface can be included in 'l2-termination- 1172 point'. 1174 If a layer 2 tunnel is needed to terminate the service in the CE-PE 1175 connection, the 'l2-tunnel-service' container is used to specify the 1176 required parameters to set such tunneling service (e.g., VPLS, 1177 VXLAN). An identity, called 'l2-tunnel-type', is defined for layer 2 1178 tunnel selection. 1180 As discussed in Section 7.6, 'l2vpn-id' is used to identify the L2VPN 1181 service that is associated with an IRB interface. 1183 To accommodate implementations that require internal bridging, a 1184 local bridge reference can be specified in 'local-bridge-reference'. 1185 Such a reference may be a local bridge domain. 1187 A site, as per [RFC4176] represents a VPN customer's location that is 1188 connected to the service provider network via a CE-PE link, which can 1189 access at least one VPN. The connection from the site to the service 1190 provider network is the bearer. Every site is associated with a list 1191 of bearers. A bearer is the layer two connections with the site. In 1192 the L3NM, it is assumed that the bearer has been allocated by the 1193 service provider at the service orchestration stage. The bearer is 1194 associated to a network element and a port. Hence, a bearer is just 1195 a 'bearer-reference' to allow the association between a service 1196 request (e.g., L3SM) and L3NM. 1198 ... 1199 +--rw connection 1200 | +--rw encapsulation 1201 | | +--rw type? identityref 1202 | | +--rw dot1q {vpn-common:dot1q}? 1203 | | | +--rw tag-type? identityref 1204 | | | +--rw cvlan-id? uint16 1205 | | +--rw priority-tagged 1206 | | | +--rw tag-type? identityref 1207 | | +--rw qinq {vpn-common:qinq}? 1208 | | +--rw tag-type? identityref 1209 | | +--rw svlan-id uint16 1210 | | +--rw cvlan-id uint16 1211 | +--rw (l2-service)? 1212 | | +--:(l2-tunnel-service) 1213 | | | +--rw l2-tunnel-service 1214 | | | +--rw type? identityref 1215 | | | +--rw pseudowire 1216 | | | | +--rw vcid? uint32 1217 | | | | +--rw far-end? union 1218 | | | +--rw vpls 1219 | | | | +--rw vcid? uint32 1220 | | | | +--rw far-end* union 1221 | | | +--rw vxlan {vpn-common:vxlan}? 1222 | | | +--rw vni-id uint32 1223 | | | +--rw peer-mode? identityref 1224 | | | +--rw peer-ip-address* inet:ip-address 1225 | | +--:(l2vpn) 1226 | | +--rw l2vpn-id? vpn-common:vpn-id 1227 | +--rw l2-termination-point? vpn-common:vpn-id 1228 | +--rw local-bridge-reference? vpn-common:vpn-id 1229 | +--rw bearer-reference? string 1230 {vpn-common:bearer-reference}? 1231 ... 1233 Figure 9: Connection Subtree Structure 1235 7.6.2. IP Connection 1237 This container is used to group Layer 3 connectivity information, 1238 particularly the IP addressing information, of a VPN network access. 1239 The allocated address represents the PE interface address 1240 configuration. Note that a distinct layer 3 interface than the one 1241 indicated under the 'connection' container may be needed to terminate 1242 the layer 3 service. The identifier of such interface is included in 1243 'l3-termination-point'. For example, this data node can be used to 1244 carry the identifier of a bridge domain Interface. 1246 As shown in Figure 10, the 'ip-connection' container can include 1247 IPv4, IPv6, or both if dual-stack is enabled. 1249 ... 1250 +--rw vpn-network-accesses 1251 +--rw vpn-network-access* [id] 1252 ... 1253 +--rw ip-connection 1254 | +--rw l3-termination-point? vpn-common:vpn-id 1255 | +--rw ipv4 {vpn-common:ipv4}? 1256 | | ... 1257 | +--rw ipv6 {vpn-common:ipv6}? 1258 | ... 1259 ... 1261 Figure 10: IP Connection Subtree Structure 1263 For both IPv4 and IPv6, the IP connection supports three IP address 1264 assignment modes for customer addresses: provider DHCP, DHCP relay, 1265 and static addressing. Note that for the IPv6 case, SLAAC [RFC4862] 1266 can be used. For both IPv4 and IPv6, 'address-allocation-type' is 1267 used to indicate the IP address allocation mode to activate for a 1268 given VPN network access. 1270 When 'address-allocation-type' is set to 'provider-dhcp', DHCP 1271 assignments can be made locally or by an external DHCP server. Such 1272 as behavior is controlled by setting 'dhcp-service-type'. 1274 Figure 11 shows the structure of the dynamic IPv4 address assignment 1275 (i.e., by means of DHCP). 1277 ... 1278 +--rw ip-connection 1279 | +--rw l3-termination-point? vpn-common:vpn-id 1280 | +--rw ipv4 {vpn-common:ipv4}? 1281 | | +--rw local-address? inet:ipv4-address 1282 | | +--rw prefix-length? uint8 1283 | | +--rw address-allocation-type? identityref 1284 | | +--rw (allocation-type)? 1285 | | +--:(provider-dhcp) 1286 | | | +--rw dhcp-service-type? enumeration 1287 | | | +--rw (service-type)? 1288 | | | +--:(relay) 1289 | | | | +--rw server-ip-address* 1290 | | | | inet:ipv4-address 1291 | | | +--:(server) 1292 | | | +--rw (address-assign)? 1293 | | | +--:(number) 1294 | | | | +--rw number-of-dynamic-address? 1295 | | | | uint16 1296 | | | +--:(explicit) 1297 | | | +--rw customer-addresses 1298 | | | +--rw address-pool* [pool-id] 1299 | | | +--rw pool-id string 1300 | | | +--rw start-address? 1301 | | | | inet:ipv4-address 1302 | | | +--rw end-address? 1303 | | | inet:ipv4-address 1304 | | +--:(dhcp-relay) 1305 | | | +--rw customer-dhcp-servers 1306 | | | +--rw server-ip-address* inet:ipv4-address 1307 | | +--:(static-addresses) 1308 | | ... 1309 ... 1311 Figure 11: IP Connection Subtree Structure (IPv4) 1313 Figure 12 shows the structure of the dynamic IPv6 address assignment 1314 (i.e., DHCPv6 and/or SLAAC). Note that if 'address-allocation-type' 1315 is set to 'slaac', the Prefix Information option of Router 1316 Advertisements that will be issued for SLAAC purposes, will carry the 1317 IPv6 prefix that is determined by 'local-address' and 'prefix- 1318 length'. For example, if 'local-address' is set to '2001:db8:0:1::1' 1319 and 'prefix-length' is set to '64', the IPv6 prefix that will be used 1320 is '2001:db8:0:1::/64'. 1322 ... 1323 +--rw ip-connection 1324 | +--rw l3-termination-point? vpn-common:vpn-id 1325 | +--rw ipv4 {vpn-common:ipv4}? 1326 | | ... 1327 | +--rw ipv6 {vpn-common:ipv6}? 1328 | +--rw local-address? inet:ipv6-address 1329 | +--rw prefix-length? uint8 1330 | +--rw address-allocation-type? identityref 1331 | +--rw (allocation-type)? 1332 | | +--rw provider-dhcp 1333 | | +--rw dhcp-service-type? enumeration 1334 | | +--rw (service-type)? 1335 | | +--:(provider-dhcp-servers) 1336 | | | +--rw server-ip-address* 1337 | | | inet:ipv6-address 1338 | | +--:(server) 1339 | | +--rw (address-assign)? 1340 | | +--:(number) 1341 | | | +--rw number-of-dynamic-address? 1342 | | | uint16 1343 | | +--:(explicit) 1344 | | +--rw customer-addresses 1345 | | +--rw address-pool* [pool-id] 1346 | | +--rw pool-id string 1347 | | +--rw start-address? 1348 | | | inet:ipv6-address 1349 | | +--rw end-address? 1350 | | inet:ipv6-address 1351 | +--:(dhcp-relay) 1352 | | +--rw customer-dhcp-servers 1353 | | +--rw server-ip-address* inet:ipv6-address 1354 | +--:(static-addresses) 1355 | ... 1356 ... 1358 Figure 12: IP Connection Subtree Structure (IPv6) 1360 In the case of the static addressing (Figure 13), the model supports 1361 the assignment of several IP addresses in the same 'vpn-network- 1362 access'. To identify which of the addresses is the primary address 1363 of a connection ,the 'primary-address' reference MUST be set with the 1364 corresponding 'address-id'. 1366 ... 1367 +--rw ip-connection 1368 | +--rw l3-termination-point? vpn-common:vpn-id 1369 | +--rw ipv4 {vpn-common:ipv4}? 1370 | | +--rw address-allocation-type? identityref 1371 | | +--rw (allocation-type)? 1372 | | ... 1373 | | +--:(static-addresses) 1374 | | +--rw primary-address? -> ../address/address-id 1375 | | +--rw address* [address-id] 1376 | | +--rw address-id string 1377 | | +--rw customer-address? inet:ipv4-address 1378 | +--rw ipv6 {vpn-common:ipv6}? 1379 | +--rw address-allocation-type? identityref 1380 | +--rw (allocation-type)? 1381 | ... 1382 | +--:(static-addresses) 1383 | +--rw primary-address? -> ../address/address-id 1384 | +--rw address* [address-id] 1385 | +--rw address-id string 1386 | +--rw customer-address? inet:ipv6-address 1387 ... 1389 Figure 13: IP Connection Subtree Structure (Static Mode) 1391 7.6.3. CE-PE Routing Protocols 1393 A VPN service provider can configure one or more routing protocols 1394 associated with a particular 'vpn-network-access'. Such routing 1395 protocol is enabled between the PE and the CE. Each instance is 1396 uniquely identified to accommodate scenarios where multiple instances 1397 of the same routing protocol have to be configured on the same link. 1399 The subtree of the 'routing-protocols' is shown in Figure 14. 1401 ... 1402 +--rw vpn-network-accesses 1403 +--rw vpn-network-access* [id] 1404 ... 1405 +--rw routing-protocols 1406 | +--rw routing-protocol* [id] 1407 | +--rw id string 1408 | +--rw type? identityref 1409 | +--rw routing-profiles* [id] 1410 | | +--rw id leafref 1411 | | +--rw type? identityref 1412 | +--rw static 1413 | | ... 1414 | +--rw bgp {vpn-common:rtg-bgp}? 1415 | | ... 1416 | +--rw ospf {vpn-common:rtg-ospf}? 1417 | | ... 1418 | +--rw isis {vpn-common:rtg-isis}? 1419 | | ... 1420 | +--rw rip {vpn-common:rtg-rip}? 1421 | | ... 1422 | +--rw vrrp {vpn-common:rtg-vrrp}? 1423 | ... 1424 +--rw security 1425 ... 1427 Figure 14: Routing Subtree Structure 1429 Multiple routing instances can be defined; each uniquely identified 1430 by an 'id'. The type of a routing instance is indicated in 'type'. 1431 The values of this attributes are those defined in 1432 [I-D.ietf-opsawg-vpn-common] ('routing-protocol-type' identity). 1434 Configuring multiple instances of the same routing protocol does not 1435 automatically imply that, from a device configuration perspective, 1436 there will be parallel instances (e.g., multiple processes) running 1437 on the PE-CE link. It is up to each implementation to decide about 1438 the appropriate configuration as a function of underlying 1439 capabilities and service provider operational guidelines. As an 1440 example, when multiple BGP peers need to be implemented, multiple 1441 instances of BGP must be configured as part of this model. However, 1442 from a device configuration point of view, this could be implemented 1443 as: 1445 o Multiple BGP processes with a single neighbor running in each 1446 process. 1448 o A single BGP process with multiple neighbors running. 1450 o A combination thereof. 1452 Routing configuration does not include low-level policies. Such 1453 policies are handed at the device configuration level. Local 1454 policies of a service provider (e.g., filtering) will be implemented 1455 as part of the device configuration; these are not captured in the 1456 L3NM, but the model allows to associate local profiles with routing 1457 instances ('routing-profiles'). 1459 The L3NM supports the configuration of one or more IPv4/IPv6 static 1460 routes. Since the same structure is used for both IPv4 and IPv6, it 1461 was considered to have one single container to group both static 1462 entries independently of their address family, but that design was 1463 abandoned to ease the mapping with the structure in [RFC8299]. As 1464 depicted in Figure 15, the following data nodes can be defined for a 1465 given IP prefix: 1467 'lan-tag': Indicates a local tag (e.g., "myfavourite-lan") that is 1468 used to enforce local policies. 1470 'next-hop': Indicates the next-hop to be used for the static route. 1471 It can be identified by an IP address, an interface, etc. 1473 'bfd-enable': Indicates whether BFD is enabled or disabled for this 1474 static route entry. 1476 'metric': Indicates the metric associated with the static route 1477 entry. 1479 'preference': Indicates the preference associated with the static 1480 route entry. This preference is used to selecting a preferred 1481 route among routes to the same destination prefix. 1483 'status': Used to convey the status of a static route entry. This 1484 data node is used to control the (de)activation of individual 1485 static route entries. 1487 ... 1488 +--rw routing-protocols 1489 | +--rw routing-protocol* [id] 1490 | ... 1491 | +--rw static 1492 | | +--rw cascaded-lan-prefixes 1493 | | +--rw ipv4-lan-prefixes* 1494 | | | [lan next-hop] 1495 | | | {vpn-common:ipv4}? 1496 | | | +--rw lan inet:ipv4-prefix 1497 | | | +--rw lan-tag? string 1498 | | | +--rw next-hop union 1499 | | | +--rw bfd-enable? boolean 1500 | | | +--rw metric? uint32 1501 | | | +--rw preference? uint32 1502 | | | +--rw status 1503 | | | +--rw admin-status 1504 | | | | +--rw status? identityref 1505 | | | | +--rw last-updated? yang:date-and-time 1506 | | | +--ro oper-status 1507 | | | +--ro status? identityref 1508 | | | +--ro last-updated? yang:date-and-time 1509 | | +--rw ipv6-lan-prefixes* 1510 | | [lan next-hop] 1511 | | {vpn-common:ipv6}? 1512 | | +--rw lan inet:ipv6-prefix 1513 | | +--rw lan-tag? string 1514 | | +--rw next-hop union 1515 | | +--rw bfd-enable? boolean 1516 | | +--rw metric? uint32 1517 | | +--rw preference? uint32 1518 | | +--rw status 1519 | | +--rw admin-status 1520 | | | +--rw status? identityref 1521 | | | +--rw last-updated? yang:date-and-time 1522 | | +--ro oper-status 1523 | | +--ro status? identityref 1524 | | +--ro last-updated? yang:date-and-time 1525 ... 1527 Figure 15: Static Routing Subtree Structure 1529 In addition, the L3NM supports the following CE-PE routing protocols: 1531 BGP: The L3NM allows to configure a BGP neighbor, including a set 1532 for parameters that are pertinent to be tweaked at the network 1533 level for service customization purposes. 1535 This container does not aim to include every BGP parameter; a 1536 comprehensive set of parameters belongs more to the BGP device 1537 model. 1539 The following data nodes are captured in Figure 16. It is up to 1540 the implementation to derive the corresponding BGP device 1541 configuration: 1543 'description': Includes a description of the BGP session. 1545 'local-autonomous-system': Indicates a local AS Number (ASN) if a 1546 distinct ASN than the one configured at the VPN node level is 1547 needed. 1549 'peer-autonomous-system': Conveys the customer's ASN. 1551 'address-family': Indicates the address-family of the peer. It 1552 can be set to IPv4, IPv6, or dual-stack. 1554 'local-address': Specifies an address or a reference to an 1555 interface to use when establishing the BGP transport session. 1557 'neighbor': Can indicate two neighbors (each for a given address- 1558 family) or one neighbor (if 'address-family' attribute is set 1559 to dual-stack). A list of IP address(es) of the BGP neighbors 1560 can be then conveyed in this data node. 1562 'multihop': Indicates the number of allowed IP hops between a PE 1563 and its BGP peer. 1565 'as-override': If set, this parameter indicates whether ASN 1566 override is enabled, i.e., replace the ASN of the customer 1567 specified in the AS_PATH BGP attribute with the ASN identified 1568 in the 'local-autonomous-system' attribute. 1570 'allow-own-as': Is used in some topologies (e.g., hub-and-spoke) 1571 to allow the provider's ASN to be included in the AS_PATH BGP 1572 attribute received from a CE. Loops are prevented by setting 1573 'allow-own-as' to a maximum number of provider's ASN 1574 occurrences. This parameter is set by default to '0' (that is, 1575 reject any AS_PATH attribute that includes the provider's ASN). 1577 'prepend-global-as': When distinct ASNs are configured in the VPN 1578 node and network access levels, this parameter controls whether 1579 the ASN provided at the VPN node level is prepended to the 1580 AS_PATH attribute. 1582 'default-route': Controls whether default routes can be 1583 advertised to the peer. 1585 'site-of-origin': Is meant to uniquely identify the set of routes 1586 learned from a site via a particular CE/PE connection and is 1587 used to prevent routing loops (Section 7 of [RFC4364]). The 1588 Site of Origin attribute is encoded as a Route Origin Extended 1589 Community. 1591 'ipv6-site-of-origin': Carries an IPv6 Address Specific BGP 1592 Extended that is used to indicate the Site of Origin for VRF 1593 information [RFC5701]. It is used to prevent routing loops. 1595 'redistribute-connected': Controls whether the PE-CE link is 1596 advertised to other PEs. 1598 'bgp-max-prefix': Controls the behavior when a prefix maximum is 1599 reached. 1601 'max-prefix': Indicates the maximum number of BGP prefixes 1602 allowed in the BGP session. If such limit is reached, the 1603 action indicated in 'action-violate' will be followed. 1605 'warning-threshold': A warning notification is triggered when 1606 this limit is reached. 1608 'violate-action': Indicates which action to execute when the 1609 maximum number of BGP prefixes is reached. Examples of such 1610 actions are: send a warning message, discard extra paths 1611 from the peer, or restart the session. 1613 'bgp-timers': Two timers can be captured in this container: (1) 1614 'hold-time' which is the time interval that will be used for 1615 the HoldTimer (Section 4.2 of [RFC4271]) when establishing a 1616 BGP session. (2) 'keepalive' which is the time interval for 1617 the KeepAlive timer between a PE and a BGP peer (Section 4.4 of 1618 [RFC4271]). 1620 'security': The module adheres to the recommendations in 1621 Section 13.2 of [RFC4364] as it allows to enable TCP-AO 1622 [RFC5925] and accommodates the installed base that makes use of 1623 MD5. In addition, the module includes a provision for the use 1624 of IPsec. 1626 'status': Indicates the status of the BGP routing instance. 1628 ... 1629 +--rw routing-protocols 1630 | +--rw routing-protocol* [id] 1631 | ... 1632 | +--rw bgp {vpn-common:rtg-bgp}? 1633 | | +--rw description? string 1634 | | +--rw local-autonomous-system? inet:as-number 1635 | | +--rw peer-autonomous-system inet:as-number 1636 | | +--rw address-family? identityref 1637 | | +--rw local-address? union 1638 | | +--rw neighbor* inet:ip-address 1639 | | +--rw multihop? uint8 1640 | | +--rw as-override? boolean 1641 | | +--rw allow-own-as? uint8 1642 | | +--rw prepend-global-as? boolean 1643 | | +--rw default-route? boolean 1644 | | +--rw site-of-origin? rt-types:route-origin 1645 | | +--rw ipv6-site-of-origin? rt-types:ipv6-route-origin 1646 | | +--rw redistribute-connected* [address-family] 1647 | | | +--rw address-family identityref 1648 | | | +--rw enable? boolean 1649 | | +--rw bgp-max-prefix 1650 | | | +--rw max-prefix? uint32 1651 | | | +--rw warning-threshold? decimal64 1652 | | | +--rw violate-action? enumeration 1653 | | | +--rw restart-interval? uint16 1654 | | +--rw bgp-timers 1655 | | | +--rw keepalive? uint16 1656 | | | +--rw hold-time? uint16 1657 | | +--rw security 1658 | | | +--rw enable? boolean 1659 | | | +--rw keying-material 1660 | | | +--rw (option)? 1661 | | | +--:(tcp-ao) 1662 | | | | +--rw enable-tcp-ao? boolean 1663 | | | | +--rw ao-keychain? key-chain:key-chain-ref 1664 | | | +--:(md5) 1665 | | | | +--rw md5-keychain? key-chain:key-chain-ref 1666 | | | +--:(explicit) 1667 | | | | +--rw key-id? uint32 1668 | | | | +--rw key? string 1669 | | | | +--rw crypto-algorithm? identityref 1670 | | | +--:(ipsec) 1671 | | | +--rw sa? string 1672 | | +--rw status 1673 | | +--rw admin-status 1674 | | | +--rw status? identityref 1675 | | | +--rw last-updated? yang:date-and-time 1676 | | +--ro oper-status 1677 | | +--ro status? identityref 1678 | | +--ro last-updated? yang:date-and-time 1679 ... 1681 Figure 16: BGP Routing Subtree Structure 1683 OSPF: OSPF can be configured to run as a routing protocol on the 1684 'vpn-network-access'. The following data nodes are captured in 1685 Figure 17: 1687 'address-family': Indicates whether IPv4, IPv6, or both address 1688 families are to be activated. 1690 When only the IPv4 address-family is requested, it will be up 1691 to the implementation to decide whether OSPFv2 [RFC4577] or 1692 OSPFv3 [RFC6565] is used. 1694 'area-id': Indicates the OSPF Area ID. 1696 'metric': Associates a metric with OSPF routes. 1698 'sham-links': Is used to create OSPF sham links between two VPN 1699 network accesses sharing the same area and having a backdoor 1700 link (Section 4.2.7 of [RFC4577] and Section 5 of [RFC6565]). 1702 'max-lsa': Sets the maximum number of LSAs that the OSPF instance 1703 will accept. 1705 'security': Controls the authentication schemes to be enabled for 1706 the OSPF instance. The following options are supported: IPsec 1707 for OSPFv3 authentication [RFC4552], authentication trailer for 1708 OSPFv2 [RFC5709] [RFC7474] and OSPFv3 [RFC7166]. 1710 'status': Indicates the status of the OSPF routing instance. 1712 ... 1713 +--rw routing-protocols 1714 | +--rw routing-protocol* [id] 1715 | ... 1716 | +--rw ospf {vpn-common:rtg-ospf}? 1717 | | +--rw address-family? identityref 1718 | | +--rw area-id yang:dotted-quad 1719 | | +--rw metric? uint16 1720 | | +--rw sham-links {vpn-common:rtg-ospf-sham-link}? 1721 | | | +--rw sham-link* [target-site] 1722 | | | +--rw target-site 1723 | | | | vpn-common:vpn-id 1724 | | | +--rw metric? uint16 1725 | | +--rw max-lsa? uint32 1726 | | +--rw security 1727 | | | +--rw enable? boolean 1728 | | | +--rw keying-material 1729 | | | +--rw (option)? 1730 | | | +--:(md5) 1731 | | | | +--rw md5-keychain? 1732 | | | | kc:key-chain-ref 1733 | | | +--:(ipsec) 1734 | | | +--rw sa? string 1735 | | +--rw status 1736 | | +--rw admin-status 1737 | | | +--rw status? identityref 1738 | | | +--rw last-updated? yang:date-and-time 1739 | | +--ro oper-status 1740 | | +--ro status? identityref 1741 | | +--ro last-updated? yang:date-and-time 1742 ... 1744 Figure 17: OPSF Routing Subtree Structure 1746 IS-IS: The model (Figure 18) allows the user to configure IS-IS 1747 [ISO10589][RFC1195][RFC5308] to run on the 'vpn-network-access' 1748 interface. The following IS-IS data nodes are supported: 1750 'address-family': Indicates whether IPv4, IPv6, or both address 1751 families are to be activated. 1753 'area-address': Indicates the IS-IS area address. 1755 'level': Indicates the IS-IS level: Level 1, Level 2, or both. 1757 'metric': Associates a metric with IS-IS routes. 1759 'mode': Indicates the IS-IS interface mode type. It can be set 1760 to 'active' (that is, send or receive IS-IS protocol control 1761 packets) or 'passive' (that is, suppress the sending of IS-IS 1762 updates through the interface). 1764 'security': Controls the authentication schemes to be enabled for 1765 the IS-IS instance. Both the specification of a key-chain 1766 [RFC8177] and the direct specification of key and 1767 authentication algorithm are supported. 1769 'status': Indicates the status of the OSPF routing instance. 1771 ... 1772 +--rw routing-protocols 1773 | +--rw routing-protocol* [id] 1774 | ... 1775 | +--rw isis {vpn-common:rtg-isis}? 1776 | | +--rw address-family? identityref 1777 | | +--rw area-address area-address 1778 | | +--rw level? identityref 1779 | | +--rw metric? uint16 1780 | | +--rw mode? enumeration 1781 | | +--rw security 1782 | | | +--rw enable? boolean 1783 | | | +--rw keying-material 1784 | | | +--rw (option)? 1785 | | | +--:(auth-key-chain) 1786 | | | | +--rw key-chain? 1787 | | | | key-chain:key-chain-ref 1788 | | | +--:(auth-key-explicit) 1789 | | | +--rw key-id? uint32 1790 | | | +--rw key? string 1791 | | | +--rw crypto-algorithm? identityref 1792 | | +--rw status 1793 | | +--rw admin-status 1794 | | | +--rw status? identityref 1795 | | | +--rw last-updated? yang:date-and-time 1796 | | +--ro oper-status 1797 | | +--ro status? identityref 1798 | | +--ro last-updated? yang:date-and-time 1799 ... 1801 Figure 18: IS-IS Routing Subtree Structure 1803 RIP: The model allows the user to configure RIP to run on the 'vpn- 1804 network-access' interface. As shown in Figure 19, the following 1805 RIP data nodes are supported: 1807 'address-family': Indicates whether IPv4, IPv6, or both address 1808 families are to be activated. This parameter is used to 1809 determine whether RIPv2 [RFC2453] and/or RIPng are to be 1810 enabled [RFC2080]. 1812 'timers': Indicates the following timers: 1814 'update-interval': Is the interval at which RIP updates are 1815 sent. 1817 'invalid-interval': Is the interval before a RIP route is 1818 declared invalid. 1820 'holddown-interval': Is the interval before better RIP routes 1821 are released. 1823 'flush-interval': Is the interval before a route is removed 1824 from the routing table. 1826 'default-metric': Sets the default RIP metric. 1828 'security': Controls the authentication schemes to be enabled for 1829 the RIP instance. 1831 'status': Indicates the status of the RIP routing instance. 1833 ... 1834 +--rw routing-protocols 1835 | +--rw routing-protocol* [id] 1836 | ... 1837 | +--rw rip {vpn-common:rtg-rip}? 1838 | | +--rw address-family? identityref 1839 | | +--rw timers 1840 | | | +--rw update-interval? uint16 1841 | | | +--rw invalid-interval? uint16 1842 | | | +--rw holddown-interval? uint16 1843 | | | +--rw flush-interval? uint16 1844 | | +--rw neighbor* inet:ip-address 1845 | | +--rw default-metric? uint8 1846 | | +--rw security 1847 | | | +--rw enable? boolean 1848 | | | +--rw keying-material 1849 | | | +--rw (option)? 1850 | | | +--:(auth-key-chain) 1851 | | | | +--rw key-chain? 1852 | | | | key-chain:key-chain-ref 1853 | | | +--:(auth-key-explicit) 1854 | | | +--rw key? string 1855 | | | +--rw crypto-algorithm? identityref 1856 | | +--rw status 1857 | | +--rw admin-status 1858 | | | +--rw status? identityref 1859 | | | +--rw last-updated? yang:date-and-time 1860 | | +--ro oper-status 1861 | | +--ro status? identityref 1862 | | +--ro last-updated? yang:date-and-time 1863 ... 1865 Figure 19: RIP Subtree Structure 1867 VRRP: The model (Figure 20) allows to enable VRRP on the 'vpn- 1868 network-access' interface. The following data nodes are 1869 supported: 1871 'address-family': Indicates whether IPv4, IPv6, or both address 1872 families are to be activated. Note that VRRP version 3 1873 [RFC5798] supports both IPv4 and IPv6. 1875 'vrrp-group': Is used to identify the VRRP group. 1877 'backup-peer': Carries the IP address of the peer. 1879 'virtual-ip-address': Includes virtual IP addresses for a single 1880 VRRP group. 1882 'priority': Assigns the VRRP election priority for the backup 1883 virtual router. 1885 'ping-reply': Controls whether ping requests can be replied to. 1887 'status': Indicates the status of the VRRP instance. 1889 Note that no security data node is included for VRRP as there 1890 isn't currently any type of VRRP authentication (see Section 9 of 1891 [RFC5798]). 1893 ... 1894 +--rw routing-protocols 1895 | +--rw routing-protocol* [id] 1896 | ... 1897 | +--rw vrrp {vpn-common:rtg-vrrp}? 1898 | +--rw address-family* identityref 1899 | +--rw vrrp-group? uint8 1900 | +--rw backup-peer? inet:ip-address 1901 | +--rw virtual-ip-address* inet:ip-address 1902 | +--rw priority? uint8 1903 | +--rw ping-reply? boolean 1904 | +--rw status 1905 | +--rw admin-status 1906 | | +--rw status? identityref 1907 | | +--rw last-updated? yang:date-and-time 1908 | +--ro oper-status 1909 | +--ro status? identityref 1910 | +--ro last-updated? yang:date-and-time 1911 ... 1913 Figure 20: VRRP Subtree Structure 1915 7.6.4. OAM 1917 This container (Figure 21) defines the Operations, Administration, 1918 and Maintenance (OAM) mechanisms used for a VPN network access. In 1919 the current version of the L3NM, only BFD is supported. The current 1920 data nodes can be specified: 1922 'desired-min-tx-interval': Is the minimum interval, in microseconds, 1923 that a PE would like to use when transmitting BFD Control packets 1924 less any jitter applied. 1926 'required-min-rx-interval': Is the minimum interval, in 1927 microseconds, between received BFD Control packets that a PE is 1928 capable of supporting, less any jitter applied by the sender. 1930 'detection-multiplier': The negotiated transmit interval, multiplied 1931 by this value, provides the detection time for the PE. 1933 'holdtime': Is used to indicate the expected BFD holddown time. The 1934 value can be set by the customer or selected from a profile. 1936 'security': Includes the required information to enable the BFD 1937 authentication modes discussed in Section 6.7 of [RFC5880]. In 1938 particular 'meticulous' controls the activation of the meticulous 1939 mode discussed in Sections 6.7.3 and 6.7.4 of [RFC5880]. 1941 'status': Indicates the status of BFD. 1943 ... 1944 +--rw oam 1945 | +--rw bfd {vpn-common:bfd}? 1946 | +--rw desired-min-tx-interval? uint32 1947 | +--rw required-min-rx-interval? uint32 1948 | +--rw detection-multiplier? uint8 1949 | +--rw (holdtime)? 1950 | | +--:(fixed) 1951 | | | +--rw fixed-value? uint32 1952 | | +--:(profile) 1953 | | | +--rw profile-name? leafref 1954 | +--rw authentication! 1955 | | +--rw key-chain? key-chain:key-chain-ref 1956 | | +--rw meticulous? boolean 1957 | +--rw status 1958 | +--rw admin-status 1959 | | +--rw status? identityref 1960 | | +--rw last-updated? yang:date-and-time 1961 | +--ro oper-status 1962 | +--ro status? identityref 1963 | +--ro last-updated? yang:date-and-time 1964 ... 1966 Figure 21: IP Connection Subtree Structure (OAM) 1968 7.6.5. Security 1970 The 'security' container specifies the authentication and the 1971 encryption to be applied for a given VPN network access traffic. As 1972 depicted in the subtree shown in Figure 22, the L3NM can be used to 1973 directly control the encryption to put in place (e.g., Layer 2 or 1974 Layer 3 encryption) or invoke a local encryption profile. 1976 ... 1977 +--rw vpn-services 1978 +--rw vpn-service* [vpn-id] 1979 ... 1980 +--rw vpn-nodes 1981 +--rw vpn-node* [vpn-node-id] 1982 ... 1983 +--rw vpn-network-accesses 1984 +--rw vpn-network-access* [id] 1985 ... 1986 +--rw security 1987 | +--rw encryption {vpn-common:encryption}? 1988 | | +--rw enabled? boolean 1989 | | +--rw layer? enumeration 1990 | +--rw encryption-profile 1991 | +--rw (profile)? 1992 | +--:(provider-profile) 1993 | | +--rw profile-name? leafref 1994 | +--:(customer-profile) 1995 | +--rw customer-key-chain? 1996 | kc:key-chain-ref 1997 +--rw service 1998 ... 2000 Figure 22: Security Subtree Structure 2002 7.6.6. Services 2004 The 'service' container specifies the service parameters to apply for 2005 a given VPN network access (Figure 23). 2007 ... 2008 +--rw vpn-network-accesses 2009 +--rw vpn-network-access* [id] 2010 ... 2011 +--rw service 2012 +--rw input-bandwidth? uint64 {vpn-common:input-bw}? 2013 +--rw output-bandwidth? uint64 {vpn-common:output-bw}? 2014 +--rw mtu? uint16 2015 +--rw qos {vpn-common:qos}? 2016 | ... 2017 +--rw carrierscarrier 2018 | {vpn-common:carrierscarrier}? 2019 | +--rw signalling-type? enumeration 2020 +--rw ntp 2021 | +--rw broadcast? enumeration 2022 | +--rw auth-profile 2023 | | +--rw profile-id? string 2024 | +--rw status 2025 | +--rw admin-status 2026 | | +--rw status? identityref 2027 | | +--rw last-updated? yang:date-and-time 2028 | +--ro oper-status 2029 | +--ro status? identityref 2030 | +--ro last-updated? yang:date-and-time 2031 +--rw multicast {vpn-common:multicast}? 2032 ... 2034 Figure 23: Services Subtree Structure 2036 The following data nodes are defined: 2038 'input-bandwidth': Indicates the inbound bandwidth of the connection 2039 (i.e., download bandwidth from the service provider to the site). 2041 'output-bandwidth': Indicates the outbound bandwidth of the 2042 connection (i.e., upload bandwidth from the site to the service 2043 provider). 2045 'mtu': Indicates the MTU at the service level. 2047 'qos': Is used to define a set of QoS policies to apply on a given 2048 connection (Figure 24). A QoS policy may be a classification or 2049 an action policy. For example, a QoS action can be defined to 2050 rate limit inbound/outbound traffic of a given class of service. 2052 ... 2053 +--rw qos {vpn-common:qos}? 2054 | +--rw qos-classification-policy 2055 | | +--rw rule* [id] 2056 | | +--rw id string 2057 | | +--rw (match-type)? 2058 | | | +--:(match-flow) 2059 | | | | +--rw (l3)? 2060 | | | | | +--:(ipv4) 2061 | | | | | | ... 2062 | | | | | +--:(ipv6) 2063 | | | | | ... 2064 | | | | +--rw (l4)? 2065 | | | | +--:(tcp) 2066 | | | | | ... 2067 | | | | +--:(udp) 2068 | | | | ... 2069 | | | +--:(match-application) 2070 | | | +--rw match-application? 2071 | | | identityref 2072 | | +--rw target-class-id? 2073 | | string 2074 | +--rw qos-action 2075 | | +--rw rule* [id] 2076 | | +--rw id string 2077 | | +--rw target-class-id? string 2078 | | +--rw inbound-rate-limit? decimal64 2079 | | +--rw outbound-rate-limit? decimal64 2080 | +--rw qos-profile 2081 | +--rw qos-profile* [profile] 2082 | +--rw profile leafref 2083 | +--rw direction? identityref 2084 ... 2086 Figure 24: Services Subtree Structure 2088 QoS classification can be based on many criteria such as: 2090 Layer 3: As shown in Figure 25, classification can be based on 2091 any IP header field or a combination thereof. Both IPv4 and 2092 IPv6 are supported. 2094 +--rw qos {vpn-common:qos}? 2095 | +--rw qos-classification-policy 2096 | | +--rw rule* [id] 2097 | | +--rw id string 2098 | | +--rw (match-type)? 2099 | | | +--:(match-flow) 2100 | | | | +--rw (l3)? 2101 | | | | | +--:(ipv4) 2102 | | | | | | +--rw ipv4 2103 | | | | | | +--rw dscp? inet:dscp 2104 | | | | | | +--rw ecn? uint8 2105 | | | | | | +--rw length? uint16 2106 | | | | | | +--rw ttl? uint8 2107 | | | | | | +--rw protocol? uint8 2108 | | | | | | +--rw ihl? uint8 2109 | | | | | | +--rw flags? bits 2110 | | | | | | +--rw offset? uint16 2111 | | | | | | +--rw identification? uint16 2112 | | | | | | +--rw (destination-network)? 2113 | | | | | | | +--:(destination-ipv4-network) 2114 | | | | | | | +--rw destination-ipv4-network? 2115 | | | | | | | inet:ipv4-prefix 2116 | | | | | | +--rw (source-network)? 2117 | | | | | | +--:(source-ipv4-network) 2118 | | | | | | +--rw source-ipv4-network? 2119 | | | | | | inet:ipv4-prefix 2120 | | | | | +--:(ipv6) 2121 | | | | | +--rw ipv6 2122 | | | | | +--rw dscp? inet:dscp 2123 | | | | | +--rw ecn? uint8 2124 | | | | | +--rw length? uint16 2125 | | | | | +--rw ttl? uint8 2126 | | | | | +--rw protocol? uint8 2127 | | | | | +--rw (destination-network)? 2128 | | | | | | +--:(destination-ipv6-network) 2129 | | | | | | +--rw destination-ipv6-network? 2130 | | | | | | inet:ipv6-prefix 2131 | | | | | +--rw (source-network)? 2132 | | | | | | +--:(source-ipv6-network) 2133 | | | | | | +--rw source-ipv6-network? 2134 | | | | | | inet:ipv6-prefix 2135 | | | | | +--rw flow-label? 2136 | | | | | inet:ipv6-flow-label 2137 ... 2139 Figure 25: QoS Subtree Structure (L3) 2141 Layer 4: As discussed in [I-D.ietf-opsawg-vpn-common], any layer 2142 4 protocol can be indicated in the 'protocol' data node under 2143 'l3' (Figure 25), but only TCP and UDP specific match criteria 2144 are elaborated in this version as these protocols are widely 2145 used in the context of VPN services. Augmentations can be 2146 considered in the future to add other Layer 4 specific data 2147 nodes, if needed. 2149 TCP or UDP-related match crietria can be specified in the L3NM 2150 as shown in Figure 26. 2152 +--rw qos {vpn-common:qos}? 2153 | +--rw qos-classification-policy 2154 | | +--rw rule* [id] 2155 | | +--rw id string 2156 | | +--rw (match-type)? 2157 | | | +--:(match-flow) 2158 | | | | +--rw (l3)? 2159 | | | | | ... 2160 | | | | +--rw (l4)? 2161 | | | | +--:(tcp) 2162 | | | | | +--rw tcp 2163 | | | | | +--rw sequence-number? uint32 2164 | | | | | +--rw acknowledgement-number? uint32 2165 | | | | | +--rw data-offset? uint8 2166 | | | | | +--rw reserved? uint8 2167 | | | | | +--rw flags? bits 2168 | | | | | +--rw window-size? uint16 2169 | | | | | +--rw urgent-pointer? uint16 2170 | | | | | +--rw options? binary 2171 | | | | | +--rw (source-port)? 2172 | | | | | | +--:(source-port-range-or-operator) 2173 | | | | | | +--rw source-port-range-or-operator 2174 | | | | | | +--rw (port-range-or-operator)? 2175 | | | | | | +--:(range) 2176 | | | | | | | +--rw lower-port 2177 | | | | | | | | inet:port-number 2178 | | | | | | | +--rw upper-port 2179 | | | | | | | inet:port-number 2180 | | | | | | +--:(operator) 2181 | | | | | | +--rw operator? operator 2182 | | | | | | +--rw port 2183 | | | | | | inet:port-number 2184 | | | | | +--rw (destination-port)? 2185 | | | | +--:(destination-port-range-or-operator) 2186 | | | | | +--rw destination-port-range-or-operator 2187 | | | | | +--rw (port-range-or-operator)? 2188 | | | | | +--:(range) 2189 | | | | | | +--rw lower-port 2190 | | | | | | | inet:port-number 2191 | | | | | | +--rw upper-port 2192 | | | | | | inet:port-number 2193 | | | | | +--:(operator) 2194 | | | | | +--rw operator? operator 2195 | | | | | +--rw port 2196 | | | | | inet:port-number 2197 | | | | +--:(udp) 2198 | | | | +--rw udp 2199 | | | | +--rw length? uint16 2200 | | | | +--rw (source-port)? 2201 | | | | | +--:(source-port-range-or-operator) 2202 | | | | | +--rw source-port-range-or-operator 2203 | | | | | +--rw (port-range-or-operator)? 2204 | | | | | +--:(range) 2205 | | | | | | +--rw lower-port 2206 | | | | | | | inet:port-number 2207 | | | | | | +--rw upper-port 2208 | | | | | | inet:port-number 2209 | | | | | +--:(operator) 2210 | | | | | +--rw operator? operator 2211 | | | | | +--rw port 2212 | | | | | inet:port-number 2213 | | | | +--rw (destination-port)? 2214 | | | | +--:(destination-port-range-or-operator) 2215 | | | | +--rw destination-port-range-or-operator 2216 | | | | +--rw (port-range-or-operator)? 2217 | | | | +--:(range) 2218 | | | | | +--rw lower-port 2219 | | | | | | inet:port-number 2220 | | | | | +--rw upper-port 2221 | | | | | inet:port-number 2222 | | | | +--:(operator) 2223 | | | | +--rw operator? operator 2224 | | | | +--rw port 2225 | | | | inet:port-number 2226 ... 2228 Figure 26: QoS Subtree Structure (L4) 2230 Application match: Relies upon application-specific 2231 classification. 2233 'carrierscarrier': Groups a set of parameters that are used when CsC 2234 is enabled such the use of BGP for signalling purposes [RFC8277]. 2236 'ntp': Time synchronization may be needed in some VPNs such as 2237 infrastructure and management VPNs. This container is used to 2238 enable the NTP service [RFC5905]. 2240 'multicast': Specifies the multicast mode and other data nodes such 2241 as the address-family. Refer to Section 7.7. 2243 7.7. Multicast 2245 Multicast may be enabled for a particular VPN at the VPN node and VPN 2246 network access levels (see Figure 27). Some data nodes (e.g., max- 2247 groups) can be controlled at various levels: VPN service, VPN node 2248 level, or VPN network access. 2250 ... 2251 +--rw vpn-services 2252 +--rw vpn-service* [vpn-id] 2253 ... 2254 +--rw vpn-instance-profiles 2255 | +--rw vpn-instance-profile* [profile-id] 2256 | .... 2257 | +--rw multicast {vpn-common:multicast}? 2258 | ... 2259 +--rw vpn-nodes 2260 +--rw vpn-node* [vpn-node-id] 2261 ... 2262 +--rw active-vpn-instance-profiles 2263 | +--rw vpn-instance-profile* [profile-id] 2264 | ... 2265 | +--rw multicast {vpn-common:multicast}? 2266 | ... 2267 +--rw vpn-network-accesses 2268 +--rw vpn-network-access* [id] 2269 ... 2270 +--rw service 2271 ... 2272 +--rw multicast {vpn-common:multicast}? 2273 ... 2275 Figure 27: Overall Multicast Subtree Structure 2277 Multicast-related data nodes at the VPN instance profile level has 2278 the structure that is shown in Figure 30. 2280 ... 2281 +--rw vpn-services 2282 +--rw vpn-service* [vpn-id] 2283 ... 2285 +--rw vpn-instance-profiles 2286 | +--rw vpn-instance-profile* [profile-id] 2287 | .... 2288 | +--rw multicast {vpn-common:multicast}? 2289 | +--rw tree-flavor* identityref 2290 | +--rw rp 2291 | | +--rw rp-group-mappings 2292 | | | +--rw rp-group-mapping* [id] 2293 | | | +--rw id uint16 2294 | | | +--rw provider-managed 2295 | | | | +--rw enabled? boolean 2296 | | | | +--rw rp-redundancy? boolean 2297 | | | | +--rw optimal-traffic-delivery? boolean 2298 | | | | +--rw anycast 2299 | | | | +--rw local-address? inet:ip-address 2300 | | | | +--rw rp-set-address* inet:ip-address 2301 | | | +--rw rp-address inet:ip-address 2302 | | | +--rw groups 2303 | | | +--rw group* [id] 2304 | | | +--rw id uint16 2305 | | | +--rw (group-format) 2306 | | | +--:(group-prefix) 2307 | | | | +--rw group-address? inet:ip-prefix 2308 | | | +--:(startend) 2309 | | | +--rw group-start? inet:ip-address 2310 | | | +--rw group-end? inet:ip-address 2311 | | +--rw rp-discovery 2312 | | +--rw rp-discovery-type? identityref 2313 | | +--rw bsr-candidates 2314 | | +--rw bsr-candidate-address* inet:ip-address 2315 | +--rw igmp {vpn-common:igmp and vpn-common:ipv4}? 2316 | | +--rw static-group* [group-addr] 2317 | | | +--rw group-addr 2318 | | | | rt-types:ipv4-multicast-group-address 2319 | | | +--rw source-addr? 2320 | | | rt-types:ipv4-multicast-source-address 2321 | | +--rw max-groups? uint32 2322 | | +--rw max-entries? uint32 2323 | | +--rw version? identityref 2324 | +--rw mld {vpn-common:mld and vpn-common:ipv6}? 2325 | | +--rw static-group* [group-addr] 2326 | | | +--rw group-addr 2327 | | | | rt-types:ipv6-multicast-group-address 2328 | | | +--rw source-addr? 2329 | | | rt-types:ipv6-multicast-source-address 2330 | | +--rw max-groups? uint32 2331 | | +--rw max-entries? uint32 2332 | | +--rw version? identityref 2333 | +--rw pim {vpn-common:pim}? 2334 | +--rw hello-interval? rt-types:timer-value-seconds16 2335 | +--rw dr-priority? uint32 2336 ... 2338 Figure 28: Multicast Subtree Structure (VPN Instance Profile Level) 2340 The model supports a single type of tree: Any-Source Multicast (ASM), 2341 Source-Specific Multicast (SSM), or bidirectional. 2343 When ASM is used, the model supports the configuration of rendez-vous 2344 points (RPs). RP discovery may be 'static', 'bsr-rp', or 'auto-rp'. 2345 When set to 'static', RP to multicast grouping mapping MUST be 2346 configured as part of the 'rp-group-mappings' container. The RP MAY 2347 be a provider node or a customer node. When the RP is a customer 2348 node, the RP address must be configured using the 'rp-address' leaf 2349 otherwise no RP address is needed. 2351 The model supports RP redundancy through the 'rp-redundancy' leaf. 2352 How the redundancy is achieved is out of scope and is up to the 2353 implementation. 2355 When a particular VPN using ASM requires a more optimal traffic 2356 delivery, 'optimal-traffic-delivery' can be set. When set to 'true', 2357 the implementation must use any mechanism to provide a more optimal 2358 traffic delivery for the customer. For example, anycast is one of 2359 the mechanisms to enhance RPs redundancy, resilience against 2360 failures, and to recover from failures quickly. 2362 The same structure as the one depicted in Figure 30 is used when 2363 configuring multicast-related parameters at the VPN node level. When 2364 defined at the VPN node level (Figure 29), Internet Group Management 2365 Protocol (IGMP) [RFC1112][RFC2236][RFC3376], Multicast Listener 2366 Discovery (MLD) [RFC2710][RFC3810], and Protocol Independent 2367 Multicast (PIM) [RFC7761] parameters are applicable to all VPN 2368 network accesses of that VPN node unless corresponding nodes are 2369 refined at the VPN network access level. 2371 ... 2372 +--rw vpn-nodes 2373 +--rw vpn-node* [vpn-node-id] 2374 ... 2375 +--rw active-vpn-instance-profiles 2376 | +--rw vpn-instance-profile* [profile-id] 2377 | ... 2378 | +--rw multicast {vpn-common:multicast}? 2379 | +--rw tree-flavor* identityref 2380 | +--rw rp 2381 | | ... 2382 | +--rw igmp {vpn-common:igmp and vpn-common:ipv4}? 2383 | | ... 2384 | +--rw mld {vpn-common:mld and vpn-common:ipv6}? 2385 | | ... 2386 | +--rw pim {vpn-common:pim}? 2387 | ... 2389 Figure 29: Multicast Subtree Structure (VPN Node Level) 2391 Multicast-related data nodes at the VPN network access level are 2392 shown in Figure 30. The values configured at the VPN network access 2393 level override the values configured for the corresponding data nodes 2394 in other levels. 2396 ... 2397 +--rw vpn-network-accesses 2398 +--rw vpn-network-access* [id] 2399 ... 2400 +--rw service 2401 ... 2402 +--rw multicast {vpn-common:multicast}? 2403 +--rw access-type? enumeration 2404 +--rw address-family? identityref 2405 +--rw protocol-type? enumeration 2406 +--rw remote-source? boolean 2407 +--rw igmp {vpn-common:igmp}? 2408 | +--rw static-group* [group-addr] 2409 | | +--rw group-addr 2410 | | rt-types:ipv4-multicast-group-address 2411 | | +--rw source-addr? 2412 | | rt-types:ipv4-multicast-source-address 2413 | +--rw max-groups? uint32 2414 | +--rw max-entries? uint32 2415 | +--rw max-group-sources? uint32 2416 | +--rw version? identityref 2417 | +--rw status 2418 | +--rw admin-status 2419 | | +--rw status? identityref 2420 | | +--rw last-updated? yang:date-and-time 2421 | +--ro oper-status 2422 | +--ro status? identityref 2423 | +--ro last-updated? yang:date-and-time 2424 +--rw mld {vpn-common:mld}? 2425 | +--rw static-group* [group-addr] 2426 | | +--rw group-addr 2427 | | rt-types:ipv6-multicast-group-address 2428 | | +--rw source-addr? 2429 | | rt-types:ipv6-multicast-source-address 2430 | +--rw max-groups? uint32 2431 | +--rw max-entries? uint32 2432 | +--rw max-group-sources? uint32 2433 | +--rw version? identityref 2434 | +--rw status 2435 | +--rw admin-status 2436 | | +--rw status? identityref 2437 | | +--rw last-updated? yang:date-and-time 2438 | +--ro oper-status 2439 | +--ro status? identityref 2440 | +--ro last-updated? yang:date-and-time 2441 +--rw pim {vpn-common:pim}? 2442 +--rw hello-interval? rt-types:timer-value-seconds16 2443 +--rw dr-priority? uint32 2444 +--rw status 2445 +--rw admin-status 2446 | +--rw status? identityref 2447 | +--rw last-updated? yang:date-and-time 2448 +--ro oper-status 2449 +--ro status? identityref 2450 +--ro last-updated? yang:date-and-time 2452 Figure 30: Multicast Subtree Structure (VPN Network Access Level) 2454 8. L3NM YANG Module 2456 This module uses types defined in [RFC6991] and [RFC8343]. It also 2457 uses groupings defined in [RFC8519], [RFC8177], and [RFC8294]. 2459 file "ietf-l3vpn-ntw@2021-05-18.yang" 2460 module ietf-l3vpn-ntw { 2461 yang-version 1.1; 2462 namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw"; 2463 prefix l3nm; 2465 import ietf-vpn-common { 2466 prefix vpn-common; 2467 reference 2468 "RFC UUUU: A Layer 2/3 VPN Common YANG Model"; 2469 } 2470 import ietf-inet-types { 2471 prefix inet; 2472 reference 2473 "RFC 6991: Common YANG Data Types, Section 4"; 2474 } 2475 import ietf-yang-types { 2476 prefix yang; 2477 reference 2478 "RFC 6991: Common YANG Data Types, Section 3"; 2479 } 2480 import ietf-key-chain { 2481 prefix key-chain; 2482 reference 2483 "RFC 8177: YANG Key Chain."; 2484 } 2485 import ietf-routing-types { 2486 prefix rt-types; 2487 reference 2488 "RFC 8294: Common YANG Data Types for the Routing Area"; 2489 } 2490 import ietf-interfaces { 2491 prefix if; 2492 reference 2493 "RFC 8343: A YANG Data Model for Interface Management"; 2494 } 2496 organization 2497 "IETF OPSA (Operations and Management Area) Working Group "; 2498 contact 2499 "WG Web: 2500 WG List: 2502 Author: Samier Barguil 2503 2504 Editor: Oscar Gonzalez de Dios 2505 2506 Editor: Mohamed Boucadair 2507 2508 Author: Luis Angel Munoz 2509 2510 Author: Alejandro Aguado 2511 "; 2512 description 2513 "This YANG module defines a generic network-oriented model 2514 for the configuration of Layer 3 Virtual Private Networks. 2516 Copyright (c) 2021 IETF Trust and the persons identified as 2517 authors of the code. All rights reserved. 2519 Redistribution and use in source and binary forms, with or 2520 without modification, is permitted pursuant to, and subject 2521 to the license terms contained in, the Simplified BSD License 2522 set forth in Section 4.c of the IETF Trust's Legal Provisions 2523 Relating to IETF Documents 2524 (http://trustee.ietf.org/license-info). 2526 This version of this YANG module is part of RFC XXXX; see 2527 the RFC itself for full legal notices."; 2529 revision 2021-05-18 { 2530 description 2531 "Initial revision."; 2532 reference 2533 "RFC XXXX: A Layer 3 VPN Network YANG Model"; 2534 } 2536 /* Features */ 2538 feature msdp { 2539 description 2540 "This feature indicates that Multicast Source Discovery Protocol 2541 (MSDP) capabilities are supported by the VPN."; 2542 reference 2543 "RFC 3618: Multicast Source Discovery Protocol (MSDP)"; 2544 } 2546 /* Identities */ 2548 identity address-allocation-type { 2549 description 2550 "Base identity for address allocation type in the 2551 Provider Edge (PE)-Customer Edge (CE) link."; 2552 } 2554 identity provider-dhcp { 2555 base address-allocation-type; 2556 description 2557 "The Provider's network provides a DHCP service to the customer."; 2558 } 2560 identity provider-dhcp-relay { 2561 base address-allocation-type; 2562 description 2563 "The Provider's network provides a DHCP relay service to the 2564 customer."; 2565 } 2567 identity provider-dhcp-slaac { 2568 if-feature "vpn-common:ipv6"; 2569 base address-allocation-type; 2570 description 2571 "The Provider's network provides a DHCP service to the customer 2572 as well as IPv6 Stateless Address Autoconfiguration (SLAAC)."; 2573 reference 2574 "RFC 4862: IPv6 Stateless Address Autoconfiguration"; 2575 } 2577 identity static-address { 2578 base address-allocation-type; 2579 description 2580 "The Provider-to-customer addressing is static."; 2581 } 2583 identity slaac { 2584 if-feature "vpn-common:ipv6"; 2585 base address-allocation-type; 2586 description 2587 "Use IPv6 SLAAC."; 2588 reference 2589 "RFC 4862: IPv6 Stateless Address Autoconfiguration"; 2590 } 2592 identity bearer-inf-type { 2593 description 2594 "Identity for the bearer interface type."; 2595 } 2597 identity port-id { 2598 base bearer-inf-type; 2599 description 2600 "Identity for the priority-tagged interface."; 2601 } 2603 identity lag-id { 2604 base bearer-inf-type; 2605 description 2606 "Identity for the lag-tagged interface."; 2607 } 2609 identity local-defined-next-hop { 2610 description 2611 "Defines a base identity type of local defined 2612 next-hops."; 2613 } 2615 identity discard { 2616 base local-defined-next-hop; 2617 description 2618 "Indicates an action to discard traffic for the 2619 corresponding destination. 2620 For example, this can be used to blackhole traffic."; 2621 } 2623 identity local-link { 2624 base local-defined-next-hop; 2625 description 2626 "Treat traffic towards addresses within the specified next-hop 2627 prefix as though they are connected to a local link."; 2628 } 2630 identity l2-tunnel-type { 2631 description 2632 "Base identity for layer-2 tunnel selection under the VPN 2633 network access."; 2634 } 2636 identity pseudowire { 2637 base l2-tunnel-type; 2638 description 2639 "Pseudowire tunnel termination in the VPN network access."; 2640 } 2642 identity vpls { 2643 base l2-tunnel-type; 2644 description 2645 "Virtual Private LAN Service (VPLS) tunnel termination in 2646 the VPN network access."; 2647 } 2649 identity vxlan { 2650 base l2-tunnel-type; 2651 description 2652 "Virtual eXtensible Local Area Network (VXLAN) tunnel 2653 termination in the VPN network access."; 2654 } 2656 /* Typedefs */ 2658 typedef predefined-next-hop { 2659 type identityref { 2660 base local-defined-next-hop; 2661 } 2662 description 2663 "Pre-defined next-hop designation for locally generated routes."; 2664 } 2666 typedef area-address { 2667 type string { 2668 pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}'; 2669 } 2670 description 2671 "This type defines the area address format."; 2672 } 2674 /* Groupings */ 2676 grouping vpn-instance-profile { 2677 description 2678 "Grouping for data nodes that may be factorized 2679 among many levels of the model. The grouping can 2680 be used to define generic profiles at the VPN service 2681 level and then called at the VPN node and VPN network 2682 access levels."; 2683 leaf local-autonomous-system { 2684 if-feature "vpn-common:rtg-bgp"; 2685 type inet:as-number; 2686 description 2687 "Provider's Autonomous System (AS) number in case the 2688 customer requests BGP routing."; 2689 } 2690 uses vpn-common:route-distinguisher; 2691 list address-family { 2692 key "address-family"; 2693 description 2694 "Set of per-address family parameters."; 2695 leaf address-family { 2696 type identityref { 2697 base vpn-common:address-family; 2698 } 2699 description 2700 "Indicates the address family (IPv4 or IPv6)."; 2701 } 2702 container vpn-targets { 2703 description 2704 "Set of route targets to match for import and export routes 2705 to/from VRF."; 2706 uses vpn-common:vpn-route-targets; 2707 } 2708 list maximum-routes { 2709 key "protocol"; 2710 description 2711 "Defines maximum routes for the VRF."; 2712 leaf protocol { 2713 type identityref { 2714 base vpn-common:routing-protocol-type; 2715 } 2716 description 2717 "Indicates the routing protocol. 'any' value can 2718 be used to identify a limit that will apply for 2719 each active routing protocol."; 2720 } 2721 leaf maximum-routes { 2722 type uint32; 2723 description 2724 "Indicates the maximum prefixes that the VRF can 2725 accept for this address family and protocol."; 2726 } 2727 } 2728 } 2729 container multicast { 2730 if-feature "vpn-common:multicast"; 2731 description 2732 "Global multicast parameters."; 2733 leaf-list tree-flavor { 2734 type identityref { 2735 base vpn-common:multicast-tree-type; 2736 } 2737 description 2738 "Type of the tree to be used."; 2739 } 2740 container rp { 2741 description 2742 "Rendezvous Point (RP) parameters."; 2743 container rp-group-mappings { 2744 description 2745 "RP-to-group mappings parameters."; 2746 list rp-group-mapping { 2747 key "id"; 2748 description 2749 "List of RP-to-group mappings."; 2750 leaf id { 2751 type uint16; 2752 description 2753 "Unique identifier for the mapping."; 2754 } 2755 container provider-managed { 2756 description 2757 "Parameters for a provider-managed RP."; 2758 leaf enabled { 2759 type boolean; 2760 default "false"; 2761 description 2762 "Set to true if the Rendezvous Point (RP) 2763 must be a provider-managed node. Set to 2764 false if it is a customer-managed node."; 2765 } 2766 leaf rp-redundancy { 2767 type boolean; 2768 default "false"; 2769 description 2770 "If set to true, it indicates that a redundancy 2771 mechanism for the RP is required."; 2772 } 2773 leaf optimal-traffic-delivery { 2774 type boolean; 2775 default "false"; 2776 description 2777 "If set to true, the service provider (SP) must 2778 ensure that the traffic uses an optimal path. 2779 An SP may use Anycast RP or RP-tree-to-SPT 2780 switchover architectures."; 2781 } 2782 container anycast { 2783 when "../rp-redundancy = 'true' and 2784 ../optimal-traffic-delivery = 'true'" { 2785 description 2786 "Only applicable if both RP redundancy and 2787 and delivery through optimal path are 2788 activated."; 2789 } 2790 description 2791 "PIM Anycast-RP parameters."; 2792 leaf local-address { 2793 type inet:ip-address; 2794 description 2795 "IP local address for PIM RP. Usually, it 2796 corresponds to the Router ID or the 2797 primary address."; 2798 } 2799 leaf-list rp-set-address { 2800 type inet:ip-address; 2801 description 2802 "Specifies the IP address of other RP routers 2803 that share the same RP IP address."; 2805 } 2806 } 2807 } 2808 leaf rp-address { 2809 when "../provider-managed/enabled = 'false'" { 2810 description 2811 "Relevant when the RP is not 2812 provider-managed."; 2813 } 2814 type inet:ip-address; 2815 mandatory true; 2816 description 2817 "Defines the address of the RP. 2818 Used if the RP is customer-managed."; 2819 } 2820 container groups { 2821 description 2822 "Multicast groups associated with the RP."; 2823 list group { 2824 key "id"; 2825 description 2826 "List of multicast groups."; 2827 leaf id { 2828 type uint16; 2829 description 2830 "Identifier for the group."; 2831 } 2832 choice group-format { 2833 mandatory true; 2834 description 2835 "Choice for multicast group format."; 2836 case group-prefix { 2837 leaf group-address { 2838 type inet:ip-prefix; 2839 description 2840 "A single multicast group prefix."; 2841 } 2842 } 2843 case startend { 2844 leaf group-start { 2845 type inet:ip-address; 2846 description 2847 "The first multicast group address in 2848 the multicast group address range."; 2849 } 2850 leaf group-end { 2851 type inet:ip-address; 2852 description 2853 "The last multicast group address in 2854 the multicast group address range."; 2855 } 2856 } 2857 } 2858 } 2859 } 2860 } 2861 } 2862 container rp-discovery { 2863 description 2864 "RP discovery parameters."; 2865 leaf rp-discovery-type { 2866 type identityref { 2867 base vpn-common:multicast-rp-discovery-type; 2868 } 2869 default "vpn-common:static-rp"; 2870 description 2871 "Type of RP discovery used."; 2872 } 2873 container bsr-candidates { 2874 when "derived-from-or-self(../rp-discovery-type, " 2875 + "'vpn-common:bsr-rp')" { 2876 description 2877 "Only applicable if discovery type is BSR-RP."; 2878 } 2879 description 2880 "Container for the customer Bootstrap Router (BSR) 2881 candidate's addresses."; 2882 leaf-list bsr-candidate-address { 2883 type inet:ip-address; 2884 description 2885 "Specifies the address of candidate BSR."; 2886 } 2887 } 2888 } 2889 } 2890 container igmp { 2891 if-feature "vpn-common:igmp and vpn-common:ipv4"; 2892 description 2893 "Includes IGMP-related parameters."; 2894 list static-group { 2895 key "group-addr"; 2896 description 2897 "Multicast static source/group associated to the 2898 IGMP session."; 2899 leaf group-addr { 2900 type rt-types:ipv4-multicast-group-address; 2901 description 2902 "Multicast group IPv4 addresss."; 2903 } 2904 leaf source-addr { 2905 type rt-types:ipv4-multicast-source-address; 2906 description 2907 "Multicast source IPv4 addresss."; 2908 } 2909 } 2910 leaf max-groups { 2911 type uint32; 2912 description 2913 "Indicates the maximum groups."; 2914 } 2915 leaf max-entries { 2916 type uint32; 2917 description 2918 "Indicates the maximum IGMP entries."; 2919 } 2920 leaf version { 2921 type identityref { 2922 base vpn-common:igmp-version; 2923 } 2924 default "vpn-common:igmpv2"; 2925 description 2926 "Version of the IGMP."; 2927 reference 2928 "RFC 1112: Host Extensions for IP Multicasting 2929 RFC 2236: Internet Group Management Protocol, Version 2 2930 RFC 3376: Internet Group Management Protocol, Version 3"; 2931 } 2932 } 2933 container mld { 2934 if-feature "vpn-common:mld and vpn-common:ipv6"; 2935 description 2936 "Includes MLD-related parameters."; 2937 list static-group { 2938 key "group-addr"; 2939 description 2940 "Multicast static source/group associated to the 2941 MLD session"; 2942 leaf group-addr { 2943 type rt-types:ipv6-multicast-group-address; 2944 description 2945 "Multicast group IPv6 addresss."; 2946 } 2947 leaf source-addr { 2948 type rt-types:ipv6-multicast-source-address; 2949 description 2950 "Multicast source IPv6 addresss."; 2951 } 2952 } 2953 leaf max-groups { 2954 type uint32; 2955 description 2956 "Indicates the maximum groups."; 2957 } 2958 leaf max-entries { 2959 type uint32; 2960 description 2961 "Indicates the maximum MLD entries."; 2962 } 2963 leaf version { 2964 type identityref { 2965 base vpn-common:mld-version; 2966 } 2967 default "vpn-common:mldv2"; 2968 description 2969 "Version of the MLD protocol."; 2970 reference 2971 "RFC 2710: Multicast Listener Discovery (MLD) for IPv6 2972 RFC 3810: Multicast Listener Discovery Version 2 (MLDv2) 2973 for IPv6"; 2974 } 2975 } 2976 container pim { 2977 if-feature "vpn-common:pim"; 2978 description 2979 "Only applies when protocol type is PIM."; 2980 leaf hello-interval { 2981 type rt-types:timer-value-seconds16; 2982 default "30"; 2983 description 2984 "PIM hello-messages interval. If set to 2985 'infinity' or 'not-set', no periodic 2986 Hello messages are sent."; 2987 reference 2988 "RFC 7761: Protocol Independent Multicast - Sparse 2989 Mode (PIM-SM): Protocol Specification (Revised), 2990 Section 4.11"; 2991 } 2992 leaf dr-priority { 2993 type uint32; 2994 default "1"; 2995 description 2996 "Indicates the preference in the Designated Router (DR) 2997 election process. Numerically larger DR priority allows 2998 a node to be elected as a DR."; 2999 reference 3000 "RFC 7761: Protocol Independent Multicast - Sparse 3001 Mode (PIM-SM): Protocol Specification (Revised), 3002 Section 4.3.2"; 3003 } 3004 } 3005 } 3006 } 3008 /* Main Blocks */ 3009 /* Main l3vpn-ntw */ 3011 container l3vpn-ntw { 3012 description 3013 "Main container for L3VPN services management."; 3014 container vpn-profiles { 3015 description 3016 "Contains a set of valid VPN profiles to reference in the VPN 3017 service."; 3018 uses vpn-common:vpn-profile-cfg; 3019 } 3020 container vpn-services { 3021 description 3022 "Top-level container for the VPN services."; 3023 list vpn-service { 3024 key "vpn-id"; 3025 description 3026 "List of VPN services."; 3027 uses vpn-common:vpn-description; 3028 leaf parent-service-id { 3029 type vpn-common:vpn-id; 3030 description 3031 "Pointer to the parent service, if any. 3032 A parent service can be an L3SM, a slice request, a VPN+ 3033 service, etc."; 3034 } 3035 leaf vpn-type { 3036 type identityref { 3037 base vpn-common:service-type; 3038 } 3039 description 3040 "Indicates the service type."; 3041 } 3042 leaf vpn-service-topology { 3043 type identityref { 3044 base vpn-common:vpn-topology; 3046 } 3047 default "vpn-common:any-to-any"; 3048 description 3049 "VPN service topology."; 3050 } 3051 uses vpn-common:service-status; 3052 container vpn-instance-profiles { 3053 description 3054 "Container for a list of VPN instance profiles."; 3055 list vpn-instance-profile { 3056 key "profile-id"; 3057 description 3058 "List of VPN instance profiles."; 3059 leaf profile-id { 3060 type string; 3061 description 3062 "VPN instance profile identifier."; 3063 } 3064 leaf role { 3065 type identityref { 3066 base vpn-common:role; 3067 } 3068 default "vpn-common:any-to-any-role"; 3069 description 3070 "Role of the VPN node in the VPN."; 3071 } 3072 uses vpn-instance-profile; 3073 } 3074 } 3075 container underlay-transport { 3076 description 3077 "Container for underlay transport."; 3078 uses vpn-common:underlay-transport; 3079 } 3080 container external-connectivity { 3081 if-feature "vpn-common:external-connectivity"; 3082 description 3083 "Container for external connectivity."; 3084 choice profile { 3085 description 3086 "Choice for the external connectivity profile."; 3087 case profile { 3088 leaf profile-name { 3089 type leafref { 3090 path "/l3vpn-ntw/vpn-profiles" 3091 + "/valid-provider-identifiers" 3092 + "/external-connectivity-identifier/id"; 3093 } 3094 description 3095 "Name of the service provider's profile to be applied 3096 at the VPN service level."; 3097 } 3098 } 3099 } 3100 } 3101 container vpn-nodes { 3102 description 3103 "Container for VPN nodes."; 3104 list vpn-node { 3105 key "vpn-node-id"; 3106 description 3107 "Includes a list of VPN nodes."; 3108 leaf vpn-node-id { 3109 type vpn-common:vpn-id; 3110 description 3111 "An identifier of the VPN node."; 3112 } 3113 leaf description { 3114 type string; 3115 description 3116 "Textual description of the VPN node."; 3117 } 3118 leaf ne-id { 3119 type string; 3120 description 3121 "Unique identifier of the network element where the VPN 3122 node is deployed."; 3123 } 3124 leaf local-autonomous-system { 3125 if-feature "vpn-common:rtg-bgp"; 3126 type inet:as-number; 3127 description 3128 "Provider's AS number in case the customer requests BGP 3129 routing."; 3130 } 3131 leaf router-id { 3132 type rt-types:router-id; 3133 description 3134 "A 32-bit number in the dotted-quad format that is used 3135 to uniquely identify a node within an autonomous 3136 system. This identifier is used for both IPv4 and 3137 IPv6."; 3138 } 3139 container active-vpn-instance-profiles { 3140 description 3141 "Container for active VPN instance profiles."; 3143 list vpn-instance-profile { 3144 key "profile-id"; 3145 description 3146 "Includes a list of active VPN instance profiles."; 3147 leaf profile-id { 3148 type leafref { 3149 path "/l3vpn-ntw/vpn-services/vpn-service" 3150 + "/vpn-instance-profiles/vpn-instance-profile" 3151 + "/profile-id"; 3152 } 3153 description 3154 "Node's active VPN instance profile."; 3155 } 3156 list router-id { 3157 key "address-family"; 3158 description 3159 "Router-id per address family."; 3160 leaf address-family { 3161 type identityref { 3162 base vpn-common:address-family; 3163 } 3164 description 3165 "Indicates the address family for which the 3166 Router-ID applies."; 3167 } 3168 leaf router-id { 3169 type inet:ip-address; 3170 description 3171 "The router-id information can be an IPv4 or IPv6 3172 address. This can be used, for example, to 3173 configure an IPv6 address as a router-id 3174 when such capability is supported by underlay 3175 routers. In such case, the configured value 3176 overrides the generic one defined at the VPN 3177 node level."; 3178 } 3179 } 3180 uses vpn-instance-profile; 3181 } 3182 } 3183 container msdp { 3184 if-feature "msdp"; 3185 description 3186 "Includes MSDP-related parameters."; 3187 leaf peer { 3188 type inet:ipv4-address; 3189 description 3190 "Indicates the IPv4 address of the MSDP peer."; 3192 } 3193 leaf local-address { 3194 type inet:ipv4-address; 3195 description 3196 "Indicates the IPv4 address of the local end. 3197 This local address must be configured on 3198 the node."; 3199 } 3200 uses vpn-common:service-status; 3201 } 3202 uses vpn-common:vpn-components-group; 3203 uses vpn-common:service-status; 3204 container vpn-network-accesses { 3205 description 3206 "List of network accesses."; 3207 list vpn-network-access { 3208 key "id"; 3209 description 3210 "List of network accesses."; 3211 leaf id { 3212 type vpn-common:vpn-id; 3213 description 3214 "Identifier for the network access."; 3215 } 3216 leaf port-id { 3217 type vpn-common:vpn-id; 3218 description 3219 "Identifier for the interface."; 3220 } 3221 leaf description { 3222 type string; 3223 description 3224 "Textual description of the network access."; 3225 } 3226 leaf vpn-network-access-type { 3227 type identityref { 3228 base vpn-common:site-network-access-type; 3229 } 3230 default "vpn-common:point-to-point"; 3231 description 3232 "Describes the type of connection, e.g., 3233 point-to-point."; 3234 } 3235 leaf vpn-instance-profile { 3236 type leafref { 3237 path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes" 3238 + "/vpn-node/active-vpn-instance-profiles" 3239 + "/vpn-instance-profile/profile-id"; 3241 } 3242 description 3243 "An identifier of an active VPN instance profile."; 3244 } 3245 uses vpn-common:service-status; 3246 container connection { 3247 description 3248 "Defines layer 2 protocols and parameters that are 3249 required to enable connectivity between the PE 3250 and the CE."; 3251 container encapsulation { 3252 description 3253 "Container for layer 2 encapsulation."; 3254 leaf type { 3255 type identityref { 3256 base vpn-common:encapsulation-type; 3257 } 3258 default "vpn-common:priority-tagged"; 3259 description 3260 "Tagged interface type. By default, the type of 3261 the tagged interface is 'priority-tagged'."; 3262 } 3263 container dot1q { 3264 when "derived-from-or-self(../type, " 3265 + "'vpn-common:dot1q')" { 3266 description 3267 "Only applies when the type of the 3268 tagged interface is 'dot1q'."; 3269 } 3270 if-feature "vpn-common:dot1q"; 3271 description 3272 "Tagged interface."; 3273 leaf tag-type { 3274 type identityref { 3275 base vpn-common:tag-type; 3276 } 3277 default "vpn-common:c-vlan"; 3278 description 3279 "Tag type. By default, the tag type is 3280 'c-vlan'."; 3281 } 3282 leaf cvlan-id { 3283 type uint16; 3284 description 3285 "VLAN identifier."; 3286 } 3287 } 3288 container priority-tagged { 3289 when "derived-from-or-self(../type, " 3290 + "'vpn-common:priority-tagged')" { 3291 description 3292 "Only applies when the type of the 3293 tagged interface is 'priority-tagged'."; 3294 } 3295 description 3296 "Priority tagged."; 3297 leaf tag-type { 3298 type identityref { 3299 base vpn-common:tag-type; 3300 } 3301 default "vpn-common:c-vlan"; 3302 description 3303 "Tag type. By default, the tag type is 3304 'c-vlan'."; 3305 } 3306 } 3307 container qinq { 3308 when "derived-from-or-self(../type, " 3309 + "'vpn-common:qinq')" { 3310 description 3311 "Only applies when the type of the tagged 3312 interface is QinQ."; 3313 } 3314 if-feature "vpn-common:qinq"; 3315 description 3316 "Includes QinQ parameters."; 3317 leaf tag-type { 3318 type identityref { 3319 base vpn-common:tag-type; 3320 } 3321 default "vpn-common:c-s-vlan"; 3322 description 3323 "Tag type. By default, the tag type is 3324 'c-s-vlan'."; 3325 } 3326 leaf svlan-id { 3327 type uint16; 3328 mandatory true; 3329 description 3330 "SVLAN identifier."; 3331 } 3332 leaf cvlan-id { 3333 type uint16; 3334 mandatory true; 3335 description 3336 "CVLAN identifier."; 3338 } 3339 } 3340 } 3341 choice l2-service { 3342 description 3343 "The layer 2 connectivity service can be 3344 provided by indicating a pointer to an L2VPN or 3345 by specifying a layer 2 tunnel service."; 3346 container l2-tunnel-service { 3347 description 3348 "Defines a layer 2 tunnel termination. 3349 It is only applicable when a tunnel is 3350 required. The supported values are: 3351 pseudowire, VPLS and, VXLAN. Other 3352 values may defined, if needed."; 3353 leaf type { 3354 type identityref { 3355 base l2-tunnel-type; 3356 } 3357 description 3358 "Selects the tunnel termiantion option for 3359 each vpn-network-access."; 3360 } 3361 container pseudowire { 3362 description 3363 "Includes pseudowire termination parameters."; 3364 leaf vcid { 3365 type uint32; 3366 description 3367 "Indicates a PW or VC identifier."; 3368 } 3369 leaf far-end { 3370 type union { 3371 type uint32; 3372 type inet:ip-address; 3373 } 3374 description 3375 "Neighbor reference."; 3376 } 3377 } 3378 container vpls { 3379 description 3380 "VPLS termination parameters."; 3381 leaf vcid { 3382 type uint32; 3383 description 3384 "VCID identifier."; 3385 } 3386 leaf-list far-end { 3387 type union { 3388 type uint32; 3389 type inet:ip-address; 3390 } 3391 description 3392 "Neighbor reference."; 3393 } 3394 } 3395 container vxlan { 3396 if-feature "vpn-common:vxlan"; 3397 description 3398 "VXLAN termination parameters."; 3399 leaf vni-id { 3400 type uint32; 3401 mandatory true; 3402 description 3403 "VXLAN Network Identifier (VNI)."; 3404 } 3405 leaf peer-mode { 3406 type identityref { 3407 base vpn-common:vxlan-peer-mode; 3408 } 3409 default "vpn-common:static-mode"; 3410 description 3411 "Specifies the VXLAN access mode. By default, 3412 the peer mode is set to 'static-mode'."; 3413 } 3414 leaf-list peer-ip-address { 3415 type inet:ip-address; 3416 description 3417 "List of peer's IP addresses."; 3418 } 3419 } 3420 } 3421 case l2vpn { 3422 leaf l2vpn-id { 3423 type vpn-common:vpn-id; 3424 description 3425 "Indicates the L2VPN service associated with an 3426 Integrated Routing and Bridging (IRB) 3427 interface."; 3428 } 3429 } 3430 } 3431 leaf l2-termination-point { 3432 type vpn-common:vpn-id; 3433 description 3434 "Specifies a reference to a local layer 2 3435 termination point such as a layer 2 sub-interface."; 3436 } 3437 leaf local-bridge-reference { 3438 type vpn-common:vpn-id; 3439 description 3440 "Specifies a local bridge reference to 3441 accommodate, for example, implementations 3442 that require internal bridging. 3443 A reference may be a local bridge domain."; 3444 } 3445 leaf bearer-reference { 3446 if-feature "vpn-common:bearer-reference"; 3447 type string; 3448 description 3449 "This is an internal reference for the service 3450 provider to identify the bearer associated 3451 with this VPN."; 3452 } 3453 } 3454 container ip-connection { 3455 description 3456 "Defines IP connection parameters."; 3457 leaf l3-termination-point { 3458 type vpn-common:vpn-id; 3459 description 3460 "Specifies a reference to a local layer 3 3461 termination point such as a bridge domain 3462 interface."; 3463 } 3464 container ipv4 { 3465 if-feature "vpn-common:ipv4"; 3466 description 3467 "IPv4-specific parameters."; 3468 leaf local-address { 3469 type inet:ipv4-address; 3470 description 3471 "This address is used at the provider side."; 3472 } 3473 leaf prefix-length { 3474 type uint8 { 3475 range "0..32"; 3476 } 3477 description 3478 "Subnet prefix length expressed in bits. 3479 It is applied to both local and customer 3480 addresses."; 3481 } 3482 leaf address-allocation-type { 3483 type identityref { 3484 base address-allocation-type; 3485 } 3486 must "not(derived-from-or-self(current(), " 3487 + "'slaac') or derived-from-or-self(current()," 3488 + " 'provider-dhcp-slaac'))" { 3489 error-message 3490 "SLAAC is only applicable to IPv6."; 3491 } 3492 description 3493 "Defines how addresses are allocated to the 3494 peer site. 3496 If there is no value for the address 3497 allocation type, then IPv4 addressing is not 3498 enabled."; 3499 } 3500 choice allocation-type { 3501 description 3502 "Choice of the IPv4 address allocation."; 3503 case provider-dhcp { 3504 when "derived-from-or-self(./address-" 3505 + "allocation-type, 'provider-dhcp')" { 3506 description 3507 "Only applies when addresses are allocated 3508 by DHCP that is operated by the provider."; 3509 } 3510 description 3511 "DHCP allocated addresses related 3512 parameters."; 3513 leaf dhcp-service-type { 3514 type enumeration { 3515 enum server { 3516 description 3517 "Local DHCP server."; 3518 } 3519 enum relay { 3520 description 3521 "Local DHCP relay. DHCP requests are 3522 relayed to a provider's server."; 3523 } 3524 } 3525 description 3526 "Indicates the type of the DHCP service to 3527 be enabled on this access."; 3528 } 3529 choice service-type { 3530 description 3531 "Choice based on the DHCP service type."; 3532 case relay { 3533 when "./dhcp-service-type = 'relay'"; 3534 description 3535 "Container for list of provider's DHCP 3536 servers."; 3537 leaf-list server-ip-address { 3538 type inet:ipv4-address; 3539 description 3540 "IPv4 addresses of the provider's DHCP 3541 server to use by the local DHCP 3542 relay."; 3543 } 3544 } 3545 case server { 3546 when "./dhcp-service-type = 'server'"; 3547 description 3548 "A choice about how addresses are assigned 3549 when a local DHCP server is enabled."; 3550 choice address-assign { 3551 default "number"; 3552 description 3553 "Choice for how IPv4 addresses are 3554 assigned."; 3555 case number { 3556 leaf number-of-dynamic-address { 3557 type uint16; 3558 default "1"; 3559 description 3560 "Specifies the number of IP 3561 addresses to be assigned to the 3562 customer on this access."; 3563 } 3564 } 3565 case explicit { 3566 container customer-addresses { 3567 description 3568 "Container for customer 3569 addresses to be allocated 3570 using DHCP."; 3571 list address-pool { 3572 key "pool-id"; 3573 description 3574 "Describes IP addresses to be 3575 allocated by DHCP. 3577 When only start-address or only 3578 end-address is present, it 3579 represents a single address. 3581 When both start-address and 3582 end-address are specified, it 3583 implies a range inclusive of both 3584 addresses."; 3585 leaf pool-id { 3586 type string; 3587 description 3588 "A pool identifier for the 3589 address range from start- 3590 address to end-address."; 3591 } 3592 leaf start-address { 3593 type inet:ipv4-address; 3594 description 3595 "Indicates the first address 3596 in the pool."; 3597 } 3598 leaf end-address { 3599 type inet:ipv4-address; 3600 description 3601 "Indicates the last address 3602 in the pool."; 3603 } 3604 } 3605 } 3606 } 3607 } 3608 } 3609 } 3610 } 3611 case dhcp-relay { 3612 when "derived-from-or-self(./address-allocation" 3613 + "-type, 'provider-dhcp-relay')" { 3614 description 3615 "Only applies when the provider is required 3616 to implement a DHCP relay function that 3617 will relay DHCP requests to a customer's 3618 DHCP server."; 3619 } 3620 description 3621 "DHCP relay is provided by the operator."; 3622 container customer-dhcp-servers { 3623 description 3624 "Container for a list of customer's DHCP 3625 servers."; 3627 leaf-list server-ip-address { 3628 type inet:ipv4-address; 3629 description 3630 "IPv4 addresses of the customer's DHCP 3631 server."; 3632 } 3633 } 3634 } 3635 case static-addresses { 3636 when "derived-from-or-self(./address-allocation" 3637 + "-type, 'static-address')" { 3638 description 3639 "Only applies when address allocation 3640 type is static."; 3641 } 3642 description 3643 "Lists the IPv4 addresses that are used."; 3644 leaf primary-address { 3645 type leafref { 3646 path "../address/address-id"; 3647 } 3648 description 3649 "Primary address of the connection."; 3650 } 3651 list address { 3652 key "address-id"; 3653 description 3654 "Lists the IPv4 addresses that are used."; 3655 leaf address-id { 3656 type string; 3657 description 3658 "An identifier of the static IPv4 3659 address."; 3660 } 3661 leaf customer-address { 3662 type inet:ipv4-address; 3663 description 3664 "IPv4 address at the customer side."; 3665 } 3666 } 3667 } 3668 } 3669 } 3670 container ipv6 { 3671 if-feature "vpn-common:ipv6"; 3672 description 3673 "IPv6-specific parameters."; 3674 leaf local-address { 3675 type inet:ipv6-address; 3676 description 3677 "IPv6 address of the provider side."; 3678 } 3679 leaf prefix-length { 3680 type uint8 { 3681 range "0..128"; 3682 } 3683 description 3684 "Subnet prefix length expressed in bits. 3685 It is applied to both local and customer 3686 addresses."; 3687 } 3688 leaf address-allocation-type { 3689 type identityref { 3690 base address-allocation-type; 3691 } 3692 description 3693 "Defines how addresses are allocated. 3694 If there is no value for the address 3695 allocation type, then IPv6 addressing is 3696 disabled."; 3697 } 3698 choice allocation-type { 3699 description 3700 "A choice based on the IPv6 allocation type."; 3701 container provider-dhcp { 3702 when "derived-from-or-self(../address-allo" 3703 + "cation-type, 'provider-dhcp') " 3704 + "or derived-from-or-self(../address-allo" 3705 + "cation-type, 'provider-dhcp-slaac')" { 3706 description 3707 "Only applies when addresses are 3708 allocated by DHCPv6 provided by the 3709 operator."; 3710 } 3711 description 3712 "DHCPv6 allocated addresses related 3713 parameters."; 3714 leaf dhcp-service-type { 3715 type enumeration { 3716 enum server { 3717 description 3718 "Local DHCPv6 server."; 3719 } 3720 enum relay { 3721 description 3722 "DHCPv6 relay."; 3724 } 3725 } 3726 description 3727 "Indicates the type of the DHCPv6 service to 3728 be enabled on this access."; 3729 } 3730 choice service-type { 3731 description 3732 "Choice based on the DHCPv6 service type."; 3733 case provider-dhcp-servers { 3734 when "./dhcp-service-type = 'relay'"; 3735 description 3736 "Case where a local DHCPv6 relay is 3737 enabled. This list is used if and only 3738 if a DHCP relay is enabled."; 3739 leaf-list server-ip-address { 3740 type inet:ipv6-address; 3741 description 3742 "IPv6 addresses of the provider's 3743 DHCPv6 server."; 3744 } 3745 } 3746 case server { 3747 when "./dhcp-service-type = 'server'"; 3748 description 3749 "Case where a local DHCPv6 server is 3750 enabled."; 3751 choice address-assign { 3752 default "number"; 3753 description 3754 "Choice about how IPv6 prefixes are 3755 assigned by the DHCPv6 server."; 3756 case number { 3757 leaf number-of-dynamic-address { 3758 type uint16; 3759 default "1"; 3760 description 3761 "Describes the number of IPv6 3762 prefixes that are allocated to 3763 the customer on this access."; 3764 } 3765 } 3766 case explicit { 3767 container customer-addresses { 3768 description 3769 "Container for customer IPv6 3770 addresses allocated by DHCPv6."; 3771 list address-pool { 3772 key "pool-id"; 3773 description 3774 "Describes IPv6 addresses 3775 allocated by DHCPv6. 3777 When only start-address or only 3778 end-address is present, it 3779 represents a single address. 3781 When both start-address and 3782 end-address are specified, it 3783 implies a range inclusive of 3784 both addresses."; 3785 leaf pool-id { 3786 type string; 3787 description 3788 "Pool identifier for the address 3789 range from identified by start- 3790 address and end-address."; 3791 } 3792 leaf start-address { 3793 type inet:ipv6-address; 3794 description 3795 "Indicates the first address."; 3796 } 3797 leaf end-address { 3798 type inet:ipv6-address; 3799 description 3800 "Indicates the last address."; 3801 } 3802 } 3803 } 3804 } 3805 } 3806 } 3807 } 3808 } 3809 case dhcp-relay { 3810 when "derived-from-or-self(./address-allo" 3811 + "cation-type, 'provider-dhcp-relay')" { 3812 description 3813 "Only applies when the provider is required 3814 to implement DHCP relay function that will 3815 relay DHCPv6 requests to a customer's DHCP 3816 server."; 3817 } 3818 description 3819 "DHCPv6 relay provided by the operator."; 3821 container customer-dhcp-servers { 3822 description 3823 "Container for a list of customer DHCP 3824 servers."; 3825 leaf-list server-ip-address { 3826 type inet:ipv6-address; 3827 description 3828 "Contains the IP addresses of the customer 3829 DHCPv6 server."; 3830 } 3831 } 3832 } 3833 case static-addresses { 3834 when "derived-from-or-self(./address-allocation" 3835 + "-type, 'static-address')" { 3836 description 3837 "Only applies when protocol allocation type 3838 is static."; 3839 } 3840 description 3841 "IPv6-specific parameters for static 3842 allocation."; 3843 leaf primary-address { 3844 type leafref { 3845 path "../address/address-id"; 3846 } 3847 description 3848 "Principal address of the connection"; 3849 } 3850 list address { 3851 key "address-id"; 3852 description 3853 "Describes IPv6 addresses that are used."; 3854 leaf address-id { 3855 type string; 3856 description 3857 "An identifier of an IPv6 address."; 3858 } 3859 leaf customer-address { 3860 type inet:ipv6-address; 3861 description 3862 "An IPv6 address of the customer side."; 3863 } 3864 } 3865 } 3866 } 3867 } 3868 } 3869 container routing-protocols { 3870 description 3871 "Defines routing protocols."; 3872 list routing-protocol { 3873 key "id"; 3874 description 3875 "List of routing protocols used on 3876 the CE/PE link. This list can be augmented."; 3877 leaf id { 3878 type string; 3879 description 3880 "Unique identifier for routing protocol."; 3881 } 3882 leaf type { 3883 type identityref { 3884 base vpn-common:routing-protocol-type; 3885 } 3886 description 3887 "Type of routing protocol."; 3888 } 3889 list routing-profiles { 3890 key "id"; 3891 description 3892 "Routing profiles."; 3893 leaf id { 3894 type leafref { 3895 path "/l3vpn-ntw/vpn-profiles" 3896 + "/valid-provider-identifiers" 3897 + "/routing-profile-identifier/id"; 3898 } 3899 description 3900 "Routing profile to be used."; 3901 } 3902 leaf type { 3903 type identityref { 3904 base vpn-common:ie-type; 3905 } 3906 description 3907 "Import, export, or both."; 3908 } 3909 } 3910 container static { 3911 when "derived-from-or-self(../type, " 3912 + "'vpn-common:static')" { 3913 description 3914 "Only applies when protocol is static."; 3915 } 3916 description 3917 "Configuration specific to static routing."; 3918 container cascaded-lan-prefixes { 3919 description 3920 "LAN prefixes from the customer."; 3921 list ipv4-lan-prefixes { 3922 if-feature "vpn-common:ipv4"; 3923 key "lan next-hop"; 3924 description 3925 "List of LAN prefixes for the site."; 3926 leaf lan { 3927 type inet:ipv4-prefix; 3928 description 3929 "LAN prefixes."; 3930 } 3931 leaf lan-tag { 3932 type string; 3933 description 3934 "Internal tag to be used in VPN 3935 policies."; 3936 } 3937 leaf next-hop { 3938 type union { 3939 type inet:ip-address; 3940 type predefined-next-hop; 3941 } 3942 description 3943 "The next-hop that is to be used 3944 for the static route. This may be 3945 specified as an IP address, an interface, 3946 or a pre-defined next-hop type (e.g., 3947 discard or local-link)."; 3948 } 3949 leaf bfd-enable { 3950 if-feature "vpn-common:bfd"; 3951 type boolean; 3952 description 3953 "Enables BFD."; 3954 } 3955 leaf metric { 3956 type uint32; 3957 description 3958 "Indicates the metric associated with 3959 the static route."; 3960 } 3961 leaf preference { 3962 type uint32; 3963 description 3964 "Indicates the preference of the static 3965 routes."; 3966 } 3967 uses vpn-common:service-status; 3968 } 3969 list ipv6-lan-prefixes { 3970 if-feature "vpn-common:ipv6"; 3971 key "lan next-hop"; 3972 description 3973 "List of LAN prefixes for the site."; 3974 leaf lan { 3975 type inet:ipv6-prefix; 3976 description 3977 "LAN prefixes."; 3978 } 3979 leaf lan-tag { 3980 type string; 3981 description 3982 "Internal tag to be used in VPN 3983 policies."; 3984 } 3985 leaf next-hop { 3986 type union { 3987 type inet:ip-address; 3988 type predefined-next-hop; 3989 } 3990 description 3991 "The next-hop that is to be used for the 3992 static route. This may be specified as 3993 an IP address, an interface, or a 3994 pre-defined next-hop type (e.g., 3995 discard or local-link)."; 3996 } 3997 leaf bfd-enable { 3998 if-feature "vpn-common:bfd"; 3999 type boolean; 4000 description 4001 "Enables BFD."; 4002 } 4003 leaf metric { 4004 type uint32; 4005 description 4006 "Indicates the metric associated with 4007 the static route."; 4008 } 4009 leaf preference { 4010 type uint32; 4011 description 4012 "Indicates the preference associated 4013 with the static route."; 4014 } 4015 uses vpn-common:service-status; 4016 } 4017 } 4018 } 4019 container bgp { 4020 when "derived-from-or-self(../type, " 4021 + "'vpn-common:bgp')" { 4022 description 4023 "Only applies when protocol is BGP."; 4024 } 4025 if-feature "vpn-common:rtg-bgp"; 4026 description 4027 "BGP-specific configuration."; 4028 leaf description { 4029 type string; 4030 description 4031 "Includes a description of the BGP session. 4033 Such description is meant to be used for 4034 diagnosis purposes. The semantic of the 4035 description is local to an 4036 implementation."; 4037 } 4038 leaf local-autonomous-system { 4039 type inet:as-number; 4040 description 4041 "Indicates a local AS Number (ASN) if a 4042 distinct ASN than the one configured at 4043 the VPN node level is needed."; 4044 } 4045 leaf peer-autonomous-system { 4046 type inet:as-number; 4047 mandatory true; 4048 description 4049 "Indicates the customer's ASN in 4050 case the customer requests BGP routing."; 4051 } 4052 leaf address-family { 4053 type identityref { 4054 base vpn-common:address-family; 4055 } 4056 description 4057 "This node contains the address families to be 4058 activated. Dual-stack means that both IPv4 4059 and IPv6 will be activated."; 4060 } 4061 leaf local-address { 4062 type union { 4063 type inet:ip-address; 4064 type if:interface-ref; 4065 } 4066 description 4067 "Set the local IP address to use for the BGP 4068 transport session. This may be expressed as 4069 either an IP address or a reference to an 4070 interface."; 4071 } 4072 leaf-list neighbor { 4073 type inet:ip-address; 4074 description 4075 "IP address(es) of the BGP neighbor. IPv4 4076 and IPv6 neighbors may be indicated if 4077 two sessions will be used for IPv4 and 4078 IPv6."; 4079 } 4080 leaf multihop { 4081 type uint8; 4082 description 4083 "Describes the number of IP hops allowed 4084 between a given BGP neighbor and the PE."; 4085 } 4086 leaf as-override { 4087 type boolean; 4088 default "false"; 4089 description 4090 "Defines whether ASN override is enabled, 4091 i.e., replace the ASN of the customer 4092 specified in the AS_Path attribute with 4093 the local ASN."; 4094 } 4095 leaf allow-own-as { 4096 type uint8; 4097 default "0"; 4098 description 4099 "Specifies the number of occurrences 4100 of the provider's ASN that can occur 4101 within the AS_PATH before it 4102 is rejected."; 4103 } 4104 leaf prepend-global-as { 4105 type boolean; 4106 default "false"; 4107 description 4108 "In some situations, the ASN that is 4109 provided at the VPN node level may be 4110 distinct from the one configured at the 4111 VPN network access level. When set to 4112 'true', this parameter prevents that 4113 the ASN provided at the VPN node 4114 level is also prepended to the BGP 4115 route updates for this access."; 4116 } 4117 leaf default-route { 4118 type boolean; 4119 default "false"; 4120 description 4121 "Defines whether default routes can be 4122 advertised to its peer. If set, the 4123 default routes are advertised to its 4124 peer."; 4125 } 4126 leaf site-of-origin { 4127 when "../address-family = 'vpn-common:ipv4' or " 4128 + "'vpn-common:dual-stack'" { 4129 description 4130 "Only applies if IPv4 is activated."; 4131 } 4132 type rt-types:route-origin; 4133 description 4134 "The Site of Origin attribute is encoded as 4135 a Route Origin Extended Community. It is 4136 meant to uniquely identify the set of routes 4137 learned from a site via a particular CE/PE 4138 connection and is used to prevent routing 4139 loops."; 4140 reference 4141 "RFC 4364: BGP/MPLS IP Virtual Private 4142 Networks (VPNs), Section 7"; 4143 } 4144 leaf ipv6-site-of-origin { 4145 when "../address-family = 'vpn-common:ipv6' or " 4146 + "'vpn-common:dual-stack'" { 4147 description 4148 "Only applies if IPv6 is activated."; 4149 } 4150 type rt-types:ipv6-route-origin; 4151 description 4152 "IPv6 Route Origins are IPv6 Address Specific 4153 BGP Extended that are meant to the Site of 4154 Origin for VRF information."; 4155 reference 4156 "RFC 5701: IPv6 Address Specific BGP Extended 4157 Community Attribute"; 4158 } 4159 list redistribute-connected { 4160 key "address-family"; 4161 description 4162 "Indicates the per-AF policy to follow 4163 for connected routes."; 4164 leaf address-family { 4165 type identityref { 4166 base vpn-common:address-family; 4167 } 4168 description 4169 "Indicates the address family."; 4170 } 4171 leaf enable { 4172 type boolean; 4173 description 4174 "Enables to redistribute connected 4175 routes."; 4176 } 4177 } 4178 container bgp-max-prefix { 4179 description 4180 "Controls the behavior when a prefix 4181 maximum is reached."; 4182 leaf max-prefix { 4183 type uint32; 4184 default "5000"; 4185 description 4186 "Indicates the maximum number of BGP 4187 prefixes allowed in the BGP session. 4189 It allows to control how many prefixes 4190 can be received from a neighbor. 4192 If the limit is exceeded, the action 4193 indicated in violate-action will be 4194 followed."; 4195 reference 4196 "RFC 4271: A Border Gateway Protocol 4 4197 (BGP-4), Section 8.2.2"; 4198 } 4199 leaf warning-threshold { 4200 type decimal64 { 4201 fraction-digits 5; 4202 range "0..100"; 4203 } 4204 units "percent"; 4205 default "75"; 4206 description 4207 "When this value is reached, a warning 4208 notification will be triggered."; 4209 } 4210 leaf violate-action { 4211 type enumeration { 4212 enum warning { 4213 description 4214 "Only a warning message is sent to 4215 the peer when the limit is 4216 exceeded."; 4217 } 4218 enum discard-extra-paths { 4219 description 4220 "Discards extra paths when the 4221 limit is exceeded."; 4222 } 4223 enum restart { 4224 description 4225 "Restarts after a time interval."; 4226 } 4227 } 4228 description 4229 "BGP neighbor max-prefix violate 4230 action"; 4231 } 4232 leaf restart-interval { 4233 type uint16; 4234 units "minutes"; 4235 description 4236 "Time interval (min) after which the 4237 BGP session will be reestablished."; 4238 } 4239 } 4240 container bgp-timers { 4241 description 4242 "Includes two BGP timers that can be 4243 customized when building a VPN service 4244 with BGP used as CE-PE routing 4245 protocol."; 4246 leaf keepalive { 4247 type uint16 { 4248 range "0..21845"; 4249 } 4250 units "seconds"; 4251 default "30"; 4252 description 4253 "This timer indicates the KEEPALIVE 4254 messages' frequency between a PE 4255 and a BGP peer. 4257 If set to '0', it indicates KEEPALIVE 4258 messages are disabled. 4260 It is suggested that the maximum time 4261 between KEEPALIVE messages would be 4262 one third of the Hold Time interval."; 4263 reference 4264 "RFC 4271: A Border Gateway Protocol 4 4265 (BGP-4), Section 4.4"; 4266 } 4267 leaf hold-time { 4268 type uint16 { 4269 range "0 | 3..65535"; 4270 } 4271 units "seconds"; 4272 default "90"; 4273 description 4274 "It indicates the maximum number of 4275 seconds that may elapse between the 4276 receipt of successive KEEPALIVE 4277 and/or UPDATE messages from the peer. 4279 The Hold Time must be either zero or 4280 at least three seconds."; 4281 reference 4282 "RFC 4271: A Border Gateway Protocol 4 4283 (BGP-4), Section 4.2"; 4284 } 4285 } 4286 container security { 4287 description 4288 "Container for BGP security parameters 4289 between a PE and a CE."; 4290 leaf enable { 4291 type boolean; 4292 default "false"; 4293 description 4294 "Enables or disables authentication."; 4295 } 4296 container keying-material { 4297 when "../enable = 'true'"; 4298 description 4299 "Container for describing how a BGP routing 4300 session is to be secured between a PE and 4301 a CE."; 4302 choice option { 4303 description 4304 "Choice of authentication options."; 4305 case tcp-ao { 4306 description 4307 "Uses TCP-Authentication Option 4308 (TCP-AO)."; 4309 reference 4310 "RFC 5925: The TCP Authentication 4311 Option."; 4312 leaf enable-tcp-ao { 4313 type boolean; 4314 description 4315 "Enables TCP-AO."; 4316 } 4317 leaf ao-keychain { 4318 type key-chain:key-chain-ref; 4319 description 4320 "Reference to the TCP-AO key chain."; 4321 reference 4322 "RFC 8177: YANG Key Chain."; 4323 } 4324 } 4325 case md5 { 4326 description 4327 "Uses MD5 to secure the session."; 4328 reference 4329 "RFC 4364: BGP/MPLS IP Virtual Private 4330 Networks (VPNs), 4331 Section 13.2"; 4332 leaf md5-keychain { 4333 type key-chain:key-chain-ref; 4334 description 4335 "Reference to the MD5 key chain."; 4336 reference 4337 "RFC 8177: YANG Key Chain."; 4338 } 4339 } 4340 case explicit { 4341 leaf key-id { 4342 type uint32; 4343 description 4344 "Key Identifier"; 4345 } 4346 leaf key { 4347 type string; 4348 description 4349 "BGP authentication key."; 4350 } 4351 leaf crypto-algorithm { 4352 type identityref { 4353 base key-chain:crypto-algorithm; 4354 } 4355 description 4356 "Indicates the cryptographic algorithm 4357 associated with the key."; 4358 } 4359 } 4360 case ipsec { 4361 description 4362 "Specifies a reference to an IKE 4363 Security Association (SA)."; 4364 leaf sa { 4365 type string; 4366 description 4367 "Indicates the name of the SA."; 4368 } 4369 } 4370 } 4371 } 4372 } 4373 uses vpn-common:service-status; 4374 } 4375 container ospf { 4376 when "derived-from-or-self(../type, " 4377 + "'vpn-common:ospf')" { 4378 description 4379 "Only applies when protocol is OSPF."; 4380 } 4381 if-feature "vpn-common:rtg-ospf"; 4382 description 4383 "OSPF-specific configuration."; 4384 leaf address-family { 4385 type identityref { 4386 base vpn-common:address-family; 4387 } 4388 description 4389 "Indicates whether IPv4, IPv6, or 4390 both are to be activated."; 4391 } 4392 leaf area-id { 4393 type yang:dotted-quad; 4394 mandatory true; 4395 description 4396 "Area ID."; 4398 reference 4399 "RFC 4577: OSPF as the Provider/Customer 4400 Edge Protocol for BGP/MPLS IP 4401 Virtual Private Networks 4402 (VPNs), Section 4.2.3 4403 RFC 6565: OSPFv3 as a Provider Edge to 4404 Customer Edge (PE-CE) Routing 4405 Protocol, Section 4.2"; 4406 } 4407 leaf metric { 4408 type uint16; 4409 default "1"; 4410 description 4411 "Metric of the PE-CE link. It is used 4412 in the routing state calculation and 4413 path selection."; 4414 } 4415 container sham-links { 4416 if-feature "vpn-common:rtg-ospf-sham-link"; 4417 description 4418 "List of sham links."; 4419 reference 4420 "RFC 4577: OSPF as the Provider/Customer 4421 Edge Protocol for BGP/MPLS IP 4422 Virtual Private Networks 4423 (VPNs), Section 4.2.7 4424 RFC 6565: OSPFv3 as a Provider Edge to 4425 Customer Edge (PE-CE) Routing 4426 Protocol, Section 5"; 4427 list sham-link { 4428 key "target-site"; 4429 description 4430 "Creates a sham link with another site."; 4431 leaf target-site { 4432 type vpn-common:vpn-id; 4433 description 4434 "Target site for the sham link connection. 4435 The site is referred to by its ID."; 4436 } 4437 leaf metric { 4438 type uint16; 4439 default "1"; 4440 description 4441 "Metric of the sham link. It is used in 4442 the routing state calculation and path 4443 selection. The default value is set 4444 to 1."; 4445 reference 4446 "RFC 4577: OSPF as the Provider/Customer 4447 Edge Protocol for BGP/MPLS IP 4448 Virtual Private Networks 4449 (VPNs), Section 4.2.7.3 4450 RFC 6565: OSPFv3 as a Provider Edge to 4451 Customer Edge (PE-CE) Routing 4452 Protocol, Section 5.2"; 4453 } 4454 } 4455 } 4456 leaf max-lsa { 4457 type uint32 { 4458 range "1..4294967294"; 4459 } 4460 description 4461 "Maximum number of allowed LSAs OSPF."; 4462 } 4463 container security { 4464 description 4465 "Authentication configuration."; 4466 leaf enable { 4467 type boolean; 4468 default "false"; 4469 description 4470 "Enables or disables authentication."; 4471 } 4472 container keying-material { 4473 when "../enable = 'true'"; 4474 description 4475 "Container for describing how an OSPF 4476 session is to be secured between a CE 4477 and a PE."; 4478 choice option { 4479 description 4480 "Options for OSPF authentication."; 4481 case auth-key-chain { 4482 leaf key-chain { 4483 type key-chain:key-chain-ref; 4484 description 4485 "key-chain name."; 4486 } 4487 } 4488 case auth-key-explicit { 4489 leaf key-id { 4490 type uint32; 4491 description 4492 "Key identifier."; 4493 } 4494 leaf key { 4495 type string; 4496 description 4497 "OSPF authentication key."; 4498 } 4499 leaf crypto-algorithm { 4500 type identityref { 4501 base key-chain:crypto-algorithm; 4502 } 4503 description 4504 "Indicates the cryptographic algorithm 4505 associated with the key."; 4506 } 4507 } 4508 case ipsec { 4509 leaf sa { 4510 type string; 4511 description 4512 "Indicates the name of the SA."; 4513 reference 4514 "RFC 4552: Authentication 4515 /Confidentiality for 4516 OSPFv3"; 4517 } 4518 } 4519 } 4520 } 4521 } 4522 uses vpn-common:service-status; 4523 } 4524 container isis { 4525 when "derived-from-or-self(../type, " 4526 + "'vpn-common:isis')" { 4527 description 4528 "Only applies when protocol is IS-IS."; 4529 } 4530 if-feature "vpn-common:rtg-isis"; 4531 description 4532 "IS-IS specific configuration."; 4533 leaf address-family { 4534 type identityref { 4535 base vpn-common:address-family; 4536 } 4537 description 4538 "Indicates whether IPv4, IPv6, or both 4539 are to be activated."; 4540 } 4541 leaf area-address { 4542 type area-address; 4543 mandatory true; 4544 description 4545 "Area address."; 4546 } 4547 leaf level { 4548 type identityref { 4549 base vpn-common:isis-level; 4550 } 4551 description 4552 "Can be level-1, level-2, or level-1-2."; 4553 } 4554 leaf metric { 4555 type uint16; 4556 default "1"; 4557 description 4558 "Metric of the PE-CE link. It is used 4559 in the routing state calculation and 4560 path selection."; 4561 } 4562 leaf mode { 4563 type enumeration { 4564 enum active { 4565 description 4566 "Interface sends or receives IS-IS 4567 protocol control packets."; 4568 } 4569 enum passive { 4570 description 4571 "Suppresses the sending of IS-IS 4572 updates through the specified 4573 interface."; 4574 } 4575 } 4576 default "active"; 4577 description 4578 "IS-IS interface mode type."; 4579 } 4580 container security { 4581 description 4582 "Authentication configuration."; 4583 leaf enable { 4584 type boolean; 4585 default "false"; 4586 description 4587 "Enables or disables authentication."; 4588 } 4589 container keying-material { 4590 when "../enable = 'true'"; 4591 description 4592 "Container for describing how an IS-IS 4593 session is to be secured between a CE 4594 and a PE."; 4595 choice option { 4596 description 4597 "Options for IS-IS authentication."; 4598 case auth-key-chain { 4599 leaf key-chain { 4600 type key-chain:key-chain-ref; 4601 description 4602 "key-chain name."; 4603 } 4604 } 4605 case auth-key-explicit { 4606 leaf key-id { 4607 type uint32; 4608 description 4609 "Key Identifier"; 4610 } 4611 leaf key { 4612 type string; 4613 description 4614 "IS-IS authentication key."; 4615 } 4616 leaf crypto-algorithm { 4617 type identityref { 4618 base key-chain:crypto-algorithm; 4619 } 4620 description 4621 "Indicates the cryptographic algorithm 4622 associated with the key."; 4623 } 4624 } 4625 } 4626 } 4627 } 4628 uses vpn-common:service-status; 4629 } 4630 container rip { 4631 when "derived-from-or-self(../type, " 4632 + "'vpn-common:rip')" { 4633 description 4634 "Only applies when the protocol is RIP. 4635 For IPv4, the model assumes that RIP 4636 version 2 is used."; 4637 } 4638 if-feature "vpn-common:rtg-rip"; 4639 description 4640 "Configuration specific to RIP routing."; 4641 leaf address-family { 4642 type identityref { 4643 base vpn-common:address-family; 4644 } 4645 description 4646 "Indicates whether IPv4, IPv6, or both 4647 address families are to be activated."; 4648 } 4649 container timers { 4650 description 4651 "Indicates the RIP timers."; 4652 reference 4653 "RFC 2453: RIP Version 2"; 4654 leaf update-interval { 4655 type uint16 { 4656 range "1..32767"; 4657 } 4658 units "seconds"; 4659 default "30"; 4660 description 4661 "Indicates the RIP update time. 4662 That is, the amount of time for which 4663 routing updates are sent."; 4664 } 4665 leaf invalid-interval { 4666 type uint16 { 4667 range "1..32767"; 4668 } 4669 units "seconds"; 4670 default "180"; 4671 description 4672 "Is the interval before a route is declared 4673 invalid after no updates are received. 4674 This value is at least three times 4675 the value for the update-interval 4676 argument."; 4677 } 4678 leaf holddown-interval { 4679 type uint16 { 4680 range "1..32767"; 4681 } 4682 units "seconds"; 4683 default "180"; 4684 description 4685 "Specifies the interval before better routes 4686 are released."; 4687 } 4688 leaf flush-interval { 4689 type uint16 { 4690 range "1..32767"; 4691 } 4692 units "seconds"; 4693 default "180"; 4694 description 4695 "Indicates the RIP flush timer. That is, 4696 the amount of time that must elapse before 4697 a route is removed from the routing 4698 table."; 4699 } 4700 } 4701 leaf default-metric { 4702 type uint8 { 4703 range "0..16"; 4704 } 4705 default "1"; 4706 description 4707 "Sets the default metric."; 4708 } 4709 container security { 4710 description 4711 "Authentication configuration."; 4712 leaf enable { 4713 type boolean; 4714 default "false"; 4715 description 4716 "Enables or disables authentication."; 4717 } 4718 container keying-material { 4719 when "../enable = 'true'"; 4720 description 4721 "Container for describing how a RIP 4722 session is to be secured between a CE 4723 and a PE."; 4724 choice option { 4725 description 4726 "Specifies the authentication scheme."; 4727 case auth-key-chain { 4728 leaf key-chain { 4729 type key-chain:key-chain-ref; 4730 description 4731 "key-chain name."; 4732 } 4733 } 4734 case auth-key-explicit { 4735 leaf key { 4736 type string; 4737 description 4738 "RIP authentication key."; 4739 } 4740 leaf crypto-algorithm { 4741 type identityref { 4742 base key-chain:crypto-algorithm; 4743 } 4744 description 4745 "Indicates the cryptographic algorithm 4746 associated with the key."; 4747 } 4748 } 4749 } 4750 } 4751 } 4752 uses vpn-common:service-status; 4753 } 4754 container vrrp { 4755 when "derived-from-or-self(../type, " 4756 + "'vpn-common:vrrp')" { 4757 description 4758 "Only applies when protocol is VRRP."; 4759 } 4760 if-feature "vpn-common:rtg-vrrp"; 4761 description 4762 "Configuration specific to VRRP."; 4763 reference 4764 "RFC 5798: Virtual Router Redundancy Protocol 4765 (VRRP) Version 3 for IPv4 and IPv6"; 4766 leaf address-family { 4767 type identityref { 4768 base vpn-common:address-family; 4769 } 4770 description 4771 "Indicates whether IPv4, IPv6, or both 4772 address families are to be enabled."; 4773 } 4774 leaf vrrp-group { 4775 type uint8 { 4776 range "1..255"; 4777 } 4778 description 4779 "Includes the VRRP group identifier."; 4780 } 4781 leaf backup-peer { 4782 type inet:ip-address; 4783 description 4784 "Indicates the IP address of the peer."; 4785 } 4786 leaf-list virtual-ip-address { 4787 type inet:ip-address; 4788 description 4789 "Virtual IP addresses for a single VRRP group. "; 4790 reference 4791 "RFC 5798: Virtual Router Redundancy Protocol (VRRP) 4792 Version 3 for IPv4 and IPv6, Sections 4793 1.2 and 1.3"; 4794 } 4795 leaf priority { 4796 type uint8 { 4797 range "1..254"; 4798 } 4799 default "100"; 4800 description 4801 "Sets the local priority of the VRRP 4802 speaker."; 4803 } 4804 leaf ping-reply { 4805 type boolean; 4806 description 4807 "Controls whether the VRRP speaker should 4808 answer to ping requests."; 4809 } 4810 uses vpn-common:service-status; 4811 } 4812 } 4813 } 4814 container oam { 4815 description 4816 "Defines the Operations, Administration, 4817 and Maintenance (OAM) mechanisms used. 4819 BFD is set as a fault detection mechanism, 4820 but other mechanisms can be defined in the 4821 future."; 4822 container bfd { 4823 if-feature "vpn-common:bfd"; 4824 description 4825 "Container for BFD."; 4826 leaf desired-min-tx-interval { 4827 type uint32; 4828 units microseconds; 4829 default 1000000; 4830 description 4831 "The minimum interval between transmission of 4832 BFD control packets that the operator desires."; 4833 reference 4834 "RFC 5880: Bidirectional Forwarding Detection 4835 (BFD), Section 6.8.7"; 4836 } 4837 leaf required-min-rx-interval { 4838 type uint32; 4839 units microseconds; 4840 description 4841 "The minimum interval between received BFD 4842 control packets that the PE should support."; 4843 reference 4844 "RFC 5880: Bidirectional Forwarding Detection 4845 (BFD), Section 6.8.7"; 4846 } 4847 leaf detection-multiplier { 4848 type uint8 { 4849 range "1..max"; 4850 } 4851 description 4852 "The detection interval for the BFD session 4853 is calculated by multiplying the value of 4854 the negotiated transmission interval by 4855 the detection multiplier value."; 4856 reference 4857 "RFC 5880: Bidirectional Forwarding Detection 4858 (BFD), Section 6.8.7"; 4859 } 4860 choice holdtime { 4861 default "fixed"; 4862 description 4863 "Choice for holdtime flavor."; 4864 case fixed { 4865 leaf fixed-value { 4866 type uint32; 4867 units "msec"; 4868 description 4869 "Expected BFD holdtime. 4871 The customer may impose some fixed 4872 values for the holdtime period if the 4873 provider allows the customer use this 4874 function. 4876 If the provider doesn't allow the 4877 customer to use this function, 4878 the fixed-value will not be set."; 4879 } 4880 } 4881 case profile { 4882 description 4883 "Well-known SP profile."; 4884 leaf profile-name { 4885 type leafref { 4886 path "/l3vpn-ntw/vpn-profiles" 4887 + "/valid-provider-identifiers" 4888 + "/bfd-profile-identifier/id"; 4889 } 4890 description 4891 "Well-known service provider profile name. 4893 The provider can propose some profiles 4894 to the customer, depending on the 4895 service level the customer wants to 4896 achieve."; 4897 } 4898 } 4899 } 4900 container authentication { 4901 presence "Enables BFD authentication"; 4902 description 4903 "Parameters for BFD authentication."; 4904 leaf key-chain { 4905 type key-chain:key-chain-ref; 4906 description 4907 "Name of the key-chain."; 4908 } 4909 leaf meticulous { 4910 type boolean; 4911 description 4912 "Enables meticulous mode."; 4913 reference 4914 "RFC 5880: Bidirectional Forwarding 4915 Detection (BFD), Section 6.7"; 4916 } 4917 } 4918 uses vpn-common:service-status; 4919 } 4920 } 4921 container security { 4922 description 4923 "Site-specific security parameters."; 4924 container encryption { 4925 if-feature "vpn-common:encryption"; 4926 description 4927 "Container for CE-PE security encryption."; 4928 leaf enabled { 4929 type boolean; 4930 default "false"; 4931 description 4932 "If true, traffic encryption on the 4933 connection is required. It is 4934 disabled, otherwise."; 4935 } 4936 leaf layer { 4937 when "../enabled = 'true'" { 4938 description 4939 "Indicates the layer on which encryption 4940 is enabled."; 4941 } 4942 type enumeration { 4943 enum layer2 { 4944 description 4945 "Encryption occurs at Layer 2."; 4946 } 4947 enum layer3 { 4948 description 4949 "Encryption occurs at Layer 3. 4950 For example, IPsec may be used when 4951 a customer requests Layer 3 4952 encryption."; 4953 } 4954 } 4955 description 4956 "Indicates the layer on which encryption 4957 is applied."; 4958 } 4959 } 4960 container encryption-profile { 4961 when "../encryption/enabled = 'true'" { 4962 description 4963 "Indicates the layer on which encryption 4964 is enabled."; 4965 } 4966 description 4967 "Container for encryption profile."; 4968 choice profile { 4969 description 4970 "Choice for the encryption profile."; 4971 case provider-profile { 4972 leaf profile-name { 4973 type leafref { 4974 path "/l3vpn-ntw/vpn-profiles" 4975 + "/valid-provider-identifiers" 4976 + "/encryption-profile-identifier/id"; 4977 } 4978 description 4979 "Name of the service provider's profile 4980 to be applied."; 4981 } 4982 } 4983 case customer-profile { 4984 leaf customer-key-chain { 4985 type key-chain:key-chain-ref; 4986 description 4987 "Customer-supplied key chain."; 4988 } 4989 } 4990 } 4991 } 4992 } 4993 container service { 4994 description 4995 "Service parameters of the attachment."; 4996 leaf input-bandwidth { 4997 if-feature "vpn-common:input-bw"; 4998 type uint64; 4999 units "bps"; 5000 description 5001 "From the customer site's perspective, the 5002 service input bandwidth of the connection 5003 or download bandwidth from the SP to 5004 the site."; 5005 } 5006 leaf output-bandwidth { 5007 if-feature "vpn-common:output-bw"; 5008 type uint64; 5009 units "bps"; 5010 description 5011 "From the customer site's perspective, 5012 the service output bandwidth of the 5013 connection or upload bandwidth from 5014 the site to the SP."; 5015 } 5016 leaf mtu { 5017 type uint16; 5018 units "bytes"; 5019 description 5020 "MTU at service level. If the service is IP, 5021 it refers to the IP MTU. If CsC is enabled, 5022 the requested MTU will refer 5023 to the MPLS MTU and not to the IP MTU."; 5024 } 5025 container qos { 5026 if-feature "vpn-common:qos"; 5027 description 5028 "QoS configuration."; 5029 container qos-classification-policy { 5030 description 5031 "Configuration of the traffic classification 5032 policy."; 5033 uses vpn-common:qos-classification-policy; 5034 } 5035 container qos-action { 5036 description 5037 "List of QoS action policies."; 5038 list rule { 5039 key "id"; 5040 description 5041 "List of QoS actions."; 5042 leaf id { 5043 type string; 5044 description 5045 "An identifier of the QoS action rule."; 5046 } 5047 leaf target-class-id { 5048 type string; 5049 description 5050 "Identification of the class of service. 5051 This identifier is internal to the 5052 administration."; 5053 } 5054 leaf inbound-rate-limit { 5055 type decimal64 { 5056 fraction-digits 5; 5057 range "0..100"; 5058 } 5059 units "percent"; 5060 description 5061 "Specifies whether/how to rate-limit the 5062 inbound traffic matching this QoS policy. 5063 It is expressed as a percent of the value 5064 that is indicated in 'input-bandwidth'."; 5065 } 5066 leaf outbound-rate-limit { 5067 type decimal64 { 5068 fraction-digits 5; 5069 range "0..100"; 5071 } 5072 units "percent"; 5073 description 5074 "Specifies whether/how to rate-limit the 5075 outbound traffic matching this QoS policy. 5076 It is expressed as a percent of the value 5077 that is indicated in 'output-bandwidth'."; 5078 } 5079 } 5080 } 5081 container qos-profile { 5082 description 5083 "QoS profile configuration."; 5084 list qos-profile { 5085 key "profile"; 5086 description 5087 "QoS profile. 5088 Can be standard profile or customized 5089 profile."; 5090 leaf profile { 5091 type leafref { 5092 path "/l3vpn-ntw/vpn-profiles" 5093 + "/valid-provider-identifiers" 5094 + "/qos-profile-identifier/id"; 5095 } 5096 description 5097 "QoS profile to be used."; 5098 } 5099 leaf direction { 5100 type identityref { 5101 base vpn-common:qos-profile-direction; 5102 } 5103 default "vpn-common:both"; 5104 description 5105 "The direction to which the QoS profile 5106 is applied."; 5107 } 5108 } 5109 } 5110 } 5111 container carrierscarrier { 5112 if-feature "vpn-common:carrierscarrier"; 5113 description 5114 "This container is used when the customer 5115 provides MPLS-based services. This is 5116 only used in the case of CsC (i.e., a 5117 customer builds an MPLSservice using an 5118 IP VPN to carry its traffic)."; 5120 leaf signalling-type { 5121 type enumeration { 5122 enum ldp { 5123 description 5124 "Use LDP as the signalling protocol 5125 between the PE and the CE. In this 5126 case, an IGP routing protocol must 5127 also be activated."; 5128 } 5129 enum bgp { 5130 description 5131 "Use BGP as the signalling protocol 5132 between the PE and the CE. 5133 In this case, BGP must also be configured 5134 as the routing protocol."; 5135 reference 5136 "RFC 8277: Using BGP to Bind MPLS Labels 5137 to Address Prefixes"; 5138 } 5139 } 5140 default "bgp"; 5141 description 5142 "MPLS signalling type."; 5143 } 5144 } 5145 container ntp { 5146 description 5147 "Time synchronization may be needed in some 5148 VPNs such as infrastructure and Management 5149 VPNs. This container includes parameters to 5150 enable NTP service."; 5151 reference 5152 "RFC 5905: Network Time Protocol Version 4: 5153 Protocol and Algorithms 5154 Specification"; 5155 leaf broadcast { 5156 type enumeration { 5157 enum client { 5158 description 5159 "The VPN node will listen to NTP broadcast 5160 messages on this VPN network access."; 5161 } 5162 enum server { 5163 description 5164 "The VPN node will behave as a broadcast 5165 server."; 5166 } 5167 } 5168 description 5169 "Indicates NTP broadcast mode to use for the 5170 VPN network access."; 5171 } 5172 container auth-profile { 5173 description 5174 "Pointer to a local profile."; 5175 leaf profile-id { 5176 type string; 5177 description 5178 "A pointer to a local authentication 5179 profile on the VPN node is provided."; 5180 } 5181 } 5182 uses vpn-common:service-status; 5183 } 5184 container multicast { 5185 if-feature "vpn-common:multicast"; 5186 description 5187 "Multicast parameters for the network 5188 access."; 5189 leaf access-type { 5190 type enumeration { 5191 enum receiver-only { 5192 description 5193 "The peer site only has receivers."; 5194 } 5195 enum source-only { 5196 description 5197 "The peer site only has sources."; 5198 } 5199 enum source-receiver { 5200 description 5201 "The peer site has both sources and 5202 receivers."; 5203 } 5204 } 5205 default "source-receiver"; 5206 description 5207 "Type of multicast site."; 5208 } 5209 leaf address-family { 5210 type identityref { 5211 base vpn-common:address-family; 5212 } 5213 description 5214 "Indicates the address family."; 5215 } 5216 leaf protocol-type { 5217 type enumeration { 5218 enum host { 5219 description 5220 "Hosts are directly connected to the 5221 provider network. 5223 Host protocols such as IGMP or MLD are 5224 required."; 5225 } 5226 enum router { 5227 description 5228 "Hosts are behind a customer router. 5229 PIM will be implemented."; 5230 } 5231 enum both { 5232 description 5233 "Some hosts are behind a customer router, 5234 and some others are directly connected 5235 to the provider network. Both host and 5236 routing protocols must be used. 5238 Typically, IGMP and PIM will be 5239 implemented."; 5240 } 5241 } 5242 default "both"; 5243 description 5244 "Multicast protocol type to be used with 5245 the customer site."; 5246 } 5247 leaf remote-source { 5248 type boolean; 5249 default "false"; 5250 description 5251 "When true, there is no PIM adjacency on 5252 the interface."; 5253 } 5254 container igmp { 5255 when "../protocol-type = 'host' and " 5256 + "../address-family = 'vpn-common:ipv4' or " 5257 + "'vpn-common:dual-stack'"; 5258 if-feature "vpn-common:igmp"; 5259 description 5260 "Includes IGMP-related parameters."; 5261 list static-group { 5262 key "group-addr"; 5263 description 5264 "Multicast static source/group associated to 5265 to IGMP session"; 5266 leaf group-addr { 5267 type rt-types:ipv4-multicast-group-address; 5268 description 5269 "Multicast group IPv4 addresss."; 5270 } 5271 leaf source-addr { 5272 type rt-types:ipv4-multicast-source-address; 5273 description 5274 "Multicast source IPv4 addresss."; 5275 } 5276 } 5277 leaf max-groups { 5278 type uint32; 5279 description 5280 "Indicates the maximum groups."; 5281 } 5282 leaf max-entries { 5283 type uint32; 5284 description 5285 "Indicates the maximum IGMP entries."; 5286 } 5287 leaf max-group-sources { 5288 type uint32; 5289 description 5290 "The maximum number of group sources."; 5291 } 5292 leaf version { 5293 type identityref { 5294 base vpn-common:igmp-version; 5295 } 5296 default "vpn-common:igmpv2"; 5297 description 5298 "Version of the IGMP."; 5299 } 5300 uses vpn-common:service-status; 5301 } 5302 container mld { 5303 when "../protocol-type = 'host' and " 5304 + "../address-family = 'vpn-common:ipv6' or " 5305 + "'vpn-common:dual-stack'"; 5306 if-feature "vpn-common:mld"; 5307 description 5308 "Includes MLD-related parameters."; 5309 list static-group { 5310 key "group-addr"; 5311 description 5312 "Multicast static source/group associated to 5313 the MLD session"; 5314 leaf group-addr { 5315 type rt-types:ipv6-multicast-group-address; 5316 description 5317 "Multicast group IPv6 addresss."; 5318 } 5319 leaf source-addr { 5320 type rt-types:ipv6-multicast-source-address; 5321 description 5322 "Multicast source IPv6 addresss."; 5323 } 5324 } 5325 leaf max-groups { 5326 type uint32; 5327 description 5328 "Indicates the maximum groups."; 5329 } 5330 leaf max-entries { 5331 type uint32; 5332 description 5333 "Indicates the maximum MLD entries."; 5334 } 5335 leaf max-group-sources { 5336 type uint32; 5337 description 5338 "The maximum number of group sources."; 5339 } 5340 leaf version { 5341 type identityref { 5342 base vpn-common:mld-version; 5343 } 5344 default "vpn-common:mldv2"; 5345 description 5346 "Version of the MLD protocol."; 5347 } 5348 uses vpn-common:service-status; 5349 } 5350 container pim { 5351 when "../protocol-type = 'router'"; 5352 if-feature "vpn-common:pim"; 5353 description 5354 "Only applies when protocol type is PIM."; 5355 leaf hello-interval { 5356 type rt-types:timer-value-seconds16; 5357 default "30"; 5358 description 5359 "PIM hello-messages interval. If set to 5360 'infinity' or 'not-set', no periodic 5361 Hello messages are sent."; 5362 reference 5363 "RFC 7761: Protocol Independent Multicast - 5364 Sparse Mode (PIM-SM): Protocol 5365 Specification (Revised), 5366 Section 4.11"; 5367 } 5368 leaf dr-priority { 5369 type uint32; 5370 default "1"; 5371 description 5372 "Indicates the preference in the DR election 5373 process. Numerically larger DR priority 5374 allows a node to be elected as a DR."; 5375 reference 5376 "RFC 7761: Protocol Independent Multicast - 5377 Sparse Mode (PIM-SM): Protocol 5378 Specification (Revised), 5379 Section 4.3.2"; 5380 } 5381 uses vpn-common:service-status; 5382 } 5383 } 5384 } 5385 } 5386 } 5387 } 5388 } 5389 } 5390 } 5391 } 5392 } 5393 5395 9. Security Considerations 5397 The YANG module specified in this document defines schema for data 5398 that is designed to be accessed via network management protocols such 5399 as NETCONF [RFC6241] or RESTCONF [RFC8040] . The lowest NETCONF layer 5400 is the secure transport layer, and the mandatory-to-implement secure 5401 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 5402 is HTTPS, and the mandatory-to-implement secure transport is TLS 5403 [RFC8446]. 5405 The Network Configuration Access Control Model (NACM) [RFC8341] 5406 provides the means to restrict access for particular NETCONF or 5407 RESTCONF users to a preconfigured subset of all available NETCONF or 5408 RESTCONF protocol operations and content. 5410 There are a number of data nodes defined in this YANG module that are 5411 writable/creatable/deletable (i.e., config true, which is the 5412 default). These data nodes may be considered sensitive or vulnerable 5413 in some network environments. Write operations (e.g., edit-config) 5414 and delete operations to these data nodes without proper protection 5415 or authentication can have a negative effect on network operations. 5416 These are the subtrees and data nodes and their sensitivity/ 5417 vulnerability in the "ietf-l3vpn-ntw" module: 5419 o 'vpn-service': An attacker who is able to access network nodes can 5420 undertake various attacks, such as deleting a running L3VPN 5421 service, interrupting all the traffic of a client. In addition, 5422 an attacker may modify the attributes of a running service (e.g., 5423 QoS, bandwidth, routing protocols), leading to malfunctioning of 5424 the service and therefore to SLA violations. In addition, an 5425 attacker could attempt to create an L3VPN service or adding a new 5426 network access. Such activity can be detected by adequately 5427 monitoring and tracking network configuration changes. 5429 Some of the readable data nodes in this YANG module may be considered 5430 sensitive or vulnerable in some network environments. It is thus 5431 important to control read access (e.g., via get, get-config, or 5432 notification) to these data nodes. These are the subtrees and data 5433 nodes and their sensitivity/vulnerability: 5435 o 'customer-name' and 'ip-connection': An attacker can retrieve 5436 privacy-related information which can be used to track a customer. 5437 Disclosing such information may be considered as a violation of 5438 the customer-provider trust relationship. 5440 Several data nodes defined in the L3NM rely upon [RFC8177] for 5441 authentication purposes. Therefore, this module inherits the 5442 security considerations discussed in Section 5 of [RFC8177]. 5444 The following summarizes the foreseen risks of using the "ietf-l3vpn- 5445 ntw" module can be classified into: 5447 o Malicious clients attempting to delete or modify VPN services. 5449 o Unauthorized clients attempting to create/modify/delete a VPN 5450 service. 5452 o Unauthorized clients attempting to read VPN service related 5453 information. 5455 10. IANA Considerations 5457 This document requests IANA to register the following URI in the "ns" 5458 subregistry within the "IETF XML Registry" [RFC3688]: 5460 URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw 5461 Registrant Contact: The IESG. 5462 XML: N/A; the requested URI is an XML namespace. 5464 This document requests IANA to register the following YANG module in 5465 the "YANG Module Names" subregistry [RFC6020] within the "YANG 5466 Parameters" registry. 5468 name: ietf-l3vpn-ntw 5469 namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw 5470 maintained by IANA: N 5471 prefix: l3nm 5472 reference: RFC XXXX 5474 11. References 5476 11.1. Normative References 5478 [I-D.ietf-opsawg-vpn-common] 5479 Barguil, S., Dios, O. G. D., Boucadair, M., and Q. Wu, "A 5480 Layer 2/3 VPN Common YANG Model", draft-ietf-opsawg-vpn- 5481 common-07 (work in progress), April 2021. 5483 [ISO10589] 5484 ISO, "Intermediate System to Intermediate System intra- 5485 domain routeing information exchange protocol for use in 5486 conjunction with the protocol for providing the 5487 connectionless-mode network service (ISO 8473)", 2002, 5488 . 5490 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 5491 RFC 1112, DOI 10.17487/RFC1112, August 1989, 5492 . 5494 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 5495 dual environments", RFC 1195, DOI 10.17487/RFC1195, 5496 December 1990, . 5498 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 5499 DOI 10.17487/RFC2080, January 1997, 5500 . 5502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5503 Requirement Levels", BCP 14, RFC 2119, 5504 DOI 10.17487/RFC2119, March 1997, 5505 . 5507 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 5508 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, 5509 . 5511 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 5512 DOI 10.17487/RFC2453, November 1998, 5513 . 5515 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 5516 Listener Discovery (MLD) for IPv6", RFC 2710, 5517 DOI 10.17487/RFC2710, October 1999, 5518 . 5520 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 5521 Thyagarajan, "Internet Group Management Protocol, Version 5522 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 5523 . 5525 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 5526 DOI 10.17487/RFC3688, January 2004, 5527 . 5529 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 5530 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 5531 DOI 10.17487/RFC3810, June 2004, 5532 . 5534 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 5535 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 5536 DOI 10.17487/RFC4271, January 2006, 5537 . 5539 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 5540 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 5541 2006, . 5543 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 5544 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 5545 . 5547 [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the 5548 Provider/Customer Edge Protocol for BGP/MPLS IP Virtual 5549 Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, 5550 June 2006, . 5552 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 5553 DOI 10.17487/RFC5308, October 2008, 5554 . 5556 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community 5557 Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, 5558 . 5560 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 5561 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 5562 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 5563 2009, . 5565 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 5566 Version 3 for IPv4 and IPv6", RFC 5798, 5567 DOI 10.17487/RFC5798, March 2010, 5568 . 5570 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 5571 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 5572 . 5574 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 5575 "Network Time Protocol Version 4: Protocol and Algorithms 5576 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 5577 . 5579 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 5580 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 5581 June 2010, . 5583 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 5584 the Network Configuration Protocol (NETCONF)", RFC 6020, 5585 DOI 10.17487/RFC6020, October 2010, 5586 . 5588 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 5589 and A. Bierman, Ed., "Network Configuration Protocol 5590 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 5591 . 5593 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 5594 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 5595 . 5597 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 5598 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 5599 2012, . 5601 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 5602 Encodings and Procedures for Multicast in MPLS/BGP IP 5603 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 5604 . 5606 [RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and 5607 M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge 5608 (PE-CE) Routing Protocol", RFC 6565, DOI 10.17487/RFC6565, 5609 June 2012, . 5611 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 5612 RFC 6991, DOI 10.17487/RFC6991, July 2013, 5613 . 5615 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 5616 Authentication Trailer for OSPFv3", RFC 7166, 5617 DOI 10.17487/RFC7166, March 2014, 5618 . 5620 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 5621 "Security Extension for OSPFv2 When Using Manual Key 5622 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 5623 . 5625 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 5626 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 5627 Multicast - Sparse Mode (PIM-SM): Protocol Specification 5628 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 5629 2016, . 5631 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 5632 RFC 7950, DOI 10.17487/RFC7950, August 2016, 5633 . 5635 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 5636 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 5637 . 5639 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5640 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5641 May 2017, . 5643 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 5644 Zhang, "YANG Data Model for Key Chains", RFC 8177, 5645 DOI 10.17487/RFC8177, June 2017, 5646 . 5648 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 5649 "Common YANG Data Types for the Routing Area", RFC 8294, 5650 DOI 10.17487/RFC8294, December 2017, 5651 . 5653 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 5654 Access Control Model", STD 91, RFC 8341, 5655 DOI 10.17487/RFC8341, March 2018, 5656 . 5658 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 5659 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 5660 . 5662 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 5663 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 5664 . 5666 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 5667 Data Model for Layer 2 Virtual Private Network (L2VPN) 5668 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 5669 2018, . 5671 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 5672 "YANG Data Model for Network Access Control Lists (ACLs)", 5673 RFC 8519, DOI 10.17487/RFC8519, March 2019, 5674 . 5676 11.2. Informative References 5678 [I-D.evenwu-opsawg-yang-composed-vpn] 5679 Even, R., Wu, B., Wu, Q., and YingCheng, "YANG Data Model 5680 for Composed VPN Service Delivery", draft-evenwu-opsawg- 5681 yang-composed-vpn-03 (work in progress), March 2019. 5683 [I-D.ietf-bess-evpn-prefix-advertisement] 5684 Rabadan, J., Henderickx, W., Drake, J. E., Lin, W., and A. 5685 Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- 5686 bess-evpn-prefix-advertisement-11 (work in progress), May 5687 2018. 5689 [I-D.ietf-idr-bgp-model] 5690 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 5691 YANG Model for Service Provider Networks", draft-ietf-idr- 5692 bgp-model-10 (work in progress), November 2020. 5694 [I-D.ietf-pim-yang] 5695 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 5696 Y., and F. Hu, "A YANG Data Model for Protocol Independent 5697 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 5698 progress), May 2018. 5700 [I-D.ietf-rtgwg-qos-model] 5701 Choudhary, A., Jethanandani, M., Strahle, N., Aries, E., 5702 and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos- 5703 model-03 (work in progress), February 2021. 5705 [I-D.ietf-teas-enhanced-vpn] 5706 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 5707 Framework for Enhanced Virtual Private Network (VPN+) 5708 Services", draft-ietf-teas-enhanced-vpn-07 (work in 5709 progress), February 2021. 5711 [I-D.ietf-teas-ietf-network-slices] 5712 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 5713 Makhijani, K., Contreras, L. M., and J. Tantsura, 5714 "Framework for IETF Network Slices", draft-ietf-teas-ietf- 5715 network-slices-00 (work in progress), April 2021. 5717 [PYANG] "pyang", November 2020, 5718 . 5720 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 5721 Discovery Protocol (MSDP)", RFC 3618, 5722 DOI 10.17487/RFC3618, October 2003, 5723 . 5725 [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. 5726 Moore, "Policy Quality of Service (QoS) Information 5727 Model", RFC 3644, DOI 10.17487/RFC3644, November 2003, 5728 . 5730 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 5731 Private Network (VPN) Terminology", RFC 4026, 5732 DOI 10.17487/RFC4026, March 2005, 5733 . 5735 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 5736 Provider-Provisioned Virtual Private Networks (PPVPNs)", 5737 RFC 4110, DOI 10.17487/RFC4110, July 2005, 5738 . 5740 [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., 5741 and A. Gonguet, "Framework for Layer 3 Virtual Private 5742 Networks (L3VPN) Operations and Management", RFC 4176, 5743 DOI 10.17487/RFC4176, October 2005, 5744 . 5746 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 5747 Address Autoconfiguration", RFC 4862, 5748 DOI 10.17487/RFC4862, September 2007, 5749 . 5751 [RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco 5752 Systems' Solution for Multicast in BGP/MPLS IP VPNs", 5753 RFC 6037, DOI 10.17487/RFC6037, October 2010, 5754 . 5756 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 5757 Networking: A Perspective from within a Service Provider 5758 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 5759 . 5761 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 5762 Connectivity Provisioning Profile (CPP)", RFC 7297, 5763 DOI 10.17487/RFC7297, July 2014, 5764 . 5766 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 5767 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 5768 Defined Networking (SDN): Layers and Architecture 5769 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 5770 2015, . 5772 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 5773 Code: The Implementation Status Section", BCP 205, 5774 RFC 7942, DOI 10.17487/RFC7942, July 2016, 5775 . 5777 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 5778 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 5779 . 5781 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 5782 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 5783 DOI 10.17487/RFC8299, January 2018, 5784 . 5786 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 5787 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 5788 . 5790 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 5791 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 5792 . 5794 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 5795 and R. Wilton, "Network Management Datastore Architecture 5796 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 5797 . 5799 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 5800 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 5801 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 5802 2018, . 5804 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 5805 Routing Management (NMDA Version)", RFC 8349, 5806 DOI 10.17487/RFC8349, March 2018, 5807 . 5809 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 5810 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 5811 DOI 10.17487/RFC8453, August 2018, 5812 . 5814 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 5815 Vinapamula, S., and Q. Wu, "A YANG Module for Network 5816 Address Translation (NAT) and Network Prefix Translation 5817 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 5818 . 5820 [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and 5821 L. Geng, "A Framework for Automating Service and Network 5822 Management with YANG", RFC 8969, DOI 10.17487/RFC8969, 5823 January 2021, . 5825 Appendix A. L3VPN Examples 5827 A.1. 4G VPN Provisioning Example 5829 L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise 5830 services mainly because several traffic discrimination policies can 5831 be applied within the network to deliver to the mobile customers a 5832 service that meets the SLA requirements. 5834 As it is shown in the Figure 31, typically, an eNodeB (CE) is 5835 directly connected to the access routers of the mobile backhaul and 5836 their logical interfaces (one or many according to the service type) 5837 are configured in a VPN that transports the packets to the mobile 5838 core platforms. In this example, a 'vpn-node' is created with two 5839 'vpn-network-accesses'. 5841 +-------------+ +------------------+ 5842 | | | PE | 5843 | | | 198.51.100.1 | 5844 | eNodeB |>--------/------->|........... | 5845 | | vlan 1 | | | 5846 | |>--------/------->|...... | | 5847 | | vlan 2 | | | | 5848 | | Direct | +-------------+ | 5849 +-------------+ Routing | | vpn-node-id | | 5850 | | 44 | | 5851 | +-------------+ | 5852 | | 5853 +------------------+ 5855 Figure 31: Mobile Backhaul Example 5857 To create an L3VPN service using the L3NM, the following steps can be 5858 followed. 5860 First: Create the 4G VPN service (Figure 32). 5862 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services 5863 Host: example.com 5864 Content-Type: application/yang-data+json 5866 { 5867 "ietf-l3vpn-ntw:vpn-services": { 5868 "vpn-service": [ 5869 { 5870 "vpn-id": "4G", 5871 "customer-name": "mycustomer", 5872 "vpn-service-topology": "custom", 5873 "description": "VPN to deploy 4G services", 5874 "vpn-instance-profiles": { 5875 "vpn-instance-profile": [ 5876 { 5877 "profile-id": "simple-profile", 5878 "local-autonomous-system": 65550, 5879 "rd": "0:65550:1", 5880 "address-family": [ 5881 { 5882 "address-family": "vpn-common:dual-stack", 5883 "vpn-targets": { 5884 "vpn-target": [ 5885 { 5886 "id": "1", 5887 "route-targets": [ 5888 "0:65550:1" 5889 ], 5890 "route-target-type": "both" 5891 } 5892 ] 5893 } 5894 } 5895 ] 5896 } 5897 ] 5898 } 5899 } 5900 ] 5901 } 5902 } 5904 Figure 32: Create VPN Service 5906 Second: Create a VPN node as depicted in Figure 33. In this type of 5907 service, the VPN node is equivalent to the VRF configured in the 5908 physical device ('ne-id'=198.51.100.1). 5910 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ 5911 vpn-services/vpn-service=4G 5912 Host: example.com 5913 Content-Type: application/yang-data+json 5915 { 5916 "ietf-l3vpn-ntw:vpn-nodes": { 5917 "vpn-node": [ 5918 { 5919 "vpn-node-id": "44", 5920 "ne-id": "198.51.100.1", 5921 "active-vpn-instance-profiles": { 5922 "vpn-instance-profile": [ 5923 { 5924 "profile-id": "simple-profile" 5925 } 5926 ] 5927 } 5928 } 5929 ] 5930 } 5931 } 5933 Figure 33: Create VPN Node 5935 Finally, two VPN network accesses are created using the same physical 5936 port ('port-id'=1/1/1). Each 'vpn-network-access' has a particular 5937 VLAN (1,2) to differentiate the traffic between: Sync and data 5938 (Figure 34). 5940 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ 5941 vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44 5942 content-type: application/yang-data+json 5944 { 5945 "ietf-l3vpn-ntw:vpn-network-accesses": { 5946 "vpn-network-access": [ 5947 { 5948 "id": "1/1/1.1", 5949 "port-id": "1/1/1", 5950 "description": "Interface SYNC to eNODE-B", 5951 "vpn-network-access-type": "vpn-common:point-to-point", 5952 "vpn-instance-profile": "simple-profile", 5953 "status": { 5954 "admin-status": { 5955 "status": "vpn-common:admin-state-up" 5956 } 5957 }, 5958 "connection": { 5959 "encapsulation": { 5960 "type": "dot1q", 5961 "dot1q": { 5962 "cvlan-id": 1 5963 } 5964 } 5965 }, 5966 "ip-connection": { 5967 "ipv4": { 5968 "local-address": "192.0.2.1", 5969 "prefix-length": 30, 5970 "address-allocation-type": "static-address", 5971 "static-addresses": { 5972 "primary-address": "1", 5973 "address": [ 5974 { 5975 "address-id": "1", 5976 "customer-address": "192.0.2.2" 5977 } 5978 ] 5979 } 5980 }, 5981 "ipv6": { 5982 "local-address": "2001:db8::1", 5983 "prefix-length": 64, 5984 "address-allocation-type": "ietf-l3vpn-ntw:static-address", 5985 "primary-address": "1", 5986 "address": [ 5987 { 5988 "address-id": "1", 5989 "customer-address": "2001:db8::2" 5990 } 5991 ] 5992 } 5993 }, 5994 "routing-protocols": { 5995 "routing-protocol": [ 5996 { 5997 "id": "1", 5998 "type": "vpn-common:direct" 5999 } 6000 ] 6001 } 6002 }, 6003 { 6004 "id": "1/1/1.2", 6005 "port-id": "1/1/1", 6006 "description": "Interface DATA to eNODE-B", 6007 "vpn-network-access-type": "vpn-common:point-to-point", 6008 "vpn-instance-profile": "simple-profile", 6009 "status": { 6010 "admin-status": { 6011 "status": "vpn-common:admin-state-up" 6012 } 6013 }, 6014 "connection": { 6015 "encapsulation": { 6016 "type": "dot1q", 6017 "dot1q": { 6018 "cvlan-id": 2 6019 } 6020 } 6021 }, 6022 "ip-connection": { 6023 "ipv4": { 6024 "local-address": "192.0.2.1", 6025 "prefix-length": 30, 6026 "address-allocation-type": "static-address", 6027 "static-addresses": { 6028 "primary-address": "1", 6029 "address": [ 6030 { 6031 "address-id": "1", 6032 "customer-address": "192.0.2.2" 6033 } 6034 ] 6035 } 6036 }, 6037 "ipv6": { 6038 "local-address": "2001:db8::1", 6039 "prefix-length": 64, 6040 "address-allocation-type": "ietf-l3vpn-ntw:static-address", 6041 "primary-address": "1", 6042 "address": [ 6043 { 6044 "address-id": "1", 6045 "customer-address": "2001:db8::2" 6046 } 6047 ] 6048 } 6049 }, 6050 "routing-protocols": { 6051 "routing-protocol": [ 6052 { 6053 "id": "1", 6054 "type": "vpn-common:direct" 6055 } 6056 ] 6057 } 6058 } 6059 ] 6060 } 6061 } 6063 Figure 34: Create VPN Network Access 6065 A.2. Loopback Interface 6067 An example of loopback interface is depicted in Figure 35. 6069 { 6070 "ietf-l3vpn-ntw:vpn-network-accesses": { 6071 "vpn-network-access": [ 6072 { 6073 "id": "vpn-access-loopback", 6074 "port-id": "Loopback1", 6075 "description": "An example of loopback interface.", 6076 "vpn-network-access-type": "vpn-common:loopback", 6077 "status": { 6078 "admin-status": { 6079 "status": "vpn-common:admin-state-up" 6080 } 6081 }, 6082 "ip-connection": { 6083 "ipv6": { 6084 "local-address": "2001:db8::4", 6085 "prefix-length": 128 6086 } 6087 } 6088 } 6089 ] 6090 } 6091 } 6093 Figure 35: VPN Network Access with a Loopback Interface (Message 6094 Body) 6096 A.3. Multicast VPN Provisioning Example 6098 IPTV is mainly distributed through multicast over the LANs. In the 6099 following example, PIM-SM is enabled and functional between the PE 6100 and the CE. The PE receives multicast traffic from a CE that is 6101 directly connected to the multicast source. The signaling between PE 6102 and CE is achieved using BGP. Also, RP is statically configured for 6103 a multicast group. 6105 +-----------+ +------+ +------+ +-----------+ 6106 | Multicast |---| CE |--/--| PE |----| Backbone | 6107 | source | +------+ +------+ | IP/MPLS | 6108 +-----------+ +-----------+ 6110 Figure 36: Multicast L3VPN Service Example 6112 An example is provided below to ilustrate how to configure a 6113 multicast L3VPN service using the L3NM. 6115 First, the multicast service is created together with a generic VPN 6116 instance profile (see the excerpt of the request message body shown 6117 in Figure 37) 6118 { 6119 "ietf-l3vpn-ntw:vpn-services": { 6120 "vpn-service": [ 6121 { 6122 "vpn-id": "Multicast-IPTV", 6123 "vpn-description": "Multicast IPTV VPN service", 6124 "customer-name": "a-name", 6125 "vpn-service-topology": "vpn-common:hub-spoke", 6126 "vpn-instance-profiles": { 6127 "vpn-instance-profile": [ 6128 { 6129 "profile-id": "multicast", 6130 "role": "ietf-vpn-common:hub-role", 6131 "local-autonomous-system": 65536, 6132 "multicast": { 6133 "rp": { 6134 "rp-group-mappings": { 6135 "rp-group-mapping": [ 6136 { 6137 "id": "1", 6138 "rp-address": "203.0.113.17", 6139 "groups": { 6140 "group": [ 6141 { 6142 "id": "1", 6143 "group-address": "239.130.0.0/15" 6144 } 6145 ] 6146 } 6147 } 6148 ] 6149 }, 6150 "rp-discovery": { 6151 "rp-discovery-type": "vpn-common:static-rp" 6152 } 6153 } 6154 } 6155 } 6156 ] 6157 } 6158 } 6159 ] 6160 } 6161 } 6163 Figure 37: Create Multicast VPN Service (Excerpt of the Message 6164 Request Body) 6166 Then, the VPN nodes are created (see the excerpt of the request 6167 message body shown in Figure 38). In this example, the VPN node will 6168 represent VRF configured in the physical device. 6170 { 6171 "ietf-l3vpn-ntw:vpn-node": [ 6172 { 6173 "vpn-node-id": "500003105", 6174 "description": "VRF-IPTV-MULTICAST", 6175 "ne-id": "198.51.100.10", 6176 "router-id": "198.51.100.10", 6177 "active-vpn-instance-profiles": { 6178 "vpn-instance-profile": [ 6179 { 6180 "profile-id": "multicast", 6181 "rd": "65536:31050202" 6182 } 6183 ] 6184 } 6185 } 6186 ] 6187 } 6189 Figure 38: Create Multicast VPN Node (Excerpt of the Message Request 6190 Body) 6192 Finally, create the VPN network access with multicast enabled (see 6193 the excerpt of the request message body shown in Figure 39). 6195 { 6196 "ietf-l3vpn-ntw:vpn-network-access": { 6197 "id": "1/1/1", 6198 "description": "Connected-to-source", 6199 "vpn-network-access-type": "vpn-common:point-to-point", 6200 "vpn-instance-profile": "multicast", 6201 "status": { 6202 "admin-status": { 6203 "status": "vpn-common:admin-state-up" 6204 }, 6205 "ip-connection": { 6206 "ipv4": { 6207 "local-address": "203.0.113.1", 6208 "prefix-length": 30, 6209 "address-allocation-type": "static-address", 6210 "static-addresses": { 6211 "primary-address": "1", 6212 "address": [ 6213 { 6214 "address-id": "1", 6215 "customer-address": "203.0.113.2" 6216 } 6217 ] 6218 } 6219 } 6220 }, 6221 "routing-protocols": { 6222 "routing-protocol": [ 6223 { 6224 "id": "1", 6225 "type": "vpn-common:bgp", 6226 "bgp": { 6227 "description": "Connected to CE", 6228 "peer-autonomous-system": "65537", 6229 "address-family": "vpn-common:ipv4", 6230 "neighbor": "203.0.113.2" 6231 } 6232 } 6233 ] 6234 }, 6235 "service": { 6236 "input-bandwidth": "100000000", 6237 "output-bandwidth": "100000000", 6238 "mtu": 1500, 6239 "multicast": { 6240 "access-type": "source-only", 6241 "address-family": "vpn-common:ipv4", 6242 "protocol-type": "router", 6243 "pim": { 6244 "hello-interval": 30, 6245 "status": { 6246 "admin-status": { 6247 "status": "vpn-common:admin-state-up" 6248 } 6249 } 6250 } 6251 } 6252 } 6253 } 6254 } 6255 } 6257 Figure 39: Create VPN Network Access (Excerpt of the Message Request 6258 Body) 6260 Appendix B. Implementation Status 6262 This section records the status of known implementations of the YANG 6263 module defined by this specification at the time of posting of this 6264 document and is based on a proposal described in [RFC7942]. The 6265 description of implementations in this section is intended to assist 6266 the IETF in its decision processes in progressing drafts to RFCs. 6267 Please note that the listing of any individual implementation here 6268 does not imply endorsement by the IETF. Furthermore, no effort has 6269 been spent to verify the information presented here that was supplied 6270 by IETF contributors. This is not intended as, and must not be 6271 construed to be, a catalog of available implementations or their 6272 features. Readers are advised to note that other implementations may 6273 exist. 6275 According to [RFC7942], "this will allow reviewers and working groups 6276 to assign due consideration to documents that have the benefit of 6277 running code, which may serve as evidence of valuable experimentation 6278 and feedback that have made the implemented protocols more mature. 6279 It is up to the individual working groups to use this information as 6280 they see fit". 6282 Note to the RFC Editor: As per [RFC7942] guidelines, please remove 6283 this Implementation Status apendix prior publication. 6285 B.1. Nokia Implementation 6287 Details can be found at: https://github.com/IETF-OPSAWG- 6288 WG/l3nm/blob/master/Implementattion/Nokia.txt 6290 B.2. Huawei Implementation 6292 Details can be found at: https://github.com/IETF-OPSAWG- 6293 WG/l3nm/blob/master/Implementattion/Huawei.txt 6295 B.3. Infinera Implementation 6297 Details can be found at: https://github.com/IETF-OPSAWG- 6298 WG/l3nm/blob/master/Implementattion/Infinera.txt 6300 B.4. Ribbon-ECI Implementation 6302 Details can be found at: https://github.com/IETF-OPSAWG- 6303 WG/l3nm/blob/master/Implementattion/Ribbon-ECI.txt 6305 Acknowledgements 6307 During the discussions of this work, helpful comments, suggestions, 6308 and reviews were received from (listed alphabetically): Raul Arco, 6309 Miguel Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque 6310 Gagliano, Christian Jacquenet, Kireeti Kompella, Julian Lucek, and 6311 Tom Petch. Many thanks to them. Thanks to Philip Eardly for the 6312 review of an early version of the document. 6314 Daniel King, Daniel Voyer, Luay Jalil, and Stephane Litkowski 6315 contributed to early version of the individual submission. 6317 This work was supported in part by the European Commission funded 6318 H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727) and Horizon 2020 6319 Secured autonomic traffic management for a Tera of SDN flows 6320 (Teraflow) project (G.A. 101015857). 6322 Contributors 6324 Victor Lopez 6325 Telefonica 6326 Email: victor.lopezalvarez@telefonica.com 6328 Qin Wu 6329 Huawei 6330 Email: bill.wu@huawei.com> 6332 Manuel Julian 6333 Vodafone 6334 Email: manuel-julian.lopez@vodafone.com 6336 Lucia Oliva Ballega 6337 Telefonica 6338 Email: lucia.olivaballega.ext@telefonica.com 6340 Erez Segev 6341 ECI Telecom 6342 Email: erez.segev@ecitele.com> 6344 Paul Sherratt 6345 Gamma Telecom 6346 Email: paul.sherratt@gamma.co.uk 6348 Authors' Addresses 6349 Samier Barguil 6350 Telefonica 6351 Madrid 6352 ES 6354 Email: samier.barguilgiraldo.ext@telefonica.com 6356 Oscar Gonzalez de Dios (editor) 6357 Telefonica 6358 Madrid 6359 ES 6361 Email: oscar.gonzalezdedios@telefonica.com 6363 Mohamed Boucadair (editor) 6364 Orange 6365 Rennes 35000 6366 France 6368 Email: mohamed.boucadair@orange.com 6370 Luis Angel Munoz 6371 Vodafone 6372 ES 6374 Email: luis-angel.munoz@vodafone.com 6376 Alejandro Aguado 6377 Nokia 6378 Madrid 6379 ES 6381 Email: alejandro.aguado_martin@nokia.com