On 11/02/2016 09:29, Juergen Schoenwaelder wrote:
On Wed, Feb 10, 2016 at 05:45:10PM +0000, Robert Wilton wrote:
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.
This is how it should be.
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?
We are discussing this text:
D. The configuration protocol MUST specify how configuration
errors are handled. Errors SHOULD be handled by semantics
similar to NETCONF's error-options for the <edit-config>
operation (stop-on-error, continue-on-error, rollback-on-
error), as described in Section 7.2 in [RFC6241], but
extended to incorporate both the intended and applied
configurations. Support for "rollback on error" semantics
SHOULD be provided.
First, let me observe that it is underspecified what a 'configuration
error' is in the context of this requirement statement. Is the
configuration of an interface that is currently not present a
configuration error?
My opinion is yes, this is an error and hence would cause configuration
to fail and rollback if "rollback-on-error" semantics had been requested.
If the request had used continue-on-error semantics then I would expect
that you would see this configuration in intended, but not applied.
If not, does it become a configuration error if a
line card is inserted to which the configuration can not be applied?
As above, this question doesn't directly apply.
But a similar question might be: what would happen if the configuration
had previously been accepted and then a linecard removed? In this case
the the affected interface configuration would stay in intended but be
removed from applied by the system.
Note that NETCONF together with YANG provides a rather clear
definition what validation of a configuration datastore means. When we
talk about applied config and the difference between intended and
applied config, the notion of what is a configuration error is not
clear cut anymore.
Personally, I agree that having tighter semantics are a good thing here
(and should be covered by the solution draft).
Second, in order to rollback, there needs to be a configuration that
can be safely rolled back into. The only robust way I can imagine to
implement this rollback requirement is to use locks until the whole
new config has been applied, thereby turning an asynchronous system
into a synchronous system. Otherwise, I fail to see how I can ensure
that I have a configuration that can be safely rolled back into.
Locks are the simplest way of implementing this, but I agree that they
defeat the point of async configuration updates.
I don't think that locking is the only way to solve this. I would have
thought that one of the optimistic transactional locking approaches
could be used to process multiple requests concurrently.
Hence, I think that the decision as to whether or not to use a global
lock should probably be specified during the client operation (if at
all), and the solution draft shouldn't enforce always using a server
side lock. Instead it should specify the exact semantics that a client
can expect when interacting with the server during configuration
requests. This is to allow for flexibility in server implementations -
i.e. to trade off complexity for performance.
Rob
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
