On 2016-05-02 18:34, "netmod on behalf of Juergen Schoenwaelder" <netmod-boun...@ietf.org on behalf of j.schoenwael...@jacobs-university.de> 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. > >> 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. The mapping of what is called intended-config onto data stores would deserve more detailed discussion. It seems the authors of this draft had in mind to associate intended-cfg with the [running] datastore. With that mapping, a failure in applying [running] to [applied] will update the [running] datastore to reflect which part is effectively applied. So a fair representation of that case would be: [candidate] -> [running] <--> [applied] -> derived state In the context of intended configuration however that doesn¹t make sense to me. A failure in applying intended configuration doesn¹t change the intention and the delta between intended and applied-config is the key value. A server that would "clean-up² intended-cfg in presence of a failure to apply would look picture perfect instead of exposing the problem clearly. Hence the sequence should more look like: [candidate] -> [intended] ‹> [running==applied] -> derived state Whatever we choose, I believe we need to spell out what¹s the data in a failure case. It¹s probably a bit late to update the requirements draft, but we can probably find a suitable place. > >> 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. > >> 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. > >/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 >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
