On 15/07/2016 15:16, Acee Lindem (acee) wrote:
On 7/14/16, 4:00 PM, "Kent Watsen" <kwat...@juniper.net> wrote:
[This thread took on a life of its own, so I’m replying to this email
>from two days ago]
I had assumed the plan/recommendation would be:
- for works-in-progress, to evaluate if their models can be improved.
- for existing RFCs, do nothing (though we may want to consider
RFC7223).
By “if their models can be improved” in the above, I’m implying that
having a top-level -state branch may still be the best solution for some
models. It’s up to each model designer to decide the best approach for
their models.
Makes sense?
I think the statement “if their models can be improved” leaves too much
subjectivity in the guideline. Either we are going to avail the revised
data store model to avoid duplication of YANG schema nodes or we are going
to leverage the new data stores solely to meet the intended/applied config
requirement. If it is the latter and a good portion of the network devices
will not support, then I would agree.
Devices can still leverage the new operational state datastore (and
hence allow foo and foo-state to be merged) without having to supporting
an intended/applied configuration split (i.e. they just treat applied =
intended).
I'm keen to get the models simpler were possible because I think that
will help with their longevity and ease of use.
Thanks,
Rob
Kent // as a contributor
On 7/12/16, 11:23 AM, "netmod on behalf of Lou Berger"
<netmod-boun...@ietf.org on behalf of lber...@labn.net> wrote:
Acee,
I personally was assuming we'd follow 3, but I'd like to understand
the implication of 2 as I'm not sure I really understand what you're
thinking here. Can you elaborate what you're thinking here?
Thanks,
Lou
On 7/11/2016 12:36 PM, Acee Lindem (acee) wrote:
While there are details to be worked out between the two data stores
models (as indicated below), we now have implicit modeling of applied
configuration. Existing models (both standard and draft) do not take
this
into consideration and, consequently, much of the state that is modeled
explicitly represents the application configuration. For the RFC models,
it probably doesn’t make much sense to redo them (unless they are being
reworked for other reasons). This still leaves the existing WG draft
models for which we have basically 3 options:
1. Do nothing - allow them proceed as they are with multiple ways of
representing the applied configuration. This would provide visibility to
the data independent of whether or not the device supported the revised
data-stores supporting implicit retrieval of the applied configuration.
2. Prune out the redundant data nodes except those required as list
keys, etc, since they can be obtained from the applied state data store.
3. #2 plus collapse the config (read-write) and system-state
(read-only) into common containers. No more branching of
<model-name>-config and <model-name>-state at the top level of the
model.
At I high-level, I feel these are the options. I’m not married to any
one
of these and the worse thing we could do is hold up progression of the
existing YANG model drafts for another couple years while we debate the
best course. Having said that, #3 is compelling since it will yield the
most concise models and colocates the schema data nodes for any managed
object.
Thanks,
Acee
On 7/1/16, 12:36 PM, "netmod on behalf of Lou Berger"
<netmod-boun...@ietf.org on behalf of lber...@labn.net> wrote:
All,
It's time to make a consensus call on this topic, so that we can all
move
on to defining a solution and aligning modules under development. Based
on the feedback received and the overall discussions on the topic, we
see
that there is consensus to follow a datastore based approach to
supporting operational state, i.e., direction 'B'.
We will be asking the authors of [4] and [5] to review their proposals
(individual drafts) in Berlin, as well as to highlight differences and
suggest ways that their work could be consolidated. Of course, others
may
also choose to submit their own proposals. Given the importance of this
work, we will be looking to have active discussion on the topic both in
Berlin and on the list, with an objective of having a draft ready for
considerations as a WG document by the November IETF.
We have reviewed this decision with our AD and the NetConf chairs and
have agreed to begin this work in NetMod. We certainly expect to
coordinate the work with the NetConf WG and re-home work as/if needed.
Finally, we'd also like to thank all those who have contributed to this
discussion to date, from problem identification to proposed solutions,
and we look forward to your continued efforts to publish a standard
solution.
Lou (and Kent)
On 6/7/2016 10:19 AM, Lou Berger wrote:
All,
We want to provide an update based on the off line discussions
related to OpState Solutions that we have been having and solicit
input from the WG.
All authors of current solution drafts [1,2,3] together with those
who helped conduct the solutions analysis* were invited to the these
discussions -- with the objective of coming up with a single
consolidated proposal to bring to the WG. (I/Lou acted as facilitator
as Kent and Juergen were and are involved with the technical details.)
The discussions have yielded some results but, unfortunately,
not a single consolidated proposal as hoped, but rather two
alternate directions -- and clearly we need to choose one:
1) Adopt the conventions for representing state/config
based on Section 6 of [1].
From a model definition perspective, these conventions
impact every model and every model writer.
2) Model OpState using a revised logical datastore definition
as introduced in [4] and also covered in [5]. There is
also a variant of this that we believe doesn't significantly
impact this choice.
With this approach, model definitions need no explicit
changes to support applied configuration.
>From a technology/WG standpoint, we believe an approach
that doesn't impact every model written (i.e., #2) is superior.
The counterpoint to this is that the conventions based
approach (i.e., #1) is available today and being followed in
OpenConfig defined models.
We would like to hear opinions on this from the WG before
declaring one of the following as the WG direction:
A) models that wish to support applied configuration MUST
follow conventions based on [1] -- and the WG needs to
formalize these conventions.
or
B) no explicit support is required for models to support
applied configuration -- and that the WG needs to
formalize an opstate solution based on the approach
discussed in [4] and [5].
We intend to close on this choice before Berlin.
Thank you,
Lou (and co-chairs)
[1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01
[2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02
[3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02
[4]
https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00
[5]
https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00
* - Chris H. and Acee L.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
