Internet DRAFT - draft-tripathy-cloud-sla-yang-model
draft-tripathy-cloud-sla-yang-model
NETCONF Data Modeling Language Working Group (netmod) A. Tripathy
Internet-Draft E. Voit
Intended status: Informational A. Clemm
Expires: April 30, 2015 Cisco Systems
October 27, 2014
Cloud SLA YANG Model incorporating Peer Mount Semantics
draft-tripathy-cloud-sla-yang-model-00
Abstract
This document defines a YANG data model which supports cloud SLA
applications. Two apps currently operating from this model are a
cloud based policer application and a distributed-denial-of-service
attack redirect application. Other applications are planned as well.
Key to this model is that it includes semantics for mounting objects
from remote network element datastores. These semantics are
necessary so that applications can operate on objects distributed
across multiple devices as if they were part of a single local
datastore.
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 http://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 30, 2015.
Copyright Notice
Copyright (c) 2014 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
(http://trustee.ietf.org/license-info) in effect on the date of
Tripathy, et al. Expires April 30, 2015 [Page 1]
Internet-Draft Cloud SLA Model October 2014
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
2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Tree diagram syntax . . . . . . . . . . . . . . . . . . . 3
2.2. Tree diagram structure for the data model . . . . . . . . 3
2.3. Of interest in the model . . . . . . . . . . . . . . . . 4
3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
This document defines a YANG data model RFC 6020 [RFC6020] for two
Cloud SLA applications defined in [peermount-req]. This model would
reside in a controller or a network element filling the role of a
controller. This document does not define the corresponding YANG
models for each of the controlled devices.
Interesting in this model is that it also includes semantics for
mounting remote datastores from remote network elements as defined as
defined in[draft-clemm-mount]. These semantics are necessary so that
applications can operate on objects distributed across multiple
devices as if they were part of a single local datastore.
The specific information which is mounted from remote systems are RFC
7223 [RFC7223]YANG operational objects. Effectively the datastore
exposes a set of statistics from many devices so that Cloud SLA
applications don't have to find and acquire them independently. Also
interesting in this model is that it exposes a minimal mix of
configuration and operational objects needed for the Cloud SLA
category of applications.
This minimal mix is key; it limits the domain of objects exposed and
therefore maximizes simplicity from the application developer's
viewpoint. This model is being contributed to serve as an
Tripathy, et al. Expires April 30, 2015 [Page 2]
Internet-Draft Cloud SLA Model October 2014
informational guide of how to use [yang-mount]. Implementations of
this model currently exist in OpenDaylight.
2. YANG Model
This section provides an overview of the information needed for Cloud
SLA services models. Within the section, selected examples are
highlighted and corresponding design choices are explained.
2.1. Tree diagram syntax
A simplified graphical representation of the data model is presented
in Section 2. The meaning if the symbols in these diagrams are as
follows:
o Brackets "[" and "]" enclose list keys.
o Symbols after data node names: "?" means an optional node, and "*"
denotes a list and leaf-list.
o Abbreviations before data node names: "rw" means configuration
data (read-write), "ro" means state data (read-only), and "M"
means mount from a remote datastore.
o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not
shown.
2.2. Tree diagram structure for the data model
Tripathy, et al. Expires April 30, 2015 [Page 3]
Internet-Draft Cloud SLA Model October 2014
+--rw ietf-cloud-sla
+--rw policies
+--rw policy [policy-name]
+--rw policy-name string
+--rw policy-max-bw? uint64
+--ro network-aggregate-bw? uint64
+--rw nes
| +--rw ne [ne-id]
| +--rw ne-id string
| +--rw policing-policies
| | +--rw policed-bandwidth* [ifref]
| | +--rw ifref mounted-interface-ref
| | +--rw bandwidth? uint64
| +--ro interfaces-state
| | +--M interface-statistics
| +--rw ddos-prop-conf
| +--rw access-list-name? string
+--rw ddos
+--rw ddos? empty
+--ro potential-ddos-underway? boolean
+--ro redirect-activated? boolean
+--ro redirect-actvation-time? uint64
Key here is the application of the[draft-clemm-mount] syntax:
+--M interface-statistics
As formally described in Section 6, this will mount the RFC 7223
[RFC7223]Section 3.2 Target Data Node:
+--ro interfaces-state
This Target Data Node contains operational data information from the
Interfaces Data Model. In fact it contains information from all
interfaces of the network element.
2.3. Of interest in the model
2.3.1. How many objects are exposed by the Mount?
Many fields will be available when mounting this particular Mount
Target. Not all will be required for the Cloud SLA applications even
if they are available. Some of the ones which are used are
identified below. For definitions of these objects, please see RFC
7223 [RFC7223].
Tripathy, et al. Expires April 30, 2015 [Page 4]
Internet-Draft Cloud SLA Model October 2014
+--ro interfaces-state
+--ro interface* [name]
+--ro name string
+--ro type identityref
+--ro oper-status enumeration
+--ro statistics
+--ro in-unicast-pkts? yang:counter64
+--ro in-broadcast-pkts? yang:counter64
+--ro in-multicast-pkts? yang:counter64
A design choice we could have made in the YANG model would be Mount
individual interfaces, rather than all interfaces for device.
However such a choice would proliferate the number of Mount Bindings
required. In the future it is expected that filtering mechanisms
will be in place to restrict the number of fields actually available/
accessible across a Mount Binding. Therefore reducing the number of
Mount Bindings in a model is a recommended best practice.
2.3.2. Why are Network Element counters exposed under policy?
Counters might be used by other applications, so why would you expose
this information so parochially? With data normalization, counters
would typically be exposed without having to look at a specific
policy. However since we are mounting a read-only copy,
normalization is not as critical. Since we are show how information
can be mounted locally while maximizing application simplicity.
2.3.3. Interface Ref into Network Element Configuration
The authoritative copy of the individual device policers is located
on this controller. It is assumed that the authoritative interface
configuration is not. This type of object ownership distribution
will be common place.
If we were to directly Mount RFC 7223 [RFC7223] interface info from
some remote authoritative source, it would not be possible to add
additional objects within this datastore. So rather than leading the
datastore tree structure with a list of interfaces, and have the
policed bandwidth contained as a data node below the list elements,
we instead have a list of policed bandwidth configuration, each
referring to an NE/interface that the specific bandwidth
configuration pertains. Consistency/integrity is maintained by
having NE/interface reference the corresponding nodes in the mounted
information. This leverages the model to employ cross-network
consistency validation.
Tripathy, et al. Expires April 30, 2015 [Page 5]
Internet-Draft Cloud SLA Model October 2014
2.3.4. Pub/Sub and Cache
It makes little sense for many services to continually ping for
Operational statistics since they can be automatically delivered on a
schedule. In this case, it is useful to subscribe to changes once,
and have them delivered continually. Since Pub/Sub and Caching are
capabilities which are required, but which would actually be embodied
underneath the YANG syntax, these topic are not explicitly part of
this model. Additional drafts to cover these topics are planned.
3. YANG Module
<CODE BEGINS>
file "ietf-cloud-sla@2014-10-21.yang"
module ietf-cloud-sla {
namespace "urn:ietf:params:xml:ns:yang:ietf-cloud-sla";
// replace with IANA namespace if it is ever assigned
prefix csla;
import ietf-inet-types {
prefix "inet";
}
import mount {
prefix mnt;
}
import ietf-interfaces {
prefix iif;
}
organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact
"WG Web: http://tools.ietf.org/wg/netmod/
WG List: netmod@ietf.org
WG Chair: Tom Nadeau
tnadeau@lucidvision.com
WG Chair: Juergen Schoenwaelder
j.schoenwaelder@jacobs-university.de
Editor: Ambika Prasad Tripathy
ambtripa@cisco.com";
description
description
Tripathy, et al. Expires April 30, 2015 [Page 6]
Internet-Draft Cloud SLA Model October 2014
"This YANG module defines a generic configuration and operational model
for Could Domain Policer + Distributes-Denial-of-Service attach
detection and mitigation application.";
revision 2014-10-21 {
description "Initial revision.";
reference "Cloud SLA YANG Model with Mount Semantics";
}
container ietf-cloud-sla {
description
"This container defines the set of objects, properties, and rpc
needed for Cloud SLA applications. As this container includes a
Mount Point, several object definitions will be loaded from other
sources";
container policies {
description
"Provides policy related configuration and operational objects.
At some point this draft will need to morph in order to be
compliant with a netmod WG ACL draft. Since one had not been
adopted at the time of this draft, we have not created a robust
ACL or Policy model in this draft.";
list policy {
description
"A Cloud SLA policy which applies across many network
elements at once, allowing them to be treated as a
composite entity.";
key "policy-name";
leaf policy-name {
type string;
description
"Defines unique policy name for a controller or network
domain. This policy will be associated with a set of
routers, possibly including routers from many
vendors.";
}
leaf policy-max-bw {
type uint64;
description
"The maximum policed bandwidth incoming to the set of
router interfaces where the policy has been applied.
This policy will typically be distributed across
multiple routers and/or switches.";
}
leaf network-aggregate-bw {
type uint64;
Tripathy, et al. Expires April 30, 2015 [Page 7]
Internet-Draft Cloud SLA Model October 2014
config false;
description
"This operational object should be updated by the
application. Every ?x? seconds this will include the
sum of aggregated network bandwidth across the set of
tracked interfaces.";
}
container nes {
description
"This container defines the configuration and
operational objects for all the network elements where
the cloud wide policy is being applied.";
list ne {
description
"Defines the set of properties associated with each
network element involved with a global policy. The
property may be config or operational.";
key "ne-id";
leaf ne-id {
type string;
description
"The network element uniquely identified by IP
address. This attribute should be used as the
key to access information related to a specific
network element. Yes having the ne-id as an IP
address as the key is less than optimal. But
it works to simplify this example model.";
}
container policing-policies {
list policed-bandwidth {
description
"Contains bandwidth limits that are in effect for
an interface of the remote network element. Each
interface for which a limit is in effect needs to
have a corresponding list entry; the absence of a
list entry for an interface implies that no limit
needing to be policed is in effect.";
key "ifref";
leaf ifref {
type mounted-interface-ref;
description
"References an interface of the remote network
element.";
}
leaf bandwidth {
type uint64;
description
"Specifies the bandwidth limit, in bps, that
Tripathy, et al. Expires April 30, 2015 [Page 8]
Internet-Draft Cloud SLA Model October 2014
traffic on this interface needs to be policed
to.";
}
}
}
container interfaces-state {
config false;
description
"Data nodes for the operational state of all
interfaces on a network element.";
mnt:mountpoint "interface-statistics" {
mnt:target "../../../ne-id";
mnt:subtree "/iif:interfaces";
}
}
container ddos-prop-conf {
description
"This container defines the config
attributes needed for the network element to
handle DDoS traffic scrubbing operation if
DDoS attach detected by application. The
current way of detecting DDoS attach is
based on interface counters for the subnet
used in a QoS policy defined by CISCO
routers.";
leaf access-list-name {
type string;
description
"Defines the preconfigured ACL which can
be applied when DDoS traffic detected by
the application for fwd traffic DDoS
sniffers.";
}
}
}
container ddos {
leaf ddos {
type empty ;
description
"This leaf enables DDoS scrubbing for the
policy.";
}
leaf potential-ddos-underway {
type boolean;
config false;
description
"This leaf flag should be updated when DDoS
Tripathy, et al. Expires April 30, 2015 [Page 9]
Internet-Draft Cloud SLA Model October 2014
scrubbing is on.";
}
leaf redirect-activated {
type boolean;
config false;
description
"This leaf flag should be updated by application
if acl based forwarding applied for the subnet
traffic.";
}
leaf redirect-actvation-time {
type uint64;
config false;
description
"The time duration during which last DDoS attack
appeared.";
}
}
}
}
}
typedef mounted-interface-ref {
type leafref {
path "/ietf-cloud-sla/policies/policy/nes/ne/interface-
state/interface-statistics/
iif:interfaces/iif:interface/iif:name";
description
"This type represents a reference to an interface list
element that is mounted from a remoted network element.";
}
}
}
<CODE ENDS>
Beyond the YANG definition itself, we need to insert the expression
for the path identifying the ifname in the mounted list. We it might
be possible to do this by moving into a "pattern" substatement of the
type component of the definition.
Tripathy, et al. Expires April 30, 2015 [Page 10]
Internet-Draft Cloud SLA Model October 2014
typedef mounted-interface-ref {
type leafref {
path ?/ietf-cloud-sla/policies/policy[pn]/nes/ne[ne-
id]/interface-statistics/ifname?;
description
"This type represents a reference to an interface list
element that is mounted from a remoted network element.";
}
}
4. IANA Considerations
This document makes no request of IANA.
5. Security Considerations
6. Acknowledgements
7. References
7.1. Normative References
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, May 2014.
7.2. Informative References
[draft-clemm-mount]
"Mounting YANG-Defined Information from Remote
Datastores", 2013, <http://tools.ietf.org/id/
draft-clemm-netmod-mount-02.txt>.
[peermount-req]
Voit, E., "Requirements for Peer Mounting of YANG subtrees
from Remote Datastores", October 2014,
<http://www.ietf.org/internet-drafts/
draft-voit-netmod-peer-mount-requirements-01.txt>.
Authors' Addresses
Ambika Tripathy
Cisco Systems
Email: ambtripa@cisco.com
Tripathy, et al. Expires April 30, 2015 [Page 11]
Internet-Draft Cloud SLA Model October 2014
Eric Voit
Cisco Systems
Email: evoit@cisco.com
Alex Clemm
Cisco Systems
Email: alex@cisco.com
Tripathy, et al. Expires April 30, 2015 [Page 12]
