Hi Kent,
Yes, I think that we are in agreement.
I've one further comment inline below ...
On 23/12/2015 02:41, Kent Watsen wrote:
[As a contributor]
Hi Robert, I want to go back to Jason’s original questions. I think we’re
aligned on this, but please check my answers below.
Quoting Jason’s original text now:
Is there some intention in the opstate requirements to add some sort
of all-or-nothing behavior to transition (C)?
Yes
i.e. if some part of
an edit fails during the transition from intended->applied we should
"rollback" the other parts that may have already been applied ?
Yes
Would we then remove it all from intended as well ?
IMO, yes. This is more easily understood when thinking about Synchronous
Configuration Operations (defined in opstate-reqs), but I believe that it
equally applies to Asynchronous Configuration Operations, so long as the client
explicitly ops-in for the behavior.
I'm not sure how that would work for an async/hybrid (read "real”)
system. We've already done an "ack" back to the client before
transition (C) so the client may have already sent some additional
new config that depends on the previous edit. That would mean that
new config isn't valid.
I’m not a fan on the “hybrid” term, but in thinking about legacy or existing
NETCONF servers, I think that this is a non-issue as the server wouldn’t
advertise support for Rollback on Error in the first place.
I agree that "hybrid" probably isn't a good term.
It is probably worth noting that NETCONF already defines a
rollback-on-error optional capability, but that shouldn't be a problem
because I think that we only need to concern ourselves with servers that
express support for an explicit sync or async capability.
Thanks,
Rob
Kent
On 12/21/15, 1:57 PM, "netmod on behalf of Robert Wilton" <netmod-boun...@ietf.org
on behalf of rwil...@cisco.com> wrote:
Hi Jason,
Picking up this slightly old thread.
The "rollback on error" definition that I added I took directly from
RFC6241, so it's good that they look similar. The intention is that the
NETCONF "rollback-on-error" capability is a valid implementation of this
requirement :-)
I think that the rollback-on-error capability defined in RFC6241 can
also be applied to the running datastore. Certainly, the example quoted
is in the context of the edit-config request on the running-config
datastore, and the RFC description of this feature doesn't appear to
limit it to the candidate datastore in any way.
Thanks,
Rob
On 03/11/2015 07:23, Sterne, Jason (Jason) wrote:
Hi all,
The term "rollback on error" (and other error options) has been used during
these discussions around the opstate requirements.
That term already has some meaning in RFC6241 (or at least rollback-on-error does and that is pretty
close) and IMO it (today) has nothing to do with "applied" config. It is an error option
that has the scope of the contents of a single edit-config request and how those contents get applied
(all or nothing) to the candidate DS (which is neither intended nor applied config) or to the running
DS (intended) if the <target> is <running/>.
I think we need to clarify this "all or nothing" concept and how it is related to
"applied" config. We may also want to use slightly different terminology so we don't get
confused with today's meaning of rollback-on-error.
There are a few transitions to consider when editing a config and applying it
to a device (I'll give the example of using the candidate DS):
(A) config changes ---> candidate DS (<edit-config>)
(B) candidate DS ----> running (intended) (<commit>)
(C) intended ----> applied (internal processed in the device)
Today rollback-on-error is only applicable to transition (A).
Transition (B) does have all-or-nothing properties (as described in RFC6241) but that
isn't related to "rollback-on-error".
Is there some intention in the opstate requirements to add some sort of all-or-nothing
behavior to transition (C) ? i.e. if some part of an edit fails during the transition from
intended->applied we should "rollback" the other parts that may have already
been applied ?
Would we then remove it all from intended as well ?
I'm not sure how that would work for an async/hybrid (read "real") system. We've already
done an "ack" back to the client before transition (C) so the client may have already
sent some additional new config that depends on the previous edit. That would mean that new config
isn't valid.
Jason
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
