Hi,
On 05/02/2016 17:34, Juergen Schoenwaelder wrote:
On Fri, Feb 05, 2016 at 05:22:03PM +0000, Robert Wilton wrote:
2. Personally, for a datastore solution, I would prefer if the new
datastore was for the intended configuration, and that the applied
configuration was stored in the same datastore (running?) as all the
rest of the operational state.
The running datastore is a configuration datastore, it does not hold
operational state.
OK. Thanks for the clarification. I hadn't realised that the
definition of datastores only applies to configuration and not to state!
So, am I right in saying that this draft is effectively reclassifying
that definition somewhat - given that applied configuration is being
defined as operational state (at least in the diagram in section 3.
Conceptual model) and datastores don't store state data?
If the logical flows of system information is as follows:
[candidate] -> intended cfg -> applied cfg -> derived state
Then it seems strange to bundle intended cfg & derived state together in
one datastore, and to have applied-cfg separate (a bit like an unwanted
step child).
This is not what is being proposed. We always had
[candidate] -> [running] -> operational state
(and I mark configuration data stores in []). Both [candidate] and
[running] have the same configuration data model. Now we are asked
to expose that [running] may not be applied synchronously and hence
[candidate] -> [running] -> [applied] -> derived state
seems to make sense.
5. Am I correct to presume that this draft doesn't provide any support
to return intended config, applied config & derived state all in a
single request? I appreciate that this isn't included as a formal
requirement - but part of me wonders whether this might have been an
oversight in the requirements.
Can be defines easily as another RPC. That said, I heard that some big
vendors even refuse to implement today's get operation that returns
the combination of [running] and operational state.
OK, but the key question is what does that returned data look like: Are
the intended and applied config nodes going to be co-located in the same
structure or is the response going to be two separate trees and for it
to be up to the client to merge them together?
6. I can understand the decision of get-diff to reuse edit-config or
YANG patch, but I'm not sure that this makes it particularly easy for
clients to then process that data. I might be wrong, but I suspect that
a solution that returns the values of the intended and applied config
nodes in an easier to relate way may be preferable (perhaps something
along the lines of the encoding proposed in
draft-wilton-netmod-opstate-yang).
A diff is a way to make delta's efficient.
Yes, but often diffs include both the old and the new values to make it
easier to see what the change is (or certainly they do whenever I review
code diffs).
I don't think that the YANG patch/edit-config encoding is significantly
more efficient that the encoding that I suggested, so I don't think that
efficiency of encoding is a strong argument here.
The strongest argument for edit-config and YANG patch is that it is
reusing an existing solution rather than inventing a new way of doing
this. But I still think that my observation that this doesn't make it
particularly easy for clients is valid, and other ways of encoding the
data could make it easier and more useful.
Rob
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
