On Mon, Feb 08, 2016 at 05:50:00PM +0000, Gert Grammel wrote: > Hi Juergen, > > I think the indentation in our emails play havoc which is confusing me > too. The key point I am making is: > > The mapping of what is called intended-config onto data stores would > deserve more detailed discussion. It seems the authors of > draft-kwatsen-netmod-opstate-02.txt had in mind to associate intended-cfg > with the [running] datastore. In my understanding, 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
This is not how I understood that state of the discussions. I do not think that the NETCONF <running/> configuration datastore changes in existing implementations dynamically. Does it on Junos? > 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. > > ——— > > > I am also wondring if we have the same understanding related to the > following statement: > I thought the whole point of having an applied config is to be able to > see the difference between intended (oops running) and applied. > > > The current draft-kwatsen-netmod-opstate-02.txt says: > "Any rollback that may occur will restore both the intended and the > applied configurations to their previous states." This rollback requirement is in my view broken (I assume people will figure this out when they try to implement solutions for it). Anyway, NETCONF today commits <candidate/> to <running/> and I do not think we should mess around with that. > The challenge I have is the term “(oops running)” in the first sentence in > combination with the citation. I reckon that any difference between > intended-config and applied-config shall be visible whereby the > intended-config is provided by the client and never altered by the server. > Applied-config on the other hand represents the state of the server. If a > failure happens in the application phase, it shall be treated accordingly > (rollback-, stop-, continue-on-error). As a result the difference between > intended and applied configuration shall be maintained. > So does this square with the notion "intended=running" and “applied” > config? Yes (with the caveat that the rollback requirement text is kind of broken). /js > - Gert > > > > > > On 2016-08-02 17:38, "Juergen Schoenwaelder" > <j.schoenwael...@jacobs-university.de> wrote: > > >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/> > -- 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
