ietf
[Top] [All Lists]

RE: Gen-art LC review: draft-mm-netconf-time-capability-05

2015-08-06 00:47:25
Hi Andy,

We appreciate the detailed review.

The draft adds the invoke-at-time capability to a small set
of NETCONF operations (via augment-stmt).
The mechanism cannot be used for any other operations.
It appears this is the entire list of operations supported:

  - get-config
  - get
  - copy-config
  - edit-config
  - delete-config
  - lock
  - unlock
  - close-session
  - kill-session
  - commit

Why was this subset of all operations selected?

This list contains most of the RPCs defined in RFC6241, with the exception of 
three RPCs: cancel-commit, validate, and discard-changes. It did not make sense 
to us to support the <scheduled-time> element for these RPCs.
The intended status of this document is experimental. For experimental 
purposes, it appears that this list of RPCs is sufficient. However, if you feel 
that there is an RPC that needs to be added to the list please let us know.


I cannot find any text in the draft that says what happens
if the client session terminates for any reason.  

(*) Agreed. We will add text that says that when a session terminates, the 
server cancels all scheduled RPCs that were received in that session.

There are
commands that support the 'execution-time' parameter
like <lock> that explicitly require a session to be maintained.
Not sure a delayed <close-session> even makes sense.

Agreed. We will remove the <close-session> RPC from the YANG module.

If the session is gone when the scheduled operation is about
to be executed, does the server cancel it or attempt it?
Without a session, the server cannot send an <rpc-reply>,
so it should not attempt the command.

Agreed. See the response to (*) above.

What if commands are scheduled at the same time?
Is the server expected to serialize these commands or
invoke them in parallel?  Note that operations within
a single session MUST be invoked in order, but this only
seems to apply to the original <rpc> to schedule the delayed
operation.

Good point. Scheduled RPCs should be processed serially, as is currently 
defined in RFC 6241. If two or more scheduled RPCs have the same 
<scheduled-time> the server can process them in an arbitrary order.
We will add text that clarifies this in the draft.


I think this draft is severely constrained by RFC 6241, sec. 4.5.

4.5.  Pipelining

  NETCONF <rpc> requests MUST be processed serially by the managed
  device.  Additional <rpc> requests MAY be sent before previous ones
  have been completed.  The managed device MUST send responses only in
  the order the requests were received.

Yes, the PURPOSE of the :time capability is to allow RPCs to be executed 
according to their scheduled time, and not according to their reception order. 
I suggest that we add some text that clarifies that replies to scheduled RPCs 
are sent in the order of their schedule, while replies of unscheduled RPCs (as 
defined in RFC 6241) are sent by the reception order of the corresponding RPCs.

There are no existing NETCONF servers that will start processing rpc(N+1)
while rpc(N) is in progress for a session.  It might violate the MUST
in sec. 4.5.

Indeed, that is the behavior of *existing* servers, but this does not impose an 
interoperability problem with the :time capability. As all capability-based 
extension, interoperability with *existing* servers is guaranteed by the 
capability exchange: a server that does not support the :time capability will 
continue to send RPC replies according to their arrival order. A server that 
supports the :time capability will perform (and reply to) scheduled RPCs 
according to their schedule, and unscheduled RPCs according to their reception 
order.  

The :time capability must be:
1. Interoperable with existing servers by means of the capability exchange (we 
believe this is currently satisfied).
2. Well defined.
To guarantee (2), I suggest that in the capability definition (section 4) we 
will clarify how the :time capability affects the order of RPC replies of 
scheduled RPCs.

A different NETCONF session is required for each scheduled operation.
Only 1 scheduled operation can be pending on each session.
A different session is also required to receive the <netconf-scheduled-message>
since the session sending the scheduled operation is busy waiting for the
<rpc-reply>.  The <cancel-schedule> RPC also must be on another session,
for the same reason.

If I understand correctly, you are suggesting a workaround that allows the 
:time capability without violating the reply-in-reception-order requirement. 
Right?

Thanks,
Tal.