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