| Operations and Management Area Working Group | Q. Sun |
| Internet-Draft | China Telecom |
| Intended status: Standards Track | B. Wu |
| Expires: December 29, 2018 | Huawei |
| June 27, 2018 |
YANG Data Model for SD-WAN VPN service model delivery
draft-sun-opsawg-sdwan-service-model-00
This document defines a YANG data model that can be used for communication between customers and network operators to deliver agile, assured IP connectivity, overlay VPN service, which is also referred to as SD-WAN VPN Service. This model provides an abstracted view of the SD-WAN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.
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 December 29, 2018.
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.
BGP/MPLS IP VPNs [RFC4364] as widely deployed technology can provide IP network connectivity over the backbone between IP VPN sites. Though having some similarity with the connectivity services offered by BGP/MPLS IP VPNs, SD-WAN(software-defined wide-area network) utilizes overlay networking technology and enable application driven networking to deliver agile, assured IP connectivity services for enterprise customer.
SD-WAN can be built on top of various underlay networks and allow multiple parallel paths between two or more sites . More specifically, two sites can be interconnected by a traditional MPLS VPN ([RFC4364] or [RFC4664]),or by public Internet using fiber, cable, DSL-based Internet access, WiFi, or 4G/Long Term Evolution (LTE)as well as by overlay tunnels. The overlay is possibly further secured by IPsec tunnels [RFC6071].Typical SD-WAN use cases are providing SD-WAN sites with secure multi-site VPN service between them, access to Internet or interconnection with traditional VPN sites.
In addition to basic connection service, SD-WAN can use policies to prioritize traffic for diverse applications used in enterprises, such as VoIP calling, videoconferencing, streaming media etc. Therefore, application traffic can be forwarded over different WANs or overlay connections based on QoS, Security and other constraints and dynamically switched among them depending on real-time measurement of the user traffic flowing through.
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.
Customer Edge (CE) Device: A CE is equipment dedicated to a particular customer; it is directly connected (at Layer 3) to one or more PE devices via attachment circuits.
Provider Edge (PE) Device: A PE is equipment managed by the SP; it can support multiple VPNs for different customers and is directly connected (at Layer 3) to one or more CE devices via attachment circuits. A PE is usually located at an SP point of presence (POP) and is managed by the SP.
CE-based VPN: Refers to an approach in which the PE devices do not know anything about the routing or the addressing of the customer networks. The PE devices offer a simple IP service, and expect to receive IP packets whose headers contain only globally unique IP addresses. What makes a CE-based VPN into a Provider-Provisioned VPN is that the SP takes on the task of managing and provisioning the CE devices
PE-Based VPNs: The PE devices know that certain traffic is VPN traffic. They forward the traffic (through tunnels) based on the destination IP address of the packet and, optionally, based on other information in the IP header of the packet. The PE devices are themselves the tunnel endpoints. The tunnels may make use of various encapsulations to send traffic over the SP network (such as, but not restricted to, GRE, IP-in-IP, IPsec, or MPLS tunnels).
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 cutomer 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 .
L3VPN Service Model defined in [RFC8299] is used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service.
SD-WAN VPN is also a layer 3 VPN service provided between two or more SD-WAN sites and offers basic logic IP connection service among the sites and advanced application aware services for traffic flowing into or out of the connection as well.
In L3VPN service model, the "vpn-services" and "sites" are defined as two core parameters.The vpn-services container defines general service parameters such as VPN topology for a virtual IP connection and other common service descriptions like multicast, extranet etc. And the "sites" container is used to describe customer sites interconnected by the virtual IP connection. Furthermore, sites contains the IP connection parameters including routing protocol needed to expose to an enterprise customer network. This draft uses them as basis to define IP connectivity service in SD-WAN VPN.
In addition, Application application aware policy services are defined as advanced SD-WAN services. The policies consist of path selection policy, QoS policy, security policy, Internet access policy and VPN interworking policy. A path selection policy is used to perform an application dynamic control behavior using multiple WAN links located at a specific site. A QoS policy is used to specify QoS requirements, such as bandwidth of a specific application or an application group within a segment. And security policy is used to filter specific traffic in terms of security consideration.Internet access policy and VPN interworking policy are parameters used to access external resources in Internet or traditional VPN.
Moreover, to provide fine granularity of traffic isolation within a tenant, a "segment-networks" container under the "sdwan-vpn" is proposed and represent virtual network services within each enterprise customer network, including parameters like segment topology and routing protocols of customer network attached.
Figure 1 below shows an example of the enterprise customer with four sites. Site 1 to site 3 are all SD-WAN sites, and site 1 and site 3 both have two WAN links connected to underlay transport networks, one is IP/MPLS VPN and the other is Internet. Site 2 has only one Internet WAN link. Unlike the others, site 4 is a traditional MPLS VPN site. And this customer needs to build up three segments to separate its traffic flowing over WAN tranport network.
SD-WAN
segment1
----------------------------------------------------
segment2
----------------------------------------------------
segment3
----------------------------------------------------
| |
site4 | ------------------ | site 3
+-----+ /+---+ +---+ \ | +-----+
--| CE |--------|PE | |PE |-----------| CE |---
+-----+ | +---+ +---+ | /+-----+
site1 | IP/MPLS | /
+-----+ | +---+ | /
--| CE |-------------- |PE | / /
+-----+\ \ +---+ / /
\ -------------- /
\ -------- /
-------/ \ /
| Internet|
site2 | |
+-----+ / \ /
-| CE |--------/ --------
+-----+
Figure 1 SD-WAN VPN service
The "sdvpn-vpn-svc" list item contains generic information about the 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 under the root container 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 .
A site represents a customer office located at a specific location. A site could have one or more devices and one or more transport network links.
The "sites" container contains device, location parameters and the "transport-network" container.
The transport-network container is used to specify underlay network link parameters. It consists of the following categories of parameters:
The "segment-networks" is a container directly under the "sdwan-vpn-svc" and it is used to represent logical networks in a particular enterprise SD-WAN network. The intention of segment network is to separate one SD-WAN network into multiple virtual networks to ensure per segment traffic separation in site to site or site to external network interconnection.
Each segment 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.
Based on the requested VPN service topology and the site list, overlay tunnels could be set up between sites over underlay networks automatically.
The "lan-network" list under the "segment-network" is used to represent one or more customer LAN networks attached from different sites belonged to a segment network. The list is composed of VLAN , IP connection and routing protocol parameters exposed by the customer networks.
In the figure below, there are three segments constructed for a customer between two sites to separate the traffic from three departments.
site 1--------| |------site 2
+------+ | +----------+ | +------+
LAN1-------|----- |---------------------+ segment A+--------|------|-----LAN1
| CE |****(TN#1 MPLS VPN) +----------+ ****| CE |
LAN2-------|----- |****(TN#2 Internet) -+ segment B+------- |------|-----LAN2
| |****(TN#3 LTE ) +----------+ ****| |
LAN3--- ---|----- |---------------------+ segment C+--------|------|-----LAN3
+------+ | +----------+ | +------+
| |
The "policies" container under the "sdwan-vpn" list is used contain all the policies and all the policy templates defined in a SD-WAN VPN service.
The policy templates have application group, classification profile and qos profile.
The"application-group" 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.
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 SD-WAN VPN 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 either over overlay network or underlay network.
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 sites or segments communicate with traditional VPN sites. An interworking-gateway allows sites interconnected via the MPLS VPN to communicate with sites interconnected via SD-WAN tunnels over the Internet. A interworking-gateway or several gateways could be specified to serve this requirment.
The "vpn-interworking" container contains "interworking-gateway-IP" used to connect a specific segment located at a site to the legacy VPN network.
This document defines sd-wan 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 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* [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 segment-networks* [segment-id]
| +--rw segment-id svc-id
| +--rw topology? identityref
| +--rw sites* [site-id]
| | +--rw site-id leafref
| | +--rw site-role? identityref
| +--rw lan-networks* [site-id]
| +--rw site-id leafref
| +--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 segment-network? leafref
| +--rw site* leafref
| +--rw rule* [rule-id]
| +--rw rule-id string
| +--rw priority? uint32
| +--rw classification-name? leafref
| +--rw traffic-sla-profile* [name]
| | +--rw name string
| | +--rw latency? uint32
| | +--rw jitter? uint32
| | +--rw packet-loss-rate? uint32
| +--rw path-primary? string
| +--rw path-sencondry? string
+--rw qos-bandwidth-policy* [name]
| +--rw name string
| +--rw priorty? uint32
| +--rw qos
| +--rw classification-name? leafref
| +--rw qos-profile-name? leafref
+--rw traffic-filter* [site-id]
| +--rw site-id leafref
| +--rw classification-name? leafref
| +--rw direction? identityref
| +--rw action? identityref
+--rw internet-access* [site-id]
| +--rw site-id leafref
| +--rw access-option? uint32
| +--rw internet-gateway-ip* inet:ip-address
| +--rw nat? uint32
| +--rw nat44-ip-addr? inet:ip-address
+--rw vpn-interworking* [site-id]
| +--rw site-id leafref
| +--rw vpn-gateway-ip? inet:ip-address
+--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
<CODE BEGINS> file "ietf-sdwan-vpn-svc@2018-06-13.yang
module ietf-sdwan-vpn-svc {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-sdwan-vpn-svc";
prefix sdwan-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-06-13 {
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";
}
identity any-to-any-role {
base site-role;
description
"Site in an any-to-any IP VPN.";
}
identity hub {
base site-role;
description
"Hob Role";
}
identity spoke {
base site-role;
description
"Spoke Role";
}
identity access-type {
description
"Access type";
}
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/policies"+"
/classification-profile/name";
}
description
"Qos Classification name";
}
leaf qos-profile-name {
type leafref {
path "/sdwan-vpn-svc/sdwan-vpn/policies/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";
}
leaf segment-network {
type leafref {
path "/sdwan-vpn-svc/sdwan-vpn/segment-networks/segment-id";
}
description
"segment network identifier";
}
leaf-list site {
type leafref {
path "/sdwan-vpn-svc/sdwan-vpn/sites/site/site-id";
}
description
"Site list ";
}
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/policies"+
"/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 path-primary {
type string;
description
"Path primary";
}
leaf path-sencondry {
type string;
description
"Path sencondry";
}
description
"List for Rule";
}
description
"List for path selection policy";
}
description
"Grouping for path-selection-policy";
}
grouping internet-access {
list internet-access {
key "site-id";
leaf site-id {
type leafref {
path "/sdwan-vpn-svc/sdwan-vpn/sites/site/site-id";
}
description
"Site id";
}
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
"List for internet access";
}
description
"Grouping for internet-access";
}
grouping vpn-interworking {
list vpn-interworking {
key "site-id";
leaf site-id {
type leafref {
path "/sdwan-vpn-svc/sdwan-vpn/sites/site/site-id";
}
description
"Site id";
}
leaf vpn-gateway-ip {
type inet:ip-address;
description
"traditional MPLS VPN gateway IP";
}
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/policies"+
"/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-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-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-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";
}
}
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";
}
description
"List for device";
}
list transport-network {
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 service";
}
description
"List for transport network ports";
}
description
"List for sites";
}
description
"Container for sites";
}
list segment-networks {
key "segment-id";
leaf segment-id {
type svc-id;
description
"segment network identifier";
}
leaf topology {
type identityref {
base vpn-topology;
}
description
"vpn segment topology: hub&spoke or any-to-any";
}
list sites {
key "site-id";
leaf site-id {
type leafref {
path "/sdwan-vpn-svc/sdwan-vpn/sites/site/site-id";
}
mandatory true;
description
"Reference to a site.";
}
leaf site-role {
type identityref {
base site-role;
}
default "any-to-any-role";
description
"Role of the site in the segment.";
}
description
"List of sites the segment is associated with.";
}
list lan-networks {
key "site-id";
leaf site-id {
type leafref {
path "/sdwan-vpn-svc/sdwan-vpn/sites/site/site-id";
}
}
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 lan network";
}
description
"List for segment network";
}
container policies {
uses path-selection-policy;
uses qos-bandwidth-policy;
uses traffic-filter-policy;
uses internet-access;
uses vpn-interworking;
uses application-group;
uses classification-profile;
uses qos-profile;
}
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.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC4364] | Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006. |
| [RFC4664] | Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 10.17487/RFC4664, September 2006. |
| [RFC6020] | Bjorklund, M., "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., Litkowski, S., Tomotaki, L. and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018. |