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