| Operations and Management Area Working Group | Q. Sun |
| Internet-Draft | H. Xu |
| Intended status: Standards Track | China Telecom |
| Expires: April 25, 2019 | B. Wu |
| Q. Wu | |
| Huawei | |
| October 22, 2018 |
A YANG Data Model for SD-WAN VPN Service Delivery
draft-sun-opsawg-sdwan-service-model-01
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.
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 25, 2019.
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 (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.
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 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. This service model defines the following main components which is also reflected in other SD-WAN work in IETF:
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.
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.
CE Device: Customer Edge Device , as per Provider Provisioned VPN Terminology .
PE Device: Provider Edge Device, as per Provider Provisioned VPN Terminology
CE-based VPN: Refers to Provider Provisioned VPN Terminology
PE-Based VPNs: Refers to Provider Provisioned VPN Terminology
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 has specified same concept.
+-------------+
+------------+ | +---+ |
| 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
An example of SD-WAN VPN network architecture is presented in 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. 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:
[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.
+---------+
|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
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.
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.
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 Protectionand IPsec Key Exchange using a Controller are two new controller based methods to optimize IPSEC process to better management in SDN context.
The policy templates consist of application group, classification profile and qos profile, which would be used by all the subVPNs.
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.
A site represents a customer office located at a specific location. The "sites" container is to specify three main information:
+---------------------------------+ | site | | | | | | | | | | | | | | TNP1 TNP2 TNP3 TNP4 | | +--------+ +--------+ | | | | | | | | |Device 1| |Device 2| | | +--------+ +--------+ | +---------------------------------+ Legend: TNP (Transport Network Port)
figure 3
The transport-network consists of the following categories of parameters:
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.
a subVPN | Logical
| Access 1
+
+--+--+
|site3|
+--X--+
/ \
/ \
/ \ Logical
/ \ Access 1
+-----+/ \+------+ +--------
-------+---+site2+-----------|site 1+-+
Logical +-----+ +------+ +--------
Access 1 Logical
Access 2
figure 4
The "policies" container under the "subVPN" list is used contain all the policies defined in a subVPN service.
The path-selection-policy container is under policies container, and it has the following parameters:
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.
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 shaping) and bandwidth represented by percentage value or absolute value.
Traffic filter is a class of security policy used to filter flow for each subVPN.
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.
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.
This document defines sd-wan-vpn yang data model.
module: ietf-sdwan-vpn-svc
+--rw sdwan-vpn-svc
+--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]
| | +--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
| | +--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
<CODE BEGINS> 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.";
}
}
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";
}
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 {
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";
}
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";
}
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'";
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";
}
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";
}
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";
}
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
"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. ";
}
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
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";
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 {
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
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 {
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;
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 {
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";
}
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
"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";
}
}
<CODE ENDS>
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 effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability.
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
This work has benefited from the discussions of xxxx.
The authors would like to thank Zitao Wang and Qin Wu for their major contributions to the initial modeling.
| [I-D.carrel-ipsecme-controller-ike] | Carrel, D. and B. Weis, "IPsec Key Exchange using a Controller", Internet-Draft draft-carrel-ipsecme-controller-ike-00, 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", Internet-Draft draft-dukes-spring-sr-for-sdwan-00, June 2018. |
| [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] | Lopez, R. and G. Lopez-Millan, "Software-Defined Networking (SDN)-based IPsec Flow Protection", Internet-Draft draft-ietf-i2nsf-sdn-ipsec-flow-protection-02, July 2018. |
| [I-D.ietf-l3vpn-ce-based] | Clercq, J., "An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec", Internet-Draft draft-ietf-l3vpn-ce-based-03, December 2005. |
| [I-D.rosen-bess-secure-l3vpn] | Rosen, E. and R. Bonica, "Augmenting RFC 4364 Technology to Provide Secure Layer L3VPNs over Public Infrastructure", Internet-Draft draft-rosen-bess-secure-l3vpn-01, 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., Gray, E., Black, D., Fang, L., Kreeger, L. and M. Napierala, "Problem Statement: Overlays for Network Virtualization", RFC 7364, DOI 10.17487/RFC7364, October 2014. |