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