Benoit,
A nit on your mail:
On September 10, 2015 4:40:39 AM Benoit Claise <[email protected]> wrote:
Dear all,
The YANG coordination team
<http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html> has
spent some time reading and gathering input on the requirements and
proposed solutions in draft-openconfig-netmod-opstate. This note is to
collect some observations that will hopefully contribute to progress in
the working group.
We believe it is useful to consider that YANG was initially designed to
be a data modeling language for the NETCONF protocol. IETF is also
working on RESTCONF which is an HTTP-based protocol to access data
defined in YANG, using the datastores defined in NETCONF.
YANG is fulfilling its intended role with NETCONF and RESTCONF and has
gained some significant traction in this capacity. There are some
changes worked on in YANG 1.1, but they are mostly incremental.
There is interest in using other protocols outside of NETCONF and
RESTCONF to manipulate data described by YANG. The proposals in the
draft is based on the assertion that YANG models should be usable for
protocols beyond RESTCONF and NETCONF. So these are new requirements on
YANG from, or in preparation for, new protocol bindings.
We have focused on two main aspects of the draft.
FIRSTLY: The proposed split between intended and applied configuration
as described in sections 4.1 (requirements) and 5.1 (implications)
There are two observations here:
1. The implication is that all configurable data nodes ("intended
configuration") shall be repeated in an operational version ("applied
configuration") in all models for all applications going forward. This
would apply independent of if the system is synchronous or asynchronous
in nature. Synchronous systems would simply hard-wire the applied
configuration to be the same as intended configuration at all times.
2. An informal round of conversations with some vendors as well as some
tooling vendors show that there are currently no widely known platforms
that allow for observing the intended and applied state separately. A
common architecture includes a central configuration data store that is
being updated by the manageability framework and updates read by the
subsystems affected by the change (e.g. the BGP service or the interface
manager). In this case, there is no other source of configuration except
for the content of the data store.
While this narrow statement is true, every system I know about can provide
the equivalent of applied config state via show commands.
Lou
Please note that this was not an exhaustive collection of data, but
should give some directional information.
The *implication* we would like to make here is that by making this
feature mandatory part of the YANG language itself (as opposed to an
optional capability) we risk introducing a fake perception that the
current NETCONF server supports a capability it can't support. Indeed,
polling the applied configuration would always return the intended
configuration.
A *question* would be if it would be useful to consider a direction
where we make an attempt to separate out requirements that are tied to
specific protocols and solve them in the protocol semantics rather than
in the language to the extent we can. Without knowing more about the
intended protocol in the case of this draft, it is hard to make more
progress.
A *suggestion* is to ask the draft authors to document the protocol
bindings in order to qualify the requirements going forward.
SECONDLY: The proposed schema locations for configuration and
corresponding operational state in sections 4.5 (requirements) and 5.4
(implications)
The observation to be made here is well captured in the draft itself as
bullet 3 under section 7:
"The proposal does not allow items that are not configured,
configured but not present, or system configured."
Please note that this is a general note that would apply to the language
itself. Meaning that YANG will no longer be able to describe situations
like the above for any type of application in any context.
Examples beyond what's already mentioned in the bullet of this could
include:
- Removable physical assets (line cards, mezzanine cards) in systems
that allow pre-provisioning of configuration
- Physical assets that arrive in the system with readable default state
Independent of the direction we will be taking going forward, the
implication we make is that it is a pretty significant impact on the
expressivity of the language itself and how useful it is in terms of
modeling application data sets that may not align with the requirements.
The question we would ask is if it would be possible to rebalance the
implication and make it a little more modular and optional in the
language. We are aware of suggestions to use the extensibility of the
language itself (e.g. in draft-kwatsen-netmod-opstate) to express
relations across data sets. Understanding that this suggested approach
does not normalize the paths according to the wish of the authors, but
it can perhaps be a balanced approach that impacts the expressivity less.
Regards, the YANG coordination team
----------
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
