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]