These terms were edited on today's call, resulting in the following text:
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 MUST fully attempt to
apply
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. This may be transactional or non-
transactional (need terms!). The transactionality of the operation
may be a server property or specified on as a property.
The reply to the client indicates whether there
are any errors in the request or errors from applying the
configuration
change.
Asynchronous configuration operation - A configuration request to
update
the running configuration of a server that is applied asynchronously
with respect to the client request. The server MUST update its
intended
configuration (see term) before replying to the client indicating
whether the request will be processed. This reply to the client only
indicates whether there are any errors in the original request. The
server's applied configuration state (see term) is updated after the
configuration change has been fully effected to all impacted
components
in the server. Once applied, there MUST be a mechanism for the
client to
determine when the request has completed processing and whether the
intended config is now fully effective or there are any errors from
applying the configuration change, which could be from an asynchronous
notification or via a client operation.
Synchronous configuration server - a configuration server that
processes
all configuration operations as synchronous configuration operations.
Asynchronous configuration server - a configuration server that
processes
all configuration operations as asynchronous configuration operations.
We have consensus on the above, but are hoping for some word-smithing
before committing it to the draft. Anybody want to take a crack at it?
BTW, do we still need to define the last two terms anymore? - they're
not used elsewhere in the draft...
Kent
From: Gert Grammel <ggram...@juniper.net <mailto:ggram...@juniper.net>>
Date: Thursday, October 15, 2015 at 10:35 AM
To: Robert Wilton <rwil...@cisco.com <mailto:rwil...@cisco.com>>, Kent
Watsen <kwat...@juniper.net <mailto:kwat...@juniper.net>>,
"netmod@ietf.org <mailto:netmod@ietf.org>" <netmod@ietf.org
<mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous
vs asynchronous (esp. wrt intended and applied)
Rob,
From a client perspective a server has three states:
1. intended != applied
2. Funny-state
3. Intended == applied
Irrespective of synchronous or asynchronous processing in the server,
the third state MUST be reported to the client. Else (from a client
perspective) the server stays in funny-state forever.
Gert
From: Robert Wilton <rwil...@cisco.com <mailto:rwil...@cisco.com>>
Date: Thursday 15 October 2015 15:59
To: Gert Grammel <ggram...@juniper.net <mailto:ggram...@juniper.net>>,
Kent Watsen <kwat...@juniper.net <mailto:kwat...@juniper.net>>,
"netmod@ietf.org <mailto:netmod@ietf.org>" <netmod@ietf.org
<mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous
vs asynchronous (esp. wrt intended and applied)
Hi Gert, Kent,
I think that notifying the client is one possible way that an
asynchronous request could be completed, but not necessarily the only
way. E.g. if the information as to whether a particular intended
leave had been successfully applied was available (e.g. as per github
issue #2).
So, I wonder whether we shouldn't weaken the last sentence, changing
MUST to COULD, or perhaps reword it.:
E.g. replacing:
Once applied, the client MUST be notified whether the intended config
is now fully effective or there are any errors from applying the
configuration change.
Perhaps with:
Once applied, the client COULD be notified whether the intended config
is now fully effective or there are any errors from applying the
configuration change.
Or:
Once applied, there MUST be a mechanism available for the client to be
able to determine whether the intended config is now fully effective
or whether there are any errors from applying the configuration change.
Thanks,
Rob
On 15/10/2015 12:17, Gert Grammel wrote:
Kent, Rob,
Comparing the cases, the definition of the asynchronous case doesn’t
look complete. The way it stands for the synchronous operation, the
client knows that it's intended config was good AND it has been
effected to the server. In the Asynchronous case, the client only
knows that the intended config was good – and that’s not enough.
So the proposal is to refine the asynchronous case definition as follows:
Asynchronous configuration operation - A configuration request to
update the running configuration of a server that is applied
asynchronously with respect to the client request. The server MUST
update its intended configuration (see term) before replying to the
client indicating whether the request will be processed. The reply
to the client only indicates whether there are any errors in the
original request.
The server's applied configuration state (see term) is updated after
the configuration change has been applied to all impacted components
in the server. Once applied, the client MUST be notified whether the
intended config is now fully effective or there are any errors from
applying the configuration change.
In addition I would suggest to require a verify operation which a
client can request from the server to obtain above information on an
on-demand basis. Would that somehow go in the opstate-reqs #3 then?
Best
Gert
From: netmod <netmod-boun...@ietf.org> on behalf of Kent Watsen
<kwat...@juniper.net <mailto:kwat...@juniper.net>>
Date: Thursday 15 October 2015 00:11
To: Robert Wilton <rwil...@cisco.com>, "netmod@ietf.org
<mailto:netmod@ietf.org>" <netmod@ietf.org <mailto:netmod@ietf.org>>
Subject: Re: [netmod] opstate-reqs #6: clarify impact of synchronous
vs asynchronous (esp. wrt intended and applied)
Hi Robert,
One comment, it seems that the asynchronous configuration operation
should
have one more sentence at its end saying that an asynchronous
notification
must be used to report any errors produced from when applying the
configuration.
What do you think?
Kent // as a contributor
On 10/14/15, 10:59 AM, "Robert Wilton" <rwil...@cisco.com> wrote:
Hi All,
Are there any more comments on the following proposed
descriptions, or
are these descriptions sufficiently clear to update the requirements
draft and resolve issue #6?
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 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.
Asynchronous configuration operation - A configuration request to
update
the running configuration of a server that is applied asynchronously
with respect to the client request. The server MUST update its
intended
configuration (see term) before replying to the client indicating
whether the request will be processed. The server's applied
configuration state (see term) is updated after the configuration
change
has been fully effected to all impacted components in the
server. The
reply to the client only indicates whether there are any errors
in the
original request.
Synchronous configuration server - a configuration server that
processes
all configuration operations as synchronous configuration operations.
Asynchronous configuration server - a configuration server that
processes
all configuration operations as asynchronous configuration
operations.
Thanks,
Rob
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.
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
_______________________________________________
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
