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

[Andy Bierman <[e-mail]>]

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