idnits 2.17.1 draft-ietf-opsawg-l3sm-l3nm-13.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 87 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 (27 September 2021) is 942 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: 31 March 2022 M. Boucadair, Ed. 6 Orange 7 L. Munoz 8 Vodafone 9 A. Aguado 10 Nokia 11 27 September 2021 13 A Layer 3 VPN Network YANG Model 14 draft-ietf-opsawg-l3sm-l3nm-13 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 31 March 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 . . . . . . . . . . . . . . . . . . . . . . . . . 46 105 7.6.5. Security . . . . . . . . . . . . . . . . . . . . . . 48 106 7.6.6. Services . . . . . . . . . . . . . . . . . . . . . . 48 107 7.6.6.1. Overview . . . . . . . . . . . . . . . . . . . . 48 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 int8 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 {vpn-common:dot1q}? 1235 | | | +--rw tag-type? identityref 1236 | | | +--rw cvlan-id? uint16 1237 | | +--rw priority-tagged 1238 | | | +--rw tag-type? identityref 1239 | | +--rw qinq {vpn-common: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 {vpn-common: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 {vpn-common:rtg-bgp}? 1454 | | ... 1455 | +--rw ospf {vpn-common:rtg-ospf}? 1456 | | ... 1457 | +--rw isis {vpn-common:rtg-isis}? 1458 | | ... 1459 | +--rw rip {vpn-common:rtg-rip}? 1460 | | ... 1461 | +--rw vrrp {vpn-common:rtg-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 The L3NM supports the configuration of one or more IPv4/IPv6 static 1504 routes. Since the same structure is used for both IPv4 and IPv6, it 1505 was considered to have one single container to group both static 1506 entries independently of their address family, but that design was 1507 abandoned to ease the mapping with the structure in [RFC8299]. 1509 7.6.3.1. Static Routing 1511 The L3NM supports the configuration of one or more IPv4/IPv6 static 1512 routes. Since the same structure is used for both IPv4 and IPv6, it 1513 was considered to have one single container to group both static 1514 entries independently of their address family, but that design was 1515 abandoned to ease the mapping with the structure in [RFC8299]. 1517 ... 1518 +--rw routing-protocols 1519 | +--rw routing-protocol* [id] 1520 | ... 1521 | +--rw static 1522 | | +--rw cascaded-lan-prefixes 1523 | | +--rw ipv4-lan-prefixes* 1524 | | | [lan next-hop] 1525 | | | {vpn-common:ipv4}? 1526 | | | +--rw lan inet:ipv4-prefix 1527 | | | +--rw lan-tag? string 1528 | | | +--rw next-hop union 1529 | | | +--rw bfd-enable? boolean 1530 | | | +--rw metric? uint32 1531 | | | +--rw preference? uint32 1532 | | | +--rw status 1533 | | | +--rw admin-status 1534 | | | | +--rw status? identityref 1535 | | | | +--rw last-change? yang:date-and-time 1536 | | | +--ro oper-status 1537 | | | +--ro status? identityref 1538 | | | +--ro last-change? yang:date-and-time 1539 | | +--rw ipv6-lan-prefixes* 1540 | | [lan next-hop] 1541 | | {vpn-common:ipv6}? 1542 | | +--rw lan inet:ipv6-prefix 1543 | | +--rw lan-tag? string 1544 | | +--rw next-hop union 1545 | | +--rw bfd-enable? boolean 1546 | | +--rw metric? uint32 1547 | | +--rw preference? uint32 1548 | | +--rw status 1549 | | +--rw admin-status 1550 | | | +--rw status? identityref 1551 | | | +--rw last-change? yang:date-and-time 1552 | | +--ro oper-status 1553 | | +--ro status? identityref 1554 | | +--ro last-change? yang:date-and-time 1555 ... 1557 Figure 15: Static Routing Subtree Structure 1559 As depicted in Figure 15, the following data nodes can be defined for 1560 a given IP prefix: 1562 'lan-tag': Indicates a local tag (e.g., "myfavourite-lan") that is 1563 used to enforce local policies. 1565 'next-hop': Indicates the next-hop to be used for the static route. 1566 It can be identified by an IP address, an interface, etc. 1568 'bfd-enable': Indicates whether BFD is enabled or disabled for this 1569 static route entry. 1571 'metric': Indicates the metric associated with the static route 1572 entry. 1574 'preference': Indicates the preference associated with the static 1575 route entry. This preference is used to selecting a preferred 1576 route among routes to the same destination prefix. 1578 'status': Used to convey the status of a static route entry. This 1579 data node can also be used to control the (de)activation of 1580 individual static route entries. 1582 7.6.3.2. BGP 1584 The L3NM allows the configuration of a BGP neighbor, including a set 1585 for parameters that are pertinent to be tweaked at the network level 1586 for service customization purposes. The 'bgp' container does not aim 1587 to include every BGP parameter; a comprehensive set of parameters 1588 belongs more to the BGP device model. The following data nodes are 1589 captured in 1591 ... 1592 +--rw routing-protocols 1593 | +--rw routing-protocol* [id] 1594 | ... 1595 | +--rw bgp {vpn-common:rtg-bgp}? 1596 | | +--rw description? string 1597 | | +--rw local-as? inet:as-number 1598 | | +--rw peer-as inet:as-number 1599 | | +--rw address-family? identityref 1600 | | +--rw local-address? union 1601 | | +--rw neighbor* inet:ip-address 1602 | | +--rw multihop? uint8 1603 | | +--rw as-override? boolean 1604 | | +--rw allow-own-as? uint8 1605 | | +--rw prepend-global-as? boolean 1606 | | +--rw send-default-route? boolean 1607 | | +--rw site-of-origin? rt-types:route-origin 1608 | | +--rw ipv6-site-of-origin? rt-types:ipv6-route-origin 1609 | | +--rw redistribute-connected* [address-family] 1610 | | | +--rw address-family identityref 1611 | | | +--rw enable? boolean 1612 | | +--rw bgp-max-prefix 1613 | | | +--rw max-prefix? uint32 1614 | | | +--rw warning-threshold? decimal64 1615 | | | +--rw violate-action? enumeration 1616 | | | +--rw restart-timer? uint32 1617 | | +--rw bgp-timers 1618 | | | +--rw keepalive? uint16 1619 | | | +--rw hold-time? uint16 1620 | | +--rw authentication 1621 | | | +--rw enable? boolean 1622 | | | +--rw keying-material 1623 | | | +--rw (option)? 1624 | | | +--:(ao) 1625 | | | | +--rw enable-ao? boolean 1626 | | | | +--rw ao-keychain? key-chain:key-chain-ref 1627 | | | +--:(md5) 1628 | | | | +--rw md5-keychain? key-chain:key-chain-ref 1629 | | | +--:(explicit) 1630 | | | | +--rw key-id? uint32 1631 | | | | +--rw key? string 1632 | | | | +--rw crypto-algorithm? identityref 1633 | | | +--:(ipsec) 1634 | | | +--rw sa? string 1635 | | +--rw status 1636 | | +--rw admin-status 1637 | | | +--rw status? identityref 1638 | | | +--rw last-change? yang:date-and-time 1639 | | +--ro oper-status 1640 | | +--ro status? identityref 1641 | | +--ro last-change? yang:date-and-time 1642 ... 1644 Figure 16: BGP Routing Subtree Structure 1646 Figure 16. It is up to the implementation (e.g., network 1647 orchestrator) to derive the corresponding BGP device configuration: 1649 'description': Includes a description of the BGP session. 1651 'local-as': Indicates a local AS Number (ASN) if a distinct ASN is 1652 required, other than the one configured at the VPN node level. 1654 'peer-as': Conveys the customer's ASN. 1656 'address-family': Indicates the address-family of the peer. It can 1657 be set to IPv4, IPv6, or dual-stack. 1659 This address family will be used together with the 'vpn-type' to 1660 derive the appropriate Address Family Identifiers 1661 (AFIs)/Subsequent Address Family Identifiers (SAFIs) that will be 1662 part of the derived device configurations (e.g., Unicast IPv4 MPLS 1663 L3VPN (AFI,SAFI = 1,128) defined in Section 4.3.4 of [RFC4364]). 1665 'local-address': Specifies an address or a reference to an interface 1666 to use when establishing the BGP transport session. 1668 'neighbor': Can indicate two neighbors (each for a given address- 1669 family) or one neighbor (if 'address-family' attribute is set to 1670 dual-stack). A list of IP address(es) of the BGP neighbors can be 1671 then conveyed in this data node. 1673 'multihop': Indicates the number of allowed IP hops between a PE and 1674 its BGP peer. 1676 'as-override': If set, this parameter indicates whether ASN override 1677 is enabled, i.e., replace the ASN of the customer specified in the 1678 AS_PATH BGP attribute with the ASN identified in the 'local-as' 1679 attribute. 1681 'allow-own-as': Is used in some topologies (e.g., hub-and-spoke) to 1682 allow the provider's ASN to be included in the AS_PATH BGP 1683 attribute received from a CE. Loops are prevented by setting 1684 'allow-own-as' to a maximum number of provider's ASN occurrences. 1685 This parameter is set by default to '0' (that is, reject any 1686 AS_PATH attribute that includes the provider's ASN). 1688 'prepend-global-as': When distinct ASNs are configured in the VPN 1689 node and network access levels, this parameter controls whether 1690 the ASN provided at the VPN node level is prepended to the AS_PATH 1691 attribute. 1693 'send-default-route': Controls whether default routes can be 1694 advertised to the peer. 1696 'site-of-origin': Is meant to uniquely identify the set of routes 1697 learned from a site via a particular CE/PE connection and is used 1698 to prevent routing loops (Section 7 of [RFC4364]). The Site of 1699 Origin attribute is encoded as a Route Origin Extended Community. 1701 'ipv6-site-of-origin': Carries an IPv6 Address Specific BGP Extended 1702 Community that is used to indicate the Site of Origin for VRF 1703 information [RFC5701]. It is used to prevent routing loops. 1705 'redistribute-connected': Controls whether the PE-CE link is 1706 advertised to other PEs. 1708 'bgp-max-prefix': Controls the behavior when a prefix maximum is 1709 reached. 1711 'max-prefix': Indicates the maximum number of BGP prefixes 1712 allowed in the BGP session. If the limit is reached, the 1713 action indicated in 'violate-action' will be followed. 1715 'warning-threshold': A warning notification is triggered when 1716 this limit is reached. 1718 'violate-action': Indicates which action to execute when the 1719 maximum number of BGP prefixes is reached. Examples of such 1720 actions are: send a warning message, discard extra paths from 1721 the peer, or restart the session. 1723 'bgp-timers': Two timers can be captured in this container: (1) 1724 'hold-time' which is the time interval that will be used for the 1725 HoldTimer (Section 4.2 of [RFC4271]) when establishing a BGP 1726 session. (2) 'keepalive' which is the time interval for the 1727 KeepAlive timer between a PE and a BGP peer (Section 4.4 of 1728 [RFC4271]). 1730 'authentication': The module adheres to the recommendations in 1731 Section 13.2 of [RFC4364] as it allows enabling TCP-AO [RFC5925] 1732 and accommodates the installed base that makes use of MD5. In 1733 addition, the module includes a provision for the use of IPsec. 1735 This version of the L3NM assumes that TCP-AO specific parameters 1736 are preconfigured as part of the key-chain that is referenced in 1737 the L3NM. No assumption is made about how such a key-chain is 1738 pre-configured. However, the structure of the key-chain should 1739 cover data nodes beyond those in [RFC8177], mainly SendID and 1740 RecvID (Section 3.1 of [RFC5925]). 1742 'status': Indicates the status of the BGP routing instance. 1744 7.6.3.3. OSPF 1746 OSPF can be configured to run as a routing protocol on the 'vpn- 1747 network-access'. 1749 ... 1750 +--rw routing-protocols 1751 | +--rw routing-protocol* [id] 1752 | ... 1753 | +--rw ospf {vpn-common:rtg-ospf}? 1754 | | +--rw address-family? identityref 1755 | | +--rw area-id yang:dotted-quad 1756 | | +--rw metric? uint16 1757 | | +--rw sham-links {vpn-common:rtg-ospf-sham-link}? 1758 | | | +--rw sham-link* [target-site] 1759 | | | +--rw target-site 1760 | | | | vpn-common:vpn-id 1761 | | | +--rw metric? uint16 1762 | | +--rw max-lsa? uint32 1763 | | +--rw authentication 1764 | | | +--rw enable? boolean 1765 | | | +--rw keying-material 1766 | | | +--rw (option)? 1767 | | | +--:(auth-key-chain) 1768 | | | | +--rw key-chain? 1769 | | | | key-chain:key-chain-ref 1770 | | | +--:(auth-key-explicit) 1771 | | | | +--rw key-id? uint32 1772 | | | | +--rw key? string 1773 | | | | +--rw crypto-algorithm? 1774 | | | | identityref 1775 | | | +--:(ipsec) 1776 | | | +--rw sa? string 1777 | | +--rw status 1778 | | +--rw admin-status 1779 | | | +--rw status? identityref 1780 | | | +--rw last-change? yang:date-and-time 1781 | | +--ro oper-status 1782 | | +--ro status? identityref 1783 | | +--ro last-change? yang:date-and-time 1784 ... 1786 Figure 17: OPSF Routing Subtree Structure 1788 The following data nodes are captured in Figure 17: 1790 'address-family': Indicates whether IPv4, IPv6, or both address 1791 families are to be activated. 1793 When the IPv4 or dual-stack address-family is requested, it is up 1794 to the implementation (e.g., network orchestrator) to decide 1795 whether OSPFv2 [RFC4577] or OSPFv3 [RFC6565] is used to announce 1796 IPv4 routes. Such decision will be typically reflected in the 1797 device configurations that will be derived to implement the L3VPN. 1799 'area-id': Indicates the OSPF Area ID. 1801 'metric': Associates a metric with OSPF routes. 1803 'sham-links': Is used to create OSPF sham links between two VPN 1804 network accesses sharing the same area and having a backdoor link 1805 (Section 4.2.7 of [RFC4577] and Section 5 of [RFC6565]). 1807 'max-lsa': Sets the maximum number of LSAs that the OSPF instance 1808 will accept. 1810 'authentication': Controls the authentication schemes to be enabled 1811 for the OSPF instance. The following options are supported: IPsec 1812 for OSPFv3 authentication [RFC4552], authentication trailer for 1813 OSPFv2 [RFC5709] [RFC7474] and OSPFv3 [RFC7166]. 1815 'status': Indicates the status of the OSPF routing instance. 1817 7.6.3.4. IS-IS 1819 The model (Figure 18) allows the user to configure IS-IS 1820 [ISO10589][RFC1195][RFC5308] to run on the 'vpn-network-access' 1821 interface. 1823 ... 1824 +--rw routing-protocols 1825 | +--rw routing-protocol* [id] 1826 | ... 1827 | +--rw isis {vpn-common:rtg-isis}? 1828 | | +--rw address-family? identityref 1829 | | +--rw area-address area-address 1830 | | +--rw level? identityref 1831 | | +--rw metric? uint16 1832 | | +--rw mode? enumeration 1833 | | +--rw authentication 1834 | | | +--rw enable? boolean 1835 | | | +--rw keying-material 1836 | | | +--rw (option)? 1837 | | | +--:(auth-key-chain) 1838 | | | | +--rw key-chain? 1839 | | | | key-chain:key-chain-ref 1840 | | | +--:(auth-key-explicit) 1841 | | | +--rw key-id? uint32 1842 | | | +--rw key? string 1843 | | | +--rw crypto-algorithm? identityref 1844 | | +--rw status 1845 | | +--rw admin-status 1846 | | | +--rw status? identityref 1847 | | | +--rw last-change? yang:date-and-time 1848 | | +--ro oper-status 1849 | | +--ro status? identityref 1850 | | +--ro last-change? yang:date-and-time 1851 ... 1853 Figure 18: IS-IS Routing Subtree Structure 1855 The following IS-IS data nodes are supported: 1857 'address-family': Indicates whether IPv4, IPv6, or both address 1858 families are to be activated. 1860 'area-address': Indicates the IS-IS area address. 1862 'level': Indicates the IS-IS level: Level 1, Level 2, or both. 1864 'metric': Associates a metric with IS-IS routes. 1866 'mode': Indicates the IS-IS interface mode type. It can be set to 1867 'active' (that is, send or receive IS-IS protocol control packets) 1868 or 'passive' (that is, suppress the sending of IS-IS updates 1869 through the interface). 1871 'authentication': Controls the authentication schemes to be enabled 1872 for the IS-IS instance. Both the specification of a key-chain 1873 [RFC8177] and the direct specification of key and authentication 1874 algorithm are supported. 1876 'status': Indicates the status of the OSPF routing instance. 1878 7.6.3.5. RIP 1880 The model (As shown in Figure 19) allows the user to configure RIP to 1881 run on the 'vpn-network-access' interface. 1883 ... 1884 +--rw routing-protocols 1885 | +--rw routing-protocol* [id] 1886 | ... 1887 | +--rw rip {vpn-common:rtg-rip}? 1888 | | +--rw address-family? identityref 1889 | | +--rw timers 1890 | | | +--rw update-interval? uint16 1891 | | | +--rw invalid-interval? uint16 1892 | | | +--rw holddown-interval? uint16 1893 | | | +--rw flush-interval? uint16 1894 | | +--rw neighbor* inet:ip-address 1895 | | +--rw default-metric? uint8 1896 | | +--rw authentication 1897 | | | +--rw enable? boolean 1898 | | | +--rw keying-material 1899 | | | +--rw (option)? 1900 | | | +--:(auth-key-chain) 1901 | | | | +--rw key-chain? 1902 | | | | key-chain:key-chain-ref 1903 | | | +--:(auth-key-explicit) 1904 | | | +--rw key? string 1905 | | | +--rw crypto-algorithm? identityref 1906 | | +--rw status 1907 | | +--rw admin-status 1908 | | | +--rw status? identityref 1909 | | | +--rw last-change? yang:date-and-time 1910 | | +--ro oper-status 1911 | | +--ro status? identityref 1912 | | +--ro last-change? yang:date-and-time 1913 ... 1915 Figure 19: RIP Subtree Structure 1917 Figure 19, the following RIP data nodes are supported: 1919 'address-family': Indicates whether IPv4, IPv6, or both address 1920 families are to be activated. This parameter is used to determine 1921 whether RIPv2 [RFC2453] and/or RIPng are to be enabled [RFC2080]. 1923 'timers': Indicates the following timers: 1925 'update-interval': Is the interval at which RIP updates are sent. 1927 'invalid-interval': Is the interval before a RIP route is 1928 declared invalid. 1930 'holddown-interval': Is the interval before better RIP routes are 1931 released. 1933 'flush-interval': Is the interval before a route is removed from 1934 the routing table. 1936 'default-metric': Sets the default RIP metric. 1938 'authentication': Controls the authentication schemes to be enabled 1939 for the RIP instance. 1941 'status': Indicates the status of the RIP routing instance. 1943 7.6.3.6. VRRP 1945 The model (The following data nodes are supported:Figure 20) allows 1946 enabling VRRP on the 'vpn-network-access' interface. 1948 ... 1949 +--rw routing-protocols 1950 | +--rw routing-protocol* [id] 1951 | ... 1952 | +--rw vrrp {vpn-common:rtg-vrrp}? 1953 | +--rw address-family* identityref 1954 | +--rw vrrp-group? uint8 1955 | +--rw backup-peer? inet:ip-address 1956 | +--rw virtual-ip-address* inet:ip-address 1957 | +--rw priority? uint8 1958 | +--rw ping-reply? boolean 1959 | +--rw status 1960 | +--rw admin-status 1961 | | +--rw status? identityref 1962 | | +--rw last-change? yang:date-and-time 1963 | +--ro oper-status 1964 | +--ro status? identityref 1965 | +--ro last-change? yang:date-and-time 1966 ... 1968 Figure 20: VRRP Subtree Structure 1970 'address-family': Indicates whether IPv4, IPv6, or both address 1971 families are to be activated. Note that VRRP version 3 [RFC5798] 1972 supports both IPv4 and IPv6. 1974 'vrrp-group': Is used to identify the VRRP group. 1976 'backup-peer': Carries the IP address of the peer. 1978 'virtual-ip-address': Includes virtual IP addresses for a single 1979 VRRP group. 1981 'priority': Assigns the VRRP election priority for the backup 1982 virtual router. 1984 'ping-reply': Controls whether ping requests can be replied to. 1986 'status': Indicates the status of the VRRP instance. 1988 Note that no authentication data node is included for VRRP as there 1989 isn't currently any type of VRRP authentication (see Section 9 of 1990 [RFC5798]). 1992 7.6.4. OAM 1994 This container (Figure 21) defines the Operations, Administration, 1995 and Maintenance (OAM) mechanisms used for a VPN network access. In 1996 the current version of the L3NM, only BFD is supported. 1998 ... 1999 +--rw oam 2000 | +--rw bfd {vpn-common:bfd}? 2001 | +--rw session-type? identityref 2002 | +--rw desired-min-tx-interval? uint32 2003 | +--rw required-min-rx-interval? uint32 2004 | +--rw local-multiplier? uint8 2005 | +--rw holdtime? uint32 2006 | +--rw profile? leafref 2007 | +--rw authentication! 2008 | | +--rw key-chain? key-chain:key-chain-ref 2009 | | +--rw meticulous? boolean 2010 | +--rw status 2011 | +--rw admin-status 2012 | | +--rw status? identityref 2013 | | +--rw last-change? yang:date-and-time 2014 | +--ro oper-status 2015 | +--ro status? identityref 2016 | +--ro last-change? yang:date-and-time 2017 ... 2019 Figure 21: IP Connection Subtree Structure (OAM) 2021 The following OAM data nodes can be specified: 2023 'session-type': Indicates which BFD flavor is used to set up the 2024 session (e.g., classic BFD [RFC5880], Seamless BFD [RFC7880]). By 2025 default, the BFD session is assumed to follow the behavior 2026 specified in [RFC5880]. 2028 'desired-min-tx-interval': Is the minimum interval, in microseconds, 2029 that a PE would like to use when transmitting BFD Control packets 2030 less any jitter applied. 2032 'required-min-rx-interval': Is the minimum interval, in 2033 microseconds, between received BFD Control packets that a PE is 2034 capable of supporting, less any jitter applied by the sender. 2036 'local-multiplier': The negotiated transmit interval, multiplied by 2037 this value, provides the detection time for the peer. 2039 'holdtime': Is used to indicate the expected BFD holddown time. 2040 This value may be inherited from the service request (see 2041 Section 6.3.2.2.2 of [RFC8299]). 2043 'profile': Refers to a BFD profile (Section 7.2). Such a profile 2044 can be set by the provider or inherited from the service request 2045 (see Section 6.3.2.2.2 of [RFC8299]). 2047 'authentication': Includes the required information to enable the 2048 BFD authentication modes discussed in Section 6.7 of [RFC5880]. 2049 In particular 'meticulous' controls the activation of the 2050 meticulous mode discussed in Sections 6.7.3 and 6.7.4 of 2051 [RFC5880]. 2053 'status': Indicates the status of BFD. 2055 7.6.5. Security 2057 The 'security' container specifies the authentication and the 2058 encryption to be applied for a given VPN network access traffic. As 2059 depicted in the subtree shown in Figure 22, the L3NM can be used to 2060 directly control the encryption to put in place (e.g., Layer 2 or 2061 Layer 3 encryption) or invoke a local encryption profile. 2063 ... 2064 +--rw vpn-services 2065 +--rw vpn-service* [vpn-id] 2066 ... 2067 +--rw vpn-nodes 2068 +--rw vpn-node* [vpn-node-id] 2069 ... 2070 +--rw vpn-network-accesses 2071 +--rw vpn-network-access* [id] 2072 ... 2073 +--rw security 2074 | +--rw encryption {vpn-common:encryption}? 2075 | | +--rw enabled? boolean 2076 | | +--rw layer? enumeration 2077 | +--rw encryption-profile 2078 | +--rw (profile)? 2079 | +--:(provider-profile) 2080 | | +--rw profile-name? leafref 2081 | +--:(customer-profile) 2082 | +--rw customer-key-chain? 2083 | kc:key-chain-ref 2084 +--rw service 2085 ... 2087 Figure 22: Security Subtree Structure 2089 7.6.6. Services 2091 7.6.6.1. Overview 2093 The 'service' container specifies the service parameters to apply for 2094 a given VPN network access (Figure 23). 2096 ... 2097 +--rw vpn-network-accesses 2098 +--rw vpn-network-access* [id] 2099 ... 2100 +--rw service 2101 +--rw inbound-bandwidth? uint64 {vpn-common:inbound-bw}? 2102 +--rw outbound-bandwidth? uint64 {vpn-common:outbound-bw}? 2103 +--rw mtu? uint32 2104 +--rw qos {vpn-common:qos}? 2105 | ... 2106 +--rw carriers-carrier 2107 | {vpn-common:carriers-carrier}? 2108 | +--rw signaling-type? enumeration 2109 +--rw ntp 2110 | +--rw broadcast? enumeration 2111 | +--rw auth-profile 2112 | | +--rw profile-id? string 2113 | +--rw status 2114 | +--rw admin-status 2115 | | +--rw status? identityref 2116 | | +--rw last-change? yang:date-and-time 2117 | +--ro oper-status 2118 | +--ro status? identityref 2119 | +--ro last-change? yang:date-and-time 2120 +--rw multicast {vpn-common:multicast}? 2121 ... 2123 Figure 23: Services Subtree Structure 2125 The following data nodes are defined: 2127 'inbound-bandwidth': Indicates the inbound bandwidth of the 2128 connection (i.e., download bandwidth from the service provider to 2129 the site). 2131 'outbound-bandwidth': Indicates the outbound bandwidth of the 2132 connection (i.e., upload bandwidth from the site to the service 2133 provider). 2135 'mtu': Indicates the MTU at the service level. 2137 'qos': Is used to define a set of QoS policies to apply on a given 2138 connection (refer to Section 7.6.6.2 for more details). 2140 'carriers-carrier': Groups a set of parameters that are used when 2141 Carriers' Carriers (CsC) is enabled such the use of BGP for 2142 signaling purposes [RFC8277]. 2144 'ntp': Time synchronization may be needed in some VPNs such as 2145 infrastructure and management VPNs. This container is used to 2146 enable the NTP service [RFC5905]. 2148 'multicast': Specifies the multicast mode and other data nodes such 2149 as the address-family. Refer to Section 7.7. 2151 7.6.6.2. QoS 2153 'qos' container is used to define a set of QoS policies to apply on a 2154 given connection (Figure 24). A QoS policy may be a classification 2155 or an action policy. For example, a QoS action can be defined to 2156 rate limit inbound/outbound traffic of a given class of service. 2158 ... 2159 +--rw qos {vpn-common:qos}? 2160 | +--rw qos-classification-policy 2161 | | +--rw rule* [id] 2162 | | +--rw id string 2163 | | +--rw (match-type)? 2164 | | | +--:(match-flow) 2165 | | | | +--rw (l3)? 2166 | | | | | +--:(ipv4) 2167 | | | | | | ... 2168 | | | | | +--:(ipv6) 2169 | | | | | ... 2170 | | | | +--rw (l4)? 2171 | | | | +--:(tcp) 2172 | | | | | ... 2173 | | | | +--:(udp) 2174 | | | | ... 2175 | | | +--:(match-application) 2176 | | | +--rw match-application? 2177 | | | identityref 2178 | | +--rw target-class-id? 2179 | | string 2180 | +--rw qos-action 2181 | | +--rw rule* [id] 2182 | | +--rw id string 2183 | | +--rw target-class-id? string 2184 | | +--rw inbound-rate-limit? decimal64 2185 | | +--rw outbound-rate-limit? decimal64 2186 | +--rw qos-profile 2187 | +--rw qos-profile* [profile] 2188 | +--rw profile leafref 2189 | +--rw direction? identityref 2190 ... 2192 Figure 24: Services Subtree Structure 2194 QoS classification can be based on many criteria such as: 2196 Layer 3: As shown in Figure 25, classification can be based on any 2197 IP header field or a combination thereof. Both IPv4 and IPv6 are 2198 supported. 2200 +--rw qos {vpn-common:qos}? 2201 | +--rw qos-classification-policy 2202 | | +--rw rule* [id] 2203 | | +--rw id string 2204 | | +--rw (match-type)? 2205 | | | +--:(match-flow) 2206 | | | | +--rw (l3)? 2207 | | | | | +--:(ipv4) 2208 | | | | | | +--rw ipv4 2209 | | | | | | +--rw dscp? inet:dscp 2210 | | | | | | +--rw ecn? uint8 2211 | | | | | | +--rw length? uint16 2212 | | | | | | +--rw ttl? uint8 2213 | | | | | | +--rw protocol? uint8 2214 | | | | | | +--rw ihl? uint8 2215 | | | | | | +--rw flags? bits 2216 | | | | | | +--rw offset? uint16 2217 | | | | | | +--rw identification? uint16 2218 | | | | | | +--rw (destination-network)? 2219 | | | | | | | +--:(destination-ipv4-network) 2220 | | | | | | | +--rw destination-ipv4-network? 2221 | | | | | | | inet:ipv4-prefix 2222 | | | | | | +--rw (source-network)? 2223 | | | | | | +--:(source-ipv4-network) 2224 | | | | | | +--rw source-ipv4-network? 2225 | | | | | | inet:ipv4-prefix 2226 | | | | | +--:(ipv6) 2227 | | | | | +--rw ipv6 2228 | | | | | +--rw dscp? inet:dscp 2229 | | | | | +--rw ecn? uint8 2230 | | | | | +--rw length? uint16 2231 | | | | | +--rw ttl? uint8 2232 | | | | | +--rw protocol? uint8 2233 | | | | | +--rw (destination-network)? 2234 | | | | | | +--:(destination-ipv6-network) 2235 | | | | | | +--rw destination-ipv6-network? 2236 | | | | | | inet:ipv6-prefix 2237 | | | | | +--rw (source-network)? 2238 | | | | | | +--:(source-ipv6-network) 2239 | | | | | | +--rw source-ipv6-network? 2240 | | | | | | inet:ipv6-prefix 2241 | | | | | +--rw flow-label? 2242 | | | | | inet:ipv6-flow-label 2243 ... 2245 Figure 25: QoS Subtree Structure (L3) 2247 Layer 4: As discussed in [I-D.ietf-opsawg-vpn-common], any layer 4 2248 protocol can be indicated in the 'protocol' data node under 'l3' 2249 (Figure 25), but only TCP and UDP specific match criteria are 2250 elaborated in this version as these protocols are widely used in 2251 the context of VPN services. Augmentations can be considered in 2252 the future to add other Layer 4 specific data nodes, if needed. 2254 TCP or UDP-related match criteria can be specified in the L3NM as 2255 shown in Figure 26. 2257 As discussed in [I-D.ietf-opsawg-vpn-common], some transport 2258 protocols use existing protocols (e.g., TCP or UDP) as substrate. 2259 The match criteria for such protocols may rely upon the 'protocol' 2260 under 'l3', TCP/UDP match criteria shown in Figure 26, part of the 2261 TCP/UDP payload, or a combination thereof. This version of the 2262 module does not support such advanced match criteria. Future 2263 revisions of the VPN common module or augmentations to the L3NM 2264 may consider adding match criteria based on the transport protocol 2265 payload (e.g., by means of a bitmask match). 2267 +--rw qos {vpn-common:qos}? 2268 | +--rw qos-classification-policy 2269 | | +--rw rule* [id] 2270 | | +--rw id string 2271 | | +--rw (match-type)? 2272 | | | +--:(match-flow) 2273 | | | | +--rw (l3)? 2274 | | | | | ... 2275 | | | | +--rw (l4)? 2276 | | | | +--:(tcp) 2277 | | | | | +--rw tcp 2278 | | | | | +--rw sequence-number? uint32 2279 | | | | | +--rw acknowledgement-number? uint32 2280 | | | | | +--rw data-offset? uint8 2281 | | | | | +--rw reserved? uint8 2282 | | | | | +--rw flags? bits 2283 | | | | | +--rw window-size? uint16 2284 | | | | | +--rw urgent-pointer? uint16 2285 | | | | | +--rw options? binary 2286 | | | | | +--rw (source-port)? 2287 | | | | | | +--:(source-port-range-or-operator) 2288 | | | | | | +--rw source-port-range-or-operator 2289 | | | | | | +--rw (port-range-or-operator)? 2290 | | | | | | +--:(range) 2291 | | | | | | | +--rw lower-port 2292 | | | | | | | | inet:port-number 2293 | | | | | | | +--rw upper-port 2294 | | | | | | | inet:port-number 2295 | | | | | | +--:(operator) 2296 | | | | | | +--rw operator? operator 2297 | | | | | | +--rw port 2298 | | | | | | inet:port-number 2299 | | | | | +--rw (destination-port)? 2300 | | | | +--:(destination-port-range-or-operator) 2301 | | | | | +--rw destination-port-range-or-operator 2302 | | | | | +--rw (port-range-or-operator)? 2303 | | | | | +--:(range) 2304 | | | | | | +--rw lower-port 2305 | | | | | | | inet:port-number 2306 | | | | | | +--rw upper-port 2307 | | | | | | inet:port-number 2308 | | | | | +--:(operator) 2309 | | | | | +--rw operator? operator 2310 | | | | | +--rw port 2311 | | | | | inet:port-number 2312 | | | | +--:(udp) 2313 | | | | +--rw udp 2314 | | | | +--rw length? uint16 2315 | | | | +--rw (source-port)? 2316 | | | | | +--:(source-port-range-or-operator) 2317 | | | | | +--rw source-port-range-or-operator 2318 | | | | | +--rw (port-range-or-operator)? 2319 | | | | | +--:(range) 2320 | | | | | | +--rw lower-port 2321 | | | | | | | inet:port-number 2322 | | | | | | +--rw upper-port 2323 | | | | | | inet:port-number 2324 | | | | | +--:(operator) 2325 | | | | | +--rw operator? operator 2326 | | | | | +--rw port 2327 | | | | | inet:port-number 2328 | | | | +--rw (destination-port)? 2329 | | | | +--:(destination-port-range-or-operator) 2330 | | | | +--rw destination-port-range-or-operator 2331 | | | | +--rw (port-range-or-operator)? 2332 | | | | +--:(range) 2333 | | | | | +--rw lower-port 2334 | | | | | | inet:port-number 2335 | | | | | +--rw upper-port 2336 | | | | | inet:port-number 2337 | | | | +--:(operator) 2338 | | | | +--rw operator? operator 2339 | | | | +--rw port 2340 | | | | inet:port-number 2341 ... 2343 Figure 26: QoS Subtree Structure (L4) 2345 Application match: Relies upon application-specific classification. 2347 7.7. Multicast 2349 Multicast may be enabled for a particular VPN at the VPN node and VPN 2350 network access levels (see Figure 27). Some data nodes (e.g., max- 2351 groups) can be controlled at various levels: VPN service, VPN node 2352 level, or VPN network access. 2354 ... 2355 +--rw vpn-services 2356 +--rw vpn-service* [vpn-id] 2357 ... 2358 +--rw vpn-instance-profiles 2359 | +--rw vpn-instance-profile* [profile-id] 2360 | .... 2361 | +--rw multicast {vpn-common:multicast}? 2362 | ... 2363 +--rw vpn-nodes 2364 +--rw vpn-node* [vpn-node-id] 2365 ... 2366 +--rw active-vpn-instance-profiles 2367 | +--rw vpn-instance-profile* [profile-id] 2368 | ... 2369 | +--rw multicast {vpn-common:multicast}? 2370 | ... 2371 +--rw vpn-network-accesses 2372 +--rw vpn-network-access* [id] 2373 ... 2374 +--rw service 2375 ... 2376 +--rw multicast {vpn-common:multicast}? 2377 ... 2379 Figure 27: Overall Multicast Subtree Structure 2381 Multicast-related data nodes at the VPN instance profile level has 2382 the structure that is shown in Figure 30. 2384 ... 2385 +--rw vpn-services 2386 +--rw vpn-service* [vpn-id] 2387 ... 2388 +--rw vpn-instance-profiles 2389 | +--rw vpn-instance-profile* [profile-id] 2390 | .... 2391 | +--rw multicast {vpn-common:multicast}? 2392 | +--rw tree-flavor? identityref 2393 | +--rw rp 2394 | | +--rw rp-group-mappings 2395 | | | +--rw rp-group-mapping* [id] 2396 | | | +--rw id uint16 2397 | | | +--rw provider-managed 2398 | | | | +--rw enabled? boolean 2399 | | | | +--rw rp-redundancy? boolean 2400 | | | | +--rw optimal-traffic-delivery? boolean 2401 | | | | +--rw anycast 2402 | | | | +--rw local-address? inet:ip-address 2403 | | | | +--rw rp-set-address* inet:ip-address 2404 | | | +--rw rp-address inet:ip-address 2405 | | | +--rw groups 2406 | | | +--rw group* [id] 2407 | | | +--rw id uint16 2408 | | | +--rw (group-format) 2409 | | | +--:(group-prefix) 2410 | | | | +--rw group-address? inet:ip-prefix 2411 | | | +--:(startend) 2412 | | | +--rw group-start? inet:ip-address 2413 | | | +--rw group-end? inet:ip-address 2414 | | +--rw rp-discovery 2415 | | +--rw rp-discovery-type? identityref 2416 | | +--rw bsr-candidates 2417 | | +--rw bsr-candidate-address* inet:ip-address 2418 | +--rw igmp {vpn-common:igmp and vpn-common:ipv4}? 2419 | | +--rw static-group* [group-addr] 2420 | | | +--rw group-addr 2421 | | | | rt-types:ipv4-multicast-group-address 2422 | | | +--rw source-addr? 2423 | | | rt-types:ipv4-multicast-source-address 2424 | | +--rw max-groups? uint32 2425 | | +--rw max-entries? uint32 2426 | | +--rw version? identityref 2427 | +--rw mld {vpn-common:mld and vpn-common:ipv6}? 2428 | | +--rw static-group* [group-addr] 2429 | | | +--rw group-addr 2430 | | | | rt-types:ipv6-multicast-group-address 2431 | | | +--rw source-addr? 2432 | | | rt-types:ipv6-multicast-source-address 2433 | | +--rw max-groups? uint32 2434 | | +--rw max-entries? uint32 2435 | | +--rw version? identityref 2436 | +--rw pim {vpn-common:pim}? 2437 | +--rw hello-interval? rt-types:timer-value-seconds16 2438 | +--rw dr-priority? uint32 2439 ... 2441 Figure 28: Multicast Subtree Structure (VPN Instance Profile Level) 2443 The model supports a single type of tree per VPN access ('tree- 2444 flavor'): Any-Source Multicast (ASM), Source-Specific Multicast 2445 (SSM), or bidirectional. 2447 When ASM is used, the model supports the configuration of Rendezvous 2448 Points (RPs). RP discovery may be 'static', 'bsr-rp', or 'auto-rp'. 2449 When set to 'static', RP to multicast grouping mappings MUST be 2450 configured as part of the 'rp-group-mappings' container. The RP MAY 2451 be a provider node or a customer node. When the RP is a customer 2452 node, the RP address must be configured using the 'rp-address' leaf. 2454 The model supports RP redundancy through the 'rp-redundancy' leaf. 2455 How the redundancy is achieved is out of scope. 2457 When a particular VPN using ASM requires a more optimal traffic 2458 delivery (e.g., requested using [RFC8299]), 'optimal-traffic- 2459 delivery' can be set. When set to 'true', the implementation must 2460 use any mechanism to provide a more optimal traffic delivery for the 2461 customer. For example, anycast is one of the mechanisms to enhance 2462 RPs redundancy, resilience against failures, and to recover from 2463 failures quickly. 2465 The same structure as the one depicted in Figure 30 is used when 2466 configuring multicast-related parameters at the VPN node level. When 2467 defined at the VPN node level (Figure 29), Internet Group Management 2468 Protocol (IGMP) [RFC1112][RFC2236][RFC3376], Multicast Listener 2469 Discovery (MLD) [RFC2710][RFC3810], and Protocol Independent 2470 Multicast (PIM) [RFC7761] parameters are applicable to all VPN 2471 network accesses of that VPN node unless corresponding nodes are 2472 overridden at the VPN network access level. 2474 ... 2475 +--rw vpn-nodes 2476 +--rw vpn-node* [vpn-node-id] 2477 ... 2478 +--rw active-vpn-instance-profiles 2479 | +--rw vpn-instance-profile* [profile-id] 2480 | ... 2481 | +--rw multicast {vpn-common:multicast}? 2482 | +--rw tree-flavor* identityref 2483 | +--rw rp 2484 | | ... 2485 | +--rw igmp {vpn-common:igmp and vpn-common:ipv4}? 2486 | | ... 2487 | +--rw mld {vpn-common:mld and vpn-common:ipv6}? 2488 | | ... 2489 | +--rw pim {vpn-common:pim}? 2490 | ... 2492 Figure 29: Multicast Subtree Structure (VPN Node Level) 2494 Multicast-related data nodes at the VPN network access level are 2495 shown in Figure 30. The values configured at the VPN network access 2496 level override the values configured for the corresponding data nodes 2497 in other levels. 2499 ... 2500 +--rw vpn-network-accesses 2501 +--rw vpn-network-access* [id] 2502 ... 2503 +--rw service 2504 ... 2505 +--rw multicast {vpn-common:multicast}? 2506 +--rw access-type? enumeration 2507 +--rw address-family? identityref 2508 +--rw protocol-type? enumeration 2509 +--rw remote-source? boolean 2510 +--rw igmp {vpn-common:igmp}? 2511 | +--rw static-group* [group-addr] 2512 | | +--rw group-addr 2513 | | rt-types:ipv4-multicast-group-address 2514 | | +--rw source-addr? 2515 | | rt-types:ipv4-multicast-source-address 2516 | +--rw max-groups? uint32 2517 | +--rw max-entries? uint32 2518 | +--rw max-group-sources? uint32 2519 | +--rw version? identityref 2520 | +--rw status 2521 | +--rw admin-status 2522 | | +--rw status? identityref 2523 | | +--rw last-change? yang:date-and-time 2524 | +--ro oper-status 2525 | +--ro status? identityref 2526 | +--ro last-change? yang:date-and-time 2527 +--rw mld {vpn-common:mld}? 2528 | +--rw static-group* [group-addr] 2529 | | +--rw group-addr 2530 | | rt-types:ipv6-multicast-group-address 2531 | | +--rw source-addr? 2532 | | rt-types:ipv6-multicast-source-address 2533 | +--rw max-groups? uint32 2534 | +--rw max-entries? uint32 2535 | +--rw max-group-sources? uint32 2536 | +--rw version? identityref 2537 | +--rw status 2538 | +--rw admin-status 2539 | | +--rw status? identityref 2540 | | +--rw last-change? yang:date-and-time 2541 | +--ro oper-status 2542 | +--ro status? identityref 2543 | +--ro last-change? yang:date-and-time 2544 +--rw pim {vpn-common:pim}? 2545 +--rw hello-interval? rt-types:timer-value-seconds16 2546 +--rw dr-priority? uint32 2547 +--rw status 2548 +--rw admin-status 2549 | +--rw status? identityref 2550 | +--rw last-change? yang:date-and-time 2551 +--ro oper-status 2552 +--ro status? identityref 2553 +--ro last-change? yang:date-and-time 2555 Figure 30: Multicast Subtree Structure (VPN Network Access Level) 2557 8. L3NM YANG Module 2559 This module uses types defined in [RFC6991] and [RFC8343]. It also 2560 uses groupings defined in [RFC8519], [RFC8177], and [RFC8294]. 2562 file "ietf-l3vpn-ntw@2021-09-10.yang" 2563 module ietf-l3vpn-ntw { 2564 yang-version 1.1; 2565 namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw"; 2566 prefix l3nm; 2568 import ietf-vpn-common { 2569 prefix vpn-common; 2570 reference 2571 "RFC UUUU: A Layer 2/3 VPN Common YANG Model"; 2572 } 2573 import ietf-inet-types { 2574 prefix inet; 2575 reference 2576 "RFC 6991: Common YANG Data Types, Section 4"; 2577 } 2578 import ietf-yang-types { 2579 prefix yang; 2580 reference 2581 "RFC 6991: Common YANG Data Types, Section 3"; 2582 } 2583 import ietf-key-chain { 2584 prefix key-chain; 2585 reference 2586 "RFC 8177: YANG Key Chain."; 2587 } 2588 import ietf-routing-types { 2589 prefix rt-types; 2590 reference 2591 "RFC 8294: Common YANG Data Types for the Routing Area"; 2592 } 2593 import ietf-interfaces { 2594 prefix if; 2595 reference 2596 "RFC 8343: A YANG Data Model for Interface Management"; 2597 } 2599 organization 2600 "IETF OPSAWG (Operations and Management Area Working Group)"; 2601 contact 2602 "WG Web: 2603 WG List: 2605 Author: Samier Barguil 2606 2607 Editor: Oscar Gonzalez de Dios 2608 2609 Editor: Mohamed Boucadair 2610 2611 Author: Luis Angel Munoz 2612 2613 Author: Alejandro Aguado 2614 "; 2615 description 2616 "This YANG module defines a generic network-oriented model 2617 for the configuration of Layer 3 Virtual Private Networks. 2619 Copyright (c) 2021 IETF Trust and the persons identified as 2620 authors of the code. All rights reserved. 2622 Redistribution and use in source and binary forms, with or 2623 without modification, is permitted pursuant to, and subject 2624 to the license terms contained in, the Simplified BSD License 2625 set forth in Section 4.c of the IETF Trust's Legal Provisions 2626 Relating to IETF Documents 2627 (http://trustee.ietf.org/license-info). 2629 This version of this YANG module is part of RFC XXXX; see 2630 the RFC itself for full legal notices."; 2632 revision 2021-09-10 { 2633 description 2634 "Initial revision."; 2635 reference 2636 "RFC XXXX: A Layer 3 VPN Network YANG Model"; 2637 } 2639 /* Features */ 2641 feature msdp { 2642 description 2643 "This feature indicates that Multicast Source Discovery Protocol 2644 (MSDP) capabilities are supported by the VPN."; 2645 reference 2646 "RFC 3618: Multicast Source Discovery Protocol (MSDP)"; 2647 } 2649 /* Identities */ 2651 identity address-allocation-type { 2652 description 2653 "Base identity for address allocation type in the 2654 Provider Edge (PE)-Customer Edge (CE) link."; 2655 } 2657 identity provider-dhcp { 2658 base address-allocation-type; 2659 description 2660 "The Provider's network provides a DHCP service to the customer."; 2661 } 2663 identity provider-dhcp-relay { 2664 base address-allocation-type; 2665 description 2666 "The Provider's network provides a DHCP relay service to the 2667 customer."; 2668 } 2670 identity provider-dhcp-slaac { 2671 if-feature "vpn-common:ipv6"; 2672 base address-allocation-type; 2673 description 2674 "The Provider's network provides a DHCP service to the customer 2675 as well as IPv6 Stateless Address Autoconfiguration (SLAAC)."; 2676 reference 2677 "RFC 4862: IPv6 Stateless Address Autoconfiguration"; 2678 } 2680 identity static-address { 2681 base address-allocation-type; 2682 description 2683 "The Provider's network provides static IP addressing to the 2684 customer."; 2685 } 2687 identity slaac { 2688 if-feature "vpn-common:ipv6"; 2689 base address-allocation-type; 2690 description 2691 "The Provider's network uses IPv6 SLAAC to provide addressing 2692 to the customer."; 2693 reference 2694 "RFC 4862: IPv6 Stateless Address Autoconfiguration"; 2695 } 2697 identity local-defined-next-hop { 2698 description 2699 "Base identity of local defined next-hops."; 2700 } 2702 identity discard { 2703 base local-defined-next-hop; 2704 description 2705 "Indicates an action to discard traffic for the 2706 corresponding destination. 2707 For example, this can be used to blackhole traffic."; 2708 } 2710 identity local-link { 2711 base local-defined-next-hop; 2712 description 2713 "Treat traffic towards addresses within the specified next-hop 2714 prefix as though they are connected to a local link."; 2716 } 2718 identity l2-tunnel-type { 2719 description 2720 "Base identity for layer-2 tunnel selection under the VPN 2721 network access."; 2722 } 2724 identity pseudowire { 2725 base l2-tunnel-type; 2726 description 2727 "Pseudowire tunnel termination in the VPN network access."; 2728 } 2730 identity vpls { 2731 base l2-tunnel-type; 2732 description 2733 "Virtual Private LAN Service (VPLS) tunnel termination in 2734 the VPN network access."; 2735 } 2737 identity vxlan { 2738 base l2-tunnel-type; 2739 description 2740 "Virtual eXtensible Local Area Network (VXLAN) tunnel 2741 termination in the VPN network access."; 2742 } 2744 /* Typedefs */ 2746 typedef predefined-next-hop { 2747 type identityref { 2748 base local-defined-next-hop; 2749 } 2750 description 2751 "Pre-defined next-hop designation for locally generated routes."; 2752 } 2754 typedef area-address { 2755 type string { 2756 pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}'; 2757 } 2758 description 2759 "This type defines the area address format."; 2760 } 2762 /* Groupings */ 2763 grouping vpn-instance-profile { 2764 description 2765 "Grouping for data nodes that may be factorized 2766 among many levels of the model. The grouping can 2767 be used to define generic profiles at the VPN service 2768 level and then referenced at the VPN node and VPN 2769 network access levels."; 2770 leaf local-as { 2771 if-feature "vpn-common:rtg-bgp"; 2772 type inet:as-number; 2773 description 2774 "Provider's Autonomous System (AS) number. Used if the 2775 customer requests BGP routing."; 2776 } 2777 uses vpn-common:route-distinguisher; 2778 list address-family { 2779 key "address-family"; 2780 description 2781 "Set of per-address family parameters."; 2782 leaf address-family { 2783 type identityref { 2784 base vpn-common:address-family; 2785 } 2786 description 2787 "Indicates the address family (IPv4 and/or IPv6)."; 2788 } 2789 container vpn-targets { 2790 description 2791 "Set of route targets to match for import and export routes 2792 to/from VRF."; 2793 uses vpn-common:vpn-route-targets; 2794 } 2795 list maximum-routes { 2796 key "protocol"; 2797 description 2798 "Defines the maximum number of routes for the VRF."; 2799 leaf protocol { 2800 type identityref { 2801 base vpn-common:routing-protocol-type; 2802 } 2803 description 2804 "Indicates the routing protocol. 'any' value can 2805 be used to identify a limit that will apply for 2806 each active routing protocol."; 2807 } 2808 leaf maximum-routes { 2809 type uint32; 2810 description 2811 "Indicates the maximum number of prefixes that the 2812 VRF can accept for this address family and protocol."; 2813 } 2814 } 2815 } 2816 container multicast { 2817 if-feature "vpn-common:multicast"; 2818 description 2819 "Global multicast parameters."; 2820 leaf tree-flavor { 2821 type identityref { 2822 base vpn-common:multicast-tree-type; 2823 } 2824 description 2825 "Type of the multicast tree to be used."; 2826 } 2827 container rp { 2828 description 2829 "Rendezvous Point (RP) parameters."; 2830 container rp-group-mappings { 2831 description 2832 "RP-to-group mappings parameters."; 2833 list rp-group-mapping { 2834 key "id"; 2835 description 2836 "List of RP-to-group mappings."; 2837 leaf id { 2838 type uint16; 2839 description 2840 "Unique identifier for the mapping."; 2841 } 2842 container provider-managed { 2843 description 2844 "Parameters for a provider-managed RP."; 2845 leaf enabled { 2846 type boolean; 2847 default "false"; 2848 description 2849 "Set to true if the Rendezvous Point (RP) 2850 must be a provider-managed node. Set to 2851 false if it is a customer-managed node."; 2852 } 2853 leaf rp-redundancy { 2854 type boolean; 2855 default "false"; 2856 description 2857 "If set to true, it indicates that a redundancy 2858 mechanism for the RP is required."; 2860 } 2861 leaf optimal-traffic-delivery { 2862 type boolean; 2863 default "false"; 2864 description 2865 "If set to true, the service provider (SP) must 2866 ensure that the traffic uses an optimal path. 2867 An SP may use Anycast RP or RP-tree-to-SPT 2868 switchover architectures."; 2869 } 2870 container anycast { 2871 when "../rp-redundancy = 'true' and 2872 ../optimal-traffic-delivery = 'true'" { 2873 description 2874 "Only applicable if both RP redundancy and 2875 delivery through optimal path are 2876 activated."; 2877 } 2878 description 2879 "PIM Anycast-RP parameters."; 2880 leaf local-address { 2881 type inet:ip-address; 2882 description 2883 "IP local address for PIM RP. Usually, it 2884 corresponds to the Router ID or the 2885 primary address."; 2886 } 2887 leaf-list rp-set-address { 2888 type inet:ip-address; 2889 description 2890 "Specifies the IP address of other RP routers 2891 that share the same RP IP address."; 2892 } 2893 } 2894 } 2895 leaf rp-address { 2896 when "../provider-managed/enabled = 'false'" { 2897 description 2898 "Relevant when the RP is not 2899 provider-managed."; 2900 } 2901 type inet:ip-address; 2902 mandatory true; 2903 description 2904 "Defines the address of the RP. 2905 Used if the RP is customer-managed."; 2906 } 2907 container groups { 2908 description 2909 "Multicast groups associated with the RP."; 2910 list group { 2911 key "id"; 2912 description 2913 "List of multicast groups."; 2914 leaf id { 2915 type uint16; 2916 description 2917 "Identifier for the group."; 2918 } 2919 choice group-format { 2920 mandatory true; 2921 description 2922 "Choice for multicast group format."; 2923 case group-prefix { 2924 leaf group-address { 2925 type inet:ip-prefix; 2926 description 2927 "A single multicast group prefix."; 2928 } 2929 } 2930 case startend { 2931 leaf group-start { 2932 type inet:ip-address; 2933 description 2934 "The first multicast group address in 2935 the multicast group address range."; 2936 } 2937 leaf group-end { 2938 type inet:ip-address; 2939 description 2940 "The last multicast group address in 2941 the multicast group address range."; 2942 } 2943 } 2944 } 2945 } 2946 } 2947 } 2948 } 2949 container rp-discovery { 2950 description 2951 "RP discovery parameters."; 2952 leaf rp-discovery-type { 2953 type identityref { 2954 base vpn-common:multicast-rp-discovery-type; 2955 } 2956 default "vpn-common:static-rp"; 2957 description 2958 "Type of RP discovery used."; 2959 } 2960 container bsr-candidates { 2961 when "derived-from-or-self(../rp-discovery-type, " 2962 + "'vpn-common:bsr-rp')" { 2963 description 2964 "Only applicable if discovery type is BSR-RP."; 2965 } 2966 description 2967 "Container for the customer Bootstrap Router (BSR) 2968 candidate's addresses."; 2969 leaf-list bsr-candidate-address { 2970 type inet:ip-address; 2971 description 2972 "Specifies the address of candidate BSR."; 2973 } 2974 } 2975 } 2976 } 2977 container igmp { 2978 if-feature "vpn-common:igmp and vpn-common:ipv4"; 2979 description 2980 "Includes IGMP-related parameters."; 2981 list static-group { 2982 key "group-addr"; 2983 description 2984 "Multicast static source/group associated to the 2985 IGMP session."; 2986 leaf group-addr { 2987 type rt-types:ipv4-multicast-group-address; 2988 description 2989 "Multicast group IPv4 address."; 2990 } 2991 leaf source-addr { 2992 type rt-types:ipv4-multicast-source-address; 2993 description 2994 "Multicast source IPv4 address."; 2995 } 2996 } 2997 leaf max-groups { 2998 type uint32; 2999 description 3000 "Indicates the maximum number of groups."; 3001 } 3002 leaf max-entries { 3003 type uint32; 3004 description 3005 "Indicates the maximum number of IGMP entries."; 3006 } 3007 leaf version { 3008 type identityref { 3009 base vpn-common:igmp-version; 3010 } 3011 default "vpn-common:igmpv2"; 3012 description 3013 "Indicates the IGMP version."; 3014 reference 3015 "RFC 1112: Host Extensions for IP Multicasting 3016 RFC 2236: Internet Group Management Protocol, Version 2 3017 RFC 3376: Internet Group Management Protocol, Version 3"; 3018 } 3019 } 3020 container mld { 3021 if-feature "vpn-common:mld and vpn-common:ipv6"; 3022 description 3023 "Includes MLD-related parameters."; 3024 list static-group { 3025 key "group-addr"; 3026 description 3027 "Multicast static source/group associated with the 3028 MLD session."; 3029 leaf group-addr { 3030 type rt-types:ipv6-multicast-group-address; 3031 description 3032 "Multicast group IPv6 address."; 3033 } 3034 leaf source-addr { 3035 type rt-types:ipv6-multicast-source-address; 3036 description 3037 "Multicast source IPv6 address."; 3038 } 3039 } 3040 leaf max-groups { 3041 type uint32; 3042 description 3043 "Indicates the maximum number of groups."; 3044 } 3045 leaf max-entries { 3046 type uint32; 3047 description 3048 "Indicates the maximum number of MLD entries."; 3049 } 3050 leaf version { 3051 type identityref { 3052 base vpn-common:mld-version; 3053 } 3054 default "vpn-common:mldv2"; 3055 description 3056 "Indicates the MLD protocol version."; 3057 reference 3058 "RFC 2710: Multicast Listener Discovery (MLD) for IPv6 3059 RFC 3810: Multicast Listener Discovery Version 2 (MLDv2) 3060 for IPv6"; 3061 } 3062 } 3063 container pim { 3064 if-feature "vpn-common:pim"; 3065 description 3066 "Only applies when protocol type is PIM."; 3067 leaf hello-interval { 3068 type rt-types:timer-value-seconds16; 3069 default "30"; 3070 description 3071 "PIM hello-messages interval. If set to 3072 'infinity' or 'not-set', no periodic 3073 Hello messages are sent."; 3074 reference 3075 "RFC 7761: Protocol Independent Multicast - Sparse 3076 Mode (PIM-SM): Protocol Specification (Revised), 3077 Section 4.11"; 3078 } 3079 leaf dr-priority { 3080 type uint32; 3081 default "1"; 3082 description 3083 "Indicates the preference in the Designated Router (DR) 3084 election process. A larger value has a higher 3085 priority over a smaller value."; 3086 reference 3087 "RFC 7761: Protocol Independent Multicast - Sparse 3088 Mode (PIM-SM): Protocol Specification (Revised), 3089 Section 4.3.2"; 3090 } 3091 } 3092 } 3093 } 3095 /* Main Blocks */ 3096 /* Main l3vpn-ntw */ 3098 container l3vpn-ntw { 3099 description 3100 "Main container for L3VPN services management."; 3101 container vpn-profiles { 3102 description 3103 "Contains a set of valid VPN profiles to reference in the VPN 3104 service."; 3105 uses vpn-common:vpn-profile-cfg; 3106 } 3107 container vpn-services { 3108 description 3109 "Container for the VPN services."; 3110 list vpn-service { 3111 key "vpn-id"; 3112 description 3113 "List of VPN services."; 3114 uses vpn-common:vpn-description; 3115 leaf parent-service-id { 3116 type vpn-common:vpn-id; 3117 description 3118 "Pointer to the parent service, if any. 3119 A parent service can be an L3SM, a slice request, a VPN+ 3120 service, etc."; 3121 } 3122 leaf vpn-type { 3123 type identityref { 3124 base vpn-common:service-type; 3125 } 3126 description 3127 "Indicates the service type."; 3128 } 3129 leaf vpn-service-topology { 3130 type identityref { 3131 base vpn-common:vpn-topology; 3132 } 3133 default "vpn-common:any-to-any"; 3134 description 3135 "VPN service topology."; 3136 } 3137 uses vpn-common:service-status; 3138 container vpn-instance-profiles { 3139 description 3140 "Container for a list of VPN instance profiles."; 3141 list vpn-instance-profile { 3142 key "profile-id"; 3143 description 3144 "List of VPN instance profiles."; 3145 leaf profile-id { 3146 type string; 3147 description 3148 "VPN instance profile identifier."; 3149 } 3150 leaf role { 3151 type identityref { 3152 base vpn-common:role; 3153 } 3154 default "vpn-common:any-to-any-role"; 3155 description 3156 "Role of the VPN node in the VPN."; 3157 } 3158 uses vpn-instance-profile; 3159 } 3160 } 3161 container underlay-transport { 3162 description 3163 "Container for underlay transport."; 3164 uses vpn-common:underlay-transport; 3165 } 3166 container external-connectivity { 3167 if-feature "vpn-common:external-connectivity"; 3168 description 3169 "Container for external connectivity."; 3170 choice profile { 3171 description 3172 "Choice for the external connectivity profile."; 3173 case profile { 3174 leaf profile-name { 3175 type leafref { 3176 path "/l3vpn-ntw/vpn-profiles" 3177 + "/valid-provider-identifiers" 3178 + "/external-connectivity-identifier/id"; 3179 } 3180 description 3181 "Name of the service provider's profile to be applied 3182 at the VPN service level."; 3183 } 3184 } 3185 } 3186 } 3187 container vpn-nodes { 3188 description 3189 "Container for VPN nodes."; 3190 list vpn-node { 3191 key "vpn-node-id"; 3192 description 3193 "Includes a list of VPN nodes."; 3194 leaf vpn-node-id { 3195 type vpn-common:vpn-id; 3196 description 3197 "An identifier of the VPN node."; 3198 } 3199 leaf description { 3200 type string; 3201 description 3202 "Textual description of the VPN node."; 3203 } 3204 leaf ne-id { 3205 type string; 3206 description 3207 "Unique identifier of the network element where the VPN 3208 node is deployed."; 3209 } 3210 leaf local-as { 3211 if-feature "vpn-common:rtg-bgp"; 3212 type inet:as-number; 3213 description 3214 "Provider's AS number in case the customer requests BGP 3215 routing."; 3216 } 3217 leaf router-id { 3218 type rt-types:router-id; 3219 description 3220 "A 32-bit number in the dotted-quad format that is used 3221 to uniquely identify a node within an autonomous 3222 system. This identifier is used for both IPv4 and 3223 IPv6."; 3224 } 3225 container active-vpn-instance-profiles { 3226 description 3227 "Container for active VPN instance profiles."; 3228 list vpn-instance-profile { 3229 key "profile-id"; 3230 description 3231 "Includes a list of active VPN instance profiles."; 3232 leaf profile-id { 3233 type leafref { 3234 path "/l3vpn-ntw/vpn-services/vpn-service" 3235 + "/vpn-instance-profiles/vpn-instance-profile" 3236 + "/profile-id"; 3237 } 3238 description 3239 "Node's active VPN instance profile."; 3240 } 3241 list router-id { 3242 key "address-family"; 3243 description 3244 "Router-id per address family."; 3245 leaf address-family { 3246 type identityref { 3247 base vpn-common:address-family; 3248 } 3249 description 3250 "Indicates the address family for which the 3251 Router-ID applies."; 3252 } 3253 leaf router-id { 3254 type inet:ip-address; 3255 description 3256 "The router-id information can be an IPv4 or IPv6 3257 address. This can be used, for example, to 3258 configure an IPv6 address as a router-id 3259 when such capability is supported by underlay 3260 routers. In such case, the configured value 3261 overrides the generic one defined at the VPN 3262 node level."; 3263 } 3264 } 3265 uses vpn-instance-profile; 3266 } 3267 } 3268 container msdp { 3269 if-feature "msdp"; 3270 description 3271 "Includes MSDP-related parameters."; 3272 leaf peer { 3273 type inet:ipv4-address; 3274 description 3275 "Indicates the IPv4 address of the MSDP peer."; 3276 } 3277 leaf local-address { 3278 type inet:ipv4-address; 3279 description 3280 "Indicates the IPv4 address of the local end. 3281 This local address must be configured on 3282 the node."; 3283 } 3284 uses vpn-common:service-status; 3285 } 3286 uses vpn-common:vpn-components-group; 3287 uses vpn-common:service-status; 3288 container vpn-network-accesses { 3289 description 3290 "List of network accesses."; 3291 list vpn-network-access { 3292 key "id"; 3293 description 3294 "List of network accesses."; 3295 leaf id { 3296 type vpn-common:vpn-id; 3297 description 3298 "Identifier for the network access."; 3299 } 3300 leaf interface-id { 3301 type string; 3302 description 3303 "Identifier for the physical or logical 3304 interface. 3305 The identification of the sub-interface 3306 is provided at the connection and/or IP 3307 connection levels."; 3308 } 3309 leaf description { 3310 type string; 3311 description 3312 "Textual description of the network access."; 3313 } 3314 leaf vpn-network-access-type { 3315 type identityref { 3316 base vpn-common:site-network-access-type; 3317 } 3318 default "vpn-common:point-to-point"; 3319 description 3320 "Describes the type of connection, e.g., 3321 point-to-point."; 3322 } 3323 leaf vpn-instance-profile { 3324 type leafref { 3325 path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes" 3326 + "/vpn-node/active-vpn-instance-profiles" 3327 + "/vpn-instance-profile/profile-id"; 3328 } 3329 description 3330 "An identifier of an active VPN instance profile."; 3331 } 3332 uses vpn-common:service-status; 3333 container connection { 3334 description 3335 "Defines layer 2 protocols and parameters that are 3336 required to enable connectivity between the PE 3337 and the CE."; 3338 container encapsulation { 3339 description 3340 "Container for layer 2 encapsulation."; 3341 leaf type { 3342 type identityref { 3343 base vpn-common:encapsulation-type; 3344 } 3345 default "vpn-common:priority-tagged"; 3346 description 3347 "Encapsulation type. By default, the type of 3348 the tagged interface is 'priority-tagged'."; 3349 } 3350 container dot1q { 3351 when "derived-from-or-self(../type, " 3352 + "'vpn-common:dot1q')" { 3353 description 3354 "Only applies when the type of the 3355 tagged interface is 'dot1q'."; 3356 } 3357 if-feature "vpn-common:dot1q"; 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; 3389 } 3390 default "vpn-common:c-vlan"; 3391 description 3392 "Tag type. By default, the tag type is 3393 'c-vlan'."; 3394 } 3395 } 3396 container qinq { 3397 when "derived-from-or-self(../type, " 3398 + "'vpn-common:qinq')" { 3399 description 3400 "Only applies when the type of the tagged 3401 interface is QinQ."; 3402 } 3403 if-feature "vpn-common:qinq"; 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 if-feature "vpn-common:vxlan"; 3507 description 3508 "VXLAN termination parameters."; 3509 leaf vni-id { 3510 type uint32; 3511 mandatory true; 3512 description 3513 "VXLAN Network Identifier (VNI)."; 3514 } 3515 leaf peer-mode { 3516 type identityref { 3517 base vpn-common:vxlan-peer-mode; 3518 } 3519 default "vpn-common:static-mode"; 3520 description 3521 "Specifies the VXLAN access mode. By 3522 default, the peer mode is set to 3523 'static-mode'."; 3524 } 3525 leaf-list peer-ip-address { 3526 type inet:ip-address; 3527 description 3528 "List of peer's IP addresses."; 3529 } 3530 } 3531 } 3532 case l2vpn { 3533 leaf l2vpn-id { 3534 type vpn-common:vpn-id; 3535 description 3536 "Indicates the L2VPN service associated with 3537 an Integrated Routing and Bridging (IRB) 3538 interface."; 3539 } 3540 } 3541 } 3542 leaf l2-termination-point { 3543 type string; 3544 description 3545 "Specifies a reference to a local layer 2 3546 termination point such as a layer 2 3547 sub-interface."; 3548 } 3549 leaf local-bridge-reference { 3550 type string; 3551 description 3552 "Specifies a local bridge reference to 3553 accommodate, for example, implementations 3554 that require internal bridging. 3555 A reference may be a local bridge domain."; 3556 } 3557 leaf bearer-reference { 3558 if-feature "vpn-common:bearer-reference"; 3559 type string; 3560 description 3561 "This is an internal reference for the service 3562 provider to identify the bearer associated 3563 with this VPN."; 3564 } 3565 container lag-interface { 3566 if-feature "vpn-common:lag-interface"; 3567 description 3568 "Container of LAG interface attributes 3569 configuration."; 3570 leaf lag-interface-id { 3571 type string; 3572 description 3573 "LAG interface identifier."; 3574 } 3575 container member-link-list { 3576 description 3577 "Container of Member link list."; 3578 list member-link { 3579 key "name"; 3580 description 3581 "Member link."; 3582 leaf name { 3583 type string; 3584 description 3585 "Member link name."; 3586 } 3587 } 3588 } 3589 } 3590 } 3591 container ip-connection { 3592 description 3593 "Defines IP connection parameters."; 3594 leaf l3-termination-point { 3595 type string; 3596 description 3597 "Specifies a reference to a local layer 3 3598 termination point such as a bridge domain 3599 interface."; 3600 } 3601 container ipv4 { 3602 if-feature "vpn-common:ipv4"; 3603 description 3604 "IPv4-specific parameters."; 3605 leaf local-address { 3606 type inet:ipv4-address; 3607 description 3608 "The IP address used at the provider's 3609 interface."; 3610 } 3611 leaf prefix-length { 3612 type uint8 { 3613 range "0..32"; 3614 } 3615 description 3616 "Subnet prefix length expressed in bits. 3617 It is applied to both local and customer 3618 addresses."; 3619 } 3620 leaf address-allocation-type { 3621 type identityref { 3622 base address-allocation-type; 3623 } 3624 must "not(derived-from-or-self(current(), " 3625 + "'slaac') or derived-from-or-self(current()," 3626 + " 'provider-dhcp-slaac'))" { 3627 error-message 3628 "SLAAC is only applicable to IPv6."; 3629 } 3630 description 3631 "Defines how addresses are allocated to the 3632 peer site. 3634 If there is no value for the address 3635 allocation type, then IPv4 addressing is not 3636 enabled."; 3637 } 3638 choice allocation-type { 3639 description 3640 "Choice of the IPv4 address allocation."; 3641 case provider-dhcp { 3642 description 3643 "DHCP allocated addresses related 3644 parameters. IP addresses are allocated 3645 by DHCP that is operated by the provider"; 3646 leaf dhcp-service-type { 3647 type enumeration { 3648 enum server { 3649 description 3650 "Local DHCP server."; 3651 } 3652 enum relay { 3653 description 3654 "Local DHCP relay. DHCP requests are 3655 relayed to a provider's server."; 3656 } 3657 } 3658 description 3659 "Indicates the type of DHCP service to 3660 be enabled on this access."; 3661 } 3662 choice service-type { 3663 description 3664 "Choice based on the DHCP service type."; 3665 case relay { 3666 description 3667 "Container for list of provider's DHCP 3668 servers (i.e., dhcp-service-type is set 3669 to relay)."; 3670 leaf-list server-ip-address { 3671 type inet:ipv4-address; 3672 description 3673 "IPv4 addresses of the provider's DHCP 3674 server to use by the local DHCP 3675 relay."; 3677 } 3678 } 3679 case server { 3680 description 3681 "A choice about how addresses are assigned 3682 when a local DHCP server is enabled."; 3683 choice address-assign { 3684 default "number"; 3685 description 3686 "Choice for how IPv4 addresses are 3687 assigned."; 3688 case number { 3689 leaf number-of-dynamic-address { 3690 type uint16; 3691 default "1"; 3692 description 3693 "Specifies the number of IP 3694 addresses to be assigned to the 3695 customer on this access."; 3696 } 3697 } 3698 case explicit { 3699 container customer-addresses { 3700 description 3701 "Container for customer 3702 addresses to be allocated 3703 using DHCP."; 3704 list address-pool { 3705 key "pool-id"; 3706 description 3707 "Describes IP addresses to be 3708 allocated by DHCP. 3710 When only start-address is 3711 present, it represents a single 3712 address. 3714 When both start-address and 3715 end-address are specified, it 3716 implies a range inclusive of both 3717 addresses."; 3718 leaf pool-id { 3719 type string; 3720 description 3721 "A pool identifier for the 3722 address range from start- 3723 address to end-address."; 3724 } 3725 leaf start-address { 3726 type inet:ipv4-address; 3727 mandatory true; 3728 description 3729 "Indicates the first address 3730 in the pool."; 3731 } 3732 leaf end-address { 3733 type inet:ipv4-address; 3734 description 3735 "Indicates the last address 3736 in the pool."; 3737 } 3738 } 3739 } 3740 } 3741 } 3742 } 3743 } 3744 } 3745 case dhcp-relay { 3746 description 3747 "DHCP relay is provided by the operator."; 3748 container customer-dhcp-servers { 3749 description 3750 "Container for a list of customer's DHCP 3751 servers."; 3752 leaf-list server-ip-address { 3753 type inet:ipv4-address; 3754 description 3755 "IPv4 addresses of the customer's DHCP 3756 server."; 3757 } 3758 } 3759 } 3760 case static-addresses { 3761 description 3762 "Lists the IPv4 addresses that are used."; 3763 leaf primary-address { 3764 type leafref { 3765 path "../address/address-id"; 3766 } 3767 description 3768 "Primary address of the connection."; 3769 } 3770 list address { 3771 key "address-id"; 3772 description 3773 "Lists the IPv4 addresses that are used."; 3774 leaf address-id { 3775 type string; 3776 description 3777 "An identifier of the static IPv4 3778 address."; 3779 } 3780 leaf customer-address { 3781 type inet:ipv4-address; 3782 description 3783 "IPv4 address at the customer side."; 3784 } 3785 } 3786 } 3787 } 3788 } 3789 container ipv6 { 3790 if-feature "vpn-common:ipv6"; 3791 description 3792 "IPv6-specific parameters."; 3793 leaf local-address { 3794 type inet:ipv6-address; 3795 description 3796 "IPv6 address of the provider side."; 3797 } 3798 leaf prefix-length { 3799 type uint8 { 3800 range "0..128"; 3801 } 3802 description 3803 "Subnet prefix length expressed in bits. 3804 It is applied to both local and customer 3805 addresses."; 3806 } 3807 leaf address-allocation-type { 3808 type identityref { 3809 base address-allocation-type; 3810 } 3811 description 3812 "Defines how addresses are allocated. 3813 If there is no value for the address 3814 allocation type, then IPv6 addressing is 3815 disabled."; 3816 } 3817 choice allocation-type { 3818 description 3819 "A choice based on the IPv6 allocation type."; 3820 container provider-dhcp { 3821 when "derived-from-or-self(../address-allo" 3822 + "cation-type, 'provider-dhcp') " 3823 + "or derived-from-or-self(../address-allo" 3824 + "cation-type, 'provider-dhcp-slaac')" { 3825 description 3826 "Only applies when addresses are 3827 allocated by DHCPv6 provided by the 3828 operator."; 3829 } 3830 description 3831 "DHCPv6 allocated addresses related 3832 parameters."; 3833 leaf dhcp-service-type { 3834 type enumeration { 3835 enum server { 3836 description 3837 "Local DHCPv6 server."; 3838 } 3839 enum relay { 3840 description 3841 "DHCPv6 relay."; 3842 } 3843 } 3844 description 3845 "Indicates the type of the DHCPv6 service to 3846 be enabled on this access."; 3847 } 3848 choice service-type { 3849 description 3850 "Choice based on the DHCPv6 service type."; 3851 case relay { 3852 leaf-list server-ip-address { 3853 type inet:ipv6-address; 3854 description 3855 "IPv6 addresses of the provider's 3856 DHCPv6 server."; 3857 } 3858 } 3859 case server { 3860 choice address-assign { 3861 default "number"; 3862 description 3863 "Choice about how IPv6 prefixes are 3864 assigned by the DHCPv6 server."; 3865 case number { 3866 leaf number-of-dynamic-address { 3867 type uint16; 3868 default "1"; 3869 description 3870 "Describes the number of IPv6 3871 prefixes that are allocated to 3872 the customer on this access."; 3873 } 3874 } 3875 case explicit { 3876 container customer-addresses { 3877 description 3878 "Container for customer IPv6 3879 addresses allocated by DHCPv6."; 3880 list address-pool { 3881 key "pool-id"; 3882 description 3883 "Describes IPv6 addresses 3884 allocated by DHCPv6. 3886 When only start-address is 3887 present, it represents a single 3888 address. 3890 When both start-address and 3891 end-address are specified, it 3892 implies a range inclusive of 3893 both addresses."; 3894 leaf pool-id { 3895 type string; 3896 description 3897 "Pool identifier for the address 3898 range from identified by start- 3899 address and end-address."; 3900 } 3901 leaf start-address { 3902 type inet:ipv6-address; 3903 mandatory true; 3904 description 3905 "Indicates the first address."; 3906 } 3907 leaf end-address { 3908 type inet:ipv6-address; 3909 description 3910 "Indicates the last address."; 3911 } 3912 } 3913 } 3914 } 3915 } 3916 } 3918 } 3919 } 3920 case dhcp-relay { 3921 description 3922 "DHCPv6 relay provided by the operator."; 3923 container customer-dhcp-servers { 3924 description 3925 "Container for a list of customer DHCP 3926 servers."; 3927 leaf-list server-ip-address { 3928 type inet:ipv6-address; 3929 description 3930 "Contains the IP addresses of the customer 3931 DHCPv6 server."; 3932 } 3933 } 3934 } 3935 case static-addresses { 3936 description 3937 "IPv6-specific parameters for static 3938 allocation."; 3939 leaf primary-address { 3940 type leafref { 3941 path "../address/address-id"; 3942 } 3943 description 3944 "Principal address of the connection"; 3945 } 3946 list address { 3947 key "address-id"; 3948 description 3949 "Describes IPv6 addresses that are used."; 3950 leaf address-id { 3951 type string; 3952 description 3953 "An identifier of an IPv6 address."; 3954 } 3955 leaf customer-address { 3956 type inet:ipv6-address; 3957 description 3958 "An IPv6 address of the customer side."; 3959 } 3960 } 3961 } 3962 } 3963 } 3964 } 3965 container routing-protocols { 3966 description 3967 "Defines routing protocols."; 3968 list routing-protocol { 3969 key "id"; 3970 description 3971 "List of routing protocols used on 3972 the CE/PE link. This list can be augmented."; 3973 leaf id { 3974 type string; 3975 description 3976 "Unique identifier for routing protocol."; 3977 } 3978 leaf type { 3979 type identityref { 3980 base vpn-common:routing-protocol-type; 3981 } 3982 description 3983 "Type of routing protocol."; 3984 } 3985 list routing-profiles { 3986 key "id"; 3987 description 3988 "Routing profiles."; 3989 leaf id { 3990 type leafref { 3991 path "/l3vpn-ntw/vpn-profiles" 3992 + "/valid-provider-identifiers" 3993 + "/routing-profile-identifier/id"; 3994 } 3995 description 3996 "Routing profile to be used."; 3997 } 3998 leaf type { 3999 type identityref { 4000 base vpn-common:ie-type; 4001 } 4002 description 4003 "Import, export, or both."; 4004 } 4005 } 4006 container static { 4007 when "derived-from-or-self(../type, " 4008 + "'vpn-common:static-routing')" { 4009 description 4010 "Only applies when protocol is static."; 4011 } 4012 description 4013 "Configuration specific to static routing."; 4015 container cascaded-lan-prefixes { 4016 description 4017 "LAN prefixes from the customer."; 4018 list ipv4-lan-prefixes { 4019 if-feature "vpn-common:ipv4"; 4020 key "lan next-hop"; 4021 description 4022 "List of LAN prefixes for the site."; 4023 leaf lan { 4024 type inet:ipv4-prefix; 4025 description 4026 "LAN prefixes."; 4027 } 4028 leaf lan-tag { 4029 type string; 4030 description 4031 "Internal tag to be used in VPN 4032 policies."; 4033 } 4034 leaf next-hop { 4035 type union { 4036 type inet:ip-address; 4037 type predefined-next-hop; 4038 } 4039 description 4040 "The next-hop that is to be used 4041 for the static route. This may be 4042 specified as an IP address or a 4043 pre-defined next-hop type (e.g., 4044 discard or local-link)."; 4045 } 4046 leaf bfd-enable { 4047 if-feature "vpn-common:bfd"; 4048 type boolean; 4049 description 4050 "Enables BFD."; 4051 } 4052 leaf metric { 4053 type uint32; 4054 description 4055 "Indicates the metric associated with 4056 the static route."; 4057 } 4058 leaf preference { 4059 type uint32; 4060 description 4061 "Indicates the preference of the static 4062 routes."; 4064 } 4065 uses vpn-common:service-status; 4066 } 4067 list ipv6-lan-prefixes { 4068 if-feature "vpn-common:ipv6"; 4069 key "lan next-hop"; 4070 description 4071 "List of LAN prefixes for the site."; 4072 leaf lan { 4073 type inet:ipv6-prefix; 4074 description 4075 "LAN prefixes."; 4076 } 4077 leaf lan-tag { 4078 type string; 4079 description 4080 "Internal tag to be used in VPN 4081 policies."; 4082 } 4083 leaf next-hop { 4084 type union { 4085 type inet:ip-address; 4086 type predefined-next-hop; 4087 } 4088 description 4089 "The next-hop that is to be used for the 4090 static route. This may be specified as 4091 an IP address or a pre-defined next-hop 4092 type (e.g., discard or local-link)."; 4093 } 4094 leaf bfd-enable { 4095 if-feature "vpn-common:bfd"; 4096 type boolean; 4097 description 4098 "Enables BFD."; 4099 } 4100 leaf metric { 4101 type uint32; 4102 description 4103 "Indicates the metric associated with 4104 the static route."; 4105 } 4106 leaf preference { 4107 type uint32; 4108 description 4109 "Indicates the preference associated 4110 with the static route."; 4111 } 4112 uses vpn-common:service-status; 4113 } 4114 } 4115 } 4116 container bgp { 4117 when "derived-from-or-self(../type, " 4118 + "'vpn-common:bgp-routing')" { 4119 description 4120 "Only applies when protocol is BGP."; 4121 } 4122 if-feature "vpn-common:rtg-bgp"; 4123 description 4124 "BGP-specific configuration."; 4125 leaf description { 4126 type string; 4127 description 4128 "Includes a description of the BGP session. 4130 This description is meant to be used for 4131 diagnosis purposes. The semantic of the 4132 description is local to an 4133 implementation."; 4134 } 4135 leaf local-as { 4136 type inet:as-number; 4137 description 4138 "Indicates a local AS Number (ASN) if a 4139 distinct ASN than the one configured at 4140 the VPN node level is needed."; 4141 } 4142 leaf peer-as { 4143 type inet:as-number; 4144 mandatory true; 4145 description 4146 "Indicates the customer's ASN when 4147 the customer requests BGP routing."; 4148 } 4149 leaf address-family { 4150 type identityref { 4151 base vpn-common:address-family; 4152 } 4153 description 4154 "This node contains the address families to be 4155 activated. Dual-stack means that both IPv4 4156 and IPv6 will be activated."; 4157 } 4158 leaf local-address { 4159 type union { 4160 type inet:ip-address; 4161 type if:interface-ref; 4162 } 4163 description 4164 "Set the local IP address to use for the BGP 4165 transport session. This may be expressed as 4166 either an IP address or a reference to an 4167 interface."; 4168 } 4169 leaf-list neighbor { 4170 type inet:ip-address; 4171 description 4172 "IP address(es) of the BGP neighbor. IPv4 4173 and IPv6 neighbors may be indicated if 4174 two sessions will be used for IPv4 and 4175 IPv6."; 4176 } 4177 leaf multihop { 4178 type uint8; 4179 description 4180 "Describes the number of IP hops allowed 4181 between a given BGP neighbor and the PE."; 4182 } 4183 leaf as-override { 4184 type boolean; 4185 default "false"; 4186 description 4187 "Defines whether ASN override is enabled, 4188 i.e., replace the ASN of the customer 4189 specified in the AS_Path attribute with 4190 the local ASN."; 4191 } 4192 leaf allow-own-as { 4193 type uint8; 4194 default "0"; 4195 description 4196 "Specifies the number of occurrences 4197 of the provider's ASN that can occur 4198 within the AS_PATH before it 4199 is rejected."; 4200 } 4201 leaf prepend-global-as { 4202 type boolean; 4203 default "false"; 4204 description 4205 "In some situations, the ASN that is 4206 provided at the VPN node level may be 4207 distinct from the one configured at the 4208 VPN network access level. When such 4209 ASNs are provided, they are both 4210 prepended to the BGP route updates 4211 for this access. To disable that 4212 behavior, the prepend-global-as 4213 must be set to 'false'. In such a case, 4214 the ASN that is provided at 4215 the VPN node level is not prepended to 4216 the BGP route updates for this access."; 4217 } 4218 leaf send-default-route { 4219 type boolean; 4220 default "false"; 4221 description 4222 "Defines whether default routes can be 4223 advertised to its peer. If set, the 4224 default routes are advertised to its 4225 peer."; 4226 } 4227 leaf site-of-origin { 4228 when "../address-family = 'vpn-common:ipv4' or " 4229 + "'vpn-common:dual-stack'" { 4230 description 4231 "Only applies if IPv4 is activated."; 4232 } 4233 type rt-types:route-origin; 4234 description 4235 "The Site of Origin attribute is encoded as 4236 a Route Origin Extended Community. It is 4237 meant to uniquely identify the set of routes 4238 learned from a site via a particular CE/PE 4239 connection and is used to prevent routing 4240 loops."; 4241 reference 4242 "RFC 4364: BGP/MPLS IP Virtual Private 4243 Networks (VPNs), Section 7"; 4244 } 4245 leaf ipv6-site-of-origin { 4246 when "../address-family = 'vpn-common:ipv6' or " 4247 + "'vpn-common:dual-stack'" { 4248 description 4249 "Only applies if IPv6 is activated."; 4250 } 4251 type rt-types:ipv6-route-origin; 4252 description 4253 "IPv6 Route Origins are IPv6 Address Specific 4254 BGP Extended that are meant to the Site of 4255 Origin for VRF information."; 4257 reference 4258 "RFC 5701: IPv6 Address Specific BGP Extended 4259 Community Attribute"; 4260 } 4261 list redistribute-connected { 4262 key "address-family"; 4263 description 4264 "Indicates the per-AF policy to follow 4265 for connected routes."; 4266 leaf address-family { 4267 type identityref { 4268 base vpn-common:address-family; 4269 } 4270 description 4271 "Indicates the address family."; 4272 } 4273 leaf enable { 4274 type boolean; 4275 description 4276 "Enables to redistribute connected 4277 routes."; 4278 } 4279 } 4280 container bgp-max-prefix { 4281 description 4282 "Controls the behavior when a prefix 4283 maximum is reached."; 4284 leaf max-prefix { 4285 type uint32; 4286 default "5000"; 4287 description 4288 "Indicates the maximum number of BGP 4289 prefixes allowed in the BGP session. 4291 It allows control of how many prefixes 4292 can be received from a neighbor. 4294 If the limit is exceeded, the action 4295 indicated in violate-action will be 4296 followed."; 4297 reference 4298 "RFC 4271: A Border Gateway Protocol 4 4299 (BGP-4), Section 8.2.2"; 4300 } 4301 leaf warning-threshold { 4302 type decimal64 { 4303 fraction-digits 5; 4304 range "0..100"; 4306 } 4307 units "percent"; 4308 default "75"; 4309 description 4310 "When this value is reached, a warning 4311 notification will be triggered."; 4312 } 4313 leaf violate-action { 4314 type enumeration { 4315 enum warning { 4316 description 4317 "Only a warning message is sent to 4318 the peer when the limit is 4319 exceeded."; 4320 } 4321 enum discard-extra-paths { 4322 description 4323 "Discards extra paths when the 4324 limit is exceeded."; 4325 } 4326 enum restart { 4327 description 4328 "The BGP session restarts after 4329 a time interval."; 4330 } 4331 } 4332 description 4333 "BGP neighbor max-prefix violate 4334 action."; 4335 } 4336 leaf restart-timer { 4337 type uint32; 4338 units "seconds"; 4339 description 4340 "Time interval after which the BGP 4341 session will be reestablished."; 4342 } 4343 } 4344 container bgp-timers { 4345 description 4346 "Includes two BGP timers that can be 4347 customized when building a VPN service 4348 with BGP used as CE-PE routing 4349 protocol."; 4350 leaf keepalive { 4351 type uint16 { 4352 range "0..21845"; 4353 } 4354 units "seconds"; 4355 default "30"; 4356 description 4357 "This timer indicates the KEEPALIVE 4358 messages' frequency between a PE 4359 and a BGP peer. 4361 If set to '0', it indicates KEEPALIVE 4362 messages are disabled. 4364 It is suggested that the maximum time 4365 between KEEPALIVE messages would be 4366 one third of the Hold Time interval."; 4367 reference 4368 "RFC 4271: A Border Gateway Protocol 4 4369 (BGP-4), Section 4.4"; 4370 } 4371 leaf hold-time { 4372 type uint16 { 4373 range "0 | 3..65535"; 4374 } 4375 units "seconds"; 4376 default "90"; 4377 description 4378 "It indicates the maximum number of 4379 seconds that may elapse between the 4380 receipt of successive KEEPALIVE 4381 and/or UPDATE messages from the peer. 4383 The Hold Time must be either zero or 4384 at least three seconds."; 4385 reference 4386 "RFC 4271: A Border Gateway Protocol 4 4387 (BGP-4), Section 4.2"; 4388 } 4389 } 4390 container authentication { 4391 description 4392 "Container for BGP authentication 4393 parameters between a PE and a CE."; 4394 leaf enable { 4395 type boolean; 4396 default "false"; 4397 description 4398 "Enables or disables authentication."; 4399 } 4400 container keying-material { 4401 when "../enable = 'true'"; 4402 description 4403 "Container for describing how a BGP routing 4404 session is to be secured between a PE and 4405 a CE."; 4406 choice option { 4407 description 4408 "Choice of authentication options."; 4409 case ao { 4410 description 4411 "Uses TCP-Authentication Option 4412 (TCP-AO)."; 4413 reference 4414 "RFC 5925: The TCP Authentication 4415 Option."; 4416 leaf enable-ao { 4417 type boolean; 4418 description 4419 "Enables TCP-AO."; 4420 } 4421 leaf ao-keychain { 4422 type key-chain:key-chain-ref; 4423 description 4424 "Reference to the TCP-AO key chain."; 4425 reference 4426 "RFC 8177: YANG Key Chain."; 4427 } 4428 } 4429 case md5 { 4430 description 4431 "Uses MD5 to secure the session."; 4432 reference 4433 "RFC 4364: BGP/MPLS IP Virtual Private 4434 Networks (VPNs), 4435 Section 13.2"; 4436 leaf md5-keychain { 4437 type key-chain:key-chain-ref; 4438 description 4439 "Reference to the MD5 key chain."; 4440 reference 4441 "RFC 8177: YANG Key Chain"; 4442 } 4443 } 4444 case explicit { 4445 leaf key-id { 4446 type uint32; 4447 description 4448 "Key Identifier."; 4449 } 4450 leaf key { 4451 type string; 4452 description 4453 "BGP authentication key in ASCII 4454 format."; 4455 } 4456 leaf crypto-algorithm { 4457 type identityref { 4458 base key-chain:crypto-algorithm; 4459 } 4460 description 4461 "Indicates the cryptographic algorithm 4462 associated with the key."; 4463 } 4464 } 4465 case ipsec { 4466 description 4467 "Specifies a reference to an IKE 4468 Security Association (SA)."; 4469 leaf sa { 4470 type string; 4471 description 4472 "Indicates the name of the SA."; 4473 } 4474 } 4475 } 4476 } 4477 } 4478 uses vpn-common:service-status; 4479 } 4480 container ospf { 4481 when "derived-from-or-self(../type, " 4482 + "'vpn-common:ospf-routing')" { 4483 description 4484 "Only applies when protocol is OSPF."; 4485 } 4486 if-feature "vpn-common:rtg-ospf"; 4487 description 4488 "OSPF-specific configuration."; 4489 leaf address-family { 4490 type identityref { 4491 base vpn-common:address-family; 4492 } 4493 description 4494 "Indicates whether IPv4, IPv6, or 4495 both are to be activated."; 4496 } 4497 leaf area-id { 4498 type yang:dotted-quad; 4499 mandatory true; 4500 description 4501 "Area ID."; 4502 reference 4503 "RFC 4577: OSPF as the Provider/Customer 4504 Edge Protocol for BGP/MPLS IP 4505 Virtual Private Networks 4506 (VPNs), Section 4.2.3 4507 RFC 6565: OSPFv3 as a Provider Edge to 4508 Customer Edge (PE-CE) Routing 4509 Protocol, Section 4.2"; 4510 } 4511 leaf metric { 4512 type uint16; 4513 default "1"; 4514 description 4515 "Metric of the PE-CE link. It is used 4516 in the routing state calculation and 4517 path selection."; 4518 } 4519 container sham-links { 4520 if-feature "vpn-common:rtg-ospf-sham-link"; 4521 description 4522 "List of sham links."; 4523 reference 4524 "RFC 4577: OSPF as the Provider/Customer 4525 Edge Protocol for BGP/MPLS IP 4526 Virtual Private Networks 4527 (VPNs), Section 4.2.7 4528 RFC 6565: OSPFv3 as a Provider Edge to 4529 Customer Edge (PE-CE) Routing 4530 Protocol, Section 5"; 4531 list sham-link { 4532 key "target-site"; 4533 description 4534 "Creates a sham link with another site."; 4535 leaf target-site { 4536 type string; 4537 description 4538 "Target site for the sham link connection. 4539 The site is referred to by its 4540 identifier."; 4541 } 4542 leaf metric { 4543 type uint16; 4544 default "1"; 4545 description 4546 "Metric of the sham link. It is used in 4547 the routing state calculation and path 4548 selection. The default value is set 4549 to 1."; 4550 reference 4551 "RFC 4577: OSPF as the Provider/Customer 4552 Edge Protocol for BGP/MPLS IP 4553 Virtual Private Networks 4554 (VPNs), Section 4.2.7.3 4555 RFC 6565: OSPFv3 as a Provider Edge to 4556 Customer Edge (PE-CE) Routing 4557 Protocol, Section 5.2"; 4558 } 4559 } 4560 } 4561 leaf max-lsa { 4562 type uint32 { 4563 range "1..4294967294"; 4564 } 4565 description 4566 "Maximum number of allowed LSAs OSPF."; 4567 } 4568 container authentication { 4569 description 4570 "Authentication configuration."; 4571 leaf enable { 4572 type boolean; 4573 default "false"; 4574 description 4575 "Enables or disables authentication."; 4576 } 4577 container keying-material { 4578 when "../enable = 'true'"; 4579 description 4580 "Container for describing how an OSPF 4581 session is to be secured between a CE 4582 and a PE."; 4583 choice option { 4584 description 4585 "Options for OSPF authentication."; 4586 case auth-key-chain { 4587 leaf key-chain { 4588 type key-chain:key-chain-ref; 4589 description 4590 "key-chain name."; 4591 } 4592 } 4593 case auth-key-explicit { 4594 leaf key-id { 4595 type uint32; 4596 description 4597 "Key identifier."; 4598 } 4599 leaf key { 4600 type string; 4601 description 4602 "OSPF authentication key in ASCII 4603 format."; 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 name of the SA."; 4619 reference 4620 "RFC 4552: Authentication 4621 /Confidentiality for 4622 OSPFv3"; 4623 } 4624 } 4625 } 4626 } 4627 } 4628 uses vpn-common:service-status; 4629 } 4630 container isis { 4631 when "derived-from-or-self(../type, " 4632 + "'vpn-common:isis-routing')" { 4633 description 4634 "Only applies when protocol is IS-IS."; 4635 } 4636 if-feature "vpn-common:rtg-isis"; 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 in ASCII 4722 format."; 4723 } 4724 leaf crypto-algorithm { 4725 type identityref { 4726 base key-chain:crypto-algorithm; 4727 } 4728 description 4729 "Indicates the cryptographic algorithm 4730 associated with the key."; 4731 } 4732 } 4733 } 4734 } 4735 } 4736 uses vpn-common:service-status; 4737 } 4738 container rip { 4739 when "derived-from-or-self(../type, " 4740 + "'vpn-common:rip-routing')" { 4741 description 4742 "Only applies when the protocol is RIP. 4743 For IPv4, the model assumes that RIP 4744 version 2 is used."; 4745 } 4746 if-feature "vpn-common:rtg-rip"; 4747 description 4748 "Configuration specific to RIP routing."; 4749 leaf address-family { 4750 type identityref { 4751 base vpn-common:address-family; 4752 } 4753 description 4754 "Indicates whether IPv4, IPv6, or both 4755 address families are to be activated."; 4756 } 4757 container timers { 4758 description 4759 "Indicates the RIP timers."; 4760 reference 4761 "RFC 2453: RIP Version 2"; 4762 leaf update-interval { 4763 type uint16 { 4764 range "1..32767"; 4765 } 4766 units "seconds"; 4767 default "30"; 4768 description 4769 "Indicates the RIP update time. 4770 That is, the amount of time for which 4771 RIP updates are sent."; 4772 } 4773 leaf invalid-interval { 4774 type uint16 { 4775 range "1..32767"; 4776 } 4777 units "seconds"; 4778 default "180"; 4779 description 4780 "Is the interval before a route is declared 4781 invalid after no updates are received. 4782 This value is at least three times 4783 the value for the update-interval 4784 argument."; 4785 } 4786 leaf holddown-interval { 4787 type uint16 { 4788 range "1..32767"; 4789 } 4790 units "seconds"; 4791 default "180"; 4792 description 4793 "Specifies the interval before better routes 4794 are released."; 4795 } 4796 leaf flush-interval { 4797 type uint16 { 4798 range "1..32767"; 4799 } 4800 units "seconds"; 4801 default "240"; 4802 description 4803 "Indicates the RIP flush timer. That is, 4804 the amount of time that must elapse before 4805 a route is removed from the routing 4806 table."; 4807 } 4808 } 4809 leaf default-metric { 4810 type uint8 { 4811 range "0..16"; 4812 } 4813 default "1"; 4814 description 4815 "Sets the default metric."; 4816 } 4817 container authentication { 4818 description 4819 "Authentication configuration."; 4820 leaf enable { 4821 type boolean; 4822 default "false"; 4823 description 4824 "Enables or disables authentication."; 4825 } 4826 container keying-material { 4827 when "../enable = 'true'"; 4828 description 4829 "Container for describing how a RIP 4830 session is to be secured between a CE 4831 and a PE."; 4832 choice option { 4833 description 4834 "Specifies the authentication scheme."; 4836 case auth-key-chain { 4837 leaf key-chain { 4838 type key-chain:key-chain-ref; 4839 description 4840 "key-chain name."; 4841 } 4842 } 4843 case auth-key-explicit { 4844 leaf key { 4845 type string; 4846 description 4847 "RIP authentication key in ASCII 4848 format."; 4849 } 4850 leaf crypto-algorithm { 4851 type identityref { 4852 base key-chain:crypto-algorithm; 4853 } 4854 description 4855 "Indicates the cryptographic algorithm 4856 associated with the key."; 4857 } 4858 } 4859 } 4860 } 4861 } 4862 uses vpn-common:service-status; 4863 } 4864 container vrrp { 4865 when "derived-from-or-self(../type, " 4866 + "'vpn-common:vrrp-routing')" { 4867 description 4868 "Only applies when protocol is VRRP."; 4869 } 4870 if-feature "vpn-common:rtg-vrrp"; 4871 description 4872 "Configuration specific to VRRP."; 4873 reference 4874 "RFC 5798: Virtual Router Redundancy Protocol 4875 (VRRP) Version 3 for IPv4 and IPv6"; 4876 leaf address-family { 4877 type identityref { 4878 base vpn-common:address-family; 4879 } 4880 description 4881 "Indicates whether IPv4, IPv6, or both 4882 address families are to be enabled."; 4883 } 4884 leaf vrrp-group { 4885 type uint8 { 4886 range "1..255"; 4887 } 4888 description 4889 "Includes the VRRP group identifier."; 4890 } 4891 leaf backup-peer { 4892 type inet:ip-address; 4893 description 4894 "Indicates the IP address of the peer."; 4895 } 4896 leaf-list virtual-ip-address { 4897 type inet:ip-address; 4898 description 4899 "Virtual IP addresses for a single VRRP 4900 group."; 4901 reference 4902 "RFC 5798: Virtual Router Redundancy Protocol 4903 (VRRP) Version 3 for IPv4 and 4904 IPv6, Sections1.2 and 1.3"; 4905 } 4906 leaf priority { 4907 type uint8 { 4908 range "1..254"; 4909 } 4910 default "100"; 4911 description 4912 "Sets the local priority of the VRRP 4913 speaker."; 4914 } 4915 leaf ping-reply { 4916 type boolean; 4917 default "false"; 4918 description 4919 "Controls whether the VRRP speaker should 4920 answer to ping requests."; 4921 } 4922 uses vpn-common:service-status; 4923 } 4924 } 4925 } 4926 container oam { 4927 description 4928 "Defines the Operations, Administration, 4929 and Maintenance (OAM) mechanisms used. 4931 BFD is set as a fault detection mechanism, 4932 but other mechanisms can be defined in the 4933 future."; 4934 container bfd { 4935 if-feature "vpn-common:bfd"; 4936 description 4937 "Container for BFD."; 4938 leaf session-type { 4939 type identityref { 4940 base vpn-common:bfd-session-type; 4941 } 4942 default "vpn-common:classic-bfd"; 4943 description 4944 "Specifies the BFD session type."; 4945 } 4946 leaf desired-min-tx-interval { 4947 type uint32; 4948 units "microseconds"; 4949 default "1000000"; 4950 description 4951 "The minimum interval between transmission of 4952 BFD control packets that the operator 4953 desires."; 4954 reference 4955 "RFC 5880: Bidirectional Forwarding Detection 4956 (BFD), Section 6.8.7"; 4957 } 4958 leaf required-min-rx-interval { 4959 type uint32; 4960 units "microseconds"; 4961 description 4962 "The minimum interval between received BFD 4963 control packets that the PE should support."; 4964 reference 4965 "RFC 5880: Bidirectional Forwarding Detection 4966 (BFD), Section 6.8.7"; 4967 } 4968 leaf local-multiplier { 4969 type uint8 { 4970 range "1..255"; 4971 } 4972 default "3"; 4973 description 4974 "Specifies the detection multiplier that is 4975 transmitted to a BFD peer. 4977 The detection interval for the receiving 4978 BFD peer is calculated by multiplying the value 4979 of the negotiated transmission interval by 4980 the received detection multiplier value."; 4981 reference 4982 "RFC 5880: Bidirectional Forwarding Detection 4983 (BFD), Section 6.8.7"; 4984 } 4985 leaf holdtime { 4986 type uint32; 4987 units "msec"; 4988 description 4989 "Expected BFD holdtime. 4991 The customer may impose some fixed 4992 values for the holdtime period if the 4993 provider allows the customer use of 4994 this function. 4996 If the provider doesn't allow the 4997 customer to use this function, 4998 the fixed-value will not be set."; 4999 reference 5000 "RFC 5880: Bidirectional Forwarding Detection 5001 (BFD), Section 6.8.18"; 5002 } 5003 leaf profile { 5004 type leafref { 5005 path "/l3vpn-ntw/vpn-profiles" 5006 + "/valid-provider-identifiers" 5007 + "/bfd-profile-identifier/id"; 5008 } 5009 description 5010 "Well-known service provider profile name. 5012 The provider can propose some profiles 5013 to the customer, depending on the 5014 service level the customer wants to 5015 achieve."; 5016 } 5017 container authentication { 5018 presence "Enables BFD authentication"; 5019 description 5020 "Parameters for BFD authentication."; 5021 leaf key-chain { 5022 type key-chain:key-chain-ref; 5023 description 5024 "Name of the key-chain."; 5025 } 5026 leaf meticulous { 5027 type boolean; 5028 description 5029 "Enables meticulous mode."; 5030 reference 5031 "RFC 5880: Bidirectional Forwarding 5032 Detection (BFD), Section 6.7"; 5033 } 5034 } 5035 uses vpn-common:service-status; 5036 } 5037 } 5038 container security { 5039 description 5040 "Site-specific security parameters."; 5041 container encryption { 5042 if-feature "vpn-common:encryption"; 5043 description 5044 "Container for CE-PE security encryption."; 5045 leaf enabled { 5046 type boolean; 5047 default "false"; 5048 description 5049 "If true, traffic encryption on the 5050 connection is required. Otherwise, it 5051 is disabled."; 5052 } 5053 leaf layer { 5054 when "../enabled = 'true'" { 5055 description 5056 "It is included only when enryption 5057 is enabled."; 5058 } 5059 type enumeration { 5060 enum layer2 { 5061 description 5062 "Encryption occurs at Layer 2."; 5063 } 5064 enum layer3 { 5065 description 5066 "Encryption occurs at Layer 3. 5067 For example, IPsec may be used when 5068 a customer requests Layer 3 5069 encryption."; 5070 } 5071 } 5072 description 5073 "Indicates the layer on which encryption 5074 is applied."; 5075 } 5077 } 5078 container encryption-profile { 5079 when "../encryption/enabled = 'true'" { 5080 description 5081 "Indicates the layer on which encryption 5082 is enabled."; 5083 } 5084 description 5085 "Container for encryption profile."; 5086 choice profile { 5087 description 5088 "Choice for the encryption profile."; 5089 case provider-profile { 5090 leaf profile-name { 5091 type leafref { 5092 path "/l3vpn-ntw/vpn-profiles" 5093 + "/valid-provider-identifiers" 5094 + "/encryption-profile-identifier/id"; 5095 } 5096 description 5097 "Name of the service provider's profile 5098 to be applied."; 5099 } 5100 } 5101 case customer-profile { 5102 leaf customer-key-chain { 5103 type key-chain:key-chain-ref; 5104 description 5105 "Customer-supplied key chain."; 5106 } 5107 } 5108 } 5109 } 5110 } 5111 container service { 5112 description 5113 "Service parameters of the attachment."; 5114 leaf inbound-bandwidth { 5115 if-feature "vpn-common:inbound-bw"; 5116 type uint64; 5117 units "bps"; 5118 description 5119 "From the customer site's perspective, the 5120 service inbound bandwidth of the connection 5121 or download bandwidth from the SP to 5122 the site. Note that the L3SM uses 'input- 5123 -bandwidth' to refer to the same concept."; 5124 } 5125 leaf outbound-bandwidth { 5126 if-feature "vpn-common:outbound-bw"; 5127 type uint64; 5128 units "bps"; 5129 description 5130 "From the customer site's perspective, 5131 the service outbound bandwidth of the 5132 connection or upload bandwidth from 5133 the site to the SP. Note that the L3SM uses 5134 'output-bandwidth' to refer to the same 5135 concept."; 5136 } 5137 leaf mtu { 5138 type uint32; 5139 units "bytes"; 5140 description 5141 "MTU at service level. If the service is IP, 5142 it refers to the IP MTU. If Carriers' 5143 Carriers (CsC) is enabled, the requested MTU 5144 will refer to the MPLS maximum labeled packet 5145 size and not to the IP MTU."; 5146 } 5147 container qos { 5148 if-feature "vpn-common:qos"; 5149 description 5150 "QoS configuration."; 5151 container qos-classification-policy { 5152 description 5153 "Configuration of the traffic classification 5154 policy."; 5155 uses vpn-common:qos-classification-policy; 5156 } 5157 container qos-action { 5158 description 5159 "List of QoS action policies."; 5160 list rule { 5161 key "id"; 5162 description 5163 "List of QoS actions."; 5164 leaf id { 5165 type string; 5166 description 5167 "An identifier of the QoS action rule."; 5168 } 5169 leaf target-class-id { 5170 type string; 5171 description 5172 "Identification of the class of service. 5174 This identifier is internal to the 5175 administration."; 5176 } 5177 leaf inbound-rate-limit { 5178 type decimal64 { 5179 fraction-digits 5; 5180 range "0..100"; 5181 } 5182 units "percent"; 5183 description 5184 "Specifies whether/how to rate-limit the 5185 inbound traffic matching this QoS policy. 5186 It is expressed as a percent of the value 5187 that is indicated in 'input-bandwidth'."; 5188 } 5189 leaf outbound-rate-limit { 5190 type decimal64 { 5191 fraction-digits 5; 5192 range "0..100"; 5193 } 5194 units "percent"; 5195 description 5196 "Specifies whether/how to rate-limit the 5197 outbound traffic matching this QoS policy. 5198 It is expressed as a percent of the value 5199 that is indicated in 'output-bandwidth'."; 5200 } 5201 } 5202 } 5203 container qos-profile { 5204 description 5205 "QoS profile configuration."; 5206 list qos-profile { 5207 key "profile"; 5208 description 5209 "QoS profile. 5210 Can be standard profile or customized 5211 profile."; 5212 leaf profile { 5213 type leafref { 5214 path "/l3vpn-ntw/vpn-profiles" 5215 + "/valid-provider-identifiers" 5216 + "/qos-profile-identifier/id"; 5217 } 5218 description 5219 "QoS profile to be used."; 5220 } 5221 leaf direction { 5222 type identityref { 5223 base vpn-common:qos-profile-direction; 5224 } 5225 default "vpn-common:both"; 5226 description 5227 "The direction to which the QoS profile 5228 is applied."; 5229 } 5230 } 5231 } 5232 } 5233 container carriers-carrier { 5234 if-feature "vpn-common:carriers-carrier"; 5235 description 5236 "This container is used when the customer 5237 provides MPLS-based services. This is 5238 only used in the case of CsC (i.e., a 5239 customer builds an MPLS service using an 5240 IP VPN to carry its traffic)."; 5241 leaf signaling-type { 5242 type enumeration { 5243 enum ldp { 5244 description 5245 "Use LDP as the signaling protocol 5246 between the PE and the CE. In this 5247 case, an IGP routing protocol must 5248 also be configured."; 5249 } 5250 enum bgp { 5251 description 5252 "Use BGP as the signaling protocol 5253 between the PE and the CE. 5254 In this case, BGP must also be configured 5255 as the routing protocol."; 5256 reference 5257 "RFC 8277: Using BGP to Bind MPLS Labels 5258 to Address Prefixes"; 5259 } 5260 } 5261 default "bgp"; 5262 description 5263 "MPLS signaling type."; 5264 } 5265 } 5266 container ntp { 5267 description 5268 "Time synchronization may be needed in some 5269 VPNs such as infrastructure and Management 5270 VPNs. This container includes parameters to 5271 enable NTP service."; 5272 reference 5273 "RFC 5905: Network Time Protocol Version 4: 5274 Protocol and Algorithms 5275 Specification"; 5276 leaf broadcast { 5277 type enumeration { 5278 enum client { 5279 description 5280 "The VPN node will listen to NTP broadcast 5281 messages on this VPN network access."; 5282 } 5283 enum server { 5284 description 5285 "The VPN node will behave as a broadcast 5286 server."; 5287 } 5288 } 5289 description 5290 "Indicates NTP broadcast mode to use for the 5291 VPN network access."; 5292 } 5293 container auth-profile { 5294 description 5295 "Pointer to a local profile."; 5296 leaf profile-id { 5297 type string; 5298 description 5299 "A pointer to a local authentication 5300 profile on the VPN node is provided."; 5301 } 5302 } 5303 uses vpn-common:service-status; 5304 } 5305 container multicast { 5306 if-feature "vpn-common:multicast"; 5307 description 5308 "Multicast parameters for the network 5309 access."; 5310 leaf access-type { 5311 type enumeration { 5312 enum receiver-only { 5313 description 5314 "The peer site only has receivers."; 5315 } 5316 enum source-only { 5317 description 5318 "The peer site only has sources."; 5319 } 5320 enum source-receiver { 5321 description 5322 "The peer site has both sources and 5323 receivers."; 5324 } 5325 } 5326 default "source-receiver"; 5327 description 5328 "Type of multicast site."; 5329 } 5330 leaf address-family { 5331 type identityref { 5332 base vpn-common:address-family; 5333 } 5334 description 5335 "Indicates the address family."; 5336 } 5337 leaf protocol-type { 5338 type enumeration { 5339 enum host { 5340 description 5341 "Hosts are directly connected to the 5342 provider network. 5344 Host protocols such as IGMP or MLD are 5345 required."; 5346 } 5347 enum router { 5348 description 5349 "Hosts are behind a customer router. 5350 PIM will be implemented."; 5351 } 5352 enum both { 5353 description 5354 "Some hosts are behind a customer router, 5355 and some others are directly connected 5356 to the provider network. Both host and 5357 routing protocols must be used. 5359 Typically, IGMP and PIM will be 5360 implemented."; 5361 } 5362 } 5363 default "both"; 5364 description 5365 "Multicast protocol type to be used with 5366 the customer site."; 5367 } 5368 leaf remote-source { 5369 type boolean; 5370 default "false"; 5371 description 5372 "A remote multicast source is a source that is 5373 not on the same subnet as the 5374 vpn-network-access. When set to 'true', the 5375 multicast traffic from a remote source is 5376 accepted."; 5377 } 5378 container igmp { 5379 when "../protocol-type = 'host' and " 5380 + "../address-family = 'vpn-common:ipv4' or " 5381 + "'vpn-common:dual-stack'"; 5382 if-feature "vpn-common:igmp"; 5383 description 5384 "Includes IGMP-related parameters."; 5385 list static-group { 5386 key "group-addr"; 5387 description 5388 "Multicast static source/group associated to 5389 IGMP session"; 5390 leaf group-addr { 5391 type rt-types:ipv4-multicast-group-address; 5392 description 5393 "Multicast group IPv4 address."; 5394 } 5395 leaf source-addr { 5396 type rt-types:ipv4-multicast-source-address; 5397 description 5398 "Multicast source IPv4 address."; 5399 } 5400 } 5401 leaf max-groups { 5402 type uint32; 5403 description 5404 "Indicates the maximum number of groups."; 5405 } 5406 leaf max-entries { 5407 type uint32; 5408 description 5409 "Indicates the maximum number of IGMP 5410 entries."; 5411 } 5412 leaf max-group-sources { 5413 type uint32; 5414 description 5415 "The maximum number of group sources."; 5416 } 5417 leaf version { 5418 type identityref { 5419 base vpn-common:igmp-version; 5420 } 5421 default "vpn-common:igmpv2"; 5422 description 5423 "Version of the IGMP."; 5424 } 5425 uses vpn-common:service-status; 5426 } 5427 container mld { 5428 when "../protocol-type = 'host' and " 5429 + "../address-family = 'vpn-common:ipv6' or " 5430 + "'vpn-common:dual-stack'"; 5431 if-feature "vpn-common:mld"; 5432 description 5433 "Includes MLD-related parameters."; 5434 list static-group { 5435 key "group-addr"; 5436 description 5437 "Multicast static source/group associated to 5438 the MLD session"; 5439 leaf group-addr { 5440 type rt-types:ipv6-multicast-group-address; 5441 description 5442 "Multicast group IPv6 address."; 5443 } 5444 leaf source-addr { 5445 type rt-types:ipv6-multicast-source-address; 5446 description 5447 "Multicast source IPv6 address."; 5448 } 5449 } 5450 leaf max-groups { 5451 type uint32; 5452 description 5453 "Indicates the maximum number of groups."; 5454 } 5455 leaf max-entries { 5456 type uint32; 5457 description 5458 "Indicates the maximum number of MLD 5459 entries."; 5460 } 5461 leaf max-group-sources { 5462 type uint32; 5463 description 5464 "The maximum number of group sources."; 5465 } 5466 leaf version { 5467 type identityref { 5468 base vpn-common:mld-version; 5469 } 5470 default "vpn-common:mldv2"; 5471 description 5472 "Version of the MLD protocol."; 5473 } 5474 uses vpn-common:service-status; 5475 } 5476 container pim { 5477 when "../protocol-type = 'router'"; 5478 if-feature "vpn-common:pim"; 5479 description 5480 "Only applies when protocol type is PIM."; 5481 leaf hello-interval { 5482 type rt-types:timer-value-seconds16; 5483 default "30"; 5484 description 5485 "PIM hello-messages interval. If set to 5486 'infinity' or 'not-set', no periodic 5487 Hello messages are sent."; 5488 reference 5489 "RFC 7761: Protocol Independent Multicast - 5490 Sparse Mode (PIM-SM): Protocol 5491 Specification (Revised), 5492 Section 4.11"; 5493 } 5494 leaf dr-priority { 5495 type uint32; 5496 default "1"; 5497 description 5498 "Indicates the preference in the DR election 5499 process. A larger value has a higher 5500 priority over a smaller value."; 5501 reference 5502 "RFC 7761: Protocol Independent Multicast - 5503 Sparse Mode (PIM-SM): Protocol 5504 Specification (Revised), 5505 Section 4.3.2"; 5506 } 5507 uses vpn-common:service-status; 5508 } 5509 } 5511 } 5512 } 5513 } 5514 } 5515 } 5516 } 5517 } 5518 } 5519 } 5520 5522 9. Security Considerations 5524 The YANG module specified in this document defines schema for data 5525 that is designed to be accessed via network management protocols such 5526 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 5527 is the secure transport layer, and the mandatory-to-implement secure 5528 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 5529 is HTTPS, and the mandatory-to-implement secure transport is TLS 5530 [RFC8446]. 5532 The Network Configuration Access Control Model (NACM) [RFC8341] 5533 provides the means to restrict access for particular NETCONF or 5534 RESTCONF users to a preconfigured subset of all available NETCONF or 5535 RESTCONF protocol operations and content. 5537 There are a number of data nodes defined in this YANG module that are 5538 writable/creatable/deletable (i.e., config true, which is the 5539 default). These data nodes may be considered sensitive or vulnerable 5540 in some network environments. Write operations (e.g., edit-config) 5541 and delete operations to these data nodes without proper protection 5542 or authentication can have a negative effect on network operations. 5543 These are the subtrees and data nodes and their sensitivity/ 5544 vulnerability in the "ietf-l3vpn-ntw" module: 5546 * 'vpn-profiles': This container includes a set of sensitive data 5547 that influence how the L3VPN service is delivered. For example, 5548 an attacker who has access to these data nodes may be able to 5549 manipulate routing policies, QoS policies, or encryption 5550 properties. These data nodes are defined with "nacm:default-deny- 5551 write" tagging [I-D.ietf-opsawg-vpn-common]. 5553 * 'vpn-services': An attacker who is able to access network nodes 5554 can undertake various attacks, such as deleting a running L3VPN 5555 service, interrupting all the traffic of a client. In addition, 5556 an attacker may modify the attributes of a running service (e.g., 5557 QoS, bandwidth, routing protocols), leading to malfunctioning of 5558 the service and therefore to SLA violations. In addition, an 5559 attacker could attempt to create an L3VPN service or add a new 5560 network access. In addition to using NACM to prevent authorized 5561 access, such activity can be detected by adequately monitoring and 5562 tracking network configuration changes. 5564 Some readable data nodes in this YANG module may be considered 5565 sensitive or vulnerable in some network environments. It is thus 5566 important to control read access (e.g., via get, get-config, or 5567 notification) to these data nodes. These are the subtrees and data 5568 nodes and their sensitivity/vulnerability: 5570 * 'customer-name' and 'ip-connection': An attacker can retrieve 5571 privacy-related information which can be used to track a customer. 5572 Disclosing such information may be considered as a violation of 5573 the customer-provider trust relationship. 5575 Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'bfd') rely 5576 upon [RFC8177] for authentication purposes. Therefore, this module 5577 inherits the security considerations discussed in Section 5 of 5578 [RFC8177]. Also, these data nodes support supplying explicit keys as 5579 strings in ASCII format. The use of keys in hexadecimal string 5580 format would afford greater key entropy with the same number of key- 5581 string octets. However, such format is not included in this version 5582 of the L3NM because it is not supported by the underlying device 5583 modules (e.g., [RFC8695]). 5585 As discussed in Section 7.6.3, the module supports MD5 to basically 5586 accommodate the installed BGP base. MD5 suffers from the security 5587 weaknesses discussed in Section 2 of [RFC6151] or Section 2.1 of 5588 [RFC6952]. 5590 [RFC8633] describes best current practices to be considered in VPNs 5591 making use of NTP. Moreover, a mechanism to provide cryptographic 5592 security for NTP is specified in [RFC8915]. 5594 10. IANA Considerations 5596 This document requests IANA to register the following URI in the "ns" 5597 subregistry within the "IETF XML Registry" [RFC3688]: 5599 URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw 5600 Registrant Contact: The IESG. 5601 XML: N/A; the requested URI is an XML namespace. 5603 This document requests IANA to register the following YANG module in 5604 the "YANG Module Names" subregistry [RFC6020] within the "YANG 5605 Parameters" registry. 5607 name: ietf-l3vpn-ntw 5608 namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw 5609 maintained by IANA: N 5610 prefix: l3nm 5611 reference: RFC XXXX 5613 11. References 5615 11.1. Normative References 5617 [I-D.ietf-opsawg-vpn-common] 5618 Barguil, S., Dios, O. G. D., Boucadair, M., and Q. Wu, "A 5619 Layer 2/3 VPN Common YANG Model", Work in Progress, 5620 Internet-Draft, draft-ietf-opsawg-vpn-common-11, 23 5621 September 2021, . 5624 [ISO10589] ISO, "Intermediate System to Intermediate System intra- 5625 domain routeing information exchange protocol for use in 5626 conjunction with the protocol for providing the 5627 connectionless-mode network service (ISO 8473)", 2002, 5628 . 5630 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 5631 RFC 1112, DOI 10.17487/RFC1112, August 1989, 5632 . 5634 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 5635 dual environments", RFC 1195, DOI 10.17487/RFC1195, 5636 December 1990, . 5638 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 5639 DOI 10.17487/RFC2080, January 1997, 5640 . 5642 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5643 Requirement Levels", BCP 14, RFC 2119, 5644 DOI 10.17487/RFC2119, March 1997, 5645 . 5647 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 5648 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, 5649 . 5651 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 5652 DOI 10.17487/RFC2453, November 1998, 5653 . 5655 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 5656 Listener Discovery (MLD) for IPv6", RFC 2710, 5657 DOI 10.17487/RFC2710, October 1999, 5658 . 5660 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 5661 Thyagarajan, "Internet Group Management Protocol, Version 5662 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 5663 . 5665 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 5666 DOI 10.17487/RFC3688, January 2004, 5667 . 5669 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 5670 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 5671 DOI 10.17487/RFC3810, June 2004, 5672 . 5674 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 5675 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 5676 DOI 10.17487/RFC4271, January 2006, 5677 . 5679 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 5680 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 5681 2006, . 5683 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 5684 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 5685 . 5687 [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the 5688 Provider/Customer Edge Protocol for BGP/MPLS IP Virtual 5689 Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, 5690 June 2006, . 5692 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 5693 DOI 10.17487/RFC5308, October 2008, 5694 . 5696 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community 5697 Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, 5698 . 5700 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 5701 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 5702 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 5703 2009, . 5705 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 5706 Version 3 for IPv4 and IPv6", RFC 5798, 5707 DOI 10.17487/RFC5798, March 2010, 5708 . 5710 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 5711 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 5712 . 5714 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 5715 "Network Time Protocol Version 4: Protocol and Algorithms 5716 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 5717 . 5719 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 5720 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 5721 June 2010, . 5723 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 5724 the Network Configuration Protocol (NETCONF)", RFC 6020, 5725 DOI 10.17487/RFC6020, October 2010, 5726 . 5728 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 5729 and A. Bierman, Ed., "Network Configuration Protocol 5730 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 5731 . 5733 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 5734 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 5735 . 5737 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 5738 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 5739 2012, . 5741 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 5742 Encodings and Procedures for Multicast in MPLS/BGP IP 5743 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 5744 . 5746 [RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and 5747 M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge 5748 (PE-CE) Routing Protocol", RFC 6565, DOI 10.17487/RFC6565, 5749 June 2012, . 5751 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 5752 RFC 6991, DOI 10.17487/RFC6991, July 2013, 5753 . 5755 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 5756 Authentication Trailer for OSPFv3", RFC 7166, 5757 DOI 10.17487/RFC7166, March 2014, 5758 . 5760 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 5761 "Security Extension for OSPFv2 When Using Manual Key 5762 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 5763 . 5765 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 5766 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 5767 Multicast - Sparse Mode (PIM-SM): Protocol Specification 5768 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 5769 2016, . 5771 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 5772 RFC 7950, DOI 10.17487/RFC7950, August 2016, 5773 . 5775 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 5776 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 5777 . 5779 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5780 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5781 May 2017, . 5783 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 5784 Zhang, "YANG Data Model for Key Chains", RFC 8177, 5785 DOI 10.17487/RFC8177, June 2017, 5786 . 5788 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 5789 "Common YANG Data Types for the Routing Area", RFC 8294, 5790 DOI 10.17487/RFC8294, December 2017, 5791 . 5793 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 5794 Access Control Model", STD 91, RFC 8341, 5795 DOI 10.17487/RFC8341, March 2018, 5796 . 5798 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 5799 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 5800 . 5802 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 5803 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 5804 . 5806 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 5807 Data Model for Layer 2 Virtual Private Network (L2VPN) 5808 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 5809 2018, . 5811 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 5812 "YANG Data Model for Network Access Control Lists (ACLs)", 5813 RFC 8519, DOI 10.17487/RFC8519, March 2019, 5814 . 5816 11.2. Informative References 5818 [I-D.evenwu-opsawg-yang-composed-vpn] 5819 Even, R., Wu, B., Wu, Q., and YingCheng, "YANG Data Model 5820 for Composed VPN Service Delivery", Work in Progress, 5821 Internet-Draft, draft-evenwu-opsawg-yang-composed-vpn-03, 5822 8 March 2019, . 5825 [I-D.ietf-bess-evpn-prefix-advertisement] 5826 Rabadan, J., Henderickx, W., Drake, J. E., Lin, W., and A. 5827 Sajassi, "IP Prefix Advertisement in EVPN", Work in 5828 Progress, Internet-Draft, draft-ietf-bess-evpn-prefix- 5829 advertisement-11, 18 May 2018, 5830 . 5833 [I-D.ietf-idr-bgp-model] 5834 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 5835 YANG Model for Service Provider Networks", Work in 5836 Progress, Internet-Draft, draft-ietf-idr-bgp-model-11, 11 5837 July 2021, . 5840 [I-D.ietf-pim-yang] 5841 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 5842 Y., and F. Hu, "A YANG Data Model for Protocol Independent 5843 Multicast (PIM)", Work in Progress, Internet-Draft, draft- 5844 ietf-pim-yang-17, 19 May 2018, 5845 . 5848 [I-D.ietf-rtgwg-qos-model] 5849 Choudhary, A., Jethanandani, M., Strahle, N., Aries, E., 5850 and I. Chen, "A YANG Data Model for Quality of Service 5851 (QoS)", Work in Progress, Internet-Draft, draft-ietf- 5852 rtgwg-qos-model-04, 12 July 2021, 5853 . 5856 [I-D.ietf-teas-enhanced-vpn] 5857 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 5858 Framework for Enhanced Virtual Private Network (VPN+) 5859 Services", Work in Progress, Internet-Draft, draft-ietf- 5860 teas-enhanced-vpn-08, 12 July 2021, 5861 . 5864 [I-D.ietf-teas-ietf-network-slices] 5865 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 5866 Makhijani, K., Contreras, L. M., and J. Tantsura, 5867 "Framework for IETF Network Slices", Work in Progress, 5868 Internet-Draft, draft-ietf-teas-ietf-network-slices-04, 23 5869 August 2021, . 5872 [I-D.ogondio-opsawg-uni-topology] 5873 Dios, O. G. D., Barguil, S., Wu, Q., and M. Boucadair, "A 5874 YANG Model for User-Network Interface (UNI) Topologies", 5875 Work in Progress, Internet-Draft, draft-ogondio-opsawg- 5876 uni-topology-01, 2 April 2020, 5877 . 5880 [IEEE802.1AX] 5881 "Link Aggregation", IEEE Std 802.1AX-2020, 2020. 5883 [PYANG] "pyang", November 2020, 5884 . 5886 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 5887 Discovery Protocol (MSDP)", RFC 3618, 5888 DOI 10.17487/RFC3618, October 2003, 5889 . 5891 [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. 5892 Moore, "Policy Quality of Service (QoS) Information 5893 Model", RFC 3644, DOI 10.17487/RFC3644, November 2003, 5894 . 5896 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 5897 Private Network (VPN) Terminology", RFC 4026, 5898 DOI 10.17487/RFC4026, March 2005, 5899 . 5901 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 5902 Provider-Provisioned Virtual Private Networks (PPVPNs)", 5903 RFC 4110, DOI 10.17487/RFC4110, July 2005, 5904 . 5906 [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., 5907 and A. Gonguet, "Framework for Layer 3 Virtual Private 5908 Networks (L3VPN) Operations and Management", RFC 4176, 5909 DOI 10.17487/RFC4176, October 2005, 5910 . 5912 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 5913 Address Autoconfiguration", RFC 4862, 5914 DOI 10.17487/RFC4862, September 2007, 5915 . 5917 [RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco 5918 Systems' Solution for Multicast in BGP/MPLS IP VPNs", 5919 RFC 6037, DOI 10.17487/RFC6037, October 2010, 5920 . 5922 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 5923 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 5924 RFC 6151, DOI 10.17487/RFC6151, March 2011, 5925 . 5927 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 5928 BGP, LDP, PCEP, and MSDP Issues According to the Keying 5929 and Authentication for Routing Protocols (KARP) Design 5930 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 5931 . 5933 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 5934 Networking: A Perspective from within a Service Provider 5935 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 5936 . 5938 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 5939 Connectivity Provisioning Profile (CPP)", RFC 7297, 5940 DOI 10.17487/RFC7297, July 2014, 5941 . 5943 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 5944 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 5945 Defined Networking (SDN): Layers and Architecture 5946 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 5947 2015, . 5949 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 5950 Pallagatti, "Seamless Bidirectional Forwarding Detection 5951 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 5952 . 5954 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 5955 Code: The Implementation Status Section", BCP 205, 5956 RFC 7942, DOI 10.17487/RFC7942, July 2016, 5957 . 5959 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 5960 Maintenance Using the Label Distribution Protocol (LDP)", 5961 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 5962 . 5964 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 5965 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 5966 . 5968 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 5969 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 5970 DOI 10.17487/RFC8299, January 2018, 5971 . 5973 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 5974 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 5975 . 5977 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 5978 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 5979 . 5981 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 5982 and R. Wilton, "Network Management Datastore Architecture 5983 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 5984 . 5986 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 5987 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 5988 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 5989 2018, . 5991 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 5992 Routing Management (NMDA Version)", RFC 8349, 5993 DOI 10.17487/RFC8349, March 2018, 5994 . 5996 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 5997 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 5998 DOI 10.17487/RFC8453, August 2018, 5999 . 6001 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 6002 Vinapamula, S., and Q. Wu, "A YANG Module for Network 6003 Address Translation (NAT) and Network Prefix Translation 6004 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 6005 . 6007 [RFC8633] Reilly, D., Stenn, H., and D. Sibold, "Network Time 6008 Protocol Best Current Practices", BCP 223, RFC 8633, 6009 DOI 10.17487/RFC8633, July 2019, 6010 . 6012 [RFC8695] Liu, X., Sarda, P., and V. Choudhary, "A YANG Data Model 6013 for the Routing Information Protocol (RIP)", RFC 8695, 6014 DOI 10.17487/RFC8695, February 2020, 6015 . 6017 [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 6018 Sundblad, "Network Time Security for the Network Time 6019 Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, 6020 . 6022 [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and 6023 L. Geng, "A Framework for Automating Service and Network 6024 Management with YANG", RFC 8969, DOI 10.17487/RFC8969, 6025 January 2021, . 6027 Appendix A. L3VPN Examples 6029 A.1. 4G VPN Provisioning Example 6031 L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise 6032 services mainly because several traffic discrimination policies can 6033 be applied within the network to deliver to the mobile customers a 6034 service that meets the SLA requirements. 6036 As it is shown in the Figure 31, typically, an eNodeB (CE) is 6037 directly connected to the access routers of the mobile backhaul and 6038 their logical interfaces (one or many according to the service type) 6039 are configured in a VPN that transports the packets to the mobile 6040 core platforms. In this example, a 'vpn-node' is created with two 6041 'vpn-network-accesses'. 6043 +-------------+ +------------------+ 6044 | | | PE | 6045 | | | 198.51.100.1 | 6046 | eNodeB |>--------/------->|........... | 6047 | | vlan 1 | | | 6048 | |>--------/------->|...... | | 6049 | | vlan 2 | | | | 6050 | | Direct | +-------------+ | 6051 +-------------+ Routing | | vpn-node-id | | 6052 | | 44 | | 6053 | +-------------+ | 6054 | | 6055 +------------------+ 6057 Figure 31: Mobile Backhaul Example 6059 To create an L3VPN service using the L3NM, the following steps can be 6060 followed. 6062 First: Create the 4G VPN service (Figure 32). 6064 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services 6065 Host: example.com 6066 Content-Type: application/yang-data+json 6068 { 6069 "ietf-l3vpn-ntw:vpn-services": { 6070 "vpn-service": [ 6071 { 6072 "vpn-id": "4G", 6073 "customer-name": "mycustomer", 6074 "vpn-service-topology": "custom", 6075 "description": "VPN to deploy 4G services", 6076 "vpn-instance-profiles": { 6077 "vpn-instance-profile": [ 6078 { 6079 "profile-id": "simple-profile", 6080 "local-as": 65550, 6081 "rd": "0:65550:1", 6082 "address-family": [ 6083 { 6084 "address-family": "vpn-common:dual-stack", 6085 "vpn-targets": { 6086 "vpn-target": [ 6087 { 6088 "id": "1", 6089 "route-targets": [ 6090 "0:65550:1" 6091 ], 6092 "route-target-type": "both" 6093 } 6094 ] 6095 } 6096 } 6097 ] 6098 } 6099 ] 6100 } 6101 } 6102 ] 6103 } 6104 } 6106 Figure 32: Create VPN Service 6108 Second: Create a VPN node as depicted in Figure 33. In this type of 6109 service, the VPN node is equivalent to the VRF configured in the 6110 physical device ('ne-id'=198.51.100.1). 6112 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ 6113 vpn-services/vpn-service=4G 6114 Host: example.com 6115 Content-Type: application/yang-data+json 6117 { 6118 "ietf-l3vpn-ntw:vpn-nodes": { 6119 "vpn-node": [ 6120 { 6121 "vpn-node-id": "44", 6122 "ne-id": "198.51.100.1", 6123 "active-vpn-instance-profiles": { 6124 "vpn-instance-profile": [ 6125 { 6126 "profile-id": "simple-profile" 6127 } 6128 ] 6129 } 6130 } 6131 ] 6132 } 6133 } 6135 Figure 33: Create VPN Node 6137 Finally, two VPN network accesses are created using the same physical 6138 port ('interface-id'=1/1/1). Each 'vpn-network-access' has a 6139 particular VLAN (1,2) to differentiate the traffic between: Sync and 6140 data (Figure 34). 6142 POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ 6143 vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44 6144 content-type: application/yang-data+json 6146 { 6147 "ietf-l3vpn-ntw:vpn-network-accesses": { 6148 "vpn-network-access": [ 6149 { 6150 "id": "1/1/1.1", 6151 "interface-id": "1/1/1", 6152 "description": "Interface SYNC to eNODE-B", 6153 "vpn-network-access-type": "vpn-common:point-to-point", 6154 "vpn-instance-profile": "simple-profile", 6155 "status": { 6156 "admin-status": { 6157 "status": "vpn-common:admin-state-up" 6158 } 6159 }, 6160 "connection": { 6161 "encapsulation": { 6162 "type": "dot1q", 6163 "dot1q": { 6164 "cvlan-id": 1 6165 } 6166 } 6167 }, 6168 "ip-connection": { 6169 "ipv4": { 6170 "local-address": "192.0.2.1", 6171 "prefix-length": 30, 6172 "address-allocation-type": "static-address", 6173 "static-addresses": { 6174 "primary-address": "1", 6175 "address": [ 6176 { 6177 "address-id": "1", 6178 "customer-address": "192.0.2.2" 6179 } 6180 ] 6181 } 6182 }, 6183 "ipv6": { 6184 "local-address": "2001:db8::1", 6185 "prefix-length": 64, 6186 "address-allocation-type": "static-address", 6187 "primary-address": "1", 6188 "address": [ 6189 { 6190 "address-id": "1", 6191 "customer-address": "2001:db8::2" 6192 } 6193 ] 6194 } 6195 }, 6196 "routing-protocols": { 6197 "routing-protocol": [ 6198 { 6199 "id": "1", 6200 "type": "vpn-common:direct" 6201 } 6202 ] 6203 } 6204 }, 6205 { 6206 "id": "1/1/1.2", 6207 "interface-id": "1/1/1", 6208 "description": "Interface DATA to eNODE-B", 6209 "vpn-network-access-type": "vpn-common:point-to-point", 6210 "vpn-instance-profile": "simple-profile", 6211 "status": { 6212 "admin-status": { 6213 "status": "vpn-common:admin-state-up" 6214 } 6215 }, 6216 "connection": { 6217 "encapsulation": { 6218 "type": "dot1q", 6219 "dot1q": { 6220 "cvlan-id": 2 6221 } 6222 } 6223 }, 6224 "ip-connection": { 6225 "ipv4": { 6226 "local-address": "192.0.2.1", 6227 "prefix-length": 30, 6228 "address-allocation-type": "static-address", 6229 "static-addresses": { 6230 "primary-address": "1", 6231 "address": [ 6232 { 6233 "address-id": "1", 6234 "customer-address": "192.0.2.2" 6235 } 6236 ] 6237 } 6238 }, 6239 "ipv6": { 6240 "local-address": "2001:db8::1", 6241 "prefix-length": 64, 6242 "address-allocation-type": "static-address", 6243 "primary-address": "1", 6244 "address": [ 6245 { 6246 "address-id": "1", 6247 "customer-address": "2001:db8::2" 6248 } 6249 ] 6250 } 6251 }, 6252 "routing-protocols": { 6253 "routing-protocol": [ 6254 { 6255 "id": "1", 6256 "type": "vpn-common:direct" 6257 } 6258 ] 6259 } 6260 } 6261 ] 6262 } 6263 } 6265 Figure 34: Create VPN Network Access 6267 A.2. Loopback Interface 6269 An example of loopback interface is depicted in Figure 35. 6271 { 6272 "ietf-l3vpn-ntw:vpn-network-accesses": { 6273 "vpn-network-access": [ 6274 { 6275 "id": "vpn-access-loopback", 6276 "interface-id": "Loopback1", 6277 "description": "An example of loopback interface.", 6278 "vpn-network-access-type": "vpn-common:loopback", 6279 "status": { 6280 "admin-status": { 6281 "status": "vpn-common:admin-state-up" 6282 } 6283 }, 6284 "ip-connection": { 6285 "ipv6": { 6286 "local-address": "2001:db8::4", 6287 "prefix-length": 128 6288 } 6289 } 6290 } 6291 ] 6292 } 6293 } 6295 Figure 35: VPN Network Access with a Loopback Interface (Message 6296 Body) 6298 A.3. Overriding VPN Instance Profile Parameters 6300 Figure 36 shows a simplified example to illustrate how some 6301 information that is provided at the VPN service level (particularly 6302 as part of the 'vpn-instance-profiles') can be overridden by the one 6303 configured at the VPN node level. In this example, PE3 and PE4 6304 inherit the 'vpn-instance-profiles' parameters that are specified at 6305 the VPN service level, but PE1 and PE2 are provided with "maximum- 6306 routes" values at the VPN node level that override the ones that are 6307 specified at the VPN service level. 6309 { 6310 "ietf-l3vpn-ntw:vpn-services": { 6311 "vpn-service": [ 6312 { 6313 "vpn-id": "override-example", 6314 "vpn-service-topology": "vpn-common:hub-spoke", 6315 "vpn-instance-profiles": { 6316 "vpn-instance-profile": [ 6317 { 6318 "profile-id": "HUB", 6319 "role": "vpn-common:hub-role", 6320 "local-as": 64510, 6321 "rd-suffix": 1001, 6322 "address-family": [ 6323 { 6324 "address-family": "vpn-common:dual-stack", 6325 "maximum-routes": [ 6326 { 6327 "protocol": "vpn-common:any", 6328 "maximum-routes": 100 6329 } 6330 ] 6331 } 6332 ] 6333 }, 6334 { 6335 "profile-id": "SPOKE", 6336 "role": "vpn-common:spoke-role", 6337 "local-as": 64510, 6338 "address-family": [ 6339 { 6340 "address-family": "vpn-common:dual-stack", 6341 "maximum-routes": [ 6342 { 6343 "protocol": "vpn-common:any", 6344 "maximum-routes": 1000 6345 } 6347 ] 6348 } 6349 ] 6350 } 6351 ] 6352 }, 6353 "vpn-nodes": { 6354 "vpn-node": [ 6355 { 6356 "vpn-node-id": "PE1", 6357 "ne-id": "pe1", 6358 "router-id": "198.51.100.1", 6359 "active-vpn-instance-profiles": { 6360 "vpn-instance-profile": [ 6361 { 6362 "profile-id": "HUB", 6363 "rd": "1:198.51.100.1:1001", 6364 "address-family": [ 6365 { 6366 "address-family": "vpn-common:dual-stack", 6367 "maximum-routes": [ 6368 { 6369 "protocol": "vpn-common:any", 6370 "maximum-routes": 10 6371 } 6372 ] 6373 } 6374 ] 6375 } 6376 ] 6377 } 6378 }, 6379 { 6380 "vpn-node-id": "PE2", 6381 "ne-id": "pe2", 6382 "router-id": "198.51.100.2", 6383 "active-vpn-instance-profiles": { 6384 "vpn-instance-profile": [ 6385 { 6386 "profile-id": "SPOKE", 6387 "address-family": [ 6388 { 6389 "address-family": "vpn-common:dual-stack", 6390 "maximum-routes": [ 6391 { 6392 "protocol": "vpn-common:any", 6393 "maximum-routes": 100 6394 } 6396 ] 6397 } 6398 ] 6399 } 6400 ] 6401 } 6402 }, 6403 { 6404 "vpn-node-id": "PE3", 6405 "ne-id": "pe3", 6406 "router-id": "198.51.100.3", 6407 "active-vpn-instance-profiles": { 6408 "vpn-instance-profile": [ 6409 { 6410 "profile-id": "SPOKE" 6411 } 6412 ] 6413 } 6414 }, 6415 { 6416 "vpn-node-id": "PE4", 6417 "ne-id": "pe4", 6418 "router-id": "198.51.100.4", 6419 "active-vpn-instance-profiles": { 6420 "vpn-instance-profile": [ 6421 { 6422 "profile-id": "SPOKE" 6423 } 6424 ] 6425 } 6426 } 6427 ] 6428 } 6429 } 6430 ] 6431 } 6432 } 6434 Figure 36: VPN Instance Profile Example (Message Body) 6436 A.4. Multicast VPN Provisioning Example 6438 IPTV is mainly distributed through multicast over the LANs. In the 6439 following example, PIM-SM is enabled and functional between the PE 6440 and the CE. The PE receives multicast traffic from a CE that is 6441 directly connected to the multicast source. The signaling between PE 6442 and CE is achieved using BGP. Also, RP is statically configured for 6443 a multicast group. 6445 +-----------+ +------+ +------+ +-----------+ 6446 | Multicast |---| CE |--/--| PE |----| Backbone | 6447 | source | +------+ +------+ | IP/MPLS | 6448 +-----------+ +-----------+ 6450 Figure 37: Multicast L3VPN Service Example 6452 An example is provided below to illustrate how to configure a 6453 multicast L3VPN service using the L3NM. 6455 First, the multicast service is created together with a generic VPN 6456 instance profile (see the excerpt of the request message body shown 6457 in Figure 38) 6458 { 6459 "ietf-l3vpn-ntw:vpn-services": { 6460 "vpn-service": [ 6461 { 6462 "vpn-id": "Multicast-IPTV", 6463 "vpn-description": "Multicast IPTV VPN service", 6464 "customer-name": "a-name", 6465 "vpn-service-topology": "vpn-common:hub-spoke", 6466 "vpn-instance-profiles": { 6467 "vpn-instance-profile": [ 6468 { 6469 "profile-id": "multicast", 6470 "role": "ietf-vpn-common:hub-role", 6471 "local-as": 65536, 6472 "multicast": { 6473 "rp": { 6474 "rp-group-mappings": { 6475 "rp-group-mapping": [ 6476 { 6477 "id": "1", 6478 "rp-address": "203.0.113.17", 6479 "groups": { 6480 "group": [ 6481 { 6482 "id": "1", 6483 "group-address": "239.130.0.0/15" 6484 } 6485 ] 6486 } 6487 } 6488 ] 6489 }, 6490 "rp-discovery": { 6491 "rp-discovery-type": "vpn-common:static-rp" 6492 } 6493 } 6494 } 6495 } 6496 ] 6497 } 6498 } 6499 ] 6500 } 6501 } 6503 Figure 38: Create Multicast VPN Service (Excerpt of the Message 6504 Request Body) 6506 Then, the VPN nodes are created (see the excerpt of the request 6507 message body shown in Figure 39). In this example, the VPN node will 6508 represent VRF configured in the physical device. 6510 { 6511 "ietf-l3vpn-ntw:vpn-node": [ 6512 { 6513 "vpn-node-id": "500003105", 6514 "description": "VRF-IPTV-MULTICAST", 6515 "ne-id": "198.51.100.10", 6516 "router-id": "198.51.100.10", 6517 "active-vpn-instance-profiles": { 6518 "vpn-instance-profile": [ 6519 { 6520 "profile-id": "multicast", 6521 "rd": "65536:31050202" 6522 } 6523 ] 6524 } 6525 } 6526 ] 6527 } 6529 Figure 39: Create Multicast VPN Node (Excerpt of the Message 6530 Request Body) 6532 Finally, create the VPN network access with multicast enabled (see 6533 the excerpt of the request message body shown in Figure 40). 6535 { 6536 "ietf-l3vpn-ntw:vpn-network-access": { 6537 "id": "1/1/1", 6538 "description": "Connected-to-source", 6539 "vpn-network-access-type": "vpn-common:point-to-point", 6540 "vpn-instance-profile": "multicast", 6541 "status": { 6542 "admin-status": { 6543 "status": "vpn-common:admin-state-up" 6544 }, 6545 "ip-connection": { 6546 "ipv4": { 6547 "local-address": "203.0.113.1", 6548 "prefix-length": 30, 6549 "address-allocation-type": "static-address", 6550 "static-addresses": { 6551 "primary-address": "1", 6552 "address": [ 6553 { 6554 "address-id": "1", 6555 "customer-address": "203.0.113.2" 6556 } 6557 ] 6558 } 6559 } 6560 }, 6561 "routing-protocols": { 6562 "routing-protocol": [ 6563 { 6564 "id": "1", 6565 "type": "vpn-common:bgp-routing", 6566 "bgp": { 6567 "description": "Connected to CE", 6568 "peer-as": "65537", 6569 "address-family": "vpn-common:ipv4", 6570 "neighbor": "203.0.113.2" 6571 } 6572 } 6573 ] 6574 }, 6575 "service": { 6576 "inbound-bandwidth": "100000000", 6577 "outbound-bandwidth": "100000000", 6578 "mtu": 1500, 6579 "multicast": { 6580 "access-type": "source-only", 6581 "address-family": "vpn-common:ipv4", 6582 "protocol-type": "router", 6583 "pim": { 6584 "hello-interval": 30, 6585 "status": { 6586 "admin-status": { 6587 "status": "vpn-common:admin-state-up" 6588 } 6589 } 6590 } 6591 } 6592 } 6593 } 6594 } 6595 } 6597 Figure 40: Create VPN Network Access (Excerpt of the Message 6598 Request Body) 6600 Appendix B. Implementation Status 6602 This section records the status of known implementations of the YANG 6603 module defined by this specification at the time of posting of this 6604 document and is based on a proposal described in [RFC7942]. The 6605 description of implementations in this section is intended to assist 6606 the IETF in its decision processes in progressing drafts to RFCs. 6607 Please note that the listing of any individual implementation here 6608 does not imply endorsement by the IETF. Furthermore, no effort has 6609 been spent to verify the information presented here that was supplied 6610 by IETF contributors. This is not intended as, and must not be 6611 construed to be, a catalog of available implementations or their 6612 features. Readers are advised to note that other implementations may 6613 exist. 6615 According to [RFC7942], "this will allow reviewers and working groups 6616 to assign due consideration to documents that have the benefit of 6617 running code, which may serve as evidence of valuable experimentation 6618 and feedback that have made the implemented protocols more mature. 6619 It is up to the individual working groups to use this information as 6620 they see fit". 6622 Note to the RFC Editor: As per [RFC7942] guidelines, please remove 6623 this Implementation Status apendix prior publication. 6625 B.1. Nokia Implementation 6627 Details can be found at: https://github.com/IETF-OPSAWG- 6628 WG/l3nm/blob/master/Implementattion/Nokia.txt 6630 B.2. Huawei Implementation 6632 Details can be found at: https://github.com/IETF-OPSAWG- 6633 WG/l3nm/blob/master/Implementattion/Huawei.txt 6635 B.3. Infinera Implementation 6637 Details can be found at: https://github.com/IETF-OPSAWG- 6638 WG/l3nm/blob/master/Implementattion/Infinera.txt 6640 B.4. Ribbon-ECI Implementation 6642 Details can be found at: https://github.com/IETF-OPSAWG- 6643 WG/l3nm/blob/master/Implementattion/Ribbon-ECI.txt 6645 B.5. Juniper Implementation 6647 https://github.com/IETF-OPSAWG-WG/lxnm/blob/master/Implementattion/ 6648 Juniper 6650 Acknowledgements 6652 During the discussions of this work, helpful comments, suggestions, 6653 and reviews were received from (listed alphabetically): Raul Arco, 6654 Miguel Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque 6655 Gagliano, Christian Jacquenet, Kireeti Kompella, Julian Lucek, Greg 6656 Mirsky, and Tom Petch. Many thanks to them. Thanks to Philip Eardly 6657 for the review of an early version of the document. 6659 Daniel King, Daniel Voyer, Luay Jalil, and Stephane Litkowski 6660 contributed to early version of the individual submission. Many 6661 thanks to Robert Wilton for the AD review. Thanks to Andrew Malis 6662 for the routing directorate review, Rifaat Shekh-Yusef for the 6663 security directorate review, and Qin Wu for the opsdir review. 6664 Thanks to Michael Scharf for the discussion on TCP-AO. Thanks to 6665 Martin Duke, Lars Eagert, Zaheduzzaman Sarker, Roman Danyliw, Erik 6666 Kline, and Benjamin Kaduk for the IESG review. 6668 This work was supported in part by the European Commission funded 6669 H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727) and Horizon 2020 6670 Secured autonomic traffic management for a Tera of SDN flows 6671 (Teraflow) project (G.A. 101015857). 6673 Contributors 6674 Victor Lopez 6675 Telefonica 6676 Email: victor.lopezalvarez@telefonica.com 6678 Qin Wu 6679 Huawei 6680 Email: bill.wu@huawei.com> 6682 Manuel Julian 6683 Vodafone 6684 Email: manuel-julian.lopez@vodafone.com 6686 Lucia Oliva Ballega 6687 Telefonica 6688 Email: lucia.olivaballega.ext@telefonica.com 6690 Erez Segev 6691 ECI Telecom 6692 Email: erez.segev@ecitele.com> 6694 Paul Sherratt 6695 Gamma Telecom 6696 Email: paul.sherratt@gamma.co.uk 6698 Authors' Addresses 6700 Samier Barguil 6701 Telefonica 6702 Madrid 6703 Spain 6705 Email: samier.barguilgiraldo.ext@telefonica.com 6707 Oscar Gonzalez de Dios (editor) 6708 Telefonica 6709 Madrid 6710 Spain 6712 Email: oscar.gonzalezdedios@telefonica.com 6714 Mohamed Boucadair (editor) 6715 Orange 6716 Rennes 35000 6717 France 6719 Email: mohamed.boucadair@orange.com 6720 Luis Angel Munoz 6721 Vodafone 6722 Spain 6724 Email: luis-angel.munoz@vodafone.com 6726 Alejandro Aguado 6727 Nokia 6728 Madrid 6729 Spain 6731 Email: alejandro.aguado_martin@nokia.com