On 22/09/2015 19:04, Andy Bierman wrote:
On Tue, Sep 22, 2015 at 10:00 AM, Juergen Schoenwaelder
<j.schoenwael...@jacobs-university.de
<mailto:j.schoenwael...@jacobs-university.de>> wrote:
On Tue, Sep 22, 2015 at 09:20:18AM -0700, Andy Bierman wrote:
>
> NETCONF and RESTCONF are asynchronous, meaning the client and server
> run in separate processes and communication between client and
server can
> occur at any time.
>
I thought the openconfig discussion was centered around the server
side...
> If the server returns <ok/> to an edit request, that means it is
accepted in
> the intended config.
I think we need to use precise terminology otherwise we keep talking
past each other. An <ok/> to an <edit-config> means the edit got
'accepted' (not sure what this term means) in the configuration
datastore being edited, such as <running/> or <candidate/>.
OK -- the edit is accepted as part of the <running> datastore.
That means is passes the YANG validation tests.
I guess our terminology is so poor that we cannot even describe that
means wrt/ the device or the network.
Perhaps <running/> === intended configuration datastore. But I think
it is important to not forget that there are multiple configuration
datastores in NETCONF.
My understanding is that the <edit-config/> operation is synchronous
with respect to the change of the configuration datastore. The
propagation of the data from the <running/> configuration datastore to
the internal pieces of hardware and software being configured may be
asynchronous and is usually considered an implementation detail. The
protocol itself allows asynchronous clients to be written that can
talk to multiple servers and in principle the protocol supports
pipelining of requests from a single client to a single server but all
requests are executed serially. I think the same applies to RESTCONF
but I am a bit less confident.
I agree with Carl that there is no problem to solve wrt/ "show running"
being delayed. I think implementations just return the intended values.
This doesn't seem to be consistent with the rfc6241 section 5.1 that states:
"The running configuration datastore holds the complete configuration
currently active on the network device."
Also, section 4.2 of openconfig-netmod-opstate states:
"In a synchronous system, configuration changes are transactional and
committed as an atomic unit. This implies that the management system
knows the success or failure of the configuration change based on the
return value, and hence knows that the intended configuration matches
what is on the system (i..e, what has been applied). In particular,
the value of any configuration variable should always reflect the
(intended) configured value. Synchronous operation is generally
associated with a NETCONF-based system that provides transactional
semantics for all changes."
Taken together, to me, this implies that the definition of "applied
configuration" is such that after a successful regular (i.e.
"synchronous") NETCONF edit-config request then the values that the
running datastore holds is both the intended configuration and applied
configuration. I.e. they are the same.
Of course, I agree that this doesn't guarantee that a particular item of
configuration has been fully programmed everywhere on the system, but
that is what the derived state indirectly tells gives you.
It is only "asynchronous" servers that return early from an edit-config
request for which the intended config can ever differ from the applied
config. Further, assuming that there are no errors when applying the
configuration, then at the point in time that a server would have
logically completed a normal "synchronous" config request, the value of
the "applied configuration" leaves would be identical to the "intended
configuration" leaves.
Rob
/js
Andy
--
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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
