idnits 2.17.00 (12 Aug 2021) /tmp/idnits42455/draft-ietf-l3sm-l3vpn-service-model-19.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4364], [RFC4026], [RFC4110]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 409 has weird spacing: '...ntifier str...' == Line 419 has weird spacing: '...site-id leafr...' == Line 422 has weird spacing: '...site-id leafr...' == Line 465 has weird spacing: '...tion-id svc-...' == Line 473 has weird spacing: '...vice-id svc-...' == (16 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The management system SHOULD honor the customer constraints, if the constraint is too strict and can not be filled, the management system MUST not provision the site and SHOULD provide an information to the user. How the information is provided is out of scope of the document. It would then be up to the user to relax the constraint or not. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: pe-diverse: the current site-network-access MUST not be connected to the same PE as the targeted site-network-accesses. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: pop-diverse: the current site-network-access MUST not be connected to the same PoP as the targeted site-network-accesses. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: linecard-diverse: the current site-network-access MUST not be connected to the same linecard as the targeted site-network-accesses. -- The document date (November 04, 2016) is 2017 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) == Missing Reference: 'VPN2' is mentioned on line 1600, but not defined == Missing Reference: 'VPN3' is mentioned on line 1609, but not defined == Outdated reference: draft-ietf-netconf-restconf has been published as RFC 8040 ** Downref: Normative reference to an Informational RFC: RFC 4026 ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 3 errors (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3SM Working Group S. Litkowski 3 Internet-Draft Orange Business Services 4 Intended status: Standards Track L. Tomotaki 5 Expires: May 8, 2017 Verizon 6 K. Ogaki 7 KDDI 8 November 04, 2016 10 YANG Data Model for L3VPN service delivery 11 draft-ietf-l3sm-l3vpn-service-model-19 13 Abstract 15 This document defines a YANG data model that can be used for 16 communication between customers and network operators and to deliver 17 a Layer 3 Provider Provisioned VPN service. The document is limited 18 to the BGP PE-based VPNs as described in [RFC4026], [RFC4110] and 19 [RFC4364]. This model is intended to be instantiated at management 20 system to deliver the overall service. This model is not a 21 configuration model to be used directly on network elements. This 22 model provides an abstracted view of the Layer 3 IPVPN service 23 configuration components. It will be up to a management system to 24 take this as an input and use specific configurations models to 25 configure the different network elements to deliver the service. How 26 configuration of network elements is done is out of scope of the 27 document. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in [RFC2119]. 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 http://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 May 8, 2017. 51 Copyright Notice 53 Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 5 71 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 4. Layer 3 IP VPN service model . . . . . . . . . . . . . . . . 7 74 5. Service data model usage . . . . . . . . . . . . . . . . . . 8 75 6. Design of the Data Model . . . . . . . . . . . . . . . . . . 9 76 6.1. Features and augmentation . . . . . . . . . . . . . . . . 16 77 6.2. VPN service overview . . . . . . . . . . . . . . . . . . 17 78 6.2.1. VPN service topology . . . . . . . . . . . . . . . . 17 79 6.2.1.1. Route Target allocation . . . . . . . . . . . . . 17 80 6.2.1.2. Any to any . . . . . . . . . . . . . . . . . . . 18 81 6.2.1.3. Hub and Spoke . . . . . . . . . . . . . . . . . . 18 82 6.2.1.4. Hub and Spoke disjoint . . . . . . . . . . . . . 19 83 6.2.2. Cloud access . . . . . . . . . . . . . . . . . . . . 20 84 6.2.3. Multicast service . . . . . . . . . . . . . . . . . . 22 85 6.2.4. Extranet VPNs . . . . . . . . . . . . . . . . . . . . 24 86 6.3. Site overview . . . . . . . . . . . . . . . . . . . . . . 25 87 6.3.1. Devices and locations . . . . . . . . . . . . . . . . 26 88 6.3.2. Site network accesses . . . . . . . . . . . . . . . . 27 89 6.3.2.1. Bearer . . . . . . . . . . . . . . . . . . . . . 28 90 6.3.2.2. Connection . . . . . . . . . . . . . . . . . . . 28 91 6.3.2.3. Inheritance of parameters between site and site- 92 network-access . . . . . . . . . . . . . . . . . 29 93 6.4. Site role . . . . . . . . . . . . . . . . . . . . . . . . 30 94 6.5. Site belonging to multiple VPNs . . . . . . . . . . . . . 30 95 6.5.1. Site vpn flavor . . . . . . . . . . . . . . . . . . . 30 96 6.5.1.1. Single VPN attachment : site-vpn-flavor-single . 30 97 6.5.1.2. Multi VPN attachment : site-vpn-flavor-multi . . 31 98 6.5.1.3. Sub VPN attachment : site-vpn-flavor-sub . . . . 31 99 6.5.1.4. NNI : site-vpn-flavor-nni . . . . . . . . . . . . 33 100 6.5.2. Attaching a site to a VPN . . . . . . . . . . . . . . 34 101 6.5.2.1. Reference a VPN . . . . . . . . . . . . . . . . . 35 102 6.5.2.2. VPN policy . . . . . . . . . . . . . . . . . . . 35 103 6.6. Deciding where to connect the site . . . . . . . . . . . 38 104 6.6.1. Constraint: Device . . . . . . . . . . . . . . . . . 39 105 6.6.2. Constraint/parameter: Site location . . . . . . . . . 39 106 6.6.3. Constraint/parameter: access type . . . . . . . . . . 41 107 6.6.4. Constraint: access diversity . . . . . . . . . . . . 41 108 6.6.5. Impossible access placement . . . . . . . . . . . . . 47 109 6.6.6. Examples of access placement . . . . . . . . . . . . 48 110 6.6.6.1. Multihoming . . . . . . . . . . . . . . . . . . . 48 111 6.6.6.2. Site offload . . . . . . . . . . . . . . . . . . 50 112 6.6.6.3. Parallel links . . . . . . . . . . . . . . . . . 56 113 6.6.6.4. SubVPN with multihoming . . . . . . . . . . . . . 57 114 6.6.7. Route Distinguisher and VRF allocation . . . . . . . 61 115 6.7. Site network access availability . . . . . . . . . . . . 62 116 6.8. Traffic protection . . . . . . . . . . . . . . . . . . . 63 117 6.9. Security . . . . . . . . . . . . . . . . . . . . . . . . 64 118 6.9.1. Authentication . . . . . . . . . . . . . . . . . . . 64 119 6.9.2. Encryption . . . . . . . . . . . . . . . . . . . . . 64 120 6.10. Management . . . . . . . . . . . . . . . . . . . . . . . 65 121 6.11. Routing protocols . . . . . . . . . . . . . . . . . . . . 66 122 6.11.1. Dual stack handling . . . . . . . . . . . . . . . . 66 123 6.11.2. Direct LAN connection onto SP network . . . . . . . 67 124 6.11.3. Direct LAN connection onto SP network with 125 redundancy . . . . . . . . . . . . . . . . . . . . . 67 126 6.11.4. Static routing . . . . . . . . . . . . . . . . . . . 68 127 6.11.5. RIP routing . . . . . . . . . . . . . . . . . . . . 68 128 6.11.6. OSPF routing . . . . . . . . . . . . . . . . . . . . 68 129 6.11.7. BGP routing . . . . . . . . . . . . . . . . . . . . 70 130 6.12. Service . . . . . . . . . . . . . . . . . . . . . . . . . 71 131 6.12.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . 71 132 6.12.2. QoS . . . . . . . . . . . . . . . . . . . . . . . . 72 133 6.12.2.1. QoS classification . . . . . . . . . . . . . . . 72 134 6.12.2.2. QoS profile . . . . . . . . . . . . . . . . . . 75 135 6.12.3. Multicast . . . . . . . . . . . . . . . . . . . . . 79 136 6.13. Enhanced VPN features . . . . . . . . . . . . . . . . . . 79 137 6.13.1. Carrier's Carrier . . . . . . . . . . . . . . . . . 79 138 6.14. External ID references . . . . . . . . . . . . . . . . . 81 139 6.15. Defining NNIs . . . . . . . . . . . . . . . . . . . . . . 81 140 6.15.1. Defining NNI with option A flavor . . . . . . . . . 83 141 6.15.2. Defining NNI with option B flavor . . . . . . . . . 86 142 6.15.3. Defining NNI with option C flavor . . . . . . . . . 88 143 7. Service model usage example . . . . . . . . . . . . . . . . . 90 144 8. Interaction with Other YANG Modules . . . . . . . . . . . . . 95 145 9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 99 146 10. Security Considerations . . . . . . . . . . . . . . . . . . . 153 147 11. Contribution . . . . . . . . . . . . . . . . . . . . . . . . 154 148 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 154 149 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 154 150 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 154 151 14.1. Changes between versions -18 and-19 . . . . . . . . . . 154 152 14.2. Changes between versions -17 and-18 . . . . . . . . . . 155 153 14.3. Changes between versions -16 and-17 . . . . . . . . . . 155 154 14.4. Changes between versions -15 and-16 . . . . . . . . . . 156 155 14.5. Changes between versions -13 and-14 . . . . . . . . . . 156 156 14.6. Changes between versions -12 and-13 . . . . . . . . . . 156 157 14.7. Changes between versions -11 and-12 . . . . . . . . . . 156 158 14.8. Changes between versions -09 and-10 . . . . . . . . . . 156 159 14.9. Changes between versions -08 and-09 . . . . . . . . . . 157 160 14.10. Changes between versions -07 and-08 . . . . . . . . . . 157 161 14.11. Changes between versions -06 and-07 . . . . . . . . . . 157 162 14.12. Changes between versions -05 and-06 . . . . . . . . . . 157 163 14.13. Changes between versions -04 and-05 . . . . . . . . . . 158 164 14.14. Changes between versions -02 and-03 . . . . . . . . . . 158 165 14.15. Changes between versions -01 and-02 . . . . . . . . . . 158 166 14.16. Changes between versions -00 and-01 . . . . . . . . . . 159 167 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 159 168 15.1. Normative References . . . . . . . . . . . . . . . . . . 159 169 15.2. Informative References . . . . . . . . . . . . . . . . . 161 170 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 161 172 1. Introduction 174 This document defines a Layer 3 VPN service data model written in 175 YANG. The model defines service configuration elements that can be 176 used in communication protocols between customers and network 177 operators. Those elements can be used also as input to automated 178 control and configuration applications. 180 1.1. Terminology 182 The following terms are defined in [RFC6241] and are not redefined 183 here: 185 o client 187 o configuration data 189 o server 191 o state data 192 The following terms are defined in [RFC7950] and are not redefined 193 here: 195 o augment 197 o data model 199 o data node 201 The terminology for describing YANG data models is found in 202 [RFC7950]. 204 This document presents some configuration examples using XML 205 representation. 207 1.2. Tree diagram 209 A simplified graphical representation of the data model is presented 210 in Section 6. 212 The meaning of the symbols in these diagrams is as follows: 214 o Brackets "[" and "]" enclose list keys. 216 o Curly braces "{" and "}" contain names of optional features that 217 make the corresponding node conditional. 219 o Abbreviations before data node names: "rw" means configuration 220 (read-write), and "ro" state data (read-only). 222 o Symbols after data node names: "?" means an optional node and "*" 223 denotes a "list" or "leaf-list". 225 o Parentheses enclose choice and case nodes, and case nodes are also 226 marked with a colon (":"). 228 o Ellipsis ("...") stands for contents of subtrees that are not 229 shown. 231 2. Acronyms 233 AAA: Authentication, Authorization, Accounting. 235 ACL: Access Control List. 237 ASM: Any-Source Multicast. 239 BFD: Bidirectional Forwarding Detection. 241 BGP: Border Gateway Protocol. 243 CE: Customer Edge. 245 CLI: Command Line Interface. 247 CsC: Carrier's Carrier. 249 CSP: Cloud Service Provider. 251 DHCP: Dynamic Host Configuration Protocol. 253 IGMP: Internet Group Management Protocol. 255 LAN: Local Area Network. 257 MLD: Multicast Listener Discovery. 259 MTU: Maximum Transmission Unit. 261 NAT: Network Address Translation. 263 NNI: Network to Network Interface. 265 OAM: Operation Administration and Management. 267 OSPF: Open Shortest Path First. 269 OSS: Operations Support System. 271 PE: Provider Edge. 273 POP: Point Of Presence. 275 PIM: Protocol Independent Multicast. 277 QoS: Quality Of Service. 279 RIP: Routing Information Protocol. 281 RD: Route Distinguisher. 283 RP: Rendez-vous Point. 285 RT: Route Target. 287 SLA: Service Level Agreement. 289 SLAAC: Stateless Address AutoConfiguration. 291 SP: Service Provider. 293 SSM: Source-Specific Multicast. 295 VPN: Virtual Private Network. 297 VRF: VPN Routing and Forwarding. 299 VRRP: Virtual Router Redundancy Protocol. 301 3. Definitions 303 Customer Edge (CE) Device: Equipment that is dedicated to a 304 particular customer and is directly connected (at layer 3) to one or 305 more PE devices via attachment circuits. A CE is usually located at 306 the customer premises, and is usually dedicated to a single VPN, 307 although it may support multiple VPNs if each one has separate 308 attachment circuits. 310 Provider Edge (PE) Device: Equipment managed by the Service Provider 311 (SP) that can support multiple VPNs for different customers, and is 312 directly connected (at layer 3) to one or more CE devices via 313 attachment circuits. A PE is usually located at an SP point of 314 presence (PoP) and is managed by the SP. 316 PE-Based VPNs: The PE devices know that certain traffic is VPN 317 traffic. They forward the traffic (through tunnels) based on the 318 destination IP address of the packet, and optionally on based on 319 other information in the IP header of the packet. The PE devices are 320 themselves the tunnel endpoints. The tunnels may make use of various 321 encapsulations to send traffic over the SP network (such as, but not 322 restricted to, GRE, IP-in-IP, IPsec, or MPLS tunnels). 324 4. Layer 3 IP VPN service model 326 A layer 3 IPVPN service is a collection of sites that are authorized 327 to exchange traffic between each other over a shared IP 328 infrastructure. This layer 3 VPN service model aims at providing a 329 common understanding on how the corresponding IP VPN service is to be 330 deployed over the shared infrastructure. This service model is 331 limited to BGP PE-Based VPNs as described in [RFC4110] and [RFC4364]. 333 5. Service data model usage 335 L3VPN-SVC | 336 MODEL | 337 | 338 +------------------+ +-----+ 339 | Orchestration | < --- > | OSS | 340 +------------------+ +-----+ 341 | | 342 +----------------+ | 343 | Config manager | | 344 +----------------+ | 345 | | 346 | Netconf/CLI ... 347 | | 348 +------------------------------------------------+ 349 Network 351 +++++++ 352 + AAA + 353 +++++++ 355 ++++++++ Bearer ++++++++ ++++++++ ++++++++ 356 + CE A + ------- + PE A + + PE B + ---- + CE B + 357 ++++++++ Cnct ++++++++ ++++++++ ++++++++ 359 Site A Site B 361 The idea of the L3 IPVPN service model is to propose an abstracted 362 interface between customers and network operators to manage 363 configuration of components of a L3VPN service. A typical usage is 364 to use this model as an input for an orchestration layer who will be 365 responsible to translate it to orchestrated configuration of network 366 elements who will be part of the service. The network elements can 367 be routers, but also servers (like AAA), and not limited to these 368 examples. The configuration of network elements can be done by the 369 CLI, or by NETCONF ([RFC6241])/RESTCONF ([I-D.ietf-netconf-restconf]) 370 coupled with specific configuration YANG data models (BGP, VRF, BFD 371 ...) or any other way. 373 The usage of this service model is not limited to this example, it 374 can be used by any component of the management system but not 375 directly by network elements. 377 6. Design of the Data Model 379 The YANG module is divided in two main containers : vpn-services, 380 sites. 382 The vpn-service under vpn-services defines global parameters for the 383 VPN service for a specific customer. 385 A site is composed of at least one site-network-access and may have 386 multiple site-network-access in case of multihoming. The site- 387 network-access attachment is done through a bearer with an IP 388 connection on top. The bearer refers to properties of the attachment 389 that are below layer 3 while the connection refers to layer 3 390 protocol oriented properties. The bearer may be allocated 391 dynamically by the service provider and the customer may provide some 392 constraints or parameters to drive the placement. 394 Authorization of traffic exchange is done through what we call a VPN 395 policy or VPN service topology defining routing exchange rules 396 between sites. 398 The figure below describe the overall structure of the YANG module: 400 module: ietf-l3vpn-svc 401 +--rw l3vpn-svc 402 +--rw vpn-services 403 | +--rw vpn-service* [vpn-id] 404 | +--rw vpn-id svc-id 405 | +--rw customer-name? string 406 | +--rw vpn-service-topology? identityref 407 | +--rw cloud-accesses {cloud-access}? 408 | | +--rw cloud-access* [cloud-identifier] 409 | | +--rw cloud-identifier string 410 | | +--rw (list-flavor)? 411 | | | +--:(permit-any) 412 | | | | +--rw permit-any? empty 413 | | | +--:(deny-any-except) 414 | | | | +--rw permit-site* leafref 415 | | | +--:(permit-any-except) 416 | | | +--rw deny-site* leafref 417 | | +--rw authorized-sites 418 | | | +--rw authorized-site* [site-id] 419 | | | +--rw site-id leafref 420 | | +--rw denied-sites 421 | | | +--rw denied-site* [site-id] 422 | | | +--rw site-id leafref 423 | | +--rw address-translation 424 | | +--rw nat44 425 | | +--rw enabled? boolean 426 | | +--rw nat44-customer-address? inet:ipv4-address 427 | +--rw multicast {multicast}? 428 | | +--rw enabled? boolean 429 | | +--rw customer-tree-flavors 430 | | | +--rw tree-flavor* identityref 431 | | +--rw rp 432 | | +--rw rp-group-mappings 433 | | | +--rw rp-group-mapping* [id] 434 | | | +--rw id uint16 435 | | | +--rw provider-managed 436 | | | | +--rw enabled? boolean 437 | | | | +--rw rp-redundancy? boolean 438 | | | | +--rw optimal-traffic-delivery? boolean 439 | | | +--rw rp-address? inet:ip-address 440 | | | +--rw groups 441 | | | +--rw group* [id] 442 | | | +--rw id uint16 443 | | | +--rw (group-format)? 444 | | | +--:(startend) 445 | | | | +--rw group-start? inet:ip-address 446 | | | | +--rw group-end? inet:ip-address 447 | | | +--:(singleaddress) 448 | | | +--rw group-address? inet:ip-address 449 | | +--rw rp-discovery 450 | | +--rw rp-discovery-type? identityref 451 | | +--rw bsr-candidates 452 | | +--rw bsr-candidate-address* inet:ip-address 453 | +--rw carrierscarrier? boolean {carrierscarrier}? 454 | +--rw extranet-vpns {extranet-vpn}? 455 | +--rw extranet-vpn* [vpn-id] 456 | +--rw vpn-id svc-id 457 | +--rw local-sites-role? identityref 458 +--rw sites 459 +--rw site* [site-id] 460 +--rw site-id svc-id 461 +--rw requested-site-start? yang:date-and-time 462 +--rw requested-site-stop? yang:date-and-time 463 +--rw locations 464 | +--rw location* [location-id] 465 | +--rw location-id svc-id 466 | +--rw address? string 467 | +--rw postal-code? string 468 | +--rw state? string 469 | +--rw city? string 470 | +--rw country-code? string 471 +--rw devices 472 | +--rw device* [device-id] 473 | +--rw device-id svc-id 474 | +--rw location? leafref 475 | +--rw management 476 | +--rw address-family? address-family 477 | +--rw address? inet:ip-address 478 +--rw site-diversity {site-diversity}? 479 | +--rw groups 480 | +--rw group* [group-id] 481 | +--rw group-id string 482 +--rw management 483 | +--rw type? identityref 484 +--rw vpn-policies 485 | +--rw vpn-policy* [vpn-policy-id] 486 | +--rw vpn-policy-id svc-id 487 | +--rw entries* [id] 488 | +--rw id svc-id 489 | +--rw filter 490 | | +--rw (lan)? 491 | | +--:(prefixes) 492 | | | +--rw ipv4-lan-prefix* inet:ipv4-prefix {ipv4}? 493 | | | +--rw ipv6-lan-prefix* inet:ipv6-prefix {ipv6}? 494 | | +--:(lan-tag) 495 | | +--rw lan-tag* string 496 | +--rw vpn 497 | +--rw vpn-id leafref 498 | +--rw site-role? identityref 499 +--rw site-vpn-flavor? identityref 500 +--rw maximum-routes 501 | +--rw address-family* [af] 502 | +--rw af address-family 503 | +--rw maximum-routes? uint32 504 +--rw security 505 | +--rw authentication 506 | +--rw encryption {encryption}? 507 | +--rw enabled? boolean 508 | +--rw layer enumeration 509 | +--rw encryption-profile 510 | +--rw (profile)? 511 | +--:(provider-profile) 512 | | +--rw profile-name? string 513 | +--:(customer-profile) 514 | +--rw algorithm? string 515 | +--rw (key-type)? 516 | +--:(psk) 517 | | +--rw preshared-key? string 518 | +--:(pki) 519 +--rw service 520 | +--rw qos {qos}? 521 | | +--rw qos-classification-policy 522 | | | +--rw rule* [id] 523 | | | +--rw id uint16 524 | | | +--rw (match-type)? 525 | | | | +--:(match-flow) 526 | | | | | +--rw match-flow 527 | | | | | +--rw dscp? inet:dscp 528 | | | | | +--rw dot1p? uint8 529 | | | | | +--rw ipv4-src-prefix? inet:ipv4-prefix 530 | | | | | +--rw ipv6-src-prefix? inet:ipv6-prefix 531 | | | | | +--rw ipv4-dst-prefix? inet:ipv4-prefix 532 | | | | | +--rw ipv6-dst-prefix? inet:ipv6-prefix 533 | | | | | +--rw l4-src-port? inet:port-number 534 | | | | | +--rw target-sites* svc-id 535 | | | | | +--rw l4-src-port-range 536 | | | | | | +--rw lower-port? inet:port-number 537 | | | | | | +--rw upper-port? inet:port-number 538 | | | | | +--rw l4-dst-port? inet:port-number 539 | | | | | +--rw l4-dst-port-range 540 | | | | | | +--rw lower-port? inet:port-number 541 | | | | | | +--rw upper-port? inet:port-number 542 | | | | | +--rw protocol-field? union 543 | | | | +--:(match-application) 544 | | | | +--rw match-application? identityref 545 | | | +--rw target-class-id? string 546 | | +--rw qos-profile 547 | | +--rw (qos-profile)? 548 | | +--:(standard) 549 | | | +--rw profile? string 550 | | +--:(custom) 551 | | +--rw classes {qos-custom}? 552 | | +--rw class* [class-id] 553 | | +--rw class-id string 554 | | +--rw rate-limit? uint8 555 | | +--rw latency 556 | | | +--rw (flavor)? 557 | | | ... 558 | | +--rw jitter 559 | | | +--rw (flavor)? 560 | | | ... 561 | | +--rw bandwidth 562 | | +--rw guaranteed-bw-percent? uint8 563 | | +--rw end-to-end? empty 564 | +--rw carrierscarrier {carrierscarrier}? 565 | | +--rw signalling-type? enumeration 566 | +--rw multicast {multicast}? 567 | +--rw multicast-site-type? enumeration 568 | +--rw multicast-address-family 569 | | +--rw ipv4? boolean {ipv4}? 570 | | +--rw ipv6? boolean {ipv6}? 571 | +--rw protocol-type? enumeration 572 +--rw traffic-protection {fast-reroute}? 573 | +--rw enabled? boolean 574 +--rw routing-protocols 575 | +--rw routing-protocol* [type] 576 | +--rw type identityref 577 | +--rw ospf {rtg-ospf}? 578 | | +--rw address-family* address-family 579 | | +--rw area-address? yang:dotted-quad 580 | | +--rw metric? uint16 581 | | +--rw sham-links {rtg-ospf-sham-link}? 582 | | +--rw sham-link* [target-site] 583 | | +--rw target-site svc-id 584 | | +--rw metric? uint16 585 | +--rw bgp {rtg-bgp}? 586 | | +--rw autonomous-system? uint32 587 | | +--rw address-family* address-family 588 | +--rw static 589 | | +--rw cascaded-lan-prefixes 590 | | +--rw ipv4-lan-prefixes* [lan next-hop] {ipv4}? 591 | | | +--rw lan inet:ipv4-prefix 592 | | | +--rw lan-tag? string 593 | | | +--rw next-hop inet:ipv4-address 594 | | +--rw ipv6-lan-prefixes* [lan next-hop] {ipv6}? 595 | | +--rw lan inet:ipv6-prefix 596 | | +--rw lan-tag? string 597 | | +--rw next-hop inet:ipv6-address 598 | +--rw rip {rtg-rip}? 599 | | +--rw address-family* address-family 600 | +--rw vrrp {rtg-vrrp}? 601 | +--rw address-family* address-family 602 +--ro actual-site-start? yang:date-and-time 603 +--ro actual-site-stop? yang:date-and-time 604 +--rw site-network-accesses 605 +--rw site-network-access* [site-network-access-id] 606 +--rw site-network-access-id svc-id 607 +--rw site-network-access-type? identityref 608 +--rw (location-flavor) 609 | +--:(location) 610 | | +--rw location-reference? leafref 611 | +--:(device) 612 | +--rw device-reference? leafref 613 +--rw access-diversity {site-diversity}? 614 | +--rw groups 615 | | +--rw group* [group-id] 616 | | +--rw group-id string 617 | +--rw constraints 618 | +--rw constraint* [constraint-type] 619 | +--rw constraint-type identityref 620 | +--rw target 621 | +--rw (target-flavor)? 622 | +--:(id) 623 | | +--rw group* [group-id] 624 | | ... 625 | +--:(all-accesses) 626 | | +--rw all-other-accesses? empty 627 | +--:(all-groups) 628 | +--rw all-other-groups? empty 629 +--rw bearer 630 | +--rw requested-type {requested-type}? 631 | | +--rw requested-type? string 632 | | +--rw strict? boolean 633 | +--rw always-on? boolean {always-on}? 634 | +--rw bearer-reference? string {bearer-reference}? 635 +--rw ip-connection 636 | +--rw ipv4 {ipv4}? 637 | | +--rw address-allocation-type? identityref 638 | | +--rw number-of-dynamic-address? uint8 639 | | +--rw dhcp-relay 640 | | | +--rw customer-dhcp-servers 641 | | | +--rw server-ip-address* inet:ipv4-address 642 | | +--rw addresses 643 | | +--rw provider-address? inet:ipv4-address 644 | | +--rw customer-address? inet:ipv4-address 645 | | +--rw mask? uint8 646 | +--rw ipv6 {ipv6}? 647 | | +--rw address-allocation-type? identityref 648 | | +--rw number-of-dynamic-address? uint8 649 | | +--rw dhcp-relay 650 | | | +--rw customer-dhcp-servers 651 | | | +--rw server-ip-address* inet:ipv6-address 652 | | +--rw addresses 653 | | +--rw provider-address? inet:ipv6-address 654 | | +--rw customer-address? inet:ipv6-address 655 | | +--rw mask? uint8 656 | +--rw oam 657 | +--rw bfd {bfd}? 658 | +--rw enabled? boolean 659 | +--rw (holdtime)? 660 | +--:(profile) 661 | | +--rw profile-name? string 662 | +--:(fixed) 663 | +--rw fixed-value? uint32 664 +--rw security 665 | +--rw authentication 666 | +--rw encryption {encryption}? 667 | +--rw enabled? boolean 668 | +--rw layer enumeration 669 | +--rw encryption-profile 670 | +--rw (profile)? 671 | +--:(provider-profile) 672 | | +--rw profile-name? string 673 | +--:(customer-profile) 674 | +--rw algorithm? string 675 | +--rw (key-type)? 676 | +--:(psk) 677 | | ... 678 | +--:(pki) 679 +--rw service 680 | +--rw svc-input-bandwidth? uint32 681 | +--rw svc-output-bandwidth? uint32 682 | +--rw svc-mtu? uint16 683 | +--rw qos {qos}? 684 | | +--rw qos-classification-policy 685 | | | +--rw rule* [id] 686 | | | +--rw id uint16 687 | | | +--rw (match-type)? 688 | | | | +--:(match-flow) 689 | | | | | +--rw match-flow 690 | | | | | ... 691 | | | | +--:(match-application) 692 | | | | +--rw match-application? identityref 693 | | | +--rw target-class-id? string 694 | | +--rw qos-profile 695 | | +--rw (qos-profile)? 696 | | +--:(standard) 697 | | | +--rw profile? string 698 | | +--:(custom) 699 | | +--rw classes {qos-custom}? 700 | | +--rw class* [class-id] 701 | | ... 702 | +--rw carrierscarrier {carrierscarrier}? 703 | | +--rw signalling-type? enumeration 704 | +--rw multicast {multicast}? 705 | +--rw multicast-site-type? enumeration 706 | +--rw multicast-address-family 707 | | +--rw ipv4? boolean {ipv4}? 708 | | +--rw ipv6? boolean {ipv6}? 709 | +--rw protocol-type? enumeration 710 +--rw routing-protocols 711 | +--rw routing-protocol* [type] 712 | +--rw type identityref 713 | +--rw ospf {rtg-ospf}? 714 | | +--rw address-family* address-family 715 | | +--rw area-address? yang:dotted-quad 716 | | +--rw metric? uint16 717 | | +--rw sham-links {rtg-ospf-sham-link}? 718 | | +--rw sham-link* [target-site] 719 | | +--rw target-site svc-id 720 | | +--rw metric? uint16 721 | +--rw bgp {rtg-bgp}? 722 | | +--rw autonomous-system? uint32 723 | | +--rw address-family* address-family 724 | +--rw static 725 | | +--rw cascaded-lan-prefixes 726 | | +--rw ipv4-lan-prefixes* [lan next-hop] {ipv4}? 727 | | | +--rw lan inet:ipv4-prefix 728 | | | +--rw lan-tag? string 729 | | | +--rw next-hop inet:ipv4-address 730 | | +--rw ipv6-lan-prefixes* [lan next-hop] {ipv6}? 731 | | +--rw lan inet:ipv6-prefix 732 | | +--rw lan-tag? string 733 | | +--rw next-hop inet:ipv6-address 734 | +--rw rip {rtg-rip}? 735 | | +--rw address-family* address-family 736 | +--rw vrrp {rtg-vrrp}? 737 | +--rw address-family* address-family 738 +--rw availability 739 | +--rw access-priority? uint32 740 +--rw vpn-attachment 741 +--rw (attachment-flavor) 742 +--:(vpn-policy-id) 743 | +--rw vpn-policy-id? leafref 744 +--:(vpn-id) 745 +--rw vpn-id? leafref 746 +--rw site-role? identityref 748 6.1. Features and augmentation 750 The model implements a lot of features allowing implementations to be 751 modular. As example, an implementation may support only IPv4 VPNs 752 (ipv4 feature), IPv6 (ipv6 feature), or both (by advertising both 753 features). The routing protocols proposed to the customer may also 754 be enabled through features. This model proposes also some features 755 for more advanced options like : extranet-vpn support 756 (Section 6.2.4), site diversity (Section 6.6), qos (Section 6.12.2), 757 ... 759 In addition, as for any YANG model, this service model can be 760 augmented to implement new behaviors or specific features. For 761 example, this model proposes different options for the IP address 762 assignment, if those options are not filling all requirements, new 763 options can be added through augmentation. 765 6.2. VPN service overview 767 A vpn-service list item contains generic informations about the VPN 768 service. The vpn-id of the vpn-service refers to an internal 769 reference for this VPN service, while customer name refers to a more 770 explicit reference to the customer. This identifier is purely 771 internal to the organization responsible for the VPN service. 773 6.2.1. VPN service topology 775 The type of VPN service topology is required for configuration. 776 Current proposal supports: any-to-any, hub and spoke (where hubs can 777 exchange traffic), and hub and spoke disjoint (where hubs cannot 778 exchange traffic). New topologies could be added by augmentation. 779 By default, any-to-any VPN service topology is used. 781 6.2.1.1. Route Target allocation 783 Layer 3 PE-based VPN is built using route-targets as described in 784 [RFC4364]. It is expected the management system to allocate 785 automatically a set of route-targets upon a VPN service creation 786 request. How the management system allocates route-targets is out of 787 scope of the document but multiple ways could be envisaged as 788 described below. 790 Management system 791 <-------------------------------------------------> 792 Request RT 793 +-----------------------+ Topo a2a +----------+ 794 RESTCONF | | -----> | | 795 User ------------- | Service Orchestration | |NetworkOSS| 796 l3vpn-svc | | <----- | | 797 model +-----------------------+ Response +----------+ 798 RT1,RT2 800 In the example above, a service orchestration, owning the 801 instantiation of this service model, request route-targets to the 802 network OSS. Based on the requested VPN service topology, the 803 network OSS replies with one or multiple route-targets. The 804 interface between this service orchestration and network OSS is out 805 of scope of this document. 807 +---------------------------+ 808 RESTCONF | | 809 User ------------- | Service Orchestration | 810 l3vpn-svc | | 811 model | | 812 | RT pool : 10:1->10:10000 | 813 | RT pool : 20:50->20:5000 | 814 +---------------------------+ 816 In the example above, a service orchestration, owning the 817 instantiation of this service model, owns one or more pools of route- 818 target (specified by service provider) that can be allocated. Based 819 on the requested VPN service topology, it will allocate one or 820 multiple route-targets from the pool. 822 The mechanism displayed above are just examples and should not be 823 considered as an exhaustive list of solutions. 825 6.2.1.2. Any to any 827 +------------------------------------------------------------+ 828 | VPN1_Site1 ------ PE1 PE2 ------ VPN1_Site2 | 829 | | 830 | VPN1_Site3 ------ PE3 PE4 ------ VPN1_Site4 | 831 +------------------------------------------------------------+ 833 Figure - Any-to-any VPN service topology 835 In the any-to-any VPN service topology, all VPN sites can communicate 836 between each other without any restriction. It is expected that the 837 management system that receives an any-to-any IPVPN service request 838 through this model needs to assign and then configure the VRF and 839 route-targets on the appropriate PEs. In the any-to-any case, in 840 general a single route-target is required and every VRF imports and 841 exports this route-target. 843 6.2.1.3. Hub and Spoke 845 +-------------------------------------------------------------+ 846 | Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 | 847 | +----------------------------------+ 848 | | 849 | +----------------------------------+ 850 | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 | 851 +-------------------------------------------------------------+ 853 Figure - Hub and Spoke VPN service topology 855 In the hub and spoke VPN service topology, all spoke sites can 856 communicate only with Hub sites but not between each other, and hubs 857 can also communicate between each other. It is expected that the 858 management system that owns an any to any IPVPN service request 859 through this model, needs to assign and then configure the VRF and 860 route-targets on the appropriate PEs. In the hub and spoke case, in 861 general a two route-targets are required (one route-target for Hub 862 routes, one route-target for spoke routes). A Hub VRF, connecting 863 Hub sites, will export Hub routes with Hub route-target, and will 864 import Spoke routes through Spoke route-target. It will also import 865 the Hub route-target to allow Hub to Hub communication. A Spoke VRF, 866 connecting Spoke sites, will export Spoke routes with Spoke route- 867 target, and will import Hub routes through Hub route-target. 869 The management system MUST take into account Hub and Spoke 870 connections constraints. For example, if a management system decides 871 to mesh a spoke site and a hub site on the same PE, it needs to mesh 872 connections in different VRFs as displayed in the figure below. 874 Hub_Site ------- (VRF_Hub) PE1 875 (VRF_Spoke) 876 / | 877 Spoke_Site1 -------------------+ | 878 | 879 Spoke_Site2 -----------------------+ 881 6.2.1.4. Hub and Spoke disjoint 883 +-------------------------------------------------------------+ 884 | Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 | 885 +--------------------------+ +-------------------------------+ 886 | | 887 +--------------------------+ +-------------------------------+ 888 | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 | 889 +-------------------------------------------------------------+ 891 Figure - Hub and Spoke disjoint VPN service topology 893 In the Hub and Spoke disjoint VPN service topology, all Spoke sites 894 can communicate only with Hub sites but not between each other and 895 Hubs cannot communicate between each other. It is expected that the 896 management system that owns an any to any IPVPN service request 897 through this model, needs to assign and then configure the VRF and 898 route-targets on the appropriate PEs. In the Hub and Spoke case, two 899 route-targets are required (one route-target for Hub routes, one 900 route-target for Spoke routes). A Hub VRF, connecting Hub sites, 901 will export Hub routes with Hub route-target, and will import Spoke 902 routes through Spoke route-target. A Spoke VRF, connecting Spoke 903 sites, will export Spoke routes with Spoke route-target, and will 904 import Hub routes through Hub route-target. 906 The management system MUST take into account Hub and Spoke 907 connections constraints as in the previous case. 909 Hub and Spoke disjoint can also be seen as multiple Hub and Spoke 910 VPNs (one per Hub) sharing with a common set of Spoke sites. 912 6.2.2. Cloud access 914 The proposed model provides a cloud access configuration through the 915 cloud-access container. The usage of cloud-access is targeted for 916 public cloud. An Internet access can also be considered as a public 917 cloud access service. The cloud-access container provides parameters 918 for network address translations and authorization rules. 920 A private cloud access may be addressed through NNIs as described in 921 Section 6.15. 923 A cloud identifier is used to reference the target service. This 924 identifier is local to each administration. 926 The model allows for source address translation before accessing the 927 cloud. IPv4 to IPv4 address translation (nat44) is the only 928 supported option but other options can be added through augmentation. 929 If IP source address translation is required to access the cloud, the 930 enabled leaf MUST be set to true in the "nat44" container. An IP 931 address may be provided in the customer-address leaf, in case the 932 customer is providing the IP address to be used for the cloud access. 933 If the service provider is providing this address, the customer- 934 address is not necessary as it can be picked from a service provider 935 pool. 937 By default, all sites in the IPVPN MUST be authorized to access to 938 the cloud. In case restrictions are required, a user MAY configure 939 the permit-site or deny-site leaf-list. The "permit-site" defines 940 the list of sites authorized for cloud access. The "deny-site" 941 defines the list of sites denied for cloud access. The model 942 supports both "deny any except" and "permit any except" 943 authorization. 945 How the restrictions will be configured on network elements is out of 946 scope of this document. 948 IPVPN 949 ++++++++++++++++++++++++++++++++ +++++++++++ 950 + Site 3 + --- + Cloud1 + 951 + Site 1 + +++++++++++ 952 + + 953 + Site 2 + --- ++++++++++++ 954 + + + Internet + 955 + Site 4 + ++++++++++++ 956 ++++++++++++++++++++++++++++++++ 957 | 958 ++++++++++ 959 + Cloud2 + 960 ++++++++++ 962 In the example above, we may configure the global VPN to access 963 Internet by creating a cloud-access pointing to the cloud identifier 964 for the Internet service. No authorized-sites will be configured as 965 all sites are required to access the Internet. The "address- 966 translation/nat44/enabled" leaf will be set to true. 968 969 123456487 970 971 972 INTERNET 973 974 975 true 976 977 978 979 980 982 If Site1 and Site2 requires access to Cloud1, a new cloud-access will 983 be created pointing to the cloud identifier of Cloud1. The "permit- 984 site" leaf-list will be filled with a reference to Site1 and Site2. 986 987 123456487 988 989 990 Cloud1 991 site1 992 site2 993 994 995 997 If all sites except Site1 requires access to Cloud2, a new cloud- 998 access will be created pointing to the cloud identifier of Cloud2. 999 The "deny-site" leaf-list will be filled with a reference to Site1. 1001 1002 123456487 1003 1004 1005 Cloud2 1006 site1 1007 1008 1009 1011 6.2.3. Multicast service 1013 Multicast in IP VPN is described in [RFC6513]. 1015 If multicast support is required for an IPVPN, some global multicast 1016 parameters are required as input of the service request. 1018 The user of this model will need to fill the flavor of trees that 1019 will be used by customer within the IPVPN (Customer tree). The 1020 proposed model supports bidirectional, shared and source-based trees 1021 (and can be augmented). Multiple flavors of tree can be supported 1022 simultaneously. 1024 Operator network 1025 ______________ 1026 / \ 1027 | | 1028 (SSM tree) | 1029 Recv (IGMPv3) -- Site2 ------- PE2 | 1030 | PE1 --- Site1 --- Source1 1031 | | \ 1032 | | -- Source2 1033 | | 1034 (ASM tree) | 1035 Recv (IGMPv2) -- Site3 ------- PE3 | 1036 | | 1037 (SSM tree) | 1038 Recv (IGMPv3) -- Site4 ------- PE4 | 1039 | / | 1040 Recv (IGMPv2) -- Site5 -------- | 1041 (ASM tree) | 1042 | | 1043 \_______________/ 1045 In case of an ASM flavor requested, this model requires to fill the 1046 rp and rp-discovery parameters. Multiple RP to group mappings can be 1047 created using the rp-group-mappings container. For each mapping, the 1048 RP service can be managed by the service provider using the leaf 1049 "provider-managed/enabled" set to true. In case of provider managed 1050 RP, the user can request a rendez-vous point redundancy and/or an 1051 optimal traffic delivery. Those parameters will help the service 1052 provider to select the appropriate technology or architecture to 1053 fulfill the customer service requirement: for instance, in case of a 1054 request for an optimal traffic delivery, a service provider may use 1055 Anycast-RP or RP-tree to SPT switchover architectures. 1057 In case of a customer managed RP, the RP address must be filled in 1058 the RP to group mappings using the "rp-address" leaf. This leaf is 1059 not needed for a provider managed RP. 1061 User can define a specific rp-discovery mechanism like: auto-rp, 1062 static-rp, bsr-rp modes. By default, the model considers static-rp 1063 if ASM is requested. A single rp-discovery mechanism is allowed for 1064 the VPN. The "rp-discovery" container can be used for both provider 1065 and customer managed RPs. In case of a provider managed RP, if the 1066 user wants to use bsr-rp as a discovery protocol, a service provider 1067 should consider the provider managed rp-group-mappings for the bsr-rp 1068 configuration. The service provider will then configure its selected 1069 RPs to be bsr-rp-candidates. In case of a customer managed RP and a 1070 bsr-rp discovery mechanism, the rp-address provided will be 1071 considered as bsr-rp candidate. 1073 6.2.4. Extranet VPNs 1075 There are some cases where a particular VPN needs to access to 1076 resources (servers, hosts ...) that are external. These resources 1077 may be located in another VPN. 1079 +-----------+ +-----------+ 1080 / \ / \ 1081 SiteA -- | VPN A | --- | VPN B | --- SiteB 1082 \ / \ / (Shared 1083 +-----------+ +-----------+ resources) 1085 In the figure above, VPN B has some resources on Site B that need to 1086 be available to some customers/partners. VPN A must be able to 1087 access those VPN B resources. 1089 Such VPN connection scenario can be achieved by the VPN policy 1090 defined in Section 6.5.2.2. But there are some simple cases where a 1091 particular VPN (VPN A) needs to access to all resources in a VPN B. 1092 The model provides an easy way to setup this connection using the 1093 "extranet-vpns" container. 1095 The "extranet-vpns" container defines a list of VPNs a particular VPN 1096 wants to access. The "extranet-vpns" must be used on customer VPNs 1097 accessing extranet resources in another VPN. In the figure above, in 1098 order to give access for VPN A to VPN B, extranet-vpns container 1099 needs to be configured under VPN A with an entry corresponding to VPN 1100 B and there is no service configuration requirement on VPN B. 1102 Readers should note that even if there is no configuration 1103 requirement on VPN B, if VPN A lists VPN B as extranet, all sites in 1104 VPN B will gain access to all sites in VPN A. 1106 The "site-role" leaf defines the role of the local VPN sites in the 1107 target extranet VPN service topology. Site roles are defined in 1108 Section 6.4. Based on this, the requirements described in 1109 Section 6.4 regarding the site-role leaf are also applicable here. 1111 In the example below, VPN A accesses to VPN B resources through an 1112 extranet connection, a Spoke role is required for VPN A sites as 1113 sites from VPN A must not be able to communicate between each other 1114 through the extranet VPN connection. 1116 1117 VPNB 1118 hub-Spoke 1119 1120 1121 VPNA 1122 any-to-any 1123 1124 1125 VPNB 1126 spoke-role 1127 1128 1129 1131 This model does not define how the extranet configuration will be 1132 achieved. 1134 Any more complex VPN interconnection scenario (e.g. only part of 1135 sites of VPN A accessing only part of sites of VPN B) needs to be 1136 achieved using the vpn attachment defined in Section 6.5.2 and 1137 especially the VPN policy defined in Section 6.5.2.2. 1139 6.3. Site overview 1141 A site represents a connection of a customer office to one or more 1142 VPN services. 1144 +-------------+ 1145 / \ 1146 +------------------+ +-----| VPN1 | 1147 | | | \ / 1148 | New York Office | ----- (site) -----+ +-------------+ 1149 | | | +-------------+ 1150 +------------------+ | / \ 1151 +-----| VPN2 | 1152 \ / 1153 +-------------+ 1155 A site is composed of some characteristics : 1157 o Unique identifier (site-id): to uniquely identify the site within 1158 the overall network infrastructure. The identifier is a string 1159 allowing to any encoding for the local administration of the VPN 1160 service. 1162 o Locations (locations): site location information to allow easy 1163 retrieval on nearest available resources. A site may be composed 1164 of multiple locations. 1166 o Devices: the customer can request one or more customer premise 1167 equipments from the service provider for a particular site. 1169 o Management (management): defines the model of management of the 1170 site, for example : co-managed, customer managed or provider 1171 managed. 1173 o Site network accesses (site-network-accesses): defines the list of 1174 network accesses associated to the sites and their properties : 1175 especially bearer, connection and service parameters. 1177 A site-network-access represents an IP logical connection of a site. 1178 A site may have multiple site-network-accesses. 1180 +------------------+ Site 1181 | |----------------------------------- 1182 | |****** (site-network-access#1) ****** 1183 | New York Office | 1184 | |****** (site-network-access#2) ****** 1185 | |----------------------------------- 1186 +------------------+ 1188 Multiple site-network-accesses are used for instance in case of 1189 multihoming. Some other meshing cases may also involve multiple 1190 site-network-accesses. 1192 The site configuration is viewed as a global entity, we assume that 1193 it is mostly the role of the management to split the parameters 1194 between the different elements within the network. For example, in 1195 the case of the site-network-access configuration, the management 1196 system needs to split the overall parameters between the PE 1197 configuration and the CE configuration. 1199 6.3.1. Devices and locations 1201 A site may be composed of multiple locations. All the locations will 1202 need to be configured as part of the "locations" container and list. 1203 A typical example of multilocation site is an headquarter in a city 1204 composed of multiple buildings. Those buildings may be located in 1205 different parts of the city and may be linked by intra-city fibers 1206 (customer metropolitan area network). In such a case, when 1207 connecting to a VPN service, the customer may ask for multihoming 1208 based on its distributed locations. 1210 New York Site 1212 +------------------+ Site 1213 | +--------------+ |----------------------------------- 1214 | | Manhattan | |****** (site-network-access#1) ****** 1215 | +--------------+ | 1216 | +--------------+ | 1217 | | Brooklyn | |****** (site-network-access#2) ****** 1218 | +--------------+ | 1219 | |----------------------------------- 1220 +------------------+ 1222 A customer may also request some premise equipments (CEs) to the 1223 service provider through the "devices" container. Requesting a CE 1224 implies a provider-managed or co-managed model. A particular device 1225 must be ordered to a particular already configured location. This 1226 would help the service provider to send the device to the appropriate 1227 postal address. In a multilocation site, a customer may for example 1228 request a CE for each location on the site where multihoming must be 1229 implemented. In the figure above, one device may be requested for 1230 the Manhattan location and one other for the Brooklyn location. 1232 By using devices and locations, the user can influence the 1233 multihoming scenario he wants to implement: single CE, dual CE... 1235 6.3.2. Site network accesses 1237 As mentioned, a site may be multihomed. Each IP network access for a 1238 site is defined in the site-network-accesses list. The site-network- 1239 access defines how the site is connected on the network and is split 1240 into three main classes of parameters: 1242 o bearer: defines requirements of the attachment (below Layer 3). 1244 o connection: defines Layer 3 protocol parameters of the attachment. 1246 o availability: defines the site availability policy. The 1247 availability parameters are defined in Section 6.7 1249 The site-network-access has a specific type (site-network-access- 1250 type). This documents defines two types : 1252 o point-to-point: describes a point to point connection between the 1253 service provider and the customer. 1255 o multipoint: describes a multipoint connection between the service 1256 provider and the customer. 1258 The type of site-network-access may have an impact on the parameters 1259 offered to the customer, e.g., a service provider may not offer 1260 encryption for multipoint accesses. Deciding what parameter is 1261 supported for point-to-point and/or multipoint accesses is up to the 1262 provider and is out of scope of this document. Some containers 1263 proposed in the model may require extension in order to work properly 1264 for multipoint accesses. 1266 6.3.2.1. Bearer 1268 The "bearer" container defines the requirements for the site 1269 attachment to the provider network that are below Layer 3. 1271 The bearer parameters will help to determine the access media to be 1272 used. This is further described in Section 6.6.3. 1274 6.3.2.2. Connection 1276 The "ip-connection" container defines the protocol parameters of the 1277 attachment (IPv4 and IPv6). Depending on the management mode, it 1278 refers to the PE-CE addressing or CE to customer LAN addressing. In 1279 any case, it describes the provider to customer responsibility 1280 boundary. For a customer managed site, it refers to the PE-CE 1281 connection. For a provider managed site, it refers to the CE to LAN 1282 connection. 1284 6.3.2.2.1. IP addressing 1286 An IP subnet can be configured for either layer 3 protocols. For a 1287 dual stack connection, two subnets will be provided, one for each 1288 address family. 1290 The address-allocation-type determines how the address allocation 1291 needs to be done. The current model proposes five ways of IP address 1292 allocation: 1294 o provider-dhcp: the provider will provide DHCP service for customer 1295 equipments, this is can be applied to either IPv4 and IPv6 1296 containers. 1298 o provider-dhcp-relay: the provider will provide DHCP relay service 1299 for customer equipments, this is applicable to both IPv4 and IPv6 1300 addressing. The customer needs to fill DHCP server list to be 1301 used. 1303 o static-address: Addresses will be assigned manually, this is 1304 applicable to both IPv4 and IPv6 addressing. 1306 o slaac: enables stateless address autoconfiguration ([RFC4862]). 1307 This is applicable only for IPv6. 1309 o provider-dhcp-slaac: the provider will provide DHCP service for 1310 customer equipments as well as stateless address 1311 autoconfiguration. This is applicable only for IPv6. 1313 In the dynamic addressing mechanism, it is expected from the service 1314 provider to provide at least the IP address, mask and default gateway 1315 information. 1317 6.3.2.2.2. OAM 1319 A customer may require a specific IP connectivity fault detection 1320 mechanism on the IP connection. The model supports BFD as a fault 1321 detection mechanism. This can be extended with other mechanisms by 1322 augmentation. The provider can propose some profiles to the customer 1323 depending of the service level the customer wants to achieve. 1324 Profile names must be communicated to the customer. This 1325 communication is out of scope of this document. Some fixed values 1326 for the holdtime period may also be imposed by the customer if the 1327 provider enables it. 1329 The OAM container can easily be augmented by other mechanisms, 1330 especially work from LIME Working Group may be reused. 1332 6.3.2.3. Inheritance of parameters between site and site-network-access 1334 Some parameters can be configured both at the site level at the site- 1335 network-access level: e.g. routing, services, security... Inheritance 1336 applies when parameters are defined at site level. If a parameter is 1337 configured at both site and access level, the access level parameter 1338 MUST override the site level parameter. Those parameters will be 1339 described later in the document. 1341 In terms of provisionning impact, it will be up to the implementation 1342 to decide of the appropriate behavior when modifying existing 1343 configurations. But the service provider will need to communicate to 1344 the user about the impact of using inheritance. For example, if we 1345 consider that a site has already provisionned three site-network- 1346 accesses, what will happen if customer is changing a service 1347 parameter at site level ? An implementation of this model may update 1348 the service parameters of all already provisionned site-network- 1349 accesses (with potential impact on live traffic) or it may take into 1350 account this new parameter only for the new sites. 1352 6.4. Site role 1354 A VPN has a particular service topology as described in 1355 Section 6.2.1. As a consequence, each site belonging to a VPN is 1356 assigned with a particular role in this topology. The site-role 1357 defines the role of the site in a particular VPN topology. 1359 In the any-to-any VPN service topology, all sites MUST have the same 1360 role which is any-to-any-role. 1362 In the hub-spoke or hub-spoke-disjoint VPN service topology, sites 1363 MUST have a hub-role or a spoke-role. 1365 6.5. Site belonging to multiple VPNs 1367 6.5.1. Site vpn flavor 1369 A site may be part of one or multiple VPNs. The site flavor defines 1370 the way the VPN multiplexing is done. The current version of the 1371 model supports four flavors: 1373 o site-vpn-flavor-single: the site belongs to only one VPN. 1375 o site-vpn-flavor-multi: the site belongs to multiple VPNs and all 1376 the logical accesses of the sites belongs to the same set of VPNs. 1378 o site-vpn-flavor-sub: the site belongs to multiple VPNs with 1379 multiple logical accesses. Each logical access may map to 1380 different VPNs (one or many). 1382 o site-vpn-flavor-nni: the site represents an option A NNI. 1384 6.5.1.1. Single VPN attachment : site-vpn-flavor-single 1386 The figure below describes the single VPN attachment. The site 1387 connects to only one VPN. 1389 +--------+ 1390 +------------------+ Site / \ 1391 | |-----------------------------| | 1392 | |***(site-network-access#1)***| VPN1 | 1393 | New York Office | | | 1394 | |***(site-network-access#2)***| | 1395 | |-----------------------------| | 1396 +------------------+ \ / 1397 +--------+ 1399 6.5.1.2. Multi VPN attachment : site-vpn-flavor-multi 1401 The figure below describes a site connected to multiple VPNs. 1403 +---------+ 1404 +---/----+ \ 1405 +------------------+ Site / | \ | 1406 | |--------------------------------- | |VPN B| 1407 | |***(site-network-access#1)******* | | | 1408 | New York Office | | | | | 1409 | |***(site-network-access#2)******* \ | / 1410 | |-----------------------------| VPN A+-----|---+ 1411 +------------------+ \ / 1412 +--------+ 1414 In the example above, the New York office is multihomed, both logical 1415 accesses are using the same VPN attachment rules. Both logical 1416 accesses are connected to VPN A and VPN B. 1418 Reaching VPN A or VPN B from New York office will be based on 1419 destination based routing. Having the same destination reachable 1420 from the two VPNs may cause routing troubles. This would be the role 1421 of the customer administration to ensure the appropriate mapping of 1422 its prefixes in each VPN. 1424 6.5.1.3. Sub VPN attachment : site-vpn-flavor-sub 1426 The figure below describes a subVPN attachment. The site connects to 1427 multiple VPNs but each logical access is attached to a particular set 1428 of VPN. A typical use case of subVPN is a customer site used by 1429 multiple affiliates with private resources for each affiliates that 1430 cannot be shared (communication is prevented between the affiliates). 1431 It is similar than having separate sites instead that the customer 1432 wants to share some physical components while keeping a strong 1433 communication isolation between affiliates. In the example, the 1434 access#1 is attached to VPN B while the access#2 is attached to VPNA. 1436 +------------------+ Site +--------+ 1437 | |----------------------------------/ \ 1438 | |****(site-network-access#1)******| VPN B | 1439 | New York Office | \ / 1440 | | +--------+ 1441 | | +--------+ 1442 | | / \ 1443 | |****(site-network-access#2)******| VPN A | 1444 | | \ / 1445 | | +--------+ 1446 | |----------------------------------- 1447 +------------------+ 1449 MultiVPN can be implemented in addition to subVPN, as a consequence, 1450 each site-network-access can access to multiple VPNs. In the example 1451 below, access#1 is mapped to VPN B and VPN C, while access#2 is 1452 mapped to VPN A and VPN D. 1454 +------------------+ Site +-----+ 1455 | |----------------------------------/ +----+ 1456 | |****(site-network-access#1)******| VPN B/ \ 1457 | New York Office | \ | VPN C | 1458 | | +----\ / 1459 | | +-----+ 1460 | | 1461 | | +------+ 1462 | | / +-----+ 1463 | |****(site-network-access#2)******| VPN A/ \ 1464 | | \ | VPN D | 1465 | | +------\ / 1466 | |----------------------------------- +---+ 1467 +------------------+ 1469 Multihoming is also possible with subVPN, in this case, site-network- 1470 accesses are grouped, and a particular group will access to the same 1471 set of VPNs. In the example below, access#1 and #2 are part of the 1472 same group (multihomed together) and are mapped to VPN B and C, in 1473 addition access#3 and #4 are part of the same group (multihomed 1474 together) and are mapped to VPN A and D. 1476 +------------------+ Site +-----+ 1477 | |----------------------------------/ +----+ 1478 | |****(site-network-access#1)******| VPNB / \ 1479 | New York Office |****(site-network-access#2)******\ | VPN C | 1480 | | +----\ / 1481 | | +-----+ 1482 | | 1483 | | +------+ 1484 | | / +-----+ 1485 | |****(site-network-access#3)******| VPNA / \ 1486 | |****(site-network-access#4)****** \ | VPN D | 1487 | | +------\ / 1488 | |----------------------------------- +---+ 1489 +------------------+ 1491 In terms of service configuration, subVPN can be achieved by 1492 requesting the site-network-access to use the same bearer (see 1493 Section 6.6.4 and Section 6.6.6.4 for more details). 1495 6.5.1.4. NNI : site-vpn-flavor-nni 1497 Some Network to Network Interface (NNI) scenario may be modeled using 1498 the site container (see Section 6.15.1). Using the site container to 1499 model an NNI is only one possible option for NNI (see Section 6.15). 1500 This option is called option A by reference to the option A NNI 1501 defined in [RFC4364]. It is helpful for the service provider to 1502 identify that the requested VPN connection is not a regular site but 1503 a NNI as specific default device configuration parameters may be 1504 applied in case of NNI (e.g. ACLs, routing policies...). 1506 SP A SP B 1507 --------------------- -------------------- 1508 / \ / \ 1509 | | | | 1510 | ++++++++ InterAS link ++++++++ | 1511 | + +_____________ + + | 1512 | + (VRF1)--(VPN1)----(VRF1) + | 1513 | + ASBR + + ASBR + | 1514 | + (VRF2)--(VPN2)----(VRF2) + | 1515 | + +______________+ + | 1516 | ++++++++ ++++++++ | 1517 | | | | 1518 | | | | 1519 | | | | 1520 | ++++++++ InterAS link ++++++++ | 1521 | + +_____________ + + | 1522 | + (VRF1)--(VPN1)----(VRF1) + | 1523 | + ASBR + + ASBR + | 1524 | + (VRF2)--(VPN2)----(VRF2) + | 1525 | + +______________+ + | 1526 | ++++++++ ++++++++ | 1527 | | | | 1528 | | | | 1529 \ / \ / 1530 -------------------- ------------------- 1532 The figure above describes an option A NNI scenario that can be 1533 modeled using the site container. In order to connect its customer 1534 VPN (VPN1 and VPN2) on the SP B network, SP A may request the 1535 creation of some site-network-accesses to SP B. The site-vpn-flavor- 1536 nni will be used to inform SP B that this is an NNI and not a regular 1537 customer site. The site-vpn-flavor-nni may be multihomed and 1538 multiVPN as well. 1540 6.5.2. Attaching a site to a VPN 1542 Due to the multiple site-vpn flavors, the attachment of a site to an 1543 IPVPN is done at the site-network-access (logical access) level 1544 through the vpn-attachment container. The vpn-attachment container 1545 is mandatory. The model provides two ways of attachment: 1547 o By referencing directly the target VPN. 1549 o By referencing a VPN policy for more complex attachments. 1551 A choice is implemented to allow user to choose the best fitting 1552 flavor. 1554 6.5.2.1. Reference a VPN 1556 Referencing a vpn-id provides an easy way to attach a particular 1557 logical access to a VPN. This is the best way in case of single VPN 1558 attachment or subVPN with single VPN attachment per logical access. 1559 When referencing a vpn-id, the site-role must be added to express the 1560 role of the site in the target VPN service topology. 1562 1563 SITE1 1564 1565 1566 LA1 1567 1568 VPNA 1569 spoke-role 1570 1571 1572 LA2 1573 1574 VPNB 1575 spoke-role 1576 1577 1578 1579 1581 The example above describes a subVPN case where a site SITE1 has two 1582 logical accesses (LA1 and LA2) with LA1 attached to VPNA and LA2 1583 attached to VPNB. 1585 6.5.2.2. VPN policy 1587 The vpn-policy helps to express a multiVPN scenario where a logical 1588 access belongs to multiple VPNs. Multiple VPN policies can be 1589 created to handle the subVPN case where each logical access is part 1590 of a different set of VPNs. 1592 As a site can belong to multiple VPNs, the vpn-policy may be composed 1593 of multiple entries. A filter can be applied to specify that only 1594 some LANs of the site should be part of a particular VPN. Each time 1595 a site (or LAN) is attached to a VPN, the user must precisely 1596 describe its role (site-role) within the target VPN service topology. 1598 +--------------------------------------------------------------+ 1599 | Site1 ------ PE7 | 1600 +-------------------------+ [VPN2] | 1601 | | 1602 +-------------------------+ | 1603 | Site2 ------ PE3 PE4 ------ Site3 | 1604 +----------------------------------+ | 1605 | | 1606 +------------------------------------------------------------+ | 1607 | Site4 ------ PE5 | PE6 ------ Site5 | | 1608 | | | 1609 | [VPN3] | | 1610 +------------------------------------------------------------+ | 1611 | | 1612 +---------------------------+ 1614 In the example above, Site5 is part of two VPNs: VPN3 and VPN2. It 1615 will play a hub-role in VPN2 and an any-to-any role in VPN3. We can 1616 express such multiVPN scenario as follows: 1618 1619 Site5 1620 1621 1622 POLICY1 1623 1624 ENTRY1 1625 1626 VPN2 1627 hub-role 1628 1629 1630 1631 ENTRY2 1632 1633 VPN3 1634 any-to-any-role 1635 1636 1637 1638 1639 1640 1641 LA1 1642 1643 POLICY1 1644 1645 1646 1647 1649 Now, if a more granular VPN attachment is necessary, filtering can be 1650 used. For example, if LAN1 from Site5 must be attached to VPN2 as 1651 Hub and LAN2 must be attached to VPN3, the following configuration 1652 can be used: 1654 1655 Site5 1656 1657 1658 POLICY1 1659 1660 ENTRY1 1661 1662 LAN1 1663 1664 1665 VPN2 1666 hub-role 1667 1668 1669 1670 ENTRY2 1671 1672 LAN2 1673 1674 1675 VPN3 1676 any-to-any-role 1677 1678 1679 1680 1681 1682 1683 LA1 1684 1685 POLICY1 1686 1687 1688 1689 1691 6.6. Deciding where to connect the site 1693 The management system will have to determine where to connect each 1694 site-network-access of a particular site to the provider network (PE, 1695 aggregation switch ...). 1697 The current model proposes parameters and constraints that can 1698 influence the meshing of the site-network-access. 1700 The management system SHOULD honor the customer constraints, if the 1701 constraint is too strict and can not be filled, the management system 1702 MUST not provision the site and SHOULD provide an information to the 1703 user. How the information is provided is out of scope of the 1704 document. It would then be up to the user to relax the constraint or 1705 not. 1707 Parameters are just hints for the management system for service 1708 placement. 1710 In addition to parameters and constraints, the management system 1711 decision MAY be based on any other internal constraint that are up to 1712 the service provider: least load, distance ... 1714 6.6.1. Constraint: Device 1716 In case of provider-management or co-management, one or more devices 1717 have been ordered by the customer. The customer may force a 1718 particular site-network-access to be connected on a particular device 1719 he ordered. 1721 New York Site 1723 +------------------+ Site 1724 | +--------------+ |----------------------------------- 1725 | | Manhattan | | 1726 | | CE1********* (site-network-access#1) ****** 1727 | +--------------+ | 1728 | +--------------+ | 1729 | | Brooklyn CE2********* (site-network-access#2) ****** 1730 | +--------------+ | 1731 | |----------------------------------- 1732 +------------------+ 1734 In the figure above, the site-network-access#1 is associated to CE1 1735 in the service request. The service provider must ensure the 1736 provisionning of this connection. 1738 6.6.2. Constraint/parameter: Site location 1740 The location information provided in this model MAY be used by a 1741 management system to determine the target PE to mesh the site 1742 (service provider side). A particular location must be associated to 1743 each site network access when configuring it. The service provider 1744 MUST honor the termination of the access on the location associated 1745 with the site network access (customer side). The country-code in 1746 the site-location SHOULD be expressed as an ISO ALPHA-2 code. 1748 The site-network-access location is determined by the "location- 1749 flavor". In case of provider-managed or co-managed site, the user is 1750 expected to configure a "device-reference" (device case) that will 1751 bind the site-network-access to a particular device the customer 1752 ordered. As each device is already associated to a particular 1753 location, in such case the location information is retrieved from the 1754 device location. In case of customer-managed site, the user is 1755 expected to configure a "location-reference" (location case), this 1756 provides a reference to an existing configured location and will help 1757 the placement. 1759 PoP#1 (New York) 1760 +---------+ 1761 | PE1 | 1762 Site #1 ---... | PE2 | 1763 (Atlantic City) | PE3 | 1764 +---------+ 1766 PoP#2 (Washington) 1767 +---------+ 1768 | PE4 | 1769 | PE5 | 1770 | PE6 | 1771 +---------+ 1773 PoP#3 (Philadelphia) 1774 +---------+ 1775 | PE7 | 1776 Site #2 CE#1---... | PE2 | 1777 (Reston) | PE9 | 1778 +---------+ 1780 In the example above, Site#1 is a customer managed site with a 1781 location L1, while Site#2 is a provider-managed site for which a CE#1 1782 was ordered, Site#2 is configured with L2 as location. When 1783 configuring a site-network-access for Site#1, the user will need to 1784 reference the location L1, so the management system will know that 1785 the access will need to terminate on this location. Then this 1786 management system may mesh Site#1 on a PE in the Philadelphia PoP for 1787 distance reason. It may also take into account resources available 1788 on PEs to determine the exact target PE (e.g. least loaded). 1789 Regarding Site#2, the user is expected to configure the site-network- 1790 access with a device-reference to CE#1, so the management system will 1791 know that the access must terminate on the location of CE#1 and must 1792 be connected to CE#1. For placing the service provider side of the 1793 access connection, in case of shortest distance PE used, it may mesh 1794 Site #2 on the Washington PoP. 1796 6.6.3. Constraint/parameter: access type 1798 The management system needs to elect the access media to connect the 1799 site to the customer (for example : xDSL, leased line, Ethernet 1800 backhaul ...). The customer may provide some parameters/constraints 1801 that will provide hints to the management system. 1803 The bearer container information SHOULD be used as first input : 1805 o The "requested-type" provides an information about the media type 1806 the customer would like. If the "strict" leaf is equal to "true", 1807 this MUST be considered as a strict constraint, so the management 1808 system cannot connect the site with another media type. If the 1809 "strict" leaf is equal to "false" (default), if the requested-type 1810 cannot be fulfilled, the management system can select another 1811 type. The supported media types SHOULD be communicated by the 1812 service provider to the customer by a mechanism that is out of 1813 scope of the document. 1815 o The "always-on" leaf defines a strict constraint: if set to 1816 "true", the management system MUST elect a media type which is 1817 always-on (this means no dial access type). 1819 o The "bearer-reference" is used in case the customer has already 1820 ordered a network connection to the service provider apart of the 1821 IPVPN site and wants to reuse this connection. The string used in 1822 an internal reference from the service provider describing the 1823 already available connection. This is also a strict requirement 1824 that cannot be relaxed. How the reference is given to the 1825 customer is out of scope of the document but as a pure example, 1826 when the customer ordered the bearer (through a process out of 1827 this model), the service provider may had provided the bearer 1828 reference that can be used for provisionning services on top. 1830 Any other internal parameters from the service provider can be used 1831 in addition. The management system MAY use other parameters such as 1832 the requested svc-input-bandwidth and svc-output-bandwidth to help to 1833 decide the access type to be used. 1835 6.6.4. Constraint: access diversity 1837 Each site-network-access may have one or more constraints that would 1838 drive the placement of the access. By default, the model assumes no 1839 constraint but is expected allocation of a unique bearer per site- 1840 network-access. 1842 In order to help the different placement scenarios, a site-network- 1843 access may be tagged using one or multiple group identifiers. The 1844 group identifier is a string so it can accommodate both explicit 1845 naming of a group of sites (e.g. "multihomed-set1" or "subVPN") or a 1846 numbered identifier (e.g. 12345678). The meaning of each group-id is 1847 local to each customer administrator. And the management system MUST 1848 ensure that different customers can use the same group-ids. One or 1849 more group-ids can also be defined at the site-level, as a 1850 consequence, all site-network-accesses under the site MUST inherit 1851 the group-ids of the site they are belonging to. When, in addition 1852 to the site group-ids, some group-ids are defined at the site- 1853 network-access level, the management system MUST consider the union 1854 of all groups (site level and site network access level) for this 1855 particular site-network-access. 1857 For an already configured site-network-access, each constraint MUST 1858 be expressed against a targeted set of site-network-accesses, this 1859 site-network-access MUST never be taken into account in the targeted 1860 set: e.g. "My site-network-access S must not be connected on the 1861 same PoP as the site-network-accesses that are part of group 10". 1862 The set of site-network-accesses against which the constraint is 1863 evaluated can be expressed as a list of groups or "all-other- 1864 accesses" or "all-other-groups". The "all-other-accesses" option 1865 means that the current site-network-access constraint MUST be 1866 evaluated against all the other site-network-accesses belonging to 1867 the current site. The "all-other-groups" option means that the 1868 constraint MUST be evaluated against all groups the current site- 1869 network-access is not belonging to. 1871 The current model proposes multiple constraint-types: 1873 pe-diverse: the current site-network-access MUST not be connected 1874 to the same PE as the targeted site-network-accesses. 1876 pop-diverse: the current site-network-access MUST not be connected 1877 to the same PoP as the targeted site-network-accesses. 1879 linecard-diverse: the current site-network-access MUST not be 1880 connected to the same linecard as the targeted site-network- 1881 accesses. 1883 bearer-diverse: the current site-network-access MUST NOT use 1884 common bearer components compared to bearers used by the targeted 1885 site-network-accesses. "bearer-diverse" provides some level of 1886 diversity at the access level. As an example, two "bearer- 1887 diverse" site-network-accesses must not use the same DSLAM or BAS 1888 or layer 2 switch... 1890 same-pe: the current site-network-access MUST be connected to the 1891 same PE as the targeted site-network-accesses. 1893 same-bearer: the current site-network-access MUST be connected 1894 using the same bearer as the targeted site-network-accesses. 1896 These constraint-types can be extended through augmentation. 1898 Each constraint is expressed as "The site-network-access S must be 1899 (e.g. pe-diverse, pop-diverse) from these 1900 site-network-accesses". 1902 The group-id used to target some site-network-accesses may be the 1903 same as the one used by the current site-network-access. This eases 1904 configuration of scenarios where a group of site-network-access has a 1905 constraint between each other. As an example if we want a set of 1906 sites (site#1 up to #5) to be connected on different PEs, we can tag 1907 them with the same group-id and express a pe-diverse constraint for 1908 this group-id. 1910 1911 SITE1 1912 1913 1914 1 1915 1916 1917 1918 10 1919 1920 1921 1922 1923 pe-diverse 1924 1925 1926 10 1927 1928 1929 1930 1931 1932 1933 VPNA 1934 spoke-role 1935 1936 1937 1938 1939 1940 SITE2 1941 1942 1943 1 1944 1945 1946 1947 10 1948 1949 1950 1951 1952 pe-diverse 1953 1954 1955 10 1956 1957 1958 1959 1960 1961 1962 VPNA 1963 spoke-role 1964 1965 1966 1967 1968 ... 1969 1970 SITE5 1971 1972 1973 1 1974 1975 1976 1977 10 1978 1979 1980 1981 1982 pe-diverse 1983 1984 1985 10 1986 1987 1988 1990 1991 1992 1993 VPNA 1994 spoke-role 1995 1996 1997 1998 2000 The group-id used to target some site-network-accesses may be also 2001 different than the one used by the current site-network-access. This 2002 can be used to express that a group of site has some constraints 2003 against another group of sites, but there is no constraint within the 2004 group. As an example, if we consider a set of 6 sites with two sets 2005 and we want to ensure that a site in the first set must be pop- 2006 diverse from a site in the second set. 2008 2009 SITE1 2010 2011 2012 1 2013 2014 2015 2016 10 2017 2018 2019 2020 2021 pop-diverse 2022 2023 2024 20 2025 2026 2027 2028 2029 2030 2031 VPNA 2032 spoke-role 2033 2034 2035 2036 2037 2038 SITE2 2039 2040 2041 1 2042 2043 2044 2045 10 2046 2047 2048 2049 2050 pop-diverse 2051 2052 2053 20 2054 2055 2056 2057 2058 2059 2060 VPNA 2061 spoke-role 2062 2063 2064 2065 2066 ... 2067 2068 SITE5 2069 2070 2071 1 2072 2073 2074 2075 20 2076 2077 2078 2079 2080 pop-diverse 2081 2082 2083 10 2084 2085 2087 2088 2089 2090 2091 VPNA 2092 spoke-role 2093 2094 2095 2096 2097 2098 SITE6 2099 2100 2101 1 2102 2103 2104 2105 20 2106 2107 2108 2109 2110 pop-diverse 2111 2112 2113 10 2114 2115 2116 2117 2118 2119 2120 VPNA 2121 spoke-role 2122 2123 2124 2125 2127 6.6.5. Impossible access placement 2129 Some impossible placement scenarios may be created through the 2130 proposed configuration framework. Impossible scenarios could come 2131 from too restrictive constraints leading to impossible placement in 2132 the network or conflicting constraints that would also lead to 2133 impossible placement. An example of conflicting rules would be to 2134 request a site-network-access#1 to be pe-diverse from a site-network- 2135 access#2 and to request at the same time that site-network-access#2 2136 to be on the same PE as site-network-access#1. When the management 2137 system cannot determine the placement of a site-network-access, it 2138 SHOULD return an error message indicating that placement was not 2139 possible. 2141 6.6.6. Examples of access placement 2143 6.6.6.1. Multihoming 2145 The customer wants to create a multihomed site. The site will be 2146 composed of two site-network-accesses and the customer wants the two 2147 site-network-accesses to be meshed on different PoPs for resiliency 2148 purpose. 2150 PoP#1 2151 +-------+ +---------+ 2152 | | | PE1 | 2153 | |---site_network_access#1 ---- | PE2 | 2154 | | | PE3 | 2155 | | +---------+ 2156 | Site#1| 2157 | | PoP#2 2158 | | +---------+ 2159 | | | PE4 | 2160 | |---site_network_access#2 ---- | PE5 | 2161 | | | PE6 | 2162 | | +---------+ 2163 +-------+ 2165 This scenario can be expressed in the following way: 2167 2168 SITE1 2169 2170 2171 1 2172 2173 2174 2175 10 2176 2177 2178 2179 2180 pop-diverse 2181 2182 2183 20 2184 2185 2186 2187 2188 2189 2190 VPNA 2191 spoke-role 2192 2193 2194 2195 2 2196 2197 2198 2199 20 2200 2201 2202 2203 2204 pop-diverse 2205 2206 2207 10 2208 2209 2210 2211 2212 2213 2214 VPNA 2215 spoke-role 2216 2217 2218 2219 2221 But it can also be expressed as: 2223 2224 SITE1 2225 2226 2227 1 2228 2229 2230 2231 pop-diverse 2232 2233 2234 2235 2236 2237 2238 2239 VPNA 2240 spoke-role 2241 2242 2243 2244 2 2245 2246 2247 2248 pop-diverse 2249 2250 2251 2252 2253 2254 2255 2256 VPNA 2257 spoke-role 2258 2259 2260 2261 2263 6.6.6.2. Site offload 2265 The customer has six branch offices in a particular region and he 2266 wants to prevent to have all branch offices to be connected on the 2267 same PE. 2269 He wants to express that three branch offices cannot be connected on 2270 the same linecard. And the other branch offices must be connected on 2271 a different PoP. Those other branch offices cannot also be connected 2272 on the same linecard. 2274 PoP#1 2275 +---------+ 2276 | PE1 | 2277 Office#1 ---... | PE2 | 2278 Office#2 ---... | PE3 | 2279 Office#3 ---... | PE4 | 2280 +---------+ 2282 PoP#2 2283 +---------+ 2284 Office#4 ---... | PE4 | 2285 Office#5 ---... | PE5 | 2286 Office#6 ---... | PE6 | 2287 +---------+ 2289 This scenario can be expressed in the following way: 2291 o We need to create two sets of sites: set#1 composed of Office#1 up 2292 to 3, set#2 composed of Office#4 up to 6. 2294 o Sites within set#1 must be pop-diverse from sites within set#2 and 2295 vice versa. 2297 o Sites within set#1 must be linecard-diverse from other sites in 2298 set#1 (same for set#2). 2300 2301 SITE1 2302 2303 2304 1 2305 2306 2307 2308 10 2309 2310 2311 2312 2313 pop-diverse 2314 2315 2316 20 2317 2318 2319 2320 2321 linecard-diverse 2322 2323 2324 10 2325 2326 2327 2328 2329 2330 2331 VPNA 2332 spoke-role 2333 2334 2335 2336 2337 SITE2 2338 2339 2340 1 2341 2342 2343 2344 10 2345 2346 2347 2348 2349 pop-diverse 2350 2351 2352 20 2353 2354 2355 2356 2357 linecard-diverse 2358 2359 2360 10 2361 2362 2363 2365 2366 2367 2368 VPNA 2369 spoke-role 2370 2371 2372 2373 2374 SITE3 2375 2376 2377 1 2378 2379 2380 2381 10 2382 2383 2384 2385 2386 pop-diverse 2387 2388 2389 20 2390 2391 2392 2393 2394 linecard-diverse 2395 2396 2397 10 2398 2399 2400 2401 2402 2403 2404 VPNA 2405 spoke-role 2406 2407 2408 2409 2411 2412 SITE4 2413 2414 2415 1 2416 2417 2418 2419 20 2420 2421 2422 2423 2424 pop-diverse 2425 2426 2427 10 2428 2429 2430 2431 2432 linecard-diverse 2433 2434 2435 20 2436 2437 2438 2439 2440 2441 2442 VPNA 2443 spoke-role 2444 2445 2446 2447 2448 SITE5 2449 2450 2451 1 2452 2453 2454 2455 20 2456 2457 2458 2459 2460 pop-diverse 2461 2462 2463 10 2464 2465 2466 2467 2468 linecard-diverse 2469 2470 2471 20 2472 2473 2474 2475 2476 2477 2478 VPNA 2479 spoke-role 2480 2481 2482 2483 2484 SITE6 2485 2486 2487 1 2488 2489 2490 2491 20 2492 2493 2494 2495 2496 pop-diverse 2497 2498 2499 10 2500 2501 2502 2503 2504 linecard-diverse 2505 2506 2507 20 2508 2510 2511 2512 2513 2514 2515 VPNA 2516 spoke-role 2517 2518 2519 2520 2522 6.6.6.3. Parallel links 2524 To increase its site bandwidth at a cheaper cost, a customer wants to 2525 order two parallel site-network-accesses that will be connected to 2526 the same PE. 2528 *******SNA1********** 2529 Site 1 *******SNA2********** PE1 2531 This scenario can be expressed in the following way: 2533 2534 SITE1 2535 2536 2537 1 2538 2539 2540 2541 PE-linkgrp-1 2542 2543 2544 2545 2546 same-pe 2547 2548 2549 PE-linkgrp-1 2550 2551 2552 2553 2554 2555 2556 VPNB 2557 spoke-role 2558 2559 2560 2561 2 2562 2563 2564 2565 PE-linkgrp-1 2566 2567 2568 2569 2570 same-pe 2571 2572 2573 PE-linkgrp-1 2574 2575 2576 2577 2578 2579 2580 VPNB 2581 spoke-role 2582 2583 2584 2585 2587 6.6.6.4. SubVPN with multihoming 2589 A customer has site which is dualhomed. The dualhoming must be done 2590 on two different PEs. The customer wants also to implement two 2591 subVPNs on those multihomed accesses. 2593 +------------------+ Site +-----+ 2594 | |----------------------------------/ +----+ 2595 | |****(site-network-access#1)******| VPNB / \ 2596 | New York Office |****(site-network-access#2)*************| VPN C | 2597 | | +----\ / 2598 | | +-----+ 2599 | | 2600 | | +------+ 2601 | | / +-----+ 2602 | |****(site-network-access#3)******| VPNB / \ 2603 | |****(site-network-access#4)**************| VPN C | 2604 | | +------\ / 2605 | |----------------------------------- +---+ 2606 +------------------+ 2608 This scenario can be expressed in the following way: 2610 o The site will have 4 site network accesses (2 subVPN coupled with 2611 dual homing). 2613 o Site-network-access#1 and #3 will correspond to the multihoming of 2614 the subVPN B. A PE-diverse constraint is required between them. 2616 o Site-network-access#2 and #4 will correspond to the multihoming of 2617 the subVPN C. A PE-diverse constraint is required between them. 2619 o To ensure proper usage of the same bearer for the subVPN, site- 2620 network-access #1 and #2 must share the same bearer as site- 2621 network-access #3 and #4. 2623 2624 SITE1 2625 2626 2627 1 2628 2629 2630 2631 dualhomed-1 2632 2633 2634 2635 2636 pe-diverse 2637 2638 2639 dualhomed-2 2640 2642 2643 2644 2645 same-bearer 2646 2647 2648 dualhomed-1 2649 2650 2651 2652 2653 2654 2655 VPNB 2656 spoke-role 2657 2658 2659 2660 2 2661 2662 2663 2664 dualhomed-1 2665 2666 2667 2668 2669 pe-diverse 2670 2671 2672 dualhomed-2 2673 2674 2675 2676 2677 same-bearer 2678 2679 2680 dualhomed-1 2681 2682 2683 2684 2685 2686 2687 VPNC 2688 spoke-role 2689 2691 2692 3 2693 2694 2695 2696 dualhomed-2 2697 2698 2699 2700 2701 pe-diverse 2702 2703 2704 dualhomed-1 2705 2706 2707 2708 2709 same-bearer 2710 2711 2712 dualhomed-2 2713 2714 2715 2716 2717 2718 2719 VPNB 2720 spoke-role 2721 2722 2723 2724 4 2725 2726 2727 2728 dualhomed-2 2729 2730 2731 2732 2733 pe-diverse 2734 2735 2736 dualhomed-1 2737 2738 2740 2741 2742 same-bearer 2743 2744 2745 dualhomed-2 2746 2747 2748 2749 2750 2751 2752 VPNC 2753 spoke-role 2754 2755 2756 2757 2759 6.6.7. Route Distinguisher and VRF allocation 2761 The route-distinguisher is a critical parameter of PE-based L3VPNs as 2762 described in [RFC4364] that allows to distinguish common addressing 2763 plans in different VPNs. As for route-targets, it is expected that a 2764 management system will allocate a VRF on the target PE and a route- 2765 distinguisher for this VRF. 2767 If a VRF already exists on the target PE, and the VRF fulfils the 2768 connectivity constraints for the site, there is no need to recreate 2769 another VRF and the site MAY be meshed within this existing VRF. How 2770 the management system checks that an existing VRF fulfils the 2771 connectivity constraints for a site is out of scope of this document. 2773 If no such a VRF exists on the target PE, the management system has 2774 to initiate a new VRF creation on the target PE and has to allocate a 2775 new route-distinguisher for this new VRF. 2777 The management system MAY apply a per-VPN or per-VRF allocation 2778 policy for the route-distinguisher depending on the service provider 2779 policy. In a per-VPN allocation policy, all VRFs (dispatched on 2780 multiple PEs) within a VPN will share the same route distinguisher 2781 value. In a per-VRF model, all VRFs should always have a unique 2782 route-distinguisher value. Some other allocation policies are also 2783 possible, and this document does not restrict the allocation policies 2784 to be used. 2786 The allocation of route-distinguishers MAY be done in the same way as 2787 route-targets. The example provided in Section 6.2.1.1 could be 2788 reused. 2790 Note that a service provider MAY configure a target PE for an 2791 automated allocation of route-distinguishers. In this case, there 2792 will be no need for any backend system to allocate a route- 2793 distinguisher value. 2795 6.7. Site network access availability 2797 A site may be multihomed, meaning it has multiple site-network-access 2798 points. Placement constraints defined in previous sections will help 2799 to ensure physical diversity. 2801 When the site-network-accesses are placed on the network, a customer 2802 may want to use a particular routing policy on those accesses. 2804 The "site-network-access/availability" container defines parameters 2805 for the site redundancy. The "access-priority" leaf defines a 2806 preference for a particular access. This preference is used to model 2807 loadbalancing or primary/backup scenarios. The higher the access- 2808 priority the higher the preference will be. 2810 The figure below describes how the access-priority attribute can be 2811 used. 2813 Hub#1 LAN (Primary/backup) Hub#2 LAN (Loadsharing) 2814 | | 2815 | access-priority 1 access-priority 1 | 2816 |--- CE1 ------- PE1 PE3 --------- CE3 --- | 2817 | | 2818 | | 2819 |--- CE2 ------- PE2 PE4 --------- CE4 --- | 2820 | access-priority 2 access-priority 1 | 2822 PE5 2823 | 2824 | 2825 | 2826 CE5 2827 | 2828 Spoke#1 site (Single-homed) 2830 In the figure above, Hub#2 requires loadsharing so all the site- 2831 network-accesses must use the same access-priority value. On the 2832 contrary, as Hub#1 requires primary/backup, an higher access-priority 2833 will be configured on the primary access. 2835 More complex scenarios can be modeled. Let's consider a Hub site 2836 with five accesses to the network (A1,A2,A3,A4,A5). The customer 2837 wants to loadshare its traffic on A1,A2 in the nominal situation. If 2838 A1 and A2 fails, he wants to loadshare its traffic on A3 and A4, and 2839 finally if A1 to A4 are down, he wants to use A5. We can model it 2840 easily by configuring the following access-priorities: A1=100, 2841 A2=100, A3=50, A4=50, A5=10. 2843 The access-priority has some limitation. A scenario like the 2844 previous one with five accesses but with the constraint of having 2845 traffic loadshared between A3 and A4 in case of A1 OR A2 being down 2846 is not achievable. But the authors consider that the access-priority 2847 covers most of the deployment use cases and the model can still be 2848 extended by augmentation to support additional use cases. 2850 6.8. Traffic protection 2852 The service model supports the ability to protect the traffic for a 2853 site. A protection provides a better availability to multihoming by, 2854 for example, using local-repair techniques in case of failures. The 2855 associated level of service guarantee would be based on an agreement 2856 between customer and service provider and is out of scope of this 2857 document. 2859 Site#1 Site#2 2860 CE1 ----- PE1 -- P1 P3 -- PE3 ---- CE3 2861 | | | 2862 | | | 2863 CE2 ----- PE2 -- P2 P4 -- PE4 ---- CE4 2864 / 2865 / 2866 CE5 ----+ 2867 Site#3 2869 In the figure above, we consider an IPVPN service with three sites 2870 including two dual homed sites (site#1 and #2). For dual homed 2871 sites, we consider PE1-CE1 and PE3-CE3 as primary, and 2872 PE2-CE2,PE4-CE4 as backup for the example (even if protection also 2873 applies to loadsharing scenarios). 2875 In order to protect Site#2 against a failure, user may set the 2876 "traffic-protection/enabled" leaf to true for site#2. How the 2877 traffic protection will be implemented is out of scope of the 2878 document. But as an example, in such a case, if we consider traffic 2879 coming from a remote site (site#1 or site#3), where the primary path 2880 is to use PE3 as egress PE. PE3 may have preprogrammed a backup 2881 forwarding entry pointing to backup path (through PE4-CE4) for all 2882 prefixes going through PE3-CE3 link. How the backup path is computed 2883 is out of scope of the document. When PE3-CE3 link fails, traffic is 2884 still received by PE3 but PE3 switch automatically traffic to the 2885 backup entry, path will so be PE1-P1-(...)-P3-PE3-PE4-CE4 until 2886 remote PEs reconverge and use PE4 as the egress PE. 2888 6.9. Security 2890 The "security" container defines customer specific security 2891 parameters for the site. The security options supported in the model 2892 are limited but may be extended by augmentation. 2894 6.9.1. Authentication 2896 The current model does not support any authentication parameters for 2897 the site connection, but such parameters may be added in the 2898 "authentication" container through augmentation. 2900 6.9.2. Encryption 2902 A traffic encryption can be requested on the connection. It may be 2903 performed at layer 2 or layer 3 by selecting the appropriate 2904 enumeration in "layer" leaf. For example, a service provider may use 2905 IPSec when a customer is requesting layer 3 encryption. The 2906 encryption profile can be a service provider defined profile or a 2907 customer specific. 2909 When a service provider profile is used and a key (e.g. a preshared 2910 key) is allocated by the provider to be used by a customer, the 2911 service provider should provide a way to communicate the key in a 2912 secured way to the customer. 2914 When a customer profile is used, the model supports only preshared 2915 key for authentication with the preshared key provided through the 2916 NETCONF or RESTCONF request. A secure channel must be used to ensure 2917 that the preshared key cannot be intercepted. 2919 It may be necessary for the customer to change the preshared key on a 2920 regular basis for security reasons. To perform a key change, the 2921 user can request to the service provider by submitting a new 2922 preshared key for the site configuration (as displayed below). This 2923 mechanism may not to be hitless. 2925 2926 SITE1 2927 2928 2929 1 2930 2931 2932 MY_NEW_KEY 2933 2934 2935 2936 2937 2939 An hitless key change mechanism may be added through augmentation. 2941 Other key management methodology may be added through augmentation. 2942 A "pki" empty container has been created to help support of PKI 2943 through augmentation. 2945 6.10. Management 2947 The model proposes three types of common management options: 2949 o provider-managed: the CE router is managed only by the provider. 2950 In this model, the responsibility boundary between SP and customer 2951 is between CE and customer network. 2953 o customer-managed: the CE router is managed only by the customer. 2954 In this model, the responsibility boundary between SP and customer 2955 is between PE and CE. 2957 o co-managed: the CE router is primarly managed by the provider and 2958 in addition SP lets customer accessing the CE for some 2959 configuration/monitoring purpose. In the co-managed mode the 2960 responsibility boundary is the same as the provider-managed model. 2962 Based on the management model, different security options MAY be 2963 derived. 2965 In case of "co-managed", the model proposes some options to define 2966 the management address family (IPv4 or IPv6) and the associated 2967 management address. 2969 6.11. Routing protocols 2971 Routing-protocol defines which routing protocol must be activated 2972 between the provider and the customer router. The current model 2973 supports: bgp, rip, ospf, static, direct, vrrp. 2975 The routing protocol defined applies at the provider to customer 2976 boundary. Depending on the management of the management model, it 2977 may apply to the PE-CE boundary or CE to customer boundary. In case 2978 of a customer managed site, the routing-protocol defined will be 2979 activated between the PE and the CE router managed by the customer. 2980 In case of a provider managed site, the routing-protocol defined will 2981 be activated between the CE managed by the SP and the router or LAN 2982 belonging to the customer. In this case, it is expected that the PE- 2983 CE routing will be configured based on the service provider rules as 2984 both are managed by the same entity. 2986 Rtg protocol 2987 192.0.2.0/24 ----- CE ----------------- PE1 2989 Customer managed site 2991 Rtg protocol 2992 Customer router ----- CE ----------------- PE1 2994 Provider managed site 2996 All the examples below will refer to a customer managed site case. 2998 6.11.1. Dual stack handling 3000 All routing protocol types support dual stack by using address-family 3001 leaf-list. 3003 Example of Dual stack using the same routing protocol: 3005 3006 3007 static 3008 3009 ipv4 3010 ipv6 3011 3012 3013 3014 Example of Dual stack using two different routing protocols: 3016 3017 3018 rip 3019 3020 ipv4 3021 3022 3023 3024 ospf 3025 3026 ipv6 3027 3028 3029 3031 6.11.2. Direct LAN connection onto SP network 3033 Routing-protocol "direct" SHOULD be used when a customer LAN is 3034 directly connected to the provider network and must be advertised in 3035 the IPVPN. 3037 LAN attached directly to provider network: 3039 192.0.2.0/24 ----- PE1 3041 In this case, the customer has a default route to the PE address. 3043 6.11.3. Direct LAN connection onto SP network with redundancy 3045 Routing-protocol "vrrp" SHOULD be used when a customer LAN is 3046 directly connected to the provider network and must be advertised in 3047 the IPVPN and LAN redundancy is expected. 3049 LAN attached directly to provider network with LAN redundancy: 3051 192.0.2.0/24 ------ PE1 3052 | 3053 +--- PE2 3055 In this case, the customer has a default route to the service 3056 provider network. 3058 6.11.4. Static routing 3060 Routing-protocol "static" MAY be used when a customer LAN is 3061 connected to the provider network through a CE router and must be 3062 advertised in the IPVPN. 3064 Static rtg 3065 192.0.2.0/24 ------ CE -------------- PE 3066 | | 3067 | Static route 192.0.2.0/24 nh CE 3068 Static route 0.0.0.0/0 nh PE 3070 In this case, the customer has a default route to the service 3071 provider network. 3073 6.11.5. RIP routing 3075 Routing-protocol "rip" MAY be used when a customer LAN is connected 3076 to the provider network through a CE router and must be advertised in 3077 the IPVPN. For IPv4, the model assumes usage of RIP version 2. 3079 In case of dual stack routing requested through this model, the 3080 management system will be responsible to configure rip (including 3081 right version number) and associated address-families on network 3082 elements. 3084 RIP rtg 3085 192.0.2.0/24 ------ CE -------------- PE 3087 6.11.6. OSPF routing 3089 Routing-protocol "ospf" MAY be used when a customer LAN is connected 3090 to the provider network through a CE router and must be advertised in 3091 the IPVPN. 3093 It can be used to extend an existing OSPF network and interconnect 3094 different areas. See [RFC4577] for more details. 3096 +---------------------+ 3097 | | 3098 OSPF | | OSPF 3099 area 1 | | area 2 3100 (OSPF | | (OSPF 3101 area 1) --- CE ---------- PE PE ----- CE --- area 2) 3102 | | 3103 +---------------------+ 3105 The model also proposes an option to create an OSPF sham-link between 3106 two sites sharing the same area and having a backdoor link. The 3107 sham-link is created by referencing the target site sharing the same 3108 OSPF area. The management system will be responsible to check if 3109 there is already a shamlink configured for this VPN and area between 3110 the same pair of PEs. If there is no existing shamlink, the 3111 management system will provision it. This shamlink MAY be reused by 3112 other sites. 3114 +------------------------+ 3115 | | 3116 | | 3117 | PE (--shamlink--)PE | 3118 | | | | 3119 +----|----------------|--+ 3120 | OSPF area1 | OSPF area 1 3121 | | 3122 CE1 CE2 3123 | | 3124 (OSPF area1) (OSPF area1) 3125 | | 3126 +----------------+ 3128 Regarding Dual stack support, user MAY specify both IPv4 and IPv6 3129 address families, if both protocols should be routed through OSPF. 3130 As OSPF uses separate protocol instances for IPv4 and IPv6, the 3131 management system will need to configure both ospf version 2 and 3132 version 3 on the PE-CE link. 3134 Example of OSPF routing parameters in service model. 3136 3137 3138 ospf 3139 3140 0.0.0.1 3141 ipv4 3142 ipv6 3143 3144 3145 3146 Example of PE configuration done by management system: 3148 router ospf 10 3149 area 0.0.0.1 3150 interface Ethernet0/0 3151 ! 3152 router ospfv3 10 3153 area 0.0.0.1 3154 interface Ethernet0/0 3155 ! 3157 6.11.7. BGP routing 3159 Routing-protocol "bgp" MAY be used when a customer LAN is connected 3160 to the provider network through a CE router and must be advertised in 3161 the IPVPN. 3163 BGP rtg 3164 192.0.2.0/24 ------ CE -------------- PE 3166 The session addressing will be derived from connection parameters as 3167 well as internal knowledge of SP. 3169 In case of dual stack access, user MAY request BGP routing for both 3170 IPv4 and IPv6 by specifying both address-families. It will be up to 3171 SP and management system to determine how to decline the 3172 configuration (two BGP sessions, single, multisession ...). 3174 The service configuration below activates BGP on PE-CE link for both 3175 IPv4 and IPv6. 3177 BGP activation requires SP to know the address of the customer peer. 3178 "static-address" allocation type for the IP connection MUST be used. 3180 3181 3182 bgp 3183 3184 65000 3185 ipv4 3186 ipv6 3187 3188 3189 3191 This service configuration can be derived by management system into 3192 multiple flavors depending on SP flavor. 3194 Example #1 of PE configuration done by management system 3195 (single session IPv4 transport session): 3197 router bgp 100 3198 neighbor 203.0.113.2 remote-as 65000 3199 address-family ipv4 vrf Cust1 3200 neighbor 203.0.113.2 activate 3201 address-family ipv6 vrf Cust1 3202 neighbor 203.0.113.2 activate 3203 neighbor 203.0.113.2 route-map SET-NH-IPV6 out 3205 Example #2 of PE configuration done 3206 by management system (two sessions): 3208 router bgp 100 3209 neighbor 203.0.113.2 remote-as 65000 3210 neighbor 2001::2 remote-as 65000 3211 address-family ipv4 vrf Cust1 3212 neighbor 203.0.113.2 activate 3213 address-family ipv6 vrf Cust1 3214 neighbor 2001::2 activate 3216 Example #3 of PE configuration done 3217 by management system (multisession): 3219 router bgp 100 3220 neighbor 203.0.113.2 remote-as 65000 3221 neighbor 203.0.113.2 multisession per-af 3222 address-family ipv4 vrf Cust1 3223 neighbor 203.0.113.2 activate 3224 address-family ipv6 vrf Cust1 3225 neighbor 203.0.113.2 activate 3226 neighbor 203.0.113.2 route-map SET-NH-IPV6 out 3228 6.12. Service 3230 The service defines service parameters associated with the site. 3232 6.12.1. Bandwidth 3234 The service bandwidth refers to the bandwidth requirement between PE 3235 and CE (WAN link bandwidth). The requested bandwidth is expressed as 3236 svc-input-bandwidth and svc-output-bandwidth in bits per seconds. 3237 Input/output direction is using customer site as reference: input 3238 bandwidth means download bandwidth for the site, and output bandwidth 3239 means upload bandwidth for the site. 3241 The service bandwidth is only configurable at site-network-access 3242 level. 3244 Using a different input and output bandwidth will allow service 3245 provider to know if customer allows for asymmetric bandwidth access 3246 like ADSL. It can also be used to set rate-limit in a different way 3247 upload and download on a symmetric bandwidth access. 3249 The bandwidth is a service bandwidth: expressed primarily as IP 3250 bandwidth but if the customer enables MPLS for carrier's carrier, 3251 this becomes MPLS bandwidth. 3253 6.12.2. QoS 3255 The model proposes to define QoS parameters in an abstracted way: 3257 o qos-classification-policy: define a set of ordered rules to 3258 classify customer traffic. 3260 o qos-profile: QoS scheduling profile to be applied. 3262 6.12.2.1. QoS classification 3264 QoS classification rules are handled by qos-classification-policy. 3265 The qos-classification-policy is an ordered list of rules that match 3266 a flow or application and set the appropriate target class of service 3267 (target-class-id). The user can define the match using an 3268 application reference or a more specific flow definition (based layer 3269 3 source and destination address, layer 4 ports, layer 4 protocol). 3270 When a flow definition is used, the user can use a target-sites leaf- 3271 list to identify the destination of a flow rather than using 3272 destination IP addresses. In such a case, an association between the 3273 site abstraction and the IP addresses used by this site must be done 3274 dynamically. How this association is done is out of scope of this 3275 document and an implementation may not support this criterion and 3276 should advertise a deviation in this case. A rule that does not have 3277 a match statement is considered as a match-all rule. A service 3278 provider may implement a default terminal classification rule if the 3279 customer does not provide it. It will be up to the service provider 3280 to determine its default target class. The current model defines 3281 some applications but new application identities may be added through 3282 augmentation. The exact meaning of each application identity is up 3283 to the service provider, so it will be necessary for the service 3284 provider to advise customer on usage of application matching. 3286 Where the classification is done depends on the SP implementation of 3287 the service, but classification concerns the flow coming from the 3288 customer site and entering the network. 3290 Provider network 3291 +-----------------------+ 3292 192.0.2.0/24 3293 198.51.100.0/24 ---- CE --------- PE 3295 Traffic flow 3296 ----------> 3298 In the figure above, the management system should implement the 3299 classification rule: 3301 o in the ingress direction on the PE interface, if the CE is 3302 customer managed. 3304 o in the ingress direction on the CE interface connected to customer 3305 LAN, if the CE is provider managed. 3307 The figure below describes a sample service description of qos- 3308 classification for a site : 3310 3311 3312 3313 3314 1 3315 3316 192.0.2.0/24 3317 203.0.113.1/32 3318 80 3319 tcp 3320 3321 DATA2 3322 3323 3324 2 3325 3326 192.0.2.0/24 3327 203.0.113.1/32 3328 21 3329 tcp 3330 3331 DATA2 3332 3333 3334 3 3335 p2p 3336 DATA3 3337 3338 3339 4 3340 DATA1 3341 3342 3343 3344 3346 In the example above: 3348 o HTTP traffic from 192.0.2.0/24 LAN destinated to 203.0.113.1/32 3349 will be classified in DATA2. 3351 o FTP traffic from 192.0.2.0/24 LAN destinated to 203.0.113.1/32 3352 will be classified in DATA2. 3354 o Peer to peer traffic will be classified in DATA3. 3356 o All other traffic will be classified in DATA1. 3358 The order of rules is really important. The management system 3359 responsible for translating those rules in network element 3360 configuration MUST keep the same processing order in network element 3361 configuration. The order of rule is defined by the "id" leaf. The 3362 lowest "id" MUST be processed first. 3364 6.12.2.2. QoS profile 3366 User can choose between standard profile provided by the operator or 3367 custom profile. The qos-profile defines the traffic scheduling 3368 policy to be used by the service provider. 3370 Provider network 3371 +-----------------------+ 3372 192.0.2.0/24 3373 198.51.100.0/24 ---- CE --------- PE 3374 \ / 3375 qos-profile 3377 In case of provider managed or co-managed connection, the provider 3378 should ensure scheduling according to the requested policy in both 3379 traffic directions (SP to customer and customer to SP). As example 3380 of implementation, a device scheduling policy may be implemented both 3381 at PE and CE side on the WAN link. In case of customer managed 3382 connection, the provider is only responsible to ensure scheduling 3383 from SP network to the customer site. As example of implementation, 3384 a device scheduling policy may be implemented only at PE side on the 3385 WAN link towards the customer. 3387 A custom qos-profile is defined as a list of class of services and 3388 associated properties. The properties are: 3390 o rate-limit: used to rate-limit the class of service. The value is 3391 expressed as a percentage of the global service bandwidth. When 3392 the qos-profile is implemented at CE side the svc-output-bandwidth 3393 is taken into account as reference. When it is implemented at PE 3394 side, the svc-input-bandwidth is used. 3396 o latency: used to define the latency constraint of the class. The 3397 latency constraint can be expressed as the lowest possible latency 3398 or a latency boundary expressed in milliseconds. How this latency 3399 constraint will be fulfilled is up to the service provider 3400 implementation: a strict priority queueing may be used on the 3401 access and in the core network, and/or a low latency routing may 3402 be created for this traffic class. 3404 o jitter: used to define the jitter constraint of the class. The 3405 jitter constraint can be expressed as the lowest possible jitter 3406 or a jitter boundary expressed in microseconds. How this jitter 3407 constraint will be fulfilled is up to the service provider 3408 implementation: a strict priority queueing may be used on the 3409 access and in the core network, and/or a jitter-aware routing may 3410 be created for this traffic class. 3412 o bandwidth: used to define a guaranteed amount of bandwidth for the 3413 class of service. It is expressed as a percentage. The 3414 guaranteed-bw-percent uses available bandwidth as a reference. 3415 When the qos-profile is implemented at CE side the svc-output- 3416 bandwidth is taken into account as reference. When it is 3417 implemented at PE side, the svc-input-bandwidth is used. By 3418 default, the bandwidth reservation is only guaranteed at the 3419 access level. The user can use the "end-to-end" leaf to request 3420 an end-to-end bandwidth reservation including the MPLS transport 3421 network. 3423 Some constraints may not be offered by a service provider, in this 3424 case a deviation should be advertised. In addition, due to the 3425 network conditions, some constraints may not be completely fulfilled 3426 by the service provider, in this case, the service provider should 3427 advise the customer about the limitations. How this communication is 3428 done is out of scope of this document. 3430 Example of service configuration using a standard qos profile: 3432 3433 1245HRTFGJGJ154654 3434 3435 100000000 3436 100000000 3437 3438 3439 PLATINUM 3440 3441 3442 3443 3444 3445 555555AAAA2344 3446 3447 2000000 3448 2000000 3449 3450 3451 GOLD 3452 3453 3454 3455 3457 Example of service configuration using a custom qos profile: 3459 3460 Site1 3461 3462 100000000 3463 100000000 3464 3465 3466 3467 3468 REAL_TIME 3469 10 3470 3471 3472 3473 3474 3475 DATA1 3476 3477 70 3478 3479 3480 3481 80 3482 3483 3484 3485 3486 DATA2 3487 3488 200 3489 3490 3491 3492 5 3493 3494 3495 3496 3497 3498 3499 3500 3501 3503 The custom qos-profile for site1 defines a REAL_TIME class with a 3504 lowest possible latency constraint. It defines also two data classes 3505 DATA1 and DATA2. The two classes express a latency boundary 3506 constraint as well as a bandwidth reservation. As the REAL_TIME 3507 class is rate-limited to 10% of the service bandwidth (10% of 100Mbps 3508 = 10Mbps). In case of congestion, the REAL_TIME traffic can go up to 3509 10Mbps (let's assume that only 5Mbps are consumed). DATA1 and DATA2 3510 will share the remaining bandwidth (95Mbps) according to their 3511 percentage. So the DATA1 class will be served with at least 76Mbps 3512 of bandwidth while the DATA2 class will be served with at least 3513 4.75Mbps. The latency boundary information of the data class may 3514 help the service provider to define a specific buffer tuning or a 3515 specific routing within the network. The maximum percentage to be 3516 used is not limited by this model but MUST be limited by the 3517 management system according to the policies authorized by the service 3518 provider. 3520 6.12.3. Multicast 3522 The multicast section defines the type of site in the customer 3523 multicast service topology: source, receiver, or both. These 3524 parameters will help management system to optimize the multicast 3525 service. User can also define the type of multicast relation with 3526 the customer: router (requires a protocol like PIM), host (IGMP or 3527 MLD), or both. Address family (IPv4 or IPv6 or both) can also be 3528 defined. 3530 6.13. Enhanced VPN features 3532 6.13.1. Carrier's Carrier 3534 In case of Carrier's Carrier ([RFC4364]), a customer may want to 3535 build MPLS service using an IPVPN to carry its traffic. 3537 LAN customer1 3538 | 3539 | 3540 CE1 3541 | 3542 | ------------- 3543 (vrf_cust1) 3544 CE1_ISP1 3545 | ISP1 PoP 3546 | MPLS link 3547 | ------------- 3548 | 3549 (vrf ISP1) 3550 PE1 3552 (...) Provider backbone 3554 PE2 3555 (vrf ISP1) 3556 | 3557 | ------------ 3558 | 3559 | MPLS link 3560 | ISP1 PoP 3561 CE2_ISP1 3562 (vrf_cust1) 3563 |------------- 3564 | 3565 CE2 3566 | 3567 Lan customer1 3569 In the figure above, ISP1 resells IPVPN service but has no core 3570 network infrastructure between its PoPs. ISP1 uses an IPVPN as core 3571 network infrastructure (belonging to another provider) between its 3572 PoPs. 3574 In order to support CsC, the VPN service must be declared MPLS 3575 support using the "carrierscarrier" leaf set to true in vpn-service. 3576 The link between CE1_ISP1/PE1 and CE2_ISP1/PE2 must also run an MPLS 3577 signalling protocol. This configuration is done at the site level. 3579 In the proposed model, LDP or BGP can be used as the MPLS signalling 3580 protocol. In case of LDP, an IGP routing protocol MUST also be 3581 activated. In case of BGP signalling, BGP MUST also be configured as 3582 routing-protocol. 3584 In case Carrier's Carrier is enabled, the requested svc-mtu will 3585 refer to the MPLS MTU and not to the IP MTU. 3587 6.14. External ID references 3589 The service model sometimes refers to external information through 3590 identifiers. As an example, to order a cloud-access to a particular 3591 Cloud Service Provider (CSP), the model uses an identifier to refer 3592 to the targeted CSP. In case, a customer is using directly this 3593 service model as an API (through REST or NETCONF for example) to 3594 order a particular service, the service provider should provide a 3595 list of authorized identifiers. In case of cloud-access, the service 3596 provider will provide the identifiers associated of each available 3597 CSP. The same applies to other identifiers like std-qos-profile, oam 3598 profile-name, provider-profile for encryption ... 3600 How an SP provides those identifiers meaning to the customer is out 3601 of scope of this document. 3603 6.15. Defining NNIs 3605 An autonomous system is a single network or group of networks that is 3606 controlled by a common system administration group and that uses a 3607 single, clearly defined routing protocol. In some cases, VPNs need 3608 to span across different autonomous systems in different geographic 3609 areas or across different service providers. The connection between 3610 autonomous systems is established by the Service Providers and is 3611 seamless to the customer. 3613 Some examples are: Partnership between service providers (carrier, 3614 cloud ...) to extend their VPN service seamlessly, or internal 3615 administrative boundary within a single service provider (Backhaul vs 3616 Core vs Datacenter ...). 3618 NNIs (Network to Network Interfaces) have to be defined to extend the 3619 VPNs across multiple autonomous systems. 3621 [RFC4364] defines multiple flavors of VPN NNI implementations. Each 3622 implementation has different pros/cons that are outside the scope of 3623 this document. As an example: In an Inter-AS Option A, ASBR peers 3624 are connected by multiple interfaces with at least one interface 3625 which VPN spans the two autonomous systems. These ASBRs associate 3626 each interface with a VPN routing and forwarding (VRF) instance and a 3627 Border Gateway Protocol (BGP) session to signal unlabeled IP 3628 prefixes. As a result, traffic between the back-to-back VRFs is IP. 3630 In this scenario, the VPNs are isolated from each other, and because 3631 the traffic is IP, QoS mechanisms that operate on IP traffic can be 3632 applied to achieve customer Service Level Agreements (SLAs). 3634 -------- -------------- ----- 3635 / \ / \ / \ 3636 | Cloud | | | | | 3637 | Provider | ----NNI---- | | ---NNI---| DC | 3638 | #1 | | | | | 3639 \ / | | \ / 3640 -------- | | ---- 3641 | | 3642 -------- | My network | ----------- 3643 / \ | | / \ 3644 | Cloud | | | | | 3645 | Provider | ----NNI---- | |---NNI---| L3VPN | 3646 | #2 | | | | Partner | 3647 \ / | | | | 3648 -------- | | | | 3649 \ / | | 3650 -------------- \ / 3651 | ---------- 3652 | 3653 NNI 3654 | 3655 | 3656 ------------------- 3657 / \ 3658 | | 3659 | | 3660 | | 3661 | L3VPN partner | 3662 | | 3663 \ / 3664 ------------------ 3666 The figure above describes a service provider network "My network" 3667 that has several NNIs. This network uses NNI to: 3669 o increase its footprint by relying on L3VPN partners. 3671 o connect its own datacenter services to the customer IPVPN. 3673 o enable customer to access to its private resources located in 3674 private cloud owned by some cloud service providers. 3676 6.15.1. Defining NNI with option A flavor 3678 AS A AS B 3679 --------------------- -------------------- 3680 / \ / \ 3681 | | | | 3682 | ++++++++ InterAS link ++++++++ | 3683 | + +_____________ + + | 3684 | + (VRF1)--(VPN1)----(VRF1) + | 3685 | + ASBR + + ASBR + | 3686 | + (VRF2)--(VPN2)----(VRF2) + | 3687 | + +______________+ + | 3688 | ++++++++ ++++++++ | 3689 | | | | 3690 | | | | 3691 | | | | 3692 | ++++++++ InterAS link ++++++++ | 3693 | + +_____________ + + | 3694 | + (VRF1)--(VPN1)----(VRF1) + | 3695 | + ASBR + + ASBR + | 3696 | + (VRF2)--(VPN2)----(VRF2) + | 3697 | + +______________+ + | 3698 | ++++++++ ++++++++ | 3699 | | | | 3700 | | | | 3701 \ / \ / 3702 -------------------- ------------------- 3704 In option A, the two ASes are connected between each other with 3705 physical links on Autonomous System Border Routers (ASBR). There may 3706 be multiple physical connections between the ASes for a resiliency 3707 purpose. A VPN connection, physical or logical (on top of physical), 3708 is created for each VPN that needs to cross the AS boundary. A back- 3709 to-back VRF model is so created. 3711 This VPN connection can be seen as a site from a service model 3712 perspective. Let's say that AS B wants to extend some VPN connection 3713 for VPN C on AS A. Administrator of AS B can use this service model 3714 to order a site on AS A. All connection scenarios could be realized 3715 using the current model features. As an example, the figure above, 3716 where two physical connections are involved with logical connections 3717 per VPN on top, could be seen as a dualhomed subVPN scenario. And 3718 for example, administrator from AS B will be able to choose the 3719 appropriate routing protocol (e.g. ebgp) to dynamically exchange 3720 routes between ASes. 3722 This document assumes that option A NNI flavor SHOULD reuse the 3723 existing VPN site modeling. 3725 Example: a customer wants from its cloud service provider A to attach 3726 its virtual network N to an existing IPVPN (VPN1) he has from a L3VPN 3727 service provider B. 3729 CSP A L3VPN SP B 3731 ----------------- -------------------- 3732 / \ / \ 3733 | | | | | 3734 | VM --| ++++++++ NNI ++++++++ |---- VPN1 3735 | | + +_________+ + | Site#1 3736 | |--------(VRF1)---(VPN1)--(VRF1)+ | 3737 | | + ASBR + + ASBR + | 3738 | | + +_________+ + | 3739 | | ++++++++ ++++++++ | 3740 | VM --| | | |---- VPN1 3741 | |Virtual | | | Site#2 3742 | |Network | | | 3743 | VM --| | | |---- VPN1 3744 | | | | | Site#3 3745 \ / \ / 3746 ---------------- ------------------- 3747 | 3748 | 3749 VPN1 3750 Site#4 3752 The cloud service provider or the customer may use our L3VPN service 3753 model exposed by service provider B to create the VPN connectivity. 3754 We could consider that, as the NNI is shared, the physical connection 3755 (bearer) between CSP A and SP B already exists. CSP A may request 3756 through a service model a new site creation with a single site- 3757 network-access (single homing used in the diagram). As placement 3758 constraint, CSP A may use the existing bearer reference it has from 3759 SP A to force the placement of the VPN NNI on the existing link. The 3760 XML below describes what could be the configuration request to SP B: 3762 3763 CSP_A_attachment 3764 3765 NY 3766 US 3767 3768 site-vpn-flavor-nni 3769 3770 3771 bgp 3772 3773 500 3774 ipv4 3775 3776 3777 3778 3779 3780 CSP_A_VN1 3781 3782 3783 3784 static-address 3785 3786 3787 203.0.113.1 3788 203.0.113.2 3789 30 3790 3791 3792 3793 3794 450000000 3795 450000000 3796 3797 3798 VPN1 3799 any-to-any-role 3800 3801 3802 3803 3804 customer-managed 3805 3806 3808 The case described above is different from the cloud-access container 3809 usage as the cloud-access provides a public cloud access while this 3810 example enables access to private resources located in a cloud 3811 service provider network. 3813 6.15.2. Defining NNI with option B flavor 3815 AS A AS B 3816 --------------------- -------------------- 3817 / \ / \ 3818 | | | | 3819 | ++++++++ InterAS link ++++++++ | 3820 | + +_____________ + + | 3821 | + + + + | 3822 | + ASBR +<---mpebgp--->+ ASBR + | 3823 | + + + + | 3824 | + +______________+ + | 3825 | ++++++++ ++++++++ | 3826 | | | | 3827 | | | | 3828 | | | | 3829 | ++++++++ InterAS link ++++++++ | 3830 | + +_____________ + + | 3831 | + + + + | 3832 | + ASBR +<---mpebgp--->+ ASBR + | 3833 | + + + + | 3834 | + +______________+ + | 3835 | ++++++++ ++++++++ | 3836 | | | | 3837 | | | | 3838 \ / \ / 3839 -------------------- ------------------- 3841 In option B, the two ASes are connected between each other with 3842 physical links on Autonomous System Border Routers (ASBR). There may 3843 be multiple physical connections between the ASes for a resiliency 3844 purpose. The VPN "connection" between ASes is done by exchanging VPN 3845 routes through MP-BGP. 3847 There are multiple flavors of implementations of such NNI, for 3848 example: 3850 1. The NNI is a provider internal NNI between a backbone and a DC. 3851 There is enough trust between the domains to not filter the VPN 3852 routes. So all the VPN routes are exchanged. Route target 3853 filtering may be implemented to save some unnecessary route 3854 states. 3856 2. The NNI is used between providers that agreed to exchange VPN 3857 routes for specific route-targets only. Each provider is 3858 authorized to use the route-target values from the other 3859 provider. 3861 3. The NNI is used between providers that agreed to exchange VPN 3862 routes for specific route-targets only. Each provider has its 3863 own route-target scheme. So a customer spanning the two networks 3864 will have different route-target in each network for a particular 3865 VPN. 3867 Case 1 does not require any service modeling, as the protocol enables 3868 dynamic exchange of necessary VPN routes. 3870 Case 2 requires to maintain some route-target filtering policy on 3871 ASBRs. From a service modeling point of view, it is necessary to 3872 agree on the list of route target to authorize. 3874 In case 3, both ASes need to agree on the VPN route-target to 3875 exchange and in addition how to map a VPN route-target from AS A to 3876 the corresponding route-target in AS B (and vice-versa). 3878 Those modelings are currently out of scope of this document. 3880 Cloud SP L3VPN SP B 3881 A 3882 ----------------- -------------------- 3883 / \ / \ 3884 | | | | | 3885 | VM --| ++++++++ NNI ++++++++ |---- VPN1 3886 | | + +_________+ + | Site#1 3887 | |-------+ + + + | 3888 | | + ASBR +<-mpebgp->+ ASBR + | 3889 | | + +_________+ + | 3890 | | ++++++++ ++++++++ | 3891 | VM --| | | |---- VPN1 3892 | |Virtual | | | Site#2 3893 | |Network | | | 3894 | VM --| | | |---- VPN1 3895 | | | | | Site#3 3896 \ / | | 3897 ---------------- | | 3898 \ / 3899 ------------------- 3900 | 3901 | 3902 VPN1 3903 Site#4 3905 The example above describes an NNI connection between the service 3906 provider network B and a cloud service provider A. Both service 3907 providers do not trust themselves and use a different route-target 3908 allocation policy. So, in term of implementation, the customer VPN 3909 has a different route-target in each network (RT A in CSP A and RT B 3910 is CSP B). In order to connect the customer virtual network in CSP A 3911 to the customer IPVPN (VPN1) in SP B network, CSP A should request SP 3912 B to open the customer VPN on the NNI (accept the appropriate RT). 3913 Who does the RT translation is up to an agreement between the two 3914 service providers: SP B may permit CSP A to request VPN (RT) 3915 translation. 3917 6.15.3. Defining NNI with option C flavor 3918 AS A AS B 3919 --------------------- -------------------- 3920 / \ / \ 3921 | | | | 3922 | | | | 3923 | | | | 3924 | ++++++++ Multihop ebgp++++++++ | 3925 | + + + + | 3926 | + + + + | 3927 | + RGW +<---mpebgp--->+ RGW + | 3928 | + + + + | 3929 | + + + + | 3930 | ++++++++ ++++++++ | 3931 | | | | 3932 | | | | 3933 | | | | 3934 | | | | 3935 | | | | 3936 | ++++++++ InterAS link ++++++++ | 3937 | + +_____________ + + | 3938 | + + + + | 3939 | + ASBR + + ASBR + | 3940 | + + + + | 3941 | + +______________+ + | 3942 | ++++++++ ++++++++ | 3943 | | | | 3944 | | | | 3945 | | | | 3946 | ++++++++ InterAS link ++++++++ | 3947 | + +_____________ + + | 3948 | + + + + | 3949 | + ASBR + + ASBR + | 3950 | + + + + | 3951 | + +______________+ + | 3952 | ++++++++ ++++++++ | 3953 | | | | 3954 | | | | 3955 \ / \ / 3956 -------------------- ------------------- 3958 From a VPN service perspective, option C NNI is very similar to 3959 option B as an MP-BGP session is used to exchange VPN routes between 3960 the ASes. The difference is that the forwarding and control plane 3961 are on different nodes, so the MP-BGP is multihop between routing 3962 gateway (RGW) nodes. 3964 Modeling option B and C will be identical from a VPN service point of 3965 view. 3967 7. Service model usage example 3969 As explained in Section 5, this service model is intended to be 3970 instantiated at a management layer and is not intended to be used 3971 directly on network elements. The management system serves as a 3972 central point of configuration of the overall service. 3974 This section provides an example on how a management system can use 3975 this model to configure an IPVPN service on network elements. 3977 The example wants to achieve the provisionning of a VPN service for 3 3978 sites using Hub and Spoke VPN service topology. One of the sites 3979 will be dual homed and loadsharing is expected. 3981 +-------------------------------------------------------------+ 3982 | Hub_Site ------ PE1 PE2 ------ Spoke_Site1 | 3983 | | +----------------------------------+ 3984 | | | 3985 | | +----------------------------------+ 3986 | Hub_Site ------ PE3 PE4 ------ Spoke_Site2 | 3987 +-------------------------------------------------------------+ 3989 The following XML describes the overall simplified service 3990 configuration of this VPN. 3992 3993 12456487 3994 hub-spoke 3995 3997 When receiving the request for provisioning the VPN service, the 3998 management system will internally (or through communication with 3999 another OSS component) allocates VPN route-targets. In this specific 4000 case two RTs will be allocated (100:1 for Hub and 100:2 for Spoke). 4001 The output below describes the configuration of Spoke1. 4003 4004 Spoke_Site1 4005 4006 NY 4007 US 4008 4009 4010 4011 bgp 4012 4013 500 4014 ipv4 4015 ipv6 4016 4017 4018 4019 4020 4021 Spoke_Site1 4022 4023 4024 4025 20 4026 4027 4028 4029 4030 pe-diverse 4031 4032 4033 10 4034 4035 4036 4037 4038 4039 4040 4041 4042 static-address 4043 4044 4045 203.0.113.254 4046 203.0.113.2 4047 24 4048 4049 4050 4051 4052 static-address 4053 4054 4055 2001:db8::1 4056 2001:db8::2 4057 64 4058 4059 4061 4062 4063 450000000 4064 450000000 4065 4066 4067 12456487 4068 spoke-role 4069 4070 4071 4072 4073 provider-managed 4074 4075 4077 When receiving the request for provisioning Spoke1 site, the 4078 management system MUST allocate network resources for this site. It 4079 MUST first determine the target network elements to provision the 4080 access, and especially the PE router (and may be an aggregation 4081 switch). As described in Section 6.6, the management system SHOULD 4082 use the location information and SHOULD use the access-diversity 4083 constraint to find the appropriate PE. In this case, we consider 4084 Spoke1 requires PE diversity with Hub and that management system 4085 allocate PEs based on lowest distance. Based on the location 4086 information, the management system finds the available PEs in the 4087 nearest area of the customer and picks one that fits the access- 4088 diversity constraint. 4090 When the PE is chosen, the management system needs to allocate 4091 interface resources on the node. One interface is selected from the 4092 PE available pool. The management system can start provisioning the 4093 PE node by using any mean (Netconf, CLI, ...). The management system 4094 will check if a VRF is already present that fits the needs. If not, 4095 it will provision the VRF: Route distinguisher will come from 4096 internal allocation policy model, route-targets are coming from the 4097 vpn-policy configuration of the site (management system allocated 4098 some RTs for the VPN). As the site is a Spoke site (site-role), the 4099 management system knows which RT must be imported and exported. As 4100 the site is provider managed, some management route-targets may also 4101 be added (100:5000). Standard provider VPN policies MAY also be 4102 added in the configuration. 4104 Example of generated PE configuration: 4106 ip vrf Customer1 4107 export-map STD-CUSTOMER-EXPORT <---- Standard SP configuration 4108 route-distinguisher 100:3123234324 4109 route-target import 100:1 4110 route-target import 100:5000 <---- Standard SP configuration 4111 route-target export 100:2 for provider managed 4112 ! 4114 When the VRF has been provisioned, the management system can start 4115 configuring the access on the PE using the allocated interface 4116 information. IP addressing is chosen by the management system. One 4117 address will be picked from an allocated subnet for the PE, another 4118 will be used for the CE configuration. Routing protocols will also 4119 be configured between PE and CE and due to provider managed model, 4120 the choice is up to service provider: BGP was chosen for the example. 4121 This choice is independant of the routing protocol chosen by 4122 customer. For the CE - LAN part, BGP will be used as requested in 4123 the service model. Peering addresses will be derived from those of 4124 the connection. As CE is provider managed, CE AS number can be 4125 automatically allocated by the management system. Some provider 4126 standard configuration templates may also be added. 4128 Example of generated PE configuration: 4130 interface Ethernet1/1/0.10 4131 encapsulation dot1q 10 4132 ip vrf forwarding Customer1 4133 ip address 198.51.100.1 255.255.255.252 <---- Comes from 4134 automated allocation 4135 ipv6 address 2001:db8::10:1/64 4136 ip access-group STD-PROTECT-IN <---- Standard SP config 4137 ! 4138 router bgp 100 4139 address-family ipv4 vrf Customer1 4140 neighbor 198.51.100.2 remote-as 65000 <---- Comes from 4141 automated allocation 4142 neighbor 198.51.100.2 route-map STD in <---- Standard SP config 4143 neighbor 198.51.100.2 filter-list 10 in <---- Standard SP config 4144 ! 4145 address-family ipv6 vrf Customer1 4146 neighbor 2001:db8::0A10:2 remote-as 65000 <---- Comes from 4147 automated allocation 4148 neighbor 2001:db8::0A10:2 route-map STD in <---- Standard SP config 4149 neighbor 2001:db8::0A10:2 filter-list 10 in <---- Standard SP config 4150 ! 4151 ip route vrf Customer1 192.0.2.1 255.255.255.255 198.51.100.2 4152 ! Static route for provider administration of CE 4153 ! 4155 As the CE router is not reachable at this stage, the management 4156 system can produce a complete CE configuration that can be uploaded 4157 to the node by manual operation before sending the CE to customer 4158 premise. The CE configuration will be built as for the PE. Based on 4159 the CE type (vendor/model) allocated to the customer and bearer 4160 information, the management system knows which interface must be 4161 configured on the CE. PE-CE link configuration is expected to be 4162 handled automatically using the service provider OSS as both 4163 resources are managed internally. CE to LAN interface parameters 4164 like IP addressing are derived from ip-connection taking into account 4165 how management system distributes addresses between PE and CE within 4166 the subnet. This will allow to produce a plug'n'play configuration 4167 for the CE. 4169 Example of generated CE configuration: 4171 interface Loopback10 4172 description "Administration" 4173 ip address 192.0.2.1 255.255.255.255 4174 ! 4175 interface FastEthernet10 4176 description "WAN" 4177 ip address 198.51.100.2 255.255.255.252 <---- Comes from 4178 automated allocation 4179 ipv6 address 2001:db8::0A10:2/64 4180 ! 4181 interface FastEthernet11 4182 description "LAN" 4183 ip address 203.0.113.254 255.255.255.0 <---- Comes from 4184 ip-connection 4185 ipv6 address 2001:db8::1/64 4186 ! 4187 router bgp 65000 4188 address-family ipv4 4189 redistribute static route-map STATIC2BGP <---- Standard SP 4190 configuration 4191 neighbor 198.51.100.1 remote-as 100 <---- Comes from 4192 automated allocation 4193 neighbor 203.0.113.2 remote-as 500 <---- Comes from 4194 ip-connection 4195 address-family ipv6 4196 redistribute static route-map STATIC2BGP <---- Standard SP 4197 configuration 4198 neighbor 2001:db8::0A10:1 remote-as 100 <---- Comes from 4199 automated allocation 4200 neighbor 2001:db8::2 remote-as 500 <---- Comes from 4201 ip-connection 4202 ! 4203 route-map STATIC2BGP permit 10 4204 match tag 10 4205 ! 4207 8. Interaction with Other YANG Modules 4209 As expressed in Section 5, this service module is intended to be 4210 instantiated in management system and not directly on network 4211 elements. 4213 It will be the role of the management system to configure the network 4214 elements. The management system may be modular, so the component 4215 instantiating the service model (let's call it service component) and 4216 the component responsible for network element configuration (let's 4217 call it configuration component) may be different. 4219 L3VPN-SVC | 4220 service model | 4221 | 4222 +----------------------+ 4223 | Service component | service datastore 4224 +----------------------+ 4225 | 4226 | 4227 +----------------------+ 4228 +----| Config component |-------+ 4229 / +----------------------+ \ Network 4230 / / \ \ Configuration 4231 / / \ \ models 4232 / / \ \ 4233 +++++++ ++++++++ ++++++++ +++++++ 4234 + CEA + ------- + PE A + + PE B + ----- + CEB + Config 4235 +++++++ ++++++++ ++++++++ +++++++ datastore 4237 Site A Site B 4239 In the previous sections, we provided some example of translation of 4240 service provisioning request to router configuration lines as an 4241 illustration. In the NETCONF/YANG ecosystem, it will be expected 4242 NETCONF/YANG to be used between configuration component and network 4243 elements to configure the requested service on these elements. 4245 In this framework, it is expected from standardization to also work 4246 on specific configuration YANG modelization of service components on 4247 network elements. There will be a strong relation between the 4248 abstracted view provided by this service model and the detailed 4249 configuration view that will be provided by specific configuration 4250 models for network elements. 4252 Authors of this document are expecting definition of YANG models for 4253 network elements on this non exhaustive list of items: 4255 o VRF definition including VPN policy expression. 4257 o Physical interface. 4259 o IP layer (IPv4, IPv6). 4261 o QoS: classification, profiles... 4263 o Routing protocols: support of configuration of all protocols 4264 listed in the document, as well as routing policies associated 4265 with these protocols. 4267 o Multicast VPN. 4269 o Network Address Translation. 4271 o ... 4273 Example of VPN site request at service level using this model: 4275 4276 Site A 4277 4278 4279 4280 4281 4282 static-address 4283 4284 4285 203.0.113.254 4286 203.0.113.2 4287 24 4288 4289 4290 4291 4292 VPNPOL1 4293 4294 4295 4296 4297 4298 static 4299 4300 4301 4302 198.51.100.0/30 4303 203.0.113.2 4304 4305 4306 4307 4308 4309 4310 customer-managed 4312 4313 4314 4315 VPNPOL1 4316 4317 1 4318 4319 VPN1 4320 any-to-any-role 4321 4322 4323 4324 4325 4327 In the service example above, it is expected that the service 4328 component requests to the configuration component of the management 4329 system the configuration of the service elements. If we consider 4330 that service component selected a PE (PE A) as target PE for the 4331 site, the configuration component will need to push the configuration 4332 to PE A. The configuration component will use several YANG data 4333 models to define the configuration to be applied to PE A. The XML 4334 configuration of PE-A may look like this: 4336 4337 4338 eth0 4339 ianaift:ethernetCsmacd 4340 4341 Link to CEA. 4342 4343 4344 4345 203.0.113.254 4346 24 4347 4348 true 4349 4350 4351 4352 4353 4354 VRF_CustA 4355 l3vpn:vrf 4356 VRF for CustomerA 4357 4358 100:1546542343 4359 4360 100:1 4361 100:1 4362 4363 4364 eth0 4365 4366 4367 4368 4369 rt:static 4370 st0 4371 4372 4373 4374 4375 198.51.100.0/30 4376 4377 4378 4379 203.0.113.2 4380 4381 4382 4383 4384 4385 4386 4387 4388 4390 9. YANG Module 4392 file "ietf-l3vpn-svc@2016-11-04.yang" 4394 module ietf-l3vpn-svc { 4395 namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc"; 4397 prefix l3vpn-svc; 4399 import ietf-inet-types { 4400 prefix inet; 4401 } 4403 import ietf-yang-types { 4404 prefix yang; 4405 } 4406 organization 4407 "IETF L3SM Working Group"; 4409 contact 4410 "WG List: <mailto:l3sm@ietf.org> 4412 Editor: 4413 L3SM WG 4415 Chairs: 4416 Adrian Farrel, Qin Wu 4417 "; 4419 description 4420 "The YANG module defines a generic service configuration 4421 model for Layer 3 VPN common across all of the vendor 4422 implementations."; 4424 revision 2016-11-03 { 4425 description 4426 "Initial document"; 4427 reference 4428 "RFC XXXX"; 4429 } 4431 /* Features */ 4433 feature cloud-access { 4434 description 4435 "Allow VPN to connect to a Cloud Service 4436 provider."; 4437 } 4438 feature multicast { 4439 description 4440 "Enables multicast capabilities in a VPN"; 4441 } 4442 feature ipv4 { 4443 description 4444 "Enables IPv4 support in a VPN"; 4445 } 4446 feature ipv6 { 4447 description 4448 "Enables IPv6 support in a VPN"; 4449 } 4450 feature carrierscarrier { 4451 description 4452 "Enables support of carrier's carrier"; 4454 } 4455 feature extranet-vpn { 4456 description 4457 "Enables support of extranet VPNs"; 4458 } 4459 feature site-diversity { 4460 description 4461 "Enables support of site diversity constraints"; 4462 } 4463 feature encryption { 4464 description 4465 "Enables support of encryption"; 4466 } 4467 feature qos { 4468 description 4469 "Enables support of Class of Services"; 4470 } 4471 feature qos-custom { 4472 description 4473 "Enables support of custom qos profile"; 4474 } 4475 feature rtg-bgp { 4476 description 4477 "Enables support of BGP routing protocol."; 4478 } 4479 feature rtg-rip { 4480 description 4481 "Enables support of RIP routing protocol."; 4482 } 4483 feature rtg-ospf { 4484 description 4485 "Enables support of OSPF routing protocol."; 4486 } 4487 feature rtg-ospf-sham-link { 4488 description 4489 "Enables support of OSPF sham-links."; 4490 } 4491 feature rtg-vrrp { 4492 description 4493 "Enables support of VRRP routing protocol."; 4494 } 4495 feature fast-reroute { 4496 description 4497 "Enables support of Fast Reroute."; 4498 } 4499 feature bfd { 4500 description 4501 "Enables support of BFD."; 4503 } 4504 feature always-on { 4505 description 4506 "Enables support for always-on access 4507 constraint."; 4508 } 4509 feature requested-type { 4510 description 4511 "Enables support for requested-type access 4512 constraint."; 4513 } 4514 feature bearer-reference { 4515 description 4516 "Enables support for bearer-reference access 4517 constraint."; 4518 } 4520 /* Typedefs */ 4522 typedef svc-id { 4523 type string; 4524 description 4525 "Defining a type of service component 4526 identificators."; 4527 } 4529 typedef template-id { 4530 type string; 4531 description 4532 "Defining a type of service template 4533 identificators."; 4534 } 4536 typedef address-family { 4537 type enumeration { 4538 enum ipv4 { 4539 description 4540 "IPv4 address family"; 4541 } 4542 enum ipv6 { 4543 description 4544 "IPv6 address family"; 4545 } 4546 } 4547 description 4548 "Defining a type for address-family."; 4549 } 4550 /* Identities */ 4552 identity site-network-access-type { 4553 description 4554 "Base identity for site-network-access type"; 4555 } 4556 identity point-to-point { 4557 base site-network-access-type; 4558 description 4559 "Identity for point-to-point connection"; 4560 } 4561 identity multipoint { 4562 base site-network-access-type; 4563 description 4564 "Identity for multipoint connection 4565 Example : ethernet broadcast segment"; 4566 } 4568 identity placement-diversity { 4569 description 4570 "Base identity for site placement 4571 constraints"; 4572 } 4573 identity bearer-diverse { 4574 base placement-diversity; 4575 description 4576 "Identity for bearer diversity. 4577 The bearers should not use common elements."; 4578 } 4579 identity pe-diverse { 4580 base placement-diversity; 4581 description 4582 "Identity for PE diversity"; 4583 } 4584 identity pop-diverse { 4585 base placement-diversity; 4586 description 4587 "Identity for POP diversity"; 4588 } 4589 identity linecard-diverse { 4590 base placement-diversity; 4591 description 4592 "Identity for linecard diversity"; 4593 } 4594 identity same-pe { 4595 base placement-diversity; 4596 description 4597 "Identity for having sites connected 4598 on the same PE"; 4599 } 4600 identity same-bearer { 4601 base placement-diversity; 4602 description 4603 "Identity for having sites connected 4604 using the same bearer"; 4605 } 4607 identity customer-application { 4608 description 4609 "Base identity for customer application"; 4610 } 4611 identity web { 4612 base customer-application; 4613 description 4614 "Identity for web application (e.g. HTTP,HTTPS)"; 4615 } 4616 identity mail { 4617 base customer-application; 4618 description 4619 "Identity for mail applications"; 4620 } 4621 identity file-transfer { 4622 base customer-application; 4623 description 4624 "Identity for file transfer applications ( 4625 e.g. FTP, SFTP, ...)"; 4626 } 4627 identity database { 4628 base customer-application; 4629 description 4630 "Identity for database applications"; 4631 } 4632 identity social { 4633 base customer-application; 4634 description 4635 "Identity for social network applications"; 4636 } 4637 identity games { 4638 base customer-application; 4639 description 4640 "Identity for gaming applications"; 4641 } 4642 identity p2p { 4643 base customer-application; 4644 description 4645 "Identity for peer to peer applications"; 4647 } 4648 identity network-management { 4649 base customer-application; 4650 description 4651 "Identity for management applications (e.g. telnet 4652 syslog, snmp ...)"; 4653 } 4654 identity voice { 4655 base customer-application; 4656 description 4657 "Identity for voice applications"; 4658 } 4659 identity video { 4660 base customer-application; 4661 description 4662 "Identity for video conference applications"; 4663 } 4665 identity site-vpn-flavor { 4666 description 4667 "Base identity for the site VPN service flavor."; 4668 } 4669 identity site-vpn-flavor-single { 4670 base site-vpn-flavor; 4671 description 4672 "Base identity for the site VPN service flavor. 4673 Used when the site belongs to only one VPN."; 4674 } 4675 identity site-vpn-flavor-multi { 4676 base site-vpn-flavor; 4677 description 4678 "Base identity for the site VPN service flavor. 4679 Used when a logical connection of a site 4680 belongs to multiple VPNs."; 4681 } 4683 identity site-vpn-flavor-sub { 4684 base site-vpn-flavor; 4685 description 4686 "Base identity for the site VPN service flavor. 4687 Used when a site has multiple logical connections. 4688 Each of the connection may belong to different 4689 multiple VPNs."; 4690 } 4691 identity site-vpn-flavor-nni { 4692 base site-vpn-flavor; 4693 description 4694 "Base identity for the site VPN service flavor. 4695 Used to describe a NNI option A connection."; 4696 } 4697 identity management { 4698 description 4699 "Base identity for site management scheme."; 4700 } 4701 identity co-managed { 4702 base management; 4703 description 4704 "Base identity for comanaged site."; 4705 } 4706 identity customer-managed { 4707 base management; 4708 description 4709 "Base identity for customer managed site."; 4710 } 4711 identity provider-managed { 4712 base management; 4713 description 4714 "Base identity for provider managed site."; 4715 } 4717 identity address-allocation-type { 4718 description 4719 "Base identity for address-allocation-type 4720 for PE-CE link."; 4721 } 4722 identity provider-dhcp { 4723 base address-allocation-type; 4724 description 4725 "Provider network provides DHCP service to customer."; 4726 } 4727 identity provider-dhcp-relay { 4728 base address-allocation-type; 4729 description 4730 "Provider network provides DHCP relay service to customer."; 4731 } 4732 identity provider-dhcp-slaac { 4733 base address-allocation-type; 4734 description 4735 "Provider network provides DHCP service to customer 4736 as well as SLAAC."; 4737 } 4738 identity static-address { 4739 base address-allocation-type; 4740 description 4741 "Provider to customer addressing is static."; 4743 } 4744 identity slaac { 4745 base address-allocation-type; 4746 description 4747 "Use IPv6 SLAAC."; 4748 } 4750 identity site-role { 4751 description 4752 "Base identity for site type."; 4753 } 4754 identity any-to-any-role { 4755 base site-role; 4756 description 4757 "Site in a any to any IPVPN."; 4758 } 4759 identity spoke-role { 4760 base site-role; 4761 description 4762 "Spoke Site in a Hub & Spoke IPVPN."; 4763 } 4764 identity hub-role { 4765 base site-role; 4766 description 4767 "Hub Site in a Hub & Spoke IPVPN."; 4768 } 4770 identity vpn-topology { 4771 description 4772 "Base identity for VPN topology."; 4773 } 4774 identity any-to-any { 4775 base vpn-topology; 4776 description 4777 "Identity for any to any VPN topology."; 4778 } 4779 identity hub-spoke { 4780 base vpn-topology; 4781 description 4782 "Identity for Hub'n'Spoke VPN topology."; 4783 } 4784 identity hub-spoke-disjoint { 4785 base vpn-topology; 4786 description 4787 "Identity for Hub'n'Spoke VPN topology 4788 where Hubs cannot talk between each other."; 4790 } 4792 identity multicast-tree-type { 4793 description 4794 "Base identity for multicast tree type."; 4795 } 4797 identity ssm-tree-type { 4798 base multicast-tree-type; 4799 description 4800 "Identity for SSM tree type."; 4801 } 4802 identity asm-tree-type { 4803 base multicast-tree-type; 4804 description 4805 "Identity for ASM tree type."; 4806 } 4807 identity bidir-tree-type { 4808 base multicast-tree-type; 4809 description 4810 "Identity for BiDir tree type."; 4811 } 4813 identity multicast-rp-discovery-type { 4814 description 4815 "Base identity for rp discovery type."; 4816 } 4817 identity auto-rp { 4818 base multicast-rp-discovery-type; 4819 description 4820 "Base identity for auto-rp discovery type."; 4821 } 4822 identity static-rp { 4823 base multicast-rp-discovery-type; 4824 description 4825 "Base identity for static type."; 4826 } 4827 identity bsr-rp { 4828 base multicast-rp-discovery-type; 4829 description 4830 "Base identity for BDR discovery type."; 4831 } 4833 identity routing-protocol-type { 4834 description 4835 "Base identity for routing-protocol type."; 4836 } 4837 identity ospf { 4838 base routing-protocol-type; 4839 description 4840 "Identity for OSPF protocol type."; 4841 } 4843 identity bgp { 4844 base routing-protocol-type; 4845 description 4846 "Identity for BGP protocol type."; 4847 } 4849 identity static { 4850 base routing-protocol-type; 4851 description 4852 "Identity for static routing protocol type."; 4853 } 4855 identity rip { 4856 base routing-protocol-type; 4857 description 4858 "Identity for RIP protocol type."; 4859 } 4861 identity vrrp { 4862 base routing-protocol-type; 4863 description 4864 "Identity for VRRP protocol type. 4865 This is to be used when LAn are directly connected 4866 to provider Edge routers."; 4867 } 4869 identity direct { 4870 base routing-protocol-type; 4871 description 4872 "Identity for direct protocol type. 4873 ."; 4874 } 4876 identity protocol-type { 4877 description 4878 "Base identity for protocol field type."; 4879 } 4881 identity tcp { 4882 base protocol-type; 4883 description 4884 "TCP protocol type."; 4886 } 4887 identity udp { 4888 base protocol-type; 4889 description 4890 "UDP protocol type."; 4891 } 4892 identity icmp { 4893 base protocol-type; 4894 description 4895 "icmp protocol type."; 4896 } 4897 identity icmp6 { 4898 base protocol-type; 4899 description 4900 "icmp v6 protocol type."; 4901 } 4902 identity gre { 4903 base protocol-type; 4904 description 4905 "GRE protocol type."; 4906 } 4907 identity ipip { 4908 base protocol-type; 4909 description 4910 "IPinIP protocol type."; 4911 } 4912 identity hop-by-hop { 4913 base protocol-type; 4914 description 4915 "Hop by Hop IPv6 header type."; 4916 } 4917 identity routing { 4918 base protocol-type; 4919 description 4920 "Routing IPv6 header type."; 4921 } 4922 identity esp { 4923 base protocol-type; 4924 description 4925 "ESP header type."; 4926 } 4927 identity ah { 4928 base protocol-type; 4929 description 4930 "AH header type."; 4931 } 4932 /* Groupings */ 4934 grouping vpn-service-cloud-access { 4935 container cloud-accesses { 4936 if-feature cloud-access; 4937 list cloud-access { 4939 key cloud-identifier; 4941 leaf cloud-identifier { 4942 type string; 4943 description 4944 "Identification of cloud service. Local 4945 admin meaning."; 4946 } 4947 choice list-flavor { 4948 case permit-any { 4949 leaf permit-any { 4950 type empty; 4951 description 4952 "Allow all sites."; 4953 } 4954 } 4955 case deny-any-except { 4956 leaf-list permit-site { 4957 type leafref { 4958 path "/l3vpn-svc/sites/site/site-id"; 4959 } 4960 description 4961 "Site ID to be authorized."; 4962 } 4963 } 4964 case permit-any-except { 4965 leaf-list deny-site { 4966 type leafref { 4967 path "/l3vpn-svc/sites/site/site-id"; 4968 } 4969 description 4970 "Site ID to be denied."; 4971 } 4972 } 4973 description 4974 "Choice for cloud access policy."; 4975 } 4976 container authorized-sites { 4977 list authorized-site { 4978 key site-id; 4980 leaf site-id { 4981 type leafref { 4982 path "/l3vpn-svc/sites/site/site-id"; 4983 } 4984 description 4985 "Site ID."; 4986 } 4987 description 4988 "List of authorized sites."; 4989 } 4990 description 4991 "Configuration of authorized sites"; 4992 } 4993 container denied-sites { 4994 list denied-site { 4995 key site-id; 4997 leaf site-id { 4998 type leafref { 4999 path "/l3vpn-svc/sites/site/site-id"; 5000 } 5001 description 5002 "Site ID."; 5003 } 5004 description 5005 "List of denied sites."; 5006 } 5007 description 5008 "Configuration of denied sites"; 5009 } 5010 container address-translation { 5011 container nat44 { 5012 leaf enabled { 5013 type boolean; 5014 default false; 5015 description 5016 "Control if 5017 address translation is required or not."; 5018 } 5019 leaf nat44-customer-address { 5020 type inet:ipv4-address; 5021 must "../enabled = 'true'" { 5022 description 5023 "Applicable only if 5024 address translation is enabled."; 5025 } 5026 description 5027 "Address to be used for translation. 5028 This is to be used in case customer is providing 5029 the address."; 5030 } 5031 description 5032 "IPv4 to IPv4 translation."; 5033 } 5034 description 5035 "Container for NAT"; 5036 } 5037 description 5038 "Cloud access configuration."; 5039 } 5040 description 5041 "Container for cloud access configurations"; 5042 } 5043 description 5044 "grouping for vpn cloud definition"; 5045 } 5047 grouping multicast-rp-group-cfg { 5048 choice group-format { 5049 case startend { 5050 leaf group-start { 5051 type inet:ip-address; 5052 description 5053 "First group address."; 5054 } 5055 leaf group-end { 5056 type inet:ip-address; 5057 description 5058 "Last group address."; 5059 } 5060 } 5061 case singleaddress { 5062 leaf group-address { 5063 type inet:ip-address; 5064 description 5065 "Group address"; 5066 } 5067 } 5068 description 5069 "Choice for group format."; 5070 } 5071 description 5072 "Definition of groups for 5073 RP to group mapping."; 5074 } 5076 grouping vpn-service-multicast { 5077 container multicast { 5078 if-feature multicast; 5079 leaf enabled { 5080 type boolean; 5081 default false; 5082 description 5083 "Enable multicast."; 5084 } 5085 container customer-tree-flavors { 5086 leaf-list tree-flavor { 5087 type identityref { 5088 base multicast-tree-type; 5089 } 5090 description 5091 "Type of tree to be used."; 5092 } 5093 description 5094 "Type of trees used by customer."; 5095 } 5096 container rp { 5097 container rp-group-mappings { 5098 list rp-group-mapping { 5099 key "id"; 5101 leaf id { 5102 type uint16; 5103 description 5104 "Unique identifier for the mapping."; 5105 } 5106 container provider-managed { 5107 leaf enabled { 5108 type boolean; 5109 default false; 5110 description 5111 "Set to true, if the RP must be a 5112 provider 5113 managed node. 5114 Set to false, if it is a customer 5115 managed node."; 5116 } 5117 leaf rp-redundancy { 5118 when "../enabled = 'true'" { 5119 description 5120 "Relevant when RP 5121 is provider managed."; 5122 } 5123 type boolean; 5124 default false; 5125 description 5126 "If true, redundancy 5127 mechanism for RP is required."; 5128 } 5129 leaf optimal-traffic-delivery { 5130 when "../enabled = 'true'" { 5131 description 5132 "Relevant when RP 5133 is provider managed."; 5134 } 5135 type boolean; 5136 default false; 5137 description 5138 "If true, SP must ensure 5139 that traffic uses an optimal path."; 5140 } 5141 description 5142 "Parameters for provider managed RP."; 5143 } 5145 leaf rp-address { 5146 when "../provider-managed/enabled = 'false'" { 5147 description 5148 "Relevant when RP 5149 is provider managed."; 5150 } 5151 type inet:ip-address; 5152 description 5153 "Defines the address of the 5154 RendezvousPoint. 5155 Used if RP is customer managed."; 5156 } 5158 container groups { 5159 list group { 5160 key id; 5162 leaf id { 5163 type uint16; 5164 description 5165 "Identifier for the group."; 5166 } 5167 uses multicast-rp-group-cfg; 5168 description 5169 "List of groups."; 5170 } 5171 description 5172 "Multicast groups associated with RP."; 5173 } 5175 description 5176 "List of RP to group mappings."; 5177 } 5178 description 5179 "RP to group mappings."; 5180 } 5181 container rp-discovery { 5182 leaf rp-discovery-type { 5183 type identityref { 5184 base multicast-rp-discovery-type; 5185 } 5186 default static-rp; 5187 description 5188 "Type of RP discovery used."; 5189 } 5190 container bsr-candidates { 5191 when "../rp-discovery-type = 'bsr-rp'" { 5192 description 5193 "Only applicable if discovery type 5194 is BSR-RP"; 5195 } 5196 leaf-list bsr-candidate-address { 5197 type inet:ip-address; 5198 description 5199 "Address of BSR candidate"; 5200 } 5201 description 5202 "Customer BSR candidates address"; 5203 } 5204 description 5205 "RP discovery parameters"; 5206 } 5208 description 5209 "RendezvousPoint parameters."; 5210 } 5211 description 5212 "Multicast global parameters for the VPN service."; 5213 } 5214 description 5215 "grouping for multicast vpn definition"; 5217 } 5219 grouping vpn-service-mpls { 5220 leaf carrierscarrier { 5221 if-feature carrierscarrier; 5222 type boolean; 5223 default false; 5224 description 5225 "The VPN is using Carrier's Carrier, 5226 and so MPLS is required."; 5227 } 5228 description 5229 "grouping for mpls CsC definition"; 5230 } 5232 grouping customer-location-info { 5233 container locations { 5234 list location { 5235 key location-id; 5237 leaf location-id { 5238 type svc-id; 5239 description 5240 "Identifier for a particular location"; 5241 } 5242 leaf address { 5243 type string; 5244 description 5245 "Address (number and street) 5246 of the site."; 5248 } 5249 leaf postal-code { 5250 type string; 5251 description 5252 "Postal code of the site."; 5253 } 5254 leaf state { 5255 type string; 5256 description 5257 "State of the site. 5258 This leaf can also be used 5259 to describe a region 5260 for country who does not have 5261 states. 5262 "; 5263 } 5264 leaf city { 5265 type string; 5266 description 5267 "City of the site."; 5268 } 5269 leaf country-code { 5270 type string { 5271 pattern '[A-Z]{2}'; 5272 } 5273 description 5274 "Country of the site. 5275 Expressed as ISO 5276 ALPHA-2 code."; 5277 } 5278 description 5279 "Location of the site."; 5280 } 5281 description 5282 "List of locations for the site"; 5283 } 5284 description 5285 "This grouping defines customer location 5286 parameters"; 5287 } 5289 grouping site-group { 5290 container groups { 5291 list group { 5292 key group-id; 5294 leaf group-id { 5295 type string; 5296 description 5297 "Group-id the site 5298 is belonging to"; 5299 } 5300 description 5301 "List of group-id"; 5302 } 5303 description 5304 "Groups the site or site-network-access 5305 is belonging to."; 5306 } 5307 description 5308 "Grouping definition to assign 5309 group-ids to site or site-network-access"; 5310 } 5311 grouping site-diversity { 5312 container site-diversity { 5313 if-feature site-diversity; 5315 uses site-group; 5317 description 5318 "Diversity constraint type. 5319 Group values defined here will be inherited 5320 to all site-network-accesses."; 5321 } 5322 description 5323 "This grouping defines site diversity 5324 parameters"; 5325 } 5326 grouping access-diversity { 5327 container access-diversity { 5328 if-feature site-diversity; 5329 uses site-group; 5331 container constraints { 5332 list constraint { 5333 key constraint-type; 5335 leaf constraint-type { 5336 type identityref { 5337 base placement-diversity; 5338 } 5339 description 5340 "Diversity constraint type."; 5341 } 5342 container target { 5343 choice target-flavor { 5344 case id { 5345 list group { 5346 key group-id; 5348 leaf group-id { 5349 type string; 5350 description 5351 "The constraint will apply 5352 against this particular 5353 group-id"; 5354 } 5355 description 5356 "List of groups"; 5357 } 5358 } 5359 case all-accesses { 5360 leaf all-other-accesses { 5361 type empty; 5362 description 5363 "The constraint will apply 5364 against all other site network 5365 access 5366 of this site"; 5367 } 5368 } 5369 case all-groups { 5370 leaf all-other-groups { 5371 type empty; 5372 description 5373 "The constraint will apply 5374 against all other groups the 5375 customer 5376 is managing"; 5377 } 5378 } 5379 description 5380 "Choice for the group definition"; 5381 } 5382 description 5383 "The constraint will apply against 5384 this list of groups"; 5385 } 5386 description 5387 "List of constraints"; 5388 } 5389 description 5390 "Constraints for placing this site 5391 network access"; 5392 } 5394 description 5395 "Diversity parameters."; 5396 } 5397 description 5398 "This grouping defines access diversity 5399 parameters"; 5400 } 5402 grouping operational-requirements { 5403 leaf requested-site-start { 5404 type yang:date-and-time; 5405 description 5406 "Optional leaf indicating requested date 5407 and time 5408 when the service at a particular site is 5409 expected 5410 to start"; 5411 } 5413 leaf requested-site-stop { 5414 type yang:date-and-time; 5415 description 5416 "Optional leaf indicating requested date 5417 and time 5418 when the service at a particular site is 5419 expected 5420 to stop"; 5421 } 5422 description 5423 "This grouping defines some operational parameters 5424 parameters"; 5425 } 5426 grouping operational-requirements-ops { 5427 leaf actual-site-start { 5428 type yang:date-and-time; 5429 config false; 5430 description 5431 "Optional leaf indicating actual date 5432 and time 5433 when the service at a particular site 5434 actually 5435 started"; 5436 } 5437 leaf actual-site-stop { 5438 type yang:date-and-time; 5439 config false; 5440 description 5441 "Optional leaf indicating actual date 5442 and time 5443 when the service at a particular site 5444 actually 5445 stopped"; 5446 } 5447 description 5448 "This grouping defines some operational parameters 5449 parameters"; 5450 } 5452 grouping flow-definition { 5453 container match-flow { 5454 leaf dscp { 5455 type inet:dscp; 5456 description 5457 "DSCP value."; 5458 } 5459 leaf dot1p { 5460 type uint8 { 5461 range "0 .. 7"; 5462 } 5463 description 5464 "802.1p matching."; 5465 } 5466 leaf ipv4-src-prefix { 5467 type inet:ipv4-prefix; 5468 description 5469 "Match on IPv4 src address."; 5470 } 5471 leaf ipv6-src-prefix { 5472 type inet:ipv6-prefix; 5473 description 5474 "Match on IPv6 src address."; 5475 } 5476 leaf ipv4-dst-prefix { 5477 type inet:ipv4-prefix; 5478 description 5479 "Match on IPv4 dst address."; 5480 } 5481 leaf ipv6-dst-prefix { 5482 type inet:ipv6-prefix; 5483 description 5484 "Match on IPv6 dst address."; 5485 } 5486 leaf l4-src-port { 5487 type inet:port-number; 5488 description 5489 "Match on layer 4 src port."; 5490 } 5491 leaf-list target-sites { 5492 type svc-id; 5493 description 5494 "Identify a site as traffic destination."; 5495 } 5496 container l4-src-port-range { 5497 leaf lower-port { 5498 type inet:port-number; 5499 description 5500 "Lower boundary for port."; 5501 } 5502 leaf upper-port { 5503 type inet:port-number; 5504 must ". >= ../lower-port" { 5505 description 5506 "Upper boundary must be higher 5507 than lower boundary"; 5508 } 5509 description 5510 "Upper boundary for port."; 5511 } 5512 description 5513 "Match on layer 4 src port range."; 5514 } 5515 leaf l4-dst-port { 5516 type inet:port-number; 5517 description 5518 "Match on layer 4 dst port."; 5519 } 5520 container l4-dst-port-range { 5521 leaf lower-port { 5522 type inet:port-number; 5523 description 5524 "Lower boundary for port."; 5525 } 5526 leaf upper-port { 5527 type inet:port-number; 5528 must ". >= ../lower-port" { 5529 description 5530 "Upper boundary must be higher 5531 than lower boundary"; 5532 } 5533 description 5534 "Upper boundary for port."; 5535 } 5536 description 5537 "Match on layer 4 dst port range."; 5538 } 5539 leaf protocol-field { 5540 type union { 5541 type uint8; 5542 type identityref { 5543 base protocol-type; 5544 } 5545 } 5546 description 5547 "Match on IPv4 protocol or 5548 Ipv6 Next Header 5549 field."; 5550 } 5551 description 5552 "Describe flow matching 5553 criterions."; 5554 } 5555 description 5556 "Flow definition based on criteria."; 5557 } 5558 grouping site-service-basic { 5559 leaf svc-input-bandwidth { 5560 type uint32; 5561 units bps; 5562 description 5563 "From the PE perspective, the service input 5564 bandwidth of the connection."; 5565 } 5566 leaf svc-output-bandwidth { 5567 type uint32; 5568 units bps; 5569 description 5570 "From the PE perspective, the service output 5571 bandwidth of the connection."; 5572 } 5573 leaf svc-mtu { 5574 type uint16; 5575 units bytes; 5576 description 5577 "MTU at service level. 5578 If the service is IP, 5579 it refers to the IP MTU."; 5580 } 5581 description 5582 "Defines basic service parameters for a site."; 5583 } 5584 grouping site-protection { 5585 container traffic-protection { 5586 if-feature fast-reroute; 5587 leaf enabled { 5588 type boolean; 5589 default false; 5590 description 5591 "Enables 5592 traffic protection of access link."; 5593 } 5594 description 5595 "Fast reroute service parameters 5596 for the site."; 5597 } 5598 description 5599 "Defines protection service parameters for a site."; 5600 } 5601 grouping site-service-mpls { 5602 container carrierscarrier { 5603 if-feature carrierscarrier; 5604 leaf signalling-type { 5605 type enumeration { 5606 enum "ldp" { 5607 description 5608 "Use LDP as signalling 5609 protocol between PE and CE."; 5610 } 5611 enum "bgp" { 5612 description 5613 "Use BGP 3107 as signalling 5614 protocol between PE and CE. 5615 In this case, bgp must be also 5616 configured 5617 as routing-protocol. 5618 "; 5619 } 5620 } 5621 description 5622 "MPLS signalling type."; 5623 } 5624 description 5625 "This container is used when customer provides 5626 MPLS based services. 5627 This is used in case of Carrier's 5628 Carrier."; 5629 } 5630 description 5631 "Defines MPLS service parameters for a site."; 5632 } 5633 grouping site-service-qos-profile { 5634 container qos { 5635 if-feature qos; 5636 container qos-classification-policy { 5637 list rule { 5638 key id; 5639 ordered-by user; 5641 leaf id { 5642 type uint16; 5643 description 5644 "ID of the rule."; 5645 } 5646 choice match-type { 5647 case match-flow { 5648 uses flow-definition; 5649 } 5650 case match-application { 5651 leaf match-application { 5652 type identityref { 5653 base customer-application; 5654 } 5655 description 5656 "Defines the application 5657 to match."; 5658 } 5659 } 5660 description 5661 "Choice for classification"; 5662 } 5664 leaf target-class-id { 5665 type string; 5666 description 5667 "Identification of the 5668 class of service. 5669 This identifier is internal to 5670 the administration."; 5671 } 5673 description 5674 "List of marking rules."; 5675 } 5676 description 5677 "Need to express marking rules ..."; 5678 } 5679 container qos-profile { 5681 choice qos-profile { 5682 description 5683 "Choice for QoS profile. 5684 Can be standard profile or custom."; 5685 case standard { 5686 leaf profile { 5687 type string; 5688 description 5689 "QoS profile to be used"; 5690 } 5691 } 5692 case custom { 5693 container classes { 5694 if-feature qos-custom; 5695 list class { 5696 key class-id; 5698 leaf class-id { 5699 type string; 5700 description 5701 "Identification of the 5702 class of service. 5703 This identifier is internal to 5704 the administration."; 5705 } 5706 leaf rate-limit { 5707 type uint8; 5708 units percent; 5709 description 5710 "To be used if class must 5711 be rate 5712 limited. Expressed as 5713 percentage of the svc-bw."; 5714 } 5715 container latency { 5716 choice flavor { 5717 case lowest { 5718 leaf use-lowest-latency { 5719 type empty; 5720 description 5721 "The traffic class should use 5722 the lowest latency path"; 5723 } 5724 } 5725 case boundary { 5726 leaf latency-boundary { 5727 type uint16; 5728 units msec; 5729 description 5730 "The traffic class should use 5731 a path with a defined maximum 5732 latency."; 5733 } 5734 } 5735 description 5736 "Latency constraint on the traffic 5737 class"; 5738 } 5739 description 5740 "Latency constraint on the traffic 5741 class"; 5743 } 5744 container jitter { 5745 choice flavor { 5746 case lowest { 5747 leaf use-lowest-jitter { 5748 type empty; 5749 description 5750 "The traffic class should use 5751 the lowest jitter path"; 5752 } 5753 } 5754 case boundary { 5755 leaf latency-boundary { 5756 type uint32; 5757 units usec; 5758 description 5759 "The traffic class should use 5760 a path with a defined maximum 5761 jitter."; 5762 } 5763 } 5764 description 5765 "Jitter constraint on the traffic 5766 class"; 5767 } 5768 description 5769 "Jitter constraint on the traffic 5770 class"; 5771 } 5772 container bandwidth { 5773 leaf guaranteed-bw-percent { 5774 type uint8; 5775 units percent; 5776 description 5777 "To be used to define the 5778 guaranteed 5779 BW in percent of the svc-bw 5780 available."; 5781 } 5782 leaf end-to-end { 5783 type empty; 5784 description 5785 "Used if the bandwidth reservation 5786 must be done on the MPLS network too"; 5787 } 5788 description 5789 "Bandwidth constraint on the traffic 5790 class"; 5792 } 5793 description 5794 "List of class of services."; 5795 } 5796 description 5797 "Container for 5798 list of class of services."; 5799 } 5801 } 5803 } 5804 description 5805 "Qos profile configuration."; 5806 } 5807 description 5808 "QoS configuration."; 5809 } 5810 description 5811 "This grouping defines QoS parameters 5812 for a site"; 5814 } 5816 grouping site-security-authentication { 5817 container authentication { 5818 description 5819 "Authentication parameters"; 5820 } 5821 description 5822 "This grouping defines authentication 5823 parameters 5824 for a site"; 5826 } 5827 grouping site-security-encryption { 5828 container encryption { 5829 if-feature encryption; 5830 leaf enabled { 5831 type boolean; 5832 default false; 5833 description 5834 "If true, access encryption is required."; 5835 } 5836 leaf layer { 5837 type enumeration { 5838 enum layer2 { 5839 description 5840 "Encryption will occur at layer 2."; 5841 } 5842 enum layer3 { 5843 description 5844 "Encryption will occur at layer 3. 5845 IPSec may be used as example."; 5846 } 5847 } 5848 mandatory true; 5849 description 5850 "Layer on which encryption is applied."; 5851 } 5852 container encryption-profile { 5853 choice profile { 5854 case provider-profile { 5855 leaf profile-name { 5856 type string; 5857 description 5858 "Name of the SP profile 5859 to be applied."; 5860 } 5861 } 5862 case customer-profile { 5863 leaf algorithm { 5864 type string; 5865 description 5866 "Encryption algorithm to 5867 be used."; 5868 } 5869 choice key-type { 5870 case psk { 5871 leaf preshared-key { 5872 type string; 5873 description 5874 "Key coming from 5875 customer."; 5876 } 5877 } 5878 case pki { 5880 } 5881 description 5882 "Type of keys to be used."; 5883 } 5884 } 5885 description 5886 "Choice of profile."; 5887 } 5888 description 5889 "Profile of encryption to be applied."; 5890 } 5891 description 5892 "Encryption parameters."; 5893 } 5894 description 5895 "This grouping defines encryption parameters 5896 for a site"; 5897 } 5899 grouping site-attachment-bearer { 5900 container bearer { 5901 container requested-type { 5902 if-feature requested-type; 5903 leaf requested-type { 5904 type string; 5905 description 5906 "Type of requested bearer Ethernet, DSL, 5907 Wireless ... 5908 Operator specific."; 5909 } 5910 leaf strict { 5911 type boolean; 5912 default false; 5913 description 5914 "define if the requested-type is a preference 5915 or a strict requirement."; 5916 } 5917 description 5918 "Container for requested type."; 5919 } 5920 leaf always-on { 5921 if-feature always-on; 5922 type boolean; 5923 default true; 5924 description 5925 "Request for an always on access type. 5926 This means no Dial access type for 5927 example."; 5928 } 5929 leaf bearer-reference { 5930 if-feature bearer-reference; 5931 type string; 5932 description 5933 "This is an internal reference for the 5934 service provider. 5936 Used "; 5937 } 5938 description 5939 "Bearer specific parameters. 5940 To be augmented."; 5941 } 5942 description 5943 "Defines physical properties of 5944 a site attachment."; 5945 } 5947 grouping site-routing { 5948 container routing-protocols { 5949 list routing-protocol { 5950 key type; 5952 leaf type { 5953 type identityref { 5954 base routing-protocol-type; 5955 } 5956 description 5957 "Type of routing protocol."; 5958 } 5960 container ospf { 5961 when "../type = 'ospf'" { 5962 description 5963 "Only applies 5964 when protocol is OSPF."; 5965 } 5966 if-feature rtg-ospf; 5967 leaf-list address-family { 5968 type address-family; 5970 description 5971 "Address family to be activated."; 5972 } 5973 leaf area-address { 5974 type yang:dotted-quad; 5975 description 5976 "Area address."; 5977 } 5978 leaf metric { 5979 type uint16; 5980 description 5981 "Metric of PE-CE link."; 5982 } 5983 container sham-links { 5984 if-feature rtg-ospf-sham-link; 5985 list sham-link { 5986 key target-site; 5988 leaf target-site { 5989 type svc-id; 5990 description 5991 "Target site for the sham link 5992 connection. 5993 The site is referred through it's ID."; 5994 } 5995 leaf metric { 5996 type uint16; 5997 description 5998 "Metric of the sham link."; 5999 } 6000 description 6001 "Creates a shamlink with another 6002 site"; 6003 } 6004 description 6005 "List of Sham links"; 6006 } 6007 description 6008 "OSPF specific configuration."; 6009 } 6011 container bgp { 6013 when "../type = 'bgp'" { 6014 description 6015 "Only applies when 6016 protocol is BGP."; 6017 } 6018 if-feature rtg-bgp; 6019 leaf autonomous-system { 6020 type uint32; 6021 description 6022 "AS number."; 6023 } 6024 leaf-list address-family { 6025 type address-family; 6027 description 6028 "Address family to be activated."; 6029 } 6030 description 6031 "BGP specific configuration."; 6032 } 6033 container static { 6034 when "../type = 'static'" { 6035 description 6036 "Only applies when protocol 6037 is static."; 6038 } 6040 container cascaded-lan-prefixes { 6041 list ipv4-lan-prefixes { 6042 if-feature ipv4; 6043 key "lan next-hop"; 6045 leaf lan { 6046 type inet:ipv4-prefix; 6047 description 6048 "Lan prefixes."; 6049 } 6050 leaf lan-tag { 6051 type string; 6052 description 6053 "Internal tag to be used in vpn 6054 policies."; 6055 } 6056 leaf next-hop { 6057 type inet:ipv4-address; 6058 description 6059 "Nexthop address to use at customer 6060 side."; 6061 } 6062 description " 6063 List of LAN prefixes for 6064 the site. 6065 "; 6066 } 6067 list ipv6-lan-prefixes { 6068 if-feature ipv6; 6069 key "lan next-hop"; 6071 leaf lan { 6072 type inet:ipv6-prefix; 6073 description 6074 "Lan prefixes."; 6075 } 6076 leaf lan-tag { 6077 type string; 6078 description 6079 "Internal tag to be used 6080 in vpn policies."; 6081 } 6082 leaf next-hop { 6083 type inet:ipv6-address; 6084 description 6085 "Nexthop address to use at 6086 customer side."; 6087 } 6088 description " 6089 List of LAN prefixes for the site. 6090 "; 6091 } 6092 description 6093 "LAN prefixes from the customer."; 6094 } 6095 description 6096 "Static routing 6097 specific configuration."; 6098 } 6099 container rip { 6101 when "../type = 'rip'" { 6102 description 6103 "Only applies when 6104 protocol is RIP."; 6105 } 6106 if-feature rtg-rip; 6107 leaf-list address-family { 6108 type address-family; 6110 description 6111 "Address family to be 6112 activated."; 6113 } 6115 description 6116 "RIP routing specific 6117 configuration."; 6118 } 6120 container vrrp { 6122 when "../type = 'vrrp'" { 6123 description 6124 "Only applies when 6125 protocol is VRRP."; 6127 } 6128 if-feature rtg-vrrp; 6129 leaf-list address-family { 6130 type address-family; 6132 description 6133 "Address family to be activated."; 6134 } 6135 description 6136 "VRRP routing specific configuration."; 6137 } 6139 description 6140 "List of routing protocols used 6141 on the site. 6142 Need to be augmented."; 6143 } 6144 description 6145 "Defines routing protocols."; 6146 } 6147 description 6148 "Grouping for routing protocols."; 6149 } 6151 grouping site-attachment-ip-connection { 6152 container ip-connection { 6153 container ipv4 { 6154 if-feature ipv4; 6155 leaf address-allocation-type { 6156 type identityref { 6157 base address-allocation-type; 6158 } 6159 default "static-address"; 6160 description 6161 "Defines how addresses are allocated. 6162 "; 6163 } 6165 leaf number-of-dynamic-address { 6166 when 6167 "../address-allocation-type = 'provider-dhcp'" 6168 { 6169 description 6170 "Only applies when 6171 addresses are dhcp allocated"; 6172 } 6173 type uint8; 6174 default 1; 6175 description 6176 "Describes the number of IP addresses the 6177 customer requires"; 6178 } 6179 container dhcp-relay { 6180 when 6181 "../address-allocation-type = 'provider-dhcp-relay'" 6182 { 6183 description 6184 "Only applies when 6185 provider is required to implementations 6186 DHCP relay function"; 6187 } 6188 container customer-dhcp-servers { 6189 leaf-list server-ip-address { 6190 type inet:ipv4-address; 6191 description 6192 "IP address of customer DHCP server"; 6193 } 6194 description 6195 "Container for list of customer DHCP server"; 6196 } 6197 description 6198 "DHCP relay provided by operator."; 6199 } 6200 container addresses { 6201 when 6202 "../address-allocation-type = 'static-address'" { 6203 description 6204 "Only applies when 6205 protocol allocation type is static"; 6206 } 6207 leaf provider-address { 6208 type inet:ipv4-address; 6209 description 6210 "Provider side address."; 6211 } 6212 leaf customer-address { 6213 type inet:ipv4-address; 6214 description 6215 "Customer side address."; 6216 } 6217 leaf mask { 6218 type uint8 { 6219 range "0..31"; 6220 } 6221 description 6222 "Subnet mask expressed 6223 in bits"; 6224 } 6225 description 6226 "Describes IP addresses used"; 6227 } 6229 description 6230 "IPv4 specific parameters"; 6232 } 6233 container ipv6 { 6234 if-feature ipv6; 6235 leaf address-allocation-type { 6236 type identityref { 6237 base address-allocation-type; 6238 } 6239 default "static-address"; 6240 description 6241 "Defines how addresses are allocated. 6242 "; 6243 } 6244 leaf number-of-dynamic-address { 6245 when 6246 "../address-allocation-type = 'provider-dhcp' "+ 6247 "or ../address-allocation-type "+ 6248 "= 'provider-dhcp-slaac'" { 6249 description 6250 "Only applies when 6251 addresses are dhcp allocated"; 6252 } 6253 type uint8; 6254 default 1; 6255 description 6256 "Describes the number of IP addresses the 6257 customer requires"; 6258 } 6259 container dhcp-relay { 6260 when 6261 "../address-allocation-type = 'provider-dhcp-relay'" 6262 { 6263 description 6264 "Only applies when 6265 provider is required to implementations 6266 DHCP relay function"; 6267 } 6268 container customer-dhcp-servers { 6269 leaf-list server-ip-address { 6270 type inet:ipv6-address; 6271 description 6272 "IP address of customer DHCP server"; 6273 } 6274 description 6275 "Container for list of customer DHCP server"; 6276 } 6277 description 6278 "DHCP relay provided by operator."; 6279 } 6280 container addresses { 6281 when 6282 "../address-allocation-type = 'static-address'" { 6283 description 6284 "Only applies when 6285 protocol allocation type is static"; 6286 } 6287 leaf provider-address { 6288 type inet:ipv6-address; 6289 description 6290 "Provider side address."; 6291 } 6292 leaf customer-address { 6293 type inet:ipv6-address; 6294 description 6295 "Customer side address."; 6296 } 6297 leaf mask { 6298 type uint8 { 6299 range "0..127"; 6300 } 6301 description 6302 "Subnet mask expressed 6303 in bits"; 6304 } 6305 description 6306 "Describes IP addresses used"; 6307 } 6309 description 6310 "IPv6 specific parameters"; 6312 } 6313 container oam { 6314 container bfd { 6315 if-feature bfd; 6316 leaf enabled { 6317 type boolean; 6318 default false; 6319 description 6320 "BFD activation"; 6321 } 6323 choice holdtime { 6324 case profile { 6325 leaf profile-name { 6326 type string; 6327 description 6328 "Service provider well 6329 known profile."; 6330 } 6331 description 6332 "Service provider well 6333 known profile."; 6334 } 6335 case fixed { 6336 leaf fixed-value { 6337 type uint32; 6338 units msec; 6339 description 6340 "Expected holdtime 6341 expressed 6342 in msec."; 6343 } 6344 } 6345 description 6346 "Choice for holdtime flavor."; 6347 } 6348 description 6349 "Container for BFD."; 6350 } 6351 description 6352 "Define the OAM used on the connection."; 6353 } 6354 description 6355 "Defines connection parameters."; 6356 } 6357 description 6358 "This grouping defines IP connection parameters."; 6359 } 6361 grouping site-service-multicast { 6362 container multicast { 6363 if-feature multicast; 6364 leaf multicast-site-type { 6365 type enumeration { 6366 enum receiver-only { 6367 description 6368 "The site has only receivers."; 6369 } 6370 enum source-only { 6371 description 6372 "The site has only sources."; 6373 } 6374 enum source-receiver { 6375 description 6376 "The site has both 6377 sources & receivers."; 6378 } 6379 } 6380 default "source-receiver"; 6381 description 6382 "Type of multicast site."; 6383 } 6384 container multicast-address-family { 6385 leaf ipv4 { 6386 if-feature ipv4; 6387 type boolean; 6388 default true; 6389 description 6390 "Enables ipv4 multicast"; 6391 } 6392 leaf ipv6 { 6393 if-feature ipv6; 6394 type boolean; 6395 default false; 6396 description 6397 "Enables ipv6 multicast"; 6398 } 6399 description 6400 "Defines protocol to carry multicast."; 6401 } 6402 leaf protocol-type { 6403 type enumeration { 6404 enum host { 6405 description 6406 " 6407 Hosts are directly connected 6408 to the provider network. 6409 Host protocols like IGMP, MLD 6410 are required. 6411 "; 6412 } 6413 enum router { 6414 description 6415 " 6416 Hosts are behind a customer router. 6417 PIM will be implemented. 6418 "; 6419 } 6420 enum both { 6421 description 6422 "Some Hosts are behind a customer 6423 router and some others are directly 6424 connected to the provider network. 6425 Both host and routing protocols must be 6426 used. Typically IGMP and PIM will be 6427 implemented. 6428 "; 6429 } 6430 } 6431 default "both"; 6432 description 6433 "Multicast protocol type to be used 6434 with the customer site."; 6435 } 6437 description 6438 "Multicast parameters for the site."; 6439 } 6440 description 6441 "Multicast parameters for the site."; 6442 } 6444 grouping site-management { 6445 container management { 6446 leaf type { 6447 type identityref { 6448 base management; 6449 } 6450 description 6451 "Management type of the connection."; 6452 } 6453 description 6454 "Management configuration"; 6455 } 6456 description 6457 "Management parameters for the site."; 6458 } 6460 grouping site-devices { 6461 container devices { 6462 must "/l3vpn-svc/sites/site/management/type = "+ 6463 "'provider-managed' or "+ 6464 "/l3vpn-svc/sites/site/management/type ="+ 6465 "'co-managed'" { 6466 description 6467 "Applicable only for provider-managed or 6468 co-managed device"; 6469 } 6470 list device { 6471 key device-id; 6473 leaf device-id { 6474 type svc-id; 6475 description 6476 "identifier for the device"; 6477 } 6478 leaf location { 6479 type leafref { 6480 path "/l3vpn-svc/sites/site/locations/"+ 6481 "location/location-id"; 6482 } 6483 description 6484 "Location of the device"; 6485 } 6486 container management { 6487 must "/l3vpn-svc/sites/site/management/type"+ 6488 "= 'co-managed'" { 6489 description 6490 "Applicable only for 6491 co-managed device"; 6492 } 6493 leaf address-family { 6494 type address-family; 6496 description 6497 "Address family used for management."; 6498 } 6499 leaf address { 6500 type inet:ip-address; 6501 description 6502 "Management address"; 6503 } 6504 description 6505 "Management configuration. Only for 6506 co-managed case."; 6507 } 6508 description 6509 "Device configuration"; 6510 } 6511 description 6512 "List of devices requested by customer"; 6513 } 6514 description 6515 "Grouping for device allocation"; 6516 } 6517 grouping site-vpn-flavor { 6518 leaf site-vpn-flavor { 6519 type identityref { 6520 base site-vpn-flavor; 6521 } 6522 default site-vpn-flavor-single; 6523 description 6524 "Defines if the site 6525 is a single VPN site, or multiVPN or ..."; 6526 } 6527 description 6528 "Grouping for site-vpn-flavor."; 6529 } 6531 grouping site-vpn-policy { 6532 container vpn-policies { 6533 list vpn-policy { 6534 key vpn-policy-id; 6536 leaf vpn-policy-id { 6537 type svc-id; 6538 description 6539 "Unique identifier for 6540 the VPN policy."; 6541 } 6543 list entries { 6544 key id; 6546 leaf id { 6547 type svc-id; 6548 description 6549 "Unique identifier for 6550 the policy entry."; 6551 } 6552 container filter { 6553 choice lan { 6554 case prefixes { 6555 leaf-list ipv4-lan-prefix { 6556 if-feature ipv4; 6557 type inet:ipv4-prefix; 6558 description 6559 "List of IPv4 prefixes to be 6560 matched."; 6561 } 6562 leaf-list ipv6-lan-prefix { 6563 if-feature ipv6; 6564 type inet:ipv6-prefix; 6565 description 6566 "List of IPv6 prefixes to be 6567 matched."; 6568 } 6569 } 6570 case lan-tag { 6571 leaf-list lan-tag { 6572 type string; 6573 description 6574 "List of lan-tags to be matched."; 6575 } 6576 } 6577 description 6578 "Choice for LAN matching type"; 6579 } 6580 description 6581 "If used, it permit to split site LANs 6582 among multiple VPNs. 6583 If no filter used, all the LANs will be 6584 part of the same VPNs with the same 6585 role."; 6586 } 6587 container vpn { 6588 leaf vpn-id { 6589 type leafref { 6590 path "/l3vpn-svc/vpn-services/" 6591 +"vpn-service/vpn-id"; 6592 } 6593 mandatory true; 6594 description 6595 "Reference to an IPVPN."; 6596 } 6597 leaf site-role { 6598 type identityref { 6599 base site-role; 6600 } 6601 default any-to-any-role; 6602 description 6603 "Role of the site in the IPVPN."; 6604 } 6605 description 6606 "List of VPNs the LAN is associated to."; 6607 } 6608 description 6609 "List of entries for export policy."; 6610 } 6611 description 6612 "List of VPN policies."; 6613 } 6614 description 6615 "VPN policy."; 6616 } 6617 description 6618 "VPN policy parameters for the site."; 6619 } 6621 grouping site-maximum-routes { 6622 container maximum-routes { 6623 list address-family { 6624 key af; 6626 leaf af { 6627 type address-family; 6629 description 6630 "Address-family."; 6631 } 6632 leaf maximum-routes { 6633 type uint32; 6634 description 6635 "Maximum prefixes the VRF can 6636 accept for this 6637 address-family."; 6638 } 6639 description 6640 "List of address families."; 6641 } 6643 description 6644 "Define maximum-routes for the VRF."; 6645 } 6646 description 6647 "Define maximum-routes for the site."; 6648 } 6650 grouping site-security { 6651 container security { 6652 uses site-security-authentication; 6653 uses site-security-encryption; 6655 description 6656 "Site specific security parameters."; 6657 } 6658 description 6659 "Grouping for security parameters."; 6660 } 6662 grouping site-service { 6663 container service { 6664 uses site-service-qos-profile; 6665 uses site-service-mpls; 6666 uses site-service-multicast; 6668 description 6669 "Service parameters on the attachement."; 6670 } 6671 description 6672 "Grouping for service parameters."; 6673 } 6675 grouping site-network-access-service { 6676 container service { 6677 uses site-service-basic; 6678 uses site-service-qos-profile; 6679 uses site-service-mpls; 6680 uses site-service-multicast; 6682 description 6683 "Service parameters on the attachement."; 6684 } 6685 description 6686 "Grouping for service parameters."; 6687 } 6689 grouping vpn-extranet { 6690 container extranet-vpns { 6691 if-feature extranet-vpn; 6692 list extranet-vpn { 6693 key vpn-id; 6695 leaf vpn-id { 6696 type svc-id; 6697 description 6698 "Identifies the target VPN"; 6700 } 6701 leaf local-sites-role { 6702 type identityref { 6703 base site-role; 6705 } 6706 default any-to-any-role; 6707 description 6708 "This describes the role of the 6709 local sites in the target VPN topology."; 6710 } 6711 description 6712 "List of extranet VPNs the local 6713 VPN is attached to."; 6714 } 6715 description 6716 "Container for extranet vpn cfg."; 6717 } 6718 description 6719 "grouping for extranet VPN configuration. 6720 Extranet provides a way to interconnect all sites 6721 from two VPNs in a easy way."; 6723 } 6725 grouping site-attachment-availability { 6726 container availability { 6727 leaf access-priority { 6728 type uint32; 6729 default 1; 6730 description 6731 "Defines the priority for the access. 6732 The highest the priority value is, 6733 the highest the 6734 preference of the access is."; 6735 } 6736 description 6737 "Availability parameters 6738 (used for multihoming)"; 6739 } 6740 description 6741 "Defines site availability parameters."; 6742 } 6744 grouping access-vpn-policy { 6745 container vpn-attachment { 6747 choice attachment-flavor { 6748 case vpn-policy-id { 6749 leaf vpn-policy-id { 6750 type leafref { 6751 path "/l3vpn-svc/sites/site/"+ 6752 "vpn-policies/vpn-policy/"+ 6753 "vpn-policy-id"; 6754 } 6755 description 6756 "Reference to a VPN policy."; 6757 } 6758 } 6759 case vpn-id { 6760 leaf vpn-id { 6761 type leafref { 6762 path "/l3vpn-svc/vpn-services"+ 6763 "/vpn-service/vpn-id"; 6764 } 6765 description 6766 "Reference to a VPN."; 6767 } 6768 leaf site-role { 6769 type identityref { 6770 base site-role; 6771 } 6772 default any-to-any-role; 6773 description 6774 "Role of the site in the IPVPN."; 6775 } 6776 } 6777 mandatory true; 6778 description 6779 "Choice for VPN attachment flavor."; 6780 } 6781 description 6782 "Defines VPN attachment of a site."; 6783 } 6784 description 6785 "Defines the VPN attachment rules 6786 for a site logical access."; 6787 } 6789 grouping vpn-svc-cfg { 6790 leaf vpn-id { 6791 type svc-id; 6792 description 6793 "VPN identifier. Local administration meaning."; 6794 } 6795 leaf customer-name { 6796 type string; 6797 description 6798 "Name of the customer."; 6799 } 6800 leaf vpn-service-topology { 6801 type identityref { 6802 base vpn-topology; 6803 } 6804 default "any-to-any"; 6805 description 6806 "VPN service topology."; 6807 } 6809 uses vpn-service-cloud-access; 6810 uses vpn-service-multicast; 6811 uses vpn-service-mpls; 6812 uses vpn-extranet; 6814 description 6815 "grouping for vpn-svc configuration."; 6816 } 6818 grouping site-top-level-cfg { 6819 uses operational-requirements; 6820 uses customer-location-info; 6821 uses site-devices; 6822 uses site-diversity; 6823 uses site-management; 6824 uses site-vpn-policy; 6825 uses site-vpn-flavor; 6826 uses site-maximum-routes; 6827 uses site-security; 6828 uses site-service; 6829 uses site-protection; 6830 uses site-routing; 6832 description 6833 "Grouping for site top level cfg."; 6834 } 6835 grouping site-network-access-top-level-cfg { 6836 leaf site-network-access-type { 6837 type identityref { 6838 base site-network-access-type; 6839 } 6840 default "point-to-point"; 6841 description 6842 "Describes the type of connection, e.g. : 6843 point-to-point or multipoint"; 6845 } 6847 choice location-flavor { 6848 case location { 6849 when "/l3vpn-svc/sites/site/management/type = "+ 6850 "'customer-managed'" { 6851 description 6852 "Applicable only for customer-managed"; 6853 } 6854 leaf location-reference { 6855 type leafref { 6856 path "/l3vpn-svc/sites/site/locations/"+ 6857 "location/location-id"; 6858 } 6859 description 6860 "Location of the site-network-access"; 6861 } 6862 } 6863 case device { 6864 when "/l3vpn-svc/sites/site/management/type = "+ 6865 "'provider-managed' or "+ 6866 "/l3vpn-svc/sites/site/management/type = "+ 6867 "'co-managed'" { 6868 description 6869 "Applicable only for provider-managed or 6870 co-managed device"; 6871 } 6872 leaf device-reference { 6873 type leafref { 6874 path "/l3vpn-svc/sites/site/devices/"+ 6875 "device/device-id"; 6876 } 6877 description 6878 "Identifier of CE to use"; 6879 } 6880 } 6881 mandatory true; 6882 description 6883 "Choice on how to describe the site location"; 6884 } 6886 uses access-diversity; 6887 uses site-attachment-bearer; 6888 uses site-attachment-ip-connection; 6889 uses site-security; 6890 uses site-network-access-service; 6891 uses site-routing; 6892 uses site-attachment-availability; 6893 uses access-vpn-policy; 6895 description 6896 "Grouping for site network access 6897 top level cfg."; 6898 } 6900 /* Main blocks */ 6902 container l3vpn-svc { 6903 container vpn-services { 6904 list vpn-service { 6905 key vpn-id; 6907 uses vpn-svc-cfg; 6909 description " 6910 List of VPN services. 6911 "; 6912 } 6913 description 6914 "top level container 6915 for the VPN services."; 6916 } 6918 container sites { 6919 list site { 6920 key site-id; 6922 leaf site-id { 6923 type svc-id; 6924 description 6925 "Identifier of the site."; 6926 } 6928 uses site-top-level-cfg; 6929 uses operational-requirements-ops; 6931 container site-network-accesses { 6932 list site-network-access { 6933 key site-network-access-id; 6935 leaf site-network-access-id { 6936 type svc-id; 6937 description 6938 "Identifier for the access"; 6939 } 6940 uses site-network-access-top-level-cfg; 6941 description 6942 "List of accesses for a site."; 6943 } 6944 description 6945 "List of accesses for a site."; 6946 } 6948 description "List of sites."; 6949 } 6950 description 6951 "Container for sites"; 6952 } 6954 description 6955 "Main container for L3VPN service configuration."; 6956 } 6958 } 6959 6961 10. Security Considerations 6963 The YANG modules defined in this document MAY be accessed via the 6964 RESTCONF protocol [I-D.ietf-netconf-restconf] or NETCONF protocol 6965 ([RFC6241]. The lowest RESTCONF or NETCONF layer requires that the 6966 transport-layer protocol provides both data integrity and 6967 confidentiality, see Section 2 in [I-D.ietf-netconf-restconf] and 6968 [RFC6241]. The client MUST carefully examine the certificate 6969 presented by the server to determine if it meets the client's 6970 expectations, and the server MUST authenticate client access to any 6971 protected resource. The client identity derived from the 6972 authentication mechanism used is subject to the NETCONF Access 6973 Control Module (NACM) ([RFC6536]). Other protocols to access this 6974 YANG module are also required to support the similar mechanism. 6976 The data nodes defined in the "ietf-l3vpn-svc" YANG module MUST be 6977 carefully created/read/updated/deleted. The entries in the lists 6978 below include customer proprietary or confidential information, 6979 therefore only authorized clients MUST access the information and the 6980 other clients MUST NOT be able to access the information. 6982 o /l3vpn-svc/vpn-services/vpn-service 6984 o /l3vpn-svc/sites/site 6985 The data model proposes some security parameters than can be extended 6986 by augmentation as part of the customer service request: those 6987 parameters are described in Section 6.9. 6989 11. Contribution 6991 Authors would like to thank Rob Shakir for his major contribution on 6992 the initial modeling and use cases. 6994 12. Acknowledgements 6996 Thanks to Qin Wu, Maxim Klyus, Luis Miguel Contreras, Gregory Mirsky, 6997 Zitao Wang, Jing Zhao, Kireeti Kompella, Eric Rosen, Aijun Wang, 6998 Michael Scharf, Xufeng Liu, David Ball, Lucy Yong, Jean-Philippe 6999 Landry and Andrew Leu for the contributions to the document. 7001 13. IANA Considerations 7003 IANA is requested to assign a new URI from the IETF XML registry 7004 ([RFC3688]). Authors are suggesting the following URI: 7006 ID: yang:ietf-l3vpn-svc 7007 URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc 7008 Filename: [ TBD-at-registration ] 7009 Reference: [ RFC-to-be ] 7010 Registrant Contact: L3SM WG 7011 XML: N/A, the requested URI is an XML namespace 7013 This document also requests a new YANG module name in the YANG Module 7014 Names registry ([RFC7950]) with the following suggestion: 7016 Name: ietf-l3vpn-svc 7017 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc 7018 Prefix: l3vpn-svc 7019 Module: 7020 Reference: [ RFC-to-be ] 7022 14. Change Log 7024 14.1. Changes between versions -18 and-19 7026 o Country code string pattern enforced to ISO ALPHA-2 code. 7028 o zip-code renamed to postal-code. 7030 o Added new address-allocation-type: provider-dhcp-slaac. 7032 o Removed transport-constraints and include transport constraints 7033 (jitter,latency, bandwidth) in the qos-profile. 7035 o qos-profile simplified with more abstraction. 7037 o added target-sites in flow-definition. 7039 14.2. Changes between versions -17 and-18 7041 o Removed TOS from flow matching. 7043 14.3. Changes between versions -16 and-17 7045 o Renamed "vpn-svc" list to "vpn-service". 7047 o Renamed "vpn-policy-list" to "vpn-policies". 7049 o Renamed "management-transport" to "address-family". 7051 o Renamed "multicast-transport" to "address-family". 7053 o Modified cloud access policy using a choice. 7055 o any-to-any-role as default site-role. 7057 o "address-family" is now an enumeration instead of identity. 7059 o cloud-access feature moved to container level. 7061 o Added "address-translation" container for cloud-access. 7063 o Renamed "customer-nat-address" to "customer-address". 7065 o New type ip:address for "customer-address". 7067 o "tree-flavor" moved to leaf-list. 7069 o "bsr-candidate" list moved to "bsr-candidate-address" leaf-list. 7071 o layer becomes mandatory in security-encryption. 7073 o ip-subnet mask range modified. 7075 o multicast transport constraint destination moved to leaf-list. 7077 o lan-prefixes in vpn-policy moved to leaf-list ang tag has been 7078 renamed "prefixes". 7080 o Added source and destination port range in QoS classification. 7082 o QoS classification uses more existing inet:types. 7084 o Grouping defined for site group list. 7086 14.4. Changes between versions -15 and-16 7088 o Rename "topology" leaf to "vpn-service-topology". 7090 14.5. Changes between versions -13 and-14 7092 o Choice between device reference and location reference. 7094 14.6. Changes between versions -12 and-13 7096 o Removed rip-ng identity (rip container has AF information) 7098 o renamed pe-dhcp to provider-dhcp 7100 o add provider-dhcp-relay identity and container 7102 o BW/MTU is now only under site-network-access 7104 o Add list of location and location ID 7106 o Site-network-access mapped to location Identifier 7108 o Add list of devices (provided by operator) requested by customer 7110 o Some management parameters moved under device list 7112 o Site-network-access mapped to device identifier 7114 14.7. Changes between versions -11 and-12 7116 o Fixing some 'when' statements that prevented compilation. 7118 14.8. Changes between versions -09 and-10 7120 o Removed templates. 7122 o Add site-network-access-type. 7124 o Add a leaf number-of-dynamic-address in case of pe-dhcp 7125 addressing. 7127 14.9. Changes between versions -08 and-09 7129 o Add site-vpn-flavor NNI. 7131 14.10. Changes between versions -07 and-08 7133 o Traffic protection moved to site level. 7135 o Decouple operational-requirements in two containers. 7137 14.11. Changes between versions -06 and-07 7139 o Set config false to actual-site-start and stop. 7141 o Add a container before cloud-access list. 7143 o Add a container before authorized-sites list. 7145 o Add a container before denied-sites list. 7147 o Modified access-diversity modeling. 7149 o Replacing type placement diversity by an identity. 7151 14.12. Changes between versions -05 and-06 7153 o Added linecard diverse for site diversity 7155 o Added a new diversity enum in placement-diversity: none 7157 o Added state to site location 7159 o remove reference to core routing model: created new address family 7160 identities 7162 o added features 7164 o Modified bearer parameters 7166 o Modified union for ipv4/ipv6 addresses to ip-address type 7168 o Add BSR parameters for multicast 7170 o Add applications matching for QoS classification 7172 14.13. Changes between versions -04 and-05 7174 o Modify VPN policy and creating a vpn-policy-list 7176 o Add VPN policy reference and VPN ID reference under site-network- 7177 access 7179 14.14. Changes between versions -02 and-03 7181 o Add extranet-vpn container in vpn-svc 7183 o Creating top level containers 7185 o Refine groupings 7187 o Added site-vpn-flavor 7189 o qos-profile moved to choice 7191 o vpn leaf moved to vpn-id in vpn-policy 7193 o added ordered-by user to qos classification list 7195 o moved traffic protection to access availability 7197 o creating a choice in matching filter for VPN policy 7199 o added dot1p matching field in flow-definition 7201 14.15. Changes between versions -01 and-02 7203 o A site is now a collection of site-accesses. This was introduced 7204 to support M to N availability. 7206 o Site-availability has been removed, replaced by availability 7207 parameters under site-accesses 7209 o Added transport-constraints within vpn-svc 7211 o Add ToS support in match-flow 7213 o nexthop in cascaded lan as mandatory 7215 o customer-specific-info deleted and moved to routing protocols 7217 o customer-lan-connection modified: need prefix and CE address 7219 o add choice in managing PE-CE addressing 7220 o Simplifying traffic protection 7222 o Refine groupings for vpn-svc 7224 o Removed name in vpn-svc 7226 o id in vpn-svc moved to string 7228 o Rename id in vpn-svc to vpn-id 7230 o Changed key of vpn-svc list to vpn-id 7232 o Add DSCP support in flow definition 7234 o Removed ACL from security 7236 o Add FW for site and cloud access 7238 14.16. Changes between versions -00 and-01 7240 o Creating multiple reusable groupings 7242 o Added mpls leaf in vpn-svc for carrier's carrier case 7244 o Modify identity single to single-site 7246 o Modify site-type to site-role and also child identities. 7248 o Creating OAM container under site and moved BFD in. 7250 o Creating flow-definition grouping to be reused in ACL, QoS ... 7252 o Simplified VPN policy. 7254 o Adding multicast static group to RP mappings. 7256 o Removed native-vpn and site-role from global site cfg, now managed 7257 within the VPN policy. 7259 o Creating a separate list for site templates. 7261 15. References 7263 15.1. Normative References 7265 [I-D.ietf-netconf-restconf] 7266 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 7267 Protocol", draft-ietf-netconf-restconf-18 (work in 7268 progress), October 2016. 7270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 7271 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 7272 RFC2119, March 1997, 7273 . 7275 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 7276 DOI 10.17487/RFC3688, January 2004, 7277 . 7279 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 7280 Private Network (VPN) Terminology", RFC 4026, DOI 7281 10.17487/RFC4026, March 2005, 7282 . 7284 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 7285 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 7286 2006, . 7288 [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the 7289 Provider/Customer Edge Protocol for BGP/MPLS IP Virtual 7290 Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, 7291 June 2006, . 7293 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 7294 Address Autoconfiguration", RFC 4862, DOI 10.17487/ 7295 RFC4862, September 2007, 7296 . 7298 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 7299 and A. Bierman, Ed., "Network Configuration Protocol 7300 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 7301 . 7303 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 7304 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 7305 2012, . 7307 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 7308 Protocol (NETCONF) Access Control Model", RFC 6536, DOI 7309 10.17487/RFC6536, March 2012, 7310 . 7312 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 7313 RFC 7950, DOI 10.17487/RFC7950, August 2016, 7314 . 7316 15.2. Informative References 7318 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 7319 Provider-Provisioned Virtual Private Networks (PPVPNs)", 7320 RFC 4110, DOI 10.17487/RFC4110, July 2005, 7321 . 7323 Authors' Addresses 7325 Stephane Litkowski 7326 Orange Business Services 7328 Email: stephane.litkowski@orange.com 7330 Luis Tomotaki 7331 Verizon 7333 Email: luis.tomotaki@verizon.com 7335 Kenichi Ogaki 7336 KDDI 7338 Email: ke-oogaki@kddi.com