On Mon, Sep 28, 2015 at 10:10 AM, Robert Wilton <rwil...@cisco.com> wrote:
> Hi Andy, > > > On 24/09/2015 19:22, Andy Bierman wrote: > > Hi, > > I find this exercise to classify servers as synchronous or asynchronous > mostly useless. > We have both types of instrumentation in our server. They can be different > on a per-node basis. They can both take a long time or both be instant, > depending > on the instrumentation code the vendor writes. > > In any case, the server does not know if the instrumentation has finished > making > the network behave according to the new edit. That would be new > functionality that > no vendor supports at this time. Currently servers return "ok" if the > edit is accepted > into the running datastore. There are no other semantics wrt/ returning > "ok". > > > I'm not sure whether we agree here, but as stated previously, Sec 5.1 of > RFC 6241, implies that if the configuration is in the running datastore > then that configuration is expected to be active on the device. > > I do not agree at all that the running datastore means anything other than the intended confg. A new operation is needed to retrieve the active config vs. the intended config. Andy Certainly I think that some Cisco's devices behave in the spirit of this > description. E.g. for a normal configuration commit (via the CLI, but I > would expect NETCONF to be the same) a configuration commit event would not > complete unless the configuration was applied and broadly in effect in the > system. However, even after the config commit, there may be some > components that are still processing parts of the config change (e.g. ARP > subsystem after an IP address change on an interface), and some hardware > tables may also still be in the process of being programmed. > > I think that is just comes down to the definition of what "that > configuration is expected to be active on the device" means, and how that > relates to the definition of "applied configuration". > > I've been trying to define "applied configuration" to be the same as > "configuration is expected to be active on the device". I.e. it is in the > config system but isn't necessarily applied everywhere. This description > appears to be consistent with sec 4.2. para 1 of > openconfig-netmod-opstate-01 but inconsistent with how "applied > configuration" is defined in Sec 2 of openconfig-netmod-opstate-01. > > The alternative definition of "applied configuration" that is being put > forward is something along the lines of "programmed absolutely everywhere > where it needs to be". But this definition is in conflict with the > behaviour described in sec 4.2. para 1 of openconfig-netmod-opstate-01, > where after a NETCONF commit it is expected that applied=intended. > Further, under this definition most NETCONF/RESTCONF servers would likely > be defined as asynchronous (at least for some leaves), and not many (if > any) servers currently have the capability to report "applied > configuration" as per this definition. > > > > Even something as simple as "set the log-level" could be centralized or > distributed. > So every single leaf is a separate case and every single implementation of > every leaf > is a separate case. It is completely implementation-dependent. One > platform may > take a long time and another from the same vendor may not, for the exact > same leaf. > > So instead of talking about the entire server being sync or async, we need > to > talk about a specific implementation of a specific leaf, and not try to > generalize > and simplify the problem. > > > But from a client perspective, I'm not quite sure whether they would want > to optimise for this case. E.g. if some of the configuration has been > applied immediately and some will be handled asynchronously then I would > imagine that a client might just treat that equivalently to it all being > handled asynchronously, and hence poll for the applied config leaves. > > Hence your suggestion feels like an optimization to me, a nice to have, > but I don't currently see that it is required. > > In summary, I think that the two main issues that need to be resolved > w.r.t to the requirements, which are: > (1) What does applied-config actually mean? > > (2) What does it mean when an existing NETCONF/RESTCONF commit completes > (which I see as depending on the definition of applied-config)? > > I expect that the rest of the requirements would probably logically follow > on from these. It would seem to be beneficial if we could get these nailed > down before the next meeting on Thursday if at all possible. > > Rob > > > > > Andy > > > > > > > > On Thu, Sep 24, 2015 at 6:25 AM, Robert Wilton <rwil...@cisco.com> wrote: > >> Hi Kent, >> >> On 23/09/2015 17:15, Kent Watsen wrote: >> >> >> Jonathan Hansford writes: The requirements talk about both synchronous >> and asynchronous systems (1(D), 3, 3(A)) but really only address the >> behaviour for asynchronous systems. Would it not be worth clarifying the >> relationship between the intended and applied configurations for >> synchronous systems (i.e. they are the same), hence there is no need for >> synchronous requirements equivalent to 1(D) and 3(A)? >> >> Ultimately, I think we need normative text in the "Terminology Section" >> for a "synchronous system" and "asynchronous system". Would someone care >> to take a stab providing these two definitions? >> >> >> First stab only, probably needs some tweaking ... >> >> I find that the term "system" is a bit ambiguous in this context. It is >> talking about the NMS, the server, or both together? >> >> Anyway, I've tried to define them relative to the configuration >> operations being performed. >> >> Synchronous configuration operation - A configuration request that the >> server applies synchronously with respect to the client request. Before >> the server replies back to the client indicating the success or failure of >> the operation it MUST semantically validate the contents of the request and >> update the intended configuration of the target datastore. If the request >> is to the running datastore then the configuration change MUST also be >> applied in the system before the server replies back to the client. The >> reply to the client indicates whether there are any semantic errors or >> system errors from applying the configuration change. >> >> Asynchronous configuration operation - A configuration request that the >> server applies asynchronously with respect to the client request. Before >> the server replies back to the client indicating the success or failure of >> the operation it MUST semantically validate the contents of the request and >> update the intended configuration of the target datastore. If the request >> is to the running datastore then the configuration change is applied to the >> system after the server has replied back to the client. The reply to the >> client only indicates whether there are any semantic errors in the >> configuration change. >> >> Synchronous system - NETCONF/RESTCONF client/server interactions that >> processes all configuration operations as synchronous configuration >> operations. >> >> Asynchronous system - NETCONF/RESTCONF client/server interactions that >> processes all configuration operations as asynchronous configuration >> operations. >> >> Thanks, >> Rob >> >> >> >> >> PS: please Reply-All to this thread, rather than post comments on the GitHub >> issue tracker. >> >> Thanks, >> Kent >> >> >> >> _______________________________________________ >> netmod mailing >> listnetmod@ietf.orghttps://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
