idnits 2.17.1 draft-sun-opsawg-sdwan-service-model-01.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 5 instances of too long lines in the document, the longest one being 28 characters in excess of 72. ** The abstract seems to contain references ([RFC4110]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 564 has weird spacing: '...rt-name str...' == Line 573 has weird spacing: '...rw name str...' == Line 630 has weird spacing: '...-system uin...' == Line 635 has weird spacing: '...ext-hop ine...' == Line 658 has weird spacing: '...-system uin...' == (2 more instances...) -- The document date (October 21, 2018) is 2014 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC6241' is mentioned on line 1700, but not defined == Missing Reference: 'RFC8040' is mentioned on line 1700, but not defined == Missing Reference: 'RFC6242' is mentioned on line 1702, but not defined == Missing Reference: 'RFC5246' is mentioned on line 1704, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Missing Reference: 'RFC3688' is mentioned on line 1721, but not defined == Unused Reference: 'I-D.ietf-i2nsf-sdn-ipsec-flow-protection' is defined on line 1796, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4026 ** Downref: Normative reference to an Informational RFC: RFC 4664 ** Downref: Normative reference to an Informational RFC: RFC 6071 == Outdated reference: A later version (-01) exists of draft-carrel-ipsecme-controller-ike-00 == Outdated reference: A later version (-03) exists of draft-dukes-spring-sr-for-sdwan-00 == Outdated reference: A later version (-14) exists of draft-ietf-i2nsf-sdn-ipsec-flow-protection-02 Summary: 6 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations and Management Area Working Group Q. Sun 3 Internet-Draft H. Xu 4 Intended status: Standards Track China Telecom 5 Expires: April 24, 2019 B. Wu 6 Q. Wu 7 Huawei 8 October 21, 2018 10 A YANG Data Model for SD-WAN VPN Service Delivery 11 draft-sun-opsawg-sdwan-service-model-01 13 Abstract 15 This document defines a SD-WAN VPN service model to enable a Service 16 Provider to deliver SD-WAN VPN services to its customers by 17 provisioning the CE devices on behalf of the customer. This document 18 is based on provider-provisioned CE-based VPNs as described in 19 [RFC4110]. 21 This model provides an abstracted view of the SD-WAN VPN service 22 configuration components, and is intended to be instantiated at the 23 management system to deliver the overall service. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 24, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. High Level overview of SD-WAN VPN . . . . . . . . . . . . . . 5 63 3. Design of the Data Model . . . . . . . . . . . . . . . . . . 7 64 3.1. SD-WAN VPN . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.1.1. Security . . . . . . . . . . . . . . . . . . . . . . 8 66 3.1.2. Policy templates . . . . . . . . . . . . . . . . . . 8 67 3.2. Site . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.3. SubVPNs . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 3.3.1. Policies . . . . . . . . . . . . . . . . . . . . . . 11 70 3.3.1.1. Path selection policies . . . . . . . . . . . . . 11 71 3.3.1.2. QoS bandwidth policies . . . . . . . . . . . . . 11 72 3.3.1.3. Traffic filter . . . . . . . . . . . . . . . . . 12 73 3.4. Internet access . . . . . . . . . . . . . . . . . . . . . 12 74 3.5. Interworking with conventional VPN . . . . . . . . . . . 12 75 4. Modules Tree Structure . . . . . . . . . . . . . . . . . . . 12 76 5. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 16 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 79 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 80 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 37 83 10.2. Informative References . . . . . . . . . . . . . . . . . 38 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 86 1. Introduction 88 The conventional VPN, such as BGP/MPLS IP VPNs [RFC4364], Ethernet 89 VPN [RFC4664] have delivered promised connectivity in terms of 90 security, mutlicast and Quality of Service. These VPNs are 91 categorized as PE-based Provider provisioned VPN. 93 By comparison, the SD-WAN is a CE-based VPN which is sitting on top 94 of the PE based Provider provisioned VPN or Internet. A CE-based VPN 95 has many benefit similarly with Network Virtualization Overlays 96 (nvo3) [RFC7364], which uses an overlay-based approach to provide the 97 flexibility of adding, removing, or moving services within the 98 physical infrastructure, without dependence of the underlay network. 100 This draft aims at providing a common understanding of how the 101 corresponding SD-WAN VPN service is to be deployed. But there is no 102 standard SD-WAN specification defined and SD-WAN VPN has more 103 functionality than the basic CE-based VPN service described in the 104 L3VPN framework document [RFC4110]. This service model defines the 105 following main components which is also reflected in other SD-WAN 106 work in IETF: 108 o Multiple accesses: The CE could connect to additional Internet 109 access, including fiber, cable, DSL-based, WiFi, or 4G/Long Term 110 Evolution (LTE) access, which implies wider reachability and 111 shorter provisioning cycles. It can also use MPLS connectivity 112 defined in [RFC4364] or [RFC4664] as well to take advantage of 113 better performance. SR For SDWAN [I-D.dukes-spring-sr-for-sdwan] 114 assumes a CE of SD-WAN could connect to Internet or MPLS underlay 115 network, so underlay network could offer SRv6 or SR-MPLS TE policy 116 path for different flows classified by the CE on enterprise site. 118 o Fine granularity isolation: Beside basic VPN service, a customer 119 may need to maintain fine granularity isolation inside one VPN 120 connectivity. Therefore, multiple subVPN could be set up for each 121 separate virtual network. Each virtual network could have its own 122 topology, addressing scheme and policies. Augmenting RFC 4364 Tec 123 hnology to Provide Secure Layer L3VPNs over Public Infrastructure 124 provides a L3VPN extension to implement this service. 126 o Policy based traffic forwarding: SD-WAN VPN can provide optimizing 127 forwarding from a network scope and deploy service nodes as 128 needed. Specifically,it can apply policies to prioritize traffic 129 for diverse applications used in enterprises, such as VoIP 130 calling, videoconferencing, streaming media etc. depending 131 different business needs. SR For SDWAN 132 [I-D.dukes-spring-sr-for-sdwan] assumes that a CE of SD-WAN could 133 classify ingress traffic ( e.g. L3-L7 flow classification), 134 monitor the flow state and steer the flow to different SR path, so 135 underlay network only needs maintaining SRTE policies at the edge 136 without holding any per-SDWAN-flow state in the core of its 137 network. 139 This draft specifies SD-WAN VPN service YANG model. This model can 140 be used as a input to automated control and configuration 141 applications to manage SD-WAN VPN services. 143 1.1. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC2119 [RFC2119]. 149 1.2. Definitions 151 CE Device: Customer Edge Device , as per Provider Provisioned VPN 152 Terminology [RFC4026] . 154 PE Device: Provider Edge Device, as per Provider Provisioned VPN 155 Terminology [RFC4026] 157 CE-based VPN: Refers to Provider Provisioned VPN Terminology 158 [RFC4026] 160 PE-Based VPNs: Refers to Provider Provisioned VPN Terminology 161 [RFC4026] 163 SD-WAN:An automated, programmatic approach to managing enterprise 164 network connectivity and circuit usage. It extends software-defined 165 networking (SDN) into an application that businesses can use to 166 quickly create a smart "hybrid WAN"- a WAN that comprises business- 167 grade IP VPN, broadband Internet, and wireless services. SD-WAN is 168 also deemed as extended CE-based VPN. 170 Underlay network: The network that provides the connectivity among 171 SD-WAN VPN sites and that the customer network packets are tunneled 172 over. The underlay network does not need to be aware that it is 173 carrying overlay customer network packets. Addresses on the underlay 174 network appear as "outer addresses" in encapsulated overlay packets. 175 In general, the underlay network can use a completely different 176 protocol (and address family) from that of the overlay network. 178 Overlay network: A virtual network in which the separation of 179 customer networks is hidden from the underlying physical 180 infrastructure. That is, the underlying transport network does not 181 need to know about customer separation to correctly forward traffic. 182 IPsec tunnels [RFC6071] is an example of an L3 overlay network. 184 SubVPN:A subVPN provides fine granularity isolation inside one VPN 185 connectivity. Therefore, multiple subVPN could be set up for each 186 separate virtual network. Each virtual network could have its own 187 topology, addressing scheme and policies.YANG Data Model for L3VPN 188 Service Delivery [RFC8299] has specified same concept. 190 2. High Level overview of SD-WAN VPN 192 An example of SD-WAN VPN network architecture is presented in figure 193 1. 195 +-------------+ 196 +------------+ | +---+ | 197 | Controller +----+ | |TS | | Legend:Tenant System 198 +------------+ | | +---+ | 199 | | | site3| 200 | | +--+--+ | 201 +--|---|CE 4 | | 202 | | +--+--+ | 203 | +-------------+ 204 | | 205 +------------------- ----+ 206 | ----- | 207 +---------------+ / MPLS \ +-----------------+ 208 | | | | WAN |__| | | 209 | | | /\ /\ \ +--+--+ | 210 | | | / +-----+ \ |\|CE 1 +-+ | 211 | +---+ +----++|/ \|/+--+--+ | +---+| 212 | |TS +--+ CE 3|| \ +--+TS || 213 | +---+ +-----+| ------ /|\+--+--+ | +---+| 214 | | |\ /Internet\ / |/|CE 2 +-+ | 215 | | | --| WAN |__/ +--+--+ | 216 | site 2| | \ / | site 1 | 217 +---------------+ ------ +-----------------+ 218 | | 219 | +-------------+ 220 | | +----+ | 221 +----|---+ CE5| | 222 | +----+ | 223 |site 4| | 224 | | | 225 | +---+ | 226 | |TS | | 227 | +---+ | 228 +-------------+ 230 figure 1 232 As shown in figure 1, an SD-WAN network is usually composed of a set 233 of sites and network connectivity services between sites or within 234 each site. Within each site, a CE is connected with customer's 235 network on one side, and also is connected to Internet WAN or MPLS 236 WAN or both on the other side. Customer's network, represented by 237 the connection between TS and CE, could be L2 or L3 network. 239 Internet WAN provides ordinary IP connectivity via access network 240 like Broadband access or LTE access. MPLS WAN refers to conventional 241 MPLS VPN network. While a CE attaches to a conventional MPLS VPN PE 242 router, then the CE appears to the conventional PE to be a CE router. 243 Additionally, a site could deploy one or more CE to improve 244 availability. 246 The establishment of the SD-WAN VPN is done at each CE device, making 247 use of different IP tunneling options (e.g., Generic Routing 248 Encapsulation (GRE), and IPsec) and [I-D.ietf-l3vpn-ce-based] 249 describes a IPSEC based architecture to provide secure connectivity 250 between sites. Either Internet WAN or MPLS WAN is regarded as 251 underlay of the tunneling, the communication among Customer's network 252 in the four sites, which also known as the overlay network, does not 253 depend on the underlay network. 255 In some cases, other than connectivity among the sites, the subset of 256 sites could also need to provide Internet connectivity, cloud network 257 connectivity or conventional MPLS VPN connectivity. 259 In the example, only four sites are shown, in actual deployment, 260 thousands of sites could be implemented and new services need to 261 bring up rapidly, it is therefore critical to automate the 262 configuration of SD-WAN services. 264 Inside one VPN service, there is a need to further set up mutiple 265 subVPNs based on different security or performance requirements, such 266 as: 268 o Separation of lines of businesses or communication between the 269 affiliates regardless of location 271 o Separation of guest WiFi access for clients and partners 273 o Isolating on-demand development and test labs that span multiple 274 locations 276 [I-D.rosen-bess-secure-l3vpn] describes similar use case, and 277 provides an L3VPN augmentation to implement it. An example of subVPN 278 is shown in figure 2 below. 280 +---------+ 281 |subVPN 1| 282 +----+----+ 283 | 284 +--+--+ 285 |CE 4 | 286 +--+--+ 287 | 288 | +---------+ 289 ----- +-----+subVPN 1| 290 / Private\ | +---------+ 291 +---------+ | WAN |_ | +---------+ 292 |subVPN 1 +----+ /\ /\ \ +-----+ +-----+subVPN 2| 293 +---------+ | / +-----+ \ \|CE 1 +--+ +---------+ 294 +---------+ +-+---+ / \ /+-----+ | 295 |subVPN 2+--+ CE 3|/ / | +---------+ 296 +---------+ +-+---+\ ------ / \+-----+ +-----+subVPN 3| 297 +---------+ | \_ / Public\ / /|CE 2 +--+ +---------+ 298 |subVPN 3+----+ | WAN |__/ +-----+ | +---------+ 299 +---------+ \ / +---- +subVPN 4| 300 ------ +---------+ 301 | 302 | 303 +----+ 304 | CE5| 305 +----+ 306 | 307 | 308 +-----+---+ 309 |subVPN 4| 310 +---------+ 312 figure 2 314 3. Design of the Data Model 316 For a SD-WAN VPN to be established under the SP's control, the VPN 317 customer informs the Service Provider of which sites should become 318 part of the considered VPN and what the requested topology of subVPN 319 should look like. The SP then configures and updates the service 320 base on a service model, and then provisions and manages the 321 customer's VPN. 323 This document defines three containers as follows, representing the 324 three categories of parameters of the Customer's VPN. 326 1. sdwan-vpn: This container includes general service parameters and 327 templates. 329 2. sites: This list is used to indicate sites that are involved in 330 different geographic locations. 332 3. subvpns: This list is to specify the characteristics of a subVPN, 333 and which logical access of the customer network is connected. 335 3.1. SD-WAN VPN 337 The "sdwpn-vpn" list item contains global configuration of a SD-WAN 338 VPN service. 340 The "vpn-id" provided in the vpn-service list refers to an internal 341 reference for this VPN service, while the customer name refers to a 342 more explicit reference to a customer. 344 A WAN transport network list is used to describe different WAN 345 network information to specify which links are reachable. In many 346 cases, enterprise customers could have business relationship with 347 multiple WAN network services providers for example broadband 348 internet service and MPLS VPN service. And a WAN transport provider 349 may not be the same of SD-WAN VPN service provider. 351 3.1.1. Security 353 A customer site could connect to MPLS WAN or Internet WAN and the 354 IPsec VPN discussed earlier which offers security service of the 355 authentication and encryption could be used in both connection. As 356 the MPLS WAN is considered to be sufficiently secure, the packets 357 traversing it may not need to be encrypted if it is not sensitive to 358 security. Therefore, the underlay tunneling could be encrypted or 359 not encrypted. 361 When a customer requests encryption service, the security parameters 362 could be specified. The security container is used to specify the 363 parameters such as encryption algorithm and preshared key for each 364 customer. Other key-management methodologies (e.g., PKI) may be 365 added through augmentation. In addition to common IPSEC 366 management,SDN-based IPsec Flow Protection 367 [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]and IPsec Key Exchange 368 using a Controller [I-D.carrel-ipsecme-controller-ike] are two new 369 controller based methods to optimize IPSEC process to better 370 management in SDN context. 372 3.1.2. Policy templates 374 The policy templates consist of application group, classification 375 profile and qos profile, which would be used by all the subVPNs. 377 The "application-group" container is used to describe all the 378 application categories, e.g. VOIP, email, games etc. 380 The "classification-profile" container defines flow classification 381 rules to be handled and it has a rule list and the corresponding flow 382 class name. This draft borrows the flow classification profile 383 defined in [RFC8299] to specify flow classification criteria. The 384 flow classification rule are supposed to be used together with other 385 policies including path-selection-policy, QoS policy and traffic 386 filter policy. 388 The "qos-profile" is used to specify the bandwidth requirements for a 389 certain flow or other criteria. 391 3.2. Site 393 A site represents a customer office located at a specific location. 394 The "sites" container is to specify three main information: 396 o Site information: General information includes site-id, site 397 location address 399 o Device information: A site could have one or more CE devices. 400 Every device participating in a VPN is to be pre-provisioned with 401 the necessary configuration information that enables it to 402 establish a secure communication path with the SD-WAN 403 controller.The device could be posted to customer for self 404 install. A customer needs to specify what kind of device looks 405 like. 407 o Transport network port: The transport-network-port container is 408 used to specify underlay WAN network link parameters. A "site" is 409 composed of at least one "transport-network" and, in the case of 410 multihoming, may have multiple transport network points. 412 +---------------------------------+ 413 | site | 414 | | | | | | 415 | | | | | | 416 | TNP1 TNP2 TNP3 TNP4 | 417 | +--------+ +--------+ | 418 | | | | | | 419 | |Device 1| |Device 2| | 420 | +--------+ +--------+ | 421 +---------------------------------+ 422 Legend: TNP (Transport Network Port) 424 figure 3 426 The transport-network consists of the following categories of 427 parameters: 429 o Access type: defines requirements of the attachment (below Layer 430 3)bearer type including Ethernet, LTE, DSL. 432 o IP Connection: defines Layer 3 parameters of the attachment 434 o Routing protocol: includes OSPF, BGP or static routing. 436 o Bandwidth: specifies the bandwidth of the attachment, including 437 inbound and outbound traffic bandwidth. 439 3.3. SubVPNs 441 The "subVPN" is a container directly under the "sdwan-vpn-svc" and it 442 is used to represent logical networks in a particular enterprise SD- 443 WAN network. Each subVPN is associated with a distinct set of 444 logical accesses that is (are) specific to the given subVPN. This 445 subVPN could define its own addressing and routing protocol. 447 Each subVPN has its own service topology. The type of VPN service 448 topology is required for configuration. Our proposed model supports 449 any-to-any, Hub and Spoke (where Hubs can exchange traffic). By 450 default, the any-to-any VPN service topology is used. New topologies 451 could be added via augmentation. 453 The "logical-access" list under the "subVPNs" is used to represent 454 one or more customer logical accesses attached from different sites 455 belonged to a subVPN. The list is composed of VLAN , IP connection 456 and routing protocol parameters exposed by the customer networks. 458 Based on the requested VPN service topology and the logical access 459 list, the overlay connectivity could be set up among sites over 460 underlay networks. 462 In the figure below, a subVPN constructed for a customer spanning 463 three sites for specified network traffic. 465 a subVPN | Logical 466 | Access 1 467 + 468 +--+--+ 469 |site3| 470 +--X--+ 471 / \ 472 / \ 473 / \ Logical 474 / \ Access 1 475 +-----+/ \+------+ +-------- 476 -------+---+site2+-----------|site 1+-+ 477 Logical +-----+ +------+ +-------- 478 Access 1 Logical 479 Access 2 481 figure 4 483 3.3.1. Policies 485 The "policies" container under the "subVPN" list is used contain all 486 the policies defined in a subVPN service. 488 3.3.1.1. Path selection policies 490 The path-selection-policy container is under policies container, and 491 it has the following parameters: 493 o Flow classification rule. 495 o Traffic SLA profile, including delay, jitter and loss sub 496 parameters. 498 o Primary and secondary path. 500 Path selection policy is an ordered list. For the traffic specified 501 by the flow classification rule, traffic SLA profile related status 502 will be collected and based on the measurement result calculated from 503 the collected information, primary path or secondary path will be 504 selected. 506 3.3.1.2. QoS bandwidth policies 508 The qos-bandwidth policy container is used to describe parameter to 509 guarantee bandwidth for specific traffic flowing through a subVPN 510 connection. It has three categories parameters, including priority, 511 DSCP parameters, traffic rate limit (CAR traffic policy or traffic 512 shaping) and bandwidth represented by percentage value or absolute 513 value. 515 3.3.1.3. Traffic filter 517 Traffic filter is a class of security policy used to filter flow for 518 each subVPN. 520 3.4. Internet access 522 In many VPNs, VPN will need to both access the public Internet as 523 well as to access other sites within the same VPN. 525 The "internet-access" container contains internet access option and 526 Internet-gateway-IP list. And Internet-gateway-IP is only used for 527 the central Internet access case. A central internet access means 528 traffic from different sites aggregates to central Internet access 529 gateway and forwards via the gateway. An internet access service can 530 include Network Address Translation (NAT) to enable the customer to 531 use private IP addresses within their networks. 533 In addition, each site could have its own Internet access links. In 534 case of local break-out for Internet access, traffic from specific 535 site could access the internet directly by setting access option as 536 local. 538 In Implementation, service provider could combine two options to 539 fulfill customer needs. 541 3.5. Interworking with conventional VPN 543 In some cases, there is a need that certain SD-WAN subVPNs 544 communicate with conventional VPNs. An interworking-gateway allows 545 sites interconnected via the MPLS VPN to communicate with sites 546 interconnected via SD-WAN VPN over the Internet. A interworking- 547 gateway or several gateways could be specified to serve this 548 requirement. 550 The "vpn-interworking" container contains "interworking-gateway-IP" 551 used to connect a specific subVPN located at a site to the MPLS VPN 552 network. 554 4. Modules Tree Structure 556 This document defines sd-wan-vpn yang data model. 558 module: ietf-sdwan-vpn-svc 559 +--rw sdwan-vpn-svc 560 +--rw sdwan-vpn* [vpn-id] 561 +--rw vpn-id svc-id 562 +--rw customer-name? svc-id 563 +--rw wan-transport-networks* [wan-transport-name] 564 | +--rw wan-transport-name string 565 | +--rw wan-transport-type? identityref 566 +--rw security 567 | +--rw algorithm? string 568 | +--rw preshared-key? string 569 +--rw application-group* [group-name] 570 | +--rw group-name string 571 | +--rw application-name* string 572 +--rw classification-profile* [name] 573 | +--rw name string 574 | +--rw rule* [id] 575 | +--rw id string 576 | +--rw (match-type)? 577 | +--:(match-flow) 578 | | +--rw match-flow 579 | | +--rw dscp? inet:dscp 580 | | +--rw dot1p? uint8 581 | | +--rw ipv4-src-prefix? inet:ipv4-prefix 582 | | +--rw ipv6-src-prefix? inet:ipv6-prefix 583 | | +--rw ipv4-dst-prefix? inet:ipv4-prefix 584 | | +--rw ipv6-dst-prefix? inet:ipv6-prefix 585 | | +--rw l4-src-port? inet:port-number 586 | | +--rw l4-src-port-range 587 | | | +--rw lower-port? inet:port-number 588 | | | +--rw upper-port? inet:port-number 589 | | +--rw l4-dst-port? inet:port-number 590 | | +--rw l4-dst-port-range 591 | | | +--rw lower-port? inet:port-number 592 | | | +--rw upper-port? inet:port-number 593 | | +--rw protocol-field? union 594 | +--:(match-application-group) 595 | +--rw match-application-group? string 596 +--rw qos-profile* [name] 597 | +--rw name string 598 | +--rw bd-limit-type? identityref 599 | +--rw percent 600 | | +--rw width-percent? uint32 601 | +--rw value 602 | +--rw cir? uint32 603 | +--rw pir? uint32 604 +--rw sites 605 | +--rw site* [site-id] 606 | +--rw site-id svc-id 607 | +--rw location* [email] 608 | | +--rw email string 609 | | +--rw postcode? string 610 | | +--rw address? string 611 | +--rw device* [name] 612 | +--rw name string 613 | +--rw type? string 614 | +--rw transport-network-port* [name] 615 | +--rw name string 616 | +--rw access-type? identityref 617 | +--rw ip-connection 618 | | +--rw type? identityref 619 | | +--rw static 620 | | +--rw customer-addr? inet:ip-address 621 | | +--rw prefix? inet:ip-prefix 622 | | +--rw provider-addr? inet:ip-address 623 | +--rw routing-protocol* [type] 624 | | +--rw type identityref 625 | | +--rw ospf 626 | | | +--rw address-family* address-family 627 | | | +--rw area-address yang:dotted-quad 628 | | | +--rw metric? uint16 629 | | +--rw bgp 630 | | | +--rw autonomous-system uint32 631 | | | +--rw address-family* address-family 632 | | +--rw static 633 | | +--rw ip-lan-prefixes* [lan next-hop] 634 | | +--rw lan inet:ip-prefix 635 | | +--rw next-hop inet:ipv4-address 636 | | +--rw priority? uint16 637 | +--rw bandwidth 638 | +--rw input-bandwidth? uint64 639 | +--rw output-bandwidth? uint64 640 | +--rw mtu? uint16 641 +--rw subvpn* [subvpn-id] 642 +--rw subvpn-id svc-id 643 +--rw topology? identityref 644 +--rw logical-access* [site-id] 645 | +--rw site-id 646 -> /sdwan-vpn-svc/sdwan-vpn/sites/site/site-id 647 | +--rw site-role? identityref 648 | +--rw vlan-tag? uint16 649 | +--rw ip-address? inet:ip-address 650 | +--rw ip-prefix? inet:ip-prefix 651 | +--rw routing-protocol* [type] 652 | +--rw type identityref 653 | +--rw ospf 654 | | +--rw address-family* address-family 655 | | +--rw area-address yang:dotted-quad 656 | | +--rw metric? uint16 657 | +--rw bgp 658 | | +--rw autonomous-system uint32 659 | | +--rw address-family* address-family 660 | +--rw static 661 | +--rw ip-lan-prefixes* [lan next-hop] 662 | +--rw lan inet:ip-prefix 663 | +--rw next-hop inet:ipv4-address 664 | +--rw priority? uint16 665 +--rw policies 666 +--rw path-selection-policy* [name] 667 | +--rw name string 668 | +--rw rule* [rule-id] 669 | +--rw rule-id string 670 | +--rw priority? uint32 671 | +--rw classification-name? 672 -> /sdwan-vpn-svc/sdwan-vpn/classification-profile/name 673 | +--rw traffic-sla-profile* [name] 674 | | +--rw name string 675 | | +--rw latency? uint32 676 | | +--rw jitter? uint32 677 | | +--rw packet-loss-rate? uint32 678 | +--rw transport-network-primary? string 679 | +--rw transport-network-sencondry? string 680 +--rw qos-bandwidth-policy* [name] 681 | +--rw name string 682 | +--rw priorty? uint32 683 | +--rw qos 684 | +--rw classification-name? 685 -> /sdwan-vpn-svc/sdwan-vpn/classification-profile/name 686 | +--rw qos-profile-name? 687 -> /sdwan-vpn-svc/sdwan-vpn/qos-profile/name 688 +--rw traffic-filter* [site-id] 689 | +--rw site-id 690 -> /sdwan-vpn-svc/sdwan-vpn/sites/site/site-id 691 | +--rw classification-name? 692 -> /sdwan-vpn-svc/sdwan-vpn/classification-profile/name 693 | +--rw direction? identityref 694 | +--rw action? identityref 695 +--rw internet-access 696 | +--rw access-option? uint32 697 | +--rw internet-gateway-ip* inet:ip-address 698 | +--rw nat? uint32 699 | +--rw nat44-ip-addr? inet:ip-address 700 +--rw vpn-interworking 701 +--rw site* 702 -> /sdwan-vpn-svc/sdwan-vpn/sites/site/site-id 704 5. YANG Modules 706 file "ietf-sdwan-vpn-svc@2018-09-24.yang" 708 module ietf-sdwan-vpn-svc { 709 yang-version 1.1; 710 namespace "urn:ietf:params:xml:ns:yang:ietf-sdwan-vpn-svc"; 711 prefix sdwan-vpn-svc; 713 import ietf-inet-types { 714 prefix inet; 715 } 716 import ietf-yang-types { 717 prefix yang; 718 } 720 organization 721 "IETF foo Working Group."; 722 contact 723 "WG List: foo@ietf.org 724 Editor: "; 725 description 726 "The YANG module defines a generic service configuration 727 model for SD-WAN VPN."; 729 revision 2018-09-25 { 730 description 731 "Initial revision"; 732 reference "A YANG Data Model for SD-WAN VPN."; 733 } 735 typedef svc-id { 736 type string; 737 description 738 "Type definition for servicer identifier"; 739 } 741 typedef address-family { 742 type enumeration { 743 enum ipv4 { 744 description 745 "IPv4 address family."; 746 } 747 enum ipv6 { 748 description 749 "IPv6 address family."; 750 } 751 } 752 description 753 "Defines a type for the address family."; 754 } 756 identity vpn-topology { 757 description 758 "Base identity for vpn topology."; 759 } 761 identity any-to-any { 762 base vpn-topology; 763 description 764 "Identity for any-to-any VPN topology."; 765 } 767 identity hub-spoke { 768 base vpn-topology; 769 description 770 "Identity for Hub-and-Spoke VPN topology."; 771 } 773 identity site-role { 774 description 775 "Site Role in a VPN topology "; 776 } 778 identity any-to-any-role { 779 base site-role; 780 description 781 "Site in an any-to-any IP VPN."; 782 } 784 identity hub { 785 base site-role; 786 description 787 "Hub Role in Hub-and-Spoke IP VPN."; 788 } 790 identity spoke { 791 base site-role; 792 description 793 "Spoke Role in Hub-and-Spoke IP VPN."; 794 } 796 identity access-type { 797 description 798 "Access type of a site in a connection to WAN network"; 799 } 800 identity ge { 801 base access-type; 802 description 803 "GE"; 804 } 806 identity ef { 807 base access-type; 808 description 809 "EF"; 810 } 812 identity xge { 813 base access-type; 814 description 815 "XGE"; 816 } 818 identity lte { 819 base access-type; 820 description 821 "LTE"; 822 } 824 identity xdsl-atm { 825 base access-type; 826 description 827 "xDSL(ATM)"; 828 } 830 identity xdsl-ptm { 831 base access-type; 832 description 833 "xDSL(PTM)"; 834 } 836 identity routing-protocol-type { 837 description 838 "Base identity for routing protocol type."; 839 } 841 identity ospf { 842 base routing-protocol-type; 843 description 844 "Identity for OSPF protocol type."; 845 } 847 identity bgp { 848 base routing-protocol-type; 849 description 850 "Identity for BGP protocol type."; 851 } 853 identity static { 854 base routing-protocol-type; 855 description 856 "Identity for static routing protocol type."; 857 } 859 identity addr-allocation { 860 description 861 "Base identity for address allocation"; 862 } 864 identity addr-allocation-static { 865 base addr-allocation; 866 description 867 "Static"; 868 } 870 identity traffic-direction { 871 description 872 "Base identity for traffic direction"; 873 } 875 identity inbound { 876 base traffic-direction; 877 description 878 "Identity for inbound"; 879 } 881 identity outbound { 882 base traffic-direction; 883 description 884 "Identity for outbound"; 885 } 887 identity both { 888 base traffic-direction; 889 description 890 "Identity for both"; 891 } 893 identity traffic-action { 894 description 895 "Base identity for traffic action"; 897 } 899 identity permit { 900 base traffic-action; 901 description 902 "Identity for permit action"; 903 } 905 identity deny { 906 base traffic-action; 907 description 908 "Identity for deny action"; 909 } 911 identity bd-limit-type { 912 description 913 "base identity for bd limit type"; 914 } 916 identity percent { 917 base bd-limit-type; 918 description 919 "Identity for percent"; 920 } 922 identity value { 923 base bd-limit-type; 924 description 925 "Identity for value"; 926 } 928 grouping qos-bandwidth-policy { 929 list qos-bandwidth-policy { 930 key "name"; 931 leaf name { 932 type string; 933 description 934 "QoS name"; 935 } 936 leaf priorty { 937 type uint32; 938 description 939 "Priorty"; 940 } 941 container qos { 942 leaf classification-name { 943 type leafref { 944 path "/sdwan-vpn-svc/sdwan-vpn/classification-profile/name"; 946 } 947 description 948 "Qos Classification name"; 949 } 950 leaf qos-profile-name { 951 type leafref { 952 path "/sdwan-vpn-svc/sdwan-vpn/qos-profile/name"; 953 } 954 description 955 "Qos profile name"; 956 } 957 description 958 "Container for QOS"; 959 } 960 description 961 "List for qos policy"; 962 } 963 description 964 "Gourping for qos-bandwidth-policy"; 965 } 967 grouping qos-profile { 968 list qos-profile { 969 key "name"; 970 leaf name { 971 type string; 972 description 973 "QOS profile name"; 974 } 975 leaf bd-limit-type { 976 type identityref { 977 base bd-limit-type; 978 } 979 description 980 "bd limit type"; 981 } 982 container percent { 983 when "../bd-limit-type = 'percent'"; 984 leaf width-percent { 985 type uint32; 986 description 987 "Width percent"; 988 } 989 description 990 "Container for percent"; 991 } 992 container value { 993 when "../bd-limit-type = 'value'"; 994 leaf cir { 995 type uint32; 996 description 997 "CIR"; 998 } 999 leaf pir { 1000 type uint32; 1001 description 1002 "PIR"; 1003 } 1004 description 1005 "Container for value"; 1006 } 1007 description 1008 "List for qos profile"; 1009 } 1010 description 1011 "Grouping for qos profile"; 1012 } 1014 grouping application-group { 1015 list application-group { 1016 key "group-name"; 1017 leaf group-name { 1018 type string; 1019 description 1020 "Gourp name"; 1021 } 1022 leaf-list application-name { 1023 type string; 1024 description 1025 "Application name"; 1026 } 1027 description 1028 "List for application group"; 1029 } 1030 description 1031 "Grouping for application-group"; 1032 } 1034 grouping path-selection-policy { 1035 list path-selection-policy { 1036 key "name"; 1037 leaf name { 1038 type string; 1039 description 1040 "Policy name"; 1041 } 1042 list rule { 1043 key "rule-id"; 1044 leaf rule-id { 1045 type string; 1046 description 1047 "Rule id"; 1048 } 1049 leaf priority { 1050 type uint32; 1051 description 1052 "Priority"; 1053 } 1054 leaf classification-name { 1055 type leafref { 1056 path "/sdwan-vpn-svc/sdwan-vpn/classification-profile/name"; 1057 } 1058 description 1059 "QOS Classification NAME"; 1060 } 1061 list traffic-sla-profile { 1062 key "name"; 1063 leaf name { 1064 type string; 1065 description 1066 "traffic sla profile"; 1067 } 1068 leaf latency { 1069 type uint32; 1070 description 1071 "latency"; 1072 } 1073 leaf jitter { 1074 type uint32; 1075 description 1076 "jitter"; 1077 } 1078 leaf packet-loss-rate { 1079 type uint32; 1080 description 1081 "packet loss rate"; 1082 } 1083 description 1084 "traffic sla profile"; 1085 } 1086 leaf transport-network-primary { 1087 type string; 1088 description 1089 "Primary transport network preferred"; 1091 } 1092 leaf transport-network-sencondry { 1093 type string; 1094 description 1095 "Sencondry transport network preferred"; 1096 } 1097 description 1098 "List for Rule"; 1099 } 1100 description 1101 "List for path selection policy"; 1102 } 1103 description 1104 "Grouping for path-selection-policy"; 1105 } 1107 grouping internet-access { 1108 container internet-access { 1109 leaf access-option { 1110 type uint32; 1111 description 1112 "internet access via local breakout or central gateway"; 1113 } 1114 leaf-list internet-gateway-ip { 1115 type inet:ip-address; 1116 description 1117 "Internet gateway IP"; 1118 } 1119 leaf nat { 1120 type uint32; 1121 description 1122 "NAT"; 1123 } 1124 leaf nat44-ip-addr { 1125 type inet:ip-address; 1126 description 1127 "Static nat custom internet IP. 1128 Address to be used for network address translation from IPv4 to 1129 IPv4. This is to be used if the customer is providing the IPv4 1130 address. If the customer address is not set, the model assumes 1131 that the provider will allocate the address."; 1132 } 1133 description 1134 "Container for internet access"; 1135 } 1136 description 1137 "Grouping for internet-access"; 1138 } 1139 grouping vpn-interworking { 1140 container vpn-interworking { 1141 leaf-list site { 1142 type leafref { 1143 path "/sdwan-vpn-svc/sdwan-vpn/sites/site/site-id"; 1144 } 1145 description 1146 "List for interworking gateway for traditional MPLS VPN "; 1147 } 1148 description 1149 "List for traditional MPLS VPN interworking"; 1150 } 1151 description 1152 "Grouping for vpn-interworking"; 1153 } 1155 grouping traffic-filter-policy { 1156 list traffic-filter { 1157 key "site-id"; 1158 leaf site-id { 1159 type leafref { 1160 path "/sdwan-vpn-svc/sdwan-vpn/sites/site/site-id"; 1161 } 1162 description 1163 "Site id"; 1164 } 1165 leaf classification-name { 1166 type leafref { 1167 path "/sdwan-vpn-svc/sdwan-vpn/classification-profile/name"; 1168 } 1169 description 1170 "Classification profile name"; 1171 } 1172 leaf direction { 1173 type identityref { 1174 base traffic-direction; 1175 } 1176 description 1177 "Traffic direction"; 1178 } 1179 leaf action { 1180 type identityref { 1181 base traffic-action; 1182 } 1183 description 1184 "Action"; 1185 } 1186 description 1187 "List for traffic filter"; 1188 } 1189 description 1190 "Grouping for traffic filter"; 1191 } 1193 grouping flow-definition { 1194 container match-flow { 1195 leaf dscp { 1196 type inet:dscp; 1197 description 1198 "DSCP value."; 1199 } 1200 leaf dot1p { 1201 type uint8 { 1202 range "0..7"; 1203 } 1204 description 1205 "802.1p matching."; 1206 } 1207 leaf ipv4-src-prefix { 1208 type inet:ipv4-prefix; 1209 description 1210 "Match on IPv4 src address."; 1211 } 1212 leaf ipv6-src-prefix { 1213 type inet:ipv6-prefix; 1214 description 1215 "Match on IPv6 src address."; 1216 } 1217 leaf ipv4-dst-prefix { 1218 type inet:ipv4-prefix; 1219 description 1220 "Match on IPv4 dst address."; 1221 } 1222 leaf ipv6-dst-prefix { 1223 type inet:ipv6-prefix; 1224 description 1225 "Match on IPv6 dst address."; 1226 } 1227 leaf l4-src-port { 1228 type inet:port-number; 1229 must "'.' <= '../l4-src-port-range/lower-port' and'.'>= '../l4-src-port-range/upper-port'" { 1230 description 1231 " If l4-src-port and l4-src-port-range/lower-port and 1232 upper-port are set at the same time, l4-src-port 1233 should not overlap with l4-src-port-range. "; 1234 } 1235 description 1236 "Match on Layer 4 src port."; 1237 } 1238 container l4-src-port-range { 1239 leaf lower-port { 1240 type inet:port-number; 1241 description 1242 "Lower boundary for port."; 1243 } 1244 leaf upper-port { 1245 type inet:port-number; 1246 must '. >= ../lower-port' { 1247 description 1248 " Upper boundary for port. If it 1249 exists, upper boundary must be 1250 higher than lower boundary."; 1251 } 1252 description 1253 "Upper boundary for port."; 1254 } 1255 description 1256 "Match on Layer 4 src port range. When only lower-port 1257 is present, it represents a single port. When both 1258 lower-port and upper-port are specified, it implies 1259 a range inclusive of both values."; 1260 } 1261 leaf l4-dst-port { 1262 type inet:port-number; 1263 must '. <= ../l4-dst-port-range/lower-port and.>= ../l4-dst-port-range/upper-port' { 1264 description 1265 " If l4-dst-port and l4-dst-port-range/lower-port and 1266 upper-port are set at the same time, l4-dst-port 1267 should not overlap with l4-src-port-range. "; 1268 } 1269 description 1270 "Match on Layer 4 dst port."; 1271 } 1272 container l4-dst-port-range { 1273 leaf lower-port { 1274 type inet:port-number; 1275 description 1276 "Lower boundary for port."; 1277 } 1278 leaf upper-port { 1279 type inet:port-number; 1280 must '. >= ../lower-port' { 1281 description 1282 "Upper boundary must be 1283 higher than lower boundary."; 1284 } 1285 description 1286 "Upper boundary for port. If it exists, upper boundary 1287 must be higher than lower boundary."; 1288 } 1289 description 1290 "Match on Layer 4 dst port range. When only lower-port is 1291 present, it represents a single port. When both lower-port 1292 and upper-port are specified, it implies a range inclusive 1293 of both values."; 1294 } 1295 leaf protocol-field { 1296 type union { 1297 type uint8; 1298 type identityref { 1299 base routing-protocol-type; 1300 } 1301 } 1302 description 1303 "Match on IPv4 protocol or IPv6 Next Header field."; 1304 } 1305 description 1306 "Describes flow-matching criteria."; 1307 } 1308 description 1309 "Flow definition based on criteria."; 1310 } 1312 grouping classification-profile { 1313 list classification-profile { 1314 key "name"; 1315 leaf name { 1316 type string; 1317 description 1318 "classification name"; 1319 } 1320 list rule { 1321 key "id"; 1322 ordered-by user; 1323 leaf id { 1324 type string; 1325 description 1326 "A description identifying qos classification 1327 policy rule."; 1328 } 1329 choice match-type { 1330 default "match-flow"; 1331 case match-flow { 1332 uses flow-definition; 1333 } 1334 case match-application-group { 1335 leaf match-application-group { 1336 type string; 1337 description 1338 "Defines the application to match."; 1339 } 1340 } 1341 description 1342 "Choice for classification."; 1343 } 1344 description 1345 "List of marking rules."; 1346 } 1347 description 1348 "List for classification profile"; 1349 } 1350 description 1351 "Gourping for classification profile"; 1352 } 1354 grouping routing-protocol { 1355 list routing-protocol { 1356 key "type"; 1357 leaf type { 1358 type identityref { 1359 base routing-protocol-type; 1360 } 1361 description 1362 "Routing protocol type"; 1363 } 1364 container ospf { 1365 when "derived-from-or-self(../type, 'sdwan-vpn-svc:ospf')" { 1366 description 1367 "Only applies when protocol is OSPF."; 1368 } 1369 leaf-list address-family { 1370 type address-family; 1371 min-elements 1; 1372 description 1373 "If OSPF is used on this site, this node 1374 contains a configured value. This node 1375 contains at least one address family 1376 to be activated."; 1377 } 1378 leaf area-address { 1379 type yang:dotted-quad; 1380 mandatory true; 1381 description 1382 "Area address."; 1383 } 1384 leaf metric { 1385 type uint16; 1386 default "1"; 1387 description 1388 "Metric of the PE-CE link. It is used 1389 in the routing state calculation and 1390 path selection."; 1391 } 1392 description 1393 "OSPF-specific configuration."; 1394 } 1395 container bgp { 1396 when "derived-from-or-self(../type, 'sdwan-vpn-svc:bgp')" { 1397 description 1398 "Only applies when protocol is BGP."; 1399 } 1400 leaf autonomous-system { 1401 type uint32; 1402 mandatory true; 1403 description 1404 "Customer AS number in case the customer 1405 requests BGP routing."; 1406 } 1407 leaf-list address-family { 1408 type address-family; 1409 min-elements 1; 1410 description 1411 "If BGP is used on this site, this node 1412 contains a configured value. This node 1413 contains at least one address family 1414 to be activated."; 1415 } 1416 description 1417 "BGP-specific configuration."; 1418 } 1419 container static { 1420 when "derived-from-or-self(../type, 'sdwan-vpn-svc:static')" { 1421 description 1422 "Only applies when protocol is static. 1423 BGP activation requires the SP to know 1424 the address of the customer peer. When 1425 BGP is enabled, the 'static-address' 1426 allocation type for the IP connection 1427 MUST be used."; 1428 } 1429 list ip-lan-prefixes { 1430 key "lan next-hop"; 1431 leaf lan { 1432 type inet:ip-prefix; 1433 description 1434 "LAN prefixes."; 1435 } 1436 leaf next-hop { 1437 type inet:ipv4-address; 1438 description 1439 "Next-hop address to use on the customer side."; 1440 } 1441 leaf priority { 1442 type uint16; 1443 description 1444 "Prority"; 1445 } 1446 description 1447 "List of LAN prefixes for the site."; 1448 } 1449 description 1450 "Configuration specific to static routing."; 1451 } 1452 description 1453 "List for Routing Protocol"; 1454 } 1455 description 1456 "Grouping for routing protocol"; 1457 } 1459 container sdwan-vpn-svc { 1460 list sdwan-vpn { 1461 key "vpn-id"; 1462 leaf vpn-id { 1463 type svc-id; 1464 description 1465 "VPN identifier. Local administration meaning."; 1466 } 1467 leaf customer-name { 1468 type svc-id; 1469 description 1470 "Id for customer"; 1471 } 1472 list wan-transport-networks { 1473 key "wan-transport-name"; 1474 leaf wan-transport-name { 1475 type string; 1476 description 1477 "WAN transport network name"; 1478 } 1479 leaf wan-transport-type { 1480 type identityref { 1481 base access-type; 1482 } 1483 description 1484 "Access type"; 1485 } 1486 description 1487 "WAN transport network type"; 1488 } 1489 container security { 1490 leaf algorithm { 1491 type string; 1492 description 1493 "Encryption algorithm to be used"; 1494 } 1495 leaf preshared-key { 1496 type string; 1497 description 1498 "Pre-Shared Key (PSK) from individual customer."; 1499 } 1500 description 1501 "Container for IPSEC VPN encryption parameters"; 1502 } 1503 uses application-group; 1504 uses classification-profile; 1505 uses qos-profile; 1506 container sites { 1507 list site { 1508 key "site-id"; 1509 leaf site-id { 1510 type svc-id; 1511 description 1512 "Site Name"; 1513 } 1514 list location { 1515 key "email"; 1516 leaf email { 1517 type string; 1518 description 1519 "List for email"; 1520 } 1521 leaf postcode { 1522 type string; 1523 description 1524 "Post code"; 1525 } 1526 leaf address { 1527 type string; 1528 description 1529 "Location address"; 1530 } 1531 description 1532 "List for location"; 1533 } 1534 list device { 1535 key "name"; 1536 leaf name { 1537 type string; 1538 description 1539 "Device Name"; 1540 } 1541 leaf type { 1542 type string; 1543 description 1544 "Device Type"; 1545 } 1546 list transport-network-port { 1547 key "name"; 1548 leaf name { 1549 type string; 1550 description 1551 "transport network port name"; 1552 } 1553 leaf access-type { 1554 type identityref { 1555 base access-type; 1556 } 1557 description 1558 "Access type"; 1559 } 1560 container ip-connection { 1561 leaf type { 1562 type identityref { 1563 base addr-allocation; 1564 } 1565 description 1566 "Address allocation type"; 1567 } 1568 container static { 1569 when "../type = 'addr-allocation-static'"; 1570 leaf customer-addr { 1571 type inet:ip-address; 1572 description 1573 "Customer address"; 1574 } 1575 leaf prefix { 1576 type inet:ip-prefix; 1577 description 1578 "IP Prefix"; 1579 } 1580 leaf provider-addr { 1581 type inet:ip-address; 1582 description 1583 "Provider address"; 1584 } 1585 description 1586 "Container for static"; 1587 } 1588 description 1589 "Container for ip connection"; 1590 } 1591 uses routing-protocol; 1592 container bandwidth { 1593 leaf input-bandwidth { 1594 type uint64; 1595 description 1596 "input bandwidth"; 1597 } 1598 leaf output-bandwidth { 1599 type uint64; 1600 description 1601 "output bandwidth"; 1602 } 1603 leaf mtu { 1604 type uint16; 1605 description 1606 "MTU"; 1607 } 1608 description 1609 "Container for bandwidth profile"; 1610 } 1611 description 1612 "List for transport network ports"; 1613 } 1614 description 1615 "List for devices"; 1616 } 1617 description 1618 "List for sites"; 1620 } 1621 description 1622 "Container for sites"; 1623 } 1624 list subvpn { 1625 key "subvpn-id"; 1626 leaf subvpn-id { 1627 type svc-id; 1628 description 1629 "subVPN network identifier"; 1630 } 1631 leaf topology { 1632 type identityref { 1633 base vpn-topology; 1634 } 1635 description 1636 "subVPN topology: hub&spoke or any-to-any"; 1637 } 1638 list logical-access { 1639 key "site-id"; 1640 leaf site-id { 1641 type leafref { 1642 path "/sdwan-vpn-svc/sdwan-vpn/sites/site/site-id"; 1643 } 1644 description 1645 "The site that the logic-access attached."; 1646 } 1647 leaf site-role { 1648 type identityref { 1649 base site-role; 1650 } 1651 default "any-to-any-role"; 1652 description 1653 "Role of the site in the subVPN."; 1654 } 1655 leaf vlan-tag { 1656 type uint16; 1657 description 1658 "VLAN TAG"; 1659 } 1660 leaf ip-address { 1661 type inet:ip-address; 1662 description 1663 "IP Address"; 1664 } 1665 leaf ip-prefix { 1666 type inet:ip-prefix; 1667 description 1668 "IP Prefix"; 1669 } 1670 uses routing-protocol; 1671 description 1672 "container for logical access"; 1673 } 1674 container policies { 1675 uses path-selection-policy; 1676 uses qos-bandwidth-policy; 1677 uses traffic-filter-policy; 1678 uses internet-access; 1679 uses vpn-interworking; 1680 description 1681 "container for policies"; 1682 } 1683 description 1684 "List for subVPN network"; 1685 } 1686 description 1687 "List for SD-WAN"; 1688 } 1689 description 1690 "Container for SD-WAN VPN service"; 1691 } 1692 } 1694 1696 6. Security Considerations 1698 The YANG module specified in this document defines a schema for data 1699 that is designed to be accessed via network management protocols such 1700 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1701 is the secure transport layer, and the mandatory-to-implement secure 1702 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1703 is HTTPS, and the mandatory-to-implement secure transport is TLS 1704 [RFC5246]. 1706 The NETCONF access control model [RFC6536]provides the means to 1707 restrict access for particular NETCONF or RESTCONF users to a 1708 preconfigured subset of all available NETCONF or RESTCONF protocol 1709 operations and content. 1711 There are a number of data nodes defined in this YANG module that are 1712 writable/creatable/deletable (i.e., config true, which is the 1713 default). These data nodes may be considered sensitive or vulnerable 1714 in some network environments. Write operations (e.g., edit-config) 1715 to these data nodes without proper protection can have a negative 1716 effect on network operations. These are the subtrees and data nodes 1717 and their sensitivity/vulnerability. 1719 7. IANA Considerations 1721 IANA has assigned a new URI from the "IETF XML Registry" [RFC3688]. 1723 URI: urn:ietf:params:xml:ns:yang:ietf-sdwan-vpn-svc 1724 Registrant Contact: The IESG 1725 XML: N/A; the requested URI is an XML namespace. 1727 IANA has recorded a YANG module name in the "YANG Module Names" 1728 registry [RFC6020] as follows: 1730 Name: ietf-sdwan-vpn-svc 1731 Namespace: urn:ietf:params:xml:ns:yang:ietf-sdwan-vpn-svc 1732 Prefix: sdwan-svc 1733 Reference: RFC xxxx 1735 8. Acknowledgments 1737 This work has benefited from the discussions of xxxx. 1739 9. Contributors 1741 The authors would like to thank Zitao Wang and Qin Wu for their major 1742 contributions to the initial modeling. 1744 10. References 1746 10.1. Normative References 1748 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1749 Requirement Levels", BCP 14, RFC 2119, 1750 DOI 10.17487/RFC2119, March 1997, 1751 . 1753 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 1754 Private Network (VPN) Terminology", RFC 4026, 1755 DOI 10.17487/RFC4026, March 2005, 1756 . 1758 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1759 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1760 2006, . 1762 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 1763 2 Virtual Private Networks (L2VPNs)", RFC 4664, 1764 DOI 10.17487/RFC4664, September 2006, 1765 . 1767 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1768 the Network Configuration Protocol (NETCONF)", RFC 6020, 1769 DOI 10.17487/RFC6020, October 2010, 1770 . 1772 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 1773 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 1774 DOI 10.17487/RFC6071, February 2011, 1775 . 1777 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1778 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1779 DOI 10.17487/RFC8299, January 2018, 1780 . 1782 10.2. Informative References 1784 [I-D.carrel-ipsecme-controller-ike] 1785 Carrel, D. and B. Weis, "IPsec Key Exchange using a 1786 Controller", draft-carrel-ipsecme-controller-ike-00 (work 1787 in progress), July 2018. 1789 [I-D.dukes-spring-sr-for-sdwan] 1790 Dukes, D., Filsfils, C., Dawra, G., Xu, X., 1791 daniel.voyer@bell.ca, d., Camarillo, P., Clad, F., and S. 1792 Salsano, "SR For SDWAN: VPN with Underlay SLA", draft- 1793 dukes-spring-sr-for-sdwan-00 (work in progress), June 1794 2018. 1796 [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] 1797 Lopez, R. and G. Lopez-Millan, "Software-Defined 1798 Networking (SDN)-based IPsec Flow Protection", draft-ietf- 1799 i2nsf-sdn-ipsec-flow-protection-02 (work in progress), 1800 July 2018. 1802 [I-D.ietf-l3vpn-ce-based] 1803 Clercq, J., "An Architecture for Provider Provisioned CE- 1804 based Virtual Private Networks using IPsec", draft-ietf- 1805 l3vpn-ce-based-03 (work in progress), December 2005. 1807 [I-D.rosen-bess-secure-l3vpn] 1808 Rosen, E. and R. Bonica, "Augmenting RFC 4364 Technology 1809 to Provide Secure Layer L3VPNs over Public 1810 Infrastructure", draft-rosen-bess-secure-l3vpn-01 (work in 1811 progress), June 2018. 1813 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 1814 Provider-Provisioned Virtual Private Networks (PPVPNs)", 1815 RFC 4110, DOI 10.17487/RFC4110, July 2005, 1816 . 1818 [RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L., 1819 Kreeger, L., and M. Napierala, "Problem Statement: 1820 Overlays for Network Virtualization", RFC 7364, 1821 DOI 10.17487/RFC7364, October 2014, 1822 . 1824 Authors' Addresses 1826 Qiong Sun 1827 China Telecom 1828 Beijing 1829 China 1831 Email: sunqiong.bri@chinatelecom.cn 1833 Honglei Xu 1834 China Telecom 1835 Beijing 1836 China 1838 Email: sunqiong.bri@chinatelecom.cn 1840 Bo Wu 1841 Huawei 1842 Nanjing 1843 China 1845 Email: lana.wubo@huawei.com 1846 Qin Wu 1847 Huawei 1848 Nanjing 1849 China 1851 Email: bill.wu@huawei.com