Hi,
On 13/10/2015 09:48, Juergen Schoenwaelder wrote:
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.
I think that the question regarding synchronous vs asynchronous is
really about what a client can usefully do with that information.
If a client knows that a request is synchronous then it doesn't have to
poll or check whether the configuration has been applied. Unless it
gets told in the reply that some configuration failed, it should be able
to assume that all the configuration has been successfully applied and
it can proceed to the next step (if any) in provisioning a service.
If a client knows that a request is asynchronous then it has to poll (or
rely on a notification) to determine when the configuration has been
applied. If, when it polls, parts of the config are applied and parts
of it are not then it might be able to continue with some provisioning
tasks but have to wait before it can continue with other parts of the
provisioning.
If a server is a hybrid (where I define a hybrid server as one that
replies somewhere between when a sync or async server would), then I
would expect that a client would end up treating this the same as an
asynchronous server. I.e. it would expect to query to find out which
parts of the configuration are applied and which are not.
But I agree that existing NC servers are potentially neither exactly
synchronous or asynchronous in their behaviour and hence my trying to
labelling them as such may be a mistake. Hence, perhaps it would be
better to classify servers as one of sync, async, hybrid?
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.
Yes, I understand your concern about having something implementable, but
equally I think that the operators want a definition that is strong
enough that they can usefully use it. I also think that it is better to
have a reasonably tight definition so that the implementers know what
they should be aiming for, even if it isn't 100% achievable in all
scenarios.
If we provide a definition of a hybrid server (i.e. somewhere between
sync and async) then we could still have a tight definition of applied
config, but aren't forcing any change in semantics to existing NC/RC
servers since we just define their behaviour as being somewhere between
an async and sync response.
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.
Inferring the applied config state from the operation state is one way
of doing this.
An alternative way is for the NC/RC server to maintain separate internal
state for intended vs applied cfg nodes. Then the NC/RC server would
update the applied cfg node when the internal IPC to program that
configuration had completed for all affected subsystems.
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.
Agreed.
Rob
/js
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
