[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Configuration Working Group                            K. Watsen
Internet-Draft                                          Juniper Networks
Expires: August 22, 2013                               February 18, 2013


             Conditional Enablement of Configuration Nodes
                draft-kwatsen-conditional-enablement-00

Abstract

   This memo presents a cross-cutting technique whereby a NETCONF server
   can support conditional enablement of configuration nodes.  That is,
   whether the node is active or not depends on the evaluation of an
   expression.  Two expression types are defined herein, one for latent
   configuration (present but not actualized) and another for temporal
   configuration (actualized based on time).  This soluton presented is
   extensible so that additional expression types may be added in the
   future.

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 August 22, 2013.

Copyright Notice

   Copyright (c) 2013 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
   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



Watsen                   Expires August 22, 2013                [Page 1]


Internet-Draft   Conditional Enablement of Config Nodes    February 2013


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Requirements Terminology  . . . . . . . . . . . . . . . . . . . 3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Explicit Nodes Defined in NETMOD Drafts . . . . . . . . . . 3
     3.2.  Precendent in Juniper's JUNOS-Based Products  . . . . . . . 4
     3.3.  Use-Cases Scoped By I2RS Working Group  . . . . . . . . . . 5
   4.  Expression Types  . . . . . . . . . . . . . . . . . . . . . . . 5
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . 5
     4.2.  Simple Expressions  . . . . . . . . . . . . . . . . . . . . 5
     4.3.  Complex Expressions . . . . . . . . . . . . . . . . . . . . 5
   5.  Feature Types . . . . . . . . . . . . . . . . . . . . . . . . . 6
     5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . 6
     5.2.  Simple  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     5.3.  Time  . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Conditional Enablement Capability . . . . . . . . . . . . . . . 7
     6.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . 7
     6.2.  Dependencies  . . . . . . . . . . . . . . . . . . . . . . . 7
     6.3.  Capability Identifier . . . . . . . . . . . . . . . . . . . 7
     6.4.  New Operations  . . . . . . . . . . . . . . . . . . . . . . 7
     6.5.  Modifications to Existing Operations  . . . . . . . . . . . 7
     6.6.  Interactions with Other Capabilities  . . . . . . . . . . . 8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   9.  Normative References  . . . . . . . . . . . . . . . . . . . . . 8






















Watsen                   Expires August 22, 2013                [Page 2]


Internet-Draft   Conditional Enablement of Config Nodes    February 2013


1.  Requirements Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Introduction

   This memo presents a cross-cutting technique whereby a NETCONF server
   can support conditional enablement of configuration nodes.  That is,
   whether the node is active or not depends on the evaluation of an
   expression.  Two expression types are defined herein, one for latent
   configuration (present but not actualized) and another for temporal
   configuration (actualized based on time).  This soluton presented is
   extensible so that additional expression types may be added in the
   future.

3.  Motivation

3.1.  Explicit Nodes Defined in NETMOD Drafts

   Two separate drafts presented during the NETMOD meeting and IETF 85
   had data-models with explicit "enabled" leaves (see examples below).
   One of the questions asked during the sessions was if cross-cutting
   concerns, such as if a node were enabled, wouldn't be better
   supported via meta-data, to which there was general agreement.

   Example of an "enabled" leaf from
   draft-ietf-netmod-routing-cfg-06.txt:

       leaf enabled {
           type boolean;
           default "true";
           description
               "Enable/disable the router instance.

               If this parameter is false, the parent router instance is
               disabled, despite any other configuration that might be
               present.";
       }

                                 Figure 1









Watsen                   Expires August 22, 2013                [Page 3]


Internet-Draft   Conditional Enablement of Config Nodes    February 2013


   Example of an "enabled" leaf from
   draft-ietf-netmod-system-mgmt-04.txt:

     leaf enabled {
         type boolean;
         default true;
         description
             "Indicates whether this server is enabled for use or not.";
     }

                                 Figure 2

3.2.  Precendent in Juniper's JUNOS-Based Products

   Further, there is already a precendent for this strategy in Juniper's
   JUNOS-based products, where any configuration node can be flagged
   with an XML attribute stating that it is inactive.

   Example of a JUNOS "inactive" statement:

       <interface inactive="inactive">...<interface>

                                 Figure 3

   Additionally, JUNOS also supports the notion of a list of
   conditionals that must all be satisfied for an associated
   configuration to be applied.  JUNOS supports the conditionals to be
   based on chassis type, model type, routing engine, member, and time.

   Example of a JUNOS "when" statement (this is not YANG):

       groups {
           my-group-g1 {
               system {
                   hostname xyz;
               }
           when {
               model tx1000;
               routing-engine re0;
               time 2am to 4am;
           }
         }
       }

                                 Figure 4






Watsen                   Expires August 22, 2013                [Page 4]


Internet-Draft   Conditional Enablement of Config Nodes    February 2013


3.3.  Use-Cases Scoped By I2RS Working Group

   Lastly, discusions with the I2RS Working Group have revealed that
   they believe they have a need for a device to autonomously switch
   configuration settings based on time.

4.  Expression Types

4.1.  Overview

   Conditional expressions are boolean expressions that evaluate to
   either "true" or "false".

   Expressions are contained inside an XML attribute called "enabled".
   An expression that evaluates to "true" enables the associated node,
   whereas an expression that evaluates to "false" disables it.

   A configuration node having no expression set is equivalent to an
   expression evaluating to "true".  That is, all nodes are enabled by
   default.

   Example usage:

       <foobar enabled="<expression>"/>

4.2.  Simple Expressions

   Simple expressions are the most trivial expressions possible; they
   are simply either the constant value "true" or "false".

     expressions = "true" / "false";

   Simple expressions are useful to disable a configuration node until
   it is explicitly reenabled.  Since this is such a common use-case,
   this draft enables simple expressions to be supported without having
   to implement support for complex expressions.

   A device advertises support for simple expressions using the feature
   "simple" in its capability string:

     <capability string>?features=simple

4.3.  Complex Expressions

   All expressions that are not "simple" are "complex".  These
   expressions require being able to compare values and evaluate logical
   expressions; they do not need to perform arithmetic, bitwise
   operations, or assignments.



Watsen                   Expires August 22, 2013                [Page 5]


Internet-Draft   Conditional Enablement of Config Nodes    February 2013


   The grammer is the same for all complex expresssions, the only thing
   that varies is what variable assignments the device supports (e.g.
   time, reference to a statistical value, etc.).

   A device does not explicitly advertise support for complex
   expressions.  Support for complex expressions are implicit when any
   feature depending on complex expressions (e.g. time) is advertized.
   For instance:

     <capability string>?features=time

   Complex expressions use the following grammer:

   <expression>  = [ <paren-expr> / <and-expr> / <or-expr> /
                     <not-expr> / <static-expr> / <simple-expr> ]
   <paren-expr>  = "(" <expression> ")"
   <and-expr>    = <expression> " && " <expression>
   <or-expr>     = <expression> " || " <expression>
   <not-expr>    = " ! " <expression>
   <static-expr> = "true" / "false"
   <simple-expr> = <variable> <operator> <value>
   <variable>    = *char
   <operator>    = " == " / " != " / " > " / " < " / " <= " / " >= "
   <value>       = *char

   # NOTES
   #
   # Valid <variables> values dependent on what the device advertises
   # support for.  # Similarly, valid <value> values are dependent on
   # the <variable> used in the expression.  For instance, the "time"
   # feature defines the variables "dayofweek" and "houe", each of which
   # can only be compared to specific values.  For instance: ((dayofweek
   # >= "Mon" && <= "Fri) && (hour >= 9am && hour <= 5pm))


5.  Feature Types

5.1.  Overview

   The types of expressions a device supports is advertised as a list of
   "features" in the capability identifier string.

5.2.  Simple

   The "simple" feature defines support for constant boolean values
   "true" and "false".  Simple expressions are useful to disable a node
   until it is explicitly reenabled.




Watsen                   Expires August 22, 2013                [Page 6]


Internet-Draft   Conditional Enablement of Config Nodes    February 2013


5.3.  Time

   The "time" feature defines support for complex expressions using
   time-oriented values such as "dayofweek" and "hour".  Time
   expressions are useful to implement policies that depend on time.

6.  Conditional Enablement Capability

6.1.  Overview

   The :conditional-enablement capability advertises that the NETCONF
   server supports the ability for nodes in its to be annotated with
   metadata specifying conditions when it is enabled or its values vary.

6.2.  Dependencies

   None.

6.3.  Capability Identifier

   The :conditional-enablement capability is identified by the following
   capability string:

     urn:ietf:params:netconf:capability:conditional-enablement:1.0? \
     features={name,...}

   The :conditional-enablement capability URI MUST contain a "features"
   argument assigned a comma-separated list of names indicating which
   expression-types the NETCONF peer supports.  For example:

     urn:ietf:params:netconf:capability:conditional-enablement:1.0? \
     features=simple,time

6.4.  New Operations

   None.

6.5.  Modifications to Existing Operations

   The :conditional-enablement capability modifies any operation that
   transmits configuration, including:

      <get-config>

      <edit-config>

      <copy-config>




Watsen                   Expires August 22, 2013                [Page 7]


Internet-Draft   Conditional Enablement of Config Nodes    February 2013


   A NETCONF server advertising the :conditional capability indicates
   that any node in its configuration MAY contain XML attributes defined
   in the "Overview" section of this capability, even though those
   attributes were not explicitly defined in its YANG module.

6.6.  Interactions with Other Capabilities

   None.

7.  Security Considerations

   There are no known security considerations at this time.

8.  IANA Considerations

   There are no IANA directives.

9.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Author's Address

   Kent Watsen
   Juniper Networks

   EMail: kwatsen@juniper.net























Watsen                   Expires August 22, 2013                [Page 8]