Internet DRAFT - draft-bjorklund-netmod-openconfig-reply

draft-bjorklund-netmod-openconfig-reply







Network Working Group                                       M. Bjorklund
Internet-Draft                                            Tail-f Systems
Intended status: Informational                                A. Bierman
Expires: January 7, 2016                                       YumaWorks
                                                        J. Schoenwaelder
                                                       Jacobs University
                                                               K. Watsen
                                                        Juniper Networks
                                                            July 6, 2015


          Comments on Data Organization and Operational State
               draft-bjorklund-netmod-openconfig-reply-00

Abstract

   This document is a reply to OpenConfig's proposed solutions to some
   common data modeling problems.

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 January 7, 2016.

Copyright Notice

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



Bjorklund, et al.        Expires January 7, 2016                [Page 1]

Internet-Draft             OpenConfig Comments                 July 2015


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

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Supporting "asynchronous" implementations.  . . . . . . . . .   2
     2.1.  Alternative Solution  . . . . . . . . . . . . . . . . . .   3
   3.  Need a way to relate config to state. . . . . . . . . . . . .   3
     3.1.  Alternative . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Top-level node  . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Alternative . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Informative References  . . . . . . . . . . . . . . . . . . .   4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   This document is a reply to OpenConfig's proposed solutions to some
   common data model-ling problems, as presented in
   [I-D.openconfig-netmod-opstate] and
   [I-D.openconfig-netmod-model-structure].

2.  Supporting "asynchronous" implementations.

   In [I-D.openconfig-netmod-opstate], the authors propose that all
   configuration nodes are duplicated in a separate config false branch
   of the data tree, in order to support "asynchronous" implementations.
   The config true part of the tree is called "intended configuration",
   and is always modeled under a NP container "config", and the
   duplicate part is called "actual configuration", and is always model-
   led under a NP container "state".

   Cons:

   o Data model duplication.  This reduces the readability of the




Bjorklund, et al.        Expires January 7, 2016                [Page 2]

Internet-Draft             OpenConfig Comments                 July 2015


     models, uses additional memory in implementations, and adds to the
     complexity of the overall solution.
   o Fragile solution, since it relies on a convention; if a
     module doesn't follow this convention, that module cannot
     be used in a such a system.
   o Adding semantics to node names instead of using YANG
     statements.
   o Relies on groupings and therefore the YANG constraints
     will be applied to the config=false copy, even if the
     operational state does not have the same restrictions as
     the config.
   o Mandatory for all platforms even if asynch does not apply.
   o Some leafrefs will be broken - if a leafref has the
     "config" node in its path, then the "state" version of
     the leafref still refers to the "config" node.

2.1.  Alternative Solution

   We propose that the actual config is handled as a separate conceptual
   datastore.  In NETCONF, this can be done by using get-config with a
   new datastore name.  Other protocols would do something similar.

   Pros:

   o This works without rewriting any modules already

     published.  It works with vendor models and models from other SDOs
     that do not follow these conventions.
   o Doesn't cost anything for platforms where asynch does
     not apply.

   Cons:

   o Needs a datastore, a concept that not all protocols support.

     However, the protocol does not have to expose the datastores in the
     same way as NETCONF in order to support this concept.  For
     example, RESTCONF does not have datastores in the way that NETCONF
     does, and it can easily be updated to support the "actual" config
     (and "ephemeral").

3.  Need a way to relate config to state.

   In [I-D.openconfig-netmod-opstate], the authors propose that all data
   models always add two special NP containers "config" and "state"
   which contains all leafs, in order to have a simple and deterministic
   way to related config to state.




Bjorklund, et al.        Expires January 7, 2016                [Page 3]

Internet-Draft             OpenConfig Comments                 July 2015


   Cons:

   o Too simplistic.  Doesn't solve the problem that the

     state may contain different instances than config.
     Configuration data and operational instances are really
     separate entities, and should be modeled as such.
   o Adds noise to the data model.
   o Fragile solution, since it relies on a convention; if a
     module doesn't follow this convention, that module cannot
     be used in a such a system.
   o Adds semantics to node names instead of using YANG statements.
   o If the data model has an address list that has "city,
     state, zipcode" the convention doesn't work.

3.1.  Alternative

   The solution in [RFC7223].

   It should be noted that in both the open config proposal and the
   scheme from [RFC7223], there is no formal way to know the
   relationship between the configuration and its related operational
   state.  It might be worthwhile to try to define YANG statements to
   solve this problem instead.

4.  Top-level node

   In [I-D.openconfig-netmod-model-structure], the authors propose that
   all data models intended for devices are rooted under a top-level
   node called "device".

   Cons:

   o Doesn't solve any problem.  It just adds 7 characters to

     all paths.  Whatever problem there is today with "/FOO"
     will now be a problem with "/device/FOO".
   o All existing models need to be rewritten, including vendor models.

4.1.  Alternative

   Use "/" as the top level.

5.  Informative References







Bjorklund, et al.        Expires January 7, 2016                [Page 4]

Internet-Draft             OpenConfig Comments                 July 2015


   [I-D.openconfig-netmod-model-structure]
              Shaikh, A., Shakir, R., D'Souza, K., and L. Fang,
              "Operational Structure and Organization of YANG Models",
              draft-openconfig-netmod-model-structure (work in
              progress), March 2015.

   [I-D.openconfig-netmod-opstate]
              Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling
              of Operational State Data in YANG", draft-openconfig-
              netmod-opstate (work in progress), March 2015.

   [RFC7223]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 7223, May 2014.

Authors' Addresses

   Martin Bjorklund
   Tail-f Systems

   Email: mbj@tail-f.com


   Andy Bierman
   YumaWorks

   Email: andy@yumaworks.com


   Juergen Schoenwaelder
   Jacobs University

   Email: j.schoenwaelder@jacobs-university.de


   Kent Watsen
   Juniper Networks

   Email: kwatsen@juniper.net













Bjorklund, et al.        Expires January 7, 2016                [Page 5]