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]
