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 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."; } } } 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, . [peermount-req] Voit, E., "Requirements for Peer Mounting of YANG subtrees from Remote Datastores", October 2014, . 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]