Please see RW: inline
On 12/07/2016 20:15, Andy Bierman wrote:
On Tue, Jul 12, 2016 at 12:07 PM, Juergen Schoenwaelder
<j.schoenwael...@jacobs-university.de
<mailto:j.schoenwael...@jacobs-university.de>> wrote:
On Tue, Jul 12, 2016 at 11:36:03AM -0700, Andy Bierman wrote:
> Yes there is value in modeling conventions in general.
> I am trying to understand the value of this specific convention.
>
> If I have an RPC that asks for applied state, then it doesn't
really matter
> how the config and state is organized. There is only overlap in
the objects
> if the data model is designed that way.
>
> Whether or not an edit is applied yet is a property of the
implementation,
> not the data model.
The current /foo and /foo-state approach requires some amount of
duplication. If the trees contain some nested lists of lists, you have
to at least replicate all the key leafs in the schema definition. For
a small model, this is not a bit deal; for more complex models, this
becomes complex and there are possible sources of errors. If it is
possible to simply data models, this may be a long-term win.
It only requires duplication if you insist on modeling opstate objects.
IMO an RPC + notification approach is far superior.
RW:
Are you thinking of a single global notification of convergence?
Although such a scheme may be sufficient if the configuration is
changing infrequently, it is not sufficient for a system in which
configuration is changing frequently (e.g. say to provision very short
lived tunnels across a data center network).
If the client is interested when a particular config change has
converged then a global converged flag:
(i) may be delayed a long time (if at all) after the config change has
completed (because other subsequent config operations are in progress)
(ii) may be hard to relate back to the original config change
Hence, I think that there are only 2 technical solutions to this problem:
(a) reporting/notifying the state of the applied configuration nodes (as
per the requirements stated in draft-ietf-netmod-opstate-reqs, and
covered by the all the various solution drafts)
(b) report the success/failure of the particular config operation.
My opinion, is that as network configuration becomes more dynamic, and
programmatically controlled then (a) is the easier solution and more
robust to failure over (b). But both approaches can be supported by
devices.
In this approach I only need to identify the intended config object
and retrieve (or be notified) of the applied-state transition.
RW:
This is only part of the solution, since metadata can only be used when
nodes exist in the YANG data tree. So, this method alone cannot
indicate configuration that is applied by the device and is in the
process of being deleted.
That is primarily why draft-wilton-netconf-opstate-metadata-00 offers
metadata both on the "persistent" datastore and "operational state
datastore".
The reason why we have the /foo and /foo-state convention is, I
believe, the design of the NETCONF <get/> operation, which assumes
state and config can be represented together in a single tree. And we
have carried this further into YANG (e.g., the way contexts are
constructed for xpath expressions). In hindsight, I am not sure the
consequences of the <get/> design were that well thought through - but
I am not complaining, at that time we did not have YANG nor did we
have experience with bigger data models written in YANG. Is it worth
fixing it? This is a tough question and I understand that people have
different opinions and also different views on where we are on the
lifecycle of this technology. The challenge, as always, is to evolve a
technology along with its usage and upcoming new requirements. If the
evolution is too fast, you risk fragmentation since people will then
run many different versions. If evolution is too slow or stops
entirely, you pave the way for complete replacements of the
technology.
I think it is worth to step back for a moment and to think about where
we like to be in 5 or 10 years from now when we discuss architectural
questions.
We have read-only foo-state because we have only been standardizing
monitoring data for the last 30 years. I completely agree that if the
state depends
on the config in order for an instance to exist, then co-locate the
config and
state and share the node naming.
But modeling admin-state and oper-state with the same object is not a
requirement.
RW:
I agree, but when the oper-state exactly of a node reflects the applied
admin-state then I see no benefit in having a separate duplicate "config
false" node.
Rob
Being able to determine if the intended config is applied yet is a
requirement.
This can be done with protocol operations so it is 100% data model
neutral.
/js
Andy
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
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
