Re: [Gen-art] Gen-art LC review: draft-mm-netconf-time-capability-05

[Tal Mizrahi <[e-mail]>]

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:[e-mail]]
Sent: Thursday, August 06, 2015 7:42 PM
To: Tal Mizrahi
Cc: Robert Sparks; General Area Review Team; [e-mail]; [e-mail]
Subject: Re: Gen-art LC review: draft-mm-netconf-time-capability-05



On Wed, Aug 5, 2015 at 10:46 PM, Tal Mizrahi <[e-mail]<mailto:[e-mail]>> 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