HI Andy, On 22/12/2015 20:37, Andy Bierman wrote:
On Tue, Dec 22, 2015 at 12:31 PM, Robert Wilton <robert.pub...@wilton.org.uk <mailto:robert.pub...@wilton.org.uk>> 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 <snip> 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 <x> followed by setting it to<y>. Then a server may skip setting it to <x>, because it is anyhow overwritten by <y>.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 <y> and hence set it to <x> instead. What does "processed in order" mean? NETCONF has a requirement that <rpc> requests on a specific session are processed in the order received. There is no such requirement across multiple sessions doing edits at once.
Thanks for the clarification. I hope that whatever NETCONF does here should be a sufficient solution. I.e. as long as the error handling semantics can be well defined with the request ordering just defined relative to particular sessions then that is fine with me. I think that it would only be necessary to refine/modify the NETCONF behaviour if it is shown to be insufficiently specified to be robustly implementable, and I'm not aware of that being the case.
Otherwise, I think that this discussion can probably be deferred until we are discussing the specific solution draft.
As an aside - I also see this as another example where it would be useful to define the common semantics and expectations of a YANG manageability protocol outside of NETCONF and RESTCONF.
Thanks, Rob
Andy2) 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<snip> From: Robert Wilton <rwil...@cisco.com <mailto:rwil...@cisco.com>> Date: Monday 21 December 2015 19:55 To: Gert Grammel <ggram...@juniper.net <mailto:ggram...@juniper.net>>, Jason Sterne <jason.ste...@alcatel-lucent.com <mailto:jason.ste...@alcatel-lucent.com>>, "netmod@ietf.org <mailto:netmod@ietf.org>" <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 <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 <mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org <mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod . _______________________________________________ netmod mailing list netmod@ietf.org <mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod_______________________________________________ netmod mailing list netmod@ietf.org <mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
