idnits 2.17.1 draft-ietf-opsawg-l3sm-l3nm-10.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 10 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 (July 13, 2021) is 1015 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 -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG S. Barguil 3 Internet-Draft O. Gonzalez de Dios, Ed. 4 Intended status: Standards Track Telefonica 5 Expires: January 14, 2022 M. Boucadair, Ed. 6 Orange 7 L. Munoz 8 Vodafone 9 A. Aguado 10 Nokia 11 July 13, 2021 13 A Layer 3 VPN Network YANG Model 14 draft-ietf-opsawg-l3sm-l3nm-10 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 January 14, 2022. 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 . . . . . . . . . . . . . . . . . . . 115 103 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 117 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 117 105 11.1. Normative References . . . . . . . . . . . . . . . . . . 117 106 11.2. Informative References . . . . . . . . . . . . . . . . . 121 107 Appendix A. L3VPN Examples . . . . . . . . . . . . . . . . . . . 125 108 A.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 125 109 A.2. Loopback Interface . . . . . . . . . . . . . . . . . . . 130 110 A.3. Multicast VPN Provisioning Example . . . . . . . . . . . 130 111 Appendix B. Implementation Status . . . . . . . . . . . . . . . 135 112 B.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 135 113 B.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 135 114 B.3. Infinera Implementation . . . . . . . . . . . . . . . . . 135 115 B.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 135 116 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 136 117 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 136 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 a model focuses 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 information captured in the L3SM can be passed by the 153 orchestrator in the L3NM (e.g., customer) or be used to feed some 154 L3NM attributes (e.g., actual forwarding policies). Also, some 155 information captured in the 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 information captured and exposed using the L3NM can feed the 159 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 The 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 for 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 Service Delivery 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, but some manual 499 intervention will still be 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, of 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 (e.g., the network controller). The subtree of 656 the '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-change? yang:date-and-time 674 | +--ro oper-status 675 | +--ro status? identityref 676 | +--ro last-change? 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 may be an indication that network provision actions 740 are 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 925 pointing to an abstract node. In this case, the network controller 926 will 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-change? yang:date-and-time 968 | +--ro oper-status 969 | +--ro status? identityref 970 | +--ro last-change? 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-change? yang:date-and-time 978 | +--ro oper-status 979 | +--ro status? identityref 980 | +--ro last-change? 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 except 'router-id'. Indeed, Router IDs can be 1010 configured per address family. This capability can be used, for 1011 example, to configure an IPv6 address as a Router ID when such 1012 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 the 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 interface-id? string 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-change? yang:date-and-time 1069 | +--ro oper-status 1070 | +--ro status? identityref 1071 | +--ro last-change? 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 'interface-id': Indicates the physical or logical interface on which 1093 the VPN network access is 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 multipoint connection between the 1108 customer site and the PEs. The controller must keep the 1109 association between a logical or physical interface on the 1110 device with the 'id' of 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 inherited data nodes 1127 (e.g., multicast) can be refined at the VPN network access level. 1128 In such case, refined values take precedence over inherited ones. 1130 'status': Indicates both operational and administrative status of a 1131 VPN network access. 1133 'connection': Represents and groups the set of Layer 2 connectivity 1134 from where the traffic of the L3VPN in a particular VPN Network 1135 access is coming. See Section 7.6.1. 1137 'ip-connection': Contains Layer 3 connectivity information of a VPN 1138 network access (e.g., IP addressing). See Section 7.6.2. 1140 'routing-protocols': Includes the CE-PE routing configuration 1141 information. See Section 7.6.3. 1143 'oam': Specifies the Operations, Administration, and Maintenance 1144 (OAM) mechanisms used for a VPN network access. See 1145 Section 7.6.4. 1147 'security': Specifies the authentication and the encryption to be 1148 applied for a given VPN network access. See Section 7.6.5. 1150 'service': Specifies the service parameters (e.g., QoS, multicast) 1151 to apply for a given VPN network access. See Section 7.6.6. 1153 7.6.1. Connection 1155 The 'connection' container represents the layer 2 connectivity to the 1156 L3VPN for a particular VPN network access. As shown in the tree 1157 depicted in Figure 9, the 'connection' container defines protocols 1158 and parameters to enable such connectivity at layer 2. 1160 The traffic can enter the VPN with or without encapsulation (e.g., 1161 VLAN, QinQ). The 'encapsulation' container specifies the layer 2 1162 encapsulation to use (if any) and allows to configure the relevant 1163 tags. 1165 The interface that is attached to the L3VPN is identified by the 1166 'interface-id' at the 'vpn-network-access' level. From a network 1167 model perspective, it is expected that the 'interface-id' is 1168 sufficient to identify the interface. However, specific layer 2 sub- 1169 interfaces may be required to be configured in some implementations/ 1170 deployments. Such a layer 2 specific interface can be included in 1171 'l2-termination-point'. 1173 If a layer 2 tunnel is needed to terminate the service in the CE-PE 1174 connection, the 'l2-tunnel-service' container is used to specify the 1175 required parameters to set such tunneling service (e.g., VPLS, 1176 VXLAN). An identity, called 'l2-tunnel-type', is defined for layer 2 1177 tunnel selection. The container can also identify the pseudowire 1178 (Section 5.2 of [RFC4447]). 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? string 1228 | +--rw local-bridge-reference? string 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 other than the 1241 one indicated under the 'connection' container may be needed to 1242 terminate the layer 3 service. The identifier of such interface is 1243 included in 'l3-termination-point'. For example, this data node can 1244 be used to 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? string 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? string 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? string 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? string 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 protocols are 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 routing instance is indicated in 'type'. 1431 The values of these 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 handled at the device configuration level. Local 1454 policies of a service provider (e.g., filtering) are implemented as 1455 part of the device configuration; these are not captured in the L3NM, 1456 but the model allows local profiles to be associated 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-change? yang:date-and-time 1506 | | | +--ro oper-status 1507 | | | +--ro status? identityref 1508 | | | +--ro last-change? 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-change? yang:date-and-time 1522 | | +--ro oper-status 1523 | | +--ro status? identityref 1524 | | +--ro last-change? 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 the configuration of a BGP neighbor, including 1532 a set for parameters that are pertinent to be tweaked at the 1533 network 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 is required, other than the one configured at the 1547 VPN node level. 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 the 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 'authentication': The module adheres to the recommendations in 1621 Section 13.2 of [RFC4364] as it allows enabling 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 authentication 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-change? yang:date-and-time 1676 | | +--ro oper-status 1677 | | +--ro status? identityref 1678 | | +--ro last-change? 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 'authentication': Controls the authentication schemes to be 1706 enabled for the OSPF instance. The following options are 1707 supported: IPsec for OSPFv3 authentication [RFC4552], 1708 authentication trailer for OSPFv2 [RFC5709] [RFC7474] and 1709 OSPFv3 [RFC7166]. 1711 'status': Indicates the status of the OSPF routing instance. 1713 ... 1714 +--rw routing-protocols 1715 | +--rw routing-protocol* [id] 1716 | ... 1717 | +--rw ospf {vpn-common:rtg-ospf}? 1718 | | +--rw address-family? identityref 1719 | | +--rw area-id yang:dotted-quad 1720 | | +--rw metric? uint16 1721 | | +--rw sham-links {vpn-common:rtg-ospf-sham-link}? 1722 | | | +--rw sham-link* [target-site] 1723 | | | +--rw target-site 1724 | | | | vpn-common:vpn-id 1725 | | | +--rw metric? uint16 1726 | | +--rw max-lsa? uint32 1727 | | +--rw authentication 1728 | | | +--rw enable? boolean 1729 | | | +--rw keying-material 1730 | | | +--rw (option)? 1731 | | | +--:(md5) 1732 | | | | +--rw md5-keychain? 1733 | | | | kc:key-chain-ref 1734 | | | +--:(ipsec) 1735 | | | +--rw sa? string 1736 | | +--rw status 1737 | | +--rw admin-status 1738 | | | +--rw status? identityref 1739 | | | +--rw last-change? yang:date-and-time 1740 | | +--ro oper-status 1741 | | +--ro status? identityref 1742 | | +--ro last-change? yang:date-and-time 1743 ... 1745 Figure 17: OPSF Routing Subtree Structure 1747 IS-IS: The model (Figure 18) allows the user to configure IS-IS 1748 [ISO10589][RFC1195][RFC5308] to run on the 'vpn-network-access' 1749 interface. The following IS-IS data nodes are supported: 1751 'address-family': Indicates whether IPv4, IPv6, or both address 1752 families are to be activated. 1754 'area-address': Indicates the IS-IS area address. 1756 'level': Indicates the IS-IS level: Level 1, Level 2, or both. 1758 'metric': Associates a metric with IS-IS routes. 1760 'mode': Indicates the IS-IS interface mode type. It can be set 1761 to 'active' (that is, send or receive IS-IS protocol control 1762 packets) or 'passive' (that is, suppress the sending of IS-IS 1763 updates through the interface). 1765 'authentication': Controls the authentication schemes to be 1766 enabled for the IS-IS instance. Both the specification of a 1767 key-chain [RFC8177] and the direct specification of key and 1768 authentication algorithm are supported. 1770 'status': Indicates the status of the OSPF routing instance. 1772 ... 1773 +--rw routing-protocols 1774 | +--rw routing-protocol* [id] 1775 | ... 1776 | +--rw isis {vpn-common:rtg-isis}? 1777 | | +--rw address-family? identityref 1778 | | +--rw area-address area-address 1779 | | +--rw level? identityref 1780 | | +--rw metric? uint16 1781 | | +--rw mode? enumeration 1782 | | +--rw authentication 1783 | | | +--rw enable? boolean 1784 | | | +--rw keying-material 1785 | | | +--rw (option)? 1786 | | | +--:(auth-key-chain) 1787 | | | | +--rw key-chain? 1788 | | | | key-chain:key-chain-ref 1789 | | | +--:(auth-key-explicit) 1790 | | | +--rw key-id? uint32 1791 | | | +--rw key? string 1792 | | | +--rw crypto-algorithm? identityref 1793 | | +--rw status 1794 | | +--rw admin-status 1795 | | | +--rw status? identityref 1796 | | | +--rw last-change? yang:date-and-time 1797 | | +--ro oper-status 1798 | | +--ro status? identityref 1799 | | +--ro last-change? yang:date-and-time 1800 ... 1802 Figure 18: IS-IS Routing Subtree Structure 1804 RIP: The model allows the user to configure RIP to run on the 'vpn- 1805 network-access' interface. As shown in Figure 19, the following 1806 RIP data nodes are supported: 1808 'address-family': Indicates whether IPv4, IPv6, or both address 1809 families are to be activated. This parameter is used to 1810 determine whether RIPv2 [RFC2453] and/or RIPng are to be 1811 enabled [RFC2080]. 1813 'timers': Indicates the following timers: 1815 'update-interval': Is the interval at which RIP updates are 1816 sent. 1818 'invalid-interval': Is the interval before a RIP route is 1819 declared invalid. 1821 'holddown-interval': Is the interval before better RIP routes 1822 are released. 1824 'flush-interval': Is the interval before a route is removed 1825 from the routing table. 1827 'default-metric': Sets the default RIP metric. 1829 'authentication': Controls the authentication schemes to be 1830 enabled for the RIP instance. 1832 'status': Indicates the status of the RIP routing instance. 1834 ... 1835 +--rw routing-protocols 1836 | +--rw routing-protocol* [id] 1837 | ... 1838 | +--rw rip {vpn-common:rtg-rip}? 1839 | | +--rw address-family? identityref 1840 | | +--rw timers 1841 | | | +--rw update-interval? uint16 1842 | | | +--rw invalid-interval? uint16 1843 | | | +--rw holddown-interval? uint16 1844 | | | +--rw flush-interval? uint16 1845 | | +--rw neighbor* inet:ip-address 1846 | | +--rw default-metric? uint8 1847 | | +--rw authentication 1848 | | | +--rw enable? boolean 1849 | | | +--rw keying-material 1850 | | | +--rw (option)? 1851 | | | +--:(auth-key-chain) 1852 | | | | +--rw key-chain? 1853 | | | | key-chain:key-chain-ref 1854 | | | +--:(auth-key-explicit) 1855 | | | +--rw key? string 1856 | | | +--rw crypto-algorithm? identityref 1857 | | +--rw status 1858 | | +--rw admin-status 1859 | | | +--rw status? identityref 1860 | | | +--rw last-change? yang:date-and-time 1861 | | +--ro oper-status 1862 | | +--ro status? identityref 1863 | | +--ro last-change? yang:date-and-time 1864 ... 1866 Figure 19: RIP Subtree Structure 1868 VRRP: The model (Figure 20) allows enabling VRRP on the 'vpn- 1869 network-access' interface. The following data nodes are 1870 supported: 1872 'address-family': Indicates whether IPv4, IPv6, or both address 1873 families are to be activated. Note that VRRP version 3 1874 [RFC5798] supports both IPv4 and IPv6. 1876 'vrrp-group': Is used to identify the VRRP group. 1878 'backup-peer': Carries the IP address of the peer. 1880 'virtual-ip-address': Includes virtual IP addresses for a single 1881 VRRP group. 1883 'priority': Assigns the VRRP election priority for the backup 1884 virtual router. 1886 'ping-reply': Controls whether ping requests can be replied to. 1888 'status': Indicates the status of the VRRP instance. 1890 Note that no authentication data node is included for VRRP as 1891 there isn't currently any type of VRRP authentication (see 1892 Section 9 of [RFC5798]). 1894 ... 1895 +--rw routing-protocols 1896 | +--rw routing-protocol* [id] 1897 | ... 1898 | +--rw vrrp {vpn-common:rtg-vrrp}? 1899 | +--rw address-family* identityref 1900 | +--rw vrrp-group? uint8 1901 | +--rw backup-peer? inet:ip-address 1902 | +--rw virtual-ip-address* inet:ip-address 1903 | +--rw priority? uint8 1904 | +--rw ping-reply? boolean 1905 | +--rw status 1906 | +--rw admin-status 1907 | | +--rw status? identityref 1908 | | +--rw last-change? yang:date-and-time 1909 | +--ro oper-status 1910 | +--ro status? identityref 1911 | +--ro last-change? yang:date-and-time 1912 ... 1914 Figure 20: VRRP Subtree Structure 1916 7.6.4. OAM 1918 This container (Figure 21) defines the Operations, Administration, 1919 and Maintenance (OAM) mechanisms used for a VPN network access. In 1920 the current version of the L3NM, only BFD is supported. The current 1921 data nodes can be specified: 1923 'desired-min-tx-interval': Is the minimum interval, in microseconds, 1924 that a PE would like to use when transmitting BFD Control packets 1925 less any jitter applied. 1927 'required-min-rx-interval': Is the minimum interval, in 1928 microseconds, between received BFD Control packets that a PE is 1929 capable of supporting, less any jitter applied by the sender. 1931 'detection-multiplier': The negotiated transmit interval, multiplied 1932 by this value, provides the detection time for the PE. 1934 'holdtime': Is used to indicate the expected BFD holddown time. The 1935 value can be set by the customer or selected from a profile. 1937 'authentication': Includes the required information to enable the 1938 BFD authentication modes discussed in Section 6.7 of [RFC5880]. 1939 In particular 'meticulous' controls the activation of the 1940 meticulous mode discussed in Sections 6.7.3 and 6.7.4 of 1941 [RFC5880]. 1943 'status': Indicates the status of BFD. 1945 ... 1946 +--rw oam 1947 | +--rw bfd {vpn-common:bfd}? 1948 | +--rw desired-min-tx-interval? uint32 1949 | +--rw required-min-rx-interval? uint32 1950 | +--rw detection-multiplier? uint8 1951 | +--rw (holdtime)? 1952 | | +--:(fixed) 1953 | | | +--rw fixed-value? uint32 1954 | | +--:(profile) 1955 | | | +--rw profile-name? leafref 1956 | +--rw authentication! 1957 | | +--rw key-chain? key-chain:key-chain-ref 1958 | | +--rw meticulous? boolean 1959 | +--rw status 1960 | +--rw admin-status 1961 | | +--rw status? identityref 1962 | | +--rw last-change? yang:date-and-time 1963 | +--ro oper-status 1964 | +--ro status? identityref 1965 | +--ro last-change? yang:date-and-time 1966 ... 1968 Figure 21: IP Connection Subtree Structure (OAM) 1970 7.6.5. Security 1972 The 'security' container specifies the authentication and the 1973 encryption to be applied for a given VPN network access traffic. As 1974 depicted in the subtree shown in Figure 22, the L3NM can be used to 1975 directly control the encryption to put in place (e.g., Layer 2 or 1976 Layer 3 encryption) or invoke a local encryption profile. 1978 ... 1979 +--rw vpn-services 1980 +--rw vpn-service* [vpn-id] 1981 ... 1982 +--rw vpn-nodes 1983 +--rw vpn-node* [vpn-node-id] 1984 ... 1985 +--rw vpn-network-accesses 1986 +--rw vpn-network-access* [id] 1987 ... 1988 +--rw security 1989 | +--rw encryption {vpn-common:encryption}? 1990 | | +--rw enabled? boolean 1991 | | +--rw layer? enumeration 1992 | +--rw encryption-profile 1993 | +--rw (profile)? 1994 | +--:(provider-profile) 1995 | | +--rw profile-name? leafref 1996 | +--:(customer-profile) 1997 | +--rw customer-key-chain? 1998 | kc:key-chain-ref 1999 +--rw service 2000 ... 2002 Figure 22: Security Subtree Structure 2004 7.6.6. Services 2006 The 'service' container specifies the service parameters to apply for 2007 a given VPN network access (Figure 23). 2009 ... 2010 +--rw vpn-network-accesses 2011 +--rw vpn-network-access* [id] 2012 ... 2013 +--rw service 2014 +--rw inbound-bandwidth? uint64 {vpn-common:inbound-bw}? 2015 +--rw outbound-bandwidth? uint64 {vpn-common:outbound-bw}? 2016 +--rw mtu? uint16 2017 +--rw qos {vpn-common:qos}? 2018 | ... 2019 +--rw carriers-carrier 2020 | {vpn-common:carriers-carrier}? 2021 | +--rw signaling-type? enumeration 2022 +--rw ntp 2023 | +--rw broadcast? enumeration 2024 | +--rw auth-profile 2025 | | +--rw profile-id? string 2026 | +--rw status 2027 | +--rw admin-status 2028 | | +--rw status? identityref 2029 | | +--rw last-change? yang:date-and-time 2030 | +--ro oper-status 2031 | +--ro status? identityref 2032 | +--ro last-change? yang:date-and-time 2033 +--rw multicast {vpn-common:multicast}? 2034 ... 2036 Figure 23: Services Subtree Structure 2038 The following data nodes are defined: 2040 'inbound-bandwidth': Indicates the inbound bandwidth of the 2041 connection (i.e., download bandwidth from the service provider to 2042 the site). 2044 'outbound-bandwidth': Indicates the outbound bandwidth of the 2045 connection (i.e., upload bandwidth from the site to the service 2046 provider). 2048 'mtu': Indicates the MTU at the service level. 2050 'qos': Is used to define a set of QoS policies to apply on a given 2051 connection (Figure 24). A QoS policy may be a classification or 2052 an action policy. For example, a QoS action can be defined to 2053 rate limit inbound/outbound traffic of a given class of service. 2055 ... 2056 +--rw qos {vpn-common:qos}? 2057 | +--rw qos-classification-policy 2058 | | +--rw rule* [id] 2059 | | +--rw id string 2060 | | +--rw (match-type)? 2061 | | | +--:(match-flow) 2062 | | | | +--rw (l3)? 2063 | | | | | +--:(ipv4) 2064 | | | | | | ... 2065 | | | | | +--:(ipv6) 2066 | | | | | ... 2067 | | | | +--rw (l4)? 2068 | | | | +--:(tcp) 2069 | | | | | ... 2070 | | | | +--:(udp) 2071 | | | | ... 2072 | | | +--:(match-application) 2073 | | | +--rw match-application? 2074 | | | identityref 2075 | | +--rw target-class-id? 2076 | | string 2077 | +--rw qos-action 2078 | | +--rw rule* [id] 2079 | | +--rw id string 2080 | | +--rw target-class-id? string 2081 | | +--rw inbound-rate-limit? decimal64 2082 | | +--rw outbound-rate-limit? decimal64 2083 | +--rw qos-profile 2084 | +--rw qos-profile* [profile] 2085 | +--rw profile leafref 2086 | +--rw direction? identityref 2087 ... 2089 Figure 24: Services Subtree Structure 2091 QoS classification can be based on many criteria such as: 2093 Layer 3: As shown in Figure 25, classification can be based on 2094 any IP header field or a combination thereof. Both IPv4 and 2095 IPv6 are supported. 2097 +--rw qos {vpn-common:qos}? 2098 | +--rw qos-classification-policy 2099 | | +--rw rule* [id] 2100 | | +--rw id string 2101 | | +--rw (match-type)? 2102 | | | +--:(match-flow) 2103 | | | | +--rw (l3)? 2104 | | | | | +--:(ipv4) 2105 | | | | | | +--rw ipv4 2106 | | | | | | +--rw dscp? inet:dscp 2107 | | | | | | +--rw ecn? uint8 2108 | | | | | | +--rw length? uint16 2109 | | | | | | +--rw ttl? uint8 2110 | | | | | | +--rw protocol? uint8 2111 | | | | | | +--rw ihl? uint8 2112 | | | | | | +--rw flags? bits 2113 | | | | | | +--rw offset? uint16 2114 | | | | | | +--rw identification? uint16 2115 | | | | | | +--rw (destination-network)? 2116 | | | | | | | +--:(destination-ipv4-network) 2117 | | | | | | | +--rw destination-ipv4-network? 2118 | | | | | | | inet:ipv4-prefix 2119 | | | | | | +--rw (source-network)? 2120 | | | | | | +--:(source-ipv4-network) 2121 | | | | | | +--rw source-ipv4-network? 2122 | | | | | | inet:ipv4-prefix 2123 | | | | | +--:(ipv6) 2124 | | | | | +--rw ipv6 2125 | | | | | +--rw dscp? inet:dscp 2126 | | | | | +--rw ecn? uint8 2127 | | | | | +--rw length? uint16 2128 | | | | | +--rw ttl? uint8 2129 | | | | | +--rw protocol? uint8 2130 | | | | | +--rw (destination-network)? 2131 | | | | | | +--:(destination-ipv6-network) 2132 | | | | | | +--rw destination-ipv6-network? 2133 | | | | | | inet:ipv6-prefix 2134 | | | | | +--rw (source-network)? 2135 | | | | | | +--:(source-ipv6-network) 2136 | | | | | | +--rw source-ipv6-network? 2137 | | | | | | inet:ipv6-prefix 2138 | | | | | +--rw flow-label? 2139 | | | | | inet:ipv6-flow-label 2140 ... 2142 Figure 25: QoS Subtree Structure (L3) 2144 Layer 4: As discussed in [I-D.ietf-opsawg-vpn-common], any layer 2145 4 protocol can be indicated in the 'protocol' data node under 2146 'l3' (Figure 25), but only TCP and UDP specific match criteria 2147 are elaborated in this version as these protocols are widely 2148 used in the context of VPN services. Augmentations can be 2149 considered in the future to add other Layer 4 specific data 2150 nodes, if needed. 2152 TCP or UDP-related match criteria can be specified in the L3NM 2153 as shown in Figure 26. 2155 +--rw qos {vpn-common:qos}? 2156 | +--rw qos-classification-policy 2157 | | +--rw rule* [id] 2158 | | +--rw id string 2159 | | +--rw (match-type)? 2160 | | | +--:(match-flow) 2161 | | | | +--rw (l3)? 2162 | | | | | ... 2163 | | | | +--rw (l4)? 2164 | | | | +--:(tcp) 2165 | | | | | +--rw tcp 2166 | | | | | +--rw sequence-number? uint32 2167 | | | | | +--rw acknowledgement-number? uint32 2168 | | | | | +--rw data-offset? uint8 2169 | | | | | +--rw reserved? uint8 2170 | | | | | +--rw flags? bits 2171 | | | | | +--rw window-size? uint16 2172 | | | | | +--rw urgent-pointer? uint16 2173 | | | | | +--rw options? binary 2174 | | | | | +--rw (source-port)? 2175 | | | | | | +--:(source-port-range-or-operator) 2176 | | | | | | +--rw source-port-range-or-operator 2177 | | | | | | +--rw (port-range-or-operator)? 2178 | | | | | | +--:(range) 2179 | | | | | | | +--rw lower-port 2180 | | | | | | | | inet:port-number 2181 | | | | | | | +--rw upper-port 2182 | | | | | | | inet:port-number 2183 | | | | | | +--:(operator) 2184 | | | | | | +--rw operator? operator 2185 | | | | | | +--rw port 2186 | | | | | | inet:port-number 2187 | | | | | +--rw (destination-port)? 2188 | | | | +--:(destination-port-range-or-operator) 2189 | | | | | +--rw destination-port-range-or-operator 2190 | | | | | +--rw (port-range-or-operator)? 2191 | | | | | +--:(range) 2192 | | | | | | +--rw lower-port 2193 | | | | | | | inet:port-number 2194 | | | | | | +--rw upper-port 2195 | | | | | | inet:port-number 2196 | | | | | +--:(operator) 2197 | | | | | +--rw operator? operator 2198 | | | | | +--rw port 2199 | | | | | inet:port-number 2200 | | | | +--:(udp) 2201 | | | | +--rw udp 2202 | | | | +--rw length? uint16 2203 | | | | +--rw (source-port)? 2204 | | | | | +--:(source-port-range-or-operator) 2205 | | | | | +--rw source-port-range-or-operator 2206 | | | | | +--rw (port-range-or-operator)? 2207 | | | | | +--:(range) 2208 | | | | | | +--rw lower-port 2209 | | | | | | | inet:port-number 2210 | | | | | | +--rw upper-port 2211 | | | | | | inet:port-number 2212 | | | | | +--:(operator) 2213 | | | | | +--rw operator? operator 2214 | | | | | +--rw port 2215 | | | | | inet:port-number 2216 | | | | +--rw (destination-port)? 2217 | | | | +--:(destination-port-range-or-operator) 2218 | | | | +--rw destination-port-range-or-operator 2219 | | | | +--rw (port-range-or-operator)? 2220 | | | | +--:(range) 2221 | | | | | +--rw lower-port 2222 | | | | | | inet:port-number 2223 | | | | | +--rw upper-port 2224 | | | | | inet:port-number 2225 | | | | +--:(operator) 2226 | | | | +--rw operator? operator 2227 | | | | +--rw port 2228 | | | | inet:port-number 2229 ... 2231 Figure 26: QoS Subtree Structure (L4) 2233 Application match: Relies upon application-specific 2234 classification. 2236 'carrierscarrier': Groups a set of parameters that are used when 2237 Carriers' Carriers (CsC) is enabled such the use of BGP for 2238 signaling purposes [RFC8277]. 2240 'ntp': Time synchronization may be needed in some VPNs such as 2241 infrastructure and management VPNs. This container is used to 2242 enable the NTP service [RFC5905]. 2244 'multicast': Specifies the multicast mode and other data nodes such 2245 as the address-family. Refer to Section 7.7. 2247 7.7. Multicast 2249 Multicast may be enabled for a particular VPN at the VPN node and VPN 2250 network access levels (see Figure 27). Some data nodes (e.g., max- 2251 groups) can be controlled at various levels: VPN service, VPN node 2252 level, or VPN network access. 2254 ... 2255 +--rw vpn-services 2256 +--rw vpn-service* [vpn-id] 2257 ... 2258 +--rw vpn-instance-profiles 2259 | +--rw vpn-instance-profile* [profile-id] 2260 | .... 2261 | +--rw multicast {vpn-common:multicast}? 2262 | ... 2263 +--rw vpn-nodes 2264 +--rw vpn-node* [vpn-node-id] 2265 ... 2266 +--rw active-vpn-instance-profiles 2267 | +--rw vpn-instance-profile* [profile-id] 2268 | ... 2269 | +--rw multicast {vpn-common:multicast}? 2270 | ... 2271 +--rw vpn-network-accesses 2272 +--rw vpn-network-access* [id] 2273 ... 2274 +--rw service 2275 ... 2276 +--rw multicast {vpn-common:multicast}? 2277 ... 2279 Figure 27: Overall Multicast Subtree Structure 2281 Multicast-related data nodes at the VPN instance profile level has 2282 the structure that is shown in Figure 30. 2284 ... 2285 +--rw vpn-services 2286 +--rw vpn-service* [vpn-id] 2287 ... 2289 +--rw vpn-instance-profiles 2290 | +--rw vpn-instance-profile* [profile-id] 2291 | .... 2292 | +--rw multicast {vpn-common:multicast}? 2293 | +--rw tree-flavor* identityref 2294 | +--rw rp 2295 | | +--rw rp-group-mappings 2296 | | | +--rw rp-group-mapping* [id] 2297 | | | +--rw id uint16 2298 | | | +--rw provider-managed 2299 | | | | +--rw enabled? boolean 2300 | | | | +--rw rp-redundancy? boolean 2301 | | | | +--rw optimal-traffic-delivery? boolean 2302 | | | | +--rw anycast 2303 | | | | +--rw local-address? inet:ip-address 2304 | | | | +--rw rp-set-address* inet:ip-address 2305 | | | +--rw rp-address inet:ip-address 2306 | | | +--rw groups 2307 | | | +--rw group* [id] 2308 | | | +--rw id uint16 2309 | | | +--rw (group-format) 2310 | | | +--:(group-prefix) 2311 | | | | +--rw group-address? inet:ip-prefix 2312 | | | +--:(startend) 2313 | | | +--rw group-start? inet:ip-address 2314 | | | +--rw group-end? inet:ip-address 2315 | | +--rw rp-discovery 2316 | | +--rw rp-discovery-type? identityref 2317 | | +--rw bsr-candidates 2318 | | +--rw bsr-candidate-address* inet:ip-address 2319 | +--rw igmp {vpn-common:igmp and vpn-common:ipv4}? 2320 | | +--rw static-group* [group-addr] 2321 | | | +--rw group-addr 2322 | | | | rt-types:ipv4-multicast-group-address 2323 | | | +--rw source-addr? 2324 | | | rt-types:ipv4-multicast-source-address 2325 | | +--rw max-groups? uint32 2326 | | +--rw max-entries? uint32 2327 | | +--rw version? identityref 2328 | +--rw mld {vpn-common:mld and vpn-common:ipv6}? 2329 | | +--rw static-group* [group-addr] 2330 | | | +--rw group-addr 2331 | | | | rt-types:ipv6-multicast-group-address 2332 | | | +--rw source-addr? 2333 | | | rt-types:ipv6-multicast-source-address 2334 | | +--rw max-groups? uint32 2335 | | +--rw max-entries? uint32 2336 | | +--rw version? identityref 2337 | +--rw pim {vpn-common:pim}? 2338 | +--rw hello-interval? rt-types:timer-value-seconds16 2339 | +--rw dr-priority? uint32 2340 ... 2342 Figure 28: Multicast Subtree Structure (VPN Instance Profile Level) 2344 The model supports a single type of tree: Any-Source Multicast (ASM), 2345 Source-Specific Multicast (SSM), or bidirectional. 2347 When ASM is used, the model supports the configuration of rendez-vous 2348 points (RPs). RP discovery may be 'static', 'bsr-rp', or 'auto-rp'. 2349 When set to 'static', RP to multicast grouping mapping MUST be 2350 configured as part of the 'rp-group-mappings' container. The RP MAY 2351 be a provider node or a customer node. When the RP is a customer 2352 node, the RP address must be configured using the 'rp-address' leaf 2353 otherwise no RP address is needed. 2355 The model supports RP redundancy through the 'rp-redundancy' leaf. 2356 How the redundancy is achieved is out of scope and is up to the 2357 implementation. 2359 When a particular VPN using ASM requires a more optimal traffic 2360 delivery, 'optimal-traffic-delivery' can be set. When set to 'true', 2361 the implementation must use any mechanism to provide a more optimal 2362 traffic delivery for the customer. For example, anycast is one of 2363 the mechanisms to enhance RPs redundancy, resilience against 2364 failures, and to recover from failures quickly. 2366 The same structure as the one depicted in Figure 30 is used when 2367 configuring multicast-related parameters at the VPN node level. When 2368 defined at the VPN node level (Figure 29), Internet Group Management 2369 Protocol (IGMP) [RFC1112][RFC2236][RFC3376], Multicast Listener 2370 Discovery (MLD) [RFC2710][RFC3810], and Protocol Independent 2371 Multicast (PIM) [RFC7761] parameters are applicable to all VPN 2372 network accesses of that VPN node unless corresponding nodes are 2373 refined at the VPN network access level. 2375 ... 2376 +--rw vpn-nodes 2377 +--rw vpn-node* [vpn-node-id] 2378 ... 2379 +--rw active-vpn-instance-profiles 2380 | +--rw vpn-instance-profile* [profile-id] 2381 | ... 2382 | +--rw multicast {vpn-common:multicast}? 2383 | +--rw tree-flavor* identityref 2384 | +--rw rp 2385 | | ... 2386 | +--rw igmp {vpn-common:igmp and vpn-common:ipv4}? 2387 | | ... 2388 | +--rw mld {vpn-common:mld and vpn-common:ipv6}? 2389 | | ... 2390 | +--rw pim {vpn-common:pim}? 2391 | ... 2393 Figure 29: Multicast Subtree Structure (VPN Node Level) 2395 Multicast-related data nodes at the VPN network access level are 2396 shown in Figure 30. The values configured at the VPN network access 2397 level override the values configured for the corresponding data nodes 2398 in other levels. 2400 ... 2401 +--rw vpn-network-accesses 2402 +--rw vpn-network-access* [id] 2403 ... 2404 +--rw service 2405 ... 2406 +--rw multicast {vpn-common:multicast}? 2407 +--rw access-type? enumeration 2408 +--rw address-family? identityref 2409 +--rw protocol-type? enumeration 2410 +--rw remote-source? boolean 2411 +--rw igmp {vpn-common:igmp}? 2412 | +--rw static-group* [group-addr] 2413 | | +--rw group-addr 2414 | | rt-types:ipv4-multicast-group-address 2415 | | +--rw source-addr? 2416 | | rt-types:ipv4-multicast-source-address 2417 | +--rw max-groups? uint32 2418 | +--rw max-entries? uint32 2419 | +--rw max-group-sources? uint32 2420 | +--rw version? identityref 2421 | +--rw status 2422 | +--rw admin-status 2423 | | +--rw status? identityref 2424 | | +--rw last-change? yang:date-and-time 2425 | +--ro oper-status 2426 | +--ro status? identityref 2427 | +--ro last-change? yang:date-and-time 2428 +--rw mld {vpn-common:mld}? 2429 | +--rw static-group* [group-addr] 2430 | | +--rw group-addr 2431 | | rt-types:ipv6-multicast-group-address 2432 | | +--rw source-addr? 2433 | | rt-types:ipv6-multicast-source-address 2434 | +--rw max-groups? uint32 2435 | +--rw max-entries? uint32 2436 | +--rw max-group-sources? uint32 2437 | +--rw version? identityref 2438 | +--rw status 2439 | +--rw admin-status 2440 | | +--rw status? identityref 2441 | | +--rw last-change? yang:date-and-time 2442 | +--ro oper-status 2443 | +--ro status? identityref 2444 | +--ro last-change? yang:date-and-time 2445 +--rw pim {vpn-common:pim}? 2446 +--rw hello-interval? rt-types:timer-value-seconds16 2447 +--rw dr-priority? uint32 2448 +--rw status 2449 +--rw admin-status 2450 | +--rw status? identityref 2451 | +--rw last-change? yang:date-and-time 2452 +--ro oper-status 2453 +--ro status? identityref 2454 +--ro last-change? yang:date-and-time 2456 Figure 30: Multicast Subtree Structure (VPN Network Access Level) 2458 8. L3NM YANG Module 2460 This module uses types defined in [RFC6991] and [RFC8343]. It also 2461 uses groupings defined in [RFC8519], [RFC8177], and [RFC8294]. 2463 file "ietf-l3vpn-ntw@2021-07-12.yang" 2464 module ietf-l3vpn-ntw { 2465 yang-version 1.1; 2466 namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw"; 2467 prefix l3nm; 2469 import ietf-vpn-common { 2470 prefix vpn-common; 2471 reference 2472 "RFC UUUU: A Layer 2/3 VPN Common YANG Model"; 2473 } 2474 import ietf-inet-types { 2475 prefix inet; 2476 reference 2477 "RFC 6991: Common YANG Data Types, Section 4"; 2478 } 2479 import ietf-yang-types { 2480 prefix yang; 2481 reference 2482 "RFC 6991: Common YANG Data Types, Section 3"; 2483 } 2484 import ietf-key-chain { 2485 prefix key-chain; 2486 reference 2487 "RFC 8177: YANG Key Chain."; 2488 } 2489 import ietf-routing-types { 2490 prefix rt-types; 2491 reference 2492 "RFC 8294: Common YANG Data Types for the Routing Area"; 2493 } 2494 import ietf-interfaces { 2495 prefix if; 2496 reference 2497 "RFC 8343: A YANG Data Model for Interface Management"; 2498 } 2500 organization 2501 "IETF OPSAWG (Operations and Management Area Working Group)"; 2502 contact 2503 "WG Web: 2504 WG List: 2506 Author: Samier Barguil 2507 2508 Editor: Oscar Gonzalez de Dios 2509 2510 Editor: Mohamed Boucadair 2511 2512 Author: Luis Angel Munoz 2513 2514 Author: Alejandro Aguado 2515 "; 2516 description 2517 "This YANG module defines a generic network-oriented model 2518 for the configuration of Layer 3 Virtual Private Networks. 2520 Copyright (c) 2021 IETF Trust and the persons identified as 2521 authors of the code. All rights reserved. 2523 Redistribution and use in source and binary forms, with or 2524 without modification, is permitted pursuant to, and subject 2525 to the license terms contained in, the Simplified BSD License 2526 set forth in Section 4.c of the IETF Trust's Legal Provisions 2527 Relating to IETF Documents 2528 (http://trustee.ietf.org/license-info). 2530 This version of this YANG module is part of RFC XXXX; see 2531 the RFC itself for full legal notices."; 2533 revision 2021-07-12 { 2534 description 2535 "Initial revision."; 2536 reference 2537 "RFC XXXX: A Layer 3 VPN Network YANG Model"; 2538 } 2540 /* Features */ 2542 feature msdp { 2543 description 2544 "This feature indicates that Multicast Source Discovery Protocol 2545 (MSDP) capabilities are supported by the VPN."; 2546 reference 2547 "RFC 3618: Multicast Source Discovery Protocol (MSDP)"; 2548 } 2550 /* Identities */ 2552 identity address-allocation-type { 2553 description 2554 "Base identity for address allocation type in the 2555 Provider Edge (PE)-Customer Edge (CE) link."; 2556 } 2558 identity provider-dhcp { 2559 base address-allocation-type; 2560 description 2561 "The Provider's network provides a DHCP service to the customer."; 2562 } 2564 identity provider-dhcp-relay { 2565 base address-allocation-type; 2566 description 2567 "The Provider's network provides a DHCP relay service to the 2568 customer."; 2569 } 2571 identity provider-dhcp-slaac { 2572 if-feature "vpn-common:ipv6"; 2573 base address-allocation-type; 2574 description 2575 "The Provider's network provides a DHCP service to the customer 2576 as well as IPv6 Stateless Address Autoconfiguration (SLAAC)."; 2577 reference 2578 "RFC 4862: IPv6 Stateless Address Autoconfiguration"; 2579 } 2581 identity static-address { 2582 base address-allocation-type; 2583 description 2584 "The Provider's network provides static IP addressing to the 2585 customer."; 2586 } 2588 identity slaac { 2589 if-feature "vpn-common:ipv6"; 2590 base address-allocation-type; 2591 description 2592 "The Provider's network uses IPv6 SLAAC to provide addressing 2593 to the customer."; 2594 reference 2595 "RFC 4862: IPv6 Stateless Address Autoconfiguration"; 2596 } 2598 identity local-defined-next-hop { 2599 description 2600 "Base identity of local defined next-hops."; 2601 } 2603 identity discard { 2604 base local-defined-next-hop; 2605 description 2606 "Indicates an action to discard traffic for the 2607 corresponding destination. 2608 For example, this can be used to blackhole traffic."; 2609 } 2611 identity local-link { 2612 base local-defined-next-hop; 2613 description 2614 "Treat traffic towards addresses within the specified next-hop 2615 prefix as though they are connected to a local link."; 2617 } 2619 identity l2-tunnel-type { 2620 description 2621 "Base identity for layer-2 tunnel selection under the VPN 2622 network access."; 2623 } 2625 identity pseudowire { 2626 base l2-tunnel-type; 2627 description 2628 "Pseudowire tunnel termination in the VPN network access."; 2629 } 2631 identity vpls { 2632 base l2-tunnel-type; 2633 description 2634 "Virtual Private LAN Service (VPLS) tunnel termination in 2635 the VPN network access."; 2636 } 2638 identity vxlan { 2639 base l2-tunnel-type; 2640 description 2641 "Virtual eXtensible Local Area Network (VXLAN) tunnel 2642 termination in the VPN network access."; 2643 } 2645 /* Typedefs */ 2647 typedef predefined-next-hop { 2648 type identityref { 2649 base local-defined-next-hop; 2650 } 2651 description 2652 "Pre-defined next-hop designation for locally generated routes."; 2653 } 2655 typedef area-address { 2656 type string { 2657 pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}'; 2658 } 2659 description 2660 "This type defines the area address format."; 2661 } 2663 /* Groupings */ 2664 grouping vpn-instance-profile { 2665 description 2666 "Grouping for data nodes that may be factorized 2667 among many levels of the model. The grouping can 2668 be used to define generic profiles at the VPN service 2669 level and then called at the VPN node and VPN network 2670 access levels."; 2671 leaf local-autonomous-system { 2672 if-feature "vpn-common:rtg-bgp"; 2673 type inet:as-number; 2674 description 2675 "Provider's Autonomous System (AS) number. Used if the 2676 customer requests BGP routing."; 2677 } 2678 uses vpn-common:route-distinguisher; 2679 list address-family { 2680 key "address-family"; 2681 description 2682 "Set of per-address family parameters."; 2683 leaf address-family { 2684 type identityref { 2685 base vpn-common:address-family; 2686 } 2687 description 2688 "Indicates the address family (IPv4 and/or IPv6)."; 2689 } 2690 container vpn-targets { 2691 description 2692 "Set of route targets to match for import and export routes 2693 to/from VRF."; 2694 uses vpn-common:vpn-route-targets; 2695 } 2696 list maximum-routes { 2697 key "protocol"; 2698 description 2699 "Defines the maximum number of routes for the VRF."; 2700 leaf protocol { 2701 type identityref { 2702 base vpn-common:routing-protocol-type; 2703 } 2704 description 2705 "Indicates the routing protocol. 'any' value can 2706 be used to identify a limit that will apply for 2707 each active routing protocol."; 2708 } 2709 leaf maximum-routes { 2710 type uint32; 2711 description 2712 "Indicates the maximum number of prefixes that the 2713 VRF can accept for this address family and protocol."; 2714 } 2715 } 2716 } 2717 container multicast { 2718 if-feature "vpn-common:multicast"; 2719 description 2720 "Global multicast parameters."; 2721 leaf-list tree-flavor { 2722 type identityref { 2723 base vpn-common:multicast-tree-type; 2724 } 2725 description 2726 "Type of tree to be used."; 2727 } 2728 container rp { 2729 description 2730 "Rendezvous Point (RP) parameters."; 2731 container rp-group-mappings { 2732 description 2733 "RP-to-group mappings parameters."; 2734 list rp-group-mapping { 2735 key "id"; 2736 description 2737 "List of RP-to-group mappings."; 2738 leaf id { 2739 type uint16; 2740 description 2741 "Unique identifier for the mapping."; 2742 } 2743 container provider-managed { 2744 description 2745 "Parameters for a provider-managed RP."; 2746 leaf enabled { 2747 type boolean; 2748 default "false"; 2749 description 2750 "Set to true if the Rendezvous Point (RP) 2751 must be a provider-managed node. Set to 2752 false if it is a customer-managed node."; 2753 } 2754 leaf rp-redundancy { 2755 type boolean; 2756 default "false"; 2757 description 2758 "If set to true, it indicates that a redundancy 2759 mechanism for the RP is required."; 2761 } 2762 leaf optimal-traffic-delivery { 2763 type boolean; 2764 default "false"; 2765 description 2766 "If set to true, the service provider (SP) must 2767 ensure that the traffic uses an optimal path. 2768 An SP may use Anycast RP or RP-tree-to-SPT 2769 switchover architectures."; 2770 } 2771 container anycast { 2772 when "../rp-redundancy = 'true' and 2773 ../optimal-traffic-delivery = 'true'" { 2774 description 2775 "Only applicable if both RP redundancy and 2776 and delivery through optimal path are 2777 activated."; 2778 } 2779 description 2780 "PIM Anycast-RP parameters."; 2781 leaf local-address { 2782 type inet:ip-address; 2783 description 2784 "IP local address for PIM RP. Usually, it 2785 corresponds to the Router ID or the 2786 primary address."; 2787 } 2788 leaf-list rp-set-address { 2789 type inet:ip-address; 2790 description 2791 "Specifies the IP address of other RP routers 2792 that share the same RP IP address."; 2793 } 2794 } 2795 } 2796 leaf rp-address { 2797 when "../provider-managed/enabled = 'false'" { 2798 description 2799 "Relevant when the RP is not 2800 provider-managed."; 2801 } 2802 type inet:ip-address; 2803 mandatory true; 2804 description 2805 "Defines the address of the RP. 2806 Used if the RP is customer-managed."; 2807 } 2808 container groups { 2809 description 2810 "Multicast groups associated with the RP."; 2811 list group { 2812 key "id"; 2813 description 2814 "List of multicast groups."; 2815 leaf id { 2816 type uint16; 2817 description 2818 "Identifier for the group."; 2819 } 2820 choice group-format { 2821 mandatory true; 2822 description 2823 "Choice for multicast group format."; 2824 case group-prefix { 2825 leaf group-address { 2826 type inet:ip-prefix; 2827 description 2828 "A single multicast group prefix."; 2829 } 2830 } 2831 case startend { 2832 leaf group-start { 2833 type inet:ip-address; 2834 description 2835 "The first multicast group address in 2836 the multicast group address range."; 2837 } 2838 leaf group-end { 2839 type inet:ip-address; 2840 description 2841 "The last multicast group address in 2842 the multicast group address range."; 2843 } 2844 } 2845 } 2846 } 2847 } 2848 } 2849 } 2850 container rp-discovery { 2851 description 2852 "RP discovery parameters."; 2853 leaf rp-discovery-type { 2854 type identityref { 2855 base vpn-common:multicast-rp-discovery-type; 2856 } 2857 default "vpn-common:static-rp"; 2858 description 2859 "Type of RP discovery used."; 2860 } 2861 container bsr-candidates { 2862 when "derived-from-or-self(../rp-discovery-type, " 2863 + "'vpn-common:bsr-rp')" { 2864 description 2865 "Only applicable if discovery type is BSR-RP."; 2866 } 2867 description 2868 "Container for the customer Bootstrap Router (BSR) 2869 candidate's addresses."; 2870 leaf-list bsr-candidate-address { 2871 type inet:ip-address; 2872 description 2873 "Specifies the address of candidate BSR."; 2874 } 2875 } 2876 } 2877 } 2878 container igmp { 2879 if-feature "vpn-common:igmp and vpn-common:ipv4"; 2880 description 2881 "Includes IGMP-related parameters."; 2882 list static-group { 2883 key "group-addr"; 2884 description 2885 "Multicast static source/group associated to the 2886 IGMP session."; 2887 leaf group-addr { 2888 type rt-types:ipv4-multicast-group-address; 2889 description 2890 "Multicast group IPv4 addresss."; 2891 } 2892 leaf source-addr { 2893 type rt-types:ipv4-multicast-source-address; 2894 description 2895 "Multicast source IPv4 addresss."; 2896 } 2897 } 2898 leaf max-groups { 2899 type uint32; 2900 description 2901 "Indicates the maximum groups."; 2902 } 2903 leaf max-entries { 2904 type uint32; 2905 description 2906 "Indicates the maximum IGMP entries."; 2907 } 2908 leaf version { 2909 type identityref { 2910 base vpn-common:igmp-version; 2911 } 2912 default "vpn-common:igmpv2"; 2913 description 2914 "Indicates the IGMP version."; 2915 reference 2916 "RFC 1112: Host Extensions for IP Multicasting 2917 RFC 2236: Internet Group Management Protocol, Version 2 2918 RFC 3376: Internet Group Management Protocol, Version 3"; 2919 } 2920 } 2921 container mld { 2922 if-feature "vpn-common:mld and vpn-common:ipv6"; 2923 description 2924 "Includes MLD-related parameters."; 2925 list static-group { 2926 key "group-addr"; 2927 description 2928 "Multicast static source/group associated with the 2929 MLD session."; 2930 leaf group-addr { 2931 type rt-types:ipv6-multicast-group-address; 2932 description 2933 "Multicast group IPv6 addresss."; 2934 } 2935 leaf source-addr { 2936 type rt-types:ipv6-multicast-source-address; 2937 description 2938 "Multicast source IPv6 addresss."; 2939 } 2940 } 2941 leaf max-groups { 2942 type uint32; 2943 description 2944 "Indicates the maximum number of groups."; 2945 } 2946 leaf max-entries { 2947 type uint32; 2948 description 2949 "Indicates the maximum number of MLD entries."; 2950 } 2951 leaf version { 2952 type identityref { 2953 base vpn-common:mld-version; 2954 } 2955 default "vpn-common:mldv2"; 2956 description 2957 "Indicates the MLD protocol version."; 2958 reference 2959 "RFC 2710: Multicast Listener Discovery (MLD) for IPv6 2960 RFC 3810: Multicast Listener Discovery Version 2 (MLDv2) 2961 for IPv6"; 2962 } 2963 } 2964 container pim { 2965 if-feature "vpn-common:pim"; 2966 description 2967 "Only applies when protocol type is PIM."; 2968 leaf hello-interval { 2969 type rt-types:timer-value-seconds16; 2970 default "30"; 2971 description 2972 "PIM hello-messages interval. If set to 2973 'infinity' or 'not-set', no periodic 2974 Hello messages are sent."; 2975 reference 2976 "RFC 7761: Protocol Independent Multicast - Sparse 2977 Mode (PIM-SM): Protocol Specification (Revised), 2978 Section 4.11"; 2979 } 2980 leaf dr-priority { 2981 type uint32; 2982 default "1"; 2983 description 2984 "Indicates the preference in the Designated Router (DR) 2985 election process. Numerically larger DR priority allows 2986 a node to be elected as a DR."; 2987 reference 2988 "RFC 7761: Protocol Independent Multicast - Sparse 2989 Mode (PIM-SM): Protocol Specification (Revised), 2990 Section 4.3.2"; 2991 } 2992 } 2993 } 2994 } 2996 /* Main Blocks */ 2997 /* Main l3vpn-ntw */ 2999 container l3vpn-ntw { 3000 description 3001 "Main container for L3VPN services management."; 3002 container vpn-profiles { 3003 description 3004 "Contains a set of valid VPN profiles to reference in the VPN 3005 service."; 3006 uses vpn-common:vpn-profile-cfg; 3007 } 3008 container vpn-services { 3009 description 3010 "Container for the VPN services."; 3011 list vpn-service { 3012 key "vpn-id"; 3013 description 3014 "List of VPN services."; 3015 uses vpn-common:vpn-description; 3016 leaf parent-service-id { 3017 type vpn-common:vpn-id; 3018 description 3019 "Pointer to the parent service, if any. 3020 A parent service can be an L3SM, a slice request, a VPN+ 3021 service, etc."; 3022 } 3023 leaf vpn-type { 3024 type identityref { 3025 base vpn-common:service-type; 3026 } 3027 description 3028 "Indicates the service type."; 3029 } 3030 leaf vpn-service-topology { 3031 type identityref { 3032 base vpn-common:vpn-topology; 3033 } 3034 default "vpn-common:any-to-any"; 3035 description 3036 "VPN service topology."; 3037 } 3038 uses vpn-common:service-status; 3039 container vpn-instance-profiles { 3040 description 3041 "Container for a list of VPN instance profiles."; 3042 list vpn-instance-profile { 3043 key "profile-id"; 3044 description 3045 "List of VPN instance profiles."; 3046 leaf profile-id { 3047 type string; 3048 description 3049 "VPN instance profile identifier."; 3050 } 3051 leaf role { 3052 type identityref { 3053 base vpn-common:role; 3054 } 3055 default "vpn-common:any-to-any-role"; 3056 description 3057 "Role of the VPN node in the VPN."; 3058 } 3059 uses vpn-instance-profile; 3060 } 3061 } 3062 container underlay-transport { 3063 description 3064 "Container for underlay transport."; 3065 uses vpn-common:underlay-transport; 3066 } 3067 container external-connectivity { 3068 if-feature "vpn-common:external-connectivity"; 3069 description 3070 "Container for external connectivity."; 3071 choice profile { 3072 description 3073 "Choice for the external connectivity profile."; 3074 case profile { 3075 leaf profile-name { 3076 type leafref { 3077 path "/l3vpn-ntw/vpn-profiles" 3078 + "/valid-provider-identifiers" 3079 + "/external-connectivity-identifier/id"; 3080 } 3081 description 3082 "Name of the service provider's profile to be applied 3083 at the VPN service level."; 3084 } 3085 } 3086 } 3087 } 3088 container vpn-nodes { 3089 description 3090 "Container for VPN nodes."; 3091 list vpn-node { 3092 key "vpn-node-id"; 3093 description 3094 "Includes a list of VPN nodes."; 3095 leaf vpn-node-id { 3096 type vpn-common:vpn-id; 3097 description 3098 "An identifier of the VPN node."; 3099 } 3100 leaf description { 3101 type string; 3102 description 3103 "Textual description of the VPN node."; 3104 } 3105 leaf ne-id { 3106 type string; 3107 description 3108 "Unique identifier of the network element where the VPN 3109 node is deployed."; 3110 } 3111 leaf local-autonomous-system { 3112 if-feature "vpn-common:rtg-bgp"; 3113 type inet:as-number; 3114 description 3115 "Provider's AS number in case the customer requests BGP 3116 routing."; 3117 } 3118 leaf router-id { 3119 type rt-types:router-id; 3120 description 3121 "A 32-bit number in the dotted-quad format that is used 3122 to uniquely identify a node within an autonomous 3123 system. This identifier is used for both IPv4 and 3124 IPv6."; 3125 } 3126 container active-vpn-instance-profiles { 3127 description 3128 "Container for active VPN instance profiles."; 3129 list vpn-instance-profile { 3130 key "profile-id"; 3131 description 3132 "Includes a list of active VPN instance profiles."; 3133 leaf profile-id { 3134 type leafref { 3135 path "/l3vpn-ntw/vpn-services/vpn-service" 3136 + "/vpn-instance-profiles/vpn-instance-profile" 3137 + "/profile-id"; 3138 } 3139 description 3140 "Node's active VPN instance profile."; 3141 } 3142 list router-id { 3143 key "address-family"; 3144 description 3145 "Router-id per address family."; 3146 leaf address-family { 3147 type identityref { 3148 base vpn-common:address-family; 3149 } 3150 description 3151 "Indicates the address family for which the 3152 Router-ID applies."; 3153 } 3154 leaf router-id { 3155 type inet:ip-address; 3156 description 3157 "The router-id information can be an IPv4 or IPv6 3158 address. This can be used, for example, to 3159 configure an IPv6 address as a router-id 3160 when such capability is supported by underlay 3161 routers. In such case, the configured value 3162 overrides the generic one defined at the VPN 3163 node level."; 3164 } 3165 } 3166 uses vpn-instance-profile; 3167 } 3168 } 3169 container msdp { 3170 if-feature "msdp"; 3171 description 3172 "Includes MSDP-related parameters."; 3173 leaf peer { 3174 type inet:ipv4-address; 3175 description 3176 "Indicates the IPv4 address of the MSDP peer."; 3177 } 3178 leaf local-address { 3179 type inet:ipv4-address; 3180 description 3181 "Indicates the IPv4 address of the local end. 3182 This local address must be configured on 3183 the node."; 3184 } 3185 uses vpn-common:service-status; 3186 } 3187 uses vpn-common:vpn-components-group; 3188 uses vpn-common:service-status; 3189 container vpn-network-accesses { 3190 description 3191 "List of network accesses."; 3192 list vpn-network-access { 3193 key "id"; 3194 description 3195 "List of network accesses."; 3196 leaf id { 3197 type vpn-common:vpn-id; 3198 description 3199 "Identifier for the network access."; 3200 } 3201 leaf interface-id { 3202 type string; 3203 description 3204 "Identifier for the physical or logical 3205 interface. 3206 The identification of the sub-interface 3207 is provided at the connection and/or IP 3208 connection levels."; 3209 } 3210 leaf description { 3211 type string; 3212 description 3213 "Textual description of the network access."; 3214 } 3215 leaf vpn-network-access-type { 3216 type identityref { 3217 base vpn-common:site-network-access-type; 3218 } 3219 default "vpn-common:point-to-point"; 3220 description 3221 "Describes the type of connection, e.g., 3222 point-to-point."; 3223 } 3224 leaf vpn-instance-profile { 3225 type leafref { 3226 path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes" 3227 + "/vpn-node/active-vpn-instance-profiles" 3228 + "/vpn-instance-profile/profile-id"; 3229 } 3230 description 3231 "An identifier of an active VPN instance profile."; 3232 } 3233 uses vpn-common:service-status; 3234 container connection { 3235 description 3236 "Defines layer 2 protocols and parameters that are 3237 required to enable connectivity between the PE 3238 and the CE."; 3239 container encapsulation { 3240 description 3241 "Container for layer 2 encapsulation."; 3242 leaf type { 3243 type identityref { 3244 base vpn-common:encapsulation-type; 3245 } 3246 default "vpn-common:priority-tagged"; 3247 description 3248 "Tagged interface type. By default, the type of 3249 the tagged interface is 'priority-tagged'."; 3250 } 3251 container dot1q { 3252 when "derived-from-or-self(../type, " 3253 + "'vpn-common:dot1q')" { 3254 description 3255 "Only applies when the type of the 3256 tagged interface is 'dot1q'."; 3257 } 3258 if-feature "vpn-common:dot1q"; 3259 description 3260 "Tagged interface."; 3261 leaf tag-type { 3262 type identityref { 3263 base vpn-common:tag-type; 3264 } 3265 default "vpn-common:c-vlan"; 3266 description 3267 "Tag type. By default, the tag type is 3268 'c-vlan'."; 3269 } 3270 leaf cvlan-id { 3271 type uint16 { 3272 range "1..4094"; 3273 } 3274 description 3275 "VLAN identifier."; 3276 } 3277 } 3278 container priority-tagged { 3279 when "derived-from-or-self(../type, " 3280 + "'vpn-common:priority-tagged')" { 3281 description 3282 "Only applies when the type of the 3283 tagged interface is 'priority-tagged'."; 3284 } 3285 description 3286 "Priority tagged."; 3287 leaf tag-type { 3288 type identityref { 3289 base vpn-common:tag-type; 3290 } 3291 default "vpn-common:c-vlan"; 3292 description 3293 "Tag type. By default, the tag type is 3294 'c-vlan'."; 3295 } 3296 } 3297 container qinq { 3298 when "derived-from-or-self(../type, " 3299 + "'vpn-common:qinq')" { 3300 description 3301 "Only applies when the type of the tagged 3302 interface is QinQ."; 3303 } 3304 if-feature "vpn-common:qinq"; 3305 description 3306 "Includes QinQ parameters."; 3307 leaf tag-type { 3308 type identityref { 3309 base vpn-common:tag-type; 3310 } 3311 default "vpn-common:s-c-vlan"; 3312 description 3313 "Tag type. By default, the tag type is 3314 'c-s-vlan'."; 3315 } 3316 leaf svlan-id { 3317 type uint16; 3318 mandatory true; 3319 description 3320 "S-VLAN identifier."; 3321 } 3322 leaf cvlan-id { 3323 type uint16; 3324 mandatory true; 3325 description 3326 "C-VLAN identifier."; 3327 } 3328 } 3329 } 3330 choice l2-service { 3331 description 3332 "The layer 2 connectivity service can be 3333 provided by indicating a pointer to an L2VPN or 3334 by specifying a layer 2 tunnel service."; 3335 container l2-tunnel-service { 3336 description 3337 "Defines a layer 2 tunnel termination. 3338 It is only applicable when a tunnel is 3339 required. The supported values are: 3340 pseudowire, VPLS and, VXLAN. Other 3341 values may defined, if needed."; 3342 leaf type { 3343 type identityref { 3344 base l2-tunnel-type; 3345 } 3346 description 3347 "Selects the tunnel termiantion option for 3348 each vpn-network-access."; 3349 } 3350 container pseudowire { 3351 description 3352 "Includes pseudowire termination parameters."; 3353 leaf vcid { 3354 type uint32; 3355 description 3356 "Indicates a PW or VC identifier."; 3357 } 3358 leaf far-end { 3359 type union { 3360 type uint32; 3361 type inet:ip-address; 3362 } 3363 description 3364 "Neighbor reference."; 3365 reference 3366 "RFC 4447: Pseudowire Setup and Maintenance 3367 Using the Label Distribution Protocol 3368 (LDP), Section 5.2"; 3369 } 3370 } 3371 container vpls { 3372 description 3373 "VPLS termination parameters."; 3374 leaf vcid { 3375 type uint32; 3376 description 3377 "VC Identifier."; 3378 } 3379 leaf-list far-end { 3380 type union { 3381 type uint32; 3382 type inet:ip-address; 3383 } 3384 description 3385 "Neighbor reference."; 3386 } 3387 } 3388 container vxlan { 3389 if-feature "vpn-common:vxlan"; 3390 description 3391 "VXLAN termination parameters."; 3392 leaf vni-id { 3393 type uint32; 3394 mandatory true; 3395 description 3396 "VXLAN Network Identifier (VNI)."; 3397 } 3398 leaf peer-mode { 3399 type identityref { 3400 base vpn-common:vxlan-peer-mode; 3401 } 3402 default "vpn-common:static-mode"; 3403 description 3404 "Specifies the VXLAN access mode. By default, 3405 the peer mode is set to 'static-mode'."; 3406 } 3407 leaf-list peer-ip-address { 3408 type inet:ip-address; 3409 description 3410 "List of peer's IP addresses."; 3411 } 3412 } 3413 } 3414 case l2vpn { 3415 leaf l2vpn-id { 3416 type vpn-common:vpn-id; 3417 description 3418 "Indicates the L2VPN service associated with an 3419 Integrated Routing and Bridging (IRB) 3420 interface."; 3421 } 3422 } 3423 } 3424 leaf l2-termination-point { 3425 type string; 3426 description 3427 "Specifies a reference to a local layer 2 3428 termination point such as a layer 2 sub-interface."; 3429 } 3430 leaf local-bridge-reference { 3431 type string; 3432 description 3433 "Specifies a local bridge reference to 3434 accommodate, for example, implementations 3435 that require internal bridging. 3436 A reference may be a local bridge domain."; 3437 } 3438 leaf bearer-reference { 3439 if-feature "vpn-common:bearer-reference"; 3440 type string; 3441 description 3442 "This is an internal reference for the service 3443 provider to identify the bearer associated 3444 with this VPN."; 3445 } 3446 } 3447 container ip-connection { 3448 description 3449 "Defines IP connection parameters."; 3450 leaf l3-termination-point { 3451 type string; 3452 description 3453 "Specifies a reference to a local layer 3 3454 termination point such as a bridge domain 3455 interface."; 3456 } 3457 container ipv4 { 3458 if-feature "vpn-common:ipv4"; 3459 description 3460 "IPv4-specific parameters."; 3461 leaf local-address { 3462 type inet:ipv4-address; 3463 description 3464 "The IP address used at the provider's interface."; 3465 } 3466 leaf prefix-length { 3467 type uint8 { 3468 range "0..32"; 3469 } 3470 description 3471 "Subnet prefix length expressed in bits. 3472 It is applied to both local and customer 3473 addresses."; 3474 } 3475 leaf address-allocation-type { 3476 type identityref { 3477 base address-allocation-type; 3478 } 3479 must "not(derived-from-or-self(current(), " 3480 + "'slaac') or derived-from-or-self(current()," 3481 + " 'provider-dhcp-slaac'))" { 3482 error-message "SLAAC is only applicable to IPv6."; 3483 } 3484 description 3485 "Defines how addresses are allocated to the 3486 peer site. 3488 If there is no value for the address 3489 allocation type, then IPv4 addressing is not 3490 enabled."; 3491 } 3492 choice allocation-type { 3493 description 3494 "Choice of the IPv4 address allocation."; 3495 case provider-dhcp { 3496 description 3497 "DHCP allocated addresses related 3498 parameters. IP addresses are allocated 3499 by DHCP that is operated by the provider"; 3500 leaf dhcp-service-type { 3501 type enumeration { 3502 enum server { 3503 description 3504 "Local DHCP server."; 3505 } 3506 enum relay { 3507 description 3508 "Local DHCP relay. DHCP requests are 3509 relayed to a provider's server."; 3510 } 3511 } 3512 description 3513 "Indicates the type of DHCP service to 3514 be enabled on this access."; 3515 } 3516 choice service-type { 3517 description 3518 "Choice based on the DHCP service type."; 3519 case relay { 3520 description 3521 "Container for list of provider's DHCP 3522 servers (i.e., dhcp-service-type is set 3523 to relay)."; 3524 leaf-list server-ip-address { 3525 type inet:ipv4-address; 3526 description 3527 "IPv4 addresses of the provider's DHCP 3528 server to use by the local DHCP 3529 relay."; 3530 } 3531 } 3532 case server { 3533 description 3534 "A choice about how addresses are assigned 3535 when a local DHCP server is enabled."; 3536 choice address-assign { 3537 default "number"; 3538 description 3539 "Choice for how IPv4 addresses are 3540 assigned."; 3541 case number { 3542 leaf number-of-dynamic-address { 3543 type uint16; 3544 default "1"; 3545 description 3546 "Specifies the number of IP 3547 addresses to be assigned to the 3548 customer on this access."; 3549 } 3550 } 3551 case explicit { 3552 container customer-addresses { 3553 description 3554 "Container for customer 3555 addresses to be allocated 3556 using DHCP."; 3557 list address-pool { 3558 key "pool-id"; 3559 description 3560 "Describes IP addresses to be 3561 allocated by DHCP. 3563 When only start-address is 3564 present, it represents a single 3565 address. 3567 When both start-address and 3568 end-address are specified, it 3569 implies a range inclusive of both 3570 addresses."; 3571 leaf pool-id { 3572 type string; 3573 description 3574 "A pool identifier for the 3575 address range from start- 3576 address to end-address."; 3578 } 3579 leaf start-address { 3580 type inet:ipv4-address; 3581 mandatory true; 3582 description 3583 "Indicates the first address 3584 in the pool."; 3585 } 3586 leaf end-address { 3587 type inet:ipv4-address; 3588 description 3589 "Indicates the last address 3590 in the pool."; 3591 } 3592 } 3593 } 3594 } 3595 } 3596 } 3597 } 3598 } 3599 case dhcp-relay { 3600 description 3601 "DHCP relay is provided by the operator."; 3602 container customer-dhcp-servers { 3603 description 3604 "Container for a list of customer's DHCP 3605 servers."; 3606 leaf-list server-ip-address { 3607 type inet:ipv4-address; 3608 description 3609 "IPv4 addresses of the customer's DHCP 3610 server."; 3611 } 3612 } 3613 } 3614 case static-addresses { 3615 description 3616 "Lists the IPv4 addresses that are used."; 3617 leaf primary-address { 3618 type leafref { 3619 path "../address/address-id"; 3620 } 3621 description 3622 "Primary address of the connection."; 3623 } 3624 list address { 3625 key "address-id"; 3626 description 3627 "Lists the IPv4 addresses that are used."; 3628 leaf address-id { 3629 type string; 3630 description 3631 "An identifier of the static IPv4 3632 address."; 3633 } 3634 leaf customer-address { 3635 type inet:ipv4-address; 3636 description 3637 "IPv4 address at the customer side."; 3638 } 3639 } 3640 } 3641 } 3642 } 3643 container ipv6 { 3644 if-feature "vpn-common:ipv6"; 3645 description 3646 "IPv6-specific parameters."; 3647 leaf local-address { 3648 type inet:ipv6-address; 3649 description 3650 "IPv6 address of the provider side."; 3651 } 3652 leaf prefix-length { 3653 type uint8 { 3654 range "0..128"; 3655 } 3656 description 3657 "Subnet prefix length expressed in bits. 3658 It is applied to both local and customer 3659 addresses."; 3660 } 3661 leaf address-allocation-type { 3662 type identityref { 3663 base address-allocation-type; 3664 } 3665 description 3666 "Defines how addresses are allocated. 3667 If there is no value for the address 3668 allocation type, then IPv6 addressing is 3669 disabled."; 3670 } 3671 choice allocation-type { 3672 description 3673 "A choice based on the IPv6 allocation type."; 3675 container provider-dhcp { 3676 when "derived-from-or-self(../address-allo" 3677 + "cation-type, 'provider-dhcp') " 3678 + "or derived-from-or-self(../address-allo" 3679 + "cation-type, 'provider-dhcp-slaac')" { 3680 description 3681 "Only applies when addresses are 3682 allocated by DHCPv6 provided by the 3683 operator."; 3684 } 3685 description 3686 "DHCPv6 allocated addresses related 3687 parameters."; 3688 leaf dhcp-service-type { 3689 type enumeration { 3690 enum server { 3691 description 3692 "Local DHCPv6 server."; 3693 } 3694 enum relay { 3695 description 3696 "DHCPv6 relay."; 3697 } 3698 } 3699 description 3700 "Indicates the type of the DHCPv6 service to 3701 be enabled on this access."; 3702 } 3703 choice service-type { 3704 description 3705 "Choice based on the DHCPv6 service type."; 3706 case provider-dhcp-servers { 3707 leaf-list server-ip-address { 3708 type inet:ipv6-address; 3709 description 3710 "IPv6 addresses of the provider's 3711 DHCPv6 server."; 3712 } 3713 } 3714 case server { 3715 choice address-assign { 3716 default "number"; 3717 description 3718 "Choice about how IPv6 prefixes are 3719 assigned by the DHCPv6 server."; 3720 case number { 3721 leaf number-of-dynamic-address { 3722 type uint16; 3723 default "1"; 3724 description 3725 "Describes the number of IPv6 3726 prefixes that are allocated to 3727 the customer on this access."; 3728 } 3729 } 3730 case explicit { 3731 container customer-addresses { 3732 description 3733 "Container for customer IPv6 3734 addresses allocated by DHCPv6."; 3735 list address-pool { 3736 key "pool-id"; 3737 description 3738 "Describes IPv6 addresses 3739 allocated by DHCPv6. 3741 When only start-address is 3742 present, it represents a single 3743 address. 3745 When both start-address and 3746 end-address are specified, it 3747 implies a range inclusive of 3748 both addresses."; 3749 leaf pool-id { 3750 type string; 3751 description 3752 "Pool identifier for the address 3753 range from identified by start- 3754 address and end-address."; 3755 } 3756 leaf start-address { 3757 type inet:ipv6-address; 3758 mandatory true; 3759 description 3760 "Indicates the first address."; 3761 } 3762 leaf end-address { 3763 type inet:ipv6-address; 3764 description 3765 "Indicates the last address."; 3766 } 3767 } 3768 } 3769 } 3770 } 3772 } 3773 } 3774 } 3775 case dhcp-relay { 3776 description 3777 "DHCPv6 relay provided by the operator."; 3778 container customer-dhcp-servers { 3779 description 3780 "Container for a list of customer DHCP 3781 servers."; 3782 leaf-list server-ip-address { 3783 type inet:ipv6-address; 3784 description 3785 "Contains the IP addresses of the customer 3786 DHCPv6 server."; 3787 } 3788 } 3789 } 3790 case static-addresses { 3791 description 3792 "IPv6-specific parameters for static 3793 allocation."; 3794 leaf primary-address { 3795 type leafref { 3796 path "../address/address-id"; 3797 } 3798 description 3799 "Principal address of the connection"; 3800 } 3801 list address { 3802 key "address-id"; 3803 description 3804 "Describes IPv6 addresses that are used."; 3805 leaf address-id { 3806 type string; 3807 description 3808 "An identifier of an IPv6 address."; 3809 } 3810 leaf customer-address { 3811 type inet:ipv6-address; 3812 description 3813 "An IPv6 address of the customer side."; 3814 } 3815 } 3816 } 3817 } 3818 } 3819 } 3820 container routing-protocols { 3821 description 3822 "Defines routing protocols."; 3823 list routing-protocol { 3824 key "id"; 3825 description 3826 "List of routing protocols used on 3827 the CE/PE link. This list can be augmented."; 3828 leaf id { 3829 type string; 3830 description 3831 "Unique identifier for routing protocol."; 3832 } 3833 leaf type { 3834 type identityref { 3835 base vpn-common:routing-protocol-type; 3836 } 3837 description 3838 "Type of routing protocol."; 3839 } 3840 list routing-profiles { 3841 key "id"; 3842 description 3843 "Routing profiles."; 3844 leaf id { 3845 type leafref { 3846 path "/l3vpn-ntw/vpn-profiles" 3847 + "/valid-provider-identifiers" 3848 + "/routing-profile-identifier/id"; 3849 } 3850 description 3851 "Routing profile to be used."; 3852 } 3853 leaf type { 3854 type identityref { 3855 base vpn-common:ie-type; 3856 } 3857 description 3858 "Import, export, or both."; 3859 } 3860 } 3861 container static { 3862 when "derived-from-or-self(../type, " 3863 + "'vpn-common:static-routing')" { 3864 description 3865 "Only applies when protocol is static."; 3866 } 3867 description 3868 "Configuration specific to static routing."; 3869 container cascaded-lan-prefixes { 3870 description 3871 "LAN prefixes from the customer."; 3872 list ipv4-lan-prefixes { 3873 if-feature "vpn-common:ipv4"; 3874 key "lan next-hop"; 3875 description 3876 "List of LAN prefixes for the site."; 3877 leaf lan { 3878 type inet:ipv4-prefix; 3879 description 3880 "LAN prefixes."; 3881 } 3882 leaf lan-tag { 3883 type string; 3884 description 3885 "Internal tag to be used in VPN 3886 policies."; 3887 } 3888 leaf next-hop { 3889 type union { 3890 type inet:ip-address; 3891 type predefined-next-hop; 3892 } 3893 description 3894 "The next-hop that is to be used 3895 for the static route. This may be 3896 specified as an IP address or a 3897 pre-defined next-hop type (e.g., 3898 discard or local-link)."; 3899 } 3900 leaf bfd-enable { 3901 if-feature "vpn-common:bfd"; 3902 type boolean; 3903 description 3904 "Enables BFD."; 3905 } 3906 leaf metric { 3907 type uint32; 3908 description 3909 "Indicates the metric associated with 3910 the static route."; 3911 } 3912 leaf preference { 3913 type uint32; 3914 description 3915 "Indicates the preference of the static 3916 routes."; 3917 } 3918 uses vpn-common:service-status; 3919 } 3920 list ipv6-lan-prefixes { 3921 if-feature "vpn-common:ipv6"; 3922 key "lan next-hop"; 3923 description 3924 "List of LAN prefixes for the site."; 3925 leaf lan { 3926 type inet:ipv6-prefix; 3927 description 3928 "LAN prefixes."; 3929 } 3930 leaf lan-tag { 3931 type string; 3932 description 3933 "Internal tag to be used in VPN 3934 policies."; 3935 } 3936 leaf next-hop { 3937 type union { 3938 type inet:ip-address; 3939 type predefined-next-hop; 3940 } 3941 description 3942 "The next-hop that is to be used for the 3943 static route. This may be specified as 3944 an IP address or a pre-defined next-hop 3945 type (e.g., discard or local-link)."; 3946 } 3947 leaf bfd-enable { 3948 if-feature "vpn-common:bfd"; 3949 type boolean; 3950 description 3951 "Enables BFD."; 3952 } 3953 leaf metric { 3954 type uint32; 3955 description 3956 "Indicates the metric associated with 3957 the static route."; 3958 } 3959 leaf preference { 3960 type uint32; 3961 description 3962 "Indicates the preference associated 3963 with the static route."; 3965 } 3966 uses vpn-common:service-status; 3967 } 3968 } 3969 } 3970 container bgp { 3971 when "derived-from-or-self(../type, " 3972 + "'vpn-common:bgp-routing')" { 3973 description 3974 "Only applies when protocol is BGP."; 3975 } 3976 if-feature "vpn-common:rtg-bgp"; 3977 description 3978 "BGP-specific configuration."; 3979 leaf description { 3980 type string; 3981 description 3982 "Includes a description of the BGP session. 3984 This description is meant to be used for 3985 diagnosis purposes. The semantic of the 3986 description is local to an 3987 implementation."; 3988 } 3989 leaf local-autonomous-system { 3990 type inet:as-number; 3991 description 3992 "Indicates a local AS Number (ASN) if a 3993 distinct ASN than the one configured at 3994 the VPN node level is needed."; 3995 } 3996 leaf peer-autonomous-system { 3997 type inet:as-number; 3998 mandatory true; 3999 description 4000 "Indicates the customer's ASN when 4001 the customer requests BGP routing."; 4002 } 4003 leaf address-family { 4004 type identityref { 4005 base vpn-common:address-family; 4006 } 4007 description 4008 "This node contains the address families to be 4009 activated. Dual-stack means that both IPv4 4010 and IPv6 will be activated."; 4011 } 4012 leaf local-address { 4013 type union { 4014 type inet:ip-address; 4015 type if:interface-ref; 4016 } 4017 description 4018 "Set the local IP address to use for the BGP 4019 transport session. This may be expressed as 4020 either an IP address or a reference to an 4021 interface."; 4022 } 4023 leaf-list neighbor { 4024 type inet:ip-address; 4025 description 4026 "IP address(es) of the BGP neighbor. IPv4 4027 and IPv6 neighbors may be indicated if 4028 two sessions will be used for IPv4 and 4029 IPv6."; 4030 } 4031 leaf multihop { 4032 type uint8; 4033 description 4034 "Describes the number of IP hops allowed 4035 between a given BGP neighbor and the PE."; 4036 } 4037 leaf as-override { 4038 type boolean; 4039 default "false"; 4040 description 4041 "Defines whether ASN override is enabled, 4042 i.e., replace the ASN of the customer 4043 specified in the AS_Path attribute with 4044 the local ASN."; 4045 } 4046 leaf allow-own-as { 4047 type uint8; 4048 default "0"; 4049 description 4050 "Specifies the number of occurrences 4051 of the provider's ASN that can occur 4052 within the AS_PATH before it 4053 is rejected."; 4054 } 4055 leaf prepend-global-as { 4056 type boolean; 4057 default "false"; 4058 description 4059 "In some situations, the ASN that is 4060 provided at the VPN node level may be 4061 distinct from the one configured at the 4062 VPN network access level. When such 4063 ASNs are provided, they are both 4064 prepended to the BGP route updates 4065 for this access. To disable that 4066 behavior, the prepend-global-as 4067 must be set to 'false'. In such a case, 4068 the ASN that is provided at 4069 the VPN node level is not prepended to 4070 the BGP route updates for this access."; 4071 } 4072 leaf default-route { 4073 type boolean; 4074 default "false"; 4075 description 4076 "Defines whether default routes can be 4077 advertised to its peer. If set, the 4078 default routes are advertised to its 4079 peer."; 4080 } 4081 leaf site-of-origin { 4082 when "../address-family = 'vpn-common:ipv4' or " 4083 + "'vpn-common:dual-stack'" { 4084 description 4085 "Only applies if IPv4 is activated."; 4086 } 4087 type rt-types:route-origin; 4088 description 4089 "The Site of Origin attribute is encoded as 4090 a Route Origin Extended Community. It is 4091 meant to uniquely identify the set of routes 4092 learned from a site via a particular CE/PE 4093 connection and is used to prevent routing 4094 loops."; 4095 reference 4096 "RFC 4364: BGP/MPLS IP Virtual Private 4097 Networks (VPNs), Section 7"; 4098 } 4099 leaf ipv6-site-of-origin { 4100 when "../address-family = 'vpn-common:ipv6' or " 4101 + "'vpn-common:dual-stack'" { 4102 description 4103 "Only applies if IPv6 is activated."; 4104 } 4105 type rt-types:ipv6-route-origin; 4106 description 4107 "IPv6 Route Origins are IPv6 Address Specific 4108 BGP Extended that are meant to the Site of 4109 Origin for VRF information."; 4110 reference 4111 "RFC 5701: IPv6 Address Specific BGP Extended 4112 Community Attribute"; 4113 } 4114 list redistribute-connected { 4115 key "address-family"; 4116 description 4117 "Indicates the per-AF policy to follow 4118 for connected routes."; 4119 leaf address-family { 4120 type identityref { 4121 base vpn-common:address-family; 4122 } 4123 description 4124 "Indicates the address family."; 4125 } 4126 leaf enable { 4127 type boolean; 4128 description 4129 "Enables to redistribute connected 4130 routes."; 4131 } 4132 } 4133 container bgp-max-prefix { 4134 description 4135 "Controls the behavior when a prefix 4136 maximum is reached."; 4137 leaf max-prefix { 4138 type uint32; 4139 default "5000"; 4140 description 4141 "Indicates the maximum number of BGP 4142 prefixes allowed in the BGP session. 4144 It allows control of how many prefixes 4145 can be received from a neighbor. 4147 If the limit is exceeded, the action 4148 indicated in violate-action will be 4149 followed."; 4150 reference 4151 "RFC 4271: A Border Gateway Protocol 4 4152 (BGP-4), Section 8.2.2"; 4153 } 4154 leaf warning-threshold { 4155 type decimal64 { 4156 fraction-digits 5; 4157 range "0..100"; 4158 } 4159 units "percent"; 4160 default "75"; 4161 description 4162 "When this value is reached, a warning 4163 notification will be triggered."; 4164 } 4165 leaf violate-action { 4166 type enumeration { 4167 enum warning { 4168 description 4169 "Only a warning message is sent to 4170 the peer when the limit is 4171 exceeded."; 4172 } 4173 enum discard-extra-paths { 4174 description 4175 "Discards extra paths when the 4176 limit is exceeded."; 4177 } 4178 enum restart { 4179 description 4180 "The BGP session restarts after 4181 a time interval."; 4182 } 4183 } 4184 description 4185 "BGP neighbor max-prefix violate 4186 action"; 4187 } 4188 leaf restart-interval { 4189 type uint16; 4190 units "minutes"; 4191 description 4192 "Time interval (min) after which the 4193 BGP session will be reestablished."; 4194 } 4195 } 4196 container bgp-timers { 4197 description 4198 "Includes two BGP timers that can be 4199 customized when building a VPN service 4200 with BGP used as CE-PE routing 4201 protocol."; 4202 leaf keepalive { 4203 type uint16 { 4204 range "0..21845"; 4206 } 4207 units "seconds"; 4208 default "30"; 4209 description 4210 "This timer indicates the KEEPALIVE 4211 messages' frequency between a PE 4212 and a BGP peer. 4214 If set to '0', it indicates KEEPALIVE 4215 messages are disabled. 4217 It is suggested that the maximum time 4218 between KEEPALIVE messages would be 4219 one third of the Hold Time interval."; 4220 reference 4221 "RFC 4271: A Border Gateway Protocol 4 4222 (BGP-4), Section 4.4"; 4223 } 4224 leaf hold-time { 4225 type uint16 { 4226 range "0 | 3..65535"; 4227 } 4228 units "seconds"; 4229 default "90"; 4230 description 4231 "It indicates the maximum number of 4232 seconds that may elapse between the 4233 receipt of successive KEEPALIVE 4234 and/or UPDATE messages from the peer. 4236 The Hold Time must be either zero or 4237 at least three seconds."; 4238 reference 4239 "RFC 4271: A Border Gateway Protocol 4 4240 (BGP-4), Section 4.2"; 4241 } 4242 } 4243 container authentication { 4244 description 4245 "Container for BGP authentication 4246 parameters between a PE and a CE."; 4247 leaf enable { 4248 type boolean; 4249 default "false"; 4250 description 4251 "Enables or disables authentication."; 4252 } 4253 container keying-material { 4254 when "../enable = 'true'"; 4255 description 4256 "Container for describing how a BGP routing 4257 session is to be secured between a PE and 4258 a CE."; 4259 choice option { 4260 description 4261 "Choice of authentication options."; 4262 case tcp-ao { 4263 description 4264 "Uses TCP-Authentication Option 4265 (TCP-AO)."; 4266 reference 4267 "RFC 5925: The TCP Authentication 4268 Option."; 4269 leaf enable-tcp-ao { 4270 type boolean; 4271 description 4272 "Enables TCP-AO."; 4273 } 4274 leaf ao-keychain { 4275 type key-chain:key-chain-ref; 4276 description 4277 "Reference to the TCP-AO key chain."; 4278 reference 4279 "RFC 8177: YANG Key Chain."; 4280 } 4281 } 4282 case md5 { 4283 description 4284 "Uses MD5 to secure the session."; 4285 reference 4286 "RFC 4364: BGP/MPLS IP Virtual Private 4287 Networks (VPNs), 4288 Section 13.2"; 4289 leaf md5-keychain { 4290 type key-chain:key-chain-ref; 4291 description 4292 "Reference to the MD5 key chain."; 4293 reference 4294 "RFC 8177: YANG Key Chain."; 4295 } 4296 } 4297 case explicit { 4298 leaf key-id { 4299 type uint32; 4300 description 4301 "Key Identifier"; 4303 } 4304 leaf key { 4305 type string; 4306 description 4307 "BGP authentication key."; 4308 } 4309 leaf crypto-algorithm { 4310 type identityref { 4311 base key-chain:crypto-algorithm; 4312 } 4313 description 4314 "Indicates the cryptographic algorithm 4315 associated with the key."; 4316 } 4317 } 4318 case ipsec { 4319 description 4320 "Specifies a reference to an IKE 4321 Security Association (SA)."; 4322 leaf sa { 4323 type string; 4324 description 4325 "Indicates the name of the SA."; 4326 } 4327 } 4328 } 4329 } 4330 } 4331 uses vpn-common:service-status; 4332 } 4333 container ospf { 4334 when "derived-from-or-self(../type, " 4335 + "'vpn-common:ospf-routing')" { 4336 description 4337 "Only applies when protocol is OSPF."; 4338 } 4339 if-feature "vpn-common:rtg-ospf"; 4340 description 4341 "OSPF-specific configuration."; 4342 leaf address-family { 4343 type identityref { 4344 base vpn-common:address-family; 4345 } 4346 description 4347 "Indicates whether IPv4, IPv6, or 4348 both are to be activated."; 4349 } 4350 leaf area-id { 4351 type yang:dotted-quad; 4352 mandatory true; 4353 description 4354 "Area ID."; 4355 reference 4356 "RFC 4577: OSPF as the Provider/Customer 4357 Edge Protocol for BGP/MPLS IP 4358 Virtual Private Networks 4359 (VPNs), Section 4.2.3 4360 RFC 6565: OSPFv3 as a Provider Edge to 4361 Customer Edge (PE-CE) Routing 4362 Protocol, Section 4.2"; 4363 } 4364 leaf metric { 4365 type uint16; 4366 default "1"; 4367 description 4368 "Metric of the PE-CE link. It is used 4369 in the routing state calculation and 4370 path selection."; 4371 } 4372 container sham-links { 4373 if-feature "vpn-common:rtg-ospf-sham-link"; 4374 description 4375 "List of sham links."; 4376 reference 4377 "RFC 4577: OSPF as the Provider/Customer 4378 Edge Protocol for BGP/MPLS IP 4379 Virtual Private Networks 4380 (VPNs), Section 4.2.7 4381 RFC 6565: OSPFv3 as a Provider Edge to 4382 Customer Edge (PE-CE) Routing 4383 Protocol, Section 5"; 4384 list sham-link { 4385 key "target-site"; 4386 description 4387 "Creates a sham link with another site."; 4388 leaf target-site { 4389 type string; 4390 description 4391 "Target site for the sham link connection. 4392 The site is referred to by its ID."; 4393 } 4394 leaf metric { 4395 type uint16; 4396 default "1"; 4397 description 4398 "Metric of the sham link. It is used in 4399 the routing state calculation and path 4400 selection. The default value is set 4401 to 1."; 4402 reference 4403 "RFC 4577: OSPF as the Provider/Customer 4404 Edge Protocol for BGP/MPLS IP 4405 Virtual Private Networks 4406 (VPNs), Section 4.2.7.3 4407 RFC 6565: OSPFv3 as a Provider Edge to 4408 Customer Edge (PE-CE) Routing 4409 Protocol, Section 5.2"; 4410 } 4411 } 4412 } 4413 leaf max-lsa { 4414 type uint32 { 4415 range "1..4294967294"; 4416 } 4417 description 4418 "Maximum number of allowed LSAs OSPF."; 4419 } 4420 container authentication { 4421 description 4422 "Authentication configuration."; 4423 leaf enable { 4424 type boolean; 4425 default "false"; 4426 description 4427 "Enables or disables authentication."; 4428 } 4429 container keying-material { 4430 when "../enable = 'true'"; 4431 description 4432 "Container for describing how an OSPF 4433 session is to be secured between a CE 4434 and a PE."; 4435 choice option { 4436 description 4437 "Options for OSPF authentication."; 4438 case auth-key-chain { 4439 leaf key-chain { 4440 type key-chain:key-chain-ref; 4441 description 4442 "key-chain name."; 4443 } 4444 } 4445 case auth-key-explicit { 4446 leaf key-id { 4447 type uint32; 4448 description 4449 "Key identifier."; 4450 } 4451 leaf key { 4452 type string; 4453 description 4454 "OSPF authentication key."; 4455 } 4456 leaf crypto-algorithm { 4457 type identityref { 4458 base key-chain:crypto-algorithm; 4459 } 4460 description 4461 "Indicates the cryptographic algorithm 4462 associated with the key."; 4463 } 4464 } 4465 case ipsec { 4466 leaf sa { 4467 type string; 4468 description 4469 "Indicates the name of the SA."; 4470 reference 4471 "RFC 4552: Authentication 4472 /Confidentiality for 4473 OSPFv3"; 4474 } 4475 } 4476 } 4477 } 4478 } 4479 uses vpn-common:service-status; 4480 } 4481 container isis { 4482 when "derived-from-or-self(../type, " 4483 + "'vpn-common:isis-routing')" { 4484 description 4485 "Only applies when protocol is IS-IS."; 4486 } 4487 if-feature "vpn-common:rtg-isis"; 4488 description 4489 "IS-IS specific configuration."; 4490 leaf address-family { 4491 type identityref { 4492 base vpn-common:address-family; 4493 } 4494 description 4495 "Indicates whether IPv4, IPv6, or both 4496 are to be activated."; 4497 } 4498 leaf area-address { 4499 type area-address; 4500 mandatory true; 4501 description 4502 "Area address."; 4503 } 4504 leaf level { 4505 type identityref { 4506 base vpn-common:isis-level; 4507 } 4508 description 4509 "Can be level-1, level-2, or level-1-2."; 4510 } 4511 leaf metric { 4512 type uint16; 4513 default "1"; 4514 description 4515 "Metric of the PE-CE link. It is used 4516 in the routing state calculation and 4517 path selection."; 4518 } 4519 leaf mode { 4520 type enumeration { 4521 enum active { 4522 description 4523 "Interface sends or receives IS-IS 4524 protocol control packets."; 4525 } 4526 enum passive { 4527 description 4528 "Suppresses the sending of IS-IS 4529 updates through the specified 4530 interface."; 4531 } 4532 } 4533 default "active"; 4534 description 4535 "IS-IS interface mode type."; 4536 } 4537 container authentication { 4538 description 4539 "Authentication configuration."; 4540 leaf enable { 4541 type boolean; 4542 default "false"; 4543 description 4544 "Enables or disables authentication."; 4545 } 4546 container keying-material { 4547 when "../enable = 'true'"; 4548 description 4549 "Container for describing how an IS-IS 4550 session is to be secured between a CE 4551 and a PE."; 4552 choice option { 4553 description 4554 "Options for IS-IS authentication."; 4555 case auth-key-chain { 4556 leaf key-chain { 4557 type key-chain:key-chain-ref; 4558 description 4559 "key-chain name."; 4560 } 4561 } 4562 case auth-key-explicit { 4563 leaf key-id { 4564 type uint32; 4565 description 4566 "Key Identifier"; 4567 } 4568 leaf key { 4569 type string; 4570 description 4571 "IS-IS authentication key."; 4572 } 4573 leaf crypto-algorithm { 4574 type identityref { 4575 base key-chain:crypto-algorithm; 4576 } 4577 description 4578 "Indicates the cryptographic algorithm 4579 associated with the key."; 4580 } 4581 } 4582 } 4583 } 4584 } 4585 uses vpn-common:service-status; 4586 } 4587 container rip { 4588 when "derived-from-or-self(../type, " 4589 + "'vpn-common:rip-routing')" { 4590 description 4591 "Only applies when the protocol is RIP. 4592 For IPv4, the model assumes that RIP 4593 version 2 is used."; 4594 } 4595 if-feature "vpn-common:rtg-rip"; 4596 description 4597 "Configuration specific to RIP routing."; 4598 leaf address-family { 4599 type identityref { 4600 base vpn-common:address-family; 4601 } 4602 description 4603 "Indicates whether IPv4, IPv6, or both 4604 address families are to be activated."; 4605 } 4606 container timers { 4607 description 4608 "Indicates the RIP timers."; 4609 reference 4610 "RFC 2453: RIP Version 2"; 4611 leaf update-interval { 4612 type uint16 { 4613 range "1..32767"; 4614 } 4615 units "seconds"; 4616 default "30"; 4617 description 4618 "Indicates the RIP update time. 4619 That is, the amount of time for which 4620 routing updates are sent."; 4621 } 4622 leaf invalid-interval { 4623 type uint16 { 4624 range "1..32767"; 4625 } 4626 units "seconds"; 4627 default "180"; 4628 description 4629 "Is the interval before a route is declared 4630 invalid after no updates are received. 4631 This value is at least three times 4632 the value for the update-interval 4633 argument."; 4634 } 4635 leaf holddown-interval { 4636 type uint16 { 4637 range "1..32767"; 4638 } 4639 units "seconds"; 4640 default "180"; 4641 description 4642 "Specifies the interval before better routes 4643 are released."; 4644 } 4645 leaf flush-interval { 4646 type uint16 { 4647 range "1..32767"; 4648 } 4649 units "seconds"; 4650 default "180"; 4651 description 4652 "Indicates the RIP flush timer. That is, 4653 the amount of time that must elapse before 4654 a route is removed from the routing 4655 table."; 4656 } 4657 } 4658 leaf default-metric { 4659 type uint8 { 4660 range "0..16"; 4661 } 4662 default "1"; 4663 description 4664 "Sets the default metric."; 4665 } 4666 container authentication { 4667 description 4668 "Authentication configuration."; 4669 leaf enable { 4670 type boolean; 4671 default "false"; 4672 description 4673 "Enables or disables authentication."; 4674 } 4675 container keying-material { 4676 when "../enable = 'true'"; 4677 description 4678 "Container for describing how a RIP 4679 session is to be secured between a CE 4680 and a PE."; 4681 choice option { 4682 description 4683 "Specifies the authentication scheme."; 4684 case auth-key-chain { 4685 leaf key-chain { 4686 type key-chain:key-chain-ref; 4687 description 4688 "key-chain name."; 4689 } 4690 } 4691 case auth-key-explicit { 4692 leaf key { 4693 type string; 4694 description 4695 "RIP authentication key."; 4696 } 4697 leaf crypto-algorithm { 4698 type identityref { 4699 base key-chain:crypto-algorithm; 4700 } 4701 description 4702 "Indicates the cryptographic algorithm 4703 associated with the key."; 4704 } 4705 } 4706 } 4707 } 4708 } 4709 uses vpn-common:service-status; 4710 } 4711 container vrrp { 4712 when "derived-from-or-self(../type, " 4713 + "'vpn-common:vrrp-routing')" { 4714 description 4715 "Only applies when protocol is VRRP."; 4716 } 4717 if-feature "vpn-common:rtg-vrrp"; 4718 description 4719 "Configuration specific to VRRP."; 4720 reference 4721 "RFC 5798: Virtual Router Redundancy Protocol 4722 (VRRP) Version 3 for IPv4 and IPv6"; 4723 leaf address-family { 4724 type identityref { 4725 base vpn-common:address-family; 4726 } 4727 description 4728 "Indicates whether IPv4, IPv6, or both 4729 address families are to be enabled."; 4730 } 4731 leaf vrrp-group { 4732 type uint8 { 4733 range "1..255"; 4734 } 4735 description 4736 "Includes the VRRP group identifier."; 4737 } 4738 leaf backup-peer { 4739 type inet:ip-address; 4740 description 4741 "Indicates the IP address of the peer."; 4742 } 4743 leaf-list virtual-ip-address { 4744 type inet:ip-address; 4745 description 4746 "Virtual IP addresses for a single VRRP group. "; 4747 reference 4748 "RFC 5798: Virtual Router Redundancy Protocol (VRRP) 4749 Version 3 for IPv4 and IPv6, Sections 4750 1.2 and 1.3"; 4751 } 4752 leaf priority { 4753 type uint8 { 4754 range "1..254"; 4755 } 4756 default "100"; 4757 description 4758 "Sets the local priority of the VRRP 4759 speaker."; 4760 } 4761 leaf ping-reply { 4762 type boolean; 4763 description 4764 "Controls whether the VRRP speaker should 4765 answer to ping requests."; 4766 } 4767 uses vpn-common:service-status; 4768 } 4769 } 4770 } 4771 container oam { 4772 description 4773 "Defines the Operations, Administration, 4774 and Maintenance (OAM) mechanisms used. 4776 BFD is set as a fault detection mechanism, 4777 but other mechanisms can be defined in the 4778 future."; 4779 container bfd { 4780 if-feature "vpn-common:bfd"; 4781 description 4782 "Container for BFD."; 4784 leaf desired-min-tx-interval { 4785 type uint32; 4786 units "microseconds"; 4787 default "1000000"; 4788 description 4789 "The minimum interval between transmission of 4790 BFD control packets that the operator desires."; 4791 reference 4792 "RFC 5880: Bidirectional Forwarding Detection 4793 (BFD), Section 6.8.7"; 4794 } 4795 leaf required-min-rx-interval { 4796 type uint32; 4797 units "microseconds"; 4798 description 4799 "The minimum interval between received BFD 4800 control packets that the PE should support."; 4801 reference 4802 "RFC 5880: Bidirectional Forwarding Detection 4803 (BFD), Section 6.8.7"; 4804 } 4805 leaf detection-multiplier { 4806 type uint8 { 4807 range "1..max"; 4808 } 4809 description 4810 "The detection interval for the BFD session 4811 is calculated by multiplying the value of 4812 the negotiated transmission interval by 4813 the detection multiplier value."; 4814 reference 4815 "RFC 5880: Bidirectional Forwarding Detection 4816 (BFD), Section 6.8.7"; 4817 } 4818 choice holdtime { 4819 default "fixed"; 4820 description 4821 "Choice for holdtime flavor."; 4822 case fixed { 4823 leaf fixed-value { 4824 type uint32; 4825 units "msec"; 4826 description 4827 "Expected BFD holdtime. 4829 The customer may impose some fixed 4830 values for the holdtime period if the 4831 provider allows the customer use of 4832 this function. 4834 If the provider doesn't allow the 4835 customer to use this function, 4836 the fixed-value will not be set."; 4837 } 4838 } 4839 case profile { 4840 description 4841 "Well-known SP profile."; 4842 leaf profile-name { 4843 type leafref { 4844 path "/l3vpn-ntw/vpn-profiles" 4845 + "/valid-provider-identifiers" 4846 + "/bfd-profile-identifier/id"; 4847 } 4848 description 4849 "Well-known service provider profile name. 4851 The provider can propose some profiles 4852 to the customer, depending on the 4853 service level the customer wants to 4854 achieve."; 4855 } 4856 } 4857 } 4858 container authentication { 4859 presence "Enables BFD authentication"; 4860 description 4861 "Parameters for BFD authentication."; 4862 leaf key-chain { 4863 type key-chain:key-chain-ref; 4864 description 4865 "Name of the key-chain."; 4866 } 4867 leaf meticulous { 4868 type boolean; 4869 description 4870 "Enables meticulous mode."; 4871 reference 4872 "RFC 5880: Bidirectional Forwarding 4873 Detection (BFD), Section 6.7"; 4874 } 4875 } 4876 uses vpn-common:service-status; 4877 } 4878 } 4879 container security { 4880 description 4881 "Site-specific security parameters."; 4882 container encryption { 4883 if-feature "vpn-common:encryption"; 4884 description 4885 "Container for CE-PE security encryption."; 4886 leaf enabled { 4887 type boolean; 4888 default "false"; 4889 description 4890 "If true, traffic encryption on the 4891 connection is required. Otherwise, it 4892 is disabled."; 4893 } 4894 leaf layer { 4895 when "../enabled = 'true'" { 4896 description 4897 "Indicates the layer on which encryption 4898 is enabled."; 4899 } 4900 type enumeration { 4901 enum layer2 { 4902 description 4903 "Encryption occurs at Layer 2."; 4904 } 4905 enum layer3 { 4906 description 4907 "Encryption occurs at Layer 3. 4908 For example, IPsec may be used when 4909 a customer requests Layer 3 4910 encryption."; 4911 } 4912 } 4913 description 4914 "Indicates the layer on which encryption 4915 is applied."; 4916 } 4917 } 4918 container encryption-profile { 4919 when "../encryption/enabled = 'true'" { 4920 description 4921 "Indicates the layer on which encryption 4922 is enabled."; 4923 } 4924 description 4925 "Container for encryption profile."; 4926 choice profile { 4927 description 4928 "Choice for the encryption profile."; 4929 case provider-profile { 4930 leaf profile-name { 4931 type leafref { 4932 path "/l3vpn-ntw/vpn-profiles" 4933 + "/valid-provider-identifiers" 4934 + "/encryption-profile-identifier/id"; 4935 } 4936 description 4937 "Name of the service provider's profile 4938 to be applied."; 4939 } 4940 } 4941 case customer-profile { 4942 leaf customer-key-chain { 4943 type key-chain:key-chain-ref; 4944 description 4945 "Customer-supplied key chain."; 4946 } 4947 } 4948 } 4949 } 4950 } 4951 container service { 4952 description 4953 "Service parameters of the attachment."; 4954 leaf inbound-bandwidth { 4955 if-feature "vpn-common:inbound-bw"; 4956 type uint64; 4957 units "bps"; 4958 description 4959 "From the customer site's perspective, the 4960 service inbound bandwidth of the connection 4961 or download bandwidth from the SP to 4962 the site. Note that the L3SM uses 'input- 4963 -bandwidth' to refer to the same concept."; 4964 } 4965 leaf outbound-bandwidth { 4966 if-feature "vpn-common:outbound-bw"; 4967 type uint64; 4968 units "bps"; 4969 description 4970 "From the customer site's perspective, 4971 the service oubtound bandwidth of the 4972 connection or upload bandwidth from 4973 the site to the SP. Note that the L3SM uses 4974 'output-bandwidth' to refer to the same 4975 concept."; 4977 } 4978 leaf mtu { 4979 type uint16; 4980 units "bytes"; 4981 description 4982 "MTU at service level. If the service is IP, 4983 it refers to the IP MTU. If Carriers' 4984 Carriers (CsC) is enabled, the requested MTU 4985 will refer to the MPLS MTU and not to the 4986 IP MTU."; 4987 } 4988 container qos { 4989 if-feature "vpn-common:qos"; 4990 description 4991 "QoS configuration."; 4992 container qos-classification-policy { 4993 description 4994 "Configuration of the traffic classification 4995 policy."; 4996 uses vpn-common:qos-classification-policy; 4997 } 4998 container qos-action { 4999 description 5000 "List of QoS action policies."; 5001 list rule { 5002 key "id"; 5003 description 5004 "List of QoS actions."; 5005 leaf id { 5006 type string; 5007 description 5008 "An identifier of the QoS action rule."; 5009 } 5010 leaf target-class-id { 5011 type string; 5012 description 5013 "Identification of the class of service. 5014 This identifier is internal to the 5015 administration."; 5016 } 5017 leaf inbound-rate-limit { 5018 type decimal64 { 5019 fraction-digits 5; 5020 range "0..100"; 5021 } 5022 units "percent"; 5023 description 5024 "Specifies whether/how to rate-limit the 5025 inbound traffic matching this QoS policy. 5026 It is expressed as a percent of the value 5027 that is indicated in 'input-bandwidth'."; 5028 } 5029 leaf outbound-rate-limit { 5030 type decimal64 { 5031 fraction-digits 5; 5032 range "0..100"; 5033 } 5034 units "percent"; 5035 description 5036 "Specifies whether/how to rate-limit the 5037 outbound traffic matching this QoS policy. 5038 It is expressed as a percent of the value 5039 that is indicated in 'output-bandwidth'."; 5040 } 5041 } 5042 } 5043 container qos-profile { 5044 description 5045 "QoS profile configuration."; 5046 list qos-profile { 5047 key "profile"; 5048 description 5049 "QoS profile. 5050 Can be standard profile or customized 5051 profile."; 5052 leaf profile { 5053 type leafref { 5054 path "/l3vpn-ntw/vpn-profiles" 5055 + "/valid-provider-identifiers" 5056 + "/qos-profile-identifier/id"; 5057 } 5058 description 5059 "QoS profile to be used."; 5060 } 5061 leaf direction { 5062 type identityref { 5063 base vpn-common:qos-profile-direction; 5064 } 5065 default "vpn-common:both"; 5066 description 5067 "The direction to which the QoS profile 5068 is applied."; 5069 } 5070 } 5071 } 5072 } 5073 container carriers-carrier { 5074 if-feature "vpn-common:carriers-carrier"; 5075 description 5076 "This container is used when the customer 5077 provides MPLS-based services. This is 5078 only used in the case of CsC (i.e., a 5079 customer builds an MPLS service using an 5080 IP VPN to carry its traffic)."; 5081 leaf signaling-type { 5082 type enumeration { 5083 enum ldp { 5084 description 5085 "Use LDP as the signaling protocol 5086 between the PE and the CE. In this 5087 case, an IGP routing protocol must 5088 also be configured."; 5089 } 5090 enum bgp { 5091 description 5092 "Use BGP as the signaling protocol 5093 between the PE and the CE. 5094 In this case, BGP must also be configured 5095 as the routing protocol."; 5096 reference 5097 "RFC 8277: Using BGP to Bind MPLS Labels 5098 to Address Prefixes"; 5099 } 5100 } 5101 default "bgp"; 5102 description 5103 "MPLS signaling type."; 5104 } 5105 } 5106 container ntp { 5107 description 5108 "Time synchronization may be needed in some 5109 VPNs such as infrastructure and Management 5110 VPNs. This container includes parameters to 5111 enable NTP service."; 5112 reference 5113 "RFC 5905: Network Time Protocol Version 4: 5114 Protocol and Algorithms 5115 Specification"; 5116 leaf broadcast { 5117 type enumeration { 5118 enum client { 5119 description 5120 "The VPN node will listen to NTP broadcast 5121 messages on this VPN network access."; 5122 } 5123 enum server { 5124 description 5125 "The VPN node will behave as a broadcast 5126 server."; 5127 } 5128 } 5129 description 5130 "Indicates NTP broadcast mode to use for the 5131 VPN network access."; 5132 } 5133 container auth-profile { 5134 description 5135 "Pointer to a local profile."; 5136 leaf profile-id { 5137 type string; 5138 description 5139 "A pointer to a local authentication 5140 profile on the VPN node is provided."; 5141 } 5142 } 5143 uses vpn-common:service-status; 5144 } 5145 container multicast { 5146 if-feature "vpn-common:multicast"; 5147 description 5148 "Multicast parameters for the network 5149 access."; 5150 leaf access-type { 5151 type enumeration { 5152 enum receiver-only { 5153 description 5154 "The peer site only has receivers."; 5155 } 5156 enum source-only { 5157 description 5158 "The peer site only has sources."; 5159 } 5160 enum source-receiver { 5161 description 5162 "The peer site has both sources and 5163 receivers."; 5164 } 5165 } 5166 default "source-receiver"; 5167 description 5168 "Type of multicast site."; 5170 } 5171 leaf address-family { 5172 type identityref { 5173 base vpn-common:address-family; 5174 } 5175 description 5176 "Indicates the address family."; 5177 } 5178 leaf protocol-type { 5179 type enumeration { 5180 enum host { 5181 description 5182 "Hosts are directly connected to the 5183 provider network. 5185 Host protocols such as IGMP or MLD are 5186 required."; 5187 } 5188 enum router { 5189 description 5190 "Hosts are behind a customer router. 5191 PIM will be implemented."; 5192 } 5193 enum both { 5194 description 5195 "Some hosts are behind a customer router, 5196 and some others are directly connected 5197 to the provider network. Both host and 5198 routing protocols must be used. 5200 Typically, IGMP and PIM will be 5201 implemented."; 5202 } 5203 } 5204 default "both"; 5205 description 5206 "Multicast protocol type to be used with 5207 the customer site."; 5208 } 5209 leaf remote-source { 5210 type boolean; 5211 default "false"; 5212 description 5213 "When true, there is no PIM adjacency on 5214 the interface."; 5215 } 5216 container igmp { 5217 when "../protocol-type = 'host' and " 5218 + "../address-family = 'vpn-common:ipv4' or " 5219 + "'vpn-common:dual-stack'"; 5220 if-feature "vpn-common:igmp"; 5221 description 5222 "Includes IGMP-related parameters."; 5223 list static-group { 5224 key "group-addr"; 5225 description 5226 "Multicast static source/group associated to 5227 to IGMP session"; 5228 leaf group-addr { 5229 type rt-types:ipv4-multicast-group-address; 5230 description 5231 "Multicast group IPv4 addresss."; 5232 } 5233 leaf source-addr { 5234 type rt-types:ipv4-multicast-source-address; 5235 description 5236 "Multicast source IPv4 addresss."; 5237 } 5238 } 5239 leaf max-groups { 5240 type uint32; 5241 description 5242 "Indicates the maximum groups."; 5243 } 5244 leaf max-entries { 5245 type uint32; 5246 description 5247 "Indicates the maximum IGMP entries."; 5248 } 5249 leaf max-group-sources { 5250 type uint32; 5251 description 5252 "The maximum number of group sources."; 5253 } 5254 leaf version { 5255 type identityref { 5256 base vpn-common:igmp-version; 5257 } 5258 default "vpn-common:igmpv2"; 5259 description 5260 "Version of the IGMP."; 5261 } 5262 uses vpn-common:service-status; 5263 } 5264 container mld { 5265 when "../protocol-type = 'host' and " 5266 + "../address-family = 'vpn-common:ipv6' or " 5267 + "'vpn-common:dual-stack'"; 5268 if-feature "vpn-common:mld"; 5269 description 5270 "Includes MLD-related parameters."; 5271 list static-group { 5272 key "group-addr"; 5273 description 5274 "Multicast static source/group associated to 5275 the MLD session"; 5276 leaf group-addr { 5277 type rt-types:ipv6-multicast-group-address; 5278 description 5279 "Multicast group IPv6 addresss."; 5280 } 5281 leaf source-addr { 5282 type rt-types:ipv6-multicast-source-address; 5283 description 5284 "Multicast source IPv6 addresss."; 5285 } 5286 } 5287 leaf max-groups { 5288 type uint32; 5289 description 5290 "Indicates the maximum groups."; 5291 } 5292 leaf max-entries { 5293 type uint32; 5294 description 5295 "Indicates the maximum MLD entries."; 5296 } 5297 leaf max-group-sources { 5298 type uint32; 5299 description 5300 "The maximum number of group sources."; 5301 } 5302 leaf version { 5303 type identityref { 5304 base vpn-common:mld-version; 5305 } 5306 default "vpn-common:mldv2"; 5307 description 5308 "Version of the MLD protocol."; 5309 } 5310 uses vpn-common:service-status; 5311 } 5312 container pim { 5313 when "../protocol-type = 'router'"; 5314 if-feature "vpn-common:pim"; 5315 description 5316 "Only applies when protocol type is PIM."; 5317 leaf hello-interval { 5318 type rt-types:timer-value-seconds16; 5319 default "30"; 5320 description 5321 "PIM hello-messages interval. If set to 5322 'infinity' or 'not-set', no periodic 5323 Hello messages are sent."; 5324 reference 5325 "RFC 7761: Protocol Independent Multicast - 5326 Sparse Mode (PIM-SM): Protocol 5327 Specification (Revised), 5328 Section 4.11"; 5329 } 5330 leaf dr-priority { 5331 type uint32; 5332 default "1"; 5333 description 5334 "Indicates the preference in the DR election 5335 process. Numerically larger DR priority 5336 allows a node to be elected as a DR."; 5337 reference 5338 "RFC 7761: Protocol Independent Multicast - 5339 Sparse Mode (PIM-SM): Protocol 5340 Specification (Revised), 5341 Section 4.3.2"; 5342 } 5343 uses vpn-common:service-status; 5344 } 5345 } 5346 } 5347 } 5348 } 5349 } 5350 } 5351 } 5352 } 5353 } 5354 } 5355 5357 9. Security Considerations 5359 The YANG module specified in this document defines schema for data 5360 that is designed to be accessed via network management protocols such 5361 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 5362 is the secure transport layer, and the mandatory-to-implement secure 5363 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 5364 is HTTPS, and the mandatory-to-implement secure transport is TLS 5365 [RFC8446]. 5367 The Network Configuration Access Control Model (NACM) [RFC8341] 5368 provides the means to restrict access for particular NETCONF or 5369 RESTCONF users to a preconfigured subset of all available NETCONF or 5370 RESTCONF protocol operations and content. 5372 There are a number of data nodes defined in this YANG module that are 5373 writable/creatable/deletable (i.e., config true, which is the 5374 default). These data nodes may be considered sensitive or vulnerable 5375 in some network environments. Write operations (e.g., edit-config) 5376 and delete operations to these data nodes without proper protection 5377 or authentication can have a negative effect on network operations. 5378 These are the subtrees and data nodes and their sensitivity/ 5379 vulnerability in the "ietf-l3vpn-ntw" module: 5381 o 'vpn-service': An attacker who is able to access network nodes can 5382 undertake various attacks, such as deleting a running L3VPN 5383 service, interrupting all the traffic of a client. In addition, 5384 an attacker may modify the attributes of a running service (e.g., 5385 QoS, bandwidth, routing protocols), leading to malfunctioning of 5386 the service and therefore to SLA violations. In addition, an 5387 attacker could attempt to create an L3VPN service or adding a new 5388 network access. In addition to using NACM to prevent authorized 5389 access, such activity can be detected by adequately monitoring and 5390 tracking network configuration changes. 5392 Some readable data nodes in this YANG module may be considered 5393 sensitive or vulnerable in some network environments. It is thus 5394 important to control read access (e.g., via get, get-config, or 5395 notification) to these data nodes. These are the subtrees and data 5396 nodes and their sensitivity/vulnerability: 5398 o 'customer-name' and 'ip-connection': An attacker can retrieve 5399 privacy-related information which can be used to track a customer. 5400 Disclosing such information may be considered as a violation of 5401 the customer-provider trust relationship. 5403 Several data nodes defined in the L3NM rely upon [RFC8177] for 5404 authentication purposes. Therefore, this module inherits the 5405 security considerations discussed in Section 5 of [RFC8177]. 5407 The following summarizes the foreseen risks of using the "ietf-l3vpn- 5408 ntw" module can be classified into: 5410 o Malicious clients attempting to delete or modify VPN services. 5412 o Unauthorized clients attempting to create/modify/delete a VPN 5413 service. 5415 o Unauthorized clients attempting to read VPN service related 5416 information. 5418 10. IANA Considerations 5420 This document requests IANA to register the following URI in the "ns" 5421 subregistry within the "IETF XML Registry" [RFC3688]: 5423 URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw 5424 Registrant Contact: The IESG. 5425 XML: N/A; the requested URI is an XML namespace. 5427 This document requests IANA to register the following YANG module in 5428 the "YANG Module Names" subregistry [RFC6020] within the "YANG 5429 Parameters" registry. 5431 name: ietf-l3vpn-ntw 5432 namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw 5433 maintained by IANA: N 5434 prefix: l3nm 5435 reference: RFC XXXX 5437 11. References 5439 11.1. Normative References 5441 [I-D.ietf-opsawg-vpn-common] 5442 Barguil, S., Dios, O. G. D., Boucadair, M., and Q. Wu, "A 5443 Layer 2/3 VPN Common YANG Model", draft-ietf-opsawg-vpn- 5444 common-07 (work in progress), April 2021. 5446 [ISO10589] 5447 ISO, "Intermediate System to Intermediate System intra- 5448 domain routeing information exchange protocol for use in 5449 conjunction with the protocol for providing the 5450 connectionless-mode network service (ISO 8473)", 2002, 5451 . 5453 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 5454 RFC 1112, DOI 10.17487/RFC1112, August 1989, 5455 . 5457 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 5458 dual environments", RFC 1195, DOI 10.17487/RFC1195, 5459 December 1990, . 5461 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 5462 DOI 10.17487/RFC2080, January 1997, 5463 . 5465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5466 Requirement Levels", BCP 14, RFC 2119, 5467 DOI 10.17487/RFC2119, March 1997, 5468 . 5470 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 5471 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, 5472 . 5474 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 5475 DOI 10.17487/RFC2453, November 1998, 5476 . 5478 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 5479 Listener Discovery (MLD) for IPv6", RFC 2710, 5480 DOI 10.17487/RFC2710, October 1999, 5481 . 5483 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 5484 Thyagarajan, "Internet Group Management Protocol, Version 5485 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 5486 . 5488 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 5489 DOI 10.17487/RFC3688, January 2004, 5490 . 5492 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 5493 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 5494 DOI 10.17487/RFC3810, June 2004, 5495 . 5497 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 5498 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 5499 DOI 10.17487/RFC4271, January 2006, 5500 . 5502 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 5503 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 5504 2006, . 5506 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 5507 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 5508 . 5510 [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the 5511 Provider/Customer Edge Protocol for BGP/MPLS IP Virtual 5512 Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, 5513 June 2006, . 5515 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 5516 DOI 10.17487/RFC5308, October 2008, 5517 . 5519 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community 5520 Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, 5521 . 5523 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 5524 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 5525 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 5526 2009, . 5528 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 5529 Version 3 for IPv4 and IPv6", RFC 5798, 5530 DOI 10.17487/RFC5798, March 2010, 5531 . 5533 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 5534 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 5535 . 5537 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 5538 "Network Time Protocol Version 4: Protocol and Algorithms 5539 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 5540 . 5542 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 5543 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 5544 June 2010, . 5546 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 5547 the Network Configuration Protocol (NETCONF)", RFC 6020, 5548 DOI 10.17487/RFC6020, October 2010, 5549 . 5551 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 5552 and A. Bierman, Ed., "Network Configuration Protocol 5553 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 5554 . 5556 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 5557 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 5558 . 5560 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 5561 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 5562 2012, . 5564 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 5565 Encodings and Procedures for Multicast in MPLS/BGP IP 5566 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 5567 . 5569 [RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and 5570 M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge 5571 (PE-CE) Routing Protocol", RFC 6565, DOI 10.17487/RFC6565, 5572 June 2012, . 5574 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 5575 RFC 6991, DOI 10.17487/RFC6991, July 2013, 5576 . 5578 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 5579 Authentication Trailer for OSPFv3", RFC 7166, 5580 DOI 10.17487/RFC7166, March 2014, 5581 . 5583 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 5584 "Security Extension for OSPFv2 When Using Manual Key 5585 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 5586 . 5588 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 5589 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 5590 Multicast - Sparse Mode (PIM-SM): Protocol Specification 5591 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 5592 2016, . 5594 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 5595 RFC 7950, DOI 10.17487/RFC7950, August 2016, 5596 . 5598 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 5599 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 5600 . 5602 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5603 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5604 May 2017, . 5606 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 5607 Zhang, "YANG Data Model for Key Chains", RFC 8177, 5608 DOI 10.17487/RFC8177, June 2017, 5609 . 5611 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 5612 "Common YANG Data Types for the Routing Area", RFC 8294, 5613 DOI 10.17487/RFC8294, December 2017, 5614 . 5616 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 5617 Access Control Model", STD 91, RFC 8341, 5618 DOI 10.17487/RFC8341, March 2018, 5619 . 5621 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 5622 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 5623 . 5625 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 5626 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 5627 . 5629 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 5630 Data Model for Layer 2 Virtual Private Network (L2VPN) 5631 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 5632 2018, . 5634 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 5635 "YANG Data Model for Network Access Control Lists (ACLs)", 5636 RFC 8519, DOI 10.17487/RFC8519, March 2019, 5637 . 5639 11.2. Informative References 5641 [I-D.evenwu-opsawg-yang-composed-vpn] 5642 Even, R., Wu, B., Wu, Q., and YingCheng, "YANG Data Model 5643 for Composed VPN Service Delivery", draft-evenwu-opsawg- 5644 yang-composed-vpn-03 (work in progress), March 2019. 5646 [I-D.ietf-bess-evpn-prefix-advertisement] 5647 Rabadan, J., Henderickx, W., Drake, J. E., Lin, W., and A. 5648 Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- 5649 bess-evpn-prefix-advertisement-11 (work in progress), May 5650 2018. 5652 [I-D.ietf-idr-bgp-model] 5653 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 5654 YANG Model for Service Provider Networks", draft-ietf-idr- 5655 bgp-model-10 (work in progress), November 2020. 5657 [I-D.ietf-pim-yang] 5658 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 5659 Y., and F. Hu, "A YANG Data Model for Protocol Independent 5660 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 5661 progress), May 2018. 5663 [I-D.ietf-rtgwg-qos-model] 5664 Choudhary, A., Jethanandani, M., Strahle, N., Aries, E., 5665 and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos- 5666 model-03 (work in progress), February 2021. 5668 [I-D.ietf-teas-enhanced-vpn] 5669 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 5670 Framework for Enhanced Virtual Private Network (VPN+) 5671 Services", draft-ietf-teas-enhanced-vpn-07 (work in 5672 progress), February 2021. 5674 [I-D.ietf-teas-ietf-network-slices] 5675 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 5676 Makhijani, K., Contreras, L. M., and J. Tantsura, 5677 "Framework for IETF Network Slices", draft-ietf-teas-ietf- 5678 network-slices-00 (work in progress), April 2021. 5680 [PYANG] "pyang", November 2020, 5681 . 5683 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 5684 Discovery Protocol (MSDP)", RFC 3618, 5685 DOI 10.17487/RFC3618, October 2003, 5686 . 5688 [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. 5689 Moore, "Policy Quality of Service (QoS) Information 5690 Model", RFC 3644, DOI 10.17487/RFC3644, November 2003, 5691 . 5693 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 5694 Private Network (VPN) Terminology", RFC 4026, 5695 DOI 10.17487/RFC4026, March 2005, 5696 . 5698 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 5699 Provider-Provisioned Virtual Private Networks (PPVPNs)", 5700 RFC 4110, DOI 10.17487/RFC4110, July 2005, 5701 . 5703 [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., 5704 and A. Gonguet, "Framework for Layer 3 Virtual Private 5705 Networks (L3VPN) Operations and Management", RFC 4176, 5706 DOI 10.17487/RFC4176, October 2005, 5707 . 5709 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 5710 G. Heron, "Pseudowire Setup and Maintenance Using the 5711 Label Distribution Protocol (LDP)", RFC 4447, 5712 DOI 10.17487/RFC4447, April 2006, 5713 . 5715 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 5716 Address Autoconfiguration", RFC 4862, 5717 DOI 10.17487/RFC4862, September 2007, 5718 . 5720 [RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco 5721 Systems' Solution for Multicast in BGP/MPLS IP VPNs", 5722 RFC 6037, DOI 10.17487/RFC6037, October 2010, 5723 . 5725 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 5726 Networking: A Perspective from within a Service Provider 5727 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 5728 . 5730 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 5731 Connectivity Provisioning Profile (CPP)", RFC 7297, 5732 DOI 10.17487/RFC7297, July 2014, 5733 . 5735 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 5736 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 5737 Defined Networking (SDN): Layers and Architecture 5738 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 5739 2015, . 5741 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 5742 Code: The Implementation Status Section", BCP 205, 5743 RFC 7942, DOI 10.17487/RFC7942, July 2016, 5744 . 5746 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 5747 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 5748 . 5750 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 5751 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 5752 DOI 10.17487/RFC8299, January 2018, 5753 . 5755 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 5756 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 5757 . 5759 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 5760 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 5761 . 5763 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 5764 and R. Wilton, "Network Management Datastore Architecture 5765 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 5766 . 5768 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 5769 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 5770 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 5771 2018, . 5773 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 5774 Routing Management (NMDA Version)", RFC 8349, 5775 DOI 10.17487/RFC8349, March 2018, 5776 . 5778 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 5779 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 5780 DOI 10.17487/RFC8453, August 2018, 5781 . 5783 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 5784 Vinapamula, S., and Q. Wu, "A YANG Module for Network 5785 Address Translation (NAT) and Network Prefix Translation 5786 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 5787 . 5789 [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and 5790 L. Geng, "A Framework for Automating Service and Network 5791 Management with YANG", RFC 8969, DOI 10.17487/RFC8969, 5792 January 2021, . 5794 Appendix A. L3VPN Examples 5796 A.1. 4G VPN Provisioning Example 5798 L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise 5799 services mainly because several traffic discrimination policies can 5800 be applied within the network to deliver to the mobile customers a 5801 service that meets the SLA requirements. 5803 As it is shown in the Figure 31, typically, an eNodeB (CE) is 5804 directly connected to the access routers of the mobile backhaul and 5805 their logical interfaces (one or many according to the service type) 5806 are configured in a VPN that transports the packets to the mobile 5807 core platforms. In this example, a 'vpn-node' is created with two 5808 'vpn-network-accesses'. 5810 +-------------+ +------------------+ 5811 | | | PE | 5812 | | | 198.51.100.1 | 5813 | eNodeB |>--------/------->|........... | 5814 | | vlan 1 | | | 5815 | |>--------/------->|...... | | 5816 | | vlan 2 | | | | 5817 | | Direct | +-------------+ | 5818 +-------------+ Routing | | vpn-node-id | | 5819 | | 44 | | 5820 | +-------------+ | 5821 | | 5822 +------------------+ 5824 Figure 31: Mobile Backhaul Example 5826 To create an L3VPN service using the L3NM, the following steps can be 5827 followed. 5829 First: Create the 4G VPN service (Figure 32). 5831 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services 5832 Host: example.com 5833 Content-Type: application/yang-data+json 5835 { 5836 "ietf-l3vpn-ntw:vpn-services": { 5837 "vpn-service": [ 5838 { 5839 "vpn-id": "4G", 5840 "customer-name": "mycustomer", 5841 "vpn-service-topology": "custom", 5842 "description": "VPN to deploy 4G services", 5843 "vpn-instance-profiles": { 5844 "vpn-instance-profile": [ 5845 { 5846 "profile-id": "simple-profile", 5847 "local-autonomous-system": 65550, 5848 "rd": "0:65550:1", 5849 "address-family": [ 5850 { 5851 "address-family": "vpn-common:dual-stack", 5852 "vpn-targets": { 5853 "vpn-target": [ 5854 { 5855 "id": "1", 5856 "route-targets": [ 5857 "0:65550:1" 5858 ], 5859 "route-target-type": "both" 5860 } 5861 ] 5862 } 5863 } 5864 ] 5865 } 5866 ] 5867 } 5868 } 5869 ] 5870 } 5871 } 5873 Figure 32: Create VPN Service 5875 Second: Create a VPN node as depicted in Figure 33. In this type of 5876 service, the VPN node is equivalent to the VRF configured in the 5877 physical device ('ne-id'=198.51.100.1). 5879 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ 5880 vpn-services/vpn-service=4G 5881 Host: example.com 5882 Content-Type: application/yang-data+json 5884 { 5885 "ietf-l3vpn-ntw:vpn-nodes": { 5886 "vpn-node": [ 5887 { 5888 "vpn-node-id": "44", 5889 "ne-id": "198.51.100.1", 5890 "active-vpn-instance-profiles": { 5891 "vpn-instance-profile": [ 5892 { 5893 "profile-id": "simple-profile" 5894 } 5895 ] 5896 } 5897 } 5898 ] 5899 } 5900 } 5902 Figure 33: Create VPN Node 5904 Finally, two VPN network accesses are created using the same physical 5905 port ('interface-id'=1/1/1). Each 'vpn-network-access' has a 5906 particular VLAN (1,2) to differentiate the traffic between: Sync and 5907 data (Figure 34). 5909 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ 5910 vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44 5911 content-type: application/yang-data+json 5913 { 5914 "ietf-l3vpn-ntw:vpn-network-accesses": { 5915 "vpn-network-access": [ 5916 { 5917 "id": "1/1/1.1", 5918 "interface-id": "1/1/1", 5919 "description": "Interface SYNC to eNODE-B", 5920 "vpn-network-access-type": "vpn-common:point-to-point", 5921 "vpn-instance-profile": "simple-profile", 5922 "status": { 5923 "admin-status": { 5924 "status": "vpn-common:admin-state-up" 5925 } 5926 }, 5927 "connection": { 5928 "encapsulation": { 5929 "type": "dot1q", 5930 "dot1q": { 5931 "cvlan-id": 1 5932 } 5933 } 5934 }, 5935 "ip-connection": { 5936 "ipv4": { 5937 "local-address": "192.0.2.1", 5938 "prefix-length": 30, 5939 "address-allocation-type": "static-address", 5940 "static-addresses": { 5941 "primary-address": "1", 5942 "address": [ 5943 { 5944 "address-id": "1", 5945 "customer-address": "192.0.2.2" 5946 } 5947 ] 5948 } 5949 }, 5950 "ipv6": { 5951 "local-address": "2001:db8::1", 5952 "prefix-length": 64, 5953 "address-allocation-type": "static-address", 5954 "primary-address": "1", 5955 "address": [ 5956 { 5957 "address-id": "1", 5958 "customer-address": "2001:db8::2" 5959 } 5960 ] 5961 } 5962 }, 5963 "routing-protocols": { 5964 "routing-protocol": [ 5965 { 5966 "id": "1", 5967 "type": "vpn-common:direct" 5968 } 5969 ] 5970 } 5971 }, 5972 { 5973 "id": "1/1/1.2", 5974 "interface-id": "1/1/1", 5975 "description": "Interface DATA to eNODE-B", 5976 "vpn-network-access-type": "vpn-common:point-to-point", 5977 "vpn-instance-profile": "simple-profile", 5978 "status": { 5979 "admin-status": { 5980 "status": "vpn-common:admin-state-up" 5981 } 5982 }, 5983 "connection": { 5984 "encapsulation": { 5985 "type": "dot1q", 5986 "dot1q": { 5987 "cvlan-id": 2 5988 } 5989 } 5990 }, 5991 "ip-connection": { 5992 "ipv4": { 5993 "local-address": "192.0.2.1", 5994 "prefix-length": 30, 5995 "address-allocation-type": "static-address", 5996 "static-addresses": { 5997 "primary-address": "1", 5998 "address": [ 5999 { 6000 "address-id": "1", 6001 "customer-address": "192.0.2.2" 6002 } 6003 ] 6004 } 6005 }, 6006 "ipv6": { 6007 "local-address": "2001:db8::1", 6008 "prefix-length": 64, 6009 "address-allocation-type": "static-address", 6010 "primary-address": "1", 6011 "address": [ 6012 { 6013 "address-id": "1", 6014 "customer-address": "2001:db8::2" 6015 } 6016 ] 6017 } 6018 }, 6019 "routing-protocols": { 6020 "routing-protocol": [ 6021 { 6022 "id": "1", 6023 "type": "vpn-common:direct" 6024 } 6025 ] 6026 } 6027 } 6028 ] 6029 } 6030 } 6032 Figure 34: Create VPN Network Access 6034 A.2. Loopback Interface 6036 An example of loopback interface is depicted in Figure 35. 6038 { 6039 "ietf-l3vpn-ntw:vpn-network-accesses": { 6040 "vpn-network-access": [ 6041 { 6042 "id": "vpn-access-loopback", 6043 "interface-id": "Loopback1", 6044 "description": "An example of loopback interface.", 6045 "vpn-network-access-type": "vpn-common:loopback", 6046 "status": { 6047 "admin-status": { 6048 "status": "vpn-common:admin-state-up" 6049 } 6050 }, 6051 "ip-connection": { 6052 "ipv6": { 6053 "local-address": "2001:db8::4", 6054 "prefix-length": 128 6055 } 6056 } 6057 } 6058 ] 6059 } 6060 } 6062 Figure 35: VPN Network Access with a Loopback Interface (Message 6063 Body) 6065 A.3. Multicast VPN Provisioning Example 6067 IPTV is mainly distributed through multicast over the LANs. In the 6068 following example, PIM-SM is enabled and functional between the PE 6069 and the CE. The PE receives multicast traffic from a CE that is 6070 directly connected to the multicast source. The signaling between PE 6071 and CE is achieved using BGP. Also, RP is statically configured for 6072 a multicast group. 6074 +-----------+ +------+ +------+ +-----------+ 6075 | Multicast |---| CE |--/--| PE |----| Backbone | 6076 | source | +------+ +------+ | IP/MPLS | 6077 +-----------+ +-----------+ 6079 Figure 36: Multicast L3VPN Service Example 6081 An example is provided below to illustrate how to configure a 6082 multicast L3VPN service using the L3NM. 6084 First, the multicast service is created together with a generic VPN 6085 instance profile (see the excerpt of the request message body shown 6086 in Figure 37) 6087 { 6088 "ietf-l3vpn-ntw:vpn-services": { 6089 "vpn-service": [ 6090 { 6091 "vpn-id": "Multicast-IPTV", 6092 "vpn-description": "Multicast IPTV VPN service", 6093 "customer-name": "a-name", 6094 "vpn-service-topology": "vpn-common:hub-spoke", 6095 "vpn-instance-profiles": { 6096 "vpn-instance-profile": [ 6097 { 6098 "profile-id": "multicast", 6099 "role": "ietf-vpn-common:hub-role", 6100 "local-autonomous-system": 65536, 6101 "multicast": { 6102 "rp": { 6103 "rp-group-mappings": { 6104 "rp-group-mapping": [ 6105 { 6106 "id": "1", 6107 "rp-address": "203.0.113.17", 6108 "groups": { 6109 "group": [ 6110 { 6111 "id": "1", 6112 "group-address": "239.130.0.0/15" 6113 } 6114 ] 6115 } 6116 } 6117 ] 6118 }, 6119 "rp-discovery": { 6120 "rp-discovery-type": "vpn-common:static-rp" 6121 } 6122 } 6123 } 6124 } 6125 ] 6126 } 6127 } 6128 ] 6129 } 6130 } 6132 Figure 37: Create Multicast VPN Service (Excerpt of the Message 6133 Request Body) 6135 Then, the VPN nodes are created (see the excerpt of the request 6136 message body shown in Figure 38). In this example, the VPN node will 6137 represent VRF configured in the physical device. 6139 { 6140 "ietf-l3vpn-ntw:vpn-node": [ 6141 { 6142 "vpn-node-id": "500003105", 6143 "description": "VRF-IPTV-MULTICAST", 6144 "ne-id": "198.51.100.10", 6145 "router-id": "198.51.100.10", 6146 "active-vpn-instance-profiles": { 6147 "vpn-instance-profile": [ 6148 { 6149 "profile-id": "multicast", 6150 "rd": "65536:31050202" 6151 } 6152 ] 6153 } 6154 } 6155 ] 6156 } 6158 Figure 38: Create Multicast VPN Node (Excerpt of the Message Request 6159 Body) 6161 Finally, create the VPN network access with multicast enabled (see 6162 the excerpt of the request message body shown in Figure 39). 6164 { 6165 "ietf-l3vpn-ntw:vpn-network-access": { 6166 "id": "1/1/1", 6167 "description": "Connected-to-source", 6168 "vpn-network-access-type": "vpn-common:point-to-point", 6169 "vpn-instance-profile": "multicast", 6170 "status": { 6171 "admin-status": { 6172 "status": "vpn-common:admin-state-up" 6173 }, 6174 "ip-connection": { 6175 "ipv4": { 6176 "local-address": "203.0.113.1", 6177 "prefix-length": 30, 6178 "address-allocation-type": "static-address", 6179 "static-addresses": { 6180 "primary-address": "1", 6181 "address": [ 6182 { 6183 "address-id": "1", 6184 "customer-address": "203.0.113.2" 6185 } 6186 ] 6187 } 6188 } 6189 }, 6190 "routing-protocols": { 6191 "routing-protocol": [ 6192 { 6193 "id": "1", 6194 "type": "vpn-common:bgp-routing", 6195 "bgp": { 6196 "description": "Connected to CE", 6197 "peer-autonomous-system": "65537", 6198 "address-family": "vpn-common:ipv4", 6199 "neighbor": "203.0.113.2" 6200 } 6201 } 6202 ] 6203 }, 6204 "service": { 6205 "inbound-bandwidth": "100000000", 6206 "outbound-bandwidth": "100000000", 6207 "mtu": 1500, 6208 "multicast": { 6209 "access-type": "source-only", 6210 "address-family": "vpn-common:ipv4", 6211 "protocol-type": "router", 6212 "pim": { 6213 "hello-interval": 30, 6214 "status": { 6215 "admin-status": { 6216 "status": "vpn-common:admin-state-up" 6217 } 6218 } 6219 } 6220 } 6221 } 6222 } 6223 } 6224 } 6226 Figure 39: Create VPN Network Access (Excerpt of the Message Request 6227 Body) 6229 Appendix B. Implementation Status 6231 This section records the status of known implementations of the YANG 6232 module defined by this specification at the time of posting of this 6233 document and is based on a proposal described in [RFC7942]. The 6234 description of implementations in this section is intended to assist 6235 the IETF in its decision processes in progressing drafts to RFCs. 6236 Please note that the listing of any individual implementation here 6237 does not imply endorsement by the IETF. Furthermore, no effort has 6238 been spent to verify the information presented here that was supplied 6239 by IETF contributors. This is not intended as, and must not be 6240 construed to be, a catalog of available implementations or their 6241 features. Readers are advised to note that other implementations may 6242 exist. 6244 According to [RFC7942], "this will allow reviewers and working groups 6245 to assign due consideration to documents that have the benefit of 6246 running code, which may serve as evidence of valuable experimentation 6247 and feedback that have made the implemented protocols more mature. 6248 It is up to the individual working groups to use this information as 6249 they see fit". 6251 Note to the RFC Editor: As per [RFC7942] guidelines, please remove 6252 this Implementation Status apendix prior publication. 6254 B.1. Nokia Implementation 6256 Details can be found at: https://github.com/IETF-OPSAWG- 6257 WG/l3nm/blob/master/Implementattion/Nokia.txt 6259 B.2. Huawei Implementation 6261 Details can be found at: https://github.com/IETF-OPSAWG- 6262 WG/l3nm/blob/master/Implementattion/Huawei.txt 6264 B.3. Infinera Implementation 6266 Details can be found at: https://github.com/IETF-OPSAWG- 6267 WG/l3nm/blob/master/Implementattion/Infinera.txt 6269 B.4. Ribbon-ECI Implementation 6271 Details can be found at: https://github.com/IETF-OPSAWG- 6272 WG/l3nm/blob/master/Implementattion/Ribbon-ECI.txt 6274 Acknowledgements 6276 During the discussions of this work, helpful comments, suggestions, 6277 and reviews were received from (listed alphabetically): Raul Arco, 6278 Miguel Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque 6279 Gagliano, Christian Jacquenet, Kireeti Kompella, Julian Lucek, and 6280 Tom Petch. Many thanks to them. Thanks to Philip Eardly for the 6281 review of an early version of the document. 6283 Daniel King, Daniel Voyer, Luay Jalil, and Stephane Litkowski 6284 contributed to early version of the individual submission. 6286 Many thanks to Robert Wilton for the AD review. 6288 This work was supported in part by the European Commission funded 6289 H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727) and Horizon 2020 6290 Secured autonomic traffic management for a Tera of SDN flows 6291 (Teraflow) project (G.A. 101015857). 6293 Contributors 6295 Victor Lopez 6296 Telefonica 6297 Email: victor.lopezalvarez@telefonica.com 6299 Qin Wu 6300 Huawei 6301 Email: bill.wu@huawei.com> 6303 Manuel Julian 6304 Vodafone 6305 Email: manuel-julian.lopez@vodafone.com 6307 Lucia Oliva Ballega 6308 Telefonica 6309 Email: lucia.olivaballega.ext@telefonica.com 6311 Erez Segev 6312 ECI Telecom 6313 Email: erez.segev@ecitele.com> 6315 Paul Sherratt 6316 Gamma Telecom 6317 Email: paul.sherratt@gamma.co.uk 6319 Authors' Addresses 6321 Samier Barguil 6322 Telefonica 6323 Madrid 6324 ES 6326 Email: samier.barguilgiraldo.ext@telefonica.com 6328 Oscar Gonzalez de Dios (editor) 6329 Telefonica 6330 Madrid 6331 ES 6333 Email: oscar.gonzalezdedios@telefonica.com 6335 Mohamed Boucadair (editor) 6336 Orange 6337 Rennes 35000 6338 France 6340 Email: mohamed.boucadair@orange.com 6342 Luis Angel Munoz 6343 Vodafone 6344 ES 6346 Email: luis-angel.munoz@vodafone.com 6348 Alejandro Aguado 6349 Nokia 6350 Madrid 6351 ES 6353 Email: alejandro.aguado_martin@nokia.com