Robert Wilton <[email protected]> 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!
No, this is not correct. RFC 6241 defines both "datastore" and "configuration datastore". However, "running" is a "configuration datastore". /martin > 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 > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
