Hi Andy,
We want to thank you again for the thorough review, and for many helpful
comments you sent us, both on the mailing list and offline.
We carefully considered each and every comment you sent. In most cases we
updated the document to resolve the issues you raised. In other cases we sent a
response that explains the rationale in not updating.
We have posted an updated draft:
https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/
Please let us know if you have further comments.
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.
Indeed, we have added a new subsection, “4.5.2. Processing Scheduled
Operations”, which discusses this issue, and explains the order of scheduled
RPCs, and how the time capability interoperates with existing implementations.
NETCONF capabilities are not allowed to undo requirements of
other capabilities.
That is correct. However, according to RFC 6241, the definition of a new
capability should include the section “Modifications to Existing Operations”.
Hence, clearly a new capability can modify the behavior of existing operations.
That is exactly what we are doing in the current draft.
We are not suggesting to undo the “MUST” you quoted. We are only defining
“modifications” that are applicable to specific operations: the operations
listed in Section “4.5.1. Affected Operations”.
Specifically, these “modifications” are only limited to scheduled RPCs (as
discussed in section 4.5.2), and thus do not affect the behavior of existing
NETCONF servers, and do not compromise interoperability.
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.
Right. Let’s consider two cases:
(1) *Existing* RFC6241 server implementations do not support the time
capability. So there is no problem there, because based on the capability
exchange, the client knows these servers do not support the time capability,
and the rpc-reply order is exactly as defined in RFC6241.
(2) *New* NETCONF implementations can support the time capability.
For *unscheduled* RPCs, the order will be exactly as defined in RFC6241.
For *scheduled* RPCs, the order will be as defined in our draft – this complies
to the “modifications to existing operations”.
Based on (1)+(2), there is no conflict between the time capability and
*existing* or *new* implementations.
Thanks,
Tal.
From: Andy Bierman [mailto:andy(_at_)yumaworks(_dot_)com]
Sent: Thursday, August 06, 2015 7:42 PM
To: Tal Mizrahi
Cc: Robert Sparks; General Area Review Team; ietf(_at_)ietf(_dot_)org;
draft-mm-netconf-time-capability(_dot_)all(_at_)ietf(_dot_)org
Subject: Re: Gen-art LC review: draft-mm-netconf-time-capability-05
On Wed, Aug 5, 2015 at 10:46 PM, Tal Mizrahi
<talmi(_at_)marvell(_dot_)com<mailto:talmi(_at_)marvell(_dot_)com>> wrote:
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.
IMO, the only operation that has a reasonable use-case is <get>
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.
NETCONF capabilities are not allowed to undo requirements of
other capabilities. In order to undo the requirements of sec. 4.5,
the server cannot advertise NETCONF base 1.0 or 1.1, and also
advertise the 'time' capability.
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.
IMO you need a new revision of the protocol that removes the pipelining
requirements in order to pursue this solution.
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?
No, I think RFC 6241 is quite clear how it will handle new <rpc> requests on
the same session as an operation already in progress. It will buffer the
requests and process them in the order received.
Other solutions such as multiple <rpc-reply> for a single request are
designed to work within the existing NETCONF protocol rules.
IMO that solution approach would be better for this problem.
(i.e. get rid of the notification and return <ok/> to the schedule request.
Then send another <rpc-reply> when the executed task is invoked
or cancelled.)
Thanks,
Tal.
Andy