Operations and Management Area Working Group Q. Sun Internet-Draft H. Xu Intended status: Standards Track China Telecom Expires: April 24, 2019 B. Wu Q. Wu Huawei October 21, 2018 A YANG Data Model for SD-WAN VPN Service Delivery draft-sun-opsawg-sdwan-service-model-01 Abstract This document defines a SD-WAN VPN service model to enable a Service Provider to deliver SD-WAN VPN services to its customers by provisioning the CE devices on behalf of the customer. This document is based on provider-provisioned CE-based VPNs as described in [RFC4110]. This model provides an abstracted view of the SD-WAN VPN service configuration components, and is intended to be instantiated at the management system to deliver the overall service. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 24, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Sun, et al. Expires April 24, 2019 [Page 1] Internet-Draft SD-WAN Service YANG Model October 2018 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 2. High Level overview of SD-WAN VPN . . . . . . . . . . . . . . 5 3. Design of the Data Model . . . . . . . . . . . . . . . . . . 7 3.1. SD-WAN VPN . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. Security . . . . . . . . . . . . . . . . . . . . . . 8 3.1.2. Policy templates . . . . . . . . . . . . . . . . . . 8 3.2. Site . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. SubVPNs . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. Policies . . . . . . . . . . . . . . . . . . . . . . 11 3.3.1.1. Path selection policies . . . . . . . . . . . . . 11 3.3.1.2. QoS bandwidth policies . . . . . . . . . . . . . 11 3.3.1.3. Traffic filter . . . . . . . . . . . . . . . . . 12 3.4. Internet access . . . . . . . . . . . . . . . . . . . . . 12 3.5. Interworking with conventional VPN . . . . . . . . . . . 12 4. Modules Tree Structure . . . . . . . . . . . . . . . . . . . 12 5. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.1. Normative References . . . . . . . . . . . . . . . . . . 37 10.2. Informative References . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction The conventional VPN, such as BGP/MPLS IP VPNs [RFC4364], Ethernet VPN [RFC4664] have delivered promised connectivity in terms of security, mutlicast and Quality of Service. These VPNs are categorized as PE-based Provider provisioned VPN. By comparison, the SD-WAN is a CE-based VPN which is sitting on top of the PE based Provider provisioned VPN or Internet. A CE-based VPN has many benefit similarly with Network Virtualization Overlays (nvo3) [RFC7364], which uses an overlay-based approach to provide the Sun, et al. Expires April 24, 2019 [Page 2] Internet-Draft SD-WAN Service YANG Model October 2018 flexibility of adding, removing, or moving services within the physical infrastructure, without dependence of the underlay network. This draft aims at providing a common understanding of how the corresponding SD-WAN VPN service is to be deployed. But there is no standard SD-WAN specification defined and SD-WAN VPN has more functionality than the basic CE-based VPN service described in the L3VPN framework document [RFC4110]. This service model defines the following main components which is also reflected in other SD-WAN work in IETF: o Multiple accesses: The CE could connect to additional Internet access, including fiber, cable, DSL-based, WiFi, or 4G/Long Term Evolution (LTE) access, which implies wider reachability and shorter provisioning cycles. It can also use MPLS connectivity defined in [RFC4364] or [RFC4664] as well to take advantage of better performance. SR For SDWAN [I-D.dukes-spring-sr-for-sdwan] assumes a CE of SD-WAN could connect to Internet or MPLS underlay network, so underlay network could offer SRv6 or SR-MPLS TE policy path for different flows classified by the CE on enterprise site. o Fine granularity isolation: Beside basic VPN service, a customer may need to maintain fine granularity isolation inside one VPN connectivity. Therefore, multiple subVPN could be set up for each separate virtual network. Each virtual network could have its own topology, addressing scheme and policies. Augmenting RFC 4364 Tec hnology to Provide Secure Layer L3VPNs over Public Infrastructure provides a L3VPN extension to implement this service. o Policy based traffic forwarding: SD-WAN VPN can provide optimizing forwarding from a network scope and deploy service nodes as needed. Specifically,it can apply policies to prioritize traffic for diverse applications used in enterprises, such as VoIP calling, videoconferencing, streaming media etc. depending different business needs. SR For SDWAN [I-D.dukes-spring-sr-for-sdwan] assumes that a CE of SD-WAN could classify ingress traffic ( e.g. L3-L7 flow classification), monitor the flow state and steer the flow to different SR path, so underlay network only needs maintaining SRTE policies at the edge without holding any per-SDWAN-flow state in the core of its network. This draft specifies SD-WAN VPN service YANG model. This model can be used as a input to automated control and configuration applications to manage SD-WAN VPN services. Sun, et al. Expires April 24, 2019 [Page 3] Internet-Draft SD-WAN Service YANG Model October 2018 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. 1.2. Definitions CE Device: Customer Edge Device , as per Provider Provisioned VPN Terminology [RFC4026] . PE Device: Provider Edge Device, as per Provider Provisioned VPN Terminology [RFC4026] CE-based VPN: Refers to Provider Provisioned VPN Terminology [RFC4026] PE-Based VPNs: Refers to Provider Provisioned VPN Terminology [RFC4026] SD-WAN:An automated, programmatic approach to managing enterprise network connectivity and circuit usage. It extends software-defined networking (SDN) into an application that businesses can use to quickly create a smart "hybrid WAN"- a WAN that comprises business- grade IP VPN, broadband Internet, and wireless services. SD-WAN is also deemed as extended CE-based VPN. Underlay network: The network that provides the connectivity among SD-WAN VPN sites and that the customer network packets are tunneled over. The underlay network does not need to be aware that it is carrying overlay customer network packets. Addresses on the underlay network appear as "outer addresses" in encapsulated overlay packets. In general, the underlay network can use a completely different protocol (and address family) from that of the overlay network. Overlay network: A virtual network in which the separation of customer networks is hidden from the underlying physical infrastructure. That is, the underlying transport network does not need to know about customer separation to correctly forward traffic. IPsec tunnels [RFC6071] is an example of an L3 overlay network. SubVPN:A subVPN provides fine granularity isolation inside one VPN connectivity. Therefore, multiple subVPN could be set up for each separate virtual network. Each virtual network could have its own topology, addressing scheme and policies.YANG Data Model for L3VPN Service Delivery [RFC8299] has specified same concept. Sun, et al. Expires April 24, 2019 [Page 4] Internet-Draft SD-WAN Service YANG Model October 2018 2. High Level overview of SD-WAN VPN An example of SD-WAN VPN network architecture is presented in figure 1. +-------------+ +------------+ | +---+ | | Controller +----+ | |TS | | Legend:Tenant System +------------+ | | +---+ | | | | site3| | | +--+--+ | +--|---|CE 4 | | | | +--+--+ | | +-------------+ | | +------------------- ----+ | ----- | +---------------+ / MPLS \ +-----------------+ | | | | WAN |__| | | | | | /\ /\ \ +--+--+ | | | | / +-----+ \ |\|CE 1 +-+ | | +---+ +----++|/ \|/+--+--+ | +---+| | |TS +--+ CE 3|| \ +--+TS || | +---+ +-----+| ------ /|\+--+--+ | +---+| | | |\ /Internet\ / |/|CE 2 +-+ | | | | --| WAN |__/ +--+--+ | | site 2| | \ / | site 1 | +---------------+ ------ +-----------------+ | | | +-------------+ | | +----+ | +----|---+ CE5| | | +----+ | |site 4| | | | | | +---+ | | |TS | | | +---+ | +-------------+ figure 1 As shown in figure 1, an SD-WAN network is usually composed of a set of sites and network connectivity services between sites or within each site. Within each site, a CE is connected with customer's network on one side, and also is connected to Internet WAN or MPLS WAN or both on the other side. Customer's network, represented by the connection between TS and CE, could be L2 or L3 network. Sun, et al. Expires April 24, 2019 [Page 5] Internet-Draft SD-WAN Service YANG Model October 2018 Internet WAN provides ordinary IP connectivity via access network like Broadband access or LTE access. MPLS WAN refers to conventional MPLS VPN network. While a CE attaches to a conventional MPLS VPN PE router, then the CE appears to the conventional PE to be a CE router. Additionally, a site could deploy one or more CE to improve availability. The establishment of the SD-WAN VPN is done at each CE device, making use of different IP tunneling options (e.g., Generic Routing Encapsulation (GRE), and IPsec) and [I-D.ietf-l3vpn-ce-based] describes a IPSEC based architecture to provide secure connectivity between sites. Either Internet WAN or MPLS WAN is regarded as underlay of the tunneling, the communication among Customer's network in the four sites, which also known as the overlay network, does not depend on the underlay network. In some cases, other than connectivity among the sites, the subset of sites could also need to provide Internet connectivity, cloud network connectivity or conventional MPLS VPN connectivity. In the example, only four sites are shown, in actual deployment, thousands of sites could be implemented and new services need to bring up rapidly, it is therefore critical to automate the configuration of SD-WAN services. Inside one VPN service, there is a need to further set up mutiple subVPNs based on different security or performance requirements, such as: o Separation of lines of businesses or communication between the affiliates regardless of location o Separation of guest WiFi access for clients and partners o Isolating on-demand development and test labs that span multiple locations [I-D.rosen-bess-secure-l3vpn] describes similar use case, and provides an L3VPN augmentation to implement it. An example of subVPN is shown in figure 2 below. Sun, et al. Expires April 24, 2019 [Page 6] Internet-Draft SD-WAN Service YANG Model October 2018 +---------+ |subVPN 1| +----+----+ | +--+--+ |CE 4 | +--+--+ | | +---------+ ----- +-----+subVPN 1| / Private\ | +---------+ +---------+ | WAN |_ | +---------+ |subVPN 1 +----+ /\ /\ \ +-----+ +-----+subVPN 2| +---------+ | / +-----+ \ \|CE 1 +--+ +---------+ +---------+ +-+---+ / \ /+-----+ | |subVPN 2+--+ CE 3|/ / | +---------+ +---------+ +-+---+\ ------ / \+-----+ +-----+subVPN 3| +---------+ | \_ / Public\ / /|CE 2 +--+ +---------+ |subVPN 3+----+ | WAN |__/ +-----+ | +---------+ +---------+ \ / +---- +subVPN 4| ------ +---------+ | | +----+ | CE5| +----+ | | +-----+---+ |subVPN 4| +---------+ figure 2 3. Design of the Data Model For a SD-WAN VPN to be established under the SP's control, the VPN customer informs the Service Provider of which sites should become part of the considered VPN and what the requested topology of subVPN should look like. The SP then configures and updates the service base on a service model, and then provisions and manages the customer's VPN. This document defines three containers as follows, representing the three categories of parameters of the Customer's VPN. 1. sdwan-vpn: This container includes general service parameters and templates. Sun, et al. Expires April 24, 2019 [Page 7] Internet-Draft SD-WAN Service YANG Model October 2018 2. sites: This list is used to indicate sites that are involved in different geographic locations. 3. subvpns: This list is to specify the characteristics of a subVPN, and which logical access of the customer network is connected. 3.1. SD-WAN VPN The "sdwpn-vpn" list item contains global configuration of a SD-WAN VPN service. The "vpn-id" provided in the vpn-service list refers to an internal reference for this VPN service, while the customer name refers to a more explicit reference to a customer. A WAN transport network list is used to describe different WAN network information to specify which links are reachable. In many cases, enterprise customers could have business relationship with multiple WAN network services providers for example broadband internet service and MPLS VPN service. And a WAN transport provider may not be the same of SD-WAN VPN service provider. 3.1.1. Security A customer site could connect to MPLS WAN or Internet WAN and the IPsec VPN discussed earlier which offers security service of the authentication and encryption could be used in both connection. As the MPLS WAN is considered to be sufficiently secure, the packets traversing it may not need to be encrypted if it is not sensitive to security. Therefore, the underlay tunneling could be encrypted or not encrypted. When a customer requests encryption service, the security parameters could be specified. The security container is used to specify the parameters such as encryption algorithm and preshared key for each customer. Other key-management methodologies (e.g., PKI) may be added through augmentation. In addition to common IPSEC management,SDN-based IPsec Flow Protection [I-D.ietf-i2nsf-sdn-ipsec-flow-protection]and IPsec Key Exchange using a Controller [I-D.carrel-ipsecme-controller-ike] are two new controller based methods to optimize IPSEC process to better management in SDN context. 3.1.2. Policy templates The policy templates consist of application group, classification profile and qos profile, which would be used by all the subVPNs. Sun, et al. Expires April 24, 2019 [Page 8] Internet-Draft SD-WAN Service YANG Model October 2018 The "application-group" container is used to describe all the application categories, e.g. VOIP, email, games etc. The "classification-profile" container defines flow classification rules to be handled and it has a rule list and the corresponding flow class name. This draft borrows the flow classification profile defined in [RFC8299] to specify flow classification criteria. The flow classification rule are supposed to be used together with other policies including path-selection-policy, QoS policy and traffic filter policy. The "qos-profile" is used to specify the bandwidth requirements for a certain flow or other criteria. 3.2. Site A site represents a customer office located at a specific location. The "sites" container is to specify three main information: o Site information: General information includes site-id, site location address o Device information: A site could have one or more CE devices. Every device participating in a VPN is to be pre-provisioned with the necessary configuration information that enables it to establish a secure communication path with the SD-WAN controller.The device could be posted to customer for self install. A customer needs to specify what kind of device looks like. o Transport network port: The transport-network-port container is used to specify underlay WAN network link parameters. A "site" is composed of at least one "transport-network" and, in the case of multihoming, may have multiple transport network points. +---------------------------------+ | site | | | | | | | | | | | | | | TNP1 TNP2 TNP3 TNP4 | | +--------+ +--------+ | | | | | | | | |Device 1| |Device 2| | | +--------+ +--------+ | +---------------------------------+ Legend: TNP (Transport Network Port) figure 3 Sun, et al. Expires April 24, 2019 [Page 9] Internet-Draft SD-WAN Service YANG Model October 2018 The transport-network consists of the following categories of parameters: o Access type: defines requirements of the attachment (below Layer 3)bearer type including Ethernet, LTE, DSL. o IP Connection: defines Layer 3 parameters of the attachment o Routing protocol: includes OSPF, BGP or static routing. o Bandwidth: specifies the bandwidth of the attachment, including inbound and outbound traffic bandwidth. 3.3. SubVPNs The "subVPN" is a container directly under the "sdwan-vpn-svc" and it is used to represent logical networks in a particular enterprise SD- WAN network. Each subVPN is associated with a distinct set of logical accesses that is (are) specific to the given subVPN. This subVPN could define its own addressing and routing protocol. Each subVPN has its own service topology. The type of VPN service topology is required for configuration. Our proposed model supports any-to-any, Hub and Spoke (where Hubs can exchange traffic). By default, the any-to-any VPN service topology is used. New topologies could be added via augmentation. The "logical-access" list under the "subVPNs" is used to represent one or more customer logical accesses attached from different sites belonged to a subVPN. The list is composed of VLAN , IP connection and routing protocol parameters exposed by the customer networks. Based on the requested VPN service topology and the logical access list, the overlay connectivity could be set up among sites over underlay networks. In the figure below, a subVPN constructed for a customer spanning three sites for specified network traffic. Sun, et al. Expires April 24, 2019 [Page 10] Internet-Draft SD-WAN Service YANG Model October 2018 a subVPN | Logical | Access 1 + +--+--+ |site3| +--X--+ / \ / \ / \ Logical / \ Access 1 +-----+/ \+------+ +-------- -------+---+site2+-----------|site 1+-+ Logical +-----+ +------+ +-------- Access 1 Logical Access 2 figure 4 3.3.1. Policies The "policies" container under the "subVPN" list is used contain all the policies defined in a subVPN service. 3.3.1.1. Path selection policies The path-selection-policy container is under policies container, and it has the following parameters: o Flow classification rule. o Traffic SLA profile, including delay, jitter and loss sub parameters. o Primary and secondary path. Path selection policy is an ordered list. For the traffic specified by the flow classification rule, traffic SLA profile related status will be collected and based on the measurement result calculated from the collected information, primary path or secondary path will be selected. 3.3.1.2. QoS bandwidth policies The qos-bandwidth policy container is used to describe parameter to guarantee bandwidth for specific traffic flowing through a subVPN connection. It has three categories parameters, including priority, DSCP parameters, traffic rate limit (CAR traffic policy or traffic Sun, et al. Expires April 24, 2019 [Page 11] Internet-Draft SD-WAN Service YANG Model October 2018 shaping) and bandwidth represented by percentage value or absolute value. 3.3.1.3. Traffic filter Traffic filter is a class of security policy used to filter flow for each subVPN. 3.4. Internet access In many VPNs, VPN will need to both access the public Internet as well as to access other sites within the same VPN. The "internet-access" container contains internet access option and Internet-gateway-IP list. And Internet-gateway-IP is only used for the central Internet access case. A central internet access means traffic from different sites aggregates to central Internet access gateway and forwards via the gateway. An internet access service can include Network Address Translation (NAT) to enable the customer to use private IP addresses within their networks. In addition, each site could have its own Internet access links. In case of local break-out for Internet access, traffic from specific site could access the internet directly by setting access option as local. In Implementation, service provider could combine two options to fulfill customer needs. 3.5. Interworking with conventional VPN In some cases, there is a need that certain SD-WAN subVPNs communicate with conventional VPNs. An interworking-gateway allows sites interconnected via the MPLS VPN to communicate with sites interconnected via SD-WAN VPN over the Internet. A interworking- gateway or several gateways could be specified to serve this requirement. The "vpn-interworking" container contains "interworking-gateway-IP" used to connect a specific subVPN located at a site to the MPLS VPN network. 4. Modules Tree Structure This document defines sd-wan-vpn yang data model. module: ietf-sdwan-vpn-svc +--rw sdwan-vpn-svc Sun, et al. Expires April 24, 2019 [Page 12] Internet-Draft SD-WAN Service YANG Model October 2018 +--rw sdwan-vpn* [vpn-id] +--rw vpn-id svc-id +--rw customer-name? svc-id +--rw wan-transport-networks* [wan-transport-name] | +--rw wan-transport-name string | +--rw wan-transport-type? identityref +--rw security | +--rw algorithm? string | +--rw preshared-key? string +--rw application-group* [group-name] | +--rw group-name string | +--rw application-name* string +--rw classification-profile* [name] | +--rw name string | +--rw rule* [id] | +--rw id string | +--rw (match-type)? | +--:(match-flow) | | +--rw match-flow | | +--rw dscp? inet:dscp | | +--rw dot1p? uint8 | | +--rw ipv4-src-prefix? inet:ipv4-prefix | | +--rw ipv6-src-prefix? inet:ipv6-prefix | | +--rw ipv4-dst-prefix? inet:ipv4-prefix | | +--rw ipv6-dst-prefix? inet:ipv6-prefix | | +--rw l4-src-port? inet:port-number | | +--rw l4-src-port-range | | | +--rw lower-port? inet:port-number | | | +--rw upper-port? inet:port-number | | +--rw l4-dst-port? inet:port-number | | +--rw l4-dst-port-range | | | +--rw lower-port? inet:port-number | | | +--rw upper-port? inet:port-number | | +--rw protocol-field? union | +--:(match-application-group) | +--rw match-application-group? string +--rw qos-profile* [name] | +--rw name string | +--rw bd-limit-type? identityref | +--rw percent | | +--rw width-percent? uint32 | +--rw value | +--rw cir? uint32 | +--rw pir? uint32 +--rw sites | +--rw site* [site-id] | +--rw site-id svc-id | +--rw location* [email] Sun, et al. Expires April 24, 2019 [Page 13] Internet-Draft SD-WAN Service YANG Model October 2018 | | +--rw email string | | +--rw postcode? string | | +--rw address? string | +--rw device* [name] | +--rw name string | +--rw type? string | +--rw transport-network-port* [name] | +--rw name string | +--rw access-type? identityref | +--rw ip-connection | | +--rw type? identityref | | +--rw static | | +--rw customer-addr? inet:ip-address | | +--rw prefix? inet:ip-prefix | | +--rw provider-addr? inet:ip-address | +--rw routing-protocol* [type] | | +--rw type identityref | | +--rw ospf | | | +--rw address-family* address-family | | | +--rw area-address yang:dotted-quad | | | +--rw metric? uint16 | | +--rw bgp | | | +--rw autonomous-system uint32 | | | +--rw address-family* address-family | | +--rw static | | +--rw ip-lan-prefixes* [lan next-hop] | | +--rw lan inet:ip-prefix | | +--rw next-hop inet:ipv4-address | | +--rw priority? uint16 | +--rw bandwidth | +--rw input-bandwidth? uint64 | +--rw output-bandwidth? uint64 | +--rw mtu? uint16 +--rw subvpn* [subvpn-id] +--rw subvpn-id svc-id +--rw topology? identityref +--rw logical-access* [site-id] | +--rw site-id -> /sdwan-vpn-svc/sdwan-vpn/sites/site/site-id | +--rw site-role? identityref | +--rw vlan-tag? uint16 | +--rw ip-address? inet:ip-address | +--rw ip-prefix? inet:ip-prefix | +--rw routing-protocol* [type] | +--rw type identityref | +--rw ospf | | +--rw address-family* address-family | | +--rw area-address yang:dotted-quad Sun, et al. Expires April 24, 2019 [Page 14] Internet-Draft SD-WAN Service YANG Model October 2018 | | +--rw metric? uint16 | +--rw bgp | | +--rw autonomous-system uint32 | | +--rw address-family* address-family | +--rw static | +--rw ip-lan-prefixes* [lan next-hop] | +--rw lan inet:ip-prefix | +--rw next-hop inet:ipv4-address | +--rw priority? uint16 +--rw policies +--rw path-selection-policy* [name] | +--rw name string | +--rw rule* [rule-id] | +--rw rule-id string | +--rw priority? uint32 | +--rw classification-name? -> /sdwan-vpn-svc/sdwan-vpn/classification-profile/name | +--rw traffic-sla-profile* [name] | | +--rw name string | | +--rw latency? uint32 | | +--rw jitter? uint32 | | +--rw packet-loss-rate? uint32 | +--rw transport-network-primary? string | +--rw transport-network-sencondry? string +--rw qos-bandwidth-policy* [name] | +--rw name string | +--rw priorty? uint32 | +--rw qos | +--rw classification-name? -> /sdwan-vpn-svc/sdwan-vpn/classification-profile/name | +--rw qos-profile-name? -> /sdwan-vpn-svc/sdwan-vpn/qos-profile/name +--rw traffic-filter* [site-id] | +--rw site-id -> /sdwan-vpn-svc/sdwan-vpn/sites/site/site-id | +--rw classification-name? -> /sdwan-vpn-svc/sdwan-vpn/classification-profile/name | +--rw direction? identityref | +--rw action? identityref +--rw internet-access | +--rw access-option? uint32 | +--rw internet-gateway-ip* inet:ip-address | +--rw nat? uint32 | +--rw nat44-ip-addr? inet:ip-address +--rw vpn-interworking +--rw site* -> /sdwan-vpn-svc/sdwan-vpn/sites/site/site-id Sun, et al. Expires April 24, 2019 [Page 15] Internet-Draft SD-WAN Service YANG Model October 2018 5. YANG Modules file "ietf-sdwan-vpn-svc@2018-09-24.yang" module ietf-sdwan-vpn-svc { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-sdwan-vpn-svc"; prefix sdwan-vpn-svc; import ietf-inet-types { prefix inet; } import ietf-yang-types { prefix yang; } organization "IETF foo Working Group."; contact "WG List: foo@ietf.org Editor: "; description "The YANG module defines a generic service configuration model for SD-WAN VPN."; revision 2018-09-25 { description "Initial revision"; reference "A YANG Data Model for SD-WAN VPN."; } typedef svc-id { type string; description "Type definition for servicer identifier"; } typedef address-family { type enumeration { enum ipv4 { description "IPv4 address family."; } enum ipv6 { description "IPv6 address family."; } } Sun, et al. Expires April 24, 2019 [Page 16] Internet-Draft SD-WAN Service YANG Model October 2018 description "Defines a type for the address family."; } identity vpn-topology { description "Base identity for vpn topology."; } identity any-to-any { base vpn-topology; description "Identity for any-to-any VPN topology."; } identity hub-spoke { base vpn-topology; description "Identity for Hub-and-Spoke VPN topology."; } identity site-role { description "Site Role in a VPN topology "; } identity any-to-any-role { base site-role; description "Site in an any-to-any IP VPN."; } identity hub { base site-role; description "Hub Role in Hub-and-Spoke IP VPN."; } identity spoke { base site-role; description "Spoke Role in Hub-and-Spoke IP VPN."; } identity access-type { description "Access type of a site in a connection to WAN network"; } Sun, et al. Expires April 24, 2019 [Page 17] Internet-Draft SD-WAN Service YANG Model October 2018 identity ge { base access-type; description "GE"; } identity ef { base access-type; description "EF"; } identity xge { base access-type; description "XGE"; } identity lte { base access-type; description "LTE"; } identity xdsl-atm { base access-type; description "xDSL(ATM)"; } identity xdsl-ptm { base access-type; description "xDSL(PTM)"; } identity routing-protocol-type { description "Base identity for routing protocol type."; } identity ospf { base routing-protocol-type; description "Identity for OSPF protocol type."; } identity bgp { Sun, et al. Expires April 24, 2019 [Page 18] Internet-Draft SD-WAN Service YANG Model October 2018 base routing-protocol-type; description "Identity for BGP protocol type."; } identity static { base routing-protocol-type; description "Identity for static routing protocol type."; } identity addr-allocation { description "Base identity for address allocation"; } identity addr-allocation-static { base addr-allocation; description "Static"; } identity traffic-direction { description "Base identity for traffic direction"; } identity inbound { base traffic-direction; description "Identity for inbound"; } identity outbound { base traffic-direction; description "Identity for outbound"; } identity both { base traffic-direction; description "Identity for both"; } identity traffic-action { description "Base identity for traffic action"; Sun, et al. Expires April 24, 2019 [Page 19] Internet-Draft SD-WAN Service YANG Model October 2018 } identity permit { base traffic-action; description "Identity for permit action"; } identity deny { base traffic-action; description "Identity for deny action"; } identity bd-limit-type { description "base identity for bd limit type"; } identity percent { base bd-limit-type; description "Identity for percent"; } identity value { base bd-limit-type; description "Identity for value"; } grouping qos-bandwidth-policy { list qos-bandwidth-policy { key "name"; leaf name { type string; description "QoS name"; } leaf priorty { type uint32; description "Priorty"; } container qos { leaf classification-name { type leafref { path "/sdwan-vpn-svc/sdwan-vpn/classification-profile/name"; Sun, et al. Expires April 24, 2019 [Page 20] Internet-Draft SD-WAN Service YANG Model October 2018 } description "Qos Classification name"; } leaf qos-profile-name { type leafref { path "/sdwan-vpn-svc/sdwan-vpn/qos-profile/name"; } description "Qos profile name"; } description "Container for QOS"; } description "List for qos policy"; } description "Gourping for qos-bandwidth-policy"; } grouping qos-profile { list qos-profile { key "name"; leaf name { type string; description "QOS profile name"; } leaf bd-limit-type { type identityref { base bd-limit-type; } description "bd limit type"; } container percent { when "../bd-limit-type = 'percent'"; leaf width-percent { type uint32; description "Width percent"; } description "Container for percent"; } container value { when "../bd-limit-type = 'value'"; Sun, et al. Expires April 24, 2019 [Page 21] Internet-Draft SD-WAN Service YANG Model October 2018 leaf cir { type uint32; description "CIR"; } leaf pir { type uint32; description "PIR"; } description "Container for value"; } description "List for qos profile"; } description "Grouping for qos profile"; } grouping application-group { list application-group { key "group-name"; leaf group-name { type string; description "Gourp name"; } leaf-list application-name { type string; description "Application name"; } description "List for application group"; } description "Grouping for application-group"; } grouping path-selection-policy { list path-selection-policy { key "name"; leaf name { type string; description "Policy name"; } Sun, et al. Expires April 24, 2019 [Page 22] Internet-Draft SD-WAN Service YANG Model October 2018 list rule { key "rule-id"; leaf rule-id { type string; description "Rule id"; } leaf priority { type uint32; description "Priority"; } leaf classification-name { type leafref { path "/sdwan-vpn-svc/sdwan-vpn/classification-profile/name"; } description "QOS Classification NAME"; } list traffic-sla-profile { key "name"; leaf name { type string; description "traffic sla profile"; } leaf latency { type uint32; description "latency"; } leaf jitter { type uint32; description "jitter"; } leaf packet-loss-rate { type uint32; description "packet loss rate"; } description "traffic sla profile"; } leaf transport-network-primary { type string; description "Primary transport network preferred"; Sun, et al. Expires April 24, 2019 [Page 23] Internet-Draft SD-WAN Service YANG Model October 2018 } leaf transport-network-sencondry { type string; description "Sencondry transport network preferred"; } description "List for Rule"; } description "List for path selection policy"; } description "Grouping for path-selection-policy"; } grouping internet-access { container internet-access { leaf access-option { type uint32; description "internet access via local breakout or central gateway"; } leaf-list internet-gateway-ip { type inet:ip-address; description "Internet gateway IP"; } leaf nat { type uint32; description "NAT"; } leaf nat44-ip-addr { type inet:ip-address; description "Static nat custom internet IP. Address to be used for network address translation from IPv4 to IPv4. This is to be used if the customer is providing the IPv4 address. If the customer address is not set, the model assumes that the provider will allocate the address."; } description "Container for internet access"; } description "Grouping for internet-access"; } Sun, et al. Expires April 24, 2019 [Page 24] Internet-Draft SD-WAN Service YANG Model October 2018 grouping vpn-interworking { container vpn-interworking { leaf-list site { type leafref { path "/sdwan-vpn-svc/sdwan-vpn/sites/site/site-id"; } description "List for interworking gateway for traditional MPLS VPN "; } description "List for traditional MPLS VPN interworking"; } description "Grouping for vpn-interworking"; } grouping traffic-filter-policy { list traffic-filter { key "site-id"; leaf site-id { type leafref { path "/sdwan-vpn-svc/sdwan-vpn/sites/site/site-id"; } description "Site id"; } leaf classification-name { type leafref { path "/sdwan-vpn-svc/sdwan-vpn/classification-profile/name"; } description "Classification profile name"; } leaf direction { type identityref { base traffic-direction; } description "Traffic direction"; } leaf action { type identityref { base traffic-action; } description "Action"; } description Sun, et al. Expires April 24, 2019 [Page 25] Internet-Draft SD-WAN Service YANG Model October 2018 "List for traffic filter"; } description "Grouping for traffic filter"; } grouping flow-definition { container match-flow { leaf dscp { type inet:dscp; description "DSCP value."; } leaf dot1p { type uint8 { range "0..7"; } description "802.1p matching."; } leaf ipv4-src-prefix { type inet:ipv4-prefix; description "Match on IPv4 src address."; } leaf ipv6-src-prefix { type inet:ipv6-prefix; description "Match on IPv6 src address."; } leaf ipv4-dst-prefix { type inet:ipv4-prefix; description "Match on IPv4 dst address."; } leaf ipv6-dst-prefix { type inet:ipv6-prefix; description "Match on IPv6 dst address."; } leaf l4-src-port { type inet:port-number; must "'.' <= '../l4-src-port-range/lower-port' and'.'>= '../l4-src-port-range/upper-port'" { description " If l4-src-port and l4-src-port-range/lower-port and upper-port are set at the same time, l4-src-port should not overlap with l4-src-port-range. "; } Sun, et al. Expires April 24, 2019 [Page 26] Internet-Draft SD-WAN Service YANG Model October 2018 description "Match on Layer 4 src port."; } container l4-src-port-range { leaf lower-port { type inet:port-number; description "Lower boundary for port."; } leaf upper-port { type inet:port-number; must '. >= ../lower-port' { description " Upper boundary for port. If it exists, upper boundary must be higher than lower boundary."; } description "Upper boundary for port."; } description "Match on Layer 4 src port range. When only lower-port is present, it represents a single port. When both lower-port and upper-port are specified, it implies a range inclusive of both values."; } leaf l4-dst-port { type inet:port-number; must '. <= ../l4-dst-port-range/lower-port and.>= ../l4-dst-port-range/upper-port' { description " If l4-dst-port and l4-dst-port-range/lower-port and upper-port are set at the same time, l4-dst-port should not overlap with l4-src-port-range. "; } description "Match on Layer 4 dst port."; } container l4-dst-port-range { leaf lower-port { type inet:port-number; description "Lower boundary for port."; } leaf upper-port { type inet:port-number; must '. >= ../lower-port' { description "Upper boundary must be Sun, et al. Expires April 24, 2019 [Page 27] Internet-Draft SD-WAN Service YANG Model October 2018 higher than lower boundary."; } description "Upper boundary for port. If it exists, upper boundary must be higher than lower boundary."; } description "Match on Layer 4 dst port range. When only lower-port is present, it represents a single port. When both lower-port and upper-port are specified, it implies a range inclusive of both values."; } leaf protocol-field { type union { type uint8; type identityref { base routing-protocol-type; } } description "Match on IPv4 protocol or IPv6 Next Header field."; } description "Describes flow-matching criteria."; } description "Flow definition based on criteria."; } grouping classification-profile { list classification-profile { key "name"; leaf name { type string; description "classification name"; } list rule { key "id"; ordered-by user; leaf id { type string; description "A description identifying qos classification policy rule."; } choice match-type { default "match-flow"; Sun, et al. Expires April 24, 2019 [Page 28] Internet-Draft SD-WAN Service YANG Model October 2018 case match-flow { uses flow-definition; } case match-application-group { leaf match-application-group { type string; description "Defines the application to match."; } } description "Choice for classification."; } description "List of marking rules."; } description "List for classification profile"; } description "Gourping for classification profile"; } grouping routing-protocol { list routing-protocol { key "type"; leaf type { type identityref { base routing-protocol-type; } description "Routing protocol type"; } container ospf { when "derived-from-or-self(../type, 'sdwan-vpn-svc:ospf')" { description "Only applies when protocol is OSPF."; } leaf-list address-family { type address-family; min-elements 1; description "If OSPF is used on this site, this node contains a configured value. This node contains at least one address family to be activated."; } leaf area-address { Sun, et al. Expires April 24, 2019 [Page 29] Internet-Draft SD-WAN Service YANG Model October 2018 type yang:dotted-quad; mandatory true; description "Area address."; } leaf metric { type uint16; default "1"; description "Metric of the PE-CE link. It is used in the routing state calculation and path selection."; } description "OSPF-specific configuration."; } container bgp { when "derived-from-or-self(../type, 'sdwan-vpn-svc:bgp')" { description "Only applies when protocol is BGP."; } leaf autonomous-system { type uint32; mandatory true; description "Customer AS number in case the customer requests BGP routing."; } leaf-list address-family { type address-family; min-elements 1; description "If BGP is used on this site, this node contains a configured value. This node contains at least one address family to be activated."; } description "BGP-specific configuration."; } container static { when "derived-from-or-self(../type, 'sdwan-vpn-svc:static')" { description "Only applies when protocol is static. BGP activation requires the SP to know the address of the customer peer. When BGP is enabled, the 'static-address' allocation type for the IP connection Sun, et al. Expires April 24, 2019 [Page 30] Internet-Draft SD-WAN Service YANG Model October 2018 MUST be used."; } list ip-lan-prefixes { key "lan next-hop"; leaf lan { type inet:ip-prefix; description "LAN prefixes."; } leaf next-hop { type inet:ipv4-address; description "Next-hop address to use on the customer side."; } leaf priority { type uint16; description "Prority"; } description "List of LAN prefixes for the site."; } description "Configuration specific to static routing."; } description "List for Routing Protocol"; } description "Grouping for routing protocol"; } container sdwan-vpn-svc { list sdwan-vpn { key "vpn-id"; leaf vpn-id { type svc-id; description "VPN identifier. Local administration meaning."; } leaf customer-name { type svc-id; description "Id for customer"; } list wan-transport-networks { key "wan-transport-name"; leaf wan-transport-name { Sun, et al. Expires April 24, 2019 [Page 31] Internet-Draft SD-WAN Service YANG Model October 2018 type string; description "WAN transport network name"; } leaf wan-transport-type { type identityref { base access-type; } description "Access type"; } description "WAN transport network type"; } container security { leaf algorithm { type string; description "Encryption algorithm to be used"; } leaf preshared-key { type string; description "Pre-Shared Key (PSK) from individual customer."; } description "Container for IPSEC VPN encryption parameters"; } uses application-group; uses classification-profile; uses qos-profile; container sites { list site { key "site-id"; leaf site-id { type svc-id; description "Site Name"; } list location { key "email"; leaf email { type string; description "List for email"; } leaf postcode { type string; Sun, et al. Expires April 24, 2019 [Page 32] Internet-Draft SD-WAN Service YANG Model October 2018 description "Post code"; } leaf address { type string; description "Location address"; } description "List for location"; } list device { key "name"; leaf name { type string; description "Device Name"; } leaf type { type string; description "Device Type"; } list transport-network-port { key "name"; leaf name { type string; description "transport network port name"; } leaf access-type { type identityref { base access-type; } description "Access type"; } container ip-connection { leaf type { type identityref { base addr-allocation; } description "Address allocation type"; } container static { when "../type = 'addr-allocation-static'"; leaf customer-addr { Sun, et al. Expires April 24, 2019 [Page 33] Internet-Draft SD-WAN Service YANG Model October 2018 type inet:ip-address; description "Customer address"; } leaf prefix { type inet:ip-prefix; description "IP Prefix"; } leaf provider-addr { type inet:ip-address; description "Provider address"; } description "Container for static"; } description "Container for ip connection"; } uses routing-protocol; container bandwidth { leaf input-bandwidth { type uint64; description "input bandwidth"; } leaf output-bandwidth { type uint64; description "output bandwidth"; } leaf mtu { type uint16; description "MTU"; } description "Container for bandwidth profile"; } description "List for transport network ports"; } description "List for devices"; } description "List for sites"; Sun, et al. Expires April 24, 2019 [Page 34] Internet-Draft SD-WAN Service YANG Model October 2018 } description "Container for sites"; } list subvpn { key "subvpn-id"; leaf subvpn-id { type svc-id; description "subVPN network identifier"; } leaf topology { type identityref { base vpn-topology; } description "subVPN topology: hub&spoke or any-to-any"; } list logical-access { key "site-id"; leaf site-id { type leafref { path "/sdwan-vpn-svc/sdwan-vpn/sites/site/site-id"; } description "The site that the logic-access attached."; } leaf site-role { type identityref { base site-role; } default "any-to-any-role"; description "Role of the site in the subVPN."; } leaf vlan-tag { type uint16; description "VLAN TAG"; } leaf ip-address { type inet:ip-address; description "IP Address"; } leaf ip-prefix { type inet:ip-prefix; description Sun, et al. Expires April 24, 2019 [Page 35] Internet-Draft SD-WAN Service YANG Model October 2018 "IP Prefix"; } uses routing-protocol; description "container for logical access"; } container policies { uses path-selection-policy; uses qos-bandwidth-policy; uses traffic-filter-policy; uses internet-access; uses vpn-interworking; description "container for policies"; } description "List for subVPN network"; } description "List for SD-WAN"; } description "Container for SD-WAN VPN service"; } } 6. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC5246]. The NETCONF access control model [RFC6536]provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative Sun, et al. Expires April 24, 2019 [Page 36] Internet-Draft SD-WAN Service YANG Model October 2018 effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability. 7. IANA Considerations IANA has assigned a new URI from the "IETF XML Registry" [RFC3688]. URI: urn:ietf:params:xml:ns:yang:ietf-sdwan-vpn-svc Registrant Contact: The IESG XML: N/A; the requested URI is an XML namespace. IANA has recorded a YANG module name in the "YANG Module Names" registry [RFC6020] as follows: Name: ietf-sdwan-vpn-svc Namespace: urn:ietf:params:xml:ns:yang:ietf-sdwan-vpn-svc Prefix: sdwan-svc Reference: RFC xxxx 8. Acknowledgments This work has benefited from the discussions of xxxx. 9. Contributors The authors would like to thank Zitao Wang and Qin Wu for their major contributions to the initial modeling. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . Sun, et al. Expires April 24, 2019 [Page 37] Internet-Draft SD-WAN Service YANG Model October 2018 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 10.17487/RFC4664, September 2006, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, DOI 10.17487/RFC6071, February 2011, . [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018, . 10.2. Informative References [I-D.carrel-ipsecme-controller-ike] Carrel, D. and B. Weis, "IPsec Key Exchange using a Controller", draft-carrel-ipsecme-controller-ike-00 (work in progress), July 2018. [I-D.dukes-spring-sr-for-sdwan] Dukes, D., Filsfils, C., Dawra, G., Xu, X., daniel.voyer@bell.ca, d., Camarillo, P., Clad, F., and S. Salsano, "SR For SDWAN: VPN with Underlay SLA", draft- dukes-spring-sr-for-sdwan-00 (work in progress), June 2018. [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] Lopez, R. and G. Lopez-Millan, "Software-Defined Networking (SDN)-based IPsec Flow Protection", draft-ietf- i2nsf-sdn-ipsec-flow-protection-02 (work in progress), July 2018. [I-D.ietf-l3vpn-ce-based] Clercq, J., "An Architecture for Provider Provisioned CE- based Virtual Private Networks using IPsec", draft-ietf- l3vpn-ce-based-03 (work in progress), December 2005. Sun, et al. Expires April 24, 2019 [Page 38] Internet-Draft SD-WAN Service YANG Model October 2018 [I-D.rosen-bess-secure-l3vpn] Rosen, E. and R. Bonica, "Augmenting RFC 4364 Technology to Provide Secure Layer L3VPNs over Public Infrastructure", draft-rosen-bess-secure-l3vpn-01 (work in progress), June 2018. [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, DOI 10.17487/RFC4110, July 2005, . [RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L., Kreeger, L., and M. Napierala, "Problem Statement: Overlays for Network Virtualization", RFC 7364, DOI 10.17487/RFC7364, October 2014, . Authors' Addresses Qiong Sun China Telecom Beijing China Email: sunqiong.bri@chinatelecom.cn Honglei Xu China Telecom Beijing China Email: sunqiong.bri@chinatelecom.cn Bo Wu Huawei Nanjing China Email: lana.wubo@huawei.com Sun, et al. Expires April 24, 2019 [Page 39] Internet-Draft SD-WAN Service YANG Model October 2018 Qin Wu Huawei Nanjing China Email: bill.wu@huawei.com Sun, et al. Expires April 24, 2019 [Page 40]