On 10/02/2016 12:51, Juergen Schoenwaelder wrote:
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?
On Cisco's IOS XR, for a normal configuration commit (i.e. rollback on
error semantics) then if applying the configuration for any config nodes
fails then the whole config commit is undone. I.e. the system ends in
the same state as if the configuration commit never happened - standard
transaction commit semantics.
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).
This was meant to be consistent with the existing rollback-on-error
semantics supported by NETCONF (specified in rfc6241).
As above, my understanding is that Cisco IOS XR already supports these
semantics.
Please can you clarify how/why the requirement is broken?
Rob
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
