A YANG Data Model for SD-WAN VPN Service Delivery
draft-sun-opsawg-sdwan-service-model-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Qiong Sun , Bo Wu , Qin Wu | ||
| Last updated | 2018-10-22 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sun-opsawg-sdwan-service-model-01
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
<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.";
}
}
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";
}
}
<CODE ENDS>
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005,
<https://www.rfc-editor.org/info/rfc4026>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
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,
<https://www.rfc-editor.org/info/rfc4664>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
DOI 10.17487/RFC6071, February 2011,
<https://www.rfc-editor.org/info/rfc6071>.
[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,
<https://www.rfc-editor.org/info/rfc8299>.
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,
<https://www.rfc-editor.org/info/rfc4110>.
[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,
<https://www.rfc-editor.org/info/rfc7364>.
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]