idnits 2.17.1 draft-wu-l3sm-rfc8049bis-07.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 166 instances of too long lines in the document, the longest one being 70 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 482 has weird spacing: '...--rw id str...' == Line 484 has weird spacing: '...--rw id str...' == Line 486 has weird spacing: '...--rw id str...' == Line 488 has weird spacing: '...--rw id str...' == Line 562 has weird spacing: '...roup-id str...' == (16 more instances...) -- The document date (October 13, 2017) is 2386 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) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) ** Obsolete normative reference: RFC 8049 (Obsoleted by RFC 8299) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Wu, Ed. 3 Internet-Draft Huawei 4 Obsoletes: 8049 (if approved) S. Litkowski 5 Intended status: Standards Track Orange 6 Expires: April 16, 2018 L. Tomotaki 7 Verizon 8 K. Ogaki 9 KDDI Corporation 10 October 13, 2017 12 YANG Data Model for L3VPN Service Delivery 13 draft-wu-l3sm-rfc8049bis-07 15 Abstract 17 This document defines a YANG data model that can be used for 18 communication between customers and network operators and to deliver 19 a Layer 3 provider-provisioned VPN service. This document is limited 20 to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This 21 model is intended to be instantiated at the management system to 22 deliver the overall service. It is not a configuration model to be 23 used directly on network elements. This model provides an abstracted 24 view of the Layer 3 IP VPN service configuration components. It will 25 be up to the management system to take this model as input and use 26 specific configuration models to configure the different network 27 elements to deliver the service. How the configuration of network 28 elements is done is out of scope for this document. 30 This document obsoletes RFC 8049 to replace the unimplementable 31 module in that RFC with a new module with the same name that is not 32 backward compatible. The changes are a series of small fixes to the 33 YANG module, and some clarifications to the text. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 16, 2018. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 71 1.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 72 1.4. Summary of Changes from RFC 8049 . . . . . . . . . . . . 5 73 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 4. Layer 3 IP VPN Service Model . . . . . . . . . . . . . . . . 9 76 5. Service Data Model Usage . . . . . . . . . . . . . . . . . . 9 77 6. Design of the Data Model . . . . . . . . . . . . . . . . . . 11 78 6.1. Features and Augmentation . . . . . . . . . . . . . . . . 20 79 6.2. VPN Service Overview . . . . . . . . . . . . . . . . . . 20 80 6.2.1. VPN Service Topology . . . . . . . . . . . . . . . . 20 81 6.2.2. Cloud Access . . . . . . . . . . . . . . . . . . . . 23 82 6.2.3. Multicast Service . . . . . . . . . . . . . . . . . . 26 83 6.2.4. Extranet VPNs . . . . . . . . . . . . . . . . . . . . 28 84 6.3. Site Overview . . . . . . . . . . . . . . . . . . . . . . 29 85 6.3.1. Devices and Locations . . . . . . . . . . . . . . . . 31 86 6.3.2. Site Network Accesses . . . . . . . . . . . . . . . . 31 87 6.4. Site Role . . . . . . . . . . . . . . . . . . . . . . . . 34 88 6.5. Site Belonging to Multiple VPNs . . . . . . . . . . . . . 34 89 6.5.1. Site VPN Flavor . . . . . . . . . . . . . . . . . . . 34 90 6.5.2. Attaching a Site to a VPN . . . . . . . . . . . . . . 38 91 6.6. Deciding Where to Connect the Site . . . . . . . . . . . 44 92 6.6.1. Constraint: Device . . . . . . . . . . . . . . . . . 45 93 6.6.2. Constraint/Parameter: Site Location . . . . . . . . . 45 94 6.6.3. Constraint/Parameter: Access Type . . . . . . . . . . 47 95 6.6.4. Constraint: Access Diversity . . . . . . . . . . . . 47 96 6.6.5. Infeasible Access Placement . . . . . . . . . . . . . 57 97 6.6.6. Examples of Access Placement . . . . . . . . . . . . 57 98 6.6.7. Route Distinguisher and VRF Allocation . . . . . . . 78 99 6.7. Site Network Access Availability . . . . . . . . . . . . 79 100 6.8. Traffic Protection . . . . . . . . . . . . . . . . . . . 80 101 6.9. Security . . . . . . . . . . . . . . . . . . . . . . . . 81 102 6.9.1. Authentication . . . . . . . . . . . . . . . . . . . 81 103 6.9.2. Encryption . . . . . . . . . . . . . . . . . . . . . 81 104 6.10. Management . . . . . . . . . . . . . . . . . . . . . . . 82 105 6.11. Routing Protocols . . . . . . . . . . . . . . . . . . . . 83 106 6.11.1. Handling of Dual Stack . . . . . . . . . . . . . . . 83 107 6.11.2. LAN Directly Connected to SP Network . . . . . . . . 85 108 6.11.3. LAN Directly Connected to SP Network with Redundancy 85 109 6.11.4. Static Routing . . . . . . . . . . . . . . . . . . . 86 110 6.11.5. RIP Routing . . . . . . . . . . . . . . . . . . . . 86 111 6.11.6. OSPF Routing . . . . . . . . . . . . . . . . . . . . 87 112 6.11.7. BGP Routing . . . . . . . . . . . . . . . . . . . . 88 113 6.12. Service . . . . . . . . . . . . . . . . . . . . . . . . . 90 114 6.12.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . 91 115 6.12.2. MTU . . . . . . . . . . . . . . . . . . . . . . . . 91 116 6.12.3. QoS . . . . . . . . . . . . . . . . . . . . . . . . 91 117 6.12.4. Multicast . . . . . . . . . . . . . . . . . . . . . 100 118 6.13. Enhanced VPN Features . . . . . . . . . . . . . . . . . . 100 119 6.13.1. Carriers' Carriers . . . . . . . . . . . . . . . . . 100 120 6.14. External ID References . . . . . . . . . . . . . . . . . 102 121 6.15. Defining NNIs . . . . . . . . . . . . . . . . . . . . . . 102 122 6.15.1. Defining an NNI with the Option A Flavor . . . . . . 104 123 6.15.2. Defining an NNI with the Option B Flavor . . . . . . 107 124 6.15.3. Defining an NNI with the Option C Flavor . . . . . . 110 125 7. Service Model Usage Example . . . . . . . . . . . . . . . . . 111 126 8. Interaction with Other YANG Modules . . . . . . . . . . . . . 117 127 9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 122 128 10. Security Considerations . . . . . . . . . . . . . . . . . . . 180 129 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 180 130 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 181 131 12.1. Normative References . . . . . . . . . . . . . . . . . . 181 132 12.2. Informative References . . . . . . . . . . . . . . . . . 182 133 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 182 134 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 183 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 183 137 1. Introduction 139 This document defines a Layer 3 VPN service data model written in 140 YANG. The model defines service configuration elements that can be 141 used in communication protocols between customers and network 142 operators. Those elements can also be used as input to automated 143 control and configuration applications. 145 The YANG module described in [RFC8049] cannot be implemented because 146 of issues around the use of XPATH. This document obsoletes [RFC8049] 147 by creating a new module with the same name that is not backward 148 compatible (in the sense described in YANG 1.1 [RFC7950]). The 149 changes (listed in full in Section 1.4) are small in scope, but 150 include fixes to the module to make it possible to implement. 152 1.1. Terminology 154 The following terms are defined in [RFC6241] and are not redefined 155 here: 157 o client 159 o configuration data 161 o server 163 o state data 165 The following terms are defined in [RFC7950] and are not redefined 166 here: 168 o augment 170 o data model 172 o data node 174 The terminology for describing YANG data models is found in 175 [RFC7950]. 177 This document presents some configuration examples using XML 178 representation. 180 1.2. Requirements Language 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [RFC2119]. 186 1.3. Tree Diagrams 188 A simplified graphical representation of the data model is presented 189 in Section 6. 191 The meanings of the symbols in these diagrams are as follows: 193 o Brackets "[" and "]" enclose list keys. 195 o Curly braces "{" and "}" contain names of optional features that 196 make the corresponding node conditional. 198 o Abbreviations before data node names: "rw" means configuration 199 data (read-write), and "ro" means state data (read-only). 201 o Symbols after data node names: "?" means an optional node, and "*" 202 denotes a "list" or "leaf-list". 204 o Parentheses enclose choice and case nodes, and case nodes are also 205 marked with a colon (":"). 207 o Ellipsis ("...") stands for contents of subtrees that are not 208 shown. 210 1.4. Summary of Changes from RFC 8049 212 This document revises and obsoletes L3VPN Service Model [RFC8049] , 213 drawing on insights gained from L3VPN Service Model deployments and 214 on feedback from the community. The major changes are: 216 o Change type from 16-bit integer to string for the leaf id under 217 "qos-classification-policy" container. 219 o Stick to using ordered-by user and remove inefficiency to map 220 service model sequence number to device model sequence number. 222 o Remove mandating the use of deviations and add "if-feature target- 223 sites" under the leaf-list target-sites in section 6.12.2. 225 o RFC2119 language changes on operation of the management system in 226 Section 6.6,3rd paragraph,Section 6.6.5 and section 7. 228 o Fix incomplete description statements. 230 o Add YANG statement to check that slaac parameters are used only 231 for IPv6. 233 o Fix strange wording in the section 6.11.7. 235 o Change the use of the absolute paths to the use of relative paths 236 in the "must" statement or "path" statement for vpn-policy-id leaf 237 node, management container, location leaf node, devices container, 238 location case, location-reference leaf, device case, device- 239 reference leaf to make configuration is only applicable to the 240 current sites. 242 o Change "must" statement to "when" statement for management 243 container device container. 245 o Fix optional parameter issues by adding a default or description 246 for others or make some of them mandatory. 248 o Define new grouping vpn-profile-cfg for all the identifiers 249 provided by SP to the customer. The identifiers include cloud- 250 identifier, std-qos-profile, OAM profile-name, and provider- 251 profile for encryption. 253 o Add in the XPATH string representation of identityrefs and remove 254 unqualified name. Change from YANG 1.0 Support to YANG 1.1 255 Support. 257 o Remove "when" statement from leaf nat44-customer-address. 259 o Fixed broken example and Add mandatory element in the examples. 261 o Remove redundant parameters in the cloud access. 263 o Specify provider address and a list of start-end addresses from 264 provider address for DHCP case. 266 o Add a few text to clarify what the site is in section 6.3. 268 o Add multi-filter and multi-VPN per entry support for VPN policy. 270 o Modify description for svc-input-bandwidth leaf and svc-output- 271 bandwidth leaf to make it consistent with the text in section 272 6.12.1. 274 o Clarify the rational of the model in the section 5. 276 o Add text to clarify the way to achieve Per-VPN QoS policy. 278 2. Acronyms 280 AAA: Authentication, Authorization, and Accounting. 282 ACL: Access Control List. 284 ADSL: Asymmetric DSL. 286 AH: Authentication Header. 288 AS: Autonomous System. 290 ASBR: Autonomous System Border Router. 292 ASM: Any-Source Multicast. 294 BAS: Broadband Access Switch. 296 BFD: Bidirectional Forwarding Detection. 298 BGP: Border Gateway Protocol. 300 BSR: Bootstrap Router. 302 CE: Customer Edge. 304 CLI: Command Line Interface. 306 CsC: Carriers' Carriers. 308 CSP: Cloud Service Provider. 310 DHCP: Dynamic Host Configuration Protocol. 312 DSLAM: Digital Subscriber Line Access Multiplexer. 314 ESP: Encapsulating Security Payload. 316 GRE: Generic Routing Encapsulation. 318 IGMP: Internet Group Management Protocol. 320 LAN: Local Area Network. 322 MLD: Multicast Listener Discovery. 324 MTU: Maximum Transmission Unit. 326 NAT: Network Address Translation. 328 NETCONF: Network Configuration Protocol. 330 NNI: Network-to-Network Interface. 332 OAM: Operations, Administration, and Maintenance. 334 OSPF: Open Shortest Path First. 336 OSS: Operations Support System. 338 PE: Provider Edge. 340 PIM: Protocol Independent Multicast. 342 POP: Point of Presence. 344 QoS: Quality of Service. 346 RD: Route Distinguisher. 348 RIP: Routing Information Protocol. 350 RP: Rendezvous Point. 352 RT: Route Target. 354 SFTP: Secure FTP. 356 SLA: Service Level Agreement. 358 SLAAC: Stateless Address Autoconfiguration. 360 SP: Service Provider. 362 SPT: Shortest Path Tree. 364 SSM: Source-Specific Multicast. 366 VM: Virtual Machine. 368 VPN: Virtual Private Network. 370 VRF: VPN Routing and Forwarding. 372 VRRP: Virtual Router Redundancy Protocol. 374 3. Definitions 376 Customer Edge (CE) Device: A CE is equipment dedicated to a 377 particular customer; it is directly connected (at Layer 3) to one or 378 more PE devices via attachment circuits. A CE is usually located at 379 the customer premises and is usually dedicated to a single VPN, 380 although it may support multiple VPNs if each one has separate 381 attachment circuits. 383 Provider Edge (PE) Device: A PE is equipment managed by the SP; it 384 can support multiple VPNs for different customers and is directly 385 connected (at Layer 3) to one or more CE devices via attachment 386 circuits. A PE is usually located at an SP point of presence (POP) 387 and is managed by the SP. 389 PE-Based VPNs: The PE devices know that certain traffic is VPN 390 traffic. They forward the traffic (through tunnels) based on the 391 destination IP address of the packet and, optionally, based on other 392 information in the IP header of the packet. The PE devices are 393 themselves the tunnel endpoints. The tunnels may make use of various 394 encapsulations to send traffic over the SP network (such as, but not 395 restricted to, GRE, IP-in-IP, IPsec, or MPLS tunnels). 397 4. Layer 3 IP VPN Service Model 399 A Layer 3 IP VPN service is a collection of sites that are authorized 400 to exchange traffic between each other over a shared IP 401 infrastructure. This Layer 3 VPN service model aims at providing a 402 common understanding of how the corresponding IP VPN service is to be 403 deployed over the shared infrastructure. This service model is 404 limited to BGP PE-based VPNs as described in [RFC4026], [RFC4110], 405 and [RFC4364]. 407 5. Service Data Model Usage 408 l3vpn-svc | 409 Model | 410 | 411 +------------------+ +-----+ 412 | Orchestration | < --- > | OSS | 413 +------------------+ +-----+ 414 | | 415 +----------------+ | 416 | Config manager | | 417 +----------------+ | 418 | | 419 | NETCONF/CLI ... 420 | | 421 +------------------------------------------------+ 422 Network 424 +++++++ 425 + AAA + 426 +++++++ 428 ++++++++ Bearer ++++++++ ++++++++ ++++++++ 429 + CE A + ----------- + PE A + + PE B + ---- + CE B + 430 ++++++++ Connection ++++++++ ++++++++ ++++++++ 432 Site A Site B 434 The idea of the L3 IP VPN service model is to propose an abstracted 435 interface between customers and network operators to manage 436 configuration of components of an L3VPN service. The model is 437 intended to be used in a mode where the network operator's system is 438 the server and the customer's system is the client. A typical 439 scenario would be to use this model as an input for an orchestration 440 layer that will be responsible for translating it to an orchestrated 441 configuration of network elements that will be part of the service. 442 The network elements can be routers but can also be servers (like 443 AAA); the network's configuration is not limited to these examples. 444 The configuration of network elements can be done via the CLI, 445 NETCONF/RESTCONF [RFC6241] [RFC8040] coupled with YANG data models of 446 a specific configuration (BGP, VRF, BFD, etc.), or some other 447 technique, as preferred by the operator. 449 The usage of this service model is not limited to this example; it 450 can be used by any component of the management system but not 451 directly by network elements. 453 6. Design of the Data Model 455 The YANG module is divided into two main containers: "vpn-services" 456 and "sites". 458 The "vpn-service" list under the vpn-services container defines 459 global parameters for the VPN service for a specific customer. 461 A "site" is composed of at least one "site-network-access" and, in 462 the case of multihoming, may have multiple site-network-access 463 points. The site-network-access attachment is done through a 464 "bearer" with an "ip-connection" on top. The bearer refers to 465 properties of the attachment that are below Layer 3, while the 466 connection refers to properties oriented to the Layer 3 protocol. 467 The bearer may be allocated dynamically by the SP, and the customer 468 may provide some constraints or parameters to drive the placement of 469 the access. 471 Authorization of traffic exchange is done through what we call a VPN 472 policy or VPN service topology defining routing exchange rules 473 between sites. 475 The figure below describes the overall structure of the YANG module: 477 module: ietf-l3vpn-svc 478 +--rw l3vpn-svc 479 +--rw vpn-profiles 480 | +--rw valid-provider-identifiers 481 | +--rw cloud-identifier* [id] {cloud-access}? 482 | | +--rw id string 483 | +--rw encryption-profile-identifier* [id] 484 | | +--rw id string 485 | +--rw qos-profile-identifier* [id] 486 | | +--rw id string 487 | +--rw bfd-profile-identifier* [id] 488 | +--rw id string 489 +--rw vpn-services 490 | +--rw vpn-service* [vpn-id] 491 | +--rw vpn-id svc-id 492 | +--rw customer-name? string 493 | +--rw vpn-service-topology? identityref 494 | +--rw cloud-accesses {cloud-access}? 495 | | +--rw cloud-access* [cloud-identifier] 496 | | +--rw cloud-identifier -> /l3vpn-svc/vpn-profiles/valid-provider-identifiers/cloud-identifier/id 497 | | +--rw (list-flavor)? 498 | | | +--:(permit-any) 499 | | | | +--rw permit-any? empty 500 | | | +--:(deny-any-except) 501 | | | | +--rw permit-site* -> /l3vpn-svc/sites/site/site-id 502 | | | +--:(permit-any-except) 503 | | | +--rw deny-site* -> /l3vpn-svc/sites/site/site-id 504 | | +--rw address-translation 505 | | +--rw nat44 506 | | +--rw enabled? boolean 507 | | +--rw nat44-customer-address? inet:ipv4-address 508 | +--rw multicast {multicast}? 509 | | +--rw enabled? boolean 510 | | +--rw customer-tree-flavors 511 | | | +--rw tree-flavor* identityref 512 | | +--rw rp 513 | | +--rw rp-group-mappings 514 | | | +--rw rp-group-mapping* [id] 515 | | | +--rw id uint16 516 | | | +--rw provider-managed 517 | | | | +--rw enabled? boolean 518 | | | | +--rw rp-redundancy? boolean 519 | | | | +--rw optimal-traffic-delivery? boolean 520 | | | +--rw rp-address inet:ip-address 521 | | | +--rw groups 522 | | | +--rw group* [id] 523 | | | +--rw id uint16 524 | | | +--rw (group-format) 525 | | | +--:(singleaddress) 526 | | | | +--rw group-address? inet:ip-address 527 | | | +--:(startend) 528 | | | +--rw group-start? inet:ip-address 529 | | | +--rw group-end? inet:ip-address 530 | | +--rw rp-discovery 531 | | +--rw rp-discovery-type? identityref 532 | | +--rw bsr-candidates 533 | | +--rw bsr-candidate-address* inet:ip-address 534 | +--rw carrierscarrier? boolean {carrierscarrier}? 535 | +--rw extranet-vpns {extranet-vpn}? 536 | +--rw extranet-vpn* [vpn-id] 537 | +--rw vpn-id svc-id 538 | +--rw local-sites-role? identityref 539 +--rw sites 540 +--rw site* [site-id] 541 +--rw site-id svc-id 542 +--rw requested-site-start? yang:date-and-time 543 +--rw requested-site-stop? yang:date-and-time 544 +--rw locations 545 | +--rw location* [location-id] 546 | +--rw location-id svc-id 547 | +--rw address? string 548 | +--rw postal-code? string 549 | +--rw state? string 550 | +--rw city? string 551 | +--rw country-code? string 552 +--rw devices 553 | +--rw device* [device-id] 554 | +--rw device-id svc-id 555 | +--rw location -> ../../../locations/location/location-id 556 | +--rw management 557 | +--rw address-family? address-family 558 | +--rw address? inet:ip-address 559 +--rw site-diversity {site-diversity}? 560 | +--rw groups 561 | +--rw group* [group-id] 562 | +--rw group-id string 563 +--rw management 564 | +--rw type identityref 565 +--rw vpn-policies 566 | +--rw vpn-policy* [vpn-policy-id] 567 | +--rw vpn-policy-id svc-id 568 | +--rw entries* [id] 569 | +--rw id svc-id 570 | +--rw filters 571 | | +--rw filter* [type] 572 | | +--rw type identityref 573 | | +--rw lan-tag* string {lan-tag}? 574 | | +--rw ipv4-lan-prefix* inet:ipv4-prefix {ipv4}? 575 | | +--rw ipv6-lan-prefix* inet:ipv6-prefix {ipv6}? 576 | +--rw vpn* [vpn-id] 577 | +--rw vpn-id -> /l3vpn-svc/vpn-services/vpn-service/vpn-id 578 | +--rw site-role? identityref 579 +--rw site-vpn-flavor? identityref 580 +--rw maximum-routes 581 | +--rw address-family* [af] 582 | +--rw af address-family 583 | +--rw maximum-routes? uint32 584 +--rw security 585 | +--rw authentication 586 | +--rw encryption {encryption}? 587 | +--rw enabled? boolean 588 | +--rw layer? enumeration 589 | +--rw encryption-profile 590 | +--rw (profile)? 591 | +--:(provider-profile) 592 | | +--rw profile-name? -> /l3vpn-svc/vpn-profiles/valid-provider-identifiers/encryption-profile-identifier/id 593 | +--:(customer-profile) 594 | +--rw algorithm? string 595 | +--rw (key-type)? 596 | +--:(psk) 597 | +--rw preshared-key? string 598 +--rw service 599 | +--rw qos {qos}? 600 | | +--rw qos-classification-policy 601 | | | +--rw rule* [id] 602 | | | +--rw id string 603 | | | +--rw (match-type)? 604 | | | | +--:(match-flow) 605 | | | | | +--rw match-flow 606 | | | | | +--rw dscp? inet:dscp 607 | | | | | +--rw dot1p? uint8 608 | | | | | +--rw ipv4-src-prefix? inet:ipv4-prefix 609 | | | | | +--rw ipv6-src-prefix? inet:ipv6-prefix 610 | | | | | +--rw ipv4-dst-prefix? inet:ipv4-prefix 611 | | | | | +--rw ipv6-dst-prefix? inet:ipv6-prefix 612 | | | | | +--rw l4-src-port? inet:port-number 613 | | | | | +--rw target-sites* svc-id {target-sites}? 614 | | | | | +--rw l4-src-port-range 615 | | | | | | +--rw lower-port? inet:port-number 616 | | | | | | +--rw upper-port? inet:port-number 617 | | | | | +--rw l4-dst-port? inet:port-number 618 | | | | | +--rw l4-dst-port-range 619 | | | | | | +--rw lower-port? inet:port-number 620 | | | | | | +--rw upper-port? inet:port-number 621 | | | | | +--rw protocol-field? union 622 | | | | +--:(match-application) 623 | | | | +--rw match-application? identityref 624 | | | +--rw target-class-id? string 625 | | +--rw qos-profile 626 | | +--rw (qos-profile)? 627 | | +--:(standard) 628 | | | +--rw profile? -> /l3vpn-svc/vpn-profiles/valid-provider-identifiers/qos-profile-identifier/id 629 | | +--:(custom) 630 | | +--rw classes {qos-custom}? 631 | | +--rw class* [class-id] 632 | | +--rw class-id string 633 | | +--rw direction? identityref 634 | | +--rw rate-limit? uint8 635 | | +--rw latency 636 | | | +--rw (flavor)? 637 | | | +--:(lowest) 638 | | | | +--rw use-lowest-latency? empty 639 | | | +--:(boundary) 640 | | | +--rw latency-boundary? uint16 641 | | +--rw jitter 642 | | | +--rw (flavor)? 643 | | | +--:(lowest) 644 | | | | +--rw use-lowest-jitter? empty 645 | | | +--:(boundary) 646 | | | +--rw latency-boundary? uint32 647 | | +--rw bandwidth 648 | | +--rw guaranteed-bw-percent uint8 649 | | +--rw end-to-end? empty 650 | +--rw carrierscarrier {carrierscarrier}? 651 | | +--rw signalling-type? enumeration 652 | +--rw multicast {multicast}? 653 | +--rw multicast-site-type? enumeration 654 | +--rw multicast-address-family 655 | | +--rw ipv4? boolean {ipv4}? 656 | | +--rw ipv6? boolean {ipv6}? 657 | +--rw protocol-type? enumeration 658 +--rw traffic-protection {fast-reroute}? 659 | +--rw enabled? boolean 660 +--rw routing-protocols 661 | +--rw routing-protocol* [type] 662 | +--rw type identityref 663 | +--rw ospf {rtg-ospf}? 664 | | +--rw address-family* address-family 665 | | +--rw area-address yang:dotted-quad 666 | | +--rw metric? uint16 667 | | +--rw sham-links {rtg-ospf-sham-link}? 668 | | +--rw sham-link* [target-site] 669 | | +--rw target-site svc-id 670 | | +--rw metric? uint16 671 | +--rw bgp {rtg-bgp}? 672 | | +--rw autonomous-system uint32 673 | | +--rw address-family* address-family 674 | +--rw static 675 | | +--rw cascaded-lan-prefixes 676 | | +--rw ipv4-lan-prefixes* [lan next-hop] {ipv4}? 677 | | | +--rw lan inet:ipv4-prefix 678 | | | +--rw lan-tag? string 679 | | | +--rw next-hop inet:ipv4-address 680 | | +--rw ipv6-lan-prefixes* [lan next-hop] {ipv6}? 681 | | +--rw lan inet:ipv6-prefix 682 | | +--rw lan-tag? string 683 | | +--rw next-hop inet:ipv6-address 684 | +--rw rip {rtg-rip}? 685 | | +--rw address-family* address-family 686 | +--rw vrrp {rtg-vrrp}? 687 | +--rw address-family* address-family 688 +--ro actual-site-start? yang:date-and-time 689 +--ro actual-site-stop? yang:date-and-time 690 +--rw site-network-accesses 691 +--rw site-network-access* [site-network-access-id] 692 +--rw site-network-access-id svc-id 693 +--rw site-network-access-type? identityref 694 +--rw (location-flavor) 695 | +--:(location) 696 | | +--rw location-reference? -> ../../../locations/location/location-id 697 | +--:(device) 698 | +--rw device-reference? -> ../../../devices/device/device-id 699 +--rw access-diversity {site-diversity}? 700 | +--rw groups 701 | | +--rw group* [group-id] 702 | | +--rw group-id string 703 | +--rw constraints 704 | +--rw constraint* [constraint-type] 705 | +--rw constraint-type identityref 706 | +--rw target 707 | +--rw (target-flavor)? 708 | +--:(id) 709 | | +--rw group* [group-id] 710 | | +--rw group-id string 711 | +--:(all-accesses) 712 | | +--rw all-other-accesses? empty 713 | +--:(all-groups) 714 | +--rw all-other-groups? empty 715 +--rw bearer 716 | +--rw requested-type {requested-type}? 717 | | +--rw requested-type? string 718 | | +--rw strict? boolean 719 | +--rw always-on? boolean {always-on}? 720 | +--rw bearer-reference? string {bearer-reference}? 721 +--rw ip-connection 722 | +--rw ipv4 {ipv4}? 723 | | +--rw address-allocation-type? identityref 724 | | +--rw provider-dhcp 725 | | | +--rw provider-address? inet:ipv4-address 726 | | | +--rw mask? uint8 727 | | | +--rw (address-assign)? 728 | | | +--:(number) 729 | | | | +--rw number-of-dynamic-address? uint16 730 | | | +--:(explicit) 731 | | | +--rw customer-addresses 732 | | | +--rw address-group* [group-id] 733 | | | +--rw group-id string 734 | | | +--rw start-address? inet:ipv4-address 735 | | | +--rw end-address? inet:ipv4-address 736 | | +--rw dhcp-relay 737 | | | +--rw provider-address? inet:ipv4-address 738 | | | +--rw mask? uint8 739 | | | +--rw customer-dhcp-servers 740 | | | +--rw server-ip-address* inet:ipv4-address 741 | | +--rw addresses 742 | | +--rw provider-address? inet:ipv4-address 743 | | +--rw customer-address? inet:ipv4-address 744 | | +--rw mask? uint8 745 | +--rw ipv6 {ipv6}? 746 | | +--rw address-allocation-type? identityref 747 | | +--rw provider-dhcp 748 | | | +--rw provider-address? inet:ipv6-address 749 | | | +--rw mask? uint8 750 | | | +--rw (address-assign)? 751 | | | +--:(number) 752 | | | | +--rw number-of-dynamic-address? uint16 753 | | | +--:(explicit) 754 | | | +--rw customer-addresses 755 | | | +--rw address-group* [group-id] 756 | | | +--rw group-id string 757 | | | +--rw start-address? inet:ipv6-address 758 | | | +--rw end-address? inet:ipv6-address 759 | | +--rw dhcp-relay 760 | | | +--rw provider-address? inet:ipv6-address 761 | | | +--rw mask? uint8 762 | | | +--rw customer-dhcp-servers 763 | | | +--rw server-ip-address* inet:ipv6-address 764 | | +--rw addresses 765 | | +--rw provider-address? inet:ipv6-address 766 | | +--rw customer-address? inet:ipv6-address 767 | | +--rw mask? uint8 768 | +--rw oam 769 | +--rw bfd {bfd}? 770 | +--rw enabled? boolean 771 | +--rw (holdtime)? 772 | +--:(fixed) 773 | | +--rw fixed-value? uint32 774 | +--:(profile) 775 | +--rw profile-name? -> /l3vpn-svc/vpn-profiles/valid-provider-identifiers/bfd-profile-identifier/id 776 +--rw security 777 | +--rw authentication 778 | +--rw encryption {encryption}? 779 | +--rw enabled? boolean 780 | +--rw layer? enumeration 781 | +--rw encryption-profile 782 | +--rw (profile)? 783 | +--:(provider-profile) 784 | | +--rw profile-name? -> /l3vpn-svc/vpn-profiles/valid-provider-identifiers/encryption-profile-identifier/id 785 | +--:(customer-profile) 786 | +--rw algorithm? string 787 | +--rw (key-type)? 788 | +--:(psk) 789 | +--rw preshared-key? string 790 +--rw service 791 | +--rw svc-input-bandwidth uint64 792 | +--rw svc-output-bandwidth uint64 793 | +--rw svc-mtu uint16 794 | +--rw qos {qos}? 795 | | +--rw qos-classification-policy 796 | | | +--rw rule* [id] 797 | | | +--rw id string 798 | | | +--rw (match-type)? 799 | | | | +--:(match-flow) 800 | | | | | +--rw match-flow 801 | | | | | +--rw dscp? inet:dscp 802 | | | | | +--rw dot1p? uint8 803 | | | | | +--rw ipv4-src-prefix? inet:ipv4-prefix 804 | | | | | +--rw ipv6-src-prefix? inet:ipv6-prefix 805 | | | | | +--rw ipv4-dst-prefix? inet:ipv4-prefix 806 | | | | | +--rw ipv6-dst-prefix? inet:ipv6-prefix 807 | | | | | +--rw l4-src-port? inet:port-number 808 | | | | | +--rw target-sites* svc-id {target-sites}? 809 | | | | | +--rw l4-src-port-range 810 | | | | | | +--rw lower-port? inet:port-number 811 | | | | | | +--rw upper-port? inet:port-number 812 | | | | | +--rw l4-dst-port? inet:port-number 813 | | | | | +--rw l4-dst-port-range 814 | | | | | | +--rw lower-port? inet:port-number 815 | | | | | | +--rw upper-port? inet:port-number 816 | | | | | +--rw protocol-field? union 817 | | | | +--:(match-application) 818 | | | | +--rw match-application? identityref 819 | | | +--rw target-class-id? string 820 | | +--rw qos-profile 821 | | +--rw (qos-profile)? 822 | | +--:(standard) 823 | | | +--rw profile? -> /l3vpn-svc/vpn-profiles/valid-provider-identifiers/qos-profile-identifier/id 824 | | +--:(custom) 825 | | +--rw classes {qos-custom}? 826 | | +--rw class* [class-id] 827 | | +--rw class-id string 828 | | +--rw direction? identityref 829 | | +--rw rate-limit? uint8 830 | | +--rw latency 831 | | | +--rw (flavor)? 832 | | | +--:(lowest) 833 | | | | +--rw use-lowest-latency? empty 834 | | | +--:(boundary) 835 | | | +--rw latency-boundary? uint16 836 | | +--rw jitter 837 | | | +--rw (flavor)? 838 | | | +--:(lowest) 839 | | | | +--rw use-lowest-jitter? empty 840 | | | +--:(boundary) 841 | | | +--rw latency-boundary? uint32 842 | | +--rw bandwidth 843 | | +--rw guaranteed-bw-percent uint8 844 | | +--rw end-to-end? empty 845 | +--rw carrierscarrier {carrierscarrier}? 846 | | +--rw signalling-type? enumeration 847 | +--rw multicast {multicast}? 848 | +--rw multicast-site-type? enumeration 849 | +--rw multicast-address-family 850 | | +--rw ipv4? boolean {ipv4}? 851 | | +--rw ipv6? boolean {ipv6}? 852 | +--rw protocol-type? enumeration 853 +--rw routing-protocols 854 | +--rw routing-protocol* [type] 855 | +--rw type identityref 856 | +--rw ospf {rtg-ospf}? 857 | | +--rw address-family* address-family 858 | | +--rw area-address yang:dotted-quad 859 | | +--rw metric? uint16 860 | | +--rw sham-links {rtg-ospf-sham-link}? 861 | | +--rw sham-link* [target-site] 862 | | +--rw target-site svc-id 863 | | +--rw metric? uint16 864 | +--rw bgp {rtg-bgp}? 865 | | +--rw autonomous-system uint32 866 | | +--rw address-family* address-family 867 | +--rw static 868 | | +--rw cascaded-lan-prefixes 869 | | +--rw ipv4-lan-prefixes* [lan next-hop] {ipv4}? 870 | | | +--rw lan inet:ipv4-prefix 871 | | | +--rw lan-tag? string 872 | | | +--rw next-hop inet:ipv4-address 873 | | +--rw ipv6-lan-prefixes* [lan next-hop] {ipv6}? 874 | | +--rw lan inet:ipv6-prefix 875 | | +--rw lan-tag? string 876 | | +--rw next-hop inet:ipv6-address 877 | +--rw rip {rtg-rip}? 878 | | +--rw address-family* address-family 879 | +--rw vrrp {rtg-vrrp}? 880 | +--rw address-family* address-family 881 +--rw availability 882 | +--rw access-priority? uint32 883 +--rw vpn-attachment 884 +--rw (attachment-flavor) 885 +--:(vpn-policy-id) 886 | +--rw vpn-policy-id? -> ../../../../vpn-policies/vpn-policy/vpn-policy-id 887 +--:(vpn-id) 888 +--rw vpn-id? -> /l3vpn-svc/vpn-services/vpn-service/vpn-id 889 +--rw site-role? identityref 891 6.1. Features and Augmentation 893 The model defined in this document implements many features that 894 allow implementations to be modular. As an example, an 895 implementation may support only IPv4 VPNs (IPv4 feature), IPv6 VPNs 896 (IPv6 feature), or both (by advertising both features). The routing 897 protocols proposed to the customer may also be enabled through 898 features. This model also defines some features for options that are 899 more advanced, such as support for extranet VPNs (Section 6.2.4), 900 site diversity (Section 6.6), and QoS (Section 6.12.3). 902 In addition, as for any YANG model, this service model can be 903 augmented to implement new behaviors or specific features. For 904 example, this model uses different options for IP address 905 assignments; if those options do not fulfill all requirements, new 906 options can be added through augmentation. 908 6.2. VPN Service Overview 910 A vpn-service list item contains generic information about the VPN 911 service. The "vpn-id" provided in the vpn-service list refers to an 912 internal reference for this VPN service, while the customer name 913 refers to a more-explicit reference to the customer. This identifier 914 is purely internal to the organization responsible for the VPN 915 service. 917 6.2.1. VPN Service Topology 919 The type of VPN service topology is required for configuration. Our 920 proposed model supports any-to-any, Hub and Spoke (where Hubs can 921 exchange traffic), and "Hub and Spoke disjoint" (where Hubs cannot 922 exchange traffic). New topologies could be added via augmentation. 923 By default, the any-to-any VPN service topology is used. 925 6.2.1.1. Route Target Allocation 927 A Layer 3 PE-based VPN is built using route targets (RTs) as 928 described in [RFC4364]. The management system is expected to 929 automatically allocate a set of RTs upon receiving a VPN service 930 creation request. How the management system allocates RTs is out of 931 scope for this document, but multiple ways could be envisaged, as 932 described below. 934 Management system 935 <-------------------------------------------------> 936 Request RT 937 +-----------------------+ Topo a2a +----------+ 938 RESTCONF | | -----> | | 939 User ------------- | Service Orchestration | | Network | 940 l3vpn-svc | | <----- | OSS | 941 Model +-----------------------+ Response +----------+ 942 RT1, RT2 944 In the example above, a service orchestration, owning the 945 instantiation of this service model, requests RTs to the network OSS. 946 Based on the requested VPN service topology, the network OSS replies 947 with one or multiple RTs. The interface between this service 948 orchestration and the network OSS is out of scope for this document. 950 +---------------------------+ 951 RESTCONF | | 952 User ------------- | Service Orchestration | 953 l3vpn-svc | | 954 Model | | 955 | RT pool: 10:1->10:10000 | 956 | RT pool: 20:50->20:5000 | 957 +---------------------------+ 959 In the example above, a service orchestration, owning the 960 instantiation of this service model, owns one or more pools of RTs 961 (specified by the SP) that can be allocated. Based on the requested 962 VPN service topology, it will allocate one or multiple RTs from the 963 pool. 965 The mechanisms shown above are just examples and should not be 966 considered an exhaustive list of solutions. 968 6.2.1.2. Any-to-Any 969 +------------------------------------------------------------+ 970 | VPN1_Site1 ------ PE1 PE2 ------ VPN1_Site2 | 971 | | 972 | VPN1_Site3 ------ PE3 PE4 ------ VPN1_Site4 | 973 +------------------------------------------------------------+ 975 Any-to-Any VPN Service Topology 977 In the any-to-any VPN service topology, all VPN sites can communicate 978 with each other without any restrictions. The management system that 979 receives an any-to-any IP VPN service request through this model is 980 expected to assign and then configure the VRF and RTs on the 981 appropriate PEs. In the any-to-any case, a single RT is generally 982 required, and every VRF imports and exports this RT. 984 6.2.1.3. Hub and Spoke 986 +-------------------------------------------------------------+ 987 | Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 | 988 | +----------------------------------+ 989 | | 990 | +----------------------------------+ 991 | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 | 992 +-------------------------------------------------------------+ 994 Hub-and-Spoke VPN Service Topology 996 In the Hub-and-Spoke VPN service topology, all Spoke sites can 997 communicate only with Hub sites but not with each other, and Hubs can 998 also communicate with each other. The management system that owns an 999 any-to-any IP VPN service request through this model is expected to 1000 assign and then configure the VRF and RTs on the appropriate PEs. In 1001 the Hub-and-Spoke case, two RTs are generally required (one RT for 1002 Hub routes and one RT for Spoke routes). A Hub VRF that connects Hub 1003 sites will export Hub routes with the Hub RT and will import Spoke 1004 routes through the Spoke RT. It will also import the Hub RT to allow 1005 Hub-to-Hub communication. A Spoke VRF that connects Spoke sites will 1006 export Spoke routes with the Spoke RT and will import Hub routes 1007 through the Hub RT. 1009 The management system MUST take into account constraints on Hub-and- 1010 Spoke connections. For example, if a management system decides to 1011 mesh a Spoke site and a Hub site on the same PE, it needs to mesh 1012 connections in different VRFs, as shown in the figure below. 1014 Hub_Site ------- (VRF_Hub) PE1 1015 (VRF_Spoke) 1016 / | 1017 Spoke_Site1 -------------------+ | 1018 | 1019 Spoke_Site2 -----------------------+ 1021 6.2.1.4. Hub and Spoke Disjoint 1023 +-------------------------------------------------------------+ 1024 | Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 | 1025 +--------------------------+ +-------------------------------+ 1026 | | 1027 +--------------------------+ +-------------------------------+ 1028 | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 | 1029 +-------------------------------------------------------------+ 1031 Hub and Spoke Disjoint VPN Service Topology 1033 In the Hub and Spoke disjoint VPN service topology, all Spoke sites 1034 can communicate only with Hub sites but not with each other, and Hubs 1035 cannot communicate with each other. The management system that owns 1036 an any-to-any IP VPN service request through this model is expected 1037 to assign and then configure the VRF and RTs on the appropriate PEs. 1038 In the Hub-and-Spoke case, two RTs are required (one RT for Hub 1039 routes and one RT for Spoke routes). A Hub VRF that connects Hub 1040 sites will export Hub routes with the Hub RT and will import Spoke 1041 routes through the Spoke RT. A Spoke VRF that connects Spoke sites 1042 will export Spoke routes with the Spoke RT and will import Hub routes 1043 through the Hub RT. 1045 The management system MUST take into account constraints on Hub-and- 1046 Spoke connections, as in the previous case. 1048 Hub and Spoke disjoint can also be seen as multiple Hub-and-Spoke 1049 VPNs (one per Hub) that share a common set of Spoke sites. 1051 6.2.2. Cloud Access 1053 The proposed model provides cloud access configuration via the 1054 "cloud-accesses" container. The usage of cloud-access is targeted 1055 for the public cloud. An Internet access can also be considered a 1056 public cloud access service. The cloud-accesses container provides 1057 parameters for network address translation and authorization rules. 1059 A private cloud access may be addressed through NNIs, as described in 1060 Section 6.15. 1062 A cloud identifier is used to reference the target service. This 1063 identifier is local to each administration. 1065 The model allows for source address translation before accessing the 1066 cloud. IPv4-to-IPv4 address translation (NAT44) is the only 1067 supported option, but other options can be added through 1068 augmentation. If IP source address translation is required to access 1069 the cloud, the "enabled" leaf MUST be set to true in the "nat44" 1070 container. An IP address may be provided in the "customer-address" 1071 leaf if the customer is providing the IP address to be used for the 1072 cloud access. If the SP is providing this address, "customer- 1073 address" is not necessary, as it can be picked from a pool of SPs. 1075 By default, all sites in the IP VPN MUST be authorized to access the 1076 cloud. If restrictions are required, a user MAY configure the 1077 "permit-site" or "deny-site" leaf-list. The permit-site leaf-list 1078 defines the list of sites authorized for cloud access. The deny-site 1079 leaf-list defines the list of sites denied for cloud access. The 1080 model supports both "deny-any-except" and "permit-any-except" 1081 authorization. 1083 How the restrictions will be configured on network elements is out of 1084 scope for this document. 1086 IP VPN 1087 ++++++++++++++++++++++++++++++++ ++++++++++++ 1088 + Site 3 + --- + Cloud 1 + 1089 + Site 1 + ++++++++++++ 1090 + + 1091 + Site 2 + --- ++++++++++++ 1092 + + + Internet + 1093 + Site 4 + ++++++++++++ 1094 ++++++++++++++++++++++++++++++++ 1095 | 1096 +++++++++++ 1097 + Cloud 2 + 1098 +++++++++++ 1100 In the example above, we configure the global VPN to access the 1101 Internet by creating a cloud-access pointing to the cloud identifier 1102 for the Internet service. No authorized sites will be configured, as 1103 all sites are required to access the Internet. The "address- 1104 translation/nat44/enabled" leaf will be set to true. 1106 1107 1108 1109 1110 123456487 1111 1112 1113 INTERNET 1114 1115 1116 true 1117 1118 1119 1120 1121 1122 1123 1125 If Site 1 and Site 2 require access to Cloud 1, a new cloud-access 1126 pointing to the cloud identifier of Cloud 1 will be created. The 1127 permit-site leaf-list will be filled with a reference to Site 1 and 1128 Site 2. 1130 1131 1132 1133 1134 123456487 1135 1136 1137 Cloud1 1138 site1 1139 site2 1140 1141 1142 1143 1144 1146 If all sites except Site 1 require access to Cloud 2, a new cloud- 1147 access pointing to the cloud identifier of Cloud 2 will be created. 1148 The deny-site leaf-list will be filled with a reference to Site 1. 1150 1151 1152 1153 1154 123456487 1155 1156 1157 Cloud2 1158 site1 1159 1160 1161 1162 1163 1165 A service with more than one cloud access is functionally identical 1166 to multiple services each with a single cloud access, where the sites 1167 that belong to each service in the latter case correspond with the 1168 authorized sites for each cloud access in the former case. However, 1169 defining a single service with multiple cloud accesses may be 1170 operationally simpler. 1172 6.2.3. Multicast Service 1174 Multicast in IP VPNs is described in [RFC6513]. 1176 If multicast support is required for an IP VPN, some global multicast 1177 parameters are required as input for the service request. 1179 Users of this model will need to provide the flavors of trees that 1180 will be used by customers within the IP VPN (customer tree). The 1181 proposed model supports bidirectional, shared, and source-based trees 1182 (and can be augmented). Multiple flavors of trees can be supported 1183 simultaneously. 1185 Operator network 1186 ______________ 1187 / \ 1188 | | 1189 (SSM tree) | 1190 Recv (IGMPv3) -- Site2 ------- PE2 | 1191 | PE1 --- Site1 --- Source1 1192 | | \ 1193 | | -- Source2 1194 | | 1195 (ASM tree) | 1196 Recv (IGMPv2) -- Site3 ------- PE3 | 1197 | | 1198 (SSM tree) | 1199 Recv (IGMPv3) -- Site4 ------- PE4 | 1200 | / | 1201 Recv (IGMPv2) -- Site5 -------- | 1202 (ASM tree) | 1203 | | 1204 \_______________/ 1206 When an ASM flavor is requested, this model requires that the "rp" 1207 and "rp-discovery" parameters be filled. Multiple RP-to-group 1208 mappings can be created using the "rp-group-mappings" container. For 1209 each mapping, the SP can manage the RP service by setting the 1210 "provider-managed/enabled" leaf to true. In the case of a provider- 1211 managed RP, the user can request RP redundancy and/or optimal traffic 1212 delivery. Those parameters will help the SP select the appropriate 1213 technology or architecture to fulfill the customer service 1214 requirement: for instance, in the case of a request for optimal 1215 traffic delivery, an SP may use Anycast-RP or RP-tree-to-SPT 1216 switchover architectures. 1218 In the case of a customer-managed RP, the RP address must be filled 1219 in the RP-to-group mappings using the "rp-address" leaf. This leaf 1220 is not needed for a provider-managed RP. 1222 Users can define a specific mechanism for RP discovery, such as the 1223 "auto-rp", "static-rp", or "bsr-rp" modes. By default, the model 1224 uses "static-rp" if ASM is requested. A single rp-discovery 1225 mechanism is allowed for the VPN. The "rp-discovery" container can 1226 be used for both provider-managed and customer-managed RPs. In the 1227 case of a provider-managed RP, if the user wants to use "bsr-rp" as a 1228 discovery protocol, an SP should consider the provider-managed "rp- 1229 group-mappings" for the "bsr-rp" configuration. The SP will then 1230 configure its selected RPs to be "bsr-rp-candidates". In the case of 1231 a customer-managed RP and a "bsr-rp" discovery mechanism, the "rp- 1232 address" provided will be the bsr-rp candidate. 1234 6.2.4. Extranet VPNs 1236 There are some cases where a particular VPN needs access to resources 1237 (servers, hosts, etc.) that are external. Those resources may be 1238 located in another VPN. 1240 +-----------+ +-----------+ 1241 / \ / \ 1242 Site A -- | VPN A | --- | VPN B | --- Site B 1243 \ / \ / (Shared 1244 +-----------+ +-----------+ resources) 1246 In the figure above, VPN B has some resources on Site B that need to 1247 be available to some customers/partners. VPN A must be able to 1248 access those VPN B resources. 1250 Such a VPN connection scenario can be achieved via a VPN policy as 1251 defined in Section 6.5.2.2. But there are some simple cases where a 1252 particular VPN (VPN A) needs access to all resources in another VPN 1253 (VPN B). The model provides an easy way to set up this connection 1254 using the "extranet-vpns" container. 1256 The extranet-vpns container defines a list of VPNs a particular VPN 1257 wants to access. The extranet-vpns container must be used on 1258 customer VPNs accessing extranet resources in another VPN. In the 1259 figure above, in order to provide VPN A with access to VPN B, the 1260 extranet-vpns container needs to be configured under VPN A with an 1261 entry corresponding to VPN B. There is no service configuration 1262 requirement on VPN B. 1264 Readers should note that even if there is no configuration 1265 requirement on VPN B, if VPN A lists VPN B as an extranet, all sites 1266 in VPN B will gain access to all sites in VPN A. 1268 The "site-role" leaf defines the role of the local VPN sites in the 1269 target extranet VPN service topology. Site roles are defined in 1270 Section 6.4. Based on this, the requirements described in 1271 Section 6.4 regarding the site-role leaf are also applicable here. 1273 In the example below, VPN A accesses VPN B resources through an 1274 extranet connection. A Spoke role is required for VPN A sites, as 1275 sites from VPN A must not be able to communicate with each other 1276 through the extranet VPN connection. 1278 1279 1280 1281 1282 VPNB 1283 hub-spoke 1284 1285 1286 VPNA 1287 any-to-any 1288 1289 1290 VPNB 1291 spoke-role 1292 1293 1294 1295 1296 1298 This model does not define how the extranet configuration will be 1299 achieved. 1301 Any VPN interconnection scenario that is more complex (e.g., only 1302 certain parts of sites on VPN A accessing only certain parts of sites 1303 on VPN B) needs to be achieved using a VPN attachment as defined in 1304 Section 6.5.2, and especially a VPN policy as defined in 1305 Section 6.5.2.2. 1307 6.3. Site Overview 1309 A site represents a connection of a customer office to one or more 1310 VPN services. Each site is associated with one or more location. 1312 +-------------+ 1313 / \ 1314 +------------------+ +-----| VPN1 | 1315 | | | \ / 1316 | New York Office |------ (site) -----+ +-------------+ 1317 | | | +-------------+ 1318 +------------------+ | / \ 1319 +-----| VPN2 | 1320 \ / 1321 +-------------+ 1323 A site has several characteristics: 1325 o Unique identifier (site-id): uniquely identifies the site within 1326 the overall network infrastructure. The identifier is a string 1327 that allows any encoding for the local administration of the VPN 1328 service. 1330 o Locations (locations): site location information that allows easy 1331 retrieval of information from the nearest available resources. A 1332 site may be composed of multiple locations. Alternatively,two or 1333 more sites can be associated with the same location, by 1334 referencing the same location ID. 1336 o Devices (devices): allows the customer to request one or more 1337 customer premises equipment entities from the SP for a particular 1338 site. 1340 o Management (management): defines the type of management for the 1341 site -- for example, co-managed, customer-managed, or provider- 1342 managed. See Section 6.10. 1344 o Site network accesses (site-network-accesses): defines the list of 1345 network accesses associated with the sites, and their properties 1346 -- especially bearer, connection, and service parameters. 1348 A site-network-access represents an IP logical connection of a site. 1349 A site may have multiple site-network-accesses. 1351 +------------------+ Site 1352 | |----------------------------------- 1353 | |****** (site-network-access#1) ****** 1354 | New York Office | 1355 | |****** (site-network-access#2) ****** 1356 | |----------------------------------- 1357 +------------------+ 1359 Multiple site-network-accesses are used, for instance, in the case of 1360 multihoming. Some other meshing cases may also include multiple 1361 site-network-accesses. 1363 The site configuration is viewed as a global entity; we assume that 1364 it is mostly the management system's role to split the parameters 1365 between the different elements within the network. For example, in 1366 the case of the site-network-access configuration, the management 1367 system needs to split the overall parameters between the PE 1368 configuration and the CE configuration. 1370 6.3.1. Devices and Locations 1372 A site may be composed of multiple locations. All the locations will 1373 need to be configured as part of the "locations" container and list. 1374 A typical example of a multi-location site is a headquarters office 1375 in a city composed of multiple buildings. Those buildings may be 1376 located in different parts of the city and may be linked by intra- 1377 city fibers (customer metropolitan area network). In such a case, 1378 when connecting to a VPN service, the customer may ask for 1379 multihoming based on its distributed locations. 1381 New York Site 1383 +------------------+ Site 1384 | +--------------+ |----------------------------------- 1385 | | Manhattan | |****** (site-network-access#1) ****** 1386 | +--------------+ | 1387 | +--------------+ | 1388 | | Brooklyn | |****** (site-network-access#2) ****** 1389 | +--------------+ | 1390 | |----------------------------------- 1391 +------------------+ 1393 A customer may also request some premises equipment entities (CEs) 1394 from the SP via the "devices" container. Requesting a CE implies a 1395 provider-managed or co-managed model. A particular device must be 1396 ordered to a particular already-configured location. This would help 1397 the SP send the device to the appropriate postal address. In a 1398 multi-location site, a customer may, for example, request a CE for 1399 each location on the site where multihoming must be implemented. In 1400 the figure above, one device may be requested for the Manhattan 1401 location and one other for the Brooklyn location. 1403 By using devices and locations, the user can influence the 1404 multihoming scenario he wants to implement: single CE, dual CE, etc. 1406 6.3.2. Site Network Accesses 1408 As mentioned earlier, a site may be multihomed. Each IP network 1409 access for a site is defined in the "site-network-accesses" 1410 container. The site-network-access parameter defines how the site is 1411 connected on the network and is split into three main classes of 1412 parameters: 1414 o bearer: defines requirements of the attachment (below Layer 3). 1416 o connection: defines Layer 3 protocol parameters of the attachment. 1418 o availability: defines the site's availability policy. The 1419 availability parameters are defined in Section 6.7. 1421 The site-network-access has a specific type (site-network-access- 1422 type). This document defines two types: 1424 o point-to-point: describes a point-to-point connection between the 1425 SP and the customer. 1427 o multipoint: describes a multipoint connection between the SP and 1428 the customer. 1430 The type of site-network-access may have an impact on the parameters 1431 offered to the customer, e.g., an SP may not offer encryption for 1432 multipoint accesses. It is up to the provider to decide what 1433 parameter is supported for point-to-point and/or multipoint accesses; 1434 this topic is out of scope for this document. Some containers 1435 proposed in the model may require extensions in order to work 1436 properly for multipoint accesses. 1438 6.3.2.1. Bearer 1440 The bearer container defines the requirements for the site attachment 1441 to the provider network that are below Layer 3. 1443 The bearer parameters will help determine the access media to be 1444 used. This is further described in Section 6.6.3. 1446 6.3.2.2. Connection 1448 The "ip-connection" container defines the protocol parameters of the 1449 attachment (IPv4 and IPv6). Depending on the management mode, it 1450 refers to PE-CE addressing or CE-to-customer-LAN addressing. In any 1451 case, it describes the responsibility boundary between the provider 1452 and the customer. For a customer-managed site, it refers to the PE- 1453 CE connection. For a provider-managed site, it refers to the CE-to- 1454 LAN connection. 1456 6.3.2.2.1. IP Addressing 1458 An IP subnet can be configured for either IPv4 or IPv6 Layer 3 1459 protocols. For a dual-stack connection, two subnets will be 1460 provided, one for each address family. 1462 The "address-allocation-type" determines how the address allocation 1463 needs to be done. The current model defines five ways to perform IP 1464 address allocation: 1466 o provider-dhcp: The provider will provide DHCP service for customer 1467 equipment; this is applicable to either the "IPv4" container or 1468 the "IPv6" container. 1470 o provider-dhcp-relay: The provider will provide DHCP relay service 1471 for customer equipment; this is applicable to both IPv4 and IPv6 1472 addressing. The customer needs to populate the DHCP server list 1473 to be used. 1475 o static-address: Addresses will be assigned manually; this is 1476 applicable to both IPv4 and IPv6 addressing. 1478 o slaac: This parameter enables stateless address autoconfiguration 1479 [RFC4862]. This is applicable to IPv6 only. 1481 o provider-dhcp-slaac: The provider will provide DHCP service for 1482 customer equipment, as well as stateless address 1483 autoconfiguration. This is applicable to IPv6 only. 1485 In the dynamic addressing mechanism, the SP is expected to provide at 1486 least the IP address, mask, and default gateway information.In the 1487 case of multiple site-network-access points belonging to the same 1488 VPN, address space allocated for one site-network-access should not 1489 conflict with one allocated for other site-network-accesses. 1491 6.3.2.2.2. OAM 1493 A customer may require a specific IP connectivity fault detection 1494 mechanism on the IP connection. The model supports BFD as a fault 1495 detection mechanism. This can be extended with other mechanisms via 1496 augmentation. The provider can propose some profiles to the 1497 customer, depending on the service level the customer wants to 1498 achieve. Profile names must be communicated to the customer. This 1499 communication is out of scope for this document. Some fixed values 1500 for the holdtime period may also be imposed by the customer if the 1501 provider allows the customer this function. 1503 The "oam" container can easily be augmented by other mechanisms; in 1504 particular, work done by the LIME Working Group 1505 (https://datatracker.ietf.org/wg/lime/charter/) may be reused in 1506 applicable scenarios. 1508 6.3.2.3. Inheritance of Parameters Defined at Site Level and Site 1509 Network Access Level 1511 Some parameters can be configured at both the site level and the 1512 site-network-access level, e.g., routing, services, security. 1513 Inheritance applies when parameters are defined at the site level. 1515 If a parameter is configured at both the site level and the access 1516 level, the access-level parameter MUST override the site-level 1517 parameter. Those parameters will be described later in this 1518 document. 1520 In terms of provisioning impact, it will be up to the implementation 1521 to decide on the appropriate behavior when modifying existing 1522 configurations. But the SP will need to communicate to the user 1523 about the impact of using inheritance. For example, if we consider 1524 that a site has already provisioned three site-network-accesses, what 1525 will happen if a customer changes a service parameter at the site 1526 level? An implementation of this model may update the service 1527 parameters of all already-provisioned site-network-accesses (with 1528 potential impact on live traffic), or it may take into account this 1529 new parameter only for the new sites. 1531 6.4. Site Role 1533 A VPN has a particular service topology, as described in 1534 Section 6.2.1. As a consequence, each site belonging to a VPN is 1535 assigned with a particular role in this topology. The site-role leaf 1536 defines the role of the site in a particular VPN topology. 1538 In the any-to-any VPN service topology, all sites MUST have the same 1539 role, which will be "any-to-any-role". 1541 In the Hub-and-Spoke VPN service topology or the Hub and Spoke 1542 disjoint VPN service topology, sites MUST have a Hub role or a Spoke 1543 role. 1545 6.5. Site Belonging to Multiple VPNs 1547 6.5.1. Site VPN Flavor 1549 A site may be part of one or multiple VPNs. The "site-vpn-flavor" 1550 defines the way the VPN multiplexing is done. The current version of 1551 the model supports four flavors: 1553 o site-vpn-flavor-single: The site belongs to only one VPN. 1555 o site-vpn-flavor-multi: The site belongs to multiple VPNs, and all 1556 the logical accesses of the sites belong to the same set of VPNs. 1558 o site-vpn-flavor-sub: The site belongs to multiple VPNs with 1559 multiple logical accesses. Each logical access may map to 1560 different VPNs (one or many). 1562 o site-vpn-flavor-nni: The site represents an option A NNI. 1564 6.5.1.1. Single VPN Attachment: site-vpn-flavor-single 1566 The figure below describes a single VPN attachment. The site 1567 connects to only one VPN. 1569 +--------+ 1570 +------------------+ Site / \ 1571 | |-----------------------------| | 1572 | |***(site-network-access#1)***| VPN1 | 1573 | New York Office | | | 1574 | |***(site-network-access#2)***| | 1575 | |-----------------------------| | 1576 +------------------+ \ / 1577 +--------+ 1579 6.5.1.2. MultiVPN Attachment: site-vpn-flavor-multi 1581 The figure below describes a site connected to multiple VPNs. 1583 +---------+ 1584 +---/----+ \ 1585 +------------------+ Site / | \ | 1586 | |--------------------------------- | |VPN B| 1587 | |***(site-network-access#1)******* | | | 1588 | New York Office | | | | | 1589 | |***(site-network-access#2)******* \ | / 1590 | |-----------------------------| VPN A+-----|---+ 1591 +------------------+ \ / 1592 +--------+ 1594 In the example above, the New York office is multihomed. Both 1595 logical accesses are using the same VPN attachment rules, and both 1596 are connected to VPN A and VPN B. 1598 Reaching VPN A or VPN B from the New York office will be done via 1599 destination-based routing. Having the same destination reachable 1600 from the two VPNs may cause routing troubles. The customer 1601 administration's role in this case would be to ensure the appropriate 1602 mapping of its prefixes in each VPN. 1604 6.5.1.3. SubVPN Attachment: site-vpn-flavor-sub 1606 The figure below describes a subVPN attachment. The site connects to 1607 multiple VPNs, but each logical access is attached to a particular 1608 set of VPNs. A typical use case for a subVPN is a customer site used 1609 by multiple affiliates with private resources for each affiliate that 1610 cannot be shared (communication between the affiliates is prevented). 1611 It is similar to have separate sites, but in the case of a SubVPN, 1612 the customer can share some physical components at a single location, 1613 while maintaining strong communication isolation between the 1614 affiliates. In this example, site-network-access#1 is attached to 1615 VPN B, while site-network-access#2 is attached to VPN A. 1617 +------------------+ Site +--------+ 1618 | |----------------------------------/ \ 1619 | |****(site-network-access#1)******| VPN B | 1620 | New York Office | \ / 1621 | | +--------+ 1622 | | +--------+ 1623 | | / \ 1624 | |****(site-network-access#2)******| VPN A | 1625 | | \ / 1626 | | +--------+ 1627 | |----------------------------------- 1628 +------------------+ 1630 A multiVPN can be implemented in addition to a subVPN; as a 1631 consequence, each site-network-access can access multiple VPNs. In 1632 the example below, site-network-access#1 is mapped to VPN B and VPN 1633 C, while site-network-access#2 is mapped to VPN A and VPN D. 1635 +-----------------+ Site +------+ 1636 | |--------------------------------/ +-----+ 1637 | |****(site-network-access#1)****| VPN B / \ 1638 | New York Office | \ | VPN C | 1639 | | +-----\ / 1640 | | +-----+ 1641 | | 1642 | | +-------+ 1643 | | / +-----+ 1644 | |****(site-network-access#2)****| VPN A / \ 1645 | | \ | VPN D | 1646 | | +------\ / 1647 | |--------------------------------- +-----+ 1648 +-----------------+ 1650 Multihoming is also possible with subVPNs; in this case, site- 1651 network-accesses are grouped, and a particular group will have access 1652 to the same set of VPNs. In the example below, site-network-access#1 1653 and site-network-access#2 are part of the same group (multihomed 1654 together) and are mapped to VPN B and VPN C; in addition, site- 1655 network-access#3 and site-network-access#4 are part of the same group 1656 (multihomed together) and are mapped to VPN A and VPN D. 1658 +-----------------+ Site +------+ 1659 | |---------------------------------/ +-----+ 1660 | |****(site-network-access#1)*****| VPN B / \ 1661 | New York Office |****(site-network-access#2)***** \ | VPN C | 1662 | | +-----\ / 1663 | | +-----+ 1664 | | 1665 | | +------+ 1666 | | / +-----+ 1667 | |****(site-network-access#3)*****| VPN A / \ 1668 | |****(site-network-access#4)***** \ | VPN D | 1669 | | +-----\ / 1670 | |---------------------------------- +-----+ 1671 +-----------------+ 1673 In terms of service configuration, a subVPN can be achieved by 1674 requesting that the site-network-access use the same bearer (see 1675 Section 6.6.4 for more details). 1677 6.5.1.4. NNI: site-vpn-flavor-nni 1679 A Network-to-Network Interface (NNI) scenario may be modeled using 1680 the sites container (see Section 6.15.1). Using the sites container 1681 to model an NNI is only one possible option for NNIs (see 1682 Section 6.15). This option is called "option A" by reference to the 1683 option A NNI defined in [RFC4364]. It is helpful for the SP to 1684 indicate that the requested VPN connection is not a regular site but 1685 rather is an NNI, as specific default device configuration parameters 1686 may be applied in the case of NNIs (e.g., ACLs, routing policies). 1688 SP A SP B 1689 ------------------- ------------------- 1690 / \ / \ 1691 | | | | 1692 | ++++++++ Inter-AS link ++++++++ | 1693 | + +_______________+ + | 1694 | + (VRF1)---(VPN1)----(VRF1) + | 1695 | + ASBR + + ASBR + | 1696 | + (VRF2)---(VPN2)----(VRF2) + | 1697 | + +_______________+ + | 1698 | ++++++++ ++++++++ | 1699 | | | | 1700 | | | | 1701 | | | | 1702 | ++++++++ Inter-AS link ++++++++ | 1703 | + +_______________+ + | 1704 | + (VRF1)---(VPN1)----(VRF1) + | 1705 | + ASBR + + ASBR + | 1706 | + (VRF2)---(VPN2)----(VRF2) + | 1707 | + +_______________+ + | 1708 | ++++++++ ++++++++ | 1709 | | | | 1710 | | | | 1711 \ / \ / 1712 ------------------- ------------------- 1714 The figure above describes an option A NNI scenario that can be 1715 modeled using the sites container. In order to connect its customer 1716 VPNs (VPN1 and VPN2) in SP B, SP A may request the creation of some 1717 site-network-accesses to SP B. The site-vpn-flavor-nni will be used 1718 to inform SP B that this is an NNI and not a regular customer site. 1719 The site-vpn-flavor-nni may be multihomed and multiVPN as well. 1721 6.5.2. Attaching a Site to a VPN 1723 Due to the multiple site-vpn flavors, the attachment of a site to an 1724 IP VPN is done at the site-network-access (logical access) level 1725 through the "vpn-attachment" container. The vpn-attachment container 1726 is mandatory. The model provides two ways to attach a site to a VPN: 1728 o By referencing the target VPN directly. 1730 o By referencing a VPN policy for attachments that are more complex. 1732 A choice is implemented to allow the user to choose the flavor that 1733 provides the best fit. 1735 6.5.2.1. Referencing a VPN 1737 Referencing a vpn-id provides an easy way to attach a particular 1738 logical access to a VPN. This is the best way in the case of a 1739 single VPN attachment or subVPN with a single VPN attachment per 1740 logical access. When referencing a vpn-id, the site-role setting 1741 must be added to express the role of the site in the target VPN 1742 service topology. 1744 1745 1746 1747 1748 VPNA 1749 1750 1751 VPNB 1752 1753 1754 1755 1756 SITE1 1757 1758 1759 L1 1760 1761 1762 1763 customer-managed 1764 1765 1766 1767 layer3 1768 1769 1770 1771 1772 LA1 1773 1774 1775 provider-dhcp 1776 1777 1778 provider-dhcp 1779 1780 1781 1782 1514 1783 10000000 1784 10000000 1785 1786 1787 1788 layer3 1789 1790 1791 L1 1792 1793 VPNA 1794 spoke-role 1795 1796 1797 1798 LA2 1799 1800 1801 provider-dhcp 1802 1803 1804 provider-dhcp 1805 1806 1807 1808 1514 1809 10000000 1810 10000000 1811 1812 1813 1814 layer3 1815 1816 1817 L1 1818 1819 VPNB 1820 spoke-role 1821 1822 1823 1824 1825 1826 1827 The example of a corresponding XML snippet above describes a subVPN 1828 case where a site (SITE1) has two logical accesses (LA1 and LA2), 1829 with LA1 attached to VPNA and LA2 attached to VPNB. 1831 6.5.2.2. VPN Policy 1833 The "vpn-policy" list helps express a multiVPN scenario where a 1834 logical access belongs to multiple VPNs. Multiple VPN policies can 1835 be created to handle the subVPN case where each logical access is 1836 part of a different set of VPNs. 1838 As a site can belong to multiple VPNs, the vpn-policy list may be 1839 composed of multiple entries. A filter can be applied to specify 1840 that only some LANs of the site should be part of a particular VPN. 1841 Each time a site (or LAN) is attached to a VPN, the user must 1842 precisely describe its role (site-role) within the target VPN service 1843 topology. 1845 +--------------------------------------------------------------+ 1846 | Site1 ------ PE7 | 1847 +-------------------------+ (VPN2) | 1848 | | 1849 +-------------------------+ | 1850 | Site2 ------ PE3 PE4 ------ Site3 | 1851 +----------------------------------+ | 1852 | | 1853 +------------------------------------------------------------+ | 1854 | Site4 ------ PE5 | PE6 ------ Site5 | | 1855 | | | 1856 | (VPN3) | | 1857 +------------------------------------------------------------+ | 1858 | | 1859 +---------------------------+ 1861 In the example above, Site5 is part of two VPNs: VPN3 and VPN2. It 1862 will play a Hub role in VPN2 and an any-to-any role in VPN3. We can 1863 express such a multiVPN scenario with the following XML snippet: 1865 1866 1867 1868 1869 VPN2 1870 1871 1872 VPN3 1873 1875 1876 1877 1878 Site5 1879 1880 1881 D1 1882 1883 1884 1885 provider-managed 1886 1887 1888 1889 layer3 1890 1891 1892 1893 1894 POLICY1 1895 1896 ENTRY1 1897 1898 VPN2 1899 hub-role 1900 1901 1902 1903 ENTRY2 1904 1905 VPN3 1906 any-to-any-role 1907 1908 1909 1910 1911 1912 1913 LA1 1914 D1 1915 1916 1917 provider-dhcp 1918 1919 1920 provider-dhcp 1921 1922 1923 1924 1514 1925 10000000 1926 10000000 1927 1928 1929 1930 layer3 1931 1932 1933 1934 POLICY1 1935 1936 1937 1938 1939 1940 1942 Now, if a more-granular VPN attachment is necessary, filtering can be 1943 used. For example, if LAN1 from Site5 must be attached to VPN2 as a 1944 Hub and LAN2 must be attached to VPN3, the following configuration of 1945 corresponding XML snippet can be used: 1947 1948 1949 1950 1951 VPN2 1952 1953 1954 VPN3 1955 1956 1957 1958 1959 Site5 1960 1961 1962 POLICY1 1963 1964 ENTRY1 1965 1966 1967 lan 1968 LAN1 1970 1971 1972 1973 VPN2 1974 hub-role 1975 1976 1977 1978 ENTRY2 1979 1980 1981 lan 1982 LAN2 1983 1984 1985 1986 VPN3 1987 any-to-any-role 1988 1989 1990 1991 1992 1993 1994 LA1 1995 1996 POLICY1 1997 1998 1999 2000 2001 2002 2004 6.6. Deciding Where to Connect the Site 2006 The management system will have to determine where to connect each 2007 site-network-access of a particular site to the provider network 2008 (e.g., PE, aggregation switch). 2010 The current model defines parameters and constraints that can 2011 influence the meshing of the site-network-access. 2013 The management system MUST honor all customer constraints, or if a 2014 constraint is too strict and cannot be fulfilled, the management 2015 system MUST NOT provision the site and MUST provide information to 2016 the user about which constraints that could not be fulfilled.How the 2017 information is provided is out of scope for this document. Whether 2018 or not to relax the constraint would then be left up to the user. 2020 Parameters such as site location (see Section 6.6.2) and access type 2021 are just hints (see Section 6.6.3) for the management system for 2022 service placement. 2024 In addition to parameters and constraints, the management system's 2025 decision MAY be based on any other internal constraints that are left 2026 up to the SP: least load, distance, etc. 2028 6.6.1. Constraint: Device 2030 In the case of provider management or co-management, one or more 2031 devices have been ordered by the customer to a particular already- 2032 configured location. The customer may force a particular site- 2033 network-access to be connected on a particular device that he 2034 ordered. 2036 New York Site 2038 +------------------+ Site 2039 | +--------------+ |----------------------------------- 2040 | | Manhattan | | 2041 | | CE1********* (site-network-access#1) ****** 2042 | +--------------+ | 2043 | +--------------+ | 2044 | | Brooklyn CE2********* (site-network-access#2) ****** 2045 | +--------------+ | 2046 | |----------------------------------- 2047 +------------------+ 2049 In the figure above, site-network-access#1 is associated with CE1 in 2050 the service request. The SP must ensure the provisioning of this 2051 connection. 2053 6.6.2. Constraint/Parameter: Site Location 2055 The location information provided in this model MAY be used by a 2056 management system to determine the target PE to mesh the site (SP 2057 side). A particular location must be associated with each site 2058 network access when configuring it. The SP MUST honor the 2059 termination of the access on the location associated with the site 2060 network access (customer side). The "country-code" in the site 2061 location SHOULD be expressed as an ISO ALPHA-2 code. 2063 The site-network-access location is determined by the "location- 2064 flavor". In the case of a provider-managed or co-managed site, the 2065 user is expected to configure a "device-reference" (device case) that 2066 will bind the site-network-access to a particular device that the 2067 customer ordered. As each device is already associated with a 2068 particular location, in such a case the location information is 2069 retrieved from the device location. In the case of a customer- 2070 managed site, the user is expected to configure a "location- 2071 reference" (location case); this provides a reference to an existing 2072 configured location and will help with placement. 2074 POP#1 (New York) 2075 +---------+ 2076 | PE1 | 2077 Site #1 ---... | PE2 | 2078 (Atlantic City) | PE3 | 2079 +---------+ 2081 POP#2 (Washington) 2082 +---------+ 2083 | PE4 | 2084 | PE5 | 2085 | PE6 | 2086 +---------+ 2088 POP#3 (Philadelphia) 2089 +---------+ 2090 | PE7 | 2091 Site #2 CE#1---... | PE8 | 2092 (Reston) | PE9 | 2093 +---------+ 2095 In the example above, Site #1 is a customer-managed site with a 2096 location L1, while Site #2 is a provider-managed site for which a CE 2097 (CE#1) was ordered. Site #2 is configured with L2 as its location. 2098 When configuring a site-network-access for Site #1, the user will 2099 need to reference location L1 so that the management system will know 2100 that the access will need to terminate on this location. Then, for 2101 distance reasons, this management system may mesh Site #1 on a PE in 2102 the Philadelphia POP. It may also take into account resources 2103 available on PEs to determine the exact target PE (e.g., least 2104 loaded). For Site #2, the user is expected to configure the site- 2105 network-access with a device-reference to CE#1 so that the management 2106 system will know that the access must terminate on the location of 2107 CE#1 and must be connected to CE#1. For placement of the SP side of 2108 the access connection, in the case of the nearest PE used, it may 2109 mesh Site #2 on the Washington POP. 2111 6.6.3. Constraint/Parameter: Access Type 2113 The management system needs to elect the access media to connect the 2114 site to the customer (for example, xDSL, leased line, Ethernet 2115 backhaul). The customer may provide some parameters/constraints that 2116 will provide hints to the management system. 2118 The bearer container information SHOULD be the first piece of 2119 information considered when making this decision: 2121 o The "requested-type" parameter provides information about the 2122 media type that the customer would like to use. If the "strict" 2123 leaf is equal to "true", this MUST be considered a strict 2124 constraint so that the management system cannot connect the site 2125 with another media type. If the "strict" leaf is equal to "false" 2126 (default) and if the requested media type cannot be fulfilled, the 2127 management system can select another media type. The supported 2128 media types SHOULD be communicated by the SP to the customer via a 2129 mechanism that is out of scope for this document. 2131 o The "always-on" leaf defines a strict constraint: if set to true, 2132 the management system MUST elect a media type that is "always-on" 2133 (e.g., this means no dial access type). 2135 o The "bearer-reference" parameter is used in cases where the 2136 customer has already ordered a network connection to the SP apart 2137 from the IP VPN site and wants to reuse this connection. The 2138 string used is an internal reference from the SP and describes the 2139 already-available connection. This is also a strict requirement 2140 that cannot be relaxed. How the reference is given to the 2141 customer is out of scope for this document, but as a pure example, 2142 when the customer ordered the bearer (through a process that is 2143 out of scope for this model), the SP may have provided the bearer 2144 reference that can be used for provisioning services on top. 2146 Any other internal parameters from the SP can also be used. The 2147 management system MAY use other parameters, such as the requested 2148 "svc-input-bandwidth" and "svc-output-bandwidth", to help decide 2149 which access type to use. 2151 6.6.4. Constraint: Access Diversity 2153 Each site-network-access may have one or more constraints that would 2154 drive the placement of the access. By default, the model assumes 2155 that there are no constraints, but allocation of a unique bearer per 2156 site-network-access is expected. 2158 In order to help with the different placement scenarios, a site- 2159 network-access may be tagged using one or multiple group identifiers. 2160 The group identifier is a string, so it can accommodate both explicit 2161 naming of a group of sites (e.g., "multihomed-set1" or "subVPN") and 2162 the use of a numbered identifier (e.g., 12345678). The meaning of 2163 each group-id is local to each customer administrator, and the 2164 management system MUST ensure that different customers can use the 2165 same group-ids. One or more group-ids can also be defined at the 2166 site level; as a consequence, all site-network-accesses under the 2167 site MUST inherit the group-ids of the site they belong to. When, in 2168 addition to the site group-ids some group-ids are defined at the 2169 site-network-access level, the management system MUST consider the 2170 union of all groups (site level and site network access level) for 2171 this particular site-network-access. 2173 For an already-configured site-network-access, each constraint MUST 2174 be expressed against a targeted set of site-network-accesses. This 2175 site-network-access MUST never be taken into account in the targeted 2176 set -- for example, "My site-network-access S must not be connected 2177 on the same POP as the site-network-accesses that are part of Group 2178 10." The set of site-network-accesses against which the constraint 2179 is evaluated can be expressed as a list of groups, "all-other- 2180 accesses", or "all-other-groups". The all-other-accesses option 2181 means that the current site-network-access constraint MUST be 2182 evaluated against all the other site-network-accesses belonging to 2183 the current site. The all-other-groups option means that the 2184 constraint MUST be evaluated against all groups that the current 2185 site-network-access does not belong to. 2187 The current model defines multiple constraint-types: 2189 o pe-diverse: The current site-network-access MUST NOT be connected 2190 to the same PE as the targeted site-network-accesses. 2192 o pop-diverse: The current site-network-access MUST NOT be connected 2193 to the same POP as the targeted site-network-accesses. 2195 o linecard-diverse: The current site-network-access MUST NOT be 2196 connected to the same linecard as the targeted site-network- 2197 accesses. 2199 o bearer-diverse: The current site-network-access MUST NOT use 2200 common bearer components compared to bearers used by the targeted 2201 site-network-accesses. "bearer-diverse" provides some level of 2202 diversity at the access level. As an example, two bearer-diverse 2203 site-network-accesses must not use the same DSLAM, BAS, or Layer 2 2204 switch. 2206 o same-pe: The current site-network-access MUST be connected to the 2207 same PE as the targeted site-network-accesses. 2209 o same-bearer: The current site-network-access MUST be connected 2210 using the same bearer as the targeted site-network-accesses. 2212 These constraint-types can be extended through augmentation. 2214 Each constraint is expressed as "The site-network-access S must be 2215 (e.g., pe-diverse, pop-diverse) from these 2216 site-network-accesses." 2218 The group-id used to target some site-network-accesses may be the 2219 same as the one used by the current site-network-access. This eases 2220 the configuration of scenarios where a group of site-network-access 2221 points has a constraint between the access points in the group. As 2222 an example, if we want a set of sites (Site#1 to Site#5) to be 2223 connected on different PEs, we can tag them with the same group-id 2224 and express a pe-diverse constraint for this group-id with the 2225 following XML snippet: 2227 2228 2229 2230 2231 VPNA 2232 2233 2234 2235 2236 SITE1 2237 2238 2239 L1 2240 2241 2242 2243 customer-managed 2244 2245 2246 2247 1 2248 2249 2250 provider-dhcp 2251 2252 2253 provider-dhcp 2255 2256 2257 2258 1514 2259 10000000 2260 10000000 2261 2262 2263 2264 layer3 2265 2266 2267 L1 2268 2269 2270 2271 10 2272 2273 2274 2275 2276 pe-diverse 2277 2278 2279 10 2280 2281 2282 2283 2284 2285 2286 VPNA 2287 spoke-role 2288 2289 2290 2291 2292 2293 SITE2 2294 2295 2296 L1 2297 2298 2299 2300 customer-managed 2301 2302 2303 2304 layer3 2305 2306 2307 2308 2309 1 2310 2311 2312 provider-dhcp 2313 2314 2315 provider-dhcp 2316 2317 2318 2319 1514 2320 10000000 2321 10000000 2322 2323 2324 2325 layer3 2326 2327 2328 L1 2329 2330 2331 2332 10 2333 2334 2335 2336 2337 pe-diverse 2338 2339 2340 10 2341 2342 2343 2344 2345 2346 2347 VPNA 2348 spoke-role 2349 2350 2352 2353 2354 ... 2355 2356 SITE5 2357 2358 2359 L1 2360 2361 2362 2363 customer-managed 2364 2365 2366 2367 layer3 2368 2369 2370 2371 2372 1 2373 2374 2375 provider-dhcp 2376 2377 2378 provider-dhcp 2379 2380 2381 2382 1514 2383 10000000 2384 10000000 2385 2386 2387 2388 layer3 2389 2390 2391 L1 2392 2393 2394 2395 10 2396 2397 2398 2399 2400 pe-diverse 2401 2402 2403 10 2404 2405 2406 2407 2408 2409 2410 VPNA 2411 spoke-role 2412 2413 2414 2415 2416 2417 2419 The group-id used to target some site-network-accesses may also be 2420 different than the one used by the current site-network-access. This 2421 can be used to express that a group of sites has some constraints 2422 against another group of sites, but there is no constraint within the 2423 group. For example, we consider a set of six sites and two groups; 2424 we want to ensure that a site in the first group must be pop-diverse 2425 from a site in the second group. The example of a corresponding XML 2426 snippet is described as follows: 2428 2429 2430 2431 2432 VPNA 2433 2434 2435 2436 2437 SITE1 2438 2439 2440 1 2441 2442 2443 2444 10 2445 2446 2447 2448 2449 pop-diverse 2450 2451 2452 20 2453 2454 2455 2456 2457 2458 2459 VPNA 2460 spoke-role 2461 2462 2463 2464 2465 2466 SITE2 2467 2468 2469 1 2470 2471 2472 2473 10 2474 2475 2476 2477 2478 pop-diverse 2479 2480 2481 20 2482 2483 2484 2485 2486 2487 2488 VPNA 2489 spoke-role 2490 2491 2492 2493 2494 ... 2496 2497 SITE5 2498 2499 2500 1 2501 2502 2503 2504 20 2505 2506 2507 2508 2509 pop-diverse 2510 2511 2512 10 2513 2514 2515 2516 2517 2518 2519 VPNA 2520 spoke-role 2521 2522 2523 2524 2525 2526 SITE6 2527 2528 2529 L1 2530 2531 2532 2533 customer-managed 2534 2535 2536 2537 layer3 2538 2539 2540 2541 2542 1 2543 2544 2545 provider-dhcp 2546 2547 2548 provider-dhcp 2549 2550 2551 2552 1514 2553 10000000 2554 10000000 2555 2556 2557 2558 layer3 2559 2560 2561 L1 2562 2563 2564 2565 20 2566 2567 2568 2569 2570 pop-diverse 2571 2572 2573 10 2574 2575 2576 2577 2578 2579 2580 VPNA 2581 spoke-role 2582 2583 2584 2585 2586 2587 2588 6.6.5. Infeasible Access Placement 2590 Some infeasible access placement scenarios could be created via the 2591 proposed configuration framework. Such infeasible access placement 2592 scenarios could result from constraints that are too restrictive, 2593 leading to infeasible access placement in the network or conflicting 2594 constraints that would also lead to infeasible access placement. An 2595 example of conflicting rules would be to request that site-network- 2596 access#1 be pe-diverse from site-network-access#2 and to request at 2597 the same time that site-network-access#2 be on the same PE as site- 2598 network-access#1. When the management system cannot determine the 2599 placement of a site-network-access, it MUST return an error message 2600 indicating that placement was not possible. 2602 6.6.6. Examples of Access Placement 2604 6.6.6.1. Multihoming 2606 The customer wants to create a multihomed site. The site will be 2607 composed of two site-network-accesses; for resiliency purposes, the 2608 customer wants the two site-network-accesses to be meshed on 2609 different POPs. 2611 POP#1 2612 +-------+ +---------+ 2613 | | | PE1 | 2614 | |---site-network-access#1----| PE2 | 2615 | | | PE3 | 2616 | | +---------+ 2617 | Site#1| 2618 | | POP#2 2619 | | +---------+ 2620 | | | PE4 | 2621 | |---site-network-access#2----| PE5 | 2622 | | | PE6 | 2623 | | +---------+ 2624 +-------+ 2626 This scenario can be expressed with the following XML snippet: 2628 2629 2630 2631 2632 VPNA 2633 2634 2635 2636 2637 SITE1 2638 2639 2640 L1 2641 2642 2643 2644 customer-managed 2645 2646 2647 2648 layer3 2649 2650 2651 2652 2653 1 2654 2655 2656 provider-dhcp 2657 2658 2659 provider-dhcp 2660 2661 2662 2663 1514 2664 10000000 2665 10000000 2666 2667 2668 2669 layer3 2670 2671 2672 L1 2673 2674 2675 2676 10 2677 2678 2679 2680 2681 pop-diverse 2682 2683 2684 20 2685 2686 2687 2688 2689 2690 2691 VPNA 2692 spoke-role 2693 2694 2695 2696 2 2697 2698 2699 provider-dhcp 2700 2701 2702 provider-dhcp 2703 2704 2705 2706 1514 2707 10000000 2708 10000000 2709 2710 2711 2712 layer3 2713 2714 2715 L1 2716 2717 2718 2719 20 2720 2721 2722 2723 2724 pop-diverse 2725 2726 2727 10 2728 2729 2730 2732 2733 2734 2735 VPNA 2736 spoke-role 2737 2738 2739 2740 2741 2742 2744 But it can also be expressed with the following XML snippet: 2746 2747 2748 2749 2750 VPNA 2751 2752 2753 2754 2755 SITE1 2756 2757 2758 1 2759 2760 2761 2762 pop-diverse 2763 2764 2765 2766 2767 2768 2769 2770 VPNA 2771 spoke-role 2772 2773 2774 2775 2 2776 2777 2778 2779 pop-diverse 2780 2781 2782 2783 2784 2785 2786 2787 VPNA 2788 spoke-role 2789 2790 2791 2792 2793 2794 2796 6.6.6.2. Site Offload 2798 The customer has six branch offices in a particular region, and he 2799 wants to prevent having all branch offices connected on the same PE. 2801 He wants to express that three branch offices cannot be connected on 2802 the same linecard. Also, the other branch offices must be connected 2803 on a different POP. Those other branch offices cannot also be 2804 connected on the same linecard. 2806 POP#1 2807 +---------+ 2808 | PE1 | 2809 Office#1 ---... | PE2 | 2810 Office#2 ---... | PE3 | 2811 Office#3 ---... | PE4 | 2812 +---------+ 2814 POP#2 2815 +---------+ 2816 Office#4 ---... | PE5 | 2817 Office#5 ---... | PE6 | 2818 Office#6 ---... | PE7 | 2819 +---------+ 2821 This scenario can be expressed as follows: 2823 o We need to create two groups of sites: Group#10, which is composed 2824 of Office#1, Office#2, and Office#3; and Group#20, which is 2825 composed of Office#4, Office#5, and Office#6. 2827 o Sites within Group#10 must be pop-diverse from sites within 2828 Group#20, and vice versa. 2830 o Sites within Group#10 must be linecard-diverse from other sites in 2831 Group#10 (same for Group#20). 2833 2834 2835 2836 2837 VPNA 2838 2839 2840 2841 2842 Office1 2843 2844 2845 L1 2846 2847 2848 2849 customer-managed 2850 2851 2852 2853 layer3 2854 2855 2856 2857 2858 1 2859 2860 2861 provider-dhcp 2862 2863 2864 provider-dhcp 2865 2866 2867 2868 1514 2869 10000000 2870 10000000 2872 2873 2874 2875 layer3 2876 2877 2878 L1 2879 2880 2881 2882 10 2883 2884 2885 2886 2887 pop-diverse 2888 2889 2890 20 2891 2892 2893 2894 2895 linecard-diverse 2896 2897 2898 10 2899 2900 2901 2902 2903 2904 2905 VPNA 2906 spoke-role 2907 2908 2909 2910 2911 2912 Office2 2913 2914 2915 L1 2916 2917 2918 2919 customer-managed 2921 2922 2923 2924 layer3 2925 2926 2927 2928 2929 1 2930 2931 2932 provider-dhcp 2933 2934 2935 provider-dhcp 2936 2937 2938 2939 1514 2940 10000000 2941 10000000 2942 2943 2944 2945 layer3 2946 2947 2948 L1 2949 2950 2951 2952 10 2953 2954 2955 2956 2957 pop-diverse 2958 2959 2960 20 2961 2962 2963 2964 2965 linecard-diverse 2966 2967 2968 10 2970 2971 2972 2973 2974 2975 2976 VPNA 2977 spoke-role 2978 2979 2980 2981 2982 2983 Office3 2984 2985 2986 L1 2987 2988 2989 2990 customer-managed 2991 2992 2993 2994 layer3 2995 2996 2997 2998 2999 1 3000 3001 3002 provider-dhcp 3003 3004 3005 provider-dhcp 3006 3007 3008 3009 1514 3010 10000000 3011 10000000 3012 3013 3014 3015 layer3 3016 3017 3018 L1 3019 3020 3021 3022 10 3023 3024 3025 3026 3027 pop-diverse 3028 3029 3030 20 3031 3032 3033 3034 3035 linecard-diverse 3036 3037 3038 10 3039 3040 3041 3042 3043 3044 3045 VPNA 3046 spoke-role 3047 3048 3049 3050 3051 3052 Office4 3053 3054 3055 L1 3056 3057 3058 3059 customer-managed 3060 3061 3062 3063 layer3 3064 3065 3066 3067 3068 1 3069 3070 3071 provider-dhcp 3072 3073 3074 provider-dhcp 3075 3076 3077 3078 1514 3079 10000000 3080 10000000 3081 3082 3083 3084 layer3 3085 3086 3087 L1 3088 3089 3090 3091 20 3092 3093 3094 3095 3096 pop-diverse 3097 3098 3099 10 3100 3101 3102 3103 3104 linecard-diverse 3105 3106 3107 20 3108 3109 3110 3111 3112 3113 3114 VPNA 3115 spoke-role 3116 3117 3118 3119 3120 3121 Office5 3122 3123 3124 L1 3125 3126 3127 3128 customer-managed 3129 3130 3131 3132 layer3 3133 3134 3135 3136 3137 1 3138 3139 3140 provider-dhcp 3141 3142 3143 provider-dhcp 3144 3145 3146 3147 1514 3148 10000000 3149 10000000 3150 3151 3152 3153 layer3 3154 3155 3156 L1 3157 3158 3159 3160 20 3161 3163 3164 3165 3166 pop-diverse 3167 3168 3169 10 3170 3171 3172 3173 3174 linecard-diverse 3175 3176 3177 20 3178 3179 3180 3181 3182 3183 3184 VPNA 3185 spoke-role 3186 3187 3188 3189 3190 3191 Office6 3192 3193 3194 L1 3195 3196 3197 3198 customer-managed 3199 3200 3201 3202 layer3 3203 3204 3205 3206 3207 1 3208 3209 3210 provider-dhcp 3212 3213 3214 provider-dhcp 3215 3216 3217 3218 1514 3219 10000000 3220 10000000 3221 3222 3223 3224 layer3 3225 3226 3227 L1 3228 3229 3230 3231 20 3232 3233 3234 3235 3236 pop-diverse 3237 3238 3239 10 3240 3241 3242 3243 3244 linecard-diverse 3245 3246 3247 20 3248 3249 3250 3251 3252 3253 3254 VPNA 3255 spoke-role 3256 3257 3258 3259 3261 3262 3264 6.6.6.3. Parallel Links 3266 To increase its site bandwidth at lower cost, a customer wants to 3267 order two parallel site-network-accesses that will be connected to 3268 the same PE. 3270 *******site-network-access#1********** 3271 Site 1 *******site-network-access#2********** PE1 3273 This scenario can be expressed with the following XML snippet: 3275 3276 3277 3278 3279 VPNB 3280 3281 3282 3283 3284 SITE1 3285 3286 3287 1 3288 3289 3290 3291 PE-linkgrp-1 3292 3293 3294 3295 3296 same-pe 3297 3298 3299 PE-linkgrp-1 3300 3301 3302 3303 3304 3305 3306 VPNB 3307 spoke-role 3308 3309 3310 3311 2 3312 3313 3314 3315 PE-linkgrp-1 3316 3317 3318 3319 3320 same-pe 3321 3322 3323 PE-linkgrp-1 3324 3325 3326 3327 3328 3329 3330 VPNB 3331 spoke-role 3332 3333 3334 3335 3336 3337 3339 6.6.6.4. SubVPN with Multihoming 3341 A customer has a site that is dual-homed. The dual-homing must be 3342 done on two different PEs. The customer also wants to implement two 3343 subVPNs on those multihomed accesses. 3345 +-----------------+ Site +------+ 3346 | |---------------------------------/ +-----+ 3347 | |****(site-network-access#1)*****| VPN B / \ 3348 | New York Office |****(site-network-access#2)************| VPN C | 3349 | | +-----\ / 3350 | | +-----+ 3351 | | 3352 | | +------+ 3353 | | / +-----+ 3354 | |****(site-network-access#3)*****| VPN B / \ 3355 | |****(site-network-access#4)************| VPN C | 3356 | | +-----\ / 3357 | |----------------------------------- +-----+ 3358 +-----------------+ 3360 This scenario can be expressed as follows: 3362 o The site will have four site network accesses (two subVPNs coupled 3363 via dual-homing). 3365 o Site-network-access#1 and site-network-access#3 will correspond to 3366 the multihoming of subVPN B. A PE-diverse constraint is required 3367 between them. 3369 o Site-network-access#2 and site-network-access#4 will correspond to 3370 the multihoming of subVPN C. A PE-diverse constraint is required 3371 between them. 3373 o To ensure proper usage of the same bearer for the subVPN, site- 3374 network-access#1 and site-network-access#2 must share the same 3375 bearer as site-network-access#3 and site-network-access#4. 3377 3378 3379 3380 3381 VPNB 3382 3383 3384 VPNC 3385 3386 3387 3388 3389 SITE1 3390 3391 3392 L1 3393 3394 3395 3396 customer-managed 3397 3398 3399 3400 layer3 3401 3402 3403 3404 3405 1 3406 3407 3408 provider-dhcp 3409 3410 3411 provider-dhcp 3412 3413 3414 3415 1514 3416 10000000 3417 10000000 3418 3419 3420 3421 layer3 3422 3423 3424 L1 3425 3426 3427 3428 dualhomed-1 3429 3430 3431 3432 3433 pe-diverse 3434 3435 3436 dualhomed-2 3437 3438 3439 3440 3441 same-bearer 3442 3443 3444 dualhomed-1 3445 3446 3447 3448 3449 3450 3451 VPNB 3452 spoke-role 3453 3454 3455 3456 2 3457 3458 3459 3460 dualhomed-1 3461 3462 3463 3464 3465 pe-diverse 3466 3467 3468 dualhomed-2 3469 3470 3471 3472 3473 same-bearer 3474 3475 3476 dualhomed-1 3477 3478 3479 3480 3481 3482 3483 VPNC 3484 spoke-role 3485 3486 3487 3488 3 3489 3490 3491 provider-dhcp 3492 3493 3494 provider-dhcp 3495 3496 3497 3498 1514 3499 10000000 3500 10000000 3501 3502 3503 3504 layer3 3505 3506 3507 L1 3508 3509 3510 3511 dualhomed-2 3512 3513 3514 3515 3516 pe-diverse 3517 3518 3519 dualhomed-1 3520 3521 3522 3523 3524 same-bearer 3525 3526 3527 dualhomed-2 3528 3529 3530 3531 3532 3533 3534 VPNB 3535 spoke-role 3537 3538 3539 3540 4 3541 3542 3543 provider-dhcp 3544 3545 3546 provider-dhcp 3547 3548 3549 3550 1514 3551 10000000 3552 10000000 3553 3554 3555 3556 layer3 3557 3558 3559 L1 3560 3561 3562 3563 dualhomed-2 3564 3565 3566 3567 3568 pe-diverse 3569 3570 3571 dualhomed-1 3572 3573 3574 3575 3576 same-bearer 3577 3578 3579 dualhomed-2 3580 3581 3582 3583 3584 3585 3586 VPNC 3587 spoke-role 3588 3589 3590 3591 3592 3593 3595 6.6.7. Route Distinguisher and VRF Allocation 3597 The route distinguisher (RD) is a critical parameter of PE-based 3598 L3VPNs as described in [RFC4364] that provides the ability to 3599 distinguish common addressing plans in different VPNs. As for route 3600 targets (RTs), a management system is expected to allocate a VRF on 3601 the target PE and an RD for this VRF. 3603 If a VRF already exists on the target PE and the VRF fulfills the 3604 connectivity constraints for the site, there is no need to recreate 3605 another VRF, and the site MAY be meshed within this existing VRF. 3606 How the management system checks that an existing VRF fulfills the 3607 connectivity constraints for a site is out of scope for this 3608 document. 3610 If no such VRF exists on the target PE, the management system has to 3611 initiate the creation of a new VRF on the target PE and has to 3612 allocate a new RD for this new VRF. 3614 The management system MAY apply a per-VPN or per-VRF allocation 3615 policy for the RD, depending on the SP's policy. In a per-VPN 3616 allocation policy, all VRFs (dispatched on multiple PEs) within a VPN 3617 will share the same RD value. In a per-VRF model, all VRFs should 3618 always have a unique RD value. Some other allocation policies are 3619 also possible, and this document does not restrict the allocation 3620 policies to be used. 3622 The allocation of RDs MAY be done in the same way as RTs. The 3623 examples provided in Section 6.2.1.1 could be reused in this 3624 scenario. 3626 Note that an SP MAY configure a target PE for an automated allocation 3627 of RDs. In this case, there will be no need for any backend system 3628 to allocate an RD value. 3630 6.7. Site Network Access Availability 3632 A site may be multihomed, meaning that it has multiple site-network- 3633 access points. Placement constraints defined in previous sections 3634 will help ensure physical diversity. 3636 When the site-network-accesses are placed on the network, a customer 3637 may want to use a particular routing policy on those accesses. 3639 The "site-network-access/availability" container defines parameters 3640 for site redundancy. The "access-priority" leaf defines a preference 3641 for a particular access. This preference is used to model load- 3642 balancing or primary/backup scenarios. The higher the access- 3643 priority value, the higher the preference will be. 3645 The figure below describes how the access-priority attribute can be 3646 used. 3648 Hub#1 LAN (Primary/backup) Hub#2 LAN (Load-sharing) 3649 | | 3650 | access-priority 1 access-priority 1 | 3651 |--- CE1 ------- PE1 PE3 --------- CE3 --- | 3652 | | 3653 | | 3654 |--- CE2 ------- PE2 PE4 --------- CE4 --- | 3655 | access-priority 2 access-priority 1 | 3657 PE5 3658 | 3659 | 3660 | 3661 CE5 3662 | 3663 Spoke#1 site (Single-homed) 3665 In the figure above, Hub#2 requires load-sharing, so all the site- 3666 network-accesses must use the same access-priority value. On the 3667 other hand, as Hub#1 requires a primary site-network-access and a 3668 backup site-network-access, a higher access-priority setting will be 3669 configured on the primary site-network-access. 3671 Scenarios that are more complex can be modeled. Let's consider a Hub 3672 site with five accesses to the network (A1,A2,A3,A4,A5). The 3673 customer wants to load-share its traffic on A1,A2 in the nominal 3674 situation. If A1 and A2 fail, the customer wants to load-share its 3675 traffic on A3 and A4; finally, if A1 to A4 are down, he wants to use 3676 A5. We can model this easily by configuring the following access- 3677 priority values: A1=100, A2=100, A3=50, A4=50, A5=10. 3679 The access-priority scenario has some limitations. An access- 3680 priority scenario like the previous one with five accesses but with 3681 the constraint of having traffic load-shared between A3 and A4 in the 3682 case where A1 OR A2 is down is not achievable. But the authors 3683 believe that using the access-priority attribute will cover most of 3684 the deployment use cases and that the model can still be extended via 3685 augmentation to support additional use cases. 3687 6.8. Traffic Protection 3689 The service model supports the ability to protect the traffic for a 3690 site. Such protection provides a better level of availability in 3691 multihoming scenarios by, for example, using local-repair techniques 3692 in case of failures. The associated level of service guarantee would 3693 be based on an agreement between the customer and the SP and is out 3694 of scope for this document. 3696 Site#1 Site#2 3697 CE1 ----- PE1 -- P1 P3 -- PE3 ---- CE3 3698 | | | 3699 | | | 3700 CE2 ----- PE2 -- P2 P4 -- PE4 ---- CE4 3701 / 3702 / 3703 CE5 ----+ 3704 Site#3 3706 In the figure above, we consider an IP VPN service with three sites, 3707 including two dual-homed sites (Site#1 and Site#2). For dual-homed 3708 sites, we consider PE1-CE1 and PE3-CE3 as primary and PE2-CE2,PE4-CE4 3709 as backup for the example (even if protection also applies to load- 3710 sharing scenarios). 3712 In order to protect Site#2 against a failure, a user may set the 3713 "traffic-protection/enabled" leaf to true for Site#2. How the 3714 traffic protection will be implemented is out of scope for this 3715 document. However, in such a case, we could consider traffic coming 3716 from a remote site (Site#1 or Site#3), where the primary path would 3717 use PE3 as the egress PE. PE3 may have preprogrammed a backup 3718 forwarding entry pointing to the backup path (through PE4-CE4) for 3719 all prefixes going through the PE3-CE3 link. How the backup path is 3720 computed is out of scope for this document. When the PE3-CE3 link 3721 fails, traffic is still received by PE3, but PE3 automatically 3722 switches traffic to the backup entry; the path will therefore be 3723 PE1-P1-(...)-P3-PE3-PE4-CE4 until the remote PEs reconverge and use 3724 PE4 as the egress PE. 3726 6.9. Security 3728 The "security" container defines customer-specific security 3729 parameters for the site. The security options supported in the model 3730 are limited but may be extended via augmentation. 3732 6.9.1. Authentication 3734 The current model does not support any authentication parameters for 3735 the site connection, but such parameters may be added in the 3736 "authentication" container through augmentation. 3738 6.9.2. Encryption 3740 Traffic encryption can be requested on the connection. It may be 3741 performed at Layer 2 or Layer 3 by selecting the appropriate 3742 enumeration in the "layer" leaf. For example, an SP may use IPsec 3743 when a customer requests Layer 3 encryption. The encryption profile 3744 can be SP defined or customer specific. 3746 When an SP profile is used and a key (e.g., a pre-shared key) is 3747 allocated by the provider to be used by a customer, the SP should 3748 provide a way to communicate the key in a secured way to the 3749 customer. 3751 When a customer profile is used, the model supports only a pre-shared 3752 key for authentication, with the pre-shared key provided through the 3753 NETCONF or RESTCONF request. A secure channel must be used to ensure 3754 that the pre-shared key cannot be intercepted. 3756 For security reasons, it may be necessary for the customer to change 3757 the pre-shared key on a regular basis. To perform a key change, the 3758 user can ask the SP to change the pre-shared key by submitting a new 3759 pre-shared key for the site configuration (as shown below with a 3760 corresponding XML snippet). This mechanism might not be hitless. 3762 3763 3764 3765 3766 VPNA 3767 3768 3769 3770 3771 SITE1 3772 3773 3774 1 3775 3776 3777 3778 MY_NEW_KEY 3779 3780 3781 3782 3783 3784 3785 3786 3788 A hitless key change mechanism may be added through augmentation. 3790 Other key-management methodologies (e.g., PKI) may be added through 3791 augmentation. 3793 6.10. Management 3795 The model defines three types of common management options: 3797 o provider-managed: The CE router is managed only by the provider. 3798 In this model, the responsibility boundary between the SP and the 3799 customer is between the CE and the customer network. 3801 o customer-managed: The CE router is managed only by the customer. 3802 In this model, the responsibility boundary between the SP and the 3803 customer is between the PE and the CE. 3805 o co-managed: The CE router is primarily managed by the provider; in 3806 addition, the SP allows customers to access the CE for 3807 configuration/monitoring purposes. In the co-managed mode, the 3808 responsibility boundary is the same as the responsibility boundary 3809 for the provider-managed model. 3811 Based on the management model, different security options MAY be 3812 derived. 3814 In the co-managed case, the model defines options for the management 3815 address family (IPv4 or IPv6) and the associated management address. 3817 6.11. Routing Protocols 3819 "routing-protocol" defines which routing protocol must be activated 3820 between the provider and the customer router. The current model 3821 supports the following settings: bgp, rip, ospf, static, direct, and 3822 vrrp. 3824 The routing protocol defined applies at the provider-to-customer 3825 boundary. Depending on how the management model is administered, it 3826 may apply to the PE-CE boundary or the CE-to-customer boundary. In 3827 the case of a customer-managed site, the routing protocol defined 3828 will be activated between the PE and the CE router managed by the 3829 customer. In the case of a provider-managed site, the routing 3830 protocol defined will be activated between the CE managed by the SP 3831 and the router or LAN belonging to the customer. In this case, we 3832 expect the PE-CE routing to be configured based on the SP's rules, as 3833 both are managed by the same entity. 3835 Rtg protocol 3836 192.0.2.0/24 ----- CE ----------------- PE1 3838 Customer-managed site 3840 Rtg protocol 3841 Customer router ----- CE ----------------- PE1 3843 Provider-managed site 3845 All the examples below will refer to a scenario for a customer- 3846 managed site. 3848 6.11.1. Handling of Dual Stack 3850 All routing protocol types support dual stack by using the "address- 3851 family" leaf-list. 3853 Example of a corresponding XML snippet with dual stack using the same 3854 routing protocol: 3856 3857 3858 3859 3860 VPNA 3861 3862 3863 3864 3865 SITE1 3866 3867 3868 static 3869 3870 3871 3872 192.0.2.0/24 3873 203.0.113.1 3874 3875 3876 3877 3878 3879 3880 3881 3883 Example of a corresponding XML snippet with dual stack using two 3884 different routing protocols: 3886 3887 3888 3889 3890 VPNA 3891 3892 3893 3894 3895 SITE1 3896 3897 3898 rip 3899 3900 ipv4 3901 3902 3903 3904 ospf 3905 3906 ipv6 3907 4.4.4.4 3908 3909 3910 3911 3912 3913 3915 6.11.2. LAN Directly Connected to SP Network 3917 The routing protocol type "direct" SHOULD be used when a customer LAN 3918 is directly connected to the provider network and must be advertised 3919 in the IP VPN. 3921 LAN attached directly to provider network: 3923 192.0.2.0/24 ----- PE1 3925 In this case, the customer has a default route to the PE address. 3927 6.11.3. LAN Directly Connected to SP Network with Redundancy 3929 The routing protocol type "vrrp" SHOULD be used and advertised in the 3930 IP VPN when 3931 o the customer LAN is directly connected to the provider network, 3932 and 3934 o LAN redundancy is expected. 3936 LAN attached directly to provider network with LAN redundancy: 3938 192.0.2.0/24 ------ PE1 3939 | 3940 +--- PE2 3942 In this case, the customer has a default route to the SP network. 3944 6.11.4. Static Routing 3946 The routing protocol type "static" MAY be used when a customer LAN is 3947 connected to the provider network through a CE router and must be 3948 advertised in the IP VPN. In this case, the static routes give next 3949 hops (nh) to the CE and to the PE. The customer has a default route 3950 to the SP network. 3952 Static rtg 3953 192.0.2.0/24 ------ CE -------------- PE 3954 | | 3955 | Static route 192.0.2.0/24 nh CE 3956 Static route 0.0.0.0/0 nh PE 3958 6.11.5. RIP Routing 3960 The routing protocol type "rip" MAY be used when a customer LAN is 3961 connected to the provider network through a CE router and must be 3962 advertised in the IP VPN. For IPv4, the model assumes that RIP 3963 version 2 is used. 3965 In the case of dual-stack routing requested through this model, the 3966 management system will be responsible for configuring RIP (including 3967 the correct version number) and associated address families on 3968 network elements. 3970 RIP rtg 3971 192.0.2.0/24 ------ CE -------------- PE 3973 6.11.6. OSPF Routing 3975 The routing protocol type "ospf" MAY be used when a customer LAN is 3976 connected to the provider network through a CE router and must be 3977 advertised in the IP VPN. 3979 It can be used to extend an existing OSPF network and interconnect 3980 different areas. See [RFC4577] for more details. 3982 +---------------------+ 3983 | | 3984 OSPF | | OSPF 3985 area 1 | | area 2 3986 (OSPF | | (OSPF 3987 area 1) --- CE ---------- PE PE ----- CE --- area 2) 3988 | | 3989 +---------------------+ 3991 The model also defines an option to create an OSPF sham link between 3992 two sites sharing the same area and having a backdoor link. The sham 3993 link is created by referencing the target site sharing the same OSPF 3994 area. The management system will be responsible for checking to see 3995 if there is already a sham link configured for this VPN and area 3996 between the same pair of PEs. If there is no existing sham link, the 3997 management system will provision one. This sham link MAY be reused 3998 by other sites. 4000 +------------------------+ 4001 | | 4002 | | 4003 | PE (--sham link--)PE | 4004 | | | | 4005 +----|----------------|--+ 4006 | OSPF area 1 | OSPF area 1 4007 | | 4008 CE1 CE2 4009 | | 4010 (OSPF area 1) (OSPF area 1) 4011 | | 4012 +----------------+ 4014 Regarding dual-stack support, the user MAY specify both IPv4 and IPv6 4015 address families, if both protocols should be routed through OSPF. 4016 As OSPF uses separate protocol instances for IPv4 and IPv6, the 4017 management system will need to configure both OSPF version 2 and OSPF 4018 version 3 on the PE-CE link. 4020 Other OSPF parameters, such as timers, are typically set by the SP 4021 and communicated to the customer outside the scope of this model. 4023 Example of a corresponding XML snippet with OSPF routing parameters 4024 in the service model: 4026 4027 4028 4029 4030 VPNA 4031 4032 4033 4034 4035 SITE1 4036 4037 4038 ospf 4039 4040 0.0.0.1 4041 ipv4 4042 ipv6 4043 4044 4045 4046 4047 4048 4050 Example of PE configuration done by the management system: 4052 router ospf 10 4053 area 0.0.0.1 4054 interface Ethernet0/0 4055 ! 4056 router ospfv3 10 4057 area 0.0.0.1 4058 interface Ethernet0/0 4059 ! 4061 6.11.7. BGP Routing 4063 The routing protocol type "bgp" MAY be used when a customer LAN is 4064 connected to the provider network through a CE router and must be 4065 advertised in the IP VPN. 4067 BGP rtg 4068 192.0.2.0/24 ------ CE -------------- PE 4070 The session addressing will be derived from connection parameters as 4071 well as the SP's knowledge of the addressing plan that is in use. 4073 In the case of dual-stack access, the user MAY request BGP routing 4074 for both IPv4 and IPv6 by specifying both address families. It will 4075 be up to the SP and management system to determine how to describe 4076 the configuration (two BGP sessions, single, multi-session, etc.). 4077 This, along with other BGP parameters such as timers, is communicated 4078 to the customer outside the scope of this model. 4080 The service configuration below activates BGP on the PE-CE link for 4081 both IPv4 and IPv6. 4083 BGP activation requires the SP to know the address of the customer 4084 peer. If the site-network-access connection addresses are used for 4085 BGP peering, the "static-address" allocation type for the IP 4086 connection MUST be used. Other peering mechanisms are outside the 4087 scope of this model. An example of a corresponding XML snippet is 4088 described as follows: 4090 4091 4092 4093 4094 VPNA 4095 4096 4097 4098 4099 SITE1 4100 4101 4102 bgp 4103 4104 65000 4105 ipv4 4106 ipv6 4107 4108 4109 4110 4111 4112 4114 Depending on the SP flavor, a management system can divide this 4115 service configuration into different flavors, as shown by the 4116 following examples. 4118 Example of PE configuration done by the management system (single 4119 IPv4 transport session): 4121 router bgp 100 4122 neighbor 203.0.113.2 remote-as 65000 4123 address-family ipv4 vrf Cust1 4124 neighbor 203.0.113.2 activate 4125 address-family ipv6 vrf Cust1 4126 neighbor 203.0.113.2 activate 4127 neighbor 203.0.113.2 route-map SET-NH-IPV6 out 4129 Example of PE configuration done by the management system (two 4130 sessions): 4132 router bgp 100 4133 neighbor 203.0.113.2 remote-as 65000 4134 neighbor 2001::2 remote-as 65000 4135 address-family ipv4 vrf Cust1 4136 neighbor 203.0.113.2 activate 4137 address-family ipv6 vrf Cust1 4138 neighbor 2001::2 activate 4140 Example of PE configuration done by the management system (multi- 4141 session): 4143 router bgp 100 4144 neighbor 203.0.113.2 remote-as 65000 4145 neighbor 203.0.113.2 multisession per-af 4146 address-family ipv4 vrf Cust1 4147 neighbor 203.0.113.2 activate 4148 address-family ipv6 vrf Cust1 4149 neighbor 203.0.113.2 activate 4150 neighbor 203.0.113.2 route-map SET-NH-IPV6 out 4152 6.12. Service 4154 The service defines service parameters associated with the site. 4156 6.12.1. Bandwidth 4158 The service bandwidth refers to the bandwidth requirement between the 4159 PE and the CE (WAN link bandwidth). The requested bandwidth is 4160 expressed as svc-input-bandwidth and svc-output-bandwidth in bits per 4161 second. The input/output direction uses the customer site as a 4162 reference: "input bandwidth" means download bandwidth for the site, 4163 and "output bandwidth" means upload bandwidth for the site. 4165 The service bandwidth is only configurable at the site-network-access 4166 level. 4168 Using a different input and output bandwidth will allow the SP to 4169 determine if the customer allows for asymmetric bandwidth access, 4170 such as ADSL. It can also be used to set rate-limiting in a 4171 different way for uploading and downloading on a symmetric bandwidth 4172 access. 4174 The bandwidth is a service bandwidth expressed primarily as IP 4175 bandwidth, but if the customer enables MPLS for Carriers' Carriers 4176 (CsC), this becomes MPLS bandwidth. 4178 6.12.2. MTU 4180 The service MTU refers to the maximum PDU size that the customer may 4181 use. If the customer sends packets which are longer than the 4182 requested service MTU, the network may discard it (or for IPv4, 4183 fragmented). 4185 6.12.3. QoS 4187 The model defines QoS parameters in an abstracted way: 4189 o qos-classification-policy: policy that defines a set of ordered 4190 rules to classify customer traffic. 4192 o qos-profile: QoS scheduling profile to be applied. 4194 6.12.3.1. QoS Classification 4196 QoS classification rules are handled by the "qos-classification- 4197 policy" container. The qos-classification-policy container is an 4198 ordered list of rules that match a flow or application and set the 4199 appropriate target class of service (target-class-id). The user can 4200 define the match using an application reference or a flow definition 4201 that is more specific (e.g., based on Layer 3 source and destination 4202 addresses, Layer 4 ports, and Layer 4 protocol). When a flow 4203 definition is used, the user can employ a "target-sites" leaf-list to 4204 identify the destination of a flow rather than using destination IP 4205 addresses. In such a case, an association between the site 4206 abstraction and the IP addresses used by this site must be done 4207 dynamically. How this association is done is out of scope for this 4208 document. The association of a site to an IP VPN is done through the 4209 "vpn-attachment" container. Therefore the user can also employ 4210 "target-sites" leaf-list and "vpn-attachment" to identify the 4211 destination of a flow targeted to specific vpn service. A rule that 4212 does not have a match statement is considered a match-all rule. An 4213 SP may implement a default terminal classification rule if the 4214 customer does not provide it. It will be up to the SP to determine 4215 its default target class. The current model defines some 4216 applications, but new application identities may be added through 4217 augmentation. The exact meaning of each application identity is up 4218 to the SP, so it will be necessary for the SP to advise the customer 4219 on the usage of application matching. 4221 Where the classification is done depends on the SP's implementation 4222 of the service, but classification concerns the flow coming from the 4223 customer site and entering the network. 4225 Provider network 4226 +-----------------------+ 4227 192.0.2.0/24 4228 198.51.100.0/24 ---- CE --------- PE 4230 Traffic flow 4231 ----------> 4233 In the figure above, the management system should implement the 4234 classification rule: 4236 o in the ingress direction on the PE interface, if the CE is 4237 customer-managed. 4239 o in the ingress direction on the CE interface connected to the 4240 customer LAN, if the CE is provider-managed. 4242 The figure below describes a sample service description of QoS 4243 classification for a site: 4245 4246 4247 4248 4249 VPNA 4250 4252 4253 4254 4255 SITE1 4256 4257 4258 4259 4260 SvrA-http 4261 4262 192.0.2.0/24 4263 203.0.113.1/32 4264 80 4265 tcp 4266 4267 DATA2 4268 4269 4270 SvrA-ftp 4271 4272 192.0.2.0/24 4273 203.0.113.1/32 4274 21 4275 tcp 4276 4277 DATA2 4278 4279 4280 p2p 4281 p2p 4282 DATA3 4283 4284 4285 any 4286 DATA1 4287 4288 4289 4290 4291 4292 4293 4295 In the example above: 4297 o HTTP traffic from the 192.0.2.0/24 LAN destined for 203.0.113.1/32 4298 will be classified in DATA2. 4300 o FTP traffic from the 192.0.2.0/24 LAN destined for 203.0.113.1/32 4301 will be classified in DATA2. 4303 o Peer-to-peer traffic will be classified in DATA3. 4305 o All other traffic will be classified in DATA1. 4307 The order of rule list entries is defined by the user. The 4308 management system responsible for translating those rules in network 4309 element configuration MUST keep the same processing order in network 4310 element configuration. 4312 6.12.3.2. QoS Profile 4314 The user can choose either a standard profile provided by the 4315 operator or a custom profile. The "qos-profile" container defines 4316 the traffic-scheduling policy to be used by the SP. 4318 Provider network 4319 +-----------------------+ 4320 192.0.2.0/24 4321 198.51.100.0/24 ---- CE --------- PE 4322 \ / 4323 qos-profile 4325 A custom QoS profile is defined as a list of classes of services and 4326 associated properties. The properties are: 4328 o direction: used to specify the direction to which the qos profile 4329 is applied. This model supports three direction settings: "Site- 4330 to-WAN", "WAN-to-Site", and "both". By default, the "both" 4331 direction value is used. In case of "both" direction, the 4332 provider should ensure scheduling according to the requested 4333 policy in both traffic directions (SP to customer and customer to 4334 SP). As an example, a device-scheduling policy may be implemented 4335 on both the PE side and the CE side of the WAN link. In case of 4336 "WAN-to-Site" direction, the provider should ensure scheduling 4337 from the SP network to the customer site. As an example, a 4338 device- scheduling policy may be implemented only on the PE side 4339 of the WAN link towards the customer. 4341 o rate-limit: used to rate-limit the class of service. The value is 4342 expressed as a percentage of the global service bandwidth. When 4343 the qos-profile container is implemented on the CE side, svc- 4344 output-bandwidth is taken into account as a reference. When it is 4345 implemented on the PE side, svc-input-bandwidth is used. 4347 o latency: used to define the latency constraint of the class. The 4348 latency constraint can be expressed as the lowest possible latency 4349 or a latency boundary expressed in milliseconds. How this latency 4350 constraint will be fulfilled is up to the SP's implementation of 4351 the service: a strict priority queuing may be used on the access 4352 and in the core network, and/or a low-latency routing 4353 configuration may be created for this traffic class. 4355 o jitter: used to define the jitter constraint of the class. The 4356 jitter constraint can be expressed as the lowest possible jitter 4357 or a jitter boundary expressed in microseconds. How this jitter 4358 constraint will be fulfilled is up to the SP's implementation of 4359 the service: a strict priority queuing may be used on the access 4360 and in the core network, and/or a jitter-aware routing 4361 configuration may be created for this traffic class. 4363 o bandwidth: used to define a guaranteed amount of bandwidth for the 4364 class of service. It is expressed as a percentage. The 4365 "guaranteed-bw-percent" parameter uses available bandwidth as a 4366 reference. When the qos-profile container is implemented on the 4367 CE side, svc-output-bandwidth is taken into account as a 4368 reference. When it is implemented on the PE side, svc-input- 4369 bandwidth is used. By default, the bandwidth reservation is only 4370 guaranteed at the access level. The user can use the "end-to-end" 4371 leaf to request an end-to-end bandwidth reservation, including 4372 across the MPLS transport network. (In other words, the SP will 4373 activate something in the MPLS core to ensure that the bandwidth 4374 request from the customer will be fulfilled by the MPLS core as 4375 well.) How this is done (e.g., RSVP reservation, controller 4376 reservation) is out of scope for this document. 4378 In addition, due to network conditions, some constraints may not be 4379 completely fulfilled by the SP; in this case, the SP should advise 4380 the customer about the limitations. How this communication is done 4381 is out of scope for this document. 4383 Example of service configuration using a standard QoS profile with 4384 the following corresponding XML snippet: 4386 4387 4388 4389 4390 4391 GOLD 4392 4393 4394 PLATINUM 4396 4397 4398 4399 4400 4401 VPNA 4402 4403 4404 4405 4406 SITE1 4407 4408 4409 L1 4410 4411 4412 4413 4414 1245HRTFGJGJ154654 4415 4416 VPNA 4417 spoke-role 4418 4419 4420 4421 provider-dhcp 4422 4423 4424 provider-dhcp 4425 4426 4427 4428 4429 layer3 4430 4431 4432 L1 4433 4434 100000000 4435 100000000 4436 1514 4437 4438 4439 PLATINUM 4440 4441 4442 4443 L1 4445 4446 4447 555555AAAA2344 4448 4449 VPNA 4450 spoke-role 4451 4452 4453 4454 provider-dhcp 4455 4456 4457 provider-dhcp 4458 4459 4460 4461 4462 layer3 4463 4464 4465 L1 4466 4467 2000000 4468 2000000 4469 1514 4470 4471 4472 GOLD 4473 4474 4475 4476 4477 4478 4479 4480 4482 Example of service configuration using a custom QoS profile with the 4483 following corresponding XML snippet: 4485 4486 4487 4488 4489 4490 GOLD 4492 4493 4494 PLATINUM 4495 4496 4497 4498 4499 4500 VPNA 4501 4502 4503 4504 4505 SITE1 4506 4507 4508 L1 4509 4510 4511 4512 4513 Site1 4514 L1 4515 4516 4517 provider-dhcp 4518 4519 4520 provider-dhcp 4521 4522 4523 4524 1514 4525 10000000 4526 10000000 4527 4528 4529 4530 layer3 4531 4532 4533 L1 4534 4535 VPNA 4536 spoke-role 4537 4538 4539 100000000 4540 100000000 4541 4542 4543 4544 4545 REAL_TIME 4546 both 4547 10 4548 4549 4550 4551 4552 80 4553 4554 4555 4556 DATA1 4557 4558 70 4559 4560 4561 80 4562 4563 4564 4565 DATA2 4566 4567 200 4568 4569 4570 5 4571 4572 4573 4574 4575 4576 4577 4578 4579 4580 4581 4582 4584 The custom QoS profile for Site1 defines a REAL_TIME class with a 4585 latency constraint expressed as the lowest possible latency. It also 4586 defines two data classes -- DATA1 and DATA2. The two classes express 4587 a latency boundary constraint as well as a bandwidth reservation, as 4588 the REAL_TIME class is rate-limited to 10% of the service bandwidth 4589 (10% of 100 Mbps = 10 Mbps). In cases where congestion occurs, the 4590 REAL_TIME traffic can go up to 10 Mbps (let's assume that only 5 Mbps 4591 are consumed). DATA1 and DATA2 will share the remaining bandwidth 4592 (95 Mbps) according to their percentage. So, the DATA1 class will be 4593 served with at least 76 Mbps of bandwidth, while the DATA2 class will 4594 be served with at least 4.75 Mbps. The latency boundary information 4595 of the data class may help the SP define a specific buffer tuning or 4596 a specific routing within the network. The maximum percentage to be 4597 used is not limited by this model but MUST be limited by the 4598 management system according to the policies authorized by the SP. 4600 6.12.4. Multicast 4602 The "multicast" container defines the type of site in the customer 4603 multicast service topology: source, receiver, or both. These 4604 parameters will help the management system optimize the multicast 4605 service. Users can also define the type of multicast relationship 4606 with the customer: router (requires a protocol such as PIM), host 4607 (IGMP or MLD), or both. An address family (IPv4, IPv6, or both) can 4608 also be defined. 4610 6.13. Enhanced VPN Features 4612 6.13.1. Carriers' Carriers 4614 In the case of CsC [RFC4364], a customer may want to build an MPLS 4615 service using an IP VPN to carry its traffic. 4617 LAN customer1 4618 | 4619 | 4620 CE1 4621 | 4622 | ------------- 4623 (vrf_cust1) 4624 CE1_ISP1 4625 | ISP1 POP 4626 | MPLS link 4627 | ------------- 4628 | 4629 (vrf ISP1) 4630 PE1 4632 (...) Provider backbone 4634 PE2 4635 (vrf ISP1) 4636 | 4637 | ------------ 4638 | 4639 | MPLS link 4640 | ISP1 POP 4641 CE2_ISP1 4642 (vrf_cust1) 4643 | ------------ 4644 | 4645 CE2 4646 | 4647 LAN customer1 4649 In the figure above, ISP1 resells an IP VPN service but has no core 4650 network infrastructure between its POPs. ISP1 uses an IP VPN as the 4651 core network infrastructure (belonging to another provider) between 4652 its POPs. 4654 In order to support CsC, the VPN service must indicate MPLS support 4655 by setting the "carrierscarrier" leaf to true in the vpn-service 4656 list. The link between CE1_ISP1/PE1 and CE2_ISP1/PE2 must also run 4657 an MPLS signalling protocol. This configuration is done at the site 4658 level. 4660 In the proposed model, LDP or BGP can be used as the MPLS signalling 4661 protocol. In the case of LDP, an IGP routing protocol MUST also be 4662 activated. In the case of BGP signalling, BGP MUST also be 4663 configured as the routing protocol. 4665 If CsC is enabled, the requested "svc-mtu" leaf will refer to the 4666 MPLS MTU and not to the IP MTU. 4668 6.14. External ID References 4670 The service model sometimes refers to external information through 4671 identifiers. As an example, to order a cloud-access to a particular 4672 cloud service provider (CSP), the model uses an identifier to refer 4673 to the targeted CSP. If a customer is directly using this service 4674 model as an API (through REST or NETCONF, for example) to order a 4675 particular service, the SP should provide a list of authorized 4676 identifiers. In the case of cloud-access, the SP will provide the 4677 associated identifiers for each available CSP. The same applies to 4678 other identifiers, such as std-qos-profile, OAM profile-name, and 4679 provider-profile for encryption. 4681 How an SP provides the meanings of those identifiers to the customer 4682 is out of scope for this document. 4684 6.15. Defining NNIs 4686 An autonomous system (AS) is a single network or group of networks 4687 that is controlled by a common system administration group and that 4688 uses a single, clearly defined routing protocol. In some cases, VPNs 4689 need to span different ASes in different geographic areas or span 4690 different SPs. The connection between ASes is established by the SPs 4691 and is seamless to the customer. Examples include 4693 o a partnership between SPs (e.g., carrier, cloud) to extend their 4694 VPN service seamlessly. 4696 o an internal administrative boundary within a single SP (e.g., 4697 backhaul versus core versus data center). 4699 NNIs (network-to-network interfaces) have to be defined to extend the 4700 VPNs across multiple ASes. 4702 [RFC4364] defines multiple flavors of VPN NNI implementations. Each 4703 implementation has pros and cons; this topic is outside the scope of 4704 this document. For example, in an Inter-AS option A, autonomous 4705 system border router (ASBR) peers are connected by multiple 4706 interfaces with at least one of those interfaces spanning the two 4707 ASes while being present in the same VPN. In order for these ASBRs 4708 to signal unlabeled IP prefixes, they associate each interface with a 4709 VPN routing and forwarding (VRF) instance and a Border Gateway 4710 Protocol (BGP) session. As a result, traffic between the back-to- 4711 back VRFs is IP. In this scenario, the VPNs are isolated from each 4712 other, and because the traffic is IP, QoS mechanisms that operate on 4713 IP traffic can be applied to achieve customer service level 4714 agreements (SLAs). 4716 -------- -------------- ----------- 4717 / \ / \ / \ 4718 | Cloud | | | | | 4719 | Provider |-----NNI-----| |----NNI---| Data Center | 4720 | #1 | | | | | 4721 \ / | | \ / 4722 -------- | | ----------- 4723 | | 4724 -------- | My network | ----------- 4725 / \ | | / \ 4726 | Cloud | | | | | 4727 | Provider |-----NNI-----| |---NNI---| L3VPN | 4728 | #2 | | | | Partner | 4729 \ / | | | | 4730 -------- | | | | 4731 \ / | | 4732 -------------- \ / 4733 | ----------- 4734 | 4735 NNI 4736 | 4737 | 4738 ------------------- 4739 / \ 4740 | | 4741 | | 4742 | | 4743 | L3VPN Partner | 4744 | | 4745 \ / 4746 ------------------- 4748 The figure above describes an SP network called "My network" that has 4749 several NNIs. This network uses NNIs to: 4751 o increase its footprint by relying on L3VPN partners. 4753 o connect its own data center services to the customer IP VPN. 4755 o enable the customer to access its private resources located in a 4756 private cloud owned by some CSPs. 4758 6.15.1. Defining an NNI with the Option A Flavor 4760 AS A AS B 4761 ------------------- ------------------- 4762 / \ / \ 4763 | | | | 4764 | ++++++++ Inter-AS link ++++++++ | 4765 | + +_______________+ + | 4766 | + (VRF1)---(VPN1)----(VRF1) + | 4767 | + ASBR + + ASBR + | 4768 | + (VRF2)---(VPN2)----(VRF2) + | 4769 | + +_______________+ + | 4770 | ++++++++ ++++++++ | 4771 | | | | 4772 | | | | 4773 | | | | 4774 | ++++++++ Inter-AS link ++++++++ | 4775 | + +_______________+ + | 4776 | + (VRF1)---(VPN1)----(VRF1) + | 4777 | + ASBR + + ASBR + | 4778 | + (VRF2)---(VPN2)----(VRF2) + | 4779 | + +_______________+ + | 4780 | ++++++++ ++++++++ | 4781 | | | | 4782 | | | | 4783 \ / \ / 4784 ------------------- ------------------- 4786 In option A, the two ASes are connected to each other with physical 4787 links on ASBRs. For resiliency purposes, there may be multiple 4788 physical connections between the ASes. A VPN connection -- physical 4789 or logical (on top of physical) -- is created for each VPN that needs 4790 to cross the AS boundary, thus providing a back-to-back VRF model. 4792 From a service model's perspective, this VPN connection can be seen 4793 as a site. Let's say that AS B wants to extend some VPN connections 4794 for VPN C on AS A. The administrator of AS B can use this service 4795 model to order a site on AS A. All connection scenarios could be 4796 realized using the features of the current model. As an example, the 4797 figure above shows two physical connections that have logical 4798 connections per VPN overlaid on them. This could be seen as a dual- 4799 homed subVPN scenario. Also, the administrator of AS B will be able 4800 to choose the appropriate routing protocol (e.g., E-BGP) to 4801 dynamically exchange routes between ASes. 4803 This document assumes that the option A NNI flavor SHOULD reuse the 4804 existing VPN site modeling. 4806 Example: a customer wants its CSP A to attach its virtual network N 4807 to an existing IP VPN (VPN1) that he has from L3VPN SP B. 4809 CSP A L3VPN SP B 4811 ----------------- ------------------- 4812 / \ / \ 4813 | | | | | 4814 | VM --| ++++++++ NNI ++++++++ |--- VPN1 4815 | | + +_________+ + | Site#1 4816 | |--------(VRF1)---(VPN1)--(VRF1)+ | 4817 | | + ASBR + + ASBR + | 4818 | | + +_________+ + | 4819 | | ++++++++ ++++++++ | 4820 | VM --| | | |--- VPN1 4821 | |Virtual | | | Site#2 4822 | |Network | | | 4823 | VM --| | | |--- VPN1 4824 | | | | | Site#3 4825 \ / \ / 4826 ----------------- ------------------- 4827 | 4828 | 4829 VPN1 4830 Site#4 4832 To create the VPN connectivity, the CSP or the customer may use the 4833 L3VPN service model that SP B exposes. We could consider that, as 4834 the NNI is shared, the physical connection (bearer) between CSP A and 4835 SP B already exists. CSP A may request through a service model the 4836 creation of a new site with a single site-network-access (single- 4837 homing is used in the figure). As a placement constraint, CSP A may 4838 use the existing bearer reference it has from SP A to force the 4839 placement of the VPN NNI on the existing link. The XML snippet below 4840 illustrates a possible configuration request to SP B: 4842 4843 4844 4845 4846 4847 GOLD 4848 4849 4850 PLATINUM 4851 4852 4854 4855 4856 4857 VPN1 4858 4859 4860 4861 4862 CSP_A_attachment 4863 4864 4865 layer3 4866 4867 4868 4869 4870 L1 4871 4872 4873 4874 4875 1 4876 NY 4877 US 4878 4879 4880 site-vpn-flavor-nni 4881 4882 4883 bgp 4884 4885 500 4886 ipv4 4887 4888 4889 4890 4891 4892 CSP_A_VN1 4893 L1 4894 4895 4896 provider-dhcp 4897 4898 4899 provider-dhcp 4900 4901 4902 4903 4904 4905 static-address 4906 4907 4908 203.0.113.1 4909 203.0.113.2 4910 30 4911 4912 4913 4914 4915 450000000 4916 450000000 4917 1514 4918 4919 4920 4921 layer3 4922 4923 4924 4925 VPN1 4926 any-to-any-role 4927 4928 4929 4930 4931 customer-managed 4932 4933 4934 4935 4937 The case described above is different from a scenario using the 4938 cloud-accesses container, as the cloud-access provides a public cloud 4939 access while this example enables access to private resources located 4940 in a CSP network. 4942 6.15.2. Defining an NNI with the Option B Flavor 4943 AS A AS B 4944 ------------------- ------------------- 4945 / \ / \ 4946 | | | | 4947 | ++++++++ Inter-AS link ++++++++ | 4948 | + +_______________+ + | 4949 | + + + + | 4950 | + ASBR +<---MP-BGP---->+ ASBR + | 4951 | + + + + | 4952 | + +_______________+ + | 4953 | ++++++++ ++++++++ | 4954 | | | | 4955 | | | | 4956 | | | | 4957 | ++++++++ Inter-AS link ++++++++ | 4958 | + +_______________+ + | 4959 | + + + + | 4960 | + ASBR +<---MP-BGP---->+ ASBR + | 4961 | + + + + | 4962 | + +_______________+ + | 4963 | ++++++++ ++++++++ | 4964 | | | | 4965 | | | | 4966 \ / \ / 4967 ------------------- ------------------- 4969 In option B, the two ASes are connected to each other with physical 4970 links on ASBRs. For resiliency purposes, there may be multiple 4971 physical connections between the ASes. The VPN "connection" between 4972 ASes is done by exchanging VPN routes through MP-BGP [RFC4760]. 4974 There are multiple flavors of implementations of such an NNI. For 4975 example: 4977 1. The NNI is internal to the provider and is situated between a 4978 backbone and a data center. There is enough trust between the 4979 domains to not filter the VPN routes. So, all the VPN routes are 4980 exchanged. RT filtering may be implemented to save some 4981 unnecessary route states. 4983 2. The NNI is used between providers that agreed to exchange VPN 4984 routes for specific RTs only. Each provider is authorized to use 4985 the RT values from the other provider. 4987 3. The NNI is used between providers that agreed to exchange VPN 4988 routes for specific RTs only. Each provider has its own RT 4989 scheme. So, a customer spanning the two networks will have 4990 different RTs in each network for a particular VPN. 4992 Case 1 does not require any service modeling, as the protocol enables 4993 the dynamic exchange of necessary VPN routes. 4995 Case 2 requires that an RT-filtering policy on ASBRs be maintained. 4996 From a service modeling point of view, it is necessary to agree on 4997 the list of RTs to authorize. 4999 In Case 3, both ASes need to agree on the VPN RT to exchange, as well 5000 as how to map a VPN RT from AS A to the corresponding RT in AS B (and 5001 vice versa). 5003 Those modelings are currently out of scope for this document. 5005 CSP A L3VPN SP B 5007 ----------------- ------------------ 5008 / \ / \ 5009 | | | | | 5010 | VM --| ++++++++ NNI ++++++++ |--- VPN1 5011 | | + +__________+ + | Site#1 5012 | |-------+ + + + | 5013 | | + ASBR +<-MP-BGP->+ ASBR + | 5014 | | + +__________+ + | 5015 | | ++++++++ ++++++++ | 5016 | VM --| | | |--- VPN1 5017 | |Virtual | | | Site#2 5018 | |Network | | | 5019 | VM --| | | |--- VPN1 5020 | | | | | Site#3 5021 \ / | | 5022 ----------------- | | 5023 \ / 5024 ------------------ 5025 | 5026 | 5027 VPN1 5028 Site#4 5030 The example above describes an NNI connection between CSP A and SP 5031 network B. Both SPs do not trust themselves and use a different RT 5032 allocation policy. So, in terms of implementation, the customer VPN 5033 has a different RT in each network (RT A in CSP A and RT B in SP 5034 network B). In order to connect the customer virtual network in CSP 5035 A to the customer IP VPN (VPN1) in SP network B, CSP A should request 5036 that SP network B open the customer VPN on the NNI (accept the 5037 appropriate RT). Who does the RT translation depends on the 5038 agreement between the two SPs: SP B may permit CSP A to request VPN 5039 (RT) translation. 5041 6.15.3. Defining an NNI with the Option C Flavor 5043 AS A AS B 5044 ------------------- ------------------- 5045 / \ / \ 5046 | | | | 5047 | | | | 5048 | | | | 5049 | ++++++++ Multihop E-BGP ++++++++ | 5050 | + + + + | 5051 | + + + + | 5052 | + RGW +<----MP-BGP---->+ RGW + | 5053 | + + + + | 5054 | + + + + | 5055 | ++++++++ ++++++++ | 5056 | | | | 5057 | | | | 5058 | | | | 5059 | | | | 5060 | | | | 5061 | ++++++++ Inter-AS link ++++++++ | 5062 | + +_______________+ + | 5063 | + + + + | 5064 | + ASBR + + ASBR + | 5065 | + + + + | 5066 | + +_______________+ + | 5067 | ++++++++ ++++++++ | 5068 | | | | 5069 | | | | 5070 | | | | 5071 | ++++++++ Inter-AS link ++++++++ | 5072 | + +_______________+ + | 5073 | + + + + | 5074 | + ASBR + + ASBR + | 5075 | + + + + | 5076 | + +_______________+ + | 5077 | ++++++++ ++++++++ | 5078 | | | | 5079 | | | | 5080 \ / \ / 5081 ------------------- ------------------- 5083 From a VPN service's perspective, the option C NNI is very similar to 5084 option B, as an MP-BGP session is used to exchange VPN routes between 5085 the ASes. The difference is that the forwarding plane and the 5086 control plane are on different nodes, so the MP-BGP session is 5087 multihop between routing gateway (RGW) nodes. 5089 From a VPN service's point of view, modeling options B and C will be 5090 identical. 5092 7. Service Model Usage Example 5094 As explained in Section 5, this service model is intended to be 5095 instantiated at a management layer and is not intended to be used 5096 directly on network elements. The management system serves as a 5097 central point of configuration of the overall service. 5099 This section provides an example of how a management system can use 5100 this model to configure an IP VPN service on network elements. 5102 In this example, we want to achieve the provisioning of a VPN service 5103 for three sites using a Hub-and-Spoke VPN service topology. One of 5104 the sites will be dual-homed, and load-sharing is expected. 5106 +-------------------------------------------------------------+ 5107 | Hub_Site ------ PE1 PE2 ------ Spoke_Site1 | 5108 | | +----------------------------------+ 5109 | | | 5110 | | +----------------------------------+ 5111 | Hub_Site ------ PE3 PE4 ------ Spoke_Site2 | 5112 +-------------------------------------------------------------+ 5114 The following XML snippet describes the overall simplified service 5115 configuration of this VPN. 5117 5118 5119 5120 5121 5122 GOLD 5123 5124 5125 PLATINUM 5126 5127 5128 5129 5130 5131 12456487 5132 hub-spoke 5133 5134 5135 5137 When receiving the request for provisioning the VPN service, the 5138 management system will internally (or through communication with 5139 another OSS component) allocate VPN RTs. In this specific case, two 5140 RTs will be allocated (100:1 for Hub and 100:2 for Spoke). The 5141 output of corresponding XML snippet below describes the configuration 5142 of Spoke_Site1. 5144 5145 5146 5147 5148 5149 GOLD 5150 5151 5152 PLATINUM 5153 5154 5155 5156 5157 5158 12456487 5159 hub-spoke 5160 5161 5162 5163 5164 Spoke_Site1 5165 5166 5167 D1 5168 5169 5170 5171 5172 1 5173 NY 5174 US 5175 5176 5177 5178 5179 layer3 5180 5181 5182 5183 5184 bgp 5185 5186 500 5187 ipv4 5188 ipv6 5189 5190 5191 5192 5193 5194 Spoke_Site1 5195 D1 5196 5197 5198 5199 20 5200 5201 5202 5203 5204 pe-diverse 5205 5206 5207 10 5208 5209 5210 5211 5213 5214 5215 5216 5217 static-address 5218 5219 5220 203.0.113.254 5221 203.0.113.2 5222 24 5223 5224 5225 5226 5227 static-address 5228 5229 5230 2001:db8::1 5231 2001:db8::2 5232 64 5233 5234 5235 5236 5237 450000000 5238 450000000 5239 1514 5240 5241 5242 5243 layer3 5244 5245 5246 5247 12456487 5248 spoke-role 5249 5250 5251 5252 5253 provider-managed 5254 5255 5256 5257 5258 When receiving the request for provisioning Spoke_Site1, the 5259 management system MUST allocate network resources for this site. It 5260 MUST first determine the target network elements to provision the 5261 access, particularly the PE router (and perhaps also an aggregation 5262 switch). As described in Section 6.6, the management system SHOULD 5263 use the location information and MUST use the access-diversity 5264 constraint to find the appropriate PE. In this case, we consider 5265 that Spoke_Site1 requires PE diversity with the Hub and that the 5266 management system allocates PEs based on the least distance. Based 5267 on the location information, the management system finds the 5268 available PEs in the area nearest the customer and picks one that 5269 fits the access-diversity constraint. 5271 When the PE is chosen, the management system needs to allocate 5272 interface resources on the node. One interface is selected from the 5273 pool of available PEs. The management system can start provisioning 5274 the chosen PE node via whatever means the management system prefers 5275 (e.g., NETCONF, CLI). The management system will check to see if a 5276 VRF that fits its needs is already present. If not, it will 5277 provision the VRF: the RD will be derived from the internal 5278 allocation policy model, and the RTs will be derived from the VPN 5279 policy configuration of the site (the management system allocated 5280 some RTs for the VPN). As the site is a Spoke site (site-role), the 5281 management system knows which RTs must be imported and exported. As 5282 the site is provider-managed, some management RTs may also be added 5283 (100:5000). Standard provider VPN policies MAY also be added in the 5284 configuration. 5286 Example of generated PE configuration: 5288 ip vrf Customer1 5289 export-map STD-CUSTOMER-EXPORT <---- Standard SP configuration 5290 route-distinguisher 100:3123234324 5291 route-target import 100:1 5292 route-target import 100:5000 <---- Standard SP configuration 5293 route-target export 100:2 for provider-managed CE 5294 ! 5296 When the VRF has been provisioned, the management system can start 5297 configuring the access on the PE using the allocated interface 5298 information. IP addressing is chosen by the management system. One 5299 address will be picked from an allocated subnet for the PE, and 5300 another will be used for the CE configuration. Routing protocols 5301 will also be configured between the PE and CE; because this model is 5302 provider-managed, the choices are left to the SP. BGP was chosen for 5303 this example. This choice is independent of the routing protocol 5304 chosen by the customer. BGP will be used to configure the CE-to-LAN 5305 connection as requested in the service model. Peering addresses will 5306 be derived from those of the connection. As the CE is provider- 5307 managed, the CE's AS number can be automatically allocated by the 5308 management system. Standard configuration templates provided by the 5309 SP may also be added. 5311 Example of generated PE configuration: 5313 interface Ethernet1/1/0.10 5314 encapsulation dot1q 10 5315 ip vrf forwarding Customer1 5316 ip address 198.51.100.1 255.255.255.252 <---- Comes from 5317 automated allocation 5318 ipv6 address 2001:db8::10:1/64 5319 ip access-group STD-PROTECT-IN <---- Standard SP config 5320 ! 5321 router bgp 100 5322 address-family ipv4 vrf Customer1 5323 neighbor 198.51.100.2 remote-as 65000 <---- Comes from 5324 automated allocation 5325 neighbor 198.51.100.2 route-map STD in <---- Standard SP config 5326 neighbor 198.51.100.2 filter-list 10 in <---- Standard SP config 5327 ! 5328 address-family ipv6 vrf Customer1 5329 neighbor 2001:db8::0a10:2 remote-as 65000 <---- Comes from 5330 automated allocation 5331 neighbor 2001:db8::0a10:2 route-map STD in <---- Standard SP 5332 config 5333 neighbor 2001:db8::0a10:2 filter-list 10 in <---- Standard SP 5334 config 5335 ! 5336 ip route vrf Customer1 192.0.2.1 255.255.255.255 198.51.100.2 5337 ! Static route for provider administration of CE 5338 ! 5340 As the CE router is not reachable at this stage, the management 5341 system can produce a complete CE configuration that can be manually 5342 uploaded to the node before sending the CE configuration to the 5343 customer premises. The CE configuration will be built in the same 5344 way as the PE would be configured. Based on the CE type (vendor/ 5345 model) allocated to the customer as well as the bearer information, 5346 the management system knows which interface must be configured on the 5347 CE. PE-CE link configuration is expected to be handled automatically 5348 using the SP OSS, as both resources are managed internally. CE-to- 5349 LAN-interface parameters such as IP addressing are derived from the 5350 ip-connection container, taking into account how the management 5351 system distributes addresses between the PE and CE within the subnet. 5353 This will allow a plug-and-play configuration for the CE to be 5354 created. 5356 Example of generated CE configuration: 5358 interface Loopback10 5359 description "Administration" 5360 ip address 192.0.2.1 255.255.255.255 5361 ! 5362 interface FastEthernet10 5363 description "WAN" 5364 ip address 198.51.100.2 255.255.255.252 <---- Comes from 5365 automated allocation 5366 ipv6 address 2001:db8::0a10:2/64 5367 ! 5368 interface FastEthernet11 5369 description "LAN" 5370 ip address 203.0.113.254 255.255.255.0 <---- Comes from the 5371 ip-connection container 5372 ipv6 address 2001:db8::1/64 5373 ! 5374 router bgp 65000 5375 address-family ipv4 5376 redistribute static route-map STATIC2BGP <---- Standard SP 5377 configuration 5378 neighbor 198.51.100.1 remote-as 100 <---- Comes from 5379 automated allocation 5380 neighbor 203.0.113.2 remote-as 500 <---- Comes from the 5381 ip-connection container 5382 address-family ipv6 5383 redistribute static route-map STATIC2BGP <---- Standard SP 5384 configuration 5385 neighbor 2001:db8::0a10:1 remote-as 100 <---- Comes from 5386 automated allocation 5387 neighbor 2001:db8::2 remote-as 500 <---- Comes from the 5388 ip-connection container 5389 ! 5390 route-map STATIC2BGP permit 10 5391 match tag 10 5392 ! 5394 8. Interaction with Other YANG Modules 5396 As expressed in Section 5, this service model is intended to be 5397 instantiated in a management system and not directly on network 5398 elements. 5400 The management system's role will be to configure the network 5401 elements. The management system may be modular, so the component 5402 instantiating the service model (let's call it "service component") 5403 and the component responsible for network element configuration 5404 (let's call it "configuration component") may be different. 5406 l3vpn-svc | 5407 Model | 5408 | 5409 +---------------------+ 5410 | Service component | Service datastore 5411 +---------------------+ 5412 | 5413 | 5414 +---------------------+ 5415 +----| Config component |------+ 5416 / +---------------------+ \ Network 5417 / / \ \ Configuration 5418 / / \ \ models 5419 / / \ \ 5420 ++++++++ ++++++++ ++++++++ ++++++++ 5421 + CE A + ------- + PE A + + PE B + ----- + CE B + Config 5422 ++++++++ ++++++++ ++++++++ ++++++++ datastore 5424 Site A Site B 5426 In the previous sections, we provided some examples of the 5427 translation of service provisioning requests to router configuration 5428 lines. In the NETCONF/YANG ecosystem, we expect NETCONF/YANG to be 5429 used between the configuration component and network elements to 5430 configure the requested services on those elements. 5432 In this framework, specifications are expected to provide specific 5433 YANG modeling of service components on network elements. There will 5434 be a strong relationship between the abstracted view provided by this 5435 service model and the detailed configuration view that will be 5436 provided by specific configuration models for network elements. 5438 The authors of this document anticipate definitions of YANG models 5439 for the network elements listed below. Note that this list is not 5440 exhaustive: 5442 o VRF definition, including VPN policy expression. 5444 o Physical interface. 5446 o IP layer (IPv4, IPv6). 5448 o QoS: classification, profiles, etc. 5450 o Routing protocols: support of configuration of all protocols 5451 listed in the document, as well as routing policies associated 5452 with those protocols. 5454 o Multicast VPN. 5456 o Network address translation. 5458 Example of a corresponding XML snippet with a VPN site request at the 5459 service level, using this model: 5461 5462 5463 5464 5465 5466 GOLD 5467 5468 5469 PLATINUM 5470 5471 5472 5473 5474 5475 VPN1 5476 hub-spoke 5477 5478 5479 5480 5481 Site A 5482 5483 5484 layer3 5485 5486 5487 5488 5489 L1 5490 5491 5492 5493 5494 1 5495 5496 5497 5498 static-address 5499 5500 5501 203.0.113.254 5502 203.0.113.2 5503 24 5504 5505 5506 5507 provider-dhcp 5508 5509 5510 5511 1514 5512 10000000 5513 10000000 5514 5515 L1 5516 5517 VPNPOL1 5518 5519 5520 5521 5522 5523 static 5524 5525 5526 5527 198.51.100.0/30 5528 203.0.113.2 5529 5530 5531 5532 5533 5534 5535 customer-managed 5536 5537 5538 5539 VPNPOL1 5540 5541 1 5542 5543 VPN1 5544 any-to-any-role 5545 5546 5547 5548 5549 5550 5551 5553 In the service example above, the service component is expected to 5554 request that the configuration component of the management system 5555 provide the configuration of the service elements. If we consider 5556 that the service component selected a PE (PE A) as the target PE for 5557 the site, the configuration component will need to push the 5558 configuration to PE A. The configuration component will use several 5559 YANG data models to define the configuration to be applied to PE A. 5560 The XML snippet configuration of PE A might look like this: 5562 5563 5564 eth0 5565 ianaift:ethernetCsmacd 5566 5567 Link to CE A. 5568 5569 5570 5571 203.0.113.254 5572 24 5573 5574 true 5575 5576 5577 5578 5579 5580 VRF_CustA 5581 l3vpn-network:vrf 5582 VRF for Customer A 5583 5584 100:1546542343 5585 5586 100:1 5587 100:1 5588 5589 5590 eth0 5592 5593 5594 5595 5596 rt:static 5597 st0 5598 5599 5600 5601 5602 198.51.100.0/30 5603 5604 5605 5606 203.0.113.2 5607 5608 5609 5610 5611 5612 5613 5614 5615 5617 9. YANG Module 5619 file "ietf-l3vpn-svc@2017-10-11.yang" 5620 module ietf-l3vpn-svc { 5621 yang-version 1.1; 5622 namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc"; 5623 prefix l3vpn-svc; 5624 import ietf-inet-types { 5625 prefix inet; 5626 } 5627 import ietf-yang-types { 5628 prefix yang; 5629 } 5630 import ietf-netconf-acm { 5631 prefix nacm; 5632 } 5633 organization 5634 "IETF L3SM Working Group"; 5635 contact 5636 "WG List: 5637 Editor: 5638 L3SM WG 5640 Chairs: 5641 Adrian Farrel, Qin Wu 5642 "; 5643 description 5644 "This YANG module defines a generic service configuration 5645 model for Layer 3 VPNs. This model is common across all 5646 vendor implementations."; 5647 revision 2017-10-11 { 5648 description 5649 "First revision of RFC8049."; 5650 reference 5651 "RFC xxxx: YANG Data Model for L3VPN Service Delivery"; 5652 } 5653 /* Features */ 5654 feature cloud-access { 5655 description 5656 "Allows the VPN to connect to a CSP."; 5657 } 5658 feature multicast { 5659 description 5660 "Enables multicast capabilities in a VPN."; 5661 } 5662 feature ipv4 { 5663 description 5664 "Enables IPv4 support in a VPN."; 5665 } 5666 feature ipv6 { 5667 description 5668 "Enables IPv6 support in a VPN."; 5669 } 5670 feature lan-tag { 5671 description 5672 "Enables LAN Tag support in a VPN Policy Filter."; 5673 } 5674 feature carrierscarrier { 5675 description 5676 "Enables support of CsC."; 5677 } 5678 feature extranet-vpn { 5679 description 5680 "Enables support of extranet VPNs."; 5681 } 5682 feature site-diversity { 5683 description 5684 "Enables support of site diversity constraints."; 5685 } 5686 feature encryption { 5687 description 5688 "Enables support of encryption."; 5689 } 5690 feature qos { 5691 description 5692 "Enables support of classes of services."; 5693 } 5694 feature qos-custom { 5696 description 5697 "Enables support of the custom QoS profile."; 5698 } 5699 feature rtg-bgp { 5700 description 5701 "Enables support of the BGP routing protocol."; 5702 } 5703 feature rtg-rip { 5704 description 5705 "Enables support of the RIP routing protocol."; 5706 } 5707 feature rtg-ospf { 5708 description 5709 "Enables support of the OSPF routing protocol."; 5710 } 5711 feature rtg-ospf-sham-link { 5712 description 5713 "Enables support of OSPF sham links."; 5714 } 5715 feature rtg-vrrp { 5716 description 5717 "Enables support of the VRRP routing protocol."; 5718 } 5719 feature fast-reroute { 5720 description 5721 "Enables support of Fast Reroute."; 5722 } 5723 feature bfd { 5724 description 5725 "Enables support of BFD."; 5726 } 5727 feature always-on { 5728 description 5729 "Enables support of the 'always-on' access constraint."; 5730 } 5731 feature requested-type { 5732 description 5733 "Enables support of the 'requested-type' access constraint."; 5734 } 5735 feature bearer-reference { 5736 description 5737 "Enables support of the 'bearer-reference' access constraint."; 5738 } 5739 feature target-sites { 5740 description 5741 "Enables support of the 'target-sites' match flow parameter."; 5742 } 5743 /* Typedefs */ 5744 typedef svc-id { 5745 type string; 5746 description 5747 "Defines a type of service component identifier."; 5748 } 5749 typedef template-id { 5750 type string; 5751 description 5752 "Defines a type of service template identifier."; 5753 } 5754 typedef address-family { 5755 type enumeration { 5756 enum ipv4 { 5757 description 5758 "IPv4 address family."; 5759 } 5760 enum ipv6 { 5761 description 5762 "IPv6 address family."; 5763 } 5764 } 5765 description 5766 "Defines a type for the address family."; 5767 } 5768 /* Identities */ 5769 identity site-network-access-type { 5770 description 5771 "Base identity for site-network-access type."; 5772 } 5773 identity point-to-point { 5774 base site-network-access-type; 5775 description 5776 "Identity for point-to-point connection."; 5777 } 5778 identity multipoint { 5779 base site-network-access-type; 5780 description 5781 "Identity for multipoint connection. 5782 Example: Ethernet broadcast segment."; 5783 } 5784 identity placement-diversity { 5785 description 5786 "Base identity for site placement constraints."; 5787 } 5788 identity bearer-diverse { 5789 base placement-diversity; 5790 description 5791 "Identity for bearer diversity. 5792 The bearers should not use common elements."; 5793 } 5794 identity pe-diverse { 5795 base placement-diversity; 5796 description 5797 "Identity for PE diversity."; 5798 } 5799 identity pop-diverse { 5800 base placement-diversity; 5801 description 5802 "Identity for POP diversity."; 5803 } 5804 identity linecard-diverse { 5805 base placement-diversity; 5806 description 5807 "Identity for linecard diversity."; 5808 } 5809 identity same-pe { 5810 base placement-diversity; 5811 description 5812 "Identity for having sites connected on the same PE."; 5813 } 5814 identity same-bearer { 5815 base placement-diversity; 5816 description 5817 "Identity for having sites connected using the same bearer."; 5818 } 5819 identity customer-application { 5820 description 5821 "Base identity for customer application."; 5822 } 5823 identity web { 5824 base customer-application; 5825 description 5826 "Identity for Web application (e.g., HTTP, HTTPS)."; 5827 } 5828 identity mail { 5829 base customer-application; 5830 description 5831 "Identity for mail application."; 5833 } 5834 identity file-transfer { 5835 base customer-application; 5836 description 5837 "Identity for file transfer application (e.g., FTP, SFTP)."; 5838 } 5839 identity database { 5840 base customer-application; 5842 description 5843 "Identity for database application."; 5844 } 5845 identity social { 5846 base customer-application; 5847 description 5848 "Identity for social-network application."; 5849 } 5850 identity games { 5851 base customer-application; 5852 description 5853 "Identity for gaming application."; 5854 } 5855 identity p2p { 5856 base customer-application; 5857 description 5858 "Identity for peer-to-peer application."; 5859 } 5860 identity network-management { 5861 base customer-application; 5862 description 5863 "Identity for management application 5864 (e.g., Telnet, syslog, SNMP)."; 5865 } 5866 identity voice { 5867 base customer-application; 5868 description 5869 "Identity for voice application."; 5870 } 5871 identity video { 5872 base customer-application; 5873 description 5874 "Identity for video conference application."; 5875 } 5876 identity embb { 5877 base customer-application; 5878 description 5879 "Identity for enhanced Mobile Broadband(eMBB) 5880 application. Note that eMBB application demands 5881 the network performance with wide variety of 5882 characteristics such as data rate, latency, 5883 loss rate, reliability and many other parameters."; 5884 } 5885 identity urllc { 5886 base customer-application; 5887 description 5888 "Identity for Ultra-Reliable and Low Latency 5889 Communications (URLLC) application. Note that 5890 URLLC application demands the network performance 5891 with wide variety of characteristics such as latency, 5892 reliability and many other parameters."; 5893 } 5894 identity mmtc { 5895 base customer-application; 5896 description 5897 "Identity for massive Machine Type 5898 Communications (mMTC) application. Note that 5899 mMTC application demands the network performance 5900 with wide variety of characteristics such as data 5901 rate, latency, loss rate, reliability and many 5902 other parameters."; 5903 } 5904 identity site-vpn-flavor { 5905 description 5906 "Base identity for the site VPN service flavor."; 5907 } 5908 identity site-vpn-flavor-single { 5909 base site-vpn-flavor; 5910 description 5911 "Base identity for the site VPN service flavor. 5912 Used when the site belongs to only one VPN."; 5913 } 5914 identity site-vpn-flavor-multi { 5915 base site-vpn-flavor; 5916 description 5917 "Base identity for the site VPN service flavor. 5918 Used when a logical connection of a site 5919 belongs to multiple VPNs."; 5920 } 5921 identity site-vpn-flavor-sub { 5922 base site-vpn-flavor; 5923 description 5924 "Base identity for the site VPN service flavor. 5925 Used when a site has multiple logical connections. 5926 Each connection may belong to different multiple VPNs."; 5927 } 5928 identity site-vpn-flavor-nni { 5929 base site-vpn-flavor; 5930 description 5931 "Base identity for the site VPN service flavor. 5932 Used to describe an NNI option A connection."; 5933 } 5934 identity management { 5935 description 5936 "Base identity for site management scheme."; 5937 } 5938 identity co-managed { 5939 base management; 5940 description 5941 "Base identity for co-managed site."; 5942 } 5943 identity customer-managed { 5944 base management; 5945 description 5946 "Base identity for customer-managed site."; 5947 } 5948 identity provider-managed { 5949 base management; 5950 description 5951 "Base identity for provider-managed site."; 5952 } 5953 identity address-allocation-type { 5954 description 5955 "Base identity for address-allocation-type for PE-CE link."; 5956 } 5957 identity provider-dhcp { 5958 base address-allocation-type; 5959 description 5960 "Provider network provides DHCP service to customer."; 5961 } 5962 identity provider-dhcp-relay { 5963 base address-allocation-type; 5964 description 5965 "Provider network provides DHCP relay service to customer."; 5967 } 5968 identity provider-dhcp-slaac { 5969 base address-allocation-type; 5970 description 5971 "Provider network provides DHCP service to customer, 5972 as well as SLAAC."; 5973 } 5974 identity static-address { 5975 base address-allocation-type; 5976 description 5977 "Provider-to-customer addressing is static."; 5978 } 5979 identity slaac { 5980 base address-allocation-type; 5981 description 5982 "Use IPv6 SLAAC."; 5983 } 5984 identity site-role { 5985 description 5986 "Base identity for site type."; 5987 } 5988 identity any-to-any-role { 5989 base site-role; 5990 description 5991 "Site in an any-to-any IP VPN."; 5992 } 5993 identity spoke-role { 5994 base site-role; 5995 description 5996 "Spoke site in a Hub-and-Spoke IP VPN."; 5997 } 5998 identity hub-role { 5999 base site-role; 6000 description 6001 "Hub site in a Hub-and-Spoke IP VPN."; 6002 } 6003 identity vpn-topology { 6004 description 6005 "Base identity for VPN topology."; 6006 } 6007 identity any-to-any { 6008 base vpn-topology; 6009 description 6010 "Identity for any-to-any VPN topology."; 6011 } 6012 identity hub-spoke { 6013 base vpn-topology; 6014 description 6016 "Identity for Hub-and-Spoke VPN topology."; 6017 } 6018 identity hub-spoke-disjoint { 6019 base vpn-topology; 6020 description 6021 "Identity for Hub-and-Spoke VPN topology 6022 where Hubs cannot communicate with each other."; 6023 } 6024 identity multicast-tree-type { 6025 description 6026 "Base identity for multicast tree type."; 6027 } 6028 identity ssm-tree-type { 6029 base multicast-tree-type; 6030 description 6031 "Identity for SSM tree type."; 6032 } 6033 identity asm-tree-type { 6034 base multicast-tree-type; 6035 description 6036 "Identity for ASM tree type."; 6037 } 6038 identity bidir-tree-type { 6039 base multicast-tree-type; 6040 description 6041 "Identity for bidirectional tree type."; 6042 } 6043 identity multicast-rp-discovery-type { 6044 description 6045 "Base identity for RP discovery type."; 6046 } 6047 identity auto-rp { 6048 base multicast-rp-discovery-type; 6049 description 6050 "Base identity for Auto-RP discovery type."; 6051 } 6052 identity static-rp { 6053 base multicast-rp-discovery-type; 6054 description 6055 "Base identity for static type."; 6056 } 6057 identity bsr-rp { 6058 base multicast-rp-discovery-type; 6059 description 6060 "Base identity for BSR discovery type."; 6061 } 6062 identity routing-protocol-type { 6063 description 6065 "Base identity for routing protocol type."; 6066 } 6067 identity ospf { 6068 base routing-protocol-type; 6069 description 6070 "Identity for OSPF protocol type."; 6071 } 6072 identity bgp { 6073 base routing-protocol-type; 6074 description 6075 "Identity for BGP protocol type."; 6076 } 6077 identity static { 6078 base routing-protocol-type; 6079 description 6080 "Identity for static routing protocol type."; 6081 } 6082 identity rip { 6083 base routing-protocol-type; 6084 description 6085 "Identity for RIP protocol type."; 6086 } 6087 identity vrrp { 6088 base routing-protocol-type; 6089 description 6090 "Identity for VRRP protocol type. 6091 This is to be used when LANs are directly connected 6092 to PE routers."; 6093 } 6094 identity direct { 6095 base routing-protocol-type; 6096 description 6097 "Identity for direct protocol type."; 6098 } 6099 identity protocol-type { 6100 description 6101 "Base identity for protocol field type."; 6102 } 6103 identity tcp { 6104 base protocol-type; 6105 description 6106 "TCP protocol type."; 6107 } 6108 identity udp { 6109 base protocol-type; 6110 description 6111 "UDP protocol type."; 6112 } 6114 identity icmp { 6115 base protocol-type; 6116 description 6117 "ICMP protocol type."; 6118 } 6119 identity icmp6 { 6120 base protocol-type; 6121 description 6122 "ICMPv6 protocol type."; 6123 } 6124 identity gre { 6125 base protocol-type; 6126 description 6127 "GRE protocol type."; 6128 } 6129 identity ipip { 6130 base protocol-type; 6131 description 6132 "IP-in-IP protocol type."; 6133 } 6134 identity hop-by-hop { 6135 base protocol-type; 6136 description 6137 "Hop-by-Hop IPv6 header type."; 6138 } 6139 identity routing { 6140 base protocol-type; 6141 description 6142 "Routing IPv6 header type."; 6143 } 6144 identity esp { 6145 base protocol-type; 6146 description 6147 "ESP header type."; 6148 } 6149 identity ah { 6150 base protocol-type; 6151 description 6152 "AH header type."; 6153 } 6154 identity vpn-policy-filter-type { 6155 description 6156 "Base identity for VPN Policy filter type."; 6157 } 6158 identity ipv4 { 6159 base vpn-policy-filter-type; 6160 description 6161 "Identity for ipv4 prefix filter type."; 6163 } 6164 identity ipv6 { 6165 base vpn-policy-filter-type; 6166 description 6167 "Identity for ipv6 prefix filter type."; 6168 } 6169 identity lan { 6170 base vpn-policy-filter-type; 6171 description 6172 "Identity for lan tag filter type."; 6173 } 6175 identity qos-profile-direction { 6176 description 6177 "Base identity for qos profile direction."; 6178 } 6180 identity site-to-wan { 6181 base qos-profile-direction; 6182 description 6183 "Identity for Site to WAN direction."; 6185 } 6186 identity wan-to-site { 6187 base qos-profile-direction; 6188 description 6189 "Identity for WAN to Site direction."; 6190 } 6191 identity both { 6192 base qos-profile-direction; 6193 description 6194 "Identity for both WAN to Site direction and Site to WAN direction."; 6195 } 6196 /* Groupings */ 6197 grouping vpn-service-cloud-access { 6198 container cloud-accesses { 6199 if-feature cloud-access; 6200 list cloud-access { 6201 key cloud-identifier; 6202 leaf cloud-identifier { 6203 type leafref { 6204 path "/l3vpn-svc/vpn-profiles/valid-provider-identifiers/"+ 6205 "cloud-identifier/id"; 6206 } 6207 description 6208 "Identification of cloud service. 6209 Local administration meaning."; 6210 } 6211 choice list-flavor { 6212 case permit-any { 6213 leaf permit-any { 6214 type empty; 6215 description 6216 "Allows all sites."; 6218 } 6219 } 6220 case deny-any-except { 6221 leaf-list permit-site { 6222 type leafref { 6223 path "/l3vpn-svc/sites/site/site-id"; 6224 } 6225 description 6226 "Site ID to be authorized."; 6227 } 6228 } 6229 case permit-any-except { 6230 leaf-list deny-site { 6231 type leafref { 6232 path "/l3vpn-svc/sites/site/site-id"; 6233 } 6234 description 6235 "Site ID to be denied."; 6236 } 6237 } 6238 description 6239 "Choice for cloud access policy. By default, all sites in the IP 6240 VPN MUST be authorized to access the cloud."; 6241 } 6242 container address-translation { 6243 container nat44 { 6244 leaf enabled { 6245 type boolean; 6246 default false; 6247 description 6248 "Controls whether or not Network address 6249 translation from IPv4 to IPv4 (NAT44) 6250 [RFC3022]is required."; 6251 } 6252 leaf nat44-customer-address { 6253 type inet:ipv4-address; 6254 description 6255 "Address to be used for network address 6256 translation from IPv4 to IPv4. This is 6257 to be used if the customer is providing 6258 the IPv4 address. If customer address 6259 is not set, the model assumes that the 6260 provider will allocate the address."; 6261 } 6262 description 6263 "IPv4-to-IPv4 translation."; 6264 } 6265 description 6266 "Container for NAT."; 6268 } 6269 description 6270 "Cloud access configuration."; 6271 } 6272 description 6273 "Container for cloud access configurations."; 6274 } 6275 description 6276 "Grouping for VPN cloud definition."; 6277 } 6278 grouping multicast-rp-group-cfg { 6279 choice group-format { 6280 mandatory true; 6281 case singleaddress { 6282 leaf group-address { 6283 type inet:ip-address; 6285 description 6286 "A Single Multicast Group address."; 6287 } 6288 } 6289 case startend { 6290 leaf group-start { 6291 type inet:ip-address; 6292 description 6293 "The first Multicast group address in 6294 the multicast group address range."; 6295 } 6296 leaf group-end { 6297 type inet:ip-address; 6298 description 6299 "The last Multicast group address in 6300 the multicast group address range."; 6301 } 6302 } 6303 description 6304 "Choice for Multicast group format."; 6305 } 6306 description 6307 "This Grouping defines Multicast Group or 6308 Multicast Groups for RP-to-group mapping."; 6309 } 6310 grouping vpn-service-multicast { 6311 container multicast { 6312 if-feature multicast; 6313 leaf enabled { 6314 type boolean; 6315 default false; 6317 description 6318 "Enables multicast."; 6319 } 6320 container customer-tree-flavors { 6321 leaf-list tree-flavor { 6322 type identityref { 6323 base multicast-tree-type; 6324 } 6325 description 6326 "Type of tree to be used."; 6327 } 6328 description 6329 "Type of trees used by customer."; 6330 } 6331 container rp { 6332 container rp-group-mappings { 6333 list rp-group-mapping { 6335 key id; 6336 leaf id { 6337 type uint16; 6338 description 6339 "Unique identifier for the mapping."; 6340 } 6341 container provider-managed { 6342 leaf enabled { 6343 type boolean; 6344 default false; 6345 description 6346 "Set to true if the Rendezvous Point (RP) 6347 must be a provider-managed node. Set to false 6348 if it is a customer-managed node."; 6349 } 6350 leaf rp-redundancy { 6351 type boolean; 6352 default false; 6353 description 6354 "If true, a redundancy mechanism for the RP 6355 is required."; 6356 } 6357 leaf optimal-traffic-delivery { 6358 type boolean; 6359 default false; 6360 description 6361 "If true, the SP must ensure that 6362 traffic uses an optimal path, an SP may use 6363 Anycast RP or RP tree to SPT switchover 6364 architectures."; 6366 } 6367 description 6368 "Parameters for a provider-managed RP."; 6369 } 6370 leaf rp-address { 6371 when "../provider-managed/enabled = 'false'" { 6372 description 6373 "Relevant when the RP is not provider-managed."; 6374 } 6375 type inet:ip-address; 6376 mandatory true; 6377 description 6378 "Defines the address of the RP. 6379 Used if the RP is customer-managed."; 6380 } 6381 container groups { 6382 list group { 6383 key id; 6385 leaf id { 6386 type uint16; 6387 description 6388 "Identifier for the group."; 6389 } 6390 uses multicast-rp-group-cfg; 6391 description 6392 "List of Multicast groups."; 6393 } 6394 description 6395 "Multicast groups associated with the RP."; 6396 } 6397 description 6398 "List of RP to group mappings."; 6399 } 6400 description 6401 "RP to group mappings parameters."; 6402 } 6403 container rp-discovery { 6404 leaf rp-discovery-type { 6405 type identityref { 6406 base multicast-rp-discovery-type; 6407 } 6408 default static-rp; 6409 description 6410 "Type of RP discovery used."; 6411 } 6412 container bsr-candidates { 6413 when "derived-from-or-self(../rp-discovery-type, 'l3vpn-svc:bsr-rp')" { 6415 description 6416 "Only applicable if discovery type is BSR-RP."; 6417 } 6418 leaf-list bsr-candidate-address { 6419 type inet:ip-address; 6420 description 6421 "Address of BSR candidate."; 6422 } 6423 description 6424 "Container for List of Customer BSR candidate's addresses."; 6425 } 6426 description 6427 "RP discovery parameters."; 6428 } 6429 description 6430 "RP parameters."; 6431 } 6432 description 6433 "Multicast global parameters for the VPN service."; 6434 } 6435 description 6436 "Grouping for multicast VPN definition."; 6437 } 6438 grouping vpn-service-mpls { 6439 leaf carrierscarrier { 6440 if-feature carrierscarrier; 6441 type boolean; 6442 default false; 6443 description 6444 "The VPN is using CsC, and so MPLS is required."; 6445 } 6446 description 6447 "Grouping for MPLS CsC definition."; 6448 } 6449 grouping customer-location-info { 6450 container locations { 6451 list location { 6452 key location-id; 6453 leaf location-id { 6454 type svc-id; 6455 description 6456 "Identifier for a particular location."; 6457 } 6458 leaf address { 6459 type string; 6460 description 6461 "Address (number and street) of the site."; 6463 } 6464 leaf postal-code { 6465 type string; 6466 description 6467 "Postal code of the site."; 6468 } 6469 leaf state { 6470 type string; 6471 description 6472 "State of the site. This leaf can also be used to describe 6473 a region for a country that does not have states."; 6474 } 6475 leaf city { 6476 type string; 6477 description 6478 "City of the site."; 6479 } 6480 leaf country-code { 6481 type string { 6482 pattern '[A-Z]{2}'; 6484 } 6485 description 6486 "Country of the site. 6487 Expressed as ISO ALPHA-2 code."; 6488 } 6489 description 6490 "Location of the site."; 6491 } 6492 description 6493 "List of locations for the site."; 6494 } 6495 description 6496 "This grouping defines customer location parameters."; 6497 } 6498 grouping site-group { 6499 container groups { 6500 list group { 6501 key group-id; 6502 leaf group-id { 6503 type string; 6504 description 6505 "Group-id the site belongs to."; 6507 } 6508 description 6509 "List of group-ids."; 6510 } 6511 description 6513 "Groups the site or site-network-access belongs to."; 6514 } 6515 description 6516 "Grouping definition to assign 6517 group-ids to site or site-network-access."; 6518 } 6519 grouping site-diversity { 6520 container site-diversity { 6521 if-feature site-diversity; 6522 uses site-group; 6523 description 6524 "Diversity constraint type. 6525 All site-network-accesses will inherit the group values 6526 defined here."; 6527 } 6528 description 6529 "This grouping defines site diversity parameters."; 6530 } 6531 grouping access-diversity { 6532 container access-diversity { 6533 if-feature site-diversity; 6535 uses site-group; 6536 container constraints { 6537 list constraint { 6538 key constraint-type; 6539 leaf constraint-type { 6540 type identityref { 6541 base placement-diversity; 6542 } 6543 description 6544 "Diversity constraint type."; 6545 } 6546 container target { 6547 choice target-flavor { 6548 default id; 6549 case id { 6550 list group { 6551 key group-id; 6552 leaf group-id { 6553 type string; 6554 description 6555 "The constraint will be applied against 6556 this particular group-id for this site network access level."; 6557 } 6558 description 6559 "List of group-ids associated with one specific 6560 constraint for this site network access level."; 6562 } 6563 } 6564 case all-accesses { 6565 leaf all-other-accesses { 6566 type empty; 6567 description 6568 "The constraint will be applied against 6569 all other site network accesses of this site."; 6570 } 6571 } 6572 case all-groups { 6573 leaf all-other-groups { 6574 type empty; 6575 description 6576 "The constraint will be applied against 6577 all other groups managed by the customer."; 6578 } 6579 } 6580 description 6581 "Choice for the target flavor definition."; 6582 } 6583 description 6585 "The constraint will be applied against 6586 Specific target, and the target can be a list 6587 of group-ids,all other site network accesses of 6588 this site or all other groups managed by the 6589 customer."; 6590 } 6591 description 6592 "List of constraints."; 6593 } 6594 description 6595 "Placement constraints for this site network access."; 6596 } 6597 description 6598 "Diversity parameters."; 6599 } 6600 description 6601 "This grouping defines access diversity parameters."; 6602 } 6603 grouping operational-requirements { 6604 leaf requested-site-start { 6605 type yang:date-and-time; 6606 description 6607 "Optional leaf indicating requested date and time when the 6608 service at a particular site is expected to start."; 6609 } 6611 leaf requested-site-stop { 6612 type yang:date-and-time; 6613 description 6614 "Optional leaf indicating requested date and time when the 6615 service at a particular site is expected to stop."; 6616 } 6617 description 6618 "This grouping defines some operational parameters."; 6619 } 6620 grouping operational-requirements-ops { 6621 leaf actual-site-start { 6622 type yang:date-and-time; 6623 config false; 6624 description 6625 "Optional leaf indicating actual date and time when the 6626 service at a particular site actually started."; 6627 } 6628 leaf actual-site-stop { 6629 type yang:date-and-time; 6630 config false; 6631 description 6632 "Optional leaf indicating actual date and time when the 6633 service at a particular site actually stopped."; 6635 } 6636 description 6637 "This grouping defines some operational parameters."; 6638 } 6639 grouping flow-definition { 6640 container match-flow { 6641 leaf dscp { 6642 type inet:dscp; 6643 description 6644 "DSCP value."; 6645 } 6646 leaf dot1p { 6647 type uint8 { 6648 range "0..7"; 6649 } 6650 description 6651 "802.1p matching."; 6652 } 6653 leaf ipv4-src-prefix { 6654 type inet:ipv4-prefix; 6655 description 6656 "Match on IPv4 src address."; 6657 } 6658 leaf ipv6-src-prefix { 6659 type inet:ipv6-prefix; 6660 description 6661 "Match on IPv6 src address."; 6662 } 6663 leaf ipv4-dst-prefix { 6664 type inet:ipv4-prefix; 6665 description 6666 "Match on IPv4 dst address."; 6667 } 6668 leaf ipv6-dst-prefix { 6669 type inet:ipv6-prefix; 6670 description 6671 "Match on IPv6 dst address."; 6672 } 6673 leaf l4-src-port { 6674 type inet:port-number; 6675 must "current() < ../l4-src-port-range/lower-port or "+ 6676 "current() > ../l4-src-port-range/upper-port" { 6677 description 6678 "If l4-src-port and l4-src-port-range/lower-port and 6679 upper-port are set at the same time, l4-src-port 6680 should not overlap with l4-src-port-range. "; 6681 } 6682 description 6683 "Match on Layer 4 src port."; 6684 } 6685 leaf-list target-sites { 6686 if-feature target-sites; 6687 type svc-id; 6688 description 6689 "Identify a site as traffic destination."; 6690 } 6691 container l4-src-port-range { 6692 leaf lower-port { 6693 type inet:port-number; 6694 description 6695 "Lower boundary for port."; 6696 } 6697 leaf upper-port { 6698 type inet:port-number; 6699 must ". >= ../lower-port" { 6700 description 6701 " Upper boundary for port. If it 6702 exists, upper boundary must be 6703 higher than lower boundary."; 6704 } 6705 description 6706 "Upper boundary for port."; 6707 } 6708 description 6709 "Match on Layer 4 src port range. When only lower-port 6710 is present, it represents a single port. When both 6711 lower-port and upper-port are specified, it implies 6712 a range inclusive of both values."; 6713 } 6714 leaf l4-dst-port { 6715 type inet:port-number; 6716 must "current() < ../l4-dst-port-range/lower-port or "+ 6717 "current() > ../l4-dst-port-range/upper-port" { 6718 description 6719 " If l4-dst-port and l4-dst-port-range/lower-port and 6720 upper-port are set at the same time, l4-dst-port 6721 should not overlap with l4-src-port-range. "; 6722 } 6723 description 6724 "Match on Layer 4 dst port."; 6725 } 6726 container l4-dst-port-range { 6727 leaf lower-port { 6728 type inet:port-number; 6729 description 6730 "Lower boundary for port."; 6731 } 6732 leaf upper-port { 6733 type inet:port-number; 6734 must ". >= ../lower-port" { 6735 description 6736 "Upper boundary must be 6737 higher than lower boundary."; 6738 } 6739 description 6740 "Upper boundary for port. If it exists, upper boundary 6741 must be higher than lower boundary."; 6742 } 6743 description 6744 "Match on Layer 4 dst port range. When only lower-port is 6745 present, it represents a single port. When both lower-port 6746 and upper-port are specified, it implies a range inclusive 6747 of both values."; 6748 } 6749 leaf protocol-field { 6750 type union { 6751 type uint8; 6752 type identityref { 6753 base protocol-type; 6754 } 6755 } 6756 description 6757 "Match on IPv4 protocol or IPv6 Next Header field."; 6758 } 6759 description 6760 "Describes flow-matching criteria."; 6761 } 6762 description 6763 "Flow definition based on criteria."; 6764 } 6765 grouping site-service-basic { 6766 leaf svc-input-bandwidth { 6767 type uint64; 6768 units bps; 6769 mandatory true; 6770 description 6771 "From the customer site's perspective, the service 6772 input bandwidth of the connection or download 6773 bandwidth from the SP to the site."; 6774 } 6775 leaf svc-output-bandwidth { 6776 type uint64; 6778 units bps; 6779 mandatory true; 6780 description 6781 "From the customer site's perspective, the service 6782 output bandwidth of the connection or upload 6783 bandwidth from the site to the SP."; 6784 } 6785 leaf svc-mtu { 6786 type uint16; 6787 units bytes; 6788 mandatory true; 6789 description 6790 "MTU at service level. If the service is IP, 6791 it refers to the IP MTU. If CsC is enabled, 6792 the requested 'svc-mtu' leaf will refer to the 6793 MPLS MTU and not to the IP MTU. "; 6794 } 6795 description 6796 "Defines basic service parameters for a site."; 6797 } 6798 grouping site-protection { 6799 container traffic-protection { 6800 if-feature fast-reroute; 6801 leaf enabled { 6802 type boolean; 6803 default false; 6805 description 6806 "Enables traffic protection of access link."; 6807 } 6808 description 6809 "Fast Reroute service parameters for the site."; 6810 } 6811 description 6812 "Defines protection service parameters for a site."; 6813 } 6814 grouping site-service-mpls { 6815 container carrierscarrier { 6816 if-feature carrierscarrier; 6817 leaf signalling-type { 6818 type enumeration { 6819 enum ldp { 6820 description 6821 "Use LDP as the signalling protocol 6822 between the PE and the CE. In this case, 6823 an IGP routing protocol must also be activated. "; 6824 } 6825 enum bgp { 6827 description 6828 "Use BGP (as per RFC 3107) as the signalling protocol 6829 between the PE and the CE. 6830 In this case, BGP must also be configured as 6831 the routing protocol."; 6832 } 6833 } 6834 default bgp; 6835 description 6836 "MPLS signalling type."; 6837 } 6838 description 6839 "This container is used when the customer provides 6840 MPLS-based services. This is only used in the case 6841 of CsC(i.e., a customer builds an MPLS service using 6842 an IP VPN to carry its traffic."; 6844 } 6845 description 6846 "Defines MPLS service parameters for a site."; 6847 } 6848 grouping site-service-qos-profile { 6849 container qos { 6850 if-feature qos; 6851 container qos-classification-policy { 6852 list rule { 6853 key id; 6854 ordered-by user; 6855 leaf id { 6856 type string; 6857 description 6858 "A description identifying qos classification 6859 policy rule."; 6860 } 6861 choice match-type { 6862 default match-flow; 6863 case match-flow { 6864 uses flow-definition; 6865 } 6866 case match-application { 6867 leaf match-application { 6868 type identityref { 6869 base customer-application; 6870 } 6871 description 6872 "Defines the application to match."; 6873 } 6874 } 6876 description 6877 "Choice for classification."; 6878 } 6879 leaf target-class-id { 6880 type string; 6881 description 6882 "Identification of the class of service. 6883 This identifier is internal to the administration."; 6884 } 6885 description 6886 "List of marking rules."; 6887 } 6888 description 6889 "Configuration of the traffic classification policy."; 6890 } 6891 container qos-profile { 6892 choice qos-profile { 6893 description 6894 "Choice for QoS profile. 6895 Can be standard profile or customized profile."; 6896 case standard { 6897 description "Standard QoS profile."; 6898 leaf profile { 6899 type leafref { 6900 path "/l3vpn-svc/vpn-profiles/valid-provider-identifiers/qos-profile-identifier/id"; 6901 } 6902 description 6904 "QoS profile to be used."; 6905 } 6906 } 6907 case custom { 6908 description "Customized QoS profile."; 6909 container classes { 6910 if-feature qos-custom; 6911 list class { 6912 key class-id; 6913 leaf class-id { 6914 type string; 6915 description 6916 "Identification of the class of service. 6917 This identifier is internal to the administration."; 6918 } 6919 leaf direction { 6920 type identityref { 6921 base qos-profile-direction; 6922 } 6923 default both; 6924 description 6925 "The direction which QoS profile is applied to"; 6926 } 6928 leaf rate-limit { 6929 type uint8 { 6930 range "0..100"; 6931 } 6932 units percent; 6933 description 6934 "To be used if the class must be rate-limited. 6935 Expressed as percentage of the service bandwidth."; 6936 } 6937 container latency { 6938 choice flavor { 6939 case lowest { 6940 leaf use-lowest-latency { 6941 type empty; 6942 description 6943 "The traffic class should use the path with the 6944 lowest latency."; 6945 } 6946 } 6947 case boundary { 6948 leaf latency-boundary { 6949 type uint16; 6950 units msec; 6951 default 400; 6952 description 6953 "The traffic class should use a path with a 6954 defined maximum latency."; 6955 } 6956 } 6957 description 6958 "Latency constraint on the traffic class."; 6959 } 6960 description 6961 "Latency constraint on the traffic class."; 6962 } 6964 container jitter { 6965 choice flavor { 6966 case lowest { 6967 leaf use-lowest-jitter { 6968 type empty; 6969 description 6970 "The traffic class should use the path with the 6971 lowest jitter."; 6972 } 6973 } 6974 case boundary { 6975 leaf latency-boundary { 6976 type uint32; 6977 units usec; 6978 default 40000; 6979 description 6980 "The traffic class should use a path with a 6981 defined maximum jitter."; 6982 } 6983 } 6984 description 6985 "Jitter constraint on the traffic class."; 6986 } 6987 description 6988 "Jitter constraint on the traffic class."; 6989 } 6990 container bandwidth { 6991 leaf guaranteed-bw-percent { 6992 type uint8 { 6993 range "0..100"; 6994 } 6995 units percent; 6996 mandatory true; 6997 description 6998 "To be used to define the guaranteed bandwidth 6999 as a percentage of the available service bandwidth."; 7000 } 7001 leaf end-to-end { 7002 type empty; 7003 description 7004 "Used if the bandwidth reservation 7005 must be done on the MPLS network too."; 7006 } 7007 description 7008 "Bandwidth constraint on the traffic class."; 7009 } 7010 description 7011 "List of classes of services."; 7012 } 7013 description 7014 "Container for list of classes of services."; 7015 } 7016 } 7017 } 7018 description 7019 "QoS profile configuration."; 7020 } 7021 description 7022 "QoS configuration."; 7023 } 7024 description 7025 "This grouping defines QoS parameters for a site."; 7026 } 7027 grouping site-security-authentication { 7028 container authentication { 7029 description 7030 "Authentication parameters."; 7031 } 7032 description 7033 "This grouping defines authentication parameters for a site."; 7034 } 7035 grouping site-security-encryption { 7036 container encryption { 7037 if-feature encryption; 7038 leaf enabled { 7039 type boolean; 7040 default false; 7041 description 7042 "If true, traffic encryption on the connection is required."; 7043 } 7044 leaf layer { 7045 when "../enabled = 'true'" { 7046 description 7047 " Require a value for layer when enabled is true."; 7048 } 7049 type enumeration { 7050 enum layer2 { 7051 description 7052 "Encryption will occur at Layer 2."; 7053 } 7054 enum layer3 { 7055 description 7056 "Encryption will occur at Layer 3. 7057 For example, IPsec may be used when a customer requests Layer 3 encryption."; 7058 } 7059 } 7060 description 7061 "Layer on which encryption is applied."; 7062 } 7063 container encryption-profile { 7064 choice profile { 7065 case provider-profile { 7066 leaf profile-name { 7067 type leafref { 7068 path "/l3vpn-svc/vpn-profiles/valid-provider-identifiers/encryption-profile-identifier/id"; 7069 } 7070 description 7071 "Name of the SP profile to be applied."; 7073 } 7074 } 7075 case customer-profile { 7076 leaf algorithm { 7077 type string; 7078 description 7079 "Encryption algorithm to be used."; 7080 } 7081 choice key-type { 7082 default psk; 7083 case psk { 7084 leaf preshared-key { 7085 type string; 7086 description 7087 " Pre-Shared Key(PSK) coming from customer."; 7088 } 7089 } 7090 description 7091 "Type of keys to be used."; 7092 } 7093 } 7094 description 7095 "Choice of encryption profile, the encryption 7096 profile can be provider profile or customer profile."; 7097 } 7098 description 7099 "Profile of encryption to be applied."; 7100 } 7101 description 7102 "Encryption parameters."; 7103 } 7104 description 7105 "This grouping defines encryption parameters for a site."; 7106 } 7107 grouping site-attachment-bearer { 7108 container bearer { 7109 container requested-type { 7110 if-feature requested-type; 7111 leaf requested-type { 7112 type string; 7114 description 7115 "Type of requested bearer: Ethernet, DSL, 7116 Wireless, etc. Operator specific."; 7117 } 7118 leaf strict { 7119 type boolean; 7120 default false; 7122 description 7123 "Defines whether requested-type is a preference 7124 or a strict requirement."; 7125 } 7126 description 7127 "Container for requested-type."; 7128 } 7129 leaf always-on { 7130 if-feature always-on; 7131 type boolean; 7132 default true; 7133 description 7134 "Request for an always-on access type. 7135 For example, this could mean no dial access type."; 7136 } 7137 leaf bearer-reference { 7138 if-feature bearer-reference; 7139 type string; 7140 description 7141 "This is an internal reference for the SP."; 7142 } 7143 description 7144 "Bearer-specific parameters. 7145 To be augmented."; 7146 } 7147 description 7148 "Defines physical properties of a site attachment."; 7149 } 7150 grouping site-routing { 7151 container routing-protocols { 7152 list routing-protocol { 7153 key type; 7154 leaf type { 7155 type identityref { 7156 base routing-protocol-type; 7157 } 7158 description 7159 "Type of routing protocol."; 7160 } 7161 container ospf { 7162 when "derived-from-or-self(../type, 'l3vpn-svc:ospf')" { 7163 description 7164 "Only applies when protocol is OSPF."; 7165 } 7166 if-feature rtg-ospf; 7167 leaf-list address-family { 7168 type address-family; 7170 min-elements "1"; 7171 description 7172 "If OSPF is used on this site, this node 7173 contains configured value. This node 7174 contains at least one address family 7175 to be activated."; 7176 } 7177 leaf area-address { 7178 type yang:dotted-quad; 7179 mandatory true; 7180 description 7181 "Area address."; 7182 } 7183 leaf metric { 7184 type uint16; 7185 default 1; 7186 description 7187 "Metric of the PE-CE link. It is used 7188 in the routing state calculation and 7189 path selection. The default value is 7190 set to 1 assigned to the PE-CE link."; 7191 } 7192 container sham-links { 7193 if-feature rtg-ospf-sham-link; 7194 list sham-link { 7195 key target-site; 7196 leaf target-site { 7197 type svc-id; 7198 description 7199 "Target site for the sham link connection. 7200 The site is referred to by its ID."; 7201 } 7202 leaf metric { 7203 type uint16; 7204 default 1; 7205 description 7206 "Metric of the sham link. It is used in 7207 the routing state calculation and path 7208 selection. The default value is set 7209 to 1."; 7210 } 7211 description 7212 "Creates a sham link with another site."; 7213 } 7214 description 7215 "List of sham links."; 7216 } 7218 description 7219 "OSPF-specific configuration."; 7220 } 7221 container bgp { 7222 when "derived-from-or-self(../type, 'l3vpn-svc:bgp')" { 7223 description 7224 "Only applies when protocol is BGP."; 7225 } 7226 if-feature rtg-bgp; 7227 leaf autonomous-system { 7228 type uint32; 7229 mandatory true; 7230 description 7231 "Customer AS number in case the customer 7232 requests BGP routing."; 7233 } 7234 leaf-list address-family { 7235 type address-family; 7236 min-elements "1"; 7237 description 7238 "If BGP is used on this site, this node 7239 contains configured value. This node 7240 contains at least one address family 7241 to be activated."; 7242 } 7243 description 7244 "BGP-specific configuration."; 7245 } 7246 container static { 7247 when "derived-from-or-self(../type, 'l3vpn-svc:static')" { 7248 description 7249 "Only applies when protocol is static. 7250 BGP activation requires the SP to know 7251 the address of the customer peer. When 7252 BGP is enabled, the 'static-address' 7253 allocation type for the IP connection 7254 MUST be used."; 7255 } 7256 container cascaded-lan-prefixes { 7257 list ipv4-lan-prefixes { 7258 if-feature ipv4; 7259 key "lan next-hop"; 7260 leaf lan { 7262 type inet:ipv4-prefix; 7263 description 7264 "LAN prefixes."; 7265 } 7267 leaf lan-tag { 7268 type string; 7269 description 7270 "Internal tag to be used in VPN policies."; 7271 } 7272 leaf next-hop { 7273 type inet:ipv4-address; 7274 description 7275 "Next-hop address to use on the customer side."; 7277 } 7278 description 7279 "List of LAN prefixes for the site."; 7280 } 7281 list ipv6-lan-prefixes { 7282 if-feature ipv6; 7283 key "lan next-hop"; 7284 leaf lan { 7285 type inet:ipv6-prefix; 7286 description 7287 "LAN prefixes."; 7288 } 7289 leaf lan-tag { 7290 type string; 7291 description 7292 "Internal tag to be used in VPN policies."; 7293 } 7294 leaf next-hop { 7295 type inet:ipv6-address; 7296 description 7297 "Next-hop address to use on the customer side."; 7298 } 7299 description 7300 "List of LAN prefixes for the site."; 7301 } 7302 description 7303 "LAN prefixes from the customer."; 7304 } 7305 description 7306 "Configuration specific to static routing."; 7307 } 7308 container rip { 7309 when "derived-from-or-self(../type, 'l3vpn-svc:rip')" { 7310 description 7311 "Only applies when protocol is RIP. For IPv4, 7312 the model assumes that RIP version 2 is used."; 7313 } 7314 if-feature rtg-rip; 7316 leaf-list address-family { 7317 type address-family; 7318 min-elements "1"; 7319 description 7320 "If RIP is used on this site, this node 7321 contains configured value.This node 7322 contains at least one address family 7323 to be activated."; 7324 } 7325 description 7326 "Configuration specific to RIP routing."; 7327 } 7328 container vrrp { 7329 when "derived-from-or-self(../type, 'l3vpn-svc:vrrp')" { 7330 description 7331 "Only applies when protocol is VRRP."; 7332 } 7333 if-feature rtg-vrrp; 7334 leaf-list address-family { 7335 type address-family; 7336 min-elements "1"; 7337 description 7338 "If VRRP is used on this site, this node 7339 contains configured value. This node contains 7340 at least one address family to be activated. "; 7341 } 7342 description 7343 "Configuration specific to VRRP routing."; 7344 } 7345 description 7346 "List of routing protocols used on 7347 the site. This list can be augmented."; 7348 } 7349 description 7350 "Defines routing protocols."; 7351 } 7352 description 7353 "Grouping for routing protocols."; 7354 } 7355 grouping site-attachment-ip-connection { 7356 container ip-connection { 7357 container ipv4 { 7358 if-feature ipv4; 7359 leaf address-allocation-type { 7360 type identityref { 7361 base address-allocation-type; 7362 } 7363 must "not(derived-from-or-self(current(), 'l3vpn-svc:slaac') or "+ 7364 "derived-from-or-self(current(), 'l3vpn-svc:provider-dhcp-slaac'))" { 7365 error-message "SLAAC is only applicable to IPv6"; 7366 } 7367 description 7368 "Defines how addresses are allocated. 7369 If there is no value for address 7370 allocation type, then the ipv4 is not enabled."; 7371 } 7372 container provider-dhcp { 7373 when "derived-from-or-self(../address-allocation-type, 'l3vpn-svc:provider-dhcp')" { 7374 description 7375 "Only applies when addresses are allocated by DHCP."; 7376 } 7377 leaf provider-address { 7378 type inet:ipv4-address; 7379 description 7380 "Address of provider side. If provider-address is not specified, 7381 then mask should not be specified as well,it also implies 7382 provider-dhcp allocation is not enabled. If provider address 7383 is specified, then mask may or may not be specified. "; 7384 } 7385 leaf mask { 7386 type uint8 { 7387 range "0..31"; 7388 } 7389 must "(../provider-address)" { 7390 error-message 7391 "if mask is specified, provider-address must also be specified."; 7392 description 7393 "if mask is specified, provider-address must also be specified."; 7394 } 7395 description 7396 "Subnet mask expressed in bits. If not specified, or specified as zero, 7397 this means the customer leaves the actual mask value to the provider."; 7398 } 7399 choice address-assign { 7400 default number; 7401 case number { 7402 leaf number-of-dynamic-address { 7403 type uint16; 7404 default 1; 7405 description 7406 "Describes the number of IP addresses the customer requires."; 7407 } 7408 } 7409 case explicit { 7410 container customer-addresses { 7411 list address-group { 7412 key "group-id"; 7413 leaf group-id { 7414 type string; 7415 description 7416 "Group-id for the address range from start-address to end-address."; 7417 } 7418 leaf start-address { 7419 type inet:ipv4-address; 7420 description 7421 "First address."; 7422 } 7424 leaf end-address { 7425 type inet:ipv4-address; 7426 description 7427 "Last address."; 7428 } 7429 description 7430 "Describes IP addresses allocated by DHCP. When only start-address 7431 or only end-address is present, it represents a single address. 7432 When both start-address and end-address are specified, it implies 7433 a range inclusive of both addresses. If no address is specified, 7434 it implies customer addresses group is not supported. "; 7435 } 7436 description 7437 "Container for customer addresses allocated by DHCP."; 7438 } 7439 } 7440 description 7441 "Choice for the way to assign addresses."; 7442 } 7443 description 7444 "DHCP allocated addresses related parameters."; 7445 } 7446 container dhcp-relay { 7447 when "derived-from-or-self(../address-allocation-type, 'l3vpn-svc:provider-dhcp-relay')" { 7448 description 7449 "Only applies when provider is required to implement 7450 DHCP relay function."; 7451 } 7452 leaf provider-address { 7453 type inet:ipv4-address; 7454 description 7455 "Address of provider side. If provider-address is not specified, 7456 then mask should not be specified as well,it also implies 7457 provider-dhcp allocation is not enabled. If provider address 7458 is specified, then mask may or may not be specified."; 7459 } 7460 leaf mask { 7461 type uint8 { 7462 range "0..31"; 7463 } 7464 must "(../provider-address)" { 7465 error-message 7466 "if mask is specified, provider-address must also be specified."; 7467 description 7468 "if mask is specified, provider-address must also be specified."; 7470 } 7471 description 7472 "Subnet mask expressed in bits. If not specified, or specified as zero, 7473 this means the customer leaves the actual mask value to the provider."; 7474 } 7476 container customer-dhcp-servers { 7477 leaf-list server-ip-address { 7478 type inet:ipv4-address; 7479 description 7480 "IP address of customer DHCP server."; 7481 } 7482 description 7483 "Container for list of customer DHCP servers."; 7484 } 7485 description 7486 "DHCP relay provided by operator."; 7487 } 7489 container addresses { 7490 when "derived-from-or-self(../address-allocation-type, 'l3vpn-svc:static-address')" { 7491 description 7492 "Only applies when protocol allocation type is static."; 7493 } 7494 leaf provider-address { 7495 type inet:ipv4-address; 7496 description 7497 "IPv4 Address List of provider side. When protocol 7498 allocation type is static, provider address must be configured."; 7499 } 7500 leaf customer-address { 7501 type inet:ipv4-address; 7502 description 7503 "IPv4 Address of customer side."; 7504 } 7505 leaf mask { 7506 type uint8 { 7507 range "0..31"; 7508 } 7509 description 7510 "Subnet mask expressed in bits. It is applied to both 7511 provider-address and customer-address."; 7512 } 7513 description 7514 "Describes IPv4 addresses used."; 7515 } 7516 description 7517 "IPv4-specific parameters."; 7519 } 7520 container ipv6 { 7521 if-feature ipv6; 7522 leaf address-allocation-type { 7523 type identityref { 7524 base address-allocation-type; 7525 } 7526 description 7527 "Defines how addresses are allocated. 7528 If there is no value for address 7529 allocation type, then the ipv6 is 7530 not enabled."; 7531 } 7533 container provider-dhcp { 7534 when "derived-from-or-self(../address-allocation-type, 'l3vpn-svc:provider-dhcp') "+ 7535 "or derived-from-or-self(../address-allocation-type, 'l3vpn-svc:provider-dhcp-slaac')" { 7536 description 7537 "Only applies when addresses are allocated by DHCP."; 7538 } 7539 leaf provider-address { 7540 type inet:ipv6-address; 7541 description 7542 "Address of provider side. If provider-address is not specified, 7543 then mask should not be specified as well,it also implies 7544 provider-dhcp allocation is not enabled. If provider address 7545 is specified, then mask may or may not be specified."; 7546 } 7547 leaf mask { 7548 type uint8 { 7549 range "0..127"; 7550 } 7551 must "(../provider-address)" { 7552 error-message 7553 "if mask is specified, provider-address must also be specified."; 7554 description 7555 "if mask is specified, provider-address must also be specified."; 7556 } 7557 description 7558 "Subnet mask expressed in bits. If not specified, or specified as zero, 7559 this means the customer leaves the actual mask value to the provider."; 7560 } 7562 choice address-assign { 7563 default number; 7564 case number { 7565 leaf number-of-dynamic-address { 7566 type uint16; 7567 default 1; 7568 description 7569 "Describes the number of IP addresses the customer requires."; 7570 } 7571 } 7572 case explicit { 7573 container customer-addresses { 7574 list address-group { 7575 key "group-id"; 7576 leaf group-id { 7577 type string; 7578 description 7579 "Group-id for the address range from start-address 7580 to end-address."; 7581 } 7582 leaf start-address { 7583 type inet:ipv6-address; 7584 description 7585 "First address."; 7586 } 7588 leaf end-address { 7589 type inet:ipv6-address; 7590 description 7591 "Last address."; 7592 } 7593 description 7594 "Describes IP addresses allocated by DHCP. When only 7595 start-address or only end-address is present, it 7596 represents a single address. When both start-address 7597 and end-address are specified, it implies a range 7598 inclusive of both addresses. If no address is specified, 7599 it implies customer addresses group is not supported."; 7600 } 7601 description 7602 "Container for customer addresses allocated by DHCP."; 7603 } 7604 } 7605 description 7606 "Choice for the way to assign addresses."; 7607 } 7608 description 7609 "DHCP allocated addresses related parameters."; 7610 } 7611 container dhcp-relay { 7612 when "derived-from-or-self(../address-allocation-type, 'l3vpn-svc:provider-dhcp-relay')" { 7613 description 7614 "Only applies when provider is required to implement 7615 DHCP relay function."; 7616 } 7617 leaf provider-address { 7618 type inet:ipv6-address; 7619 description 7620 "Address of provider side. If provider-address is not specified, 7621 then mask should not be specified as well,it also implies 7622 provider-dhcp allocation is not enabled. If provider address 7623 is specified, then mask may or may not be specified."; 7624 } 7625 leaf mask { 7626 type uint8 { 7627 range "0..127"; 7628 } 7629 must "(../provider-address)" { 7630 error-message 7631 "if mask is specified, provider-address must also be specified."; 7632 description 7633 "if mask is specified, provider-address must also be specified."; 7634 } 7635 description 7636 "Subnet mask expressed in bits. If not specified, or specified as zero, 7637 this means the customer leaves the actual mask value to the provider."; 7638 } 7640 container customer-dhcp-servers { 7641 leaf-list server-ip-address { 7642 type inet:ipv6-address; 7643 description 7644 "This node contains IP address of 7645 customer DHCP server.If DHCP relay 7646 function is implemented by the 7647 provider, this node contains the 7648 configured value."; 7649 } 7650 description 7651 "Container for list of customer DHCP servers."; 7652 } 7653 description 7654 "DHCP relay provided by operator."; 7655 } 7657 container addresses { 7658 when "derived-from-or-self(../address-allocation-type, 'l3vpn-svc:static-address')" { 7659 description 7660 "Only applies when protocol allocation type is static."; 7661 } 7662 leaf provider-address { 7663 type inet:ipv6-address; 7664 description 7665 "IPv6 Address of provider side. When protocol 7666 allocation type is static, provider address must be configured."; 7667 } 7668 leaf customer-address { 7669 type inet:ipv6-address; 7670 description 7671 "IPv6 Address of customer side."; 7672 } 7673 leaf mask { 7674 type uint8 { 7675 range "0..127"; 7676 } 7677 description 7678 "Subnet mask expressed in bits. It is applied to both provider-address and customer-address."; 7679 } 7680 description 7681 "Describes IPv6 addresses used."; 7682 } 7683 description 7684 "IPv6-specific parameters."; 7685 } 7686 container oam { 7687 container bfd { 7688 if-feature bfd; 7689 leaf enabled { 7690 type boolean; 7691 default false; 7692 description 7693 "If true, BFD activation is required."; 7694 } 7695 choice holdtime { 7696 default fixed; 7697 case fixed { 7698 leaf fixed-value { 7699 type uint32; 7700 units msec; 7701 description 7702 "Expected BFD holdtime expressed in msec. The customer 7703 may impose Some fixed values for the holdtime period if the 7704 provider allows the customer use this function.If the 7705 provider doesn't allow the customer use this function, 7706 the fixed-value will not be set."; 7707 } 7708 } 7709 case profile { 7710 leaf profile-name { 7711 type leafref { 7712 path "/l3vpn-svc/vpn-profiles/valid-provider-identifiers/bfd-profile-identifier/id"; 7713 } 7714 description 7715 "Well-known SP profile Name. The provider can propose some profiles 7716 to the customer, depending on the service level the customer wants 7717 to achieve. Profile names must be communicated to the customer"; 7718 } 7719 description 7720 "Well-known SP profile."; 7721 } 7722 description 7723 "Choice for holdtime flavor."; 7724 } 7725 description 7726 "Container for BFD."; 7727 } 7728 description 7729 "Defines the OAM mechanisms used on the connection. 7730 BFD is set as a fault detection mechanism, but the 'oam' container 7731 can easily be augmented by other mechanisms"; 7732 } 7733 description 7734 "Defines connection parameters."; 7735 } 7736 description 7737 "This grouping defines IP connection parameters."; 7738 } 7739 grouping site-service-multicast { 7740 container multicast { 7741 if-feature multicast; 7742 leaf multicast-site-type { 7743 type enumeration { 7745 enum receiver-only { 7746 description 7747 "The site only has receivers."; 7748 } 7749 enum source-only { 7750 description 7751 "The site only has sources."; 7752 } 7754 enum source-receiver { 7755 description 7756 "The site has both sources and receivers."; 7757 } 7758 } 7759 default source-receiver; 7760 description 7761 "Type of multicast site."; 7762 } 7763 container multicast-address-family { 7764 leaf ipv4 { 7765 if-feature ipv4; 7766 type boolean; 7767 default false; 7768 description 7769 "Enables IPv4 multicast."; 7770 } 7771 leaf ipv6 { 7772 if-feature ipv6; 7773 type boolean; 7774 default false; 7775 description 7776 "Enables IPv6 multicast."; 7777 } 7778 description 7779 "Defines protocol to carry multicast."; 7780 } 7781 leaf protocol-type { 7782 type enumeration { 7783 enum host { 7784 description 7785 "Hosts are directly connected to the provider network. 7786 Host protocols such as IGMP or MLD are required."; 7787 } 7788 enum router { 7789 description 7790 "Hosts are behind a customer router. 7791 PIM will be implemented."; 7792 } 7793 enum both { 7794 description 7795 "Some hosts are behind a customer router, and some others 7796 are directly connected to the provider network. 7797 Both host and routing protocols must be used. 7798 Typically, IGMP and PIM will be implemented."; 7799 } 7800 } 7801 default "both"; 7803 description 7804 "Multicast protocol type to be used with the customer site."; 7805 } 7806 description 7807 "Multicast parameters for the site."; 7808 } 7809 description 7810 "Multicast parameters for the site."; 7811 } 7812 grouping site-management { 7813 container management { 7814 leaf type { 7815 type identityref { 7816 base management; 7817 } 7818 mandatory true; 7819 description 7820 "Management type of the connection."; 7821 } 7822 description 7823 "Management configuration."; 7824 } 7825 description 7826 "Management parameters for the site."; 7827 } 7828 grouping site-devices { 7829 container devices { 7830 when "derived-from-or-self(../management/type, 'l3vpn-svc:provider-managed') or "+ 7831 "derived-from-or-self(../management/type, 'l3vpn-svc:co-managed')" { 7832 description 7833 "Applicable only for provider-managed or co-managed device."; 7834 } 7835 list device { 7836 key device-id; 7837 leaf device-id { 7838 type svc-id; 7839 description 7840 "Identifier for the device."; 7841 } 7842 leaf location { 7844 type leafref { 7845 path "../../../locations/"+ 7846 "location/location-id"; 7847 } 7848 mandatory true; 7849 description 7850 "Location of the device."; 7852 } 7853 container management { 7854 when "derived-from-or-self(../../../management/type,"+ 7855 "'l3vpn-svc:co-managed')" { 7856 description 7857 "Applicable only for co-managed device."; 7858 } 7859 leaf address-family { 7860 type address-family; 7861 description 7862 "Address family used for management."; 7863 } 7864 leaf address { 7865 when "(../address-family)" { 7866 description 7867 "If address-family is specified, then address should 7868 also be specified.If address-family is not specified, 7869 then address should also not be specified."; 7870 } 7871 type inet:ip-address; 7872 mandatory true; 7873 description 7874 "Management address."; 7875 } 7876 description 7877 "Management configuration. Applicable only for 7878 co-managed device."; 7879 } 7880 description 7881 "Device configuration."; 7882 } 7883 description 7884 "List of devices requested by customer."; 7885 } 7886 description 7887 "Grouping for device allocation."; 7888 } 7889 grouping site-vpn-flavor { 7890 leaf site-vpn-flavor { 7891 type identityref { 7892 base site-vpn-flavor; 7893 } 7894 default site-vpn-flavor-single; 7895 description 7896 "Defines the way the VPN multiplexing is done ,e.g.,whether 7897 the site belongs to a single VPN site or a multiVPN; In case 7898 of multiVPN, whether the logical accesses of the sites belong 7899 to the same set of VPNs or each logical accesses map to 7900 different VPNs. "; 7901 } 7902 description 7903 "Grouping for site VPN flavor."; 7904 } 7905 grouping site-vpn-policy { 7906 container vpn-policies { 7907 list vpn-policy { 7908 key vpn-policy-id; 7909 leaf vpn-policy-id { 7910 type svc-id; 7911 description 7912 "Unique identifier for the VPN policy."; 7913 } 7914 list entries { 7915 key id; 7916 leaf id { 7917 type svc-id; 7918 description 7919 "Unique identifier for the policy entry."; 7920 } 7921 container filters { 7922 list filter { 7923 key type; 7924 ordered-by user; 7925 leaf type { 7926 type identityref { 7927 base vpn-policy-filter-type; 7928 } 7929 description 7930 "Type of VPN Policy filter."; 7931 } 7932 leaf-list lan-tag { 7933 when "derived-from-or-self(../type, 'l3vpn-svc:lan')" { 7934 description 7935 "Only applies when VPN Policy filter is LAN Tag filter."; 7936 } 7937 if-feature lan-tag; 7938 type string; 7939 description 7940 "List of 'lan-tag' items to be matched. Lan-tag 7941 is Internal tag to be used in VPN policies "; 7942 } 7943 leaf-list ipv4-lan-prefix { 7944 when "derived-from-or-self(../type, 'l3vpn-svc:ipv4')" { 7945 description 7946 "Only applies when VPN Policy filter is IPv4 Prefix filter."; 7947 } 7948 if-feature ipv4; 7949 type inet:ipv4-prefix; 7950 description 7951 "List of IPv4 prefixes as LAN Prefixes to be matched."; 7952 } 7953 leaf-list ipv6-lan-prefix { 7954 when "derived-from-or-self(../type, 'l3vpn-svc:ipv6')" { 7955 description 7956 "Only applies when VPN Policy filter is IPv6 Prefix filter."; 7957 } 7958 if-feature ipv6; 7959 type inet:ipv6-prefix; 7960 description 7961 "List of IPv6 prefixes as LAN prefixes to be matched."; 7962 } 7963 description 7964 "List of filters used on the site. This list can 7965 be augmented."; 7966 } 7967 description 7968 "If a more-granular VPN attachment is necessary, filtering can 7969 be used. If used, it permits the splitting of site LANs among 7970 multiple VPNs.The Site LAN can be split based on either LAN-tag 7971 or LAN prefix. If no filter is used, all the LANs will be 7972 part of the same VPNs with the same role."; 7973 } 7974 list vpn { 7975 key vpn-id; 7976 leaf vpn-id { 7977 type leafref { 7978 path "/l3vpn-svc/vpn-services/"+ 7979 "vpn-service/vpn-id"; 7980 } 7981 mandatory true; 7982 description 7983 "Reference to an IP VPN."; 7984 } 7985 leaf site-role { 7986 type identityref { 7987 base site-role; 7988 } 7989 default any-to-any-role; 7990 description 7991 "Role of the site in the IP VPN."; 7992 } 7993 description 7994 "List of VPNs the LAN is associated with."; 7995 } 7996 description 7997 "List of entries for export policy."; 7998 } 7999 description 8000 "List of VPN policies."; 8001 } 8002 description 8003 "VPN policy."; 8004 } 8005 description 8006 "VPN policy parameters for the site."; 8007 } 8008 grouping site-maximum-routes { 8009 container maximum-routes { 8010 list address-family { 8012 key af; 8013 leaf af { 8014 type address-family; 8015 description 8016 "Address family."; 8017 } 8018 leaf maximum-routes { 8019 type uint32; 8020 description 8021 "Maximum prefixes the VRF can accept for this address family."; 8022 } 8023 description 8024 "List of address families."; 8025 } 8026 description 8027 "Defines 'maximum-routes' for the VRF."; 8028 } 8029 description 8030 "Defines 'maximum-routes' for the site."; 8031 } 8032 grouping site-security { 8033 container security { 8034 uses site-security-authentication; 8035 uses site-security-encryption; 8036 description 8037 "Site-specific security parameters."; 8038 } 8039 description 8040 "Grouping for security parameters."; 8041 } 8042 grouping site-service { 8043 container service { 8044 uses site-service-qos-profile; 8045 uses site-service-mpls; 8046 uses site-service-multicast; 8047 description 8048 "Service parameters on the attachment."; 8049 } 8050 description 8051 "Grouping for service parameters."; 8052 } 8053 grouping site-network-access-service { 8054 container service { 8055 uses site-service-basic; 8056 uses site-service-qos-profile; 8057 uses site-service-mpls; 8058 uses site-service-multicast; 8059 description 8061 "Service parameters on the attachment."; 8062 } 8063 description 8064 "Grouping for service parameters."; 8065 } 8066 grouping vpn-extranet { 8067 container extranet-vpns { 8068 if-feature extranet-vpn; 8069 list extranet-vpn { 8070 key vpn-id; 8071 leaf vpn-id { 8072 type svc-id; 8073 description 8074 "Identifies the target VPN the local VPN want to access."; 8075 } 8076 leaf local-sites-role { 8077 type identityref { 8078 base site-role; 8079 } 8080 default any-to-any-role; 8081 description 8082 "This describes the role of the 8083 local sites in the target VPN topology. In the any-to-any VPN 8084 service topology, the local sites must have the same role, which 8085 will be 'any-to-any-role '.In the Hub-and-Spoke VPN service 8086 topology or the Hub and Spoke disjoint VPN service topology, 8087 the local sites must have a Hub role or a Spoke role."; 8088 } 8089 description 8090 "List of extranet VPNs or target VPNs the local VPN is attached to."; 8091 } 8092 description 8093 "Container for extranet VPN configuration."; 8094 } 8095 description 8096 "Grouping for extranet VPN configuration. 8097 This provides an easy way to interconnect 8098 all sites from two VPNs."; 8099 } 8100 grouping site-attachment-availability { 8101 container availability { 8102 leaf access-priority { 8103 type uint32; 8104 default 100; 8105 description 8106 "Defines the priority for the access. 8108 The higher the access-priority value, 8110 the higher the preference of the 8111 access will be."; 8112 } 8113 description 8114 "Availability parameters (used for multihoming)."; 8115 } 8116 description 8117 "Defines availability parameters for a site."; 8118 } 8119 grouping access-vpn-policy { 8120 container vpn-attachment { 8121 choice attachment-flavor { 8122 case vpn-policy-id { 8123 leaf vpn-policy-id { 8124 type leafref { 8125 path "../../../../"+ 8126 "vpn-policies/vpn-policy/"+ 8127 "vpn-policy-id"; 8128 } 8129 description 8130 "Reference to a VPN policy. When referencing VPN 8131 policy for attachment, the vpn-policy-id must be 8132 configured."; 8133 } 8134 } 8135 case vpn-id { 8136 leaf vpn-id { 8137 type leafref { 8138 path "/l3vpn-svc/vpn-services"+ 8139 "/vpn-service/vpn-id"; 8140 } 8141 description 8142 "Reference to a IP VPN. Referencing a vpn-id provides 8143 an easy way to attach a particular logical access to 8144 a VPN. In this case, vpn-id must be configured."; 8145 } 8146 leaf site-role { 8147 type identityref { 8148 base site-role; 8149 } 8150 default any-to-any-role; 8151 description 8152 "Role of the site in the IP VPN. When referencing a vpn-id, 8153 the site-role setting must be added to express the role of 8154 the site in the target VPN service topology."; 8155 } 8156 } 8158 mandatory true; 8159 description 8160 "Choice for VPN attachment flavor. A choice is implemented 8161 to allow the user to choose the flavor that provides the 8162 best fit."; 8163 } 8164 description 8165 "Defines VPN attachment of a site."; 8166 } 8167 description 8168 "Defines the VPN attachment rules for 8169 a site's logical access."; 8170 } 8171 grouping vpn-profile-cfg { 8172 container valid-provider-identifiers { 8173 list cloud-identifier { 8174 if-feature cloud-access; 8175 key id; 8176 leaf id { 8177 type string; 8178 description 8179 "Identification of cloud service. 8180 Local administration meaning."; 8181 } 8182 description 8183 "List for Cloud Identifiers."; 8184 } 8185 list encryption-profile-identifier { 8186 key id; 8187 leaf id { 8188 type string; 8189 description 8190 "Identification of the SP encryption profile 8191 to be used. Local administration meaning."; 8192 } 8193 description 8194 "List for encryption profile identifiers."; 8195 } 8196 list qos-profile-identifier { 8197 key id; 8198 leaf id { 8199 type string; 8200 description 8201 "Identification of the QoS Profile to be used. 8202 Local administration meaning."; 8203 } 8204 description 8205 "List for QoS Profile Identifiers."; 8207 } 8209 list bfd-profile-identifier { 8210 key id; 8211 leaf id { 8212 type string; 8213 description 8214 "Identification of the SP BFD Profile to be used. 8215 Local administration meaning."; 8216 } 8217 description 8218 "List for BFD profile Identifiers."; 8219 } 8220 nacm:default-deny-write; 8221 description 8222 "Container for Valid Provider Identifies."; 8223 } 8224 description 8225 "Grouping for VPN Profile configuration."; 8226 } 8227 grouping vpn-svc-cfg { 8228 leaf vpn-id { 8229 type svc-id; 8230 description 8231 "VPN identifier. Local administration meaning."; 8232 } 8233 leaf customer-name { 8234 type string; 8235 description 8236 "Name of the customer which actually uses vpn service. 8237 In the case that any intermediary (e.g. Tier-2 provider 8238 or partner) sells the vpn service to their enduser 8239 on behalf of the original service provider (e.g. Tier-1 8240 provider), the original service provider may require the 8241 customer name to provide smooth activation/commitioning 8242 and operation for the service."; 8243 } 8244 leaf vpn-service-topology { 8245 type identityref { 8246 base vpn-topology; 8247 } 8248 default any-to-any; 8249 description 8250 "VPN service topology."; 8251 } 8252 uses vpn-service-cloud-access; 8253 uses vpn-service-multicast; 8254 uses vpn-service-mpls; 8256 uses vpn-extranet; 8257 description 8259 "Grouping for VPN service configuration."; 8260 } 8261 grouping site-top-level-cfg { 8262 uses operational-requirements; 8263 uses customer-location-info; 8264 uses site-devices; 8265 uses site-diversity; 8266 uses site-management; 8267 uses site-vpn-policy; 8268 uses site-vpn-flavor; 8269 uses site-maximum-routes; 8270 uses site-security; 8271 uses site-service; 8272 uses site-protection; 8273 uses site-routing; 8274 description 8275 "Grouping for site top-level configuration."; 8276 } 8277 grouping site-network-access-top-level-cfg { 8278 leaf site-network-access-type { 8279 type identityref { 8280 base site-network-access-type; 8281 } 8282 default point-to-point; 8283 description 8284 "Describes the type of connection, e.g., 8285 point-to-point or multipoint."; 8286 } 8287 choice location-flavor { 8288 case location { 8289 when "derived-from-or-self(../../management/type, "+ 8290 "'l3vpn-svc:customer-managed')" { 8291 description 8292 "Applicable only for customer-managed device."; 8293 } 8294 leaf location-reference { 8295 type leafref { 8296 path "../../../locations/location/location-id"; 8297 } 8298 description 8299 "Location of the site-network-access."; 8300 } 8301 } 8302 case device { 8303 when "derived-from-or-self(../../management/type, "+ 8305 "'l3vpn-svc:provider-managed') or "+ 8306 "derived-from-or-self(../../management/type, "+ 8307 "'l3vpn-svc:co-managed')" { 8309 description 8310 "Applicable only for provider-managed or co-managed device."; 8311 } 8312 leaf device-reference { 8313 type leafref { 8314 path "../../../devices/device/device-id"; 8315 } 8316 description 8317 "Identifier of CE to use."; 8318 } 8319 } 8320 mandatory true; 8321 description 8322 "Choice of how to describe the site's location."; 8323 } 8324 uses access-diversity; 8325 uses site-attachment-bearer; 8326 uses site-attachment-ip-connection; 8327 uses site-security; 8328 uses site-network-access-service; 8329 uses site-routing; 8330 uses site-attachment-availability; 8331 uses access-vpn-policy; 8332 description 8333 "Grouping for site network access top-level configuration."; 8334 } 8335 /* Main blocks */ 8336 container l3vpn-svc { 8337 container vpn-profiles { 8338 uses vpn-profile-cfg; 8339 description 8340 "Container for VPN Profiles."; 8341 } 8342 container vpn-services { 8343 list vpn-service { 8344 key vpn-id; 8345 uses vpn-svc-cfg; 8346 description 8347 "List of VPN services."; 8348 } 8349 description 8350 "Top-level container for the VPN services."; 8351 } 8352 container sites { 8354 list site { 8355 key site-id; 8356 leaf site-id { 8357 type svc-id; 8359 description 8360 "Identifier of the site."; 8361 } 8362 uses site-top-level-cfg; 8363 uses operational-requirements-ops; 8364 container site-network-accesses { 8365 list site-network-access { 8366 key site-network-access-id; 8367 leaf site-network-access-id { 8368 type svc-id; 8369 description 8370 "Identifier for the access."; 8371 } 8372 uses site-network-access-top-level-cfg; 8373 description 8374 "List of accesses for a site."; 8375 } 8376 description 8377 "List of accesses for a site."; 8378 } 8379 description 8380 "List of sites."; 8381 } 8382 description 8383 "Container for sites."; 8384 } 8385 description 8386 "Main container for L3VPN service configuration."; 8387 } 8388 } 8389 8391 10. Security Considerations 8393 The YANG module defined in this document MAY be accessed via the 8394 RESTCONF protocol [RFC8040] or the NETCONF protocol [RFC6241]. The 8395 lowest RESTCONF or NETCONF layer requires that the transport-layer 8396 protocol provide both data integrity and confidentiality; see 8397 Section 2 in [RFC8040] and Section 2 in [RFC6241]. The client MUST 8398 carefully examine the certificate presented by the server to 8399 determine if it meets the client's expectations, and the server MUST 8400 authenticate client and authorize access to any protected resource. 8401 The client identity derived from the authentication mechanism used is 8402 subject to the NETCONF Access Control Model (NACM) [RFC6536]. Other 8403 protocols that are used to access this YANG module are also required 8404 to support similar security mechanisms. 8406 The data nodes defined in the "ietf-l3vpn-svc" YANG module MUST be 8407 carefully created, read, updated, or deleted as appropriate. The 8408 entries in the lists below include customer-proprietary or 8409 confidential information; therefore, access to confidential 8410 information MUST be limited to authorized clients, and other clients 8411 MUST NOT be permitted to access the information. 8413 o /l3vpn-svc/vpn-services/vpn-service 8415 o /l3vpn-svc/sites/site 8417 The data model defines some security parameters than can be extended 8418 via augmentation as part of the customer service request; those 8419 parameters are described in Section 6.9. 8421 11. IANA Considerations 8423 IANA has assigned a new URI from the "IETF XML Registry" [RFC3688]. 8425 URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc 8426 Registrant Contact: The IESG 8427 XML: N/A; the requested URI is an XML namespace. 8429 IANA has recorded a YANG module name in the "YANG Module Names" 8430 registry [RFC7950] as follows: 8432 Name: ietf-l3vpn-svc 8433 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc 8434 Prefix: l3vpn-svc 8435 Reference: RFC 8049 8437 IANA is requested to update this registry to reference this document 8438 on publication as an RFC. 8440 12. References 8442 12.1. Normative References 8444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 8445 Requirement Levels", BCP 14, RFC 2119, 8446 DOI 10.17487/RFC2119, March 1997, 8447 . 8449 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 8450 DOI 10.17487/RFC3688, January 2004, 8451 . 8453 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 8454 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 8455 2006, . 8457 [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the 8458 Provider/Customer Edge Protocol for BGP/MPLS IP Virtual 8459 Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, 8460 June 2006, . 8462 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 8463 Address Autoconfiguration", RFC 4862, 8464 DOI 10.17487/RFC4862, September 2007, 8465 . 8467 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 8468 and A. Bierman, Ed., "Network Configuration Protocol 8469 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 8470 . 8472 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 8473 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 8474 2012, . 8476 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 8477 Protocol (NETCONF) Access Control Model", RFC 6536, 8478 DOI 10.17487/RFC6536, March 2012, 8479 . 8481 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 8482 RFC 7950, DOI 10.17487/RFC7950, August 2016, 8483 . 8485 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 8486 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 8487 . 8489 [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 8490 Model for L3VPN Service Delivery", RFC 8049, 8491 DOI 10.17487/RFC8049, February 2017, 8492 . 8494 12.2. Informative References 8496 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 8497 Private Network (VPN) Terminology", RFC 4026, 8498 DOI 10.17487/RFC4026, March 2005, 8499 . 8501 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 8502 Provider-Provisioned Virtual Private Networks (PPVPNs)", 8503 RFC 4110, DOI 10.17487/RFC4110, July 2005, 8504 . 8506 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 8507 "Multiprotocol Extensions for BGP-4", RFC 4760, 8508 DOI 10.17487/RFC4760, January 2007, 8509 . 8511 Appendix A. Acknowledgements 8513 Maxim Klyus, Luis Miguel Contreras, Gregory Mirsky, Zitao Wang, Jing 8514 Zhao, Kireeti Kompella, Eric Rosen, Aijun Wang,Michael Scharf, Xufeng 8515 Liu, David Ball, Lucy Yong, Jean-Philippe Landry, and Andrew Leu 8516 provided useful review to this document. 8518 Jan Lindblad reviewed the first release of RFC8049 and found some 8519 bugs and His thorough YANG Doctor review on the YANG Model is 8520 valuable input to revision of RFC8049. David ball also provided a 8521 second review on published RFC8049. 8523 Many thanks to these people. 8525 Appendix B. Contributors 8527 The authors would like to thank Rob Shakir for his major 8528 contributions to the initial modeling and use cases. 8530 Adrian Farrel prepared the editorial revisions for this bis. 8532 Authors' Addresses 8534 Qin Wu (editor) 8535 Huawei Technologies 8537 Email: bill.wu@huawei.com 8539 Stephane Litkowski 8540 Orange Business Services 8542 Email: stephane.litkowski@orange.com 8544 Luis Tomotaki 8545 Verizon 8547 Email: luis.tomotaki@verizon.com 8549 Kenichi Ogaki 8550 KDDI Corporation 8552 Email: ke-oogaki@kddi.com