Hi all, There is some discussion below about the difference between perfectly async (reply to the <commit> as soon as possible) vs hybrid.
Isn't there some value in being hybrid if the additional delay to reply is reasonably bounded (i.e. less than a few seconds 95% of the time) while adding some valuable additional checks (e.g. resource checking or other prelim checking in the application layer) ? It is easier for a client to deal with a request failure via an error response than to find out later that something failed (and that failure indication may not always be easy to correlate with a specific request or workflow in the client). Being hybrid means that more error cases are indicated via a response rather than communicated using an asynchronous notification later. Of course no system is going to be perfectly synchronous so clients do have to be able to deal with async failure notifications after-the-fact. Jason From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Gert Grammel Sent: Monday, October 19, 2015 9:15 To: Robert Wilton Cc: netmod@ietf.org<mailto:netmod@ietf.org> Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update? Hi Rob, From: Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>> Date: Monday 19 October 2015 14:25 To: Gert Grammel <ggram...@juniper.net<mailto:ggram...@juniper.net>> Cc: Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>, Martin Bjorklund <m...@tail-f.com<mailto:m...@tail-f.com>>, "netmod@ietf.org<mailto:netmod@ietf.org>" <netmod@ietf.org<mailto:netmod@ietf.org>> Subject: Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update? Hi Gert, On 19/10/2015 09:06, Gert Grammel wrote: Rob, I think we are describing the same problem from a little different perspective: Perhaps, but I'm not sure that we are on the same page yet. Didn't claim that we'd be on the same page, but at least we appear to look at the same problem. Sent from my Apple ][ On 16 Oct 2015, at 20:50, Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote: Hi Gert, On 16/10/2015 18:14, Gert Grammel wrote: Rob, Current implementations are incomplete asynchronous, because they didn't verify the config as operational and applied. What is frequently done is to perform additional checks on the intended config that go beyond a syntax check. That is fine, but I have a hard time to consider this to be "hybrid" which suggests something in between asynchronous and synchronous. I'm talking about netconf servers that effectively apply most of their configuration before they reply. E.g. they might take 10 minutes to reply. Exactly, that's why those servers are running asynchronously. The trouble is that in contrast to the synchronous operation there is no "done" information. Current implementations often try to work around that point by applying more than just a syntax check in the first phase. This way they are still quick in replying are more reliably responding, but still fail from time to time I don't follow why you think that these servers are running asynchronously. They are much closer to handling all config operations as synchronous blocking calls. This is a just a small amount of programming that is being performed asynchronously. If a configuration would only take some second or so, everyone would probably be happy to apply synchronous config. Asynchronous config come in, when the server would need a long time to apply the config or if the time is unpredictable. So when we talk about a config that needs 10 min to be applied, I would consider a synchronous configuration the wrong design choice to start with. A server should reply shortly after receiving the intended config to indicate that they are accepting the config and after e.g. 9:59 minutes come back with an information that the config has successfully been applied. If you mix both information into one you either create a black hole in the beginning of the process (request an intended config and getting feedback 10min after) or you end up with a grey hole in the end where you know the server is working on it but have no idea when it has finished, so that you can reasonably expect an operational state in line with your config. Perhaps this isn't a valid Netconf implementation, and all Netconf server implementations are expected to be asynchronous w.r.t to when they apply their configuration - but I can't see where this is stated in the NETCONF RFC (but possibly I'm not looking in the right place). >From a client perspective an asynchronous server and a hybrid server look the >same. The difference is that the asynchronous one should convey a "finished" >information to the client, while the hybrid would remain in a "trust me babe" >mode forever. Yes, but this isn't the only difference: - a client could expect that an asynchronous config operation response should be reasonably expedient. Agree, but this is true for hybrid and asynchronous and the term "reasonable" is not well defined. This is true for asynchronous but not hybrid, since a hybrid operation might return just before a proper synchronous operation would. What is the level of information the client has before and after this 'return'? Before the return, it doesn't know if the config is being processed, and after the return it doesn't know if it has been applied. Just like asynchronous. E.g. if a client was to update 10 devices each with a reasonable size configuration (that takes minutes to apply) in an asynchronous way then it might reasonably consider sequencing the async config requests to each server on one thread. If each server acknowledged the requests in a couple of seconds then all the servers would broadly end up applying the configuration concurrently. Yes, that's why we need asynchronous mode in the first place. - however, if the servers were hybrid, and their replies were sent much closer to when the configuration was actually applied then initiating the requests sequentially would effectively mean that the devices end up applying the configuration serially which would end up taking much longer. I.e. it seems reasonable that a client may want to differentiate between the behaviour of these two servers even if how it handles the resultant config changes is the same. It seems your definition of hybrid is something like "asynchronous but with a longer than reasonable response time". My definition of hybrid (i.e. the default existing netconf config operations) is along the lines of "asynchronous in behaviour, but may reply any time between when the intended configuration has been updated and the applied configuration has been completely updated ". Understand, but the information available to the client is just the same as for asynchronous: before responding, the client doesn't know if the config is being processed, and after the response it doesn't know if it has been applied. The only difference is that in a proper asynchronous implementation the time between a config request and response is short, while the time between response and applied config is long. Hybrid tends to move the response time out. I don't see how in principle it is different from asynchronous. This is similar to a bloated synchronous operation which takes too much time to respond. Both cases are undesired and in both cases the solution is to make them truly asynchronous. So that we can have a reasonable response time. I agree with the goal, but it may be difficult to change some existing NETCONF operational handling to be either strictly sync or async. Please help me to understand what you mean with "strictly sync or async". And in particular why a hybrid (according to your definition) is not asynch. Another way to look at hybrids is to consider them "cheating synchronous". Given that the new config may not have been applied at the time of the response to the client. This is worse than the situation before where a missing verify lets the client know that something may still go on. Clients can't tell if servers are cheating :-) Yes, but clients also need to be able to determine if the server is likely to be slow to response, because then the client would probably be designed to interact with the server in a different fashion (e.g. use a pool of threads to initiate the updates concurrently). How would you do this in practice? Roughly, I would suggest: Assuming that this is going to be a new optional to implement extension: - There would be a capability to indicate whether a server supports an explicit sync config operation. - There would be a capability to indicate whether a server supports an explicit async config operation. - It would be implicitly assumed that the server would support the existing default config operation. In Netconf/Restconf when an edit-config request is made, an extension would include an option to indicate whether the request should be processed as sync, async, or default (i.e. existing behaviour). How would that help the client to figure out how slow the response is likely to be? The fact that a request is synch, asynch or hybrid wouldn't tell him how fast it is. Thanks Gert Thanks, Rob Even servers don't know if they're likely to slow a response when they get a request. That's why a quick first response is required that assures the client the requests will be processed, followed by a potentially slow feedback that it is successfully executed (=verified) or failed. Thanks, Rob Gert Sent from my Apple ][ On 16 Oct 2015, at 18:44, Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote: On 16/10/2015 14:59, Kent Watsen wrote: 3. Support for both synchronous and asynchronous configuration operations A. A server may choose to support only synchronous configuration operations, or only asynchronous configuration operations, or both synchronous and asynchronous configuration operations in a client specified per-operation basis. I think the most common mode *today* is a mix of sync/async, on a per-object basis. Yes, I agree. Wait, I think we're talking about different things. Martin, I'm sure that internal to a NC/RC server, parts of the intended configuration is actually applied synchronously (e.g., a hostname) whereas other parts are not (e.g., config for data plane). But that nuance is not currently exposed in any way today -right? I think that today, from what a client sees/experiences, many replies from netconf servers fits neither the definition of "synchronous configuration operation" nor "asynchronous configuration operation", but instead, the reply is somewhere between the two extremes. So the question I was trying to raise is whether servers that need to meet the opstate requirements have to change to strictly comply with the defined async or sync config operation semantics? E.g. not just adding a "done-applying" option, but perhaps also adding something along the lines of a "done-verifying" option. Thanks, Rob What we're talking about here is an ability for a client to request a protocol operation (PATCH) to block, or for the "done-applying" notification to not be sent, until all that processing of the request is complete. This regardless if the request contains a mix of nodes that are applied internally sync/async. Makes sense? - or it is something else? B. Support for synchronous operations as per the definition of "synchronous configuration operation". Doesn't this follow from A? Yes, possibly. I don't mind if B is deleted. If we do this then I would suggest that we also delete the analogous first sentence of C, and re-introduce the "(see terms)" text in the headline description. +1 Kent // as a contributor . _______________________________________________ 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
