RTWG Working Group S. Wood, Ed.
Internet-Draft Cisco Systems
Intended status: Standards Track B. Wu, Ed.
Expires: September 12, 2019 Q. Wu, Ed.
Huawei
C. Menezes
HPE Aruba
March 11, 2019
YANG Data Model for SD-WAN OSE service delivery
draft-wood-rtgwg-sdwan-ose-yang-00
Abstract
This document defines two SD-WAN OSE Open SD-WAN Exchange(OSE)
service YANG modules to enable the orchestrator in the enterprise
network to implement SD-WAN inter-domain reachability and
connectivity services and application aware traffic steering
services.
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 September 12, 2019.
Copyright Notice
Copyright (c) 2019 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
Wood, et al. Expires September 12, 2019 [Page 1]
Internet-Draft SDWAN OSE YANG Model March 2019
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 . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1. Requirements Language . . . . . . . . . . . . . . . . 4
1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The SD-WAN OSE Service Model Requirements . . . . . . . . . . 5
3.1. Reachability & Router Exchange Requirements . . . . . . . 5
3.2. Path management Requirements . . . . . . . . . . . . . . 5
3.3. Network Segmentation Requirements . . . . . . . . . . . . 6
4. Service Model Usage . . . . . . . . . . . . . . . . . . . . . 6
5. Design of the Data Model . . . . . . . . . . . . . . . . . . 8
5.1. OSE Gateway module . . . . . . . . . . . . . . . . . . . 8
5.2. path-management module . . . . . . . . . . . . . . . . . 9
6. SD-WAN OSE Path Management YANG Module . . . . . . . . . . . 12
7. SD-WAN OSE Reachability Service YANG Module . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Acknowledges . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction
Software-Defined WAN networking (SDWAN) has become a major new
technology in Wide Area Networking. SDWAN architecture is a
combination of data and control plane orchestration, proprietary
control-plane enhancements as well as single-hop, CE-CE data-planes
often referred to as "fabrics". On top of this infrastructure,
centralized network policy administration and distribution is
provided to achieve a specific set of network outcomes or use-cases.
As a result of the use-case driven approach, SDWAN technology
solutions often encode choices about data-plane and protocol
operation into associated data-plane, control-plane and controller
subsystems. These choices are intended to simplify deployment of
SDWAN use-cases, but often result in systems that are not compatible
and network elements that cannot interoperate in the manner of
traditional, standards-based IP networks.
Wood, et al. Expires September 12, 2019 [Page 2]
Internet-Draft SDWAN OSE YANG Model March 2019
The Open SD-WAN Exchange (OSE) is an open framework to allow for one
vendor SD-WAN domain to communicate with another vendor SD-WAN
domain. The goal is to enable interworking between different SDWAN
domains via the definition of standard service behaviours as well as
standard data models to define those services. The underlying
service implementation in each domain is only relevant in that it
meets the specified service definition. To create OSE SD-WAN
services across domain, a higher layer orchestrator may use generic
API calls based on the service models to create the desired SDWAN
services within each domain via the serving SDWAN manager.
The services currently defined by specification [OSE] include:
o OSE Gateway Reachability services
o Application Path Management Services
This document defines two SD-WAN service YANG modules to enable the
orchestrator in the enterprise network to implement SD-WAN inter-
domain reachability and connectivity services and application aware
traffic steering services. The SD-WAN OSE Service Model is for
enterprise own network.
1.1. Terminology
The following terms are defined in [RFC6241] and are not redefined
here:
o client
o server
o configuration data
o state data
The following terms are defined in [RFC7950] and are not redefined
here:
o augment
o data model
o data node
The terminology for describing YANG data models is found in
[RFC7950].
Wood, et al. Expires September 12, 2019 [Page 3]
Internet-Draft SDWAN OSE YANG Model March 2019
1.1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Tree diagram
Tree diagrams used in this document follow the notation defined in
[RFC8340].
2. Definitions
This document uses the following terms:
Service Provider (SP): The organization (usually a commercial
undertaking) responsible for operating the network that offers VPN
services to clients and customers.
Customer Edge (CE) Device: Equipment that is dedicated to a
particular customer and is directly connected to one or more PE
devices via attachment circuits. A CE is usually located at the
customer premises, and is usually dedicated to a single VPN,
although it may support multiple VPNs if each one has separate
attachment circuits. The CE devices can be routers, bridges,
switches or hosts.
Provider Edge (PE) Device: Equipment managed by the SP that can
support multiple VPNs for different customers, and is directly
connected 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.
SDWAN Manager: SDWAN Manager is the domain specific manager and
controller required to configure, manage and control a particular
SDWAN domain. To create OSE SDWAN services, a higher layer
orchestrator may use OSE defined API calls to create the desired
SDWAN services within each domain via the serving SDWAN manager.
Client Orchestration: The Client Orchestration layer is an
abstraction of a service level orchestrator or software that
implements control the the SDWAN through the defined OSE APIs.
The OSE service specifications do not specify the functions and
procedures within this entity apart from the fact that it would
use the OSE APIs. The client orchestration layer is a functional
Wood, et al. Expires September 12, 2019 [Page 4]
Internet-Draft SDWAN OSE YANG Model March 2019
block which would implement OSE API calls to one or more serving
SDWAN managers.
SD-WAN controller: The SD-WAN Controller is a reference block that
encompasses the network control-plane functions required to
operate the SDWAN network. The SD-WAN network controller delivers
control-plane/data-plane separation the is the realization of SDN
architecture within the SD-WAN usecase. Each SD-WAN network
controller is managed and configured by the SD-WAN manager. The
interface between SDWAN network controller and SD-WAN network
manager for this purpose is currently outside the scope of the
document.
3. The SD-WAN OSE Service Model Requirements
This section provides a common definition for service types required
across different SD-WAN vendor domains. The Open SD-WAN Exchange
(OSE) model focuses on interoperability between domains, rather than
specifying standard protocol and operations with each SD-WAN domain.
The OSE interoperability models focus on the definition of a standard
set of service models and parameters that can be implemented in an
SDWAN management system to configure interoperable services within an
SDWAN domain and between SDWAN domains.
3.1. Reachability & Router Exchange Requirements
In [OSE]SD-WAN reference model, it is assumed that communication
between sites sitting in different domains happening via the OSE
gateway which suggests that traffic spanning the domains will be
backhauled to the OSE gateway.
Requirements for reachability and route exchange services are split
into control plane and data plane requirements. Control plane
requirements cover information exchange between sd-wan islands while
data plane requirements cover the requirements of the actual data
plane encapsulation.
3.2. Path management Requirements
As specified in ONUG SD-WAN whitepaper[ONUG], dynamic path selection
is one of the core features of the SD-WAN, which site-to-site packets
can be distributed across multiple WAN connections in real-time,
based on current link metrics such as delay, loss and jitter. In
this model, a path is considered to be an access network and not a
path within an access network, although the latter is not precluded.
For business critical applications traversing SD-WAN domains,
policies via standardized APIs need to be provisioned to guarantee
Wood, et al. Expires September 12, 2019 [Page 5]
Internet-Draft SDWAN OSE YANG Model March 2019
end-to-end SLA requirements and each domain is responsible for
implementing consistent policy enforcement behaviour. Since inter-
domain traffic are all backhauled by the OSE gateways, each part of
the traversing path needs to be consistent.
Note: A method needs to be specified for budgeting end-to-end delay
across multiple domains - delay/loss/jitter needs to be shared so
that each domain can compute the total path, determine who's
violating and then execute path change.
3.3. Network Segmentation Requirements
Network segmentation divides an enterprise network into different
traffic or routing contexts to provide clear separation of traffic of
each segment. These are often referred to as Virtual networks. The
most common technology of network segmentation are virtual LANs, or
VLANs, for Layer 2 implementation, and virtual routing and
forwarding, or VRF, for Layer 3 implementation. For traffic flowing
across SD-WAN domains boundaries, segmentation must be preserved. A
method of configuration is required to ensure per segment traffic
flow separation while passing through SD-WAN domain boundaries.
4. Service Model Usage
+-------------------------------------+
| Client Orchestration |
+-------------------------------------+
| |
ose-path-svc | ose-reachability-svc |
Model | Model |
| |
+----------------+ +----------------+
| SDWAN manager | | SDWAN manager |
+----------------+ +-------+--------+
| |
| NETCONF/CLI ... |
| |
+-------------------------+ +------+-------------------+
| SDWAN Domin #1 | | SDWAN Domin #2 |
| | | |
|++++++++ +++++++++++++ | NNI | +++++++++++++ ++++++++ |
|+Branch+--+OSE Gateway+--+------------+-+OSE Gateway+---+Branch+ |
|++++++++ +++++++++++++ | | +++++++++++++ ++++++++ |
| | | |
|Site A | | Site B |
+-------------------------+ +--------------------------+
Figure 1
Wood, et al. Expires September 12, 2019 [Page 6]
Internet-Draft SDWAN OSE YANG Model March 2019
As shown in figure 1, communication between branch sites sitting in
domain#1 and domain#2 happens via a border element referred to as the
OSE Gateway. This border element interworks the SDWAN control and
data plane of the SDWAN domain to a common, defined NNI carrying
routing information to establish reachability between domains. It
also carries segmentation identifiers that are mutually agreed and
configured within each OSE gateway by the domain serving SDWAN
manager. The serving SDWAN manager in each respective domain is
configured by the operator with information about which segments in
each domain are to be connected.
Segment connections must be 1:1 across each OSE gateway.
Note: The detailed control and data plane specifications for the OSE
Gateway NNI will refer to the definition of the relevant SD-WAN
protocols in the IETF.
The ONUG SD-WAN service YANG model provides an abstracted interface
to configure, and manage the components of an SD-WAN service. The
components of the SD-WAN service include the OSE Gateway Service
component and the Path Management Service component. OSE gateway
service component defines Reachability and Route Exchange
Segmentation requirements for OSE Gateway devices while path
management service component defines path management policy for
domain serving SD-WAN managers.
A typical usage for this model is to generate Restconf[RFC8040] API
used between Client Orchestraton layer and SDWAN manager and used by
an enterprise operator to provision the inter-domain services.
Before configuring the inter-domain path management policy service,
the ose-reachability-svc model is used for the following
configuration:
o Create one or more OSE gateways in the serving domain.
o Create underlying connections between the OSE gateway and other
SD-WAN domain gateways, including control plane and data plane.
o Create overlay tunnels between the OSE gateway and other SD-WAN
domain gateways with Tunnel setup parameters, such as IPsec Tunnel
related authentication and encryption parameters.
o Create segment mappings between the OSE gateway and other SD-WAN
domain gateways with segment related parameters, such as VLAN ID
or VRF ID.
For the configuration of network elements may be done using NETCONF
[RFC6241] or any other configuration (or "southbound") interface such
Wood, et al. Expires September 12, 2019 [Page 7]
Internet-Draft SDWAN OSE YANG Model March 2019
as Command Line Interface (CLI) in combination with device-specific
and protocol-specific YANG data models.
The usage of this service model is not limited to this example: it
can be used by any component of the management system but not
directly by network elements.
5. Design of the Data Model
The SD-WAN OSE service model currently has two YANG modules.
5.1. OSE Gateway module
The aim of OSE Gateway module is to define parameters for connection
setup between SD-WAN domains. As specified by RFC4364, this model
defines Option A and Option B to interconnect the different domain.
The option B allows one to minimize configuration inputs and allows
the solution to scale really high because only the BGP RIBs store all
the inter-AS / inter-SD-WAN VPN routes. MP-BGP can run a single
label stack within the GRE tunnel, between the NNI nodes such that
the MPLS label will be used for traffic segmentation. In the cases,
where L3VPN Inter-AS Option B is not supported, revert to MP-BGP
based Inter-AS VPN Option A while using MPLS labels. The option A
requires Orchestration layer to signal underlying SD-WAN domains to
configure and instantiate VRF instances per tenant, as well as MP-BGP
based L3VPN configuration and instantiation per tenant. This option
can still run on GRE or IPSec tunnels while providing isolation from
underlay changes and dependencies and MPLS label within the GRE
tunnel will provide per tenant service level separation.
o ose-gateway: Gateway name and Gateway ID are specified for each
domain.
o tunnel: describes encap-type in the interconnection points, and
authentication and encryption are also specified to secure the
interconnection between SD-WAN domains.
o ose-interworking-option: MP-BGP based L3VPN Inter-AS Option B with
MPLS labels and Inter-AS Option A are defined.
o ose-gateway control plane peering:Control Plane peering between
SD-WAN Edge Nodes which exchanges routes and additional
reachability information as well as forward transit traffic. For
good HA and resiliency characteristics, it is recommended to
establish control plane sessions between each node.
Wood, et al. Expires September 12, 2019 [Page 8]
Internet-Draft SDWAN OSE YANG Model March 2019
o segment: to guarantee end to end secure traffic, the segment
traffic from a specific domain needs to cross connect to the
target segment through an OSE gateway.
The complete data hierarchy is presented as follows:
module: ietf-ose-reachability-svc
+--rw ose-gateways
+--rw ose-gateway* [gw-name]
+--rw gw-name string
+--rw gw-id? uint32
+--rw ose-interworking-option? enumeration
+--rw encap-type? enumeration
+--rw auth-type? enumeration
+--rw crypto? enumeration
+--rw peer-list* [name]
| +--rw name string
| +--rw Local-gw-id? uint32
| +--rw peer-gw-id? uint32
| +--rw peer-gw-name? string
| +--rw authType? enumeration
| +--rw crypto-option? enumeration
| +--rw ose-interworking-option? enumeration
+--rw segment-list* [segment-name]
+--rw segment-name string
+--rw vlan-id? uint16
+--rw vrf-id? uint16
+--rw segment-type? enumeration
+--rw CrossConnects
+--rw CCname? string
+--rw local-seg-name? string
+--rw local-Seg-id-vlan? uint16 {ose-option-A}?
+--rw local-seg-id-vrf? uint16 {ose-option-B}?
+--rw peer-seg-name? string
+--rw peer-seg-id-vlan? uint16 {ose-option-A}?
+--rw peer-seg-id-vrf? uint16 {ose-option-B}?
5.2. path-management module
Path management module defines automatic path selection policy for
traffic across the domain. Policy control will take shape in the
form of an ordered list. Each item in the list will be evaluated to
match the traffic classifier. The first match will result in
processing the matched traffic according to the associated link &
path policy. In turn, the link & path policy will be framed in the
context of the Performance SLA associated to the links and paths.
Wood, et al. Expires September 12, 2019 [Page 9]
Internet-Draft SDWAN OSE YANG Model March 2019
+------------------+ +------------------+ +------------------+
| | \| Link & Path |/ | Link&Path |
|Traffic Classifier+----+ Policy +------+ Performance |
| | /| |\ | SLAs |
+------------------+ +------------------+ +------------------+
figure 2
Traffic classification rules are handled by the "traffic-class"
container. The traffic-classification-policy container is an ordered
list of rules that match a flow or application and set the
appropriate business-priority and make link or path selection.This
business priority can be factored into the path selection decision.
The client orchestrator can define the match using an application
reference or a flow definition that is more specific (e.g., based on
Layer 3 source and destination addresses, Layer 4 ports, and Layer 4
protocol).
The link or path selection is defined as a list of services
properties. Describes the policy for how links should be selected
for the specified traffic flow. The properties are as follows:
o mode:Describes the policy for how links should be selected for the
specified traffic flow. Values are: 1-Automatic 2-Primary/
preferred 3-Lowest cost
o physical-port:describe the WAN port number
o service-type:Commodity - referring to broadband Internet
links,Wireless - referring to subset of 3G/4G/LTE and upcoming
5G,Private - referring to private circuits such as Ethernet, T1,
etc
o service-provider:specifying the name of provider per enumerated
list of providers globally
o path-selection-mode:Describes the policy for how paths should be
selected for the specified traffic flow. This includes the policy
option for portions of traffic to not be sent across the SD-WAN
overlay tunnel. Values are: 1 - "Drop" 2 - "UnderNon overlay" 3 -
"Overlay"
A custom SLA profile is defined as a list of services properties.
The properties are as follows:
o delay:used to define the latency constraint of a specific traffic
class .
Wood, et al. Expires September 12, 2019 [Page 10]
Internet-Draft SDWAN OSE YANG Model March 2019
o jitter:used to define the jitter constraint of a specific traffic
class.
o bandwidth usage:used to define the bandwidth constraint of a
specific traffic class.
The complete data hierarchy is presented as follows:
module: ietf-ose-path-svc
+--rw path-svc
| +--rw service* [name]
| +--rw name string
| +--rw class-id? string
| +--rw traffic-class* [name]
| | +--rw name string
| | +--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
| +--rw application* [name]
| | +--rw name string
| | +--rw category-id? uint32
| | +--rw application-id? uint32
| +--rw user
| | +--rw list-name? string
| | +--rw user-id* string
| | +--rw group* string
| +--rw site-id* uint32
| +--rw business-priority? enumeration
| +--rw link-selection-mode
| | +--rw mode? enumeration
| | +--rw physical-port? uint32
| | +--rw service-type? enumeration
| | +--rw service-provider? string
| +--rw path-selection-mode? enumeration
+--rw traffic-profile
+--rw (qos-profile)?
Wood, et al. Expires September 12, 2019 [Page 11]
Internet-Draft SDWAN OSE YANG Model March 2019
+--:(standard)
| +--rw profile? string
+--:(custom)
+--rw classes {qos-custom}?
+--rw class* [class-id]
+--rw class-id string
+--rw direction? identityref
+--rw rate-limit? decimal64
+--rw latency
| +--rw (flavor)?
| +--:(lowest)
| | +--rw use-lowest-latency? em
| +--:(boundary)
| +--rw latency-boundary? ui
+--rw jitter
| +--rw (flavor)?
| +--:(lowest)
| | +--rw use-lowest-jitter? emp
| +--:(boundary)
| +--rw latency-boundary? uin
+--rw bandwidth
+--rw guaranteed-bw-percent decim
+--rw end-to-end? empty
6. SD-WAN OSE Path Management YANG Module
<CODE BEGINS> file "ietf-ose-path-svc.yang"
module ietf-ose-path-svc {
namespace "urn:ietf:params:xml:ns:yang:ietf-ose-path-svc";
prefix path-svc;
import ietf-inet-types {
prefix inet;
}
feature qos-custom {
description
"Enables support of the custom QoS profile.";
}
identity qos-profile-direction {
description
"Base identity for QoS profile direction.";
}
identity site-to-wan {
base qos-profile-direction;
description
Wood, et al. Expires September 12, 2019 [Page 12]
Internet-Draft SDWAN OSE YANG Model March 2019
"Identity for Site-to-WAN direction.";
}
identity wan-to-site {
base qos-profile-direction;
description
"Identity for WAN-to-Site direction.";
}
identity both {
base qos-profile-direction;
description
"Identity for both WAN-to-Site direction
and Site-to-WAN direction.";
}
identity protocol-type {
description
"Base identity for protocol field type.";
}
identity tcp {
base protocol-type;
description
"TCP protocol type.";
}
identity udp {
base protocol-type;
description
"UDP protocol type.";
}
identity icmp {
base protocol-type;
description
"ICMP protocol type.";
}
identity icmp6 {
base protocol-type;
description
"ICMPv6 protocol type.";
}
identity gre {
base protocol-type;
description
Wood, et al. Expires September 12, 2019 [Page 13]
Internet-Draft SDWAN OSE YANG Model March 2019
"GRE protocol type.";
}
identity ipip {
base protocol-type;
description
"IP-in-IP protocol type.";
}
identity hop-by-hop {
base protocol-type;
description
"Hop-by-Hop IPv6 header type.";
}
identity routing {
base protocol-type;
description
"Routing IPv6 header type.";
}
identity esp {
base protocol-type;
description
"ESP header type.";
}
identity ah {
base protocol-type;
description
"AH header type.";
}
container path-svc {
list service {
key "name";
leaf name {
type string;
}
leaf class-id {
type string;
}
list traffic-class {
key "name";
leaf name {
type string;
}
leaf dscp {
Wood, et al. Expires September 12, 2019 [Page 14]
Internet-Draft SDWAN OSE YANG Model March 2019
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 'current() < ../l4-src-port-range/lower-port or current() > ../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.";
}
Wood, et al. Expires September 12, 2019 [Page 15]
Internet-Draft SDWAN OSE YANG Model March 2019
leaf upper-port {
type inet:port-number;
must '. >= ../lower-port' {
description
"Upper boundary for port. If it
exists, the upper boundary must be
higher than the lower boundary.";
}
description
"Upper boundary for port.";
}
description
"Match on Layer 4 src port range. When
only the lower-port is present, it represents
a single port. When both the lower-port and
upper-port are specified, it implies
a range inclusive of both values.";
}
leaf l4-dst-port {
type inet:port-number;
must 'current() < ../l4-dst-port-range/lower-port or current() > ../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.";
}
Wood, et al. Expires September 12, 2019 [Page 16]
Internet-Draft SDWAN OSE YANG Model March 2019
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 protocol-type;
}
}
description
"Match on IPv4 protocol or IPv6 Next Header field.";
}
}
list application {
key "name";
leaf name {
type string;
}
leaf category-id {
type uint32;
}
leaf application-id {
type uint32;
}
}
container user {
leaf list-name {
type string;
}
leaf-list user-id {
type string;
}
leaf-list group {
type string;
}
}
leaf-list site-id {
type uint32;
}
leaf business-priority {
type enumeration {
enum high;
enum normal;
Wood, et al. Expires September 12, 2019 [Page 17]
Internet-Draft SDWAN OSE YANG Model March 2019
enum low;
enum Voice;
enum Critical_Data;
enum Transactional;
enum user-defined;
}
}
container link-selection-mode {
leaf mode {
type enumeration {
enum automatic;
enum preferred;
enum lowest-cost;
}
}
leaf physical-port {
type uint32;
}
leaf service-type {
type enumeration {
enum commodity;
enum wireless;
enum private;
}
}
leaf service-provider {
type string;
}
}
leaf path-selection-mode {
type enumeration {
enum drop;
enum underlay;
enum overlay;
}
}
}
}
container traffic-profile {
choice qos-profile {
description
"Choice for traffic QoS profile.
Can be standard profile or customized profile.";
case standard {
description
"Standard QoS profile.";
leaf profile {
type string;
Wood, et al. Expires September 12, 2019 [Page 18]
Internet-Draft SDWAN OSE YANG Model March 2019
description
"QoS profile to be used.";
}
}
case custom {
description
"Customized QoS profile.";
container classes {
if-feature "qos-custom";
list class {
key "class-id";
leaf class-id {
type string;
description
"Identification of the class of service.
This identifier is internal to the
administration.";
}
leaf direction {
type identityref {
base qos-profile-direction;
}
default "both";
description
"The direction to which the QoS profile
is applied.";
}
leaf rate-limit {
type decimal64 {
fraction-digits 5;
range "0..100";
}
units "percent";
description
"To be used if the class must be rate-limited.
Expressed as percentage of the service
bandwidth.";
}
container latency {
choice flavor {
case lowest {
leaf use-lowest-latency {
type empty;
description
"The traffic class should use the path with the
lowest latency.";
}
}
Wood, et al. Expires September 12, 2019 [Page 19]
Internet-Draft SDWAN OSE YANG Model March 2019
case boundary {
leaf latency-boundary {
type uint16;
units "msec";
default "400";
description
"The traffic class should use a path with a
defined maximum latency.";
}
}
description
"Latency constraint on the traffic class.";
}
description
"Latency constraint on the traffic class.";
}
container jitter {
choice flavor {
case lowest {
leaf use-lowest-jitter {
type empty;
description
"The traffic class should use the path with the
lowest jitter.";
}
}
case boundary {
leaf latency-boundary {
type uint32;
units "usec";
default "40000";
description
"The traffic class should use a path with a
defined maximum jitter.";
}
}
description
"Jitter constraint on the traffic class.";
}
description
"Jitter constraint on the traffic class.";
}
container bandwidth {
leaf guaranteed-bw-percent {
type decimal64 {
fraction-digits 5;
range "0..100";
}
Wood, et al. Expires September 12, 2019 [Page 20]
Internet-Draft SDWAN OSE YANG Model March 2019
units "percent";
mandatory true;
description
"To be used to define the guaranteed bandwidth
as a percentage of the available service bandwidth.";
}
leaf end-to-end {
type empty;
description
"Used if the bandwidth reservation
must be done on the MPLS network too.";
}
description
"Bandwidth constraint on the traffic class.";
}
}
}
}
}
}
}
<CODE ENDS>
7. SD-WAN OSE Reachability Service YANG Module
<CODE BEGINS> file "ietf-ose-reachability-svc.yang"
module ietf-ose-reachability-svc {
namespace "urn:ietf:params:xml:ns:yang:ietf-ose-reachability-svc";
prefix reach-svc;
import ietf-inet-types {
prefix inet;
}
import ietf-yang-types {
prefix yang;
}
feature ose-option-A {
description
"This feature means that ose reachability service option-A is supported by the Serving SDWAN manager";
reference
"ONUG-OSE-2 SDWAN Reachability and Segmentation Specification";
}
feature ose-option-B {
description
"This feature means that ose reachability service option-B is supported by the Serving SDWAN manager";
reference
Wood, et al. Expires September 12, 2019 [Page 21]
Internet-Draft SDWAN OSE YANG Model March 2019
"ONUG-OSE-2 SDWAN Reachability and Segmentation Specification";
}
container ose-gateways {
list ose-gateway {
key "gw-name";
leaf gw-name {
type string;
description
"OSE gateway name.";
}
leaf gw-id {
type uint32;
description
"Identifier for Gateway.";
}
leaf ose-interworking-option {
type enumeration {
enum ose-option-A;
enum ose-option-B;
}
description
"OSE interworking options.";
}
leaf encap-type {
type enumeration {
enum IPSEC_TUNNEL;
enum IPSEC_TRANSPORT;
enum GRE;
}
description
"encapsulation type of tunnel.";
}
leaf auth-type {
type enumeration {
enum PSK;
enum PKI;
}
description
"authentication type.";
}
leaf crypto {
type enumeration {
enum AES-128;
enum AES-256;
enum AES-256-GCM;
}
description
Wood, et al. Expires September 12, 2019 [Page 22]
Internet-Draft SDWAN OSE YANG Model March 2019
"crypto algorithm type.";
}
list peer-list {
key "name";
leaf name {
type string;
description
"peer index.";
}
leaf Local-gw-id {
type uint32;
description
"Identifier for the local gateway.";
}
leaf peer-gw-id {
type uint32;
description
"Identifier for the remote peer gateway.";
}
leaf peer-gw-name {
type string;
description
"Name of remote peer gateway. ";
}
leaf authType {
type enumeration {
enum PSK;
enum PKI;
}
description
"authentication type.";
}
leaf crypto-option {
type enumeration {
enum AES-256;
enum AES-128;
enum AES-256-GCM;
}
description
"Crypto algorithm selection. Others to be added";
}
leaf ose-interworking-option {
type enumeration {
enum ose-option-A;
enum ose-option-B;
}
description
"ose interworking options.";
Wood, et al. Expires September 12, 2019 [Page 23]
Internet-Draft SDWAN OSE YANG Model March 2019
}
}
list segment-list {
key "segment-name";
leaf segment-name {
type string;
description
"segment name.";
}
leaf vlan-id {
type uint16;
description
"vlan ID.";
}
leaf vrf-id {
type uint16;
description
"vrf ID.";
}
leaf segment-type {
type enumeration {
enum overlay;
enum nsw;
}
description
"segment type.";
}
container CrossConnects {
leaf CCname {
type string;
description
"cross connection name.";
}
leaf local-seg-name {
type string;
description
"local segment name.";
}
leaf local-Seg-id-vlan {
if-feature "ose-option-A";
type uint16;
description
"local segment VLAN ID.";
}
leaf local-seg-id-vrf {
if-feature "ose-option-B";
type uint16;
description
Wood, et al. Expires September 12, 2019 [Page 24]
Internet-Draft SDWAN OSE YANG Model March 2019
"lcoal segment vrf ID.";
}
leaf peer-seg-name {
type string;
description
"Peer segment name.";
}
leaf peer-seg-id-vlan {
if-feature "ose-option-A";
type uint16;
description
"Peer segment vlan ID.";
}
leaf peer-seg-id-vrf {
if-feature "ose-option-B";
type uint16;
description
"Peer Segment vrf ID.";
}
}
}
description
"Segment List";
}
description
"OSE gateway.";
}
}
<CODE ENDS>
8. 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
Wood, et al. Expires September 12, 2019 [Page 25]
Internet-Draft SDWAN OSE YANG Model March 2019
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:
o /ose-path/service
The entries in the list above include the whole ose path service
configurations which the customer subscribes, and indirectly
create or modify the path selection configurations. Unexpected
changes to these entries could lead to service disruption and/or
network misbehavior.
o /path-svc/ose-gateway
The entries in the list above include the whole ose gateway
service configurations which the customer subscribes, and
indirectly create or modify the PE,ASBR device configurations.
Unexpected changes to these entries could lead to service
disruption and/or network misbehavior.
o /ose-gateways/ose-gateway/peer-list
The entries in the list above include the peer list
configurations. As above, unexpected changes to these entries
could lead to service disruption and/or network misbehavior.
o /ose-gateways/ose-gateway/segment-list
The entries in the list above include the segment list
configurations. As above, unexpected changes to these entries
could lead to service disruption and/or network misbehavior.
9. IANA Considerations
This document registers a URI in the IETF XML registry [RFC3688].
Following the format in [RFC3688], the following registrations are
requested to be made:
Wood, et al. Expires September 12, 2019 [Page 26]
Internet-Draft SDWAN OSE YANG Model March 2019
---------------------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-ose-path-svc
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-ose-reachability-svc
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace.
---------------------------------------------------------------------
This document registers two YANG modules in the YANG Module Names
registry [RFC6020].
---------------------------------------------------------------------
Name: ietf-ose-path-svc
Namespace: urn:ietf:params:xml:ns:yang:ietf-ose-path-svc
Prefix: path-svc
Reference: RFC xxxx
Name: ietf-ose-reachability-svc
Namespace: urn:ietf:params:xml:ns:yang:ietf-ose-reachability-svc
Prefix: reach-vpn
Reference: RFC xxxx
---------------------------------------------------------------------
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[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>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[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>.
Wood, et al. Expires September 12, 2019 [Page 27]
Internet-Draft SDWAN OSE YANG Model March 2019
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370,
DOI 10.17487/RFC6370, September 2011,
<https://www.rfc-editor.org/info/rfc6370>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012,
<https://www.rfc-editor.org/info/rfc6536>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
10.2. Informative References
[ONUG] Group, O. S. W., Ed., "ONUG Software-Defned WAN Use Case:
A white paper from the ONUG SD-WAN Working Group", October
2014.
[OSE] Group, O. O. W., Ed., "ONUG SOFTWARE DEFINED WAN (SD-WAN):
NETWORK ARCHITECTURE FRAMEWORK".
Appendix A. Acknowledges
Authors' Addresses
Steve Wood (editor)
Cisco Systems
Email: swood1@cisco.com
Wood, et al. Expires September 12, 2019 [Page 28]
Internet-Draft SDWAN OSE YANG Model March 2019
Bo Wu (editor)
Huawei Technologies, Co., Ltd
Email: lana.wubo@huawei.com
Qin Wu (editor)
Huawei Technologies, Co., Ltd
Email: bill.wu@huawei.com
Conrad Menezes
HPE Aruba
Email: conrad.menezes@hpe.com
Wood, et al. Expires September 12, 2019 [Page 29]