idnits 2.17.1 draft-ltsd-l3sm-l3vpn-service-model-00.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 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 266 has weird spacing: '...site-id lea...' == Line 268 has weird spacing: '...site-id lea...' == Line 335 has weird spacing: '...et-site lea...' == Line 397 has weird spacing: '...-rw lan ine...' == Line 399 has weird spacing: '...-rw lan ine...' -- The document date (June 16, 2015) is 3235 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 4110 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 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 Service 4 Intended status: Standards Track R. Shakir 5 Expires: December 18, 2015 BT 6 L. Tomotaki 7 Verizon 8 K. D'Souza 9 ATT 10 June 16, 2015 12 YANG Data Model for L3VPN service delivery 13 draft-ltsd-l3sm-l3vpn-service-model-00 15 Abstract 17 This document defines a YANG data model that can be used to deliver a 18 Layer 3 Provider Provisioned VPN service. The document is limited to 19 the BGP PE-based VPNs as described in RFC4110 and RFC4364. This 20 model is intended to be instantiated at management system to deliver 21 the overall service. This model is not a configuration model to be 22 used directly on network elements. This model provides an abstracted 23 view of the Layer 3 IPVPN service configuration components. It will 24 be up to a management system to take this as an input and use 25 specific configurations models to configure the different network 26 elements to deliver the service. How configuration of network 27 elements is done is out of scope of the 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 December 18, 2015. 51 Copyright Notice 53 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Layer 3 IP VPN service model . . . . . . . . . . . . . . . . 4 73 4. Service data model usage . . . . . . . . . . . . . . . . . . 5 74 5. Design of the Data Model . . . . . . . . . . . . . . . . . . 6 75 5.1. VPN service overview . . . . . . . . . . . . . . . . . . 9 76 5.1.1. VPN service topology . . . . . . . . . . . . . . . . 10 77 5.1.1.1. Route Target allocation . . . . . . . . . . . . . 10 78 5.1.1.2. Any to any . . . . . . . . . . . . . . . . . . . 11 79 5.1.1.3. Hub and Spoke . . . . . . . . . . . . . . . . . . 11 80 5.1.1.4. Hub and Spoke disjoint . . . . . . . . . . . . . 12 81 5.1.2. Cloud access . . . . . . . . . . . . . . . . . . . . 13 82 5.1.3. Multicast service . . . . . . . . . . . . . . . . . . 15 83 5.2. Site overview . . . . . . . . . . . . . . . . . . . . . . 16 84 5.2.1. Deciding where to connect the site . . . . . . . . . 17 85 5.2.1.1. Site location . . . . . . . . . . . . . . . . . . 17 86 5.2.1.2. Site availability . . . . . . . . . . . . . . . . 18 87 5.2.1.3. Site diversity . . . . . . . . . . . . . . . . . 20 88 5.2.1.4. Route Distinguisher and VRF allocation . . . . . 22 89 5.2.2. VPN policy . . . . . . . . . . . . . . . . . . . . . 22 90 5.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 23 91 5.2.3.1. Encryption . . . . . . . . . . . . . . . . . . . 23 92 5.2.4. Management . . . . . . . . . . . . . . . . . . . . . 24 93 5.2.5. Attachment . . . . . . . . . . . . . . . . . . . . . 24 94 5.2.5.1. Bearer . . . . . . . . . . . . . . . . . . . . . 24 95 5.2.5.2. Connection . . . . . . . . . . . . . . . . . . . 24 96 5.2.6. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 30 97 5.2.7. Service . . . . . . . . . . . . . . . . . . . . . . . 32 98 5.2.7.1. QoS . . . . . . . . . . . . . . . . . . . . . . . 32 99 5.2.7.2. Multicast . . . . . . . . . . . . . . . . . . . . 37 100 5.2.7.3. Traffic protection . . . . . . . . . . . . . . . 37 101 5.2.8. Customer specific information . . . . . . . . . . . . 38 102 5.2.8.1. Customer cascaded LANs with provider managed CE . 38 103 5.2.8.2. Customer LANs with provider managed CE . . . . . 39 104 5.2.8.3. Customer LANs with customer managed CE . . . . . 39 105 5.3. Using configuration templates . . . . . . . . . . . . . . 39 106 6. Service model usage example . . . . . . . . . . . . . . . . . 43 107 7. Interaction with Other YANG Modules . . . . . . . . . . . . . 47 108 8. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 51 109 9. To do list / Open questions / Open issues . . . . . . . . . . 80 110 10. Security Considerations . . . . . . . . . . . . . . . . . . . 81 111 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 81 112 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 81 113 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 114 14. Normative References . . . . . . . . . . . . . . . . . . . . 81 115 Appendix A. Example: NETCONF Reply . . . . . . . . . . . . 82 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 118 1. Introduction 120 This document defines a YANG data model for Layer 3 IPVPN service 121 configuration. 123 1.1. Terminology 125 The following terms are defined in [RFC6241] and are not redefined 126 here: 128 o client 130 o configuration data 132 o server 134 o state data 136 The following terms are defined in [RFC6020] and are not redefined 137 here: 139 o augment 141 o data model 143 o data node 144 The terminology for describing YANG data models is found in 145 [RFC6020]. 147 1.2. Tree diagram 149 A simplified graphical representation of the data model is presented 150 in Section 5. 152 The meaning of the symbols in these diagrams is as follows: 154 o Brackets "[" and "]" enclose list keys. 156 o Curly braces "{" and "}" contain names of optional features that 157 make the corresponding node conditional. 159 o Abbreviations before data node names: "rw" means configuration 160 (read-write), and "ro" state data (read-only). 162 o Symbols after data node names: "?" means an optional node and "*" 163 denotes a "list" or "leaf-list". 165 o Parentheses enclose choice and case nodes, and case nodes are also 166 marked with a colon (":"). 168 o Ellipsis ("...") stands for contents of subtrees that are not 169 shown. 171 2. Definitions 173 Customer Edge (CE) Device: The equipment on the customer side of the 174 SP-customer boundary (the customer interface). 176 Provider Edge (PE) Device: The equipment on the SP side of the SP- 177 customer boundary (the customer interface). 179 PE-Based VPNs: The PE devices know that certain traffic is VPN 180 traffic. They forward the traffic (through tunnels) based on the 181 destination IP address of the packet, and optionally on based on 182 other information in the IP header of the packet. The PE devices are 183 themselves the tunnel endpoints. The tunnels may make use of various 184 encapsulations to send traffic over the SP network (such as, but not 185 restricted to, GRE, IP-in-IP, IPsec, or MPLS tunnels). 187 3. Layer 3 IP VPN service model 189 A Layer 3 IPVPN service is a collection of sites that are authorized 190 to exchange traffic between each other over a shared IP 191 infrastructure. This layer 3 VPN service model aims at providing a 192 common understanding on how the corresponding IP VPN service is to be 193 deployed over the shared infrastructure. This service model is 194 limited to BGP PE-Based VPNs as described in [RFC4110] and [RFC4364]. 196 4. Service data model usage 198 L3VPN-SVC | 199 MODEL | 200 | 201 +------------------+ +-----+ 202 | Orchestration | < --- > | OSS | 203 +------------------+ +-----+ 204 | | 205 +----------------+ | 206 | Config manager | | 207 +----------------+ | 208 | | 209 | Netconf/CLI ... 210 | | 211 +------------------------------------------------+ 212 Network 214 +++++++ 215 + AAA + 216 +++++++ 218 +++++++ Bearer ++++++++ ++++++++ +++++++ 219 + CEA + ------- + PE A + + PE B + ----- + CEB + 220 +++++++ Cnct ++++++++ ++++++++ +++++++ 222 Site A Site B 224 The idea of the L3 IPVPN service model is to propose an abstracted 225 interface to manage configuration of components of a L3VPN service. 226 A typical usage is to use this model as an input for an orchestration 227 layer who will be responsible to translate it to orchestrated 228 configuration of network elements who will be part of the service. 229 The network elements can be routers, but also servers (like AAA), and 230 not limited to these examples. The configuration of network elements 231 MAY be done by CLI, or by NetConf/RestConf coupled with specific 232 configuration YANG data models (BGP, VRF, BFD ...) or any other way. 234 The usage of this service model is not limited to this example, it 235 can be used by any component of the management system but not 236 directly by network elements. 238 5. Design of the Data Model 240 The YANG module is divided in two main containers : vpn-svc, sites. 242 The vpn-svc defines global parameters for the VPN service for a 243 specific customer. 245 A site is composed of a customer edge router (CE) attached to a 246 provider edge router (PE). The attachment is done through a bearer 247 with a connection (transport protocol) on top. The bearer refers to 248 physical properties of the attachment while the connection refers to 249 more protocol oriented properties. 251 Authorization of traffic exchange is done through what we call a VPN 252 policy or VPN topology defining routing exchange rules between sites. 254 The figure below describe the overall structure of the YANG module: 256 module: ietf-l3vpn-svc 257 +--rw l3vpn-svc 258 +--rw vpn-svc* [name] 259 | +--rw name string 260 | +--rw id? uint32 261 | +--rw customer-name? string 262 | +--rw topology? identityref 263 | +--rw cloud-access* [cloud-identifier] 264 | | +--rw cloud-identifier string 265 | | +--rw authorized-sites* [site-id] 266 | | | +--rw site-id leafref 267 | | +--rw denied-sites* [site-id] 268 | | | +--rw site-id leafref 269 | | +--rw nat-enabled? boolean 270 | | +--rw customer-nat-address? inet:ipv4-address 271 | +--rw multicast 272 | +--rw tree-flavor* identityref 273 | +--rw rp 274 | | +--rw ipv4-address? inet:ipv4-address 275 | | +--rw ipv6-address? inet:ipv6-address 276 | +--rw rp-discovery? identityref 277 | +--rw anycast-rp-location* string 278 +--rw sites* [site-id] 279 +--rw template? boolean 280 +--rw site-id string 281 +--rw native-vpn? leafref 282 +--rw site-type? identityref 283 +--rw apply-template? leafref 284 +--rw requested-site-start? yang:date-and-time 285 +--rw requested-site-stop? yang:date-and-time 286 +--rw actual-site-start? yang:date-and-time 287 +--rw actual-site-stop? yang:date-and-time 288 +--rw location 289 | +--rw address? string 290 | +--rw zip-code? string 291 | +--rw city? string 292 | +--rw country-code? string 293 +--rw site-diversity 294 | +--rw type? enumeration 295 | +--rw site-group* uint32 296 +--rw security 297 | +--rw apply-template? leafref 298 | +--rw authentication 299 | +--rw encryption 300 | | +--rw enabled? boolean 301 | | +--rw layer? enumeration 302 | | +--rw encryption-profile 303 | | +--rw (profile)? 304 | | +--:(provider-profile) 305 | | | +--rw profile-name? string 306 | | +--:(customer-profile) 307 | | +--rw algorithm? string 308 | | +--rw (key-type)? 309 | | ... 310 | +--rw access-control-list 311 +--rw availability 312 | +--rw availability-type 313 | | +--rw service-type? identityref 314 | | +--rw access-type? identityref 315 | +--rw loadsharing-type? identityref 316 +--rw attachment 317 | +--rw apply-template? leafref 318 | +--rw bearer 319 | | +--rw type? string 320 | | +--rw bearer-reference? string 321 | +--rw connection 322 | +--rw ipv4 323 | | +--rw address-allocation-type? identityref 324 | | +--rw subnet-prefix? inet:ipv4-prefix 325 | +--rw ipv6 326 | | +--rw address-allocation-type? string 327 | | +--rw subnet-prefix? inet:ipv6-prefix 328 | +--rw routing-protocols* [type] 329 | +--rw type identityref 330 | +--rw ospf 331 | | +--rw address-family* identityref 332 | | +--rw area-address? yang:dotted-quad 333 | | +--rw metric? uint16 334 | | +--rw sham-link* [target-site] 335 | | +--rw target-site leafref 336 | | +--rw metric? uint16 337 | +--rw bgp 338 | | +--rw address-family* identityref 339 | +--rw static 340 | | +--rw address-family* identityref 341 | +--rw rip 342 | | +--rw address-family* identityref 343 | +--rw vrrp 344 | | +--rw address-family* identityref 345 | +--rw bfd 346 | +--rw bfd-enabled? boolean 347 | +--rw (holdtime)? 348 | +--:(profile) 349 | | ... 350 | +--:(fixed) 351 | ... 352 +--rw service 353 | +--rw apply-template? leafref 354 | +--rw qos 355 | | +--rw qos-classification-policy 356 | | | +--rw rules* [id] 357 | | | +--rw id uint16 358 | | | +--rw match 359 | | | | +--rw ipv4-src-prefix? inet:ipv4-prefix 360 | | | | +--rw ipv6-src-prefix? inet:ipv6-prefix 361 | | | | +--rw ipv4-dst-prefix? inet:ipv4-prefix 362 | | | | +--rw ipv6-dst-prefix? inet:ipv6-prefix 363 | | | | +--rw l4-src-port? uint16 364 | | | | +--rw l4-dst-port? uint16 365 | | | | +--rw l4-protocol? union 366 | | | +--rw target-class-id? string 367 | | +--rw std-qos-profile? string 368 | | +--rw custom-qos-profile 369 | | +--rw class* [class-id] 370 | | +--rw class-id string 371 | | +--rw rate-limit? uint8 372 | | +--rw priority-level? uint8 373 | | +--rw guaranteed-bw-percent? uint8 374 | +--rw svc-input-bandwidth? uint32 375 | +--rw svc-output-bandwidth? uint32 376 | +--rw svc-mtu? uint16 377 | +--rw traffic-protection 378 | | +--rw link-local-protection? boolean 379 | | +--rw node-local-protection? boolean 380 | | +--rw node-global-protection? boolean 381 | +--rw mpls 382 | | +--rw signalling-type? enumeration 383 | +--rw multicast 384 | +--rw site-type? enumeration 385 +--rw management 386 | +--rw type? identityref 387 | +--rw management-transport? identityref 388 | +--rw address? union 389 +--rw vpn-policy 390 | +--rw import-policy 391 | | +--rw vpn* leafref 392 | +--rw export-policy 393 | +--rw entries* [id] 394 | +--rw id uint32 395 | +--rw lan-prefixes 396 | | +--rw ipv4-lan-prefixes* [lan] 397 | | | +--rw lan inet:ipv4-prefix 398 | | +--rw ipv6-lan-prefixes* [lan] 399 | | +--rw lan inet:ipv6-prefix 400 | +--rw lan-tag* string 401 | +--rw vpn* leafref 402 +--rw maximum-routes 403 | +--rw address-family* [af] 404 | +--rw af identityref 405 | +--rw maximum-routes? uint32 406 +--rw customer-specific-information 407 +--rw name? string 408 +--rw autonomous-system? uint32 409 +--rw interface? string 410 +--rw customer-lan-connection* [address] 411 | +--rw address union 412 | +--rw lan-protocol? identityref 413 +--rw cascaded-lan-prefixes 414 +--rw ipv4-lan-prefixes* [lan] 415 | +--rw lan inet:ipv4-prefix 416 | +--rw lan-tag? string 417 | +--rw next-hop? inet:ipv4-address 418 +--rw ipv6-lan-prefixes* [lan] 419 +--rw lan inet:ipv6-prefix 420 +--rw lan-tag? string 421 +--rw next-hop? inet:ipv6-address 423 5.1. VPN service overview 425 The vpn-svc top container contains generic information about the VPN 426 service. The name of the vpn-svc refers to an internal reference for 427 this VPN service, while customer name refers to a more explicit 428 reference to the customer. An identifier (id) is also present for 429 information systems and configuration that requires this information. 431 This identifier is purely internal to the organization responsible 432 for the VPN service. The vpn-svc name and id MUST be unique. 434 5.1.1. VPN service topology 436 The type of topology of the VPN is required for configuration. 437 Current proposal supports : any-to-any, hub and spoke (where hubs can 438 exchange traffic), and hub and spoke disjoint (where hubs cannot 439 exchange traffic). New topologies could be added by augmentation. 441 5.1.1.1. Route Target allocation 443 Layer 3 PE-based VPN is built using route-targets as described in 444 [RFC4364]. It is expected management system to allocate 445 automatically set of route-targets upon a VPN service creation 446 request. How management system allocates route-targets is out of 447 scope of the document but multiple ways could be envisaged as 448 described below. 450 Management system 451 <----------------------------------------------------> 452 Request RT 453 +-----------------------+ Topo a2a +-------------+ 454 RestConf | | -----> | | 455 User ------------- | Service Orchestration | | Network OSS | 456 l3vpn-svc | | <----- | | 457 model +-----------------------+ Response +-------------+ 458 RT1,RT2 460 In the example above, a service orchestration, owning the 461 instantiation of this service model, request route-targets to the 462 network OSS. Based on the requested VPN topology, the network OSS 463 replies with one or multiple route-targets. The interface between 464 this service orchestration and network OSS is out of scope of this 465 document. 467 +---------------------------+ 468 RestConf | | 469 User ------------- | Service Orchestration | 470 l3vpn-svc | | 471 model | | 472 | RT pool : 10:1->10:10000 | 473 | RT pool : 20:50->20:5000 | 474 +---------------------------+ 476 In the example above, a service orchestration, owning the 477 instantiation of this service model, owns one or more pools of route- 478 target (filled by service provider) that can be allocated. Based on 479 the requested VPN topology, it will allocate one or multiple route- 480 targets from the pool. 482 The mechanism displayed above are just examples and SHOULD NOT be 483 considered as exhaustive list of solutions. 485 5.1.1.2. Any to any 487 +------------------------------------------------------------+ 488 | VPN1_Site1 ------ PE1 PE2 ------ VPN1_Site2 | 489 | | 490 | VPN1_Site3 ------ PE3 PE4 ------ VPN1_Site4 | 491 +------------------------------------------------------------+ 493 Figure - Any to any VPN topology 495 In the any to any topology, all VPN sites can discuss between each 496 other without any restriction. It is expected that the management 497 system that owns a any to any IPVPN service request through this 498 model, needs to assign and then configure the VRF and route-targets 499 on the appropriate PEs. In case of any to any, in general a single 500 route-target is required and every VRF imports and exports this 501 route-target. 503 5.1.1.3. Hub and Spoke 505 +-------------------------------------------------------------+ 506 | Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 | 507 | +----------------------------------+ 508 | | 509 | +----------------------------------+ 510 | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 | 511 +-------------------------------------------------------------+ 513 Figure - Hub and Spoke VPN topology 515 In the hub and spoke topology, all spoke sites can discuss only with 516 Hub sites but not between each other. Hubs can discuss also between 517 each other. It is expected that the management system that owns a 518 any to any IPVPN service request through this model, needs to assign 519 and then configure the VRF and route-targets on the appropriate PEs. 520 In case of hub and spoke, in general a two route-targets are required 521 (one route-target for Hub routes, one route-target for spoke routes). 522 A Hub VRF, connecting Hub sites, will export Hub routes with Hub 523 route-target, and will import Spoke routes through Spoke route- 524 target. It will also import the Hub route-target to permit Hub to 525 Hub communication. A Spoke VRF, connecting Spoke sites, will export 526 Spoke routes with Spoke route-target, and will import Hub routes 527 through Hub route-target. 529 The management system MUST take into account Hub and Spoke 530 connections constraints. For example, if management system decides 531 to mesh a spoke site and a hub site on the same PE, it needs to mesh 532 connections in different VRFs as displayed in the figure below. 534 Hub_Site ------- (VRF_Hub) PE1 535 (VRF_Spoke) 536 / | 537 Spoke_Site1 -------------------+ | 538 | 539 Spoke_Site2 -----------------------+ 541 5.1.1.4. Hub and Spoke disjoint 543 +-------------------------------------------------------------+ 544 | Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 | 545 +--------------------------+ +-------------------------------+ 546 | | 547 +--------------------------+ +-------------------------------+ 548 | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 | 549 +-------------------------------------------------------------+ 551 Figure - Hub and Spoke disjoint VPN topology 553 In the hub and spoke disjoint topology, all spoke sites can discuss 554 only with Hub sites but not between each other. Hubs cannot discuss 555 between each other. It is expected that the management system that 556 owns a any to any IPVPN service request through this model, needs to 557 assign and then configure the VRF and route-targets on the 558 appropriate PEs. In case of hub and spoke, in general a two route- 559 targets are required (one route-target for Hub routes, one route- 560 target for spoke routes). A Hub VRF, connecting Hub sites, will 561 export Hub routes with Hub route-target, and will import Spoke routes 562 through Spoke route-target. A Spoke VRF, connecting Spoke sites, 563 will export Spoke routes with Spoke route-target, and will import Hub 564 routes through Hub route-target. 566 The management system MUST take into account Hub and Spoke 567 connections constraints as in the previous case. 569 5.1.2. Cloud access 571 The proposed model provides cloud access configuration through the 572 cloud-access container. Internet access can typically be considered 573 as cloud access service. The cloud-access container provides 574 parameters for network address translation and authorization rules. 576 A cloud identifier is used to reference the target service. This 577 identifier is local to each administration. 579 If NAT is required to access to the cloud, the nat-enabled leaf MUST 580 be set to true. A NAT address can be provided in customer-nat- 581 address, in case the customer is providing the public IP address for 582 the cloud access. If service provider is providing the NAT address, 583 customer-nat-address MAY not be necessary as it can be picked from a 584 service provider pool. 586 By default, all sites in the IPVPN MUST be authorized to access to 587 the cloud. In case restrictions are required, a user MAY configure 588 the authorized-sites and denied-sites list. The authorization-sites 589 defines the list of sites authorized for cloud access. The denied- 590 sites defines the list of sites denied for cloud access. The model 591 supports both "deny all expect" and "accept all expect" 592 authorization. 594 The "deny all expect" behavior is obtained by filling only the 595 authorized-sites. All the sites listed will be authorized, all 596 others will be denied. 598 The "accept all expect" behavior is obtained by filling only the 599 denied-sites. All the sites listed will be denied, all others will 600 be authorized. 602 Defining both denied-sites and authorized-sites MUST be processed as 603 "deny all expect", so the denied-sites will have not effect. 605 How the restrictions will be configured on network elements is out of 606 scope of this document and will be specific to each deployment. 608 IPVPN 609 ++++++++++++++++++++++++++++++++ +++++++++++ 610 + Site 3 + --- + Cloud1 + 611 + Site 1 + +++++++++++ 612 + + 613 + Site 2 + --- ++++++++++++ 614 + + + Internet + 615 + Site 4 + ++++++++++++ 616 ++++++++++++++++++++++++++++++++ 617 | 618 ++++++++++ 619 + Cloud2 + 620 ++++++++++ 622 In the example above, we may configure the global VPN to access 623 Internet by creating a cloud-access pointing to the cloud identifier 624 for Internet service. No authorized-sites will be configured as all 625 sites are required to access to Internet. NAT-enabled will be set to 626 true and a nat-address will be configured. 628 629 ZKITYHJ054687 630 12456487 631 CUSTOMER_1 632 any-to-any 633 634 51 635 true 636 1.1.1.1 637 638 640 If Site1 and Site2 requires access to Cloud1, a new cloud-access will 641 be created pointing to the cloud identifier of Cloud1. Authorized 642 sites will be filled with reference to Site1 and Site2. 644 645 ZKITYHJ054687 646 12456487 647 CUSTOMER_1 648 any-to-any 649 650 1111111 651 652 site1 653 site2 654 655 656 658 If all sites except Site1 requires access to Cloud2, a new cloud- 659 access will be created pointing to the cloud identifier of Cloud2. 660 denied-sites will be filled with reference to Site1. 662 663 ZKITYHJ054687 664 12456487 665 CUSTOMER_1 666 any-to-any 667 668 22222222 669 670 site1 671 672 673 675 5.1.3. Multicast service 677 Multicast in IP VPN is described in [RFC6513]. 679 If IPVPN supports multicast service, it is expected to provide inputs 680 on global multicast parameters. 682 The user of this model will need to fill the flavor of trees that 683 will be used by customer within the IPVPN (Customer tree). The 684 proposed model supports ASM, SSM and BiDirectional trees (and can be 685 augmented). Multiple flavors of tree can be supported 686 simultaneously. 688 (SSM tree) 689 Recv (IGMPv3) -- Site2 ------- PE2 690 PE1 --- Site1 --- Source1 691 \ 692 ---- Source2 694 (ASM tree) 695 Recv (IGMPv2) -- Site3 ------- PE3 697 (SSM tree) 698 Recv (IGMPv3) -- Site4 ------- PE4 699 / 700 Recv (IGMPv2) -- Site5 -------- 701 (ASM tree) 703 In case of ASM flavor, this model requires to fill the rp and rp- 704 discovery parameters. The rp-discovery supports the auto-rp, static- 705 rp, anycast-rp and bsr-rp modes. 707 5.2. Site overview 709 The L3VPN service is really attached to the notion of sites. A site 710 is composed of some characteristics : 712 o Unique identifier (site-id) : to uniquely identify the site within 713 the overall network infrastructure. The identifier is a string 714 permitting to any encoding for the local administration of the VPN 715 service. 717 o Location (location) : site location informations to permit easy 718 retrieval on nearest available ressources. 720 o Site constraints (site-diversity) : site-diversity container 721 permit to define some constraints for the setup of the site, for 722 example : PE disjointness or PoP disjointness. A site-group 723 identifier permit to manage the disjointness. Two sites with the 724 same group and requiring PE disjointness cannot be connected on 725 the same PE. 727 o Site availability (site-availability) : permit to define the 728 availability service type (single, loadsharing, primary/backup 729 scenarios) and also the access-type within the service (single, 730 primary, backup ...). 732 o Native VPN (native-vpn) and site-type : reference the vpn-svc, the 733 site is belonging to. The site-type defines the role of the site 734 within the native VPN topology (e.g. Hub, Spoke ...). 736 o Management (management) : defines the model of management of the 737 site, for example : comanaged, customer managed or provider 738 managed. 740 o Attachment (attachment) : defines parameters of the attachment of 741 the site, especially bearer, connection and service parameters. 743 The site configuration is viewed as a global entity, we assume that 744 it is mostly the role of the management to split the parameters 745 between the different elements within the network. For example, in 746 the case of the attachment configuration, the management system needs 747 to split the overall parameters between PE configuration and CE 748 configuration. 750 5.2.1. Deciding where to connect the site 752 The management system will have to decide where to connect the site 753 in the provider network (PE, aggregation switch ...). This decision 754 MAY be based on any constraint that are up to the service provider : 755 least load, distance ... The current model proposes some parameters 756 that will help the management system to decide where to attach the 757 customer site. 759 5.2.1.1. Site location 761 The location information provided in this model MAY be used by a 762 management system to decide the target PE to mesh the site. 764 PoP#1 (New York) 765 +---------+ 766 | PE1 | 767 Site #1 ---... | PE2 | 768 (Atlantic City) | PE3 | 769 +---------+ 771 PoP#2 (Washington) 772 +---------+ 773 | PE4 | 774 | PE5 | 775 | PE6 | 776 +---------+ 778 PoP#3 (Philadelphia) 779 +---------+ 780 | PE7 | 781 Site #2 ---... | PE2 | 782 (Reston) | PE9 | 783 +---------+ 785 In the example below, the management system may decide to mesh Site 786 #1 on a PE from Philadelphia PoP for distance reason. It may also 787 take in account resources available on PEs to decide the exact target 788 PE (least load). In case of shortest distance PE used, it may also 789 decide to mesh Site #2 on Washington PoP. 791 5.2.1.2. Site availability 793 The site availability defines parameters for the site redundancy. 794 The YANG model proposes three models of redundancy (service-type) 795 that MAY be extended by augmentation : 797 o single : single homing scenario, no attachment redundancy 798 required. 800 o primary-backup : dual homing scenario, one attachment is primary, 801 when the attachment goes down, traffic goes to the backup 802 attachment. 804 o loadsharing : multihoming scenario, both attachment are used at 805 the same time. How loadsharing is done is not part of service- 806 type. 808 The site availability also defines access-type which defines the role 809 of the site in the availability system. The YANG model proposes four 810 models of access-type : 812 o single-access : used to indicate the single access function. Used 813 for single-homed sites and coupled with "single" service-type. 815 o primary-access : used to indicate the primary access in a primary- 816 backup service-type. 818 o backup-access : used to indicate the backup access in a primary- 819 backup service-type. 821 o loadsharing-access : used to indicate any access in a loadsharing 822 service-type. 824 The figure below describes how site availability attributes can be 825 used. 827 Hub#1 LAN Hub#2 LAN 828 | primary-backup loadsharing | 829 | primary-access loadsharing-access | 830 |--- CE1 ------- PE1 PE3 --------- CE3 --- | 831 | | 832 | | 833 |--- CE2 ------- PE2 PE4 --------- CE4 --- | 834 | primary-backup loadsharing | 835 backup-access loadsharing-access 837 PE5 838 | single 839 | single-access 840 | 841 CE5 842 | 843 Spoke#1 site 845 In case of loadsharing, the YANG model proposes to define the 846 loadsharing policy using loadsharing-type. The model proposes the 847 following types that could be augmented. These option MAY be used on 848 any remote sites (single, primary-backup ...) facing a loadsharing 849 site. 851 o loadsharing-ibgp : loadbalancing will be done between multiple 852 received iBGP paths. 854 o loadsharing-eibgp : loadbalancing will be done between multiple 855 received iBGP paths or eBGP paths : typical application is when a 856 remote site is connected on the same PE than the hub requiring 857 loadsharing. 859 Considering the diagram above, to enable loadsharing for Hub#2 sites, 860 Hub#1 sites and Spoke#1 site can be configured with loadsharing-ibgp 861 as loadsharing-type. If a Spoke#2 site was connected also on PE4, 862 Spoke#2 site may be configured with loadsharing-eibgp as loadsharing- 863 type. 865 Hub#2 LAN 866 loadsharing | 867 loadsharing-access | 868 PE3 --------- CE3 --- | 869 | 870 | 871 PE4 --------- CE4 --- | 872 | loadsharing | 873 | loadsharing-access 874 | 875 | single 876 | single-access 877 | loadsharing-eibgp 878 | 879 CE6 880 | 881 Spoke#2 site 883 The site availability will have an impact on site meshing location, 884 as dual homing may require meshing at least on different network 885 elements (see next section). 887 5.2.1.3. Site diversity 889 The site diversity defines what is the acceptable fate sharing level 890 in case multiple sites for a single VPN must be provisioned in a 891 common location. The site diversity introduces the notion of site- 892 group. Sites belonging to the same site-group cannot share the same 893 fate. We propose to introduce two constraints : 895 PoP diverse : site belonging to the same site-group MUST be 896 provisioned on different PoPs. 898 PE diverse : site belonging to the same site-group MUST be 899 provisioned on different PE routers. 901 How these diversity constraints are applied is out of scope of the 902 document. As an example, the management system receiving the request 903 for diversity, MAY exchange information with some OSS components to 904 define the best target PEs based on location and ressource 905 availability. 907 Consider a dual homed hub site, it is desirable for redundancy to 908 provision the two VPN access connections on two different PEs or two 909 different PoPs. 911 PoP#1 912 +---------+ 913 | PE1 | 914 Hub_Site_primary ------ | PE2 | 915 | PE3 | 916 +---------+ 918 PoP#2 919 +---------+ 920 | PE4 | 921 Hub_Site_backup ------- | PE5 | 922 | PE6 | 923 +---------+ 925 In a PoP diverse scenario, the management system may decide to mesh 926 Hub_Site_primary on any PE of PoP#1 and Hub_Site_backup on any PE of 927 PoP#2. In a PE diverse scenario, if the management system decides to 928 mesh Hub_Site_primary on PE1, it is require to mesh Hub_Site_backup 929 on any PE different from PE1. 931 Site diversity is not limited to multihoming scenarios. If a company 932 has multiple small branch offices (single homed) that requires to be 933 connected in the same location, it is desirable to dispatch the 934 attachment on multiple PEs. So in case of PE crash, only some 935 offices will be impacted. 937 PoP#1 938 +---------+ 939 | PE1 | 940 Office#1 ---... | PE2 | 941 Office#2 ---... | PE3 | 942 Office#3 ---... | PE4 | 943 Office#...--... +---------+ 944 Office#100--... 946 In the figure above, it may be good to mesh 25 offices on each PE of 947 PoP#1 to prevent concentration of two many customer offices on common 948 network elements. 950 5.2.1.4. Route Distinguisher and VRF allocation 952 Route distinguisher is also a critical parameter of PE-based L3VPN as 953 described in [RFC4364] that will permit to distinguish common 954 addressing plans in different VPNs. As for Route-targets, it is 955 expected management system to allocate a VRF on the target PE and a 956 route-distinguisher for this VRF. 958 If a VRF exists on the target PE, and the VRF fulfils the 959 connectivity constraints for the site, there is no need to recreate 960 another VRF and the site MAY be meshed within this existing VRF. How 961 the management system checks that an existing VRF fulfils the 962 connectivity constraints for a site is out of scope of this document. 964 If no VRF exists on the target PE, filling the site constraints, the 965 management system will have to initiate a new VRF creation on the 966 target PE and will have to allocate a new route distinguisher for 967 this new VRF. 969 The management system MAY apply a per-VPN or per-VRF allocation 970 policy for the route-distinguisher depending of the service provider 971 policy. In a per-VPN allocation policy, all VRFs (dispatched on 972 multiple PEs) within a VPN will share the same route distinguisher 973 value. In a per-VRF model, all VRFs will always have a unique route- 974 distinguisher value. Some other allocation policies are also 975 possible, and this document does not restrict the allocation policies 976 to be used. 978 Allocation of route-distinguisher MAY be done in the same way as the 979 route-targets. The example provided in Section 5.1.1.1 could be 980 reused. 982 Note that a service provider MAY decide to configure target PE for 983 automated allocation of route distinguisher. In this case, there 984 will be no need for any backend system to allocate a route- 985 distinguisher value. 987 5.2.2. VPN policy 989 The VPN policy defines the route exchange between multiple VPNs. A 990 vpn-policy configuration is not required if there is no inter VPN 991 relations. Indeed the VPN policy already exists from the topology of 992 the VPN, and the management system using this service model MUST 993 derive the VRF configuration from the VPN topology. The vpn-policy 994 container only defines relations with VPNs that are not the native 995 vpn. In case, a vpn-policy is defined, the management system will 996 built the route-target policy configuration from a combination of 997 both the vpn-policy and the vpn-topology. 999 +--------------------------------------------------------------+ 1000 | VPN1_Site1 ------ PE1 PE2 ------ VPN1_Site2 | 1001 +--------------------------------------------------------------+ 1003 +--------------------------------------------------------------+ 1004 | VPN2_Site1 ------ PE3 PE4 ------ VPN2_Site2 | 1005 +----------------------------------+ | 1006 | | 1007 +------------------------------------------------------------+ | 1008 | VPN3_Site1 ------ PE5 | PE6 ------ VPN3_Site2 | | 1009 +------------------------------------------------------------+ | 1010 | | 1011 +---------------------------+ 1013 Let us consider two existing vpn service VPN1 and VPN2 with a any-to- 1014 any topology. When the vpn services are provisioned a route-target 1015 value will be affected by the OSS of the service provider for these 1016 VPNs. Let's call RT1 the route-target of VPN1,and RT2 the route- 1017 target of VPN2. Now we consider a new VPN service VPN3 (any to any) 1018 that must be provisioned, RT3 will be allocated by the OSS for proper 1019 configuration on network elements. 1021 Consider a site#1 in VPN3 that must communicate only in VPN3, in this 1022 case, there is no need to specify any vpn-policy for site#1, as 1023 site#1 will be provisioned using the native-vpn policy which is any- 1024 to-any in VPN3. VRF on PE5 for VPN3 will be so provisioned by the 1025 management system using RT3 value as import and export value. 1027 Consider a site#2 in VPN3 that must communicate in VPN3, and a 1028 specific LAN LAN1 must communicate with VPN2, in this case, we need 1029 to define for site#2 a vpn-policy that imports VPN2 and exports LAN1 1030 to VPN2. VRF on PE6 for VPN3 will be so provisioned by the 1031 management system using RT3 value as import and RT3 as export value 1032 plus RT2 for LAN1 prefix. 1034 5.2.3. Security 1036 Security container defines customer specific security parameters for 1037 the site. This section will more be detailled in future revision. 1039 5.2.3.1. Encryption 1041 Encryption can be requested on the connection. It may be performed 1042 at layer 2 or layer 3 by selecting the appropriate enumeration in 1043 "layer" leaf. The encryption profile can be a service provider 1044 defined template or customer specific. 1046 5.2.4. Management 1048 The model proposes three types of common management options : 1050 o comanaged : the CE router is managed by the provider and also by 1051 the customer. 1053 o provider-managed : the CE router is managed only by the provider. 1055 o customer-managed : the CE router is managed only by the customer. 1057 Based on the management model, different security options MAY be 1058 derived. 1060 In case of "provider-managed" or "comanaged", the model proposes some 1061 option to define the management transport protocol (IPv4 or IPv6) and 1062 the associated management address. 1064 5.2.5. Attachment 1066 The attachment defines how the service is connected on the network 1067 and is splitted in three class of parameters : 1069 o bearer : defines physical parameters of the attachment. 1071 o connection : defines protocol parameters of the attachment 1072 (transport layer and routing protocols). 1074 5.2.5.1. Bearer 1076 TBD. 1078 5.2.5.2. Connection 1080 The connection defines the protocol parameters of the attachment 1081 (IPv4 and IPv6) as well as routing. 1083 5.2.5.2.1. IP addressing 1085 IP subnet can be configured for either transport protocols. For a 1086 dual stack connection, two subnets will be provided, one for each 1087 transport layer. 1089 The address-allocation-type will help in defining how the address 1090 allocation MUST be done. The current model proposes three ways of IP 1091 address allocation : 1093 o pe-dhcp : the PE router will provide DHCP service for CE router, 1094 this is applicable to both IPv4 and IPv6 addressing. 1096 o static-address : Addresses will be assigned manually on both 1097 sides, this is applicable to both IPv4 and IPv6 addressing. 1099 o slaac : enables stateless address autoconfiguration ([RFC4862]). 1100 This is applicable only for IPv6. 1102 5.2.5.2.2. Routing protocols 1104 Routing-protocol defines which routing protocol must be activated 1105 between the provider edge and the customer. The current model 1106 support : bgp, rip, rip-ng, ospf, static, direct, vrrp. 1108 Rtg protocol 1109 192.0.2.0/24 ----- CE ----------------- PE1 1111 If the CE is comanaged or provider managed, the management system 1112 will be required to configure the routing protocol on both side on 1113 the connnection. 1115 | L3VPN SVC model 1116 | 1117 +------------+ 1118 + Mgt system + 1119 +------------+ 1120 / \ 1121 / \ Routing protocol config 1122 / \ (CLI, Netconf ...) 1123 / Rtg protocol \ 1124 192.0.2.0/24 ----- CE ----------------- PE1 1126 Routing protocol config - provider managed or comanaged CE 1128 If the CE is customer managed, the management system will be required 1129 to configure the routing protocol only the PE router. 1131 | L3VPN SVC model 1132 | 1133 +------------+ 1134 + Mgt system + 1135 +------------+ 1136 \ 1137 \ Routing protocol config 1138 \ (CLI, Netconf ...) 1139 Rtg protocol \ 1140 192.0.2.0/24 ----- CE ----------------- PE1 1142 Routing protocol config - customer managed CE 1144 5.2.5.2.2.1. Dual stack handling 1146 All routing protocol types support dual stack by using address-family 1147 leaf-list. 1149 Example of Dual stack using the same routing protocol : 1151 1152 static 1153 1154 ipv4-unicast 1155 ipv6-unicast 1156 1157 1159 Example of Dual stack using two different routing protocols : 1161 1162 rip 1163 1164 ipv4-unicast 1165 1166 1167 1168 ospf 1169 1170 ipv6-unicast 1171 1172 1174 5.2.5.2.2.2. Direct LAN connection onto SP network 1176 Routing-protocol "direct" SHOULD be used when a customer LAN is 1177 directly connected to the provider network and must be advertised in 1178 the IPVPN. 1180 LAN attached directly to provider network : 1182 192.0.2.0/24 ----- PE1 1184 5.2.5.2.2.3. Direct LAN connection onto SP network with redundancy 1186 Routing-protocol "vrrp" SHOULD be used when a customer LAN is 1187 directly connected to the provider network and must be advertised in 1188 the IPVPN and LAN redundancy is expected. 1190 LAN attached directly to provider network with LAN redundancy: 1192 192.0.2.0/24 ------ PE1 1193 | 1194 +-- PE2 1196 5.2.5.2.2.4. Static routing 1198 Routing-protocol "static" MAY be used when a customer LAN is 1199 connected to the provider network through a CE router and must be 1200 advertised in the IPVPN. 1202 Static rtg 1203 192.0.2.0/24 ------ CE -------------- PE 1204 | | 1205 | Static route 192.0.2.0/24 nh CE 1206 Static route 0.0.0.0/0 nh PE 1208 5.2.5.2.2.5. RIP routing 1210 Routing-protocol "rip" MAY be used when a customer LAN is connected 1211 to the provider network through a CE router and must be advertised in 1212 the IPVPN. 1214 In case of dual stack, the management system will be responsible to 1215 configure rip (including right version number) and rip-ng instances 1216 on network elements. 1218 RIP rtg 1219 192.0.2.0/24 ------ CE -------------- PE 1221 5.2.5.2.2.6. OSPF routing 1223 Routing-protocol "ospf" MAY be used when a customer LAN is connected 1224 to the provider network through a CE router and must be advertised in 1225 the IPVPN. 1227 It can be used to extend an existing OSPF network and interconnect 1228 different areas. See [RFC4577] for more details. 1230 +---------------------+ 1231 | | 1232 OSPF | | OSPF 1233 area 1 | | area 2 1234 (OSPF | | (OSPF 1235 area 1) --- CE ---------- PE PE ------- CE --- area 2) 1236 | | 1237 +---------------------+ 1239 The model also proposes an option to create an OSPF sham-link between 1240 two sites sharing the same area and having a backdoor link. The 1241 sham-link is created by referencing the target site sharing the same 1242 OSPF area. The management system will be responsible to check if 1243 there is already a shamlink configured for this VPN and area between 1244 the same pair of PEs. If there is no existing shamlink, the 1245 management system will provision it, this shamlink MAY be reused by 1246 other sites. 1248 +------------------------+ 1249 | | 1250 | | 1251 | PE (--shamlink--)PE | 1252 | | | | 1253 +----|----------------|--+ 1254 | OSPF area1 | OSPF area 1 1255 | | 1256 CE1 CE2 1257 | | 1258 (OSPF area1) (OSPF area1) 1259 | | 1260 +----------------+ 1262 Regarding Dual stack support, user MAY decide to fill both IPv4 and 1263 IPv6 address families, if both protocols SHOULD be routed through 1264 OSPF. As OSPF is using two different protocol for IPv4 and IPv6, the 1265 management system will need to configure both ospf version 2 and 1266 version 3 on the PE-CE link. 1268 Example of OSPF routing parameters in service model. 1270 1271 ospf 1272 1273 1.1.1.1 1274 ipv4-unicast 1275 ipv6-unicast 1276 1277 1279 Example of PE configuration done by management system : 1281 router ospf 10 1282 area 0.0.0.0 1283 interface Ethernet0/0 1284 ! 1285 router ospfv3 10 1286 area 0.0.0.0 1287 interface Ethernet0/0 1288 ! 1290 5.2.5.2.2.7. BGP routing 1292 Routing-protocol "bgp" MAY be used when a customer LAN is connected 1293 to the provider network through a CE router and must be advertised in 1294 the IPVPN. 1296 BGP rtg 1297 10.0.0.0/24 ------ CE -------------- PE 1299 The AS numbers, peerings addressing will be derived from connection 1300 parameters or customer-specific-information as well as internal 1301 knowledge of SP. 1303 In case of dual stack access, user MAY request BGP routing for both 1304 IPv4 and IPv6 by filling both address-families. It will be up to SP 1305 and management system to decide how to decline the configuration (two 1306 BGP sessions, single, multisession ...). 1308 The service configuration below actives BGP on PE-CE link for both 1309 IPv4 and IPv6. 1311 1312 bgp 1313 1314 ipv4-unicast 1315 ipv6-unicast 1316 1317 1319 This service configuration can be derived by management system into 1320 multiple flavors depending on SP flavor. 1322 Example #1 of PE configuration done by management system 1323 (single session IPv4 transport): 1325 router bgp 100 1326 neighbor 203.0.113.2 remote-as 65000 1327 address-family ipv4 vrf Cust1 1328 neighbor 203.0.113.2 activate 1329 address-family ipv6 vrf Cust1 1330 neighbor 203.0.113.2 activate 1331 neighbor 203.0.113.2 route-map SET-NH-IPV6 out 1333 Example #2 of PE configuration done by management system (two sessions): 1335 router bgp 100 1336 neighbor 203.0.113.2 remote-as 65000 1337 neighbor 2001::2 remote-as 65000 1338 address-family ipv4 vrf Cust1 1339 neighbor 203.0.113.2 activate 1340 address-family ipv6 vrf Cust1 1341 neighbor 2001::2 activate 1343 Example #3 of PE configuration done by management system (multisession): 1345 router bgp 100 1346 neighbor 203.0.113.2 remote-as 65000 1347 neighbor 203.0.113.2 multisession per-af 1348 address-family ipv4 vrf Cust1 1349 neighbor 203.0.113.2 activate 1350 address-family ipv6 vrf Cust1 1351 neighbor 203.0.113.2 activate 1352 neighbor 203.0.113.2 route-map SET-NH-IPV6 out 1354 5.2.6. MPLS 1356 In case of Carrier Supporting Carrier (CsC), a customer MAY want to 1357 build MPLS service using an IPVPN as transport layer. 1359 LAN customer1 1360 | 1361 | 1362 CE1 1363 | 1364 | ------------- 1365 (vrf_cust1) 1366 CE1_ISP1 1367 | ISP1 PoP 1368 | MPLS link 1369 | ------------- 1370 | 1371 (vrf ISP1) 1372 PE1 1374 (...) Provider backbone 1376 PE2 1377 (vrf ISP1) 1378 | 1379 | ------------ 1380 | 1381 | MPLS link 1382 | ISP1 PoP 1383 CE2_ISP1 1384 (vrf_cust1) 1385 |------------- 1386 | 1387 CE2 1388 | 1389 Lan customer1 1391 In the figure above, ISP1 resells IPVPN service but has no transport 1392 infrastructure between its PoPs. ISP1 uses an IPVPN as transport 1393 infrastructure (belonging to another provider) between its PoPs. The 1394 link between CE1_ISP1/PE1 and CE2_ISP1/PE2 MUST so be MPLS enabled. 1396 In the proposed model, LDP or BGP can be used as MPLS signalling 1397 protocol. In case of LDP, an IGP routing protocol MUST also be 1398 activated. In case of BGP signalling, BGP MUST also be configured as 1399 routing-protocol. 1401 5.2.7. Service 1403 The service defines service parameters associated with the site. 1405 5.2.7.1. QoS 1407 The model proposes to define QoS parameters in an abstracted way : 1409 o qos-classification-policy : define a set of ordered rules to 1410 classify customer traffic. 1412 o std-qos-profile : provider standard outgoing QoS profile to be 1413 applied. This is a reference to a well known profile in Service 1414 provider administration. 1416 o custom-qos-profile : defines customer specific profiles. 1418 5.2.7.1.1. QoS classification 1420 QoS classification rules are handled by qos-classification-policy. 1421 The qos-classification-policy is an ordered list of rules that match 1422 a flow and set the appropriate target class of service (target-class- 1423 id). The match criterions provide a basic infrastructure for 1424 defining flows : layer 3 source and destination address, layer 4 1425 ports, layer 4 protocol. 1427 Where the classification is done depends on the SP implementation of 1428 the service, but classification concerns the flow coming from the 1429 customer site and entering the network. 1431 Provider network 1432 +-----------------------+ 1433 192.0.2.0/24 1434 198.51.100.0/24 ---- CE --------- PE 1436 Traffic flow 1437 ----------> 1439 In the figure above, the management system can decide : 1441 o if the CE is customer managed, to implement the classification 1442 rule in the ingress direction on the PE interface. 1444 o if the CE is provider managed, to implement the classification 1445 rule in the ingress direction on the CE interface connected to 1446 customer LAN. 1448 The figure below describes a sample service description of qos- 1449 classification for a site : 1451 1452 1453 1454 1455 1 1456 1457 192.0.2.0/24 1458 1.1.1.1/32 1459 80 1460 tcp 1461 1462 DATA2 1463 1464 1465 2 1466 1467 192.0.2.0/24 1468 1.1.1.1/32 1469 21 1470 tcp 1471 1472 DATA2 1473 1474 1475 3 1476 DATA1 1477 1478 1479 1480 1482 In the example above : 1484 o HTTP traffic from 192.0.2.0/24 LAN destinated to 1.1.1.1/32 will 1485 be classified in DATA2. 1487 o FTP traffic from 192.0.2.0/24 LAN destinated to 1.1.1.1/32 will be 1488 classified in DATA2. 1490 o All other traffic will be classified in DATA1. 1492 The order of rules is really important. The management system 1493 responsible for translating those rules in network element 1494 configuration MUST keep the same processing order in element 1495 configuration. The order of rule is defined by the "id" leaf. The 1496 lowest "id" MUST be processed first. 1498 5.2.7.1.2. QoS profile 1500 std-qos-profile and custom-qos-profile define output QoS profiles to 1501 be used between PE and CE. 1503 Provider network 1504 +-----------------------+ 1505 192.0.2.0/24 1506 198.51.100.0/24 ---- CE --------- PE 1507 \ / 1508 qos-profile 1510 std-qos-profile and custom-qos-profile cannot be used at the same 1511 time. If both are present, the management system SHOULD keep only 1512 the custom-qos-profile. 1514 A custom-qos-profile is defined as a list of class of services and 1515 associated properties. The properties are : 1517 o rate-limit : used to rate-limit the class of service. The value 1518 is expressed as a percentage of the global service bandwidth. 1520 o priority-level : used to define priorities between class of 1521 services. The value of the priority to be used is dependant of 1522 each administration. The higher the priority-level is, the higher 1523 the priority of the class will be. Priority-level is used to 1524 define strict priority queueing. A priority-level 250 class will 1525 be served before a priority-level 100 class until there is no more 1526 packet to process or until rate-limit does not allow anymore 1527 packets from the higher priority class. 1529 o guaranteed-bw-percent : used to define a guaranteed amount of 1530 bandwidth for the class of service. It is expressed as a 1531 percentage. The guaranteed-bw-percent uses available bandwidth at 1532 the priority-level of the class. 1534 Example of service configuration using a standard qos profile : 1536 1537 1245HRTFGJGJ154654 1538 VPN1 1539 any-to-any-site 1540 1541 100000000 1542 100000000 1543 1544 PLATINUM 1545 1546 1547 1548 1549 555555AAAA2344 1550 VPN1 1551 any-to-any-site 1552 1553 2000000 1554 2000000 1555 1556 GOLD 1557 1558 1559 1561 Example of service configuration using a custom qos profile : 1563 1564 Site1 1565 VPN1 1566 any-to-any-site 1567 1568 100000000 1569 100000000 1570 1571 1572 1573 REAL_TIME 1574 10 1575 10 1576 1577 1578 DATA 1579 5 1580 1581 1582 1584 1585 1586 1587 Site2 1588 VPN1 1589 any-to-any-site 1590 1591 2000000 1592 2000000 1593 1594 1595 1596 REAL_TIME 1597 30 1598 10 1599 1600 1601 DATA1 1602 5 1603 80 1604 1605 1606 DATA2 1607 5 1608 20 1609 1610 1611 1612 1613 1615 The custom-qos-profile for site1 defines that traffic from REAL_TIME 1616 class will have a higher priority than traffic from DATA class. The 1617 REAL_TIME traffic will be rate-limit to 10% of the service bandwidth 1618 (10% of 100Mbps = 10Mbps) to let some place for DATA traffic. 1620 The custom-qos-profile for site2 defines that traffic from REAL_TIME 1621 class will have a higher priority than traffic from data traffic. 1622 Data traffic will be splitted in two class of service DATA1 and DATA2 1623 that will share bandwidth between them according to the percentage of 1624 guaranteed-bw-percent. The maximum of percentage to be used is not 1625 limited by this model but MUST be limited by the management system 1626 according to the policies authorized by the service provider. The 1627 REAL_TIME traffic will be rate-limit to 30% of the service bandwidth 1628 (30% of 100Mbps = 30Mbps) to let some place for data traffic. In 1629 case of congestion of the access, the REAL_TIME traffic can go up to 1630 30Mbps (Let's assume that 20Mbps only are consumed). The DATA1 and 1631 DATA2 will share remaining bandwidth (80Mbps) according to their 1632 percentage. So DATA1 will be served with at least 64Mbps of 1633 bandwidth. 1635 5.2.7.2. Multicast 1637 The multicast section defines the type of site in the customer 1638 multicast topology : source, receiver, or both. These parameters 1639 will help management system to optimize the multicast service. 1641 5.2.7.3. Traffic protection 1643 The service model supports the ability to protect traffic from or to 1644 a site. 1646 Site#1 Site#2 1647 CE1 ----- PE1 -- P1 P3 -- PE3 ---- CE3 1648 | | | 1649 | | | 1650 CE2 ----- PE2 -- P2 P4 -- PE4 ---- CE4 1651 / 1652 / 1653 CE5 ----+ 1654 Site#3 1656 In the figure above, we consider an IPVPN service with three sites 1657 including two dual homed sites (site#1 and #2). For dual homed 1658 sites, we consider PE1-CE1 and PE3-CE3 as primary, and 1659 PE2-CE2,PE4-CE4 as backup for the example (even if protection also 1660 applies to loadsharing scenarios.) 1662 In order to protect Site#2 for a PE-CE link failure, a service 1663 provider MAY configure link-local-protection on the primary access of 1664 site#2 (PE3-CE3). In such case, if we consider traffic coming from a 1665 remote site (site#1 or site#3), primary path is to use PE3 as egress 1666 PE. PE3 has preprogrammed a backup forwarding entry pointing to 1667 backup path (through PE4-CE4) for all prefixes going through PE3-CE3 1668 link. How backup path is computed is out of scope of the document. 1669 When PE3-CE3 link fails, traffic is still received by PE3 but PE3 1670 switch automatically traffic to the backup entry, path will so be 1671 PE1-P1-(...)-P3-PE3-PE4-CE4 until remote PEs reconverge and use PE4 1672 as egress PE. 1674 In order to protect Site#2 for a egress PE node failure, a service 1675 provider may configure node-local-protection on the primary access of 1676 site#2 (PE3-CE3). This protection flavor is so called egress PE node 1677 protection. In such case, if we consider traffic coming from a 1678 remote site (site#1 or site#3), primary path is to use PE3 as egress 1679 PE. P3 has preprogrammed a backup forwarding entry pointing to 1680 backup path. How backup path is computed is out of scope of the 1681 document. When PE3 node fails, traffic is still received by P3 but 1682 P3 switch automatically traffic to the backup entry, path will so be 1683 PE1-P1-(...)-P3-P4-PE4-CE4 until remote PEs reconverge and use PE4 as 1684 egress PE. 1686 In order to protect Site#2 for a egress PE node failure, another 1687 flavor of protection can be used, a service provider MAY configure 1688 node-global-protection on all remote sites. This protection flavor 1689 is generally called PIC Edge (Prefix Independent Convergence for 1690 Edge). In such case, if we consider traffic coming from a remote 1691 site (site#1 or site#3), primary path is to use PE3 as egress PE. 1692 All remote PEs (PE1,PE2) have preprogrammed a backup forwarding entry 1693 pointing to backup path (through PE4). How backup path is computed 1694 is out of scope of the document. When PE3 node fails, remote PEs 1695 detect through IGP convergence that PE3 is no more reachable and 1696 decide to switch automatically traffic to the backup entry, path will 1697 so be PE1-P1-(...)-P4-PE4-CE4. In this case, as BGP convergence is 1698 involved, there is no other need of reconvergence. 1700 5.2.8. Customer specific information 1702 Customer specific informations are used to store informations owned 1703 by customers. The customer may have some LANs directly connected to 1704 CE routers managed by Service providers. In this case, customer 1705 needs to allocate IP addresses from its LAN addressing plan for the 1706 CE router. This is the purpose of the customer-lan-connection list 1707 which provides information about addresses allocated from each 1708 customer LAN connected to the CE router. 1710 In case, provider needs to route some LAN that are cascaded behind 1711 those connected LANs, cascaded-lan-prefixes can be used. In this 1712 version of the document, static routing is assumed between CE and 1713 customer LANs. 1715 5.2.8.1. Customer cascaded LANs with provider managed CE 1717 192.0.2.0/24 ---- CustFW1 ---- 203.0.113.0/24 --- CE1 ----- PE1 1718 / 1719 198.51.100.0/24 ---- 1720 In the example above, CE1 owned by service provider is attached to 1721 203.0.113.0/24 LAN of the customer. Customer allocated 192.0.2.254 1722 for CE1, this information will have to be reported as a customer-lan- 1723 connection in the service model. Customer also have two LANs 1724 cascaded behind a firewall (192.0.2.0/24 and 198.51.100.0/24), those 1725 LANs MUST be routed within the IPVPN. cascaded-lan-prefixes MUST be 1726 used to fill those informations. The IP address of the firewall MUST 1727 be filled as nexthop of those LANs. 1729 5.2.8.2. Customer LANs with provider managed CE 1731 192.0.2.0/24 ---- CE1 ----- PE1 1732 / 1733 198.51.100.0/24 ---- 1735 In the example above, CE1 owned by service provider is attached to 1736 203.0.113.0/24 LAN of the customer. Customer allocated 192.0.2.254 1737 and 198.51.100.254 for CE1, this information will have to be reported 1738 as a customer-lan-connection in the service model. 1740 5.2.8.3. Customer LANs with customer managed CE 1742 192.0.2.0/24 ---- CE1 ----- PE1 1743 / 1744 198.51.100.0/24 ---- 1746 In the example above, CE1 owned by customer is attached to 1747 203.0.113.0/24 LAN. The service provider only have to deal with 1748 routing with customer CE, the routing-protocol information on the 1749 connection will define this. 1751 5.3. Using configuration templates 1753 The proposed model supports the creation and application of 1754 configuration templates for sites. 1756 A template can be configured by creating a new site with the template 1757 leaf equal to true. This means that the site is not a real site and 1758 its just a configuration template. 1760 Multiple template sites can be configured. Templates can be applied 1761 at multiple levels referenced by apply-template leaf. The apply- 1762 template references the site-id of the template to be called. The 1763 location of the apply-template within the sites hierarchy defines 1764 which parameters must be inherited. For example, if apply-template 1765 is done on service container of a site, only service container 1766 parameters (and childs) from the template will be applied. 1768 Apply-template cannot be used within a template. 1770 1771 Template-VoiceCoS-Cust1 1772 1773 1774 1775 1776 1777 REAL_TIME 1778 30 1779 10 1780 1781 1782 DATA1 1783 5 1784 80 1785 1786 1787 DATA2 1788 5 1789 20 1790 1791 1792 1793 1794 1796 1797 Template-VPNsite-Customer1 1798 VPN1 1799 any-to-any-site 1800 1801 1802 1803 PLATINUM 1804 1805 1806 1807 1808 1809 static 1810 static 1811 1813 1814 1815 1816 1817 Service_VPN1 1818 1819 1820 1821 VOICE 1822 Service_VPN1 1823 1824 1825 1826 1828 Template sites permit to define configuration blocks that will be 1829 inherited by one or multiple sites in order to speed up 1830 configuration. For example, if all the sites of an IPVPN service 1831 have the almost same configuration (routing-protocol, qos, management 1832 ...), a template can be created and each site of the VPN will 1833 reference the template. If a site has some particular parameters, 1834 specific parameters within the site MUST always override parameters 1835 derived from template. 1837 The example above defines two site templates : 1839 o Template-VPNsite-Customer1 that will be used to configure all the 1840 VPN sites for customer 1. 1842 o Template-VoiceCoS-Cust1 that will be used to configure some 1843 special CoS policy on some specific accesses of the VPN. 1845 In the example below, all sites of VPN1 are inheriting basic 1846 configuration from template Template-VPNsite-Customer1. Some 1847 specific parameters like svc-input-bandwidth are also defined for 1848 each site. For Site 4 and 5 , specific QoS parameters are required, 1849 a new template Template-VoiceCoS-Cust1 is applied at service level 1850 for these two sites, overriding the service parameters from the 1851 Template-VPNsite-Customer1 template. 1853 1854 Site1 1855 Template-VPNsite-Customer1 1856 1857 5000000 1858 5000000 1859 1860 1861 1862 Site2 1863 Template-VPNsite-Customer1 1864 1865 20000000 1866 20000000 1867 1868 1869 1870 Site3 1871 Template-VPNsite-Customer1 1872 1873 30000000 1874 30000000 1875 1876 1878 1879 Site4 1880 Template-VPNsite-Customer1 1881 1882 Template-VoiceCoS-Cust1 1883 100000000 1884 100000000 1885 1886 1887 1888 Site5 1889 Template-VPNsite-Customer1 1890 1891 Template-VoiceCoS-Cust1 1892 450000000 1893 450000000 1894 1895 1897 6. Service model usage example 1899 As explained in Section 4, this service model is intended to be 1900 instantiated at a management layer and is not intended to be used 1901 directly on network elements. The management system serves as a 1902 central point of configuration of the overall service. 1904 This section provides an example on how a management system can use 1905 this model to configure an IPVPN service on network elements. 1907 The example wants to achieve the provisionning of a VPN service for 3 1908 sites using hub and spoke topology. One of the site will be dual 1909 homed and loadsharing is expected. 1911 +-------------------------------------------------------------+ 1912 | Hub_Site ------ PE1 PE2 ------ Spoke_Site1 | 1913 | | +----------------------------------+ 1914 | | | 1915 | | +----------------------------------+ 1916 | Hub_Site ------ PE3 PE4 ------ Spoke_Site2 | 1917 +-------------------------------------------------------------+ 1919 The following XML describes the overall simplified service 1920 configuration of this VPN. 1922 1923 VPN1 1924 12456487 1925 CUSTOMER1 1926 hub-spoke 1927 1929 When receiving the request for provisionning the VPN service, the 1930 management system will internally (or through discussion with other 1931 OSS component) allocates VPN route-targets. In this specific case 1932 two RTs will be allocated (100:1 for Hub and 100:2 for Spoke). The 1933 output below describes the configuration of Spoke1. 1935 1936 Spoke_Site1 1937 VPN1 1938 spoke-site 1939 1940 pe-diverse 1941 100 1942 1943 1944 NY 1945 US 1946 1947 1948 1949 1950 203.0.113.0/30 1951 1952 1953 bgp 1954 1955 ipv4-unicast 1956 1957 1958 1959 1960 1961 provider-managed 1962 ipv4-unicast 1963
10.46.1.1
1964 1965 1966 450000000 1967 450000000 1968 1969 1970 1971
192.0.2.254
1972 ipv4-unicast 1973 1974 1975 1976 198.51.100.0/30 1977 192.0.2.253 1978 1979 1980 198.51.100.4/30 1981 192.0.2.253 1982 1983 1984 198.51.100.8/30 1985 192.0.2.253 1986 1987 1988 1989 1991 When receiving the request for provisionning Spoke1 site, the 1992 management system MUST allocate network ressources for this site. It 1993 MUST first decide the target network elements to provision the 1994 access, and especially the PE router (and may be an aggregation 1995 switch). As described in Section 5.2.1, the management system MAY 1996 use the location information and MUST use the site-diversity 1997 constraint to find the appropriate PE. In this case, we consider 1998 Spoke1 requires PE diversity with Hub and that management system 1999 allocate PEs based on lowest distance. Based on the location 2000 information, the management system finds the available PEs in the 2001 nearest area of the customer and picks one that fits the site- 2002 diversity constraint. 2004 When the PE is chosen, management system needs to allocate interface 2005 resources on the node, one interface is so picked from the PE 2006 available pool. The management system can start provisioning the PE 2007 node by using any mean (Netconf, CLI, ...). The management system 2008 will check if a VRF is already present that fits the needs. If not, 2009 it will provision the VRF : Route distinguisher will come from 2010 internal allocation policy model, route-targets are coming from the 2011 native-vpn configuration of the site (management system allocated 2012 some RTs for the VPN). As the site is a spoke site (site-type), the 2013 management system knows which RT must be imported and exported. As 2014 the site is provider managed, some management route-targets may also 2015 be added (100:5000). Standard provider VPN policies MAY also be 2016 added in the configuration. 2018 Example of generated PE configuration : 2020 ip vrf Customer1 2021 export-map STD-CUSTOMER-EXPORT <---- Standard SP configuration 2022 route-distinguisher 100:3123234324 2023 route-target import 100:1 2024 route-target import 100:5000 <---- Standard SP configuration 2025 route-target export 100:2 for provider managed 2026 ! 2028 When the VRF has been provisioned, the management system can start 2029 configuring the access on the PE using the allocated interface 2030 information. IP addressing is derived from the subnet-prefix of the 2031 connection. One address will be picked from the subnet for the PE, 2032 another will be used for the CE configuration. Routing protocols 2033 will also be configured on the PE, bgp will be used as requested in 2034 the service model. Peering addresses will be derived from subnet- 2035 prefix. PE AS number is well known and as CE is provider managed, CE 2036 AS number can be automatically allocated by the management system. 2037 Some provider standard configuration templates may also be added. 2039 Example of generated PE configuration : 2041 interface Ethernet1/1/0.10 2042 encapsulation dot1q 10 2043 ip vrf forwarding Customer1 2044 ip address 203.0.113.1 255.255.255.252 <---- Comes from subnet-prefix 2045 ip access-group STD-PROTECT-IN <---- Standard SP configuration 2046 ! 2047 router bgp 100 2048 address-family ipv4 vrf Customer1 2049 neighbor 203.0.113.2 remote-as 65000 <---- Comes from subnet-prefix 2050 and allocated CE ASN 2051 neighbor 203.0.113.2 route-map STD in <---- Standard SP configuration 2052 neighbor 203.0.113.2 filter-list 10 in <---- Standard SP configuration 2053 ! 2054 ip route vrf Customer1 203.0.113.254 255.255.255.255 203.0.113.2 tag 50 2055 ! Static route for provider administration of CE 2056 ! 2058 As the CE router is not reachable at this stage, the management 2059 system can produce a complete CE configuration that can be uploaded 2060 to the node by manual operation before sending the CE to customer 2061 premise. The CE configuration will be built as for the PE. Based on 2062 the CE type (vendor/model) allocated to the customer and bearer 2063 information, the management system knows which interface must be 2064 configured on the CE. Interface parameters like IP addressing are 2065 derived from subnet-prefix taking into account how management system 2066 distributes addresses between PE and CE within the subnet. Routing 2067 protocol configuration is done as for the PE, in this example, bgp 2068 peering address is retrieved from subnet prefix and internal 2069 allocation policy, remote AS number is well known. LAN addresses 2070 will be added to the configuration and exported to BGP. This will 2071 permit to produce a plug'n'play configuration for the CE. 2073 Example of generated CE configuration : 2075 interface Loopback10 2076 description "Administration" 2077 ip address 203.0.113.254 255.255.255.255 2078 ! 2079 interface FastEthernet10 2080 description "WAN" 2081 ip address 203.0.113.2 255.255.255.252 <---- Comes from subnet-prefix 2082 ! 2083 interface FastEthernet11 2084 description "LAN" 2085 ip address 192.0.2.254 255.255.255.252 <---- Comes from 2086 customer-lan-connection 2087 ! 2088 router bgp 65000 2089 redistribute static route-map STATIC2BGP <---- Standard SP 2090 configuration 2091 neighbor 203.0.113.1 remote-as 100 <---- Comes from subnet-prefix 2092 and allocated CE ASN 2093 ! 2094 route-map STATIC2BGP permit 10 2095 match tag 10 2096 ! 2097 ip route 198.51.100.0 255.255.255.252 192.0.2.253 tag 10 2098 ip route 198.51.100.4 255.255.255.252 192.0.2.253 tag 10 2099 ip route 198.51.100.8 255.255.255.252 192.0.2.253 tag 10 2101 7. Interaction with Other YANG Modules 2103 As expressed in Section 4, this service module is intended to be 2104 instantiated in management system and not directly on network 2105 elements. 2107 It will be the role of the management system to configure the network 2108 elements. The management system MAY be modular, so the component 2109 instantiating the service model (let's call it service component) and 2110 the component responsible for network element configuration (let's 2111 call it configuration component) MAY be different. 2113 L3VPN-SVC | 2114 service model | 2115 | 2116 +----------------------+ 2117 | Service component | service datastore 2118 +----------------------+ 2119 | 2120 | 2121 +----------------------+ 2122 +----| Config component |-------+ 2123 / +----------------------+ \ Network 2124 / / \ \ Configuration models 2125 / / \ \ 2126 / / \ \ 2127 +++++++ ++++++++ ++++++++ +++++++ 2128 + CEA + ------- + PE A + + PE B + ----- + CEB + Config 2129 +++++++ ++++++++ ++++++++ +++++++ datastore 2131 Site A Site B 2133 In the previous sections, we provided some example of translation of 2134 service provisioning request to router configuration lines as 2135 illustration. In the NetConf/Yang ecosystem, it will be expected 2136 NetConf/YANG to be used between configuration component and network 2137 elements to configure the requested service on these elements. 2139 In this framework, it is expected from standardization to also work 2140 on specific configuration YANG modelization of service components on 2141 network elements. There will be so a strong relation between the 2142 abstracted view provided by this service model and the detailed 2143 configuration view that will be provided by specific configuration 2144 models for network elements. 2146 Authors of this document are expecting definition of YANG models for 2147 network elements on this non exhaustive list of items : 2149 o VRF definition including VPN policy expression. 2151 o Physical interface. 2153 o IP layer (IPv4, IPv6). 2155 o QoS : classification, profiles... 2157 o Routing protocols : support of configuration of all protocols 2158 listed in the document, as well as routing policies associated 2159 with these protocols. 2161 o Multicast VPN. 2163 o Network Address Translation. 2165 o ... 2167 Example of VPN site request at service level using this model : 2169 2170 Site A 2171 VPN1 2172 any-to-any-site 2173 2174 2175 2176 static-address 2177 203.0.113.0/30 2178 2179 2180 static 2181 static 2182 2183 2184 2185 2186 2187 2188 198.51.100.0/30 2189 192.0.2.253 2190 2191 2192 2193 2195 In the service example above, it is expected that the service 2196 component requests to the configuration component of the management 2197 system the configuration of the service elements. If we consider 2198 that service component selected a PE (PE A) as target PE for the 2199 site, the configuration component will need to push the configuration 2200 to PE A. The configuration component will use several YANG data 2201 models to define the configuration to be applied to PE A. The XML 2202 configuration of PE-A may look like this : 2204 2205 2206 eth0 2207 ianaift:ethernetCsmacd 2208 2209 Link to CEA. 2210 2211 2212 2213 203.0.113.1 2214 30 2215 2216 true 2217 2218 2219 2220 2221 2222 VRF_CustA 2223 l3vpn:vrf 2224 VRF for CustomerA 2225 2226 100:1546542343 2227 2228 100:1 2229 100:1 2230 2231 2232 eth0 2233 2234 2235 2236 2237 rt:static 2238 st0 2239 2240 2241 2242 2243 198.51.100.0/30 2244 2245 2246 2247 203.0.113.2 2248 2249 2250 2251 2252 2253 2254 2255 2256 2258 8. YANG Module 2260 file "ietf-l3vpn-svc@2015-06-16.yang" 2262 module ietf-l3vpn-svc { 2263 namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc"; 2265 prefix l3vpn-svc; 2267 import ietf-routing { 2268 prefix "rt"; 2269 } 2271 import ietf-inet-types { 2272 prefix inet; 2273 } 2275 import ietf-yang-types { 2276 prefix yang; 2277 } 2279 organization 2280 "IETF L3SM Working Group"; 2282 contact 2283 "WG List: <mailto:l3sm@ietf.org> 2285 Editor: 2287 "; 2289 description 2290 "The YANG module defines a generic service configuration 2291 model for Layer 3 VPN common across all of the vendor 2292 implementations."; 2294 revision 2015-04-24 { 2295 description " 2296 * Add encryption parameters 2297 * Adding holdtime for BFD. 2298 * Add postal address in location 2299 "; 2300 reference "draft-lstd-l3sm-l3vpn-service-yang-00"; 2301 } 2302 revision 2015-02-05 { 2303 description "Initial revision."; 2304 reference "draft-l3vpn-service-yang-00"; 2305 } 2306 identity management { 2307 description 2308 "Base identity for site management scheme."; 2309 } 2310 identity comanaged { 2311 base management; 2312 description 2313 "Base identity for comanaged site."; 2314 } 2315 identity customer-managed { 2316 base management; 2317 description 2318 "Base identity for customer managed site."; 2319 } 2320 identity provider-managed { 2321 base management; 2322 description 2323 "Base identity for provider managed site."; 2324 } 2326 identity address-allocation-type { 2327 description 2328 "Base identity for address-allocation-type 2329 for PE-CE link."; 2330 } 2331 identity pe-dhcp { 2332 base address-allocation-type; 2333 description 2334 "PE router provides DHCP service to CE."; 2335 } 2336 identity static-address { 2337 base address-allocation-type; 2338 description 2339 "PE-CE addressing is static."; 2340 } 2341 identity slaac { 2342 base address-allocation-type; 2343 description 2344 "Use IPv6 SLAAC."; 2345 } 2347 identity site-availability { 2348 description 2349 "Base identity for site availability."; 2350 } 2351 identity loadsharing { 2352 base site-availability; 2353 description 2354 "Identity for loadsharing site."; 2355 } 2356 identity loadsharing-ibgp { 2357 base loadsharing; 2358 description 2359 "Identity for ECMP ibgp based loadsharing site."; 2360 } 2361 identity loadsharing-eibgp { 2362 base loadsharing; 2363 description 2364 "Identity for ECMP eibgp based loadsharing site."; 2365 } 2366 identity primary-backup { 2367 base site-availability; 2368 description 2369 "Identity for primary-backup site."; 2370 } 2371 identity single { 2372 base site-availability; 2373 description 2374 "Identity for single site."; 2375 } 2376 identity access-availability-type { 2377 description 2378 "base identity for access-availability-type"; 2379 } 2380 identity primary-access { 2381 base access-availability-type; 2382 description 2383 "Identity for primary access type."; 2384 } 2385 identity backup-access { 2386 base access-availability-type; 2387 description 2388 "Identity for backup access type."; 2389 } 2390 identity single-access { 2391 base access-availability-type; 2392 description 2393 "Identity for single access type."; 2394 } 2395 identity loadsharing-access { 2396 base access-availability-type; 2397 description 2398 "Identity for loadsharing access type."; 2399 } 2400 identity site-type { 2401 description 2402 "Base identity for site type."; 2403 } 2404 identity any-to-any-site { 2405 base site-type; 2406 description 2407 "Site in a any to any IPVPN."; 2408 } 2409 identity spoke-site { 2410 base site-type; 2411 description 2412 "Spoke Site in a Hub & Spoke IPVPN."; 2413 } 2414 identity hub-site { 2415 base site-type; 2416 description 2417 "Hub Site in a Hub & Spoke IPVPN."; 2418 } 2420 identity vpn-topology { 2421 description 2422 "Base identity for VPN topology."; 2423 } 2424 identity any-to-any { 2425 base vpn-topology; 2426 description 2427 "Identity for any to any VPN topology."; 2428 } 2429 identity hub-spoke { 2430 base vpn-topology; 2431 description 2432 "Identity for Hub'n'Spoke VPN topology."; 2433 } 2434 identity hub-spoke-disjoint { 2435 base vpn-topology; 2436 description 2437 "Identity for Hub'n'Spoke VPN topology 2438 where Hubs cannot talk between each other."; 2439 } 2441 identity multicast-tree-type { 2442 description 2443 "Base identity for multicast tree type."; 2444 } 2446 identity ssm-tree-type { 2447 base multicast-tree-type; 2448 description 2449 "Identity for SSM tree type."; 2450 } 2451 identity asm-tree-type { 2452 base multicast-tree-type; 2453 description 2454 "Identity for ASM tree type."; 2455 } 2456 identity bidir-tree-type { 2457 base multicast-tree-type; 2458 description 2459 "Identity for BiDir tree type."; 2460 } 2462 identity multicast-rp-discovery-type { 2463 description 2464 "Base identity for rp discovery type."; 2465 } 2466 identity auto-rp { 2467 base multicast-rp-discovery-type; 2468 description 2469 "Base identity for auto-rp discovery type."; 2470 } 2471 identity static-rp { 2472 base multicast-rp-discovery-type; 2473 description 2474 "Base identity for static type."; 2475 } 2476 identity anycast-rp { 2477 base multicast-rp-discovery-type; 2478 description 2479 "Base identity for anycast rp type."; 2480 } 2481 identity bsr-rp { 2482 base multicast-rp-discovery-type; 2483 description 2484 "Base identity for BDR discovery type."; 2485 } 2487 identity routing-protocol-type { 2488 description 2489 "Base identity for routing-protocol type."; 2490 } 2492 identity ospf { 2493 base routing-protocol-type; 2494 description 2495 "Identity for OSPF protocol type."; 2496 } 2498 identity bgp { 2499 base routing-protocol-type; 2500 description 2501 "Identity for BGP protocol type."; 2502 } 2504 identity static { 2505 base routing-protocol-type; 2506 description 2507 "Identity for static routing protocol type."; 2508 } 2510 identity rip { 2511 base routing-protocol-type; 2512 description 2513 "Identity for RIP protocol type."; 2514 } 2516 identity rip-ng { 2517 base routing-protocol-type; 2518 description 2519 "Identity for RIPng protocol type."; 2520 } 2522 identity vrrp { 2523 base routing-protocol-type; 2524 description 2525 "Identity for VRRP protocol type. 2526 This is to be used when LAn are directly connected 2527 to provider Edge routers."; 2528 } 2530 identity direct { 2531 base routing-protocol-type; 2532 description 2533 "Identity for direct protocol type. 2534 ."; 2535 } 2537 identity l4-protocol-type { 2538 description 2539 "Base identity for Layer 4 protocol type."; 2540 } 2542 identity tcp { 2543 base l4-protocol-type; 2544 description 2545 "TCP protocol type."; 2546 } 2547 identity udp { 2548 base l4-protocol-type; 2549 description 2550 "UDP protocol type."; 2551 } 2552 identity icmp { 2553 base l4-protocol-type; 2554 description 2555 "icmp protocol type."; 2556 } 2557 identity icmp6 { 2558 base l4-protocol-type; 2559 description 2560 "icmp v6 protocol type."; 2561 } 2562 identity gre { 2563 base l4-protocol-type; 2564 description 2565 "GRE protocol type."; 2566 } 2567 identity ipip { 2568 base l4-protocol-type; 2569 description 2570 "IPinIP protocol type."; 2571 } 2572 identity hop-by-hop { 2573 base l4-protocol-type; 2574 description 2575 "Hop by Hop IPv6 header type."; 2576 } 2577 identity routing { 2578 base l4-protocol-type; 2579 description 2580 "Routing IPv6 header type."; 2581 } 2582 identity esp { 2583 base l4-protocol-type; 2584 description 2585 "ESP header type."; 2586 } 2587 identity ah { 2588 base l4-protocol-type; 2589 description 2590 "AH header type."; 2592 } 2594 /* Groupings */ 2596 grouping vpn-svc-cfg { 2597 description 2598 "Configuration block for l3vpn svc."; 2600 leaf name { 2601 type string; 2602 description 2603 "Name of the VPN."; 2604 } 2605 leaf id { 2606 type uint32; 2607 description 2608 "VPN identifier. Local administration meaning."; 2609 } 2610 leaf customer-name { 2611 type string; 2612 description 2613 "Name of the customer."; 2614 } 2615 leaf topology { 2616 type identityref { 2617 base vpn-topology; 2618 } 2619 description 2620 "VPN topology."; 2621 } 2623 list cloud-access { 2624 key cloud-identifier; 2626 leaf cloud-identifier { 2627 type string; 2628 description 2629 "Identification of cloud service. Local 2630 admin meaning."; 2631 } 2632 list authorized-sites { 2633 key site-id; 2635 leaf site-id { 2636 type leafref { 2637 path "../../../../sites/site-id"; 2638 } 2639 description 2640 "Site ID."; 2641 } 2642 description 2643 "List of authorized sites."; 2644 } 2645 list denied-sites { 2646 key site-id; 2648 leaf site-id { 2649 type leafref { 2650 path "../../../../sites/site-id"; 2651 } 2652 description 2653 "Site ID."; 2654 } 2655 description 2656 "List of denied sites."; 2657 } 2658 leaf nat-enabled { 2659 type boolean; 2660 description 2661 "Control if NAT is required or not."; 2662 } 2663 leaf customer-nat-address { 2664 type inet:ipv4-address; 2665 description 2666 "NAT address to be used in case of public 2667 or shared cloud. 2668 This is to be used in case customer is providing 2669 the public address."; 2670 } 2671 description 2672 "Cloud access configuration."; 2673 } 2675 container multicast { 2676 leaf-list tree-flavor { 2677 type identityref { 2678 base multicast-tree-type; 2679 } 2680 description 2681 "Type of tree to be used."; 2682 } 2683 container rp { 2684 leaf ipv4-address { 2685 type inet:ipv4-address; 2686 description 2687 "Management address"; 2688 } 2689 leaf ipv6-address { 2690 type inet:ipv6-address; 2691 description 2692 "Management address"; 2693 } 2694 description 2695 "Defines the address of the RendezvousPoint."; 2696 } 2697 leaf rp-discovery { 2698 type identityref { 2699 base multicast-rp-discovery-type; 2700 } 2701 description 2702 "Type of RP discovery used."; 2703 } 2704 leaf-list anycast-rp-location { 2705 type string; 2706 description 2707 "Encodes the location of the RPs in anycast RP 2708 deployment."; 2709 } 2710 description 2711 "Multicast global parameters for the VPN service."; 2712 } 2713 } 2715 /* Main blocks */ 2717 container l3vpn-svc { 2718 list vpn-svc { 2719 key name; 2721 uses vpn-svc-cfg; 2723 description " 2724 List of VPN services. 2725 "; 2726 } 2728 list sites { 2729 key site-id; 2731 leaf template { 2732 type boolean; 2733 default false; 2734 description 2735 "Defines if the site is a real site, 2736 or a configuration template."; 2737 } 2739 leaf site-id { 2740 type string; 2741 description 2742 "Identifier of the site."; 2743 } 2745 leaf native-vpn { 2746 type leafref { 2747 path "../../vpn-svc/name"; 2748 } 2749 description 2750 "Reference to associated VPN."; 2751 } 2753 leaf site-type { 2754 type identityref { 2755 base site-type; 2756 } 2757 description 2758 "Type of site."; 2759 } 2761 leaf apply-template { 2762 type leafref { 2763 path "../../sites/site-id"; 2764 } 2765 description 2766 "It we would be good to ensure that 2767 site-id is template type"; 2768 } 2769 leaf requested-site-start { 2770 type yang:date-and-time; 2771 description 2772 "Optional leaf indicating requested date 2773 and time 2774 when the service at a particular site is 2775 expected 2776 to start"; 2777 } 2779 leaf requested-site-stop { 2780 type yang:date-and-time; 2781 description 2782 "Optional leaf indicating requested date 2783 and time 2784 when the service at a particular site is 2785 expected 2786 to stop"; 2787 } 2789 leaf actual-site-start { 2790 type yang:date-and-time; 2791 description 2792 "Optional leaf indicating actual date 2793 and time 2794 when the service at a particular site 2795 actually 2796 started"; 2797 } 2798 leaf actual-site-stop { 2799 type yang:date-and-time; 2800 description 2801 "Optional leaf indicating actual date 2802 and time 2803 when the service at a particular site 2804 actually 2805 stopped"; 2806 } 2807 container location { 2808 leaf address { 2809 type string; 2810 description 2811 "Address (number and street) 2812 of the site."; 2814 } 2815 leaf zip-code { 2816 type string; 2817 description 2818 "ZIP code of the site."; 2819 } 2820 leaf city { 2821 type string; 2822 description 2823 "City of the site."; 2824 } 2825 leaf country-code { 2826 type string; 2827 description 2828 "Country of the site."; 2829 } 2830 description 2831 "Location of the site."; 2832 } 2834 container site-diversity { 2835 leaf type { 2836 type enumeration { 2837 enum "pop-diverse" { 2838 description 2839 "The access must use another PoP 2840 compared 2841 to other accesses in the same group."; 2842 } 2843 enum "pe-diverse" { 2844 description 2845 "The access must use another PE 2846 compared 2847 to other accesses in the same group."; 2848 } 2849 } 2850 description 2851 "Diversity constraint type."; 2852 } 2854 leaf-list site-group { 2855 type uint32; 2856 description 2857 "IDs of group."; 2858 } 2859 description 2860 "Diversity constraint type."; 2861 } 2863 container security { 2864 leaf apply-template { 2865 type leafref { 2866 path "../../../sites/site-id"; 2867 } 2868 description 2869 "It we would be good to ensure that site-id is 2870 template type"; 2871 } 2872 container authentication { 2873 description 2874 "Authentication parameters"; 2875 } 2876 container encryption { 2877 leaf enabled { 2878 type boolean; 2879 description 2880 "If true, access encryption is required."; 2881 } 2882 leaf layer { 2883 type enumeration { 2884 enum layer2 { 2885 description 2886 "Encryption will occur at layer2."; 2887 } 2888 enum layer3 { 2889 description 2890 "IPSec is requested."; 2891 } 2892 } 2893 description 2894 "Layer on which encryption is applied."; 2895 } 2896 container encryption-profile { 2897 choice profile { 2898 case provider-profile { 2899 leaf profile-name { 2900 type string; 2901 description 2902 "Name of the SP profile 2903 to be applied."; 2904 } 2905 } 2906 case customer-profile { 2907 leaf algorithm { 2908 type string; 2909 description 2910 "Encryption algorithm to 2911 be used."; 2912 } 2913 choice key-type { 2914 case psk { 2915 leaf preshared-key { 2916 type string; 2917 description 2918 "Key coming from 2919 customer."; 2920 } 2921 } 2922 case pki { 2924 } 2925 description 2926 "Type of keys to be used."; 2927 } 2928 } 2929 description 2930 "Choice of profile."; 2931 } 2932 description 2933 "Profile of encryption to be applied."; 2934 } 2935 description 2936 "Encryption parameters."; 2937 } 2938 container access-control-list { 2939 description 2940 "Access control list."; 2941 } 2942 description 2943 "Site specific security parameters."; 2944 } 2946 container availability { 2947 container availability-type { 2948 leaf service-type { 2949 type identityref { 2950 base site-availability; 2951 } 2952 description 2953 "Type of availability, 2954 ex : single, backup, loadsharing"; 2955 } 2956 leaf access-type { 2957 type identityref { 2958 base access-availability-type; 2959 } 2960 description 2961 "Access type within the service."; 2962 } 2963 description 2964 "Availability solution parameters"; 2965 } 2966 leaf loadsharing-type { 2967 type identityref { 2968 base loadsharing; 2969 } 2970 description 2971 "Loadsharing flavor."; 2972 } 2973 description 2974 "Site availability parameters."; 2975 } 2976 container attachment { 2977 leaf apply-template { 2978 type leafref { 2979 path "../../../sites/site-id"; 2980 } 2981 description 2982 "It we would be good to ensure that site-id is 2983 template type"; 2984 } 2985 container bearer { 2986 leaf type { 2987 type string; 2988 description 2989 "Type of bearer Ethernet, DSL, Wireless ... 2990 Operator specific."; 2991 } 2992 leaf bearer-reference { 2993 type string; 2994 description 2995 "This is an internal reference for the 2996 service provider."; 2997 } 2998 description 2999 "Bearer specific parameters. To be augmented."; 3000 } 3001 container connection { 3002 container ipv4 { 3003 leaf address-allocation-type { 3004 type identityref { 3005 base address-allocation-type; 3006 } 3007 description 3008 "Defines how addresses are allocated. 3009 Need to be detailed further."; 3010 } 3011 leaf subnet-prefix { 3012 type inet:ipv4-prefix; 3013 description 3014 "Interco subnet."; 3015 } 3016 description 3017 "IPv4 specific parameters"; 3019 } 3020 container ipv6 { 3021 leaf address-allocation-type { 3022 type string; 3023 description 3024 "Defines how addresses are allocated. 3025 Need to be detailled further."; 3026 } 3027 leaf subnet-prefix { 3028 type inet:ipv6-prefix; 3029 description 3030 "Interco subnet."; 3031 } 3032 description 3033 "IPv6 specific parameters"; 3035 } 3036 list routing-protocols { 3037 key type; 3039 leaf type { 3040 type identityref { 3041 base routing-protocol-type; 3042 } 3043 description 3044 "Type of routing protocol."; 3045 } 3047 container ospf { 3048 when "type = 'ospf'" { 3049 description 3050 "Only applies when protocol is OSPF."; 3051 } 3052 leaf-list address-family { 3053 type identityref { 3054 base rt:address-family; 3055 } 3056 description 3057 "Address family to be activated."; 3058 } 3059 leaf area-address { 3060 type yang:dotted-quad; 3061 description 3062 "Area address."; 3063 } 3064 leaf metric { 3065 type uint16; 3066 description 3067 "Metric of PE-CE link."; 3068 } 3069 list sham-link { 3070 key target-site; 3072 leaf target-site { 3073 type leafref { 3074 path "../../../../../../" 3075 +"../sites/site-id"; 3076 } 3077 description 3078 "Target site for the sham link 3079 connection."; 3080 } 3081 leaf metric { 3082 type uint16; 3083 description 3084 "Metric of the sham link."; 3085 } 3086 description 3087 "Creates a shamlink with another 3088 site"; 3089 } 3090 description 3091 "OSPF specific configuration."; 3092 } 3094 container bgp { 3095 when "type = 'bgp'" { 3096 description 3097 "Only applies when protocol is BGP."; 3098 } 3099 leaf-list address-family { 3100 type identityref { 3101 base rt:address-family; 3102 } 3103 description 3104 "Address family to be activated."; 3105 } 3106 description 3107 "BGP specific configuration."; 3108 } 3109 container static { 3110 when "type = 'static'" { 3111 description 3112 "Only applies when protocol 3113 is static."; 3114 } 3115 leaf-list address-family { 3116 type identityref { 3117 base rt:address-family; 3118 } 3119 description 3120 "Address family to be activated."; 3121 } 3122 description 3123 "Static routing specific configuration."; 3124 } 3125 container rip { 3126 when "type = 'rip'" { 3127 description 3128 "Only applies when protocol is RIP."; 3129 } 3130 leaf-list address-family { 3131 type identityref { 3132 base rt:address-family; 3133 } 3134 description 3135 "Address family to be activated."; 3136 } 3138 description 3139 "RIP routing specific configuration."; 3140 } 3142 container vrrp { 3143 when "type = 'vrrp'" { 3144 description 3145 "Only applies when protocol is VRRP."; 3146 } 3147 leaf-list address-family { 3148 type identityref { 3149 base rt:address-family; 3150 } 3151 description 3152 "Address family to be activated."; 3153 } 3154 description 3155 "VRRP routing specific configuration."; 3156 } 3158 container bfd { 3159 leaf bfd-enabled { 3160 type boolean; 3161 description 3162 "BFD activation"; 3163 } 3164 choice holdtime { 3165 case profile { 3166 leaf profile-name { 3167 type string; 3168 description 3169 "Service provider well 3170 known profile."; 3171 } 3172 description 3173 "Service provider well 3174 known profile."; 3175 } 3176 case fixed { 3177 leaf fixed-value { 3178 type uint32; 3179 units msec; 3180 description 3181 "Expected holdtime expressed 3182 in msec."; 3183 } 3184 } 3185 description 3186 "Choice for holdtime flavor."; 3187 } 3188 description 3189 "Container for BFD."; 3190 } 3191 description 3192 "List of routing protocols used on the site. 3193 Need to be augmented."; 3194 } 3195 description 3196 "Defines connection parameters."; 3197 } 3199 description 3200 "Parameters of the attachement."; 3201 } 3203 container service { 3204 leaf apply-template { 3205 type leafref { 3206 path "../../../sites/site-id"; 3207 } 3208 description 3209 "It we would be good to ensure that site-id is 3210 template type"; 3212 } 3213 container qos { 3214 container qos-classification-policy { 3215 list rules { 3216 key id; 3218 leaf id { 3219 type uint16; 3220 description 3221 "ID of the rule."; 3222 } 3223 container match { 3224 leaf ipv4-src-prefix { 3225 type inet:ipv4-prefix; 3226 description 3227 "Match on IPv4 src address."; 3228 } 3229 leaf ipv6-src-prefix { 3230 type inet:ipv6-prefix; 3231 description 3232 "Match on IPv6 src address."; 3233 } 3234 leaf ipv4-dst-prefix { 3235 type inet:ipv4-prefix; 3236 description 3237 "Match on IPv4 dst address."; 3238 } 3239 leaf ipv6-dst-prefix { 3240 type inet:ipv6-prefix; 3241 description 3242 "Match on IPv6 dst address."; 3243 } 3244 leaf l4-src-port { 3245 type uint16; 3246 description 3247 "Match on layer 4 src port."; 3248 } 3249 leaf l4-dst-port { 3250 type uint16; 3251 description 3252 "Match on layer 4 dst port."; 3253 } 3254 leaf l4-protocol { 3255 type union { 3256 type uint8; 3257 type identityref { 3258 base l4-protocol-type; 3259 } 3261 } 3262 description 3263 "Match on IPv4 protocol field or 3264 IPv6 nextheader field."; 3265 } 3266 description 3267 "Describe flow matching criterions."; 3268 } 3270 leaf target-class-id { 3271 type string; 3272 description 3273 "Identification of the 3274 class of service. 3275 This identifier is internal to 3276 the administration."; 3277 } 3279 description 3280 "List of marking rules."; 3281 } 3282 description 3283 "Need to express marking rules ..."; 3284 } 3285 leaf std-qos-profile { 3286 type string; 3287 description 3288 "QoS profile to be used"; 3289 } 3290 container custom-qos-profile { 3291 list class { 3292 key class-id; 3294 leaf class-id { 3295 type string; 3296 description 3297 "Identification of the 3298 class of service. 3299 This identifier is internal to 3300 the administration."; 3301 } 3302 leaf rate-limit { 3303 type uint8; 3304 units percent; 3305 description 3306 "To be used if class must be rate 3307 limited. Expressed as 3308 percentage of the svc-bw."; 3310 } 3311 leaf priority-level { 3312 type uint8; 3313 description 3314 "Defines the level of the class in 3315 term of priority queueing. 3316 The higher the level is the higher 3317 is the priority."; 3318 } 3319 leaf guaranteed-bw-percent { 3320 type uint8; 3321 units percent; 3322 description 3323 "To be used to define the guaranteed 3324 BW in percent of the svc-bw 3325 available at the priority-level."; 3326 } 3327 description 3328 "List of class of services."; 3329 } 3330 description 3331 "Custom qos profile."; 3332 } 3333 description 3334 "QoS configuration."; 3335 } 3337 leaf svc-input-bandwidth { 3338 type uint32; 3339 units bps; 3340 description 3341 "From the PE perspective, the service input 3342 bandwidth of the connection."; 3343 } 3345 leaf svc-output-bandwidth { 3346 type uint32; 3347 units bps; 3348 description 3349 "From the PE perspective, the service output 3350 bandwidth of the connection."; 3351 } 3352 leaf svc-mtu { 3353 type uint16; 3354 units bytes; 3355 description 3356 "MTU at service level. 3357 If the service is IP, it refers to the IP MTU."; 3359 } 3361 container traffic-protection { 3362 leaf link-local-protection { 3363 type boolean; 3364 description 3365 "Enables protection of PE-CE link."; 3366 } 3367 leaf node-local-protection { 3368 type boolean; 3369 description 3370 "Enables protection against local 3371 PE node failure."; 3372 } 3373 leaf node-global-protection { 3374 type boolean; 3375 description 3376 "Enables protection against remote 3377 PE node failure. 3378 This is also called PIC Edge. 3379 "; 3380 } 3381 description 3382 "Fast reroute service parameters for the site."; 3383 } 3384 container mpls { 3385 leaf signalling-type { 3386 type enumeration { 3387 enum "ldp" { 3388 description 3389 "Use LDP as signalling 3390 protocol between PE and CE."; 3391 } 3392 enum "bgp" { 3393 description 3394 "Use BGP 3107 as signalling 3395 protocol between PE and CE. 3396 In this case, bgp must be also 3397 configured 3398 as routing-protocol. 3399 "; 3400 } 3401 } 3402 description 3403 "MPLS signalling type."; 3404 } 3405 description 3406 "This container is used when customer provides 3407 MPLS based services. 3408 This is used in case of Carrier 3409 Supporting Carrier."; 3410 } 3411 container multicast { 3412 leaf site-type { 3413 type enumeration { 3414 enum receiver-only { 3415 description 3416 "The site has only receivers."; 3417 } 3418 enum source-only { 3419 description 3420 "The site has only sources."; 3421 } 3422 enum source-receiver { 3423 description 3424 "The site has both 3425 sources & receivers."; 3426 } 3427 } 3428 description 3429 "Type of multicast site."; 3430 } 3432 description 3433 "Multicast parameters for the site."; 3434 } 3435 description 3436 "Service parameters on the attachement."; 3437 } 3439 container management { 3440 leaf type { 3441 type identityref { 3442 base management; 3443 } 3444 description 3445 "Management type of the connection."; 3446 } 3447 leaf management-transport { 3448 type identityref { 3449 base rt:address-family; 3450 } 3451 description 3452 "Transport protocol used for management."; 3453 } 3454 leaf address { 3455 type union { 3456 type inet:ipv4-address; 3457 type inet:ipv6-address; 3458 } 3459 description 3460 "Management address"; 3461 } 3463 description 3464 "Management configuration"; 3465 } 3467 container vpn-policy { 3468 container import-policy { 3469 leaf-list vpn { 3470 type leafref { 3471 path "../../../../vpn-svc/name"; 3472 } 3473 description 3474 "Reference to an IPVPN."; 3475 } 3476 description 3477 "Import policy."; 3478 } 3479 container export-policy { 3480 list entries { 3481 key id; 3483 leaf id { 3484 type uint32; 3485 description 3486 "Unique identifier for 3487 the export policy entry."; 3488 } 3489 container lan-prefixes { 3490 list ipv4-lan-prefixes { 3491 key lan; 3493 leaf lan { 3494 type inet:ipv4-prefix; 3495 description 3496 "Lan prefixes."; 3497 } 3498 description " 3499 List of LAN prefixes for the site. 3500 "; 3501 } 3502 list ipv6-lan-prefixes { 3503 key lan; 3505 leaf lan { 3506 type inet:ipv6-prefix; 3507 description 3508 "Lan prefixes."; 3509 } 3510 description " 3511 List of LAN prefixes for the site. 3512 "; 3513 } 3514 description 3515 "LAN prefixes from the customer."; 3516 } 3517 leaf-list lan-tag { 3518 type string; 3519 description 3520 "List of lan-tags to be matched."; 3521 } 3522 leaf-list vpn { 3523 type leafref { 3524 path "../../../../../vpn-svc/name"; 3525 } 3526 description 3527 "Reference to an IPVPN."; 3528 } 3529 description 3530 "List of entries for export policy."; 3531 } 3532 description 3533 "Export policy."; 3535 } 3536 description 3537 "Define attachment to VPNs that are not the 3538 attachment VPN. 3539 Use to permit multiple VPN sites."; 3540 } 3542 container maximum-routes { 3543 list address-family { 3544 key af; 3546 leaf af { 3547 type identityref { 3548 base rt:address-family; 3549 } 3550 description 3551 "Address-family."; 3552 } 3553 leaf maximum-routes { 3554 type uint32; 3555 description 3556 "Maximum prefixes the VRF can 3557 accept for this 3558 address-family."; 3559 } 3560 description 3561 "List of address families."; 3562 } 3564 description 3565 "Define maximum-routes for the VRF."; 3566 } 3568 container customer-specific-information { 3569 leaf name { 3570 type string; 3571 description 3572 "Name of the customer router."; 3573 } 3574 leaf autonomous-system { 3575 type uint32; 3576 description 3577 "AS number."; 3578 } 3579 leaf interface { 3580 type string; 3581 description 3582 "Interface reference of the access."; 3583 } 3584 list customer-lan-connection { 3585 key "address"; 3586 leaf address { 3587 type union { 3588 type inet:ipv4-address; 3589 type inet:ipv6-address; 3590 } 3591 description 3592 "Address given by the customer on its LAN 3593 for the SP router."; 3594 } 3595 leaf lan-protocol { 3596 type identityref { 3597 base rt:address-family; 3598 } 3599 description 3600 "Transport protocol used on LAN."; 3601 } 3602 description 3603 "List of customer LAN to be connected 3604 directly on the CE."; 3605 } 3606 container cascaded-lan-prefixes { 3607 list ipv4-lan-prefixes { 3608 key lan; 3610 leaf lan { 3611 type inet:ipv4-prefix; 3612 description 3613 "Lan prefixes."; 3614 } 3615 leaf lan-tag { 3616 type string; 3617 description 3618 "Internal tag to be used in vpn 3619 policies."; 3620 } 3621 leaf next-hop { 3622 type inet:ipv4-address; 3623 description 3624 "Nexthop address to use at customer 3625 side."; 3626 } 3627 description " 3628 List of LAN prefixes for the site. 3629 "; 3630 } 3631 list ipv6-lan-prefixes { 3632 key lan; 3634 leaf lan { 3635 type inet:ipv6-prefix; 3636 description 3637 "Lan prefixes."; 3638 } 3639 leaf lan-tag { 3640 type string; 3641 description 3642 "Internal tag to be used in vpn policies."; 3643 } 3644 leaf next-hop { 3645 type inet:ipv6-address; 3646 description 3647 "Nexthop address to use at customer side."; 3648 } 3649 description " 3650 List of LAN prefixes for the site. 3651 "; 3652 } 3653 description 3654 "LAN prefixes from the customer."; 3655 } 3657 description 3658 "Customer premise configuration."; 3659 } 3661 description "List of sites."; 3662 } 3664 description 3665 "Main container for L3VPN service configuration."; 3666 } 3668 } 3669 3671 9. To do list / Open questions / Open issues 3673 Open questions : 3675 o Do we need to handle service chaining for the L3VPN service ? 3677 Open issues : 3679 o 3681 TODO : 3683 o Security items 3685 o Bearer details 3687 o ... 3689 10. Security Considerations 3691 TBD. 3693 11. Contributors 3695 12. Acknowledgements 3697 Thanks to Qin Wu, Maxim Klyus, Luis Miguel Contreras, Gregory Mirsky, 3698 Zitao Wang, Jing Zhao, and Andrew Leu for the contributions to the 3699 document. 3701 13. IANA Considerations 3703 TBD. 3705 14. Normative References 3707 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3708 Requirement Levels", BCP 14, RFC 2119, March 1997. 3710 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 3711 Provider-Provisioned Virtual Private Networks (PPVPNs)", 3712 RFC 4110, July 2005. 3714 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 3715 Networks (VPNs)", RFC 4364, February 2006. 3717 [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the 3718 Provider/Customer Edge Protocol for BGP/MPLS IP Virtual 3719 Private Networks (VPNs)", RFC 4577, June 2006. 3721 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 3722 Address Autoconfiguration", RFC 4862, September 2007. 3724 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 3725 Network Configuration Protocol (NETCONF)", RFC 6020, 3726 October 2010. 3728 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 3729 Bierman, "Network Configuration Protocol (NETCONF)", RFC 3730 6241, June 2011. 3732 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 3733 VPNs", RFC 6513, February 2012. 3735 Appendix A. Example: NETCONF Reply 3737 This section gives an example of a reply to the NETCONF request 3738 for a device that implements the data model defined in this document. 3739 The example is written in XML. 3741 Authors' Addresses 3743 Stephane Litkowski 3744 Orange Business Service 3746 Email: stephane.litkowski@orange.com 3748 Rob Shakir 3749 BT 3751 Email: rob.shakir@bt.com 3753 Luis Tomotaki 3754 Verizon 3756 Email: luis.tomotaki@verizon.com 3758 Kevin D'Souza 3759 ATT 3761 Email: kd6913@att.com