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]