On Tue, Oct 06, 2015 at 09:42:37PM +0100, Robert Wilton wrote: > Hi Juergen, > > On 06/10/2015 17:16, Juergen Schoenwaelder wrote: > >On Tue, Oct 06, 2015 at 02:59:29PM +0100, Robert Wilton wrote: > >>Hi Kent, > >> > >>Feeding in the various input, I think that this is the best refinement > >>that I've come up with: > >> > >>Synchronous configuration operation - A configuration request to update > >>the running configuration of a server that is applied synchronously with > >>respect to the client request. The server SHOULD ensure that the > >>request is valid, and MUST fully effect the configuration change to all > >>impacted components in the server, updating both the server's intended > >>and applied configuration (see terms), before replying to the client. > >>The reply to the client indicates whether there are any errors in the > >>request or errors from applying the configuration change. > >What does "SHOULD ensure that the request is valid" mean? RFC 6020 > >says: > > > > When datastore processing is complete, the final contents MUST obey > > all validation constraints. This validation processing is performed > > at differing times according to the datastore. If the datastore is > > <running/> or <startup/>, these constraints MUST be enforced at the > > end of the <edit-config> or <copy-config> operation. If the > > datastore is <candidate/>, the constraint enforcement is delayed > > until a <commit> or <validate> operation. > > > >Are we talking about datastore validation or validation of a request? > >If the former, are we watering down a MUST to a SHOULD? > Really it is datastore validation, particularly for an async request > where the intended config nodes are updated before replying. I'm not > intentionally trying to water down a MUST to a SHOULD, but Kent had > concerns that my previous description using "semantically validate" > would exclude an ephemeral datastore, so I was trying to water down the > description and also describe the behaviour in a way that isn't specific > to either RESTCONF/NETCONF or datastores. > > Perhaps, the start of sentence could simply be changed to: > > The server MUST fully effect the configuration change to all > impacted components in the server ... > > And equivalently for the asynchronous case below: > > The server MUST update the server's intended configuration ... >
Works for me. Sometimes less is more. > >And I would not be surprised if we also need this sooner or later: > > > > Mixed configuration server - a configuration server that processes > > some configuration operations as synchronous configuration > > operations and some configuration operations as asynchronous > > configuration operations. > Yes, I would expect that clients may want to define the expected > behaviour, potentially on a per request basis. I doubt that servers will offer clients to choose; I am more with Andy that in real systems, depending on the data model, certain parts of a data model may be synchronous while others may be asynchronous. > >>Any further comments? > >> > >>Based on the feedback from Andy and others, it seems that the prevailing > >>view is that existing NETCONF and RESTCONF should be regarded as being > >>asynchronous in their behaviour in that the config nodes in the running > >>datastore only represent the intended configuration and not the applied > >>configuration. > >Depends on the definition of applied configuration - where is the latest > >version of it? > The last proposed text for intended/applied is as below: > > intended configuration - this data represents the configuration > state that the network operator intends the system to be in, and > that > has been accepted by the system as valid configuration. This > data is > colloquially referred to as the 'configuration' of the system. > > applied configuration - this data represents the configuration > state that the network element is actually in, i.e., the > configuration state which is currently being being used by system > components (e.g., control plane daemons, operating system > kernels, line cards). Well, sometimes the config goes to a control plane daemon and then to the OS kernel and finally to the line cards. This definition leaves some room what an applied configuration is (which is IMHO needed if you want to have something implementable) and hence a NC server can either be considered synchronous or asynchronous. > From Thursday's interim meeting, Rob Shakir clarified that the desired > intention is that applied configuration should mean that the > configuration is fully applied everywhere. I don't know if that means > that the definition of applied configuration should be strengthened, or > if it is sufficient? As said before, an OS kernel usually does not track where resource parameters were coming from. (An interface has a set of IP addresses and the kernel usually does not know which addresses were coming from a configuration daemon, a dhcp daemon, a tunneling daemon, a command line utility, ...) The same may be true for line card. So in order to implement a very tight definition, one has to either 'guess' which 'subset' of operational state can be related 'somehow' to the intended config and then report the result of the guess work as applied config or one would have to to change daemons/kernels/linecards to have a tracking number or something like that. Anyway, as long as a regular NC/RC server does not have to pay a price for this applied config idea, I have no real problem with this since I am sure the market will sort this out. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
