On 08/02/2016 16:31, Juergen Schoenwaelder wrote:
On Mon, Feb 08, 2016 at 01:30:02PM +0000, Robert Wilton wrote:
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?
Not sure what 'that definition' refers to. This WG has had lenghty
discussions how we look at operational state has. Some of it is
briefly mentioned in RFC 6244 and there were quite a few presentations
at IETF meetings before 'the operators' started contributing ideas.
I was referring to the definition of Configuration Datastore in RFC-6241.
I had mistakenly thought that the running datastore contained both the
running configuration and operational state.
You corrected me that the running datastore only contains config,
although it is still slightly unclear to me whether the operational
state lives in a datastore or not.
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.
So if in my 1 million XML elements one has not been applied, how do I
find out efficiently in your encoding?
By using 'diff-cfg-only' option of the <with-config-state> parameter,
you would get 3 or 4 leaves per mismatching node: (intended value,
applied value, status, and optionally error reason). Only nodes with
differences would be returned.
A more complete example is in
https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02, "A.2.
NETCONF get-config request using with-config-state with diff-cfg-only
option", about page 16.
Yes, this data would be larger than the patch, but it also contains more
information (i.e. reason why they differ, and error string).
The client is also able to process this data straight away. With the
patch, they may need to generate the before and after values to make it
easier to process.
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.
We are on a very slippery slope here - what may be easy for one client
may not be easy for another client. Difficult for taking good
engineering decisions.
Yes, but a diff that provides the old and new values can be used more
flexibly then a diff that only provides the new values. I.e. the client
can always ignore the extra information if they don't need it.
Rob
/js
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
