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? If not, does it become a configuration error if a
line card is inserted to which the configuration can not be applied?
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.
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.
/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
