On Mon, Feb 08, 2016 at 02:53:57PM +0000, Gert Grammel wrote: > > > >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.
Why would that be the case? If I configure an interface that is not currently present today in running this is just find and running is not expected to change arbitrarily. > 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 What is 'this draft'? I thought the whole point of having an applied config is to be able to see the difference between intended (oops running) and applied. I am confused now. > 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. There is apparently much less agreement on what the problem is, what the terms mean, and how they related to existing technology than I thought. /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
