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. > >>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? > 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. /js -- 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
