Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
Sorry, missed Kent’s remark: [KENT] or due to missing hardware, right? That’s one root cause, but I didn’t want to go into much details here. Missing Hardware is one issue, other issues are unconscious configuration requests from the client, faulty HW, bugs etc. Whatever the root cause, the result is intended != applied and Client+Server have to deal with it in a meaningful manner. Gert From: Robert Wilton [mailto:rwil...@cisco.com] Sent: 06 January 2016 17:49 To: Kent Watsen; Gert Grammel Cc: netmod@ietf.org Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error) Hi Kent, On 06/01/2016 16:43, Kent Watsen wrote: [As a contributor] Gert> If a client is has the intention to update/change a config, its decision is based on the present state of the configuration when the decision is taken. Ideally the present configuration is in a state where intended == applied config, so there is stable ground upon which a change is applied. However there is also the case where intended != applied config and there are two reasons for that. a) a previous intended config is in the process of being applied b) a previous configuration failed due to an error [KENT] or due to missing hardware, right? Regardless, I don’t think this thread has bearing of the requirements draft. Note that I removed the *-on-error terms from the Terminology section in -02 by instead rewording requirement 2-C, which was the only place they were being referenced before and the reference was merely suggestive (not normative). Can we leave it to the solution drafts to sort out? Yes, deferring this issue to the solutions draft works for me. I don't think that it will have any bearing on the discussion of the overall solution approach. Thanks, Rob ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
Kent, I would agree that the discussion doesn’t affect the requirements draft in its current state. The solutions draft would be a better place probably. Gert From: Kent Watsen Sent: 06 January 2016 17:43 To: Gert Grammel; Robert Wilton Cc: netmod@ietf.org Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error) [As a contributor] Gert> If a client is has the intention to update/change a config, its decision is based on the present state of the configuration when the decision is taken. Ideally the present configuration is in a state where intended == applied config, so there is stable ground upon which a change is applied. However there is also the case where intended != applied config and there are two reasons for that. a) a previous intended config is in the process of being applied b) a previous configuration failed due to an error [KENT] or due to missing hardware, right? Regardless, I don’t think this thread has bearing of the requirements draft. Note that I removed the *-on-error terms from the Terminology section in -02 by instead rewording requirement 2-C, which was the only place they were being referenced before and the reference was merely suggestive (not normative). Can we leave it to the solution drafts to sort out? ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
Hi Kent, On 06/01/2016 16:43, Kent Watsen wrote: [As a contributor] Gert> If a client is has the intention to update/change a config, its decision is based on the present state of the configuration when the decision is taken. Ideally the present configuration is in a state where intended == applied config, so there is stable ground upon which a change is applied. However there is also the case where intended != applied config and there are two reasons for that. a)a previous intended config is in the process of being applied b)a previous configuration failed due to an error [KENT] or due to missing hardware, right? Regardless, I don’t think this thread has bearing of the requirements draft. Note that I removed the *-on-error terms from the Terminology section in -02 by instead rewording requirement 2-C, which was the only place they were being referenced before and the reference was merely suggestive (not normative). Can we leave it to the solution drafts to sort out? Yes, deferring this issue to the solutions draft works for me. I don't think that it will have any bearing on the discussion of the overall solution approach. Thanks, Rob ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
[As a contributor] Gert> If a client is has the intention to update/change a config, its decision is based on the present state of the configuration when the decision is taken. Ideally the present configuration is in a state where intended == applied config, so there is stable ground upon which a change is applied. However there is also the case where intended != applied config and there are two reasons for that. a) a previous intended config is in the process of being applied b) a previous configuration failed due to an error [KENT] or due to missing hardware, right? Regardless, I don’t think this thread has bearing of the requirements draft. Note that I removed the *-on-error terms from the Terminology section in -02 by instead rewording requirement 2-C, which was the only place they were being referenced before and the reference was merely suggestive (not normative). Can we leave it to the solution drafts to sort out? ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
Hi Rob, See below ... --Gert From: Robert Wilton [mailto:rwil...@cisco.com] Sent: 05 January 2016 16:05 To: Gert Grammel Cc: netmod@ietf.org Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error) Hi Gert, Considering a rollback-on-error request that failed: If you leave the configuration in intended config then what happens if a separate config request comes in from another client? Should that request be processed in the context of the failed intended config, or the last successful config change, or must it wait for the original client to decide how to process the failure that occurred? Gert> If a client is has the intention to update/change a config, its decision is based on the present state of the configuration when the decision is taken. Ideally the present configuration is in a state where intended == applied config, so there is stable ground upon which a change is applied. However there is also the case where intended != applied config and there are two reasons for that. a) a previous intended config is in the process of being applied b) a previous configuration failed due to an error In case a) the following config just needs to wait, or if it can be applied without interfering with the previous intended config *may* be executed in parallel (up to the server to implement) Case b) is just about the same as stop-on-error or continue-on-error. If there is an error in configuring a node and the new intended config uses stop-on-error, then it should not be executed. In contrast, a continue-on-error configuration can be applied independently. Also what would happen if the client disconnects from the server when a rollback-on-error request has failed, and the server is waiting for the client to tell it what to do? Gert> the previous (rolled-back) configuration is applied and the intended config remains different from the applied config. It will stay like that until the Client figured out what to do. E.g. one option is to re-apply the intended config with a continue-on-error semantic. If a second client, despite the server calamities, decides to change the config, it can try to do so in a continue-on-error mode as well. I think that what you describe sounds more like a config request to a candidate configuration datastore. I.e. write the config to candidate, and then commit. If the commit fails, the configuration in the running datastore is rolled back but the configuration remains in the candidate datastore. But note that in this scenario both the intended and applied configuration have both been reverted to the state before the commit operation was attempted. Gert> bear with me but I don't parse the two sentences as they seem contradictory. Perhaps you could spend a few more words. I am advocating for a case with a consistent behavior in case of failures in all execution models. Irrespective of stop-on-error, continue-on-error or rollback-on-error, the non-performing configuration is the diff between intended and applied configuration that can conveniently be reported by the server. In any of those cases, the server is rightfully in an errored state with respect to configuration and it is risky to attempt a new configuration unless the client resolves the misalignment. It appears to me that we have broadly 3 failure cases to deal with: 1) The client did a poor job in figuring out which configuration to push on a server 2) The server did a poor job in reporting its own state to the client (see cheating synchronous), which in turn can lead to 1) 3) Something unexpected happens in between the client figuring out the intended config and the server applying it. Case 1) can only be dealt by the Client. 2) is often dealt with re-applying the same intended config a bit later, hoping the server is in a better mood now (by experience it often works). If it still doesn't, it's again up to the client to figure out what's best now. Since the event in 3) may impact the state of the node quite a bit, also here it is the job of the client to figure out which config to apply based on the new state. Thanks, Rob On 28/12/2015 17:40, Gert Grammel wrote: Rob, >From a client perspective there should be no difference in the intended state >behavior depending on error conditions, if continue-on-error leaves the >intended state, a rollback-on-error should keep it as well. Moreover, a client >reaction on a unsuccessful application of intended state could be to a) >re-try, b) retry with continue-on-error or c) retry wit stop-on-error. Those >actions would not require any change of intended state. It shouldn't be the server to decide what the intended state is supposed to be or hoe long it should last. Gert Sent from my Apple ][ On 23 Dec 2015, at 22:25, Robert Wilton mailto:robert.pub...@wilton.org.uk>> wrote: Hi Gert, Please see one comment inli
Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
Hi Gert, Considering a rollback-on-error request that failed: If you leave the configuration in intended config then what happens if a separate config request comes in from another client? Should that request be processed in the context of the failed intended config, or the last successful config change, or must it wait for the original client to decide how to process the failure that occurred? Also what would happen if the client disconnects from the server when a rollback-on-error request has failed, and the server is waiting for the client to tell it what to do? I think that what you describe sounds more like a config request to a candidate configuration datastore. I.e. write the config to candidate, and then commit. If the commit fails, the configuration in the running datastore is rolled back but the configuration remains in the candidate datastore. But note that in this scenario both the intended and applied configuration have both been reverted to the state before the commit operation was attempted. Thanks, Rob On 28/12/2015 17:40, Gert Grammel wrote: Rob, From a client perspective there should be no difference in the intended state behavior depending on error conditions, if continue-on-error leaves the intended state, a rollback-on-error should keep it as well. Moreover, a client reaction on a unsuccessful application of intended state could be to a) re-try, b) retry with continue-on-error or c) retry wit stop-on-error. Those actions would not require any change of intended state. It shouldn't be the server to decide what the intended state is supposed to be or hoe long it should last. Gert Sent from my Apple ][ On 23 Dec 2015, at 22:25, Robert Wilton <mailto:robert.pub...@wilton.org.uk>> wrote: Hi Gert, Please see one comment inline ... On 23/12/2015 10:24, Gert Grammel wrote: Rob, Kent, Adding to Rob’s comments: From: netmod on behalf of Robert Wilton mailto:robert.pub...@wilton.org.uk>> Date: Wednesday 23 December 2015 09:28 To: Kent Watsen , "netmod@ietf.org <mailto:netmod@ietf.org>" mailto:netmod@ietf.org>> Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error) 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 +1 (if rollback-on-error has been requested) 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 +1 (if rollback-on-error has been requested) 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. IMO no. The intended config is imposed by the client to the server and other than performing some syntax check, the server has no choice to accept it as-is. If the server can’t apply the intended config, obviously the mismatch between intended and applied config needs to be notified. As a result, it is up to the client to decide what to do. Actions can vary according to the situation naming a few: 1) retry intended config, 2) retry intended config with continue-on-error, 3) re-apply the previous intended config, … In other words: 1. the client shall not touch the applied config directly, 2. the server shall not touch the intended config, 3. it’s up to the server to align the intended with the applied config in a way requested by the client (i.e. rollback-on-error, …) 4. Once applied, the server notifies the client about success or failure to do so I think that it cleaner just to fail and roll back the entire request (both intended and applied), i.e. effectively implementing default transaction semantics. The client still has full control as to what to do after the failure has occurred. I'm not sure how leaving it in intended config would pragmatically work with subsequent requests that may have been queued up. Thanks, Rob ___ 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
Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
Rob, >From a client perspective there should be no difference in the intended state >behavior depending on error conditions, if continue-on-error leaves the >intended state, a rollback-on-error should keep it as well. Moreover, a client >reaction on a unsuccessful application of intended state could be to a) >re-try, b) retry with continue-on-error or c) retry wit stop-on-error. Those >actions would not require any change of intended state. It shouldn't be the server to decide what the intended state is supposed to be or hoe long it should last. Gert Sent from my Apple ][ On 23 Dec 2015, at 22:25, Robert Wilton mailto:robert.pub...@wilton.org.uk>> wrote: Hi Gert, Please see one comment inline ... On 23/12/2015 10:24, Gert Grammel wrote: Rob, Kent, Adding to Rob's comments: From: netmod <<mailto:netmod-boun...@ietf.org>netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> on behalf of Robert Wilton mailto:robert.pub...@wilton.org.uk>> Date: Wednesday 23 December 2015 09:28 To: Kent Watsen <<mailto:kwat...@juniper.net>kwat...@juniper.net<mailto:kwat...@juniper.net>>, "netmod@ietf.org<mailto:netmod@ietf.org>" mailto:netmod@ietf.org>> Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error) 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 +1 (if rollback-on-error has been requested) 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 +1 (if rollback-on-error has been requested) 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. IMO no. The intended config is imposed by the client to the server and other than performing some syntax check, the server has no choice to accept it as-is. If the server can't apply the intended config, obviously the mismatch between intended and applied config needs to be notified. As a result, it is up to the client to decide what to do. Actions can vary according to the situation naming a few: 1) retry intended config, 2) retry intended config with continue-on-error, 3) re-apply the previous intended config, ... In other words: 1. the client shall not touch the applied config directly, 2. the server shall not touch the intended config, 3. it's up to the server to align the intended with the applied config in a way requested by the client (i.e. rollback-on-error, ...) 4. Once applied, the server notifies the client about success or failure to do so I think that it cleaner just to fail and roll back the entire request (both intended and applied), i.e. effectively implementing default transaction semantics. The client still has full control as to what to do after the failure has occurred. I'm not sure how leaving it in intended config would pragmatically work with subsequent requests that may have been queued up. Thanks, Rob ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
Hi Gert, Please see one comment inline ... On 23/12/2015 10:24, Gert Grammel wrote: Rob, Kent, Adding to Rob’s comments: From: netmod <mailto:netmod-boun...@ietf.org>> on behalf of Robert Wilton mailto:robert.pub...@wilton.org.uk>> Date: Wednesday 23 December 2015 09:28 To: Kent Watsen mailto:kwat...@juniper.net>>, "netmod@ietf.org <mailto:netmod@ietf.org>" <mailto:netmod@ietf.org>> Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error) 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 +1 (if rollback-on-error has been requested) 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 +1 (if rollback-on-error has been requested) 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. IMO no. The intended config is imposed by the client to the server and other than performing some syntax check, the server has no choice to accept it as-is. If the server can’t apply the intended config, obviously the mismatch between intended and applied config needs to be notified. As a result, it is up to the client to decide what to do. Actions can vary according to the situation naming a few: 1) retry intended config, 2) retry intended config with continue-on-error, 3) re-apply the previous intended config, … In other words: 1. the client shall not touch the applied config directly, 2. the server shall not touch the intended config, 3. it’s up to the server to align the intended with the applied config in a way requested by the client (i.e. rollback-on-error, …) 4. Once applied, the server notifies the client about success or failure to do so I think that it cleaner just to fail and roll back the entire request (both intended and applied), i.e. effectively implementing default transaction semantics. The client still has full control as to what to do after the failure has occurred. I'm not sure how leaving it in intended config would pragmatically work with subsequent requests that may have been queued up. Thanks, Rob ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
It seems message quoting is all messed up here (both in mutt and thunderbird). I can't really follow anymore from this message who said what and who agrees with whom on what. /js On Wed, Dec 23, 2015 at 10:24:08AM +, Gert Grammel wrote: > Rob, Kent, > > Adding to Rob’s comments: > > > > From: netmod mailto:netmod-boun...@ietf.org>> on > behalf of Robert Wilton > mailto:robert.pub...@wilton.org.uk>> > Date: Wednesday 23 December 2015 09:28 > To: Kent Watsen mailto:kwat...@juniper.net>>, > "netmod@ietf.org<mailto:netmod@ietf.org>" > mailto:netmod@ietf.org>> > Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on > error) > > 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 > +1 (if rollback-on-error has been requested) > > > > 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 > +1 (if rollback-on-error has been requested) > > > 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. > IMO no. The intended config is imposed by the client to the server and other > than performing some syntax check, the server has no choice to accept it > as-is. If the server can’t apply the intended config, obviously the mismatch > between intended and applied config needs to be notified. As a result, it is > up to the client to decide what to do. Actions can vary according to the > situation naming a few: 1) retry intended config, 2) retry intended config > with continue-on-error, 3) re-apply the previous intended config, … > In other words: > > 1. the client shall not touch the applied config directly, > 2. the server shall not touch the intended config, > 3. it’s up to the server to align the intended with the applied config in > a way requested by the client (i.e. rollback-on-error, …) > 4. Once applied, the server notifies the client about success or failure > to do so > > > > 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. > +1 in fact it’s a "cheating synchronous” behaviour, probably not the best > term either. Let’s find a better term we can agree upon. > > 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. > +1 > > Thanks, > Rob > > > > > Kent > > > > > > On 12/21/15, 1:57 PM, "netmod on behalf of Robert Wilton" > mailto:netmod-boun...@ietf.org> on behalf of > rwil...@cisco.com<mailto: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 candida
Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
Rob, Kent, Adding to Rob’s comments: From: netmod mailto:netmod-boun...@ietf.org>> on behalf of Robert Wilton mailto:robert.pub...@wilton.org.uk>> Date: Wednesday 23 December 2015 09:28 To: Kent Watsen mailto:kwat...@juniper.net>>, "netmod@ietf.org<mailto:netmod@ietf.org>" mailto:netmod@ietf.org>> Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error) 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 +1 (if rollback-on-error has been requested) 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 +1 (if rollback-on-error has been requested) 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. IMO no. The intended config is imposed by the client to the server and other than performing some syntax check, the server has no choice to accept it as-is. If the server can’t apply the intended config, obviously the mismatch between intended and applied config needs to be notified. As a result, it is up to the client to decide what to do. Actions can vary according to the situation naming a few: 1) retry intended config, 2) retry intended config with continue-on-error, 3) re-apply the previous intended config, … In other words: 1. the client shall not touch the applied config directly, 2. the server shall not touch the intended config, 3. it’s up to the server to align the intended with the applied config in a way requested by the client (i.e. rollback-on-error, …) 4. Once applied, the server notifies the client about success or failure to do so 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. +1 in fact it’s a "cheating synchronous” behaviour, probably not the best term either. Let’s find a better term we can agree upon. 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. +1 Thanks, Rob Kent On 12/21/15, 1:57 PM, "netmod on behalf of Robert Wilton" mailto:netmod-boun...@ietf.org> on behalf of rwil...@cisco.com<mailto: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 is . 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 s
Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
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" 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 is . 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 () (B) candidate DS > running (intended) () (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
Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
[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. Kent On 12/21/15, 1:57 PM, "netmod on behalf of Robert Wilton" 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 is . >> >> 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 () >> (B) candidate DS > running (intended) () >> (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
Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
Robert Wilton mailto:rwil...@cisco.com>>
Date: Monday 21 December 2015 19:55
To: Gert Grammel mailto:ggram...@juniper.net>>, Jason Sterne
mailto:jason.ste...@alcatel-lucent.com>>, "netmod@ietf.org
<mailto:netmod@ietf.org>" mailto:netmod@ietf.org>>
Subject: Re: [netmod] netmod-opstate-reqs and error option terms
(rollback on error)
Hi Gert,
Please see inline ...
On 05/11/2015 03:53, Gert Grammel wrote:
Jason,
A synchronous config basically contains two pieces of
information in the commit:
1) the intended configuration is valid (i.e. is syntactically
correct) and
2) the intended config has been applied
Any error that would affect the config before the commit
could be rolled back to the old config and a suitable
notification sent to the client. After the commit, there is
no roll-back.
I agree.
Similarly for asynchronous, however here the information
needs to be split into two messages:
1) a commit that the intended config is valid
2) another message when the intended config is fully applied
(let's call this 'validated').
A rollback can happen before the intended config is fully
applied i.e. before the 'validated' state is reached.
I agree.
The real problem is what you called in another
email 'hybrid' or cheating-synchronous implementations. This
leads to a situation where the client is made to believe the
intended config is applied, but the server still didn't apply
it yet. Take the case where the server runs into trouble
after the synchronous-commit (which lets the client believe
that the intended config is applied) and decides to
roll-back. From a client perspective this would look like a
node randomly losing its committed configuration. There is
tons of code required on the client side to cope with that
situation. So what was the purpose of implementing it that
way in the first place - instead of just applying an
asynchronous implementation?
Yes, I agree that handling rollback could be a problem in this
scenario,
and hence I would propose that the behaviour in such a scenario is
explicitly documented as being undefined in whatever solution is
agreed
upon :-)
Otherwise assuming that all requests are strictly synchronous or
asynchronous then I think that we should be OK with the following
two
rules on the server:
1) All edit-config requests must strictly be processed in order.
2) You cannot tell a client that a request has been full applied
unless
all previous requests specifying rollback-on-error semantics with
any
overlapping nodes with the current request have either be applied or
aborted (i.e. rolled back)
Thanks,
Rob
Gert
-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of
Sterne, Jason (Jason)
Sent: 03 November 2015 08:24
To: netmod@ietf.org <mailto:netmod@ietf.org>
Subject: [netmod] netmod-opstate-reqs and error option terms
(rollback on error)
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
is .
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 ()
(B) candidate DS > running (intended) ()
(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
Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
On Tue, Dec 22, 2015 at 12:31 PM, Robert Wilton wrote: > Hi Gert, > > On 21/12/2015 20:17, Gert Grammel wrote: > > Hi Rob, > > Seems we are pretty close with our understanding, so snipping the only > discussion point left, with further comments: > > Gert > > > > > The real problem is what you called in another email 'hybrid' or > cheating-synchronous implementations. This leads to a situation where the > client is made to believe the intended config is applied, but the server > still didn't apply it yet. Take the case where the server runs into trouble > after the synchronous-commit (which lets the client believe that the > intended config is applied) and decides to roll-back. From a client > perspective this would look like a node randomly losing its committed > configuration. There is tons of code required on the client side to cope > with that situation. So what was the purpose of implementing it that way in > the first place - instead of just applying an asynchronous implementation? > > Yes, I agree that handling rollback could be a problem in this scenario, > and hence I would propose that the behaviour in such a scenario is > explicitly documented as being undefined in whatever solution is agreed > upon :-) > Gert> sadly, we can’t roll time back. So the best option is indeed to > document the issue and move on to improve things > > Otherwise assuming that all requests are strictly synchronous or > asynchronous then I think that we should be OK with the following two > rules on the server: > >1. All edit-config requests must strictly be processed in order. > > Gert> yes, although there are corner cases we need to hash out. I.e. a > client may set a leaf to followed by setting it to . Then a server > may skip setting it to , because it is anyhow overwritten by . > > > Yes, it might, but from a correctness point of view it will need to able > to fail the subsequent request to set the value to and hence set it to > instead. > > What does "processed in order" mean? NETCONF has a requirement that requests on a specific session are processed in the order received. There is no such requirement across multiple sessions doing edits at once. Andy > > > 2) You cannot tell a client that a request has been full applied unless > all previous requests specifying rollback-on-error semantics with any > overlapping nodes with the current request have either be applied or > aborted (i.e. rolled back) > > Gert> with “have bee full applied” you meant a state that I tentatively > named ‘validated’ in my earlier email? I am a bit sensitive to naming > here because of those ‘cheating synchronous nodes’ would return ‘applied’ > without actually doing so in full. It would be great if we could quickly > converge on some naming convention to remove ambiguity. > > > Yes, it means the same state as your 'validated'. I basically just mean > that the synchronous operation has completed (as per the definition of > 'Synchronous Configuration Operation' defined in > draft-ietf-netmod-opstate-reqs-01). > > > > > The rule holds true but I don’t see a dependency on “rollback-on-error” > semantics. In my view it is applicable also in cases of "continue-on-error” > and “stop-on-error” in the sense that unless any error has been reported, > the client still needs to wait for the ‘validated’ state before it can > reliably assume the config was applied. > > I would see that a "continue-on-error" configuration operation is > processed best effort. I.e. even if applying one of more config nodes > failed to be applied, the rest of the configuration contained in a best > effort operation would always be applied. As such subsequent operations > would not need to wait for a best effort request to complete first before > they can complete. > > Thanks, > Rob > > > > > > From: Robert Wilton > Date: Monday 21 December 2015 19:55 > To: Gert Grammel < ggram...@juniper.net>, Jason > Sterne , "netmod@ietf.org" < > netmod@ietf.org> > Subject: Re: [netmod] netmod-opstate-reqs and error option terms > (rollback on error) > > Hi Gert, > > Please see inline ... > > On 05/11/2015 03:53, Gert Grammel wrote: > > Jason, > > A synchronous config basically contains two pieces of information in the > commit: > 1) the intended configuration is valid (i.e. is syntactically correct) and > 2) the intended config has been applied > Any error that would affect the config before the commit could be rolled > back to the old config and a suitable notification sent to the client. > After the commit, there is no roll-back.
Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
Hi Gert, On 21/12/2015 20:17, Gert Grammel wrote: Hi Rob, Seems we are pretty close with our understanding, so snipping the only discussion point left, with further comments: Gert The real problem is what you called in another email 'hybrid' or cheating-synchronous implementations. This leads to a situation where the client is made to believe the intended config is applied, but the server still didn't apply it yet. Take the case where the server runs into trouble after the synchronous-commit (which lets the client believe that the intended config is applied) and decides to roll-back. From a client perspective this would look like a node randomly losing its committed configuration. There is tons of code required on the client side to cope with that situation. So what was the purpose of implementing it that way in the first place - instead of just applying an asynchronous implementation? Yes, I agree that handling rollback could be a problem in this scenario, and hence I would propose that the behaviour in such a scenario is explicitly documented as being undefined in whatever solution is agreed upon :-) Gert> sadly, we can’t roll time back. So the best option is indeed to document the issue and move on to improve things Otherwise assuming that all requests are strictly synchronous or asynchronous then I think that we should be OK with the following two rules on the server: 1. All edit-config requests must strictly be processed in order. Gert> yes, although there are corner cases we need to hash out. I.e. a client may set a leaf to followed by setting it to . Then a server may skip setting it to , because it is anyhow overwritten by . Yes, it might, but from a correctness point of view it will need to able to fail the subsequent request to set the value to and hence set it to instead. 2) You cannot tell a client that a request has been full applied unless all previous requests specifying rollback-on-error semantics with any overlapping nodes with the current request have either be applied or aborted (i.e. rolled back) Gert> with “have bee full applied” you meant a state that I tentatively named ‘validated’ in my earlier email? I am a bit sensitive to naming here because of those ‘cheating synchronous nodes’ would return ‘applied’ without actually doing so in full. It would be great if we could quickly converge on some naming convention to remove ambiguity. Yes, it means the same state as your 'validated'. I basically just mean that the synchronous operation has completed (as per the definition of 'Synchronous Configuration Operation' defined in draft-ietf-netmod-opstate-reqs-01). The rule holds true but I don’t see a dependency on “rollback-on-error” semantics. In my view it is applicable also in cases of "continue-on-error” and “stop-on-error” in the sense that unless any error has been reported, the client still needs to wait for the ‘validated’ state before it can reliably assume the config was applied. I would see that a "continue-on-error" configuration operation is processed best effort. I.e. even if applying one of more config nodes failed to be applied, the rest of the configuration contained in a best effort operation would always be applied. As such subsequent operations would not need to wait for a best effort request to complete first before they can complete. Thanks, Rob From: Robert Wilton mailto:rwil...@cisco.com>> Date: Monday 21 December 2015 19:55 To: Gert Grammel mailto:ggram...@juniper.net>>, Jason Sterne <mailto:jason.ste...@alcatel-lucent.com>>, "netmod@ietf.org <mailto:netmod@ietf.org>" mailto:netmod@ietf.org>> Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error) Hi Gert, Please see inline ... On 05/11/2015 03:53, Gert Grammel wrote: Jason, A synchronous config basically contains two pieces of information in the commit: 1) the intended configuration is valid (i.e. is syntactically correct) and 2) the intended config has been applied Any error that would affect the config before the commit could be rolled back to the old config and a suitable notification sent to the client. After the commit, there is no roll-back. I agree. Similarly for asynchronous, however here the information needs to be split into two messages: 1) a commit that the intended config is valid 2) another message when the intended config is fully applied (let's call this 'validated'). A rollback can happen before the intended config is fully applied i.e. before the 'validated' state is reached. I agree. The real problem is what you called in another email 'hybrid' or cheating-synchronous implementations. This leads to a situation where the c
Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
Hi Rob, Seems we are pretty close with our understanding, so snipping the only discussion point left, with further comments: Gert The real problem is what you called in another email 'hybrid' or cheating-synchronous implementations. This leads to a situation where the client is made to believe the intended config is applied, but the server still didn't apply it yet. Take the case where the server runs into trouble after the synchronous-commit (which lets the client believe that the intended config is applied) and decides to roll-back. From a client perspective this would look like a node randomly losing its committed configuration. There is tons of code required on the client side to cope with that situation. So what was the purpose of implementing it that way in the first place - instead of just applying an asynchronous implementation? Yes, I agree that handling rollback could be a problem in this scenario, and hence I would propose that the behaviour in such a scenario is explicitly documented as being undefined in whatever solution is agreed upon :-) Gert> sadly, we can’t roll time back. So the best option is indeed to document the issue and move on to improve things Otherwise assuming that all requests are strictly synchronous or asynchronous then I think that we should be OK with the following two rules on the server: 1. All edit-config requests must strictly be processed in order. Gert> yes, although there are corner cases we need to hash out. I.e. a client may set a leaf to followed by setting it to . Then a server may skip setting it to , because it is anyhow overwritten by . 2) You cannot tell a client that a request has been full applied unless all previous requests specifying rollback-on-error semantics with any overlapping nodes with the current request have either be applied or aborted (i.e. rolled back) Gert> with “have bee full applied” you meant a state that I tentatively named ‘validated’ in my earlier email? I am a bit sensitive to naming here because of those ‘cheating synchronous nodes’ would return ‘applied’ without actually doing so in full. It would be great if we could quickly converge on some naming convention to remove ambiguity. The rule holds true but I don’t see a dependency on “rollback-on-error” semantics. In my view it is applicable also in cases of "continue-on-error” and “stop-on-error” in the sense that unless any error has been reported, the client still needs to wait for the ‘validated’ state before it can reliably assume the config was applied. From: Robert Wilton mailto:rwil...@cisco.com>> Date: Monday 21 December 2015 19:55 To: Gert Grammel mailto:ggram...@juniper.net>>, Jason Sterne mailto:jason.ste...@alcatel-lucent.com>>, "netmod@ietf.org<mailto:netmod@ietf.org>" mailto:netmod@ietf.org>> Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error) Hi Gert, Please see inline ... On 05/11/2015 03:53, Gert Grammel wrote: Jason, A synchronous config basically contains two pieces of information in the commit: 1) the intended configuration is valid (i.e. is syntactically correct) and 2) the intended config has been applied Any error that would affect the config before the commit could be rolled back to the old config and a suitable notification sent to the client. After the commit, there is no roll-back. I agree. Similarly for asynchronous, however here the information needs to be split into two messages: 1) a commit that the intended config is valid 2) another message when the intended config is fully applied (let's call this 'validated'). A rollback can happen before the intended config is fully applied i.e. before the 'validated' state is reached. I agree. The real problem is what you called in another email 'hybrid' or cheating-synchronous implementations. This leads to a situation where the client is made to believe the intended config is applied, but the server still didn't apply it yet. Take the case where the server runs into trouble after the synchronous-commit (which lets the client believe that the intended config is applied) and decides to roll-back. From a client perspective this would look like a node randomly losing its committed configuration. There is tons of code required on the client side to cope with that situation. So what was the purpose of implementing it that way in the first place - instead of just applying an asynchronous implementation? Yes, I agree that handling rollback could be a problem in this scenario, and hence I would propose that the behaviour in such a scenario is explicitly documented as being undefined in whatever solution is agreed upon :-) Otherwise assuming that all requests are strictly synchronous or asynchronous then I think that we should be OK with the following two rules on the server: 1) All edit-config requests mus
Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
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 is . 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 () (B) candidate DS > running (intended) () (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
Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
Hi Gert, Please see inline ... On 05/11/2015 03:53, Gert Grammel wrote: Jason, A synchronous config basically contains two pieces of information in the commit: 1) the intended configuration is valid (i.e. is syntactically correct) and 2) the intended config has been applied Any error that would affect the config before the commit could be rolled back to the old config and a suitable notification sent to the client. After the commit, there is no roll-back. I agree. Similarly for asynchronous, however here the information needs to be split into two messages: 1) a commit that the intended config is valid 2) another message when the intended config is fully applied (let's call this 'validated'). A rollback can happen before the intended config is fully applied i.e. before the 'validated' state is reached. I agree. The real problem is what you called in another email 'hybrid' or cheating-synchronous implementations. This leads to a situation where the client is made to believe the intended config is applied, but the server still didn't apply it yet. Take the case where the server runs into trouble after the synchronous-commit (which lets the client believe that the intended config is applied) and decides to roll-back. From a client perspective this would look like a node randomly losing its committed configuration. There is tons of code required on the client side to cope with that situation. So what was the purpose of implementing it that way in the first place - instead of just applying an asynchronous implementation? Yes, I agree that handling rollback could be a problem in this scenario, and hence I would propose that the behaviour in such a scenario is explicitly documented as being undefined in whatever solution is agreed upon :-) Otherwise assuming that all requests are strictly synchronous or asynchronous then I think that we should be OK with the following two rules on the server: 1) All edit-config requests must strictly be processed in order. 2) You cannot tell a client that a request has been full applied unless all previous requests specifying rollback-on-error semantics with any overlapping nodes with the current request have either be applied or aborted (i.e. rolled back) Thanks, Rob Gert -Original Message- From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Sterne, Jason (Jason) Sent: 03 November 2015 08:24 To: netmod@ietf.org Subject: [netmod] netmod-opstate-reqs and error option terms (rollback on error) 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 is . 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 () (B) candidate DS > running (intended) () (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
Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
Jason, A synchronous config basically contains two pieces of information in the commit: 1) the intended configuration is valid (i.e. is syntactically correct) and 2) the intended config has been applied Any error that would affect the config before the commit could be rolled back to the old config and a suitable notification sent to the client. After the commit, there is no roll-back. Similarly for asynchronous, however here the information needs to be split into two messages: 1) a commit that the intended config is valid 2) another message when the intended config is fully applied (let's call this 'validated'). A rollback can happen before the intended config is fully applied i.e. before the 'validated' state is reached. The real problem is what you called in another email 'hybrid' or cheating-synchronous implementations. This leads to a situation where the client is made to believe the intended config is applied, but the server still didn't apply it yet. Take the case where the server runs into trouble after the synchronous-commit (which lets the client believe that the intended config is applied) and decides to roll-back. From a client perspective this would look like a node randomly losing its committed configuration. There is tons of code required on the client side to cope with that situation. So what was the purpose of implementing it that way in the first place - instead of just applying an asynchronous implementation? Gert -Original Message- From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Sterne, Jason (Jason) Sent: 03 November 2015 08:24 To: netmod@ietf.org Subject: [netmod] netmod-opstate-reqs and error option terms (rollback on error) 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 is . 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 () (B) candidate DS > running (intended) () (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] netmod-opstate-reqs and error option terms (rollback on error)
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 is . 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 () (B) candidate DS > running (intended) () (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
