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