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