Re: [netconf] RPC request Timeout

[Andy Bierman <[e-mail]>]

On Mon, Mar 21, 2022 at 8:34 AM Jonathan Hansford <jonathan=
[e-mail]> wrote:

> Hi Kent,
>
> I'm grateful for your reply, however I don't believe it addressed my
> questions which relate to aspects of NETCONF error handling for which I
> cannot find guidance in RFC 6241. I think what I am looking for is any
> guidance from existing implementations, if people are willing to share.
>
> 1) How should a client behave if it doesn't receive an <rpc-reply> to an
> <rpc> request? Is the assumption that, since the transport protocol
> "provides reliable, sequenced data delivery", the server has failed and the
> session should be terminated, or should the client retry? If the latter,
> for how long should it wait before retrying? Should it retry with the
> same message-id? And how many times should it try to send the <rpc>
> request before terminating and attempting to re-establish the session?
>
>
The client should (usually) timeout after a configured amount of time.
yangcli-pro uses a default of 30 seconds.
https://www.yumaworks.com/pub/latest/cli/yumapro-cli-reference.html#timeout



> 2) If the server receives a duplicate <rpc> request with the same
> message-id, how should it behave? Should it resend its previous
> <rpc-reply>? Respond as though it were a new request? What if other clients
> have managed to send <rpc> requests in the meantime that have e.g. changed
> one of the server's configuration datastores?
>

The netconfd-pro server just makes sure a message-id attribute is present.
It ignores the value and just returns all attributes for this requirement

      If additional attributes are present in an <rpc> element, a NETCONF

   peer MUST return them unmodified in the <rpc-reply> element.  This
   includes any "xmlns" attributes.


This sentence implies the server should reuse any prefix mappings
in xmlns attributes passed by the client. It has to (at least)
not conflict with them.




> 3) If the client is pipelining, is there a maximum number of additional
> <rpc> requests one might typically expect it to send while awaiting an
> <rpc-reply>?
>
>
A small number (like 3), but this is really implementation specific, so who
knows.



> 4) What should a client do if it receives an <rpc-reply> with the wrong
> message-id? Should it terminate and re-establish the session?
>
>

Wrong or just late?
yangcli-pro just drops the message and prints an error message in both
cases.



> Thanks,
>
> Jonathan
>


Andy


>
> On 21/03/2022 13:15:23, "Kent Watsen" <[e-mail]> wrote:
>
> Hi Jonathan,
>
> On Mar 21, 2022, at 4:59 AM, Jonathan Hansford <
> jonathan=[e-mail]> wrote:
>
> Hi,
>
> back in 2004, V. Sarma asked (see Pipelining and Timeout queries
> <https://mailarchive.ietf.org/arch/msg/netconf/h_vSQNr9YY2ewAQQHudNJaTCpns/>
> ):
>
> Once the netconf manager sends a rpc request to the managed device, how
> long should it wait for the rpc-reply?
>
> Can the netconf manager time-out after a specified time interval?
>
> I know this is a basic question, but it doesn't appear it was ever
> answered. So, can anyone advise what the typical strategies are:
> When the client doesn't receive an rpc-reply (e.g. time interval to retry,
> number of retries, presumably followed by closing the session if it is
> still open)?
> When the server receives a duplicate rpc request (e.g. reply based on
> latest config and state)?
>
>
> I'm unaware of the client-behavior being defined but, in general, I expect
> server-interaction to be fairly responsive (seconds, not minutes).
> Notably, the undefined expectation is that the server will ACK an
> <edit-config> or <commit> immediately after validating the input but
> *before* applying the update (e.g., to the data plane), which may take
> minutes.  The opstate-reqs draft
> <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-opstate-reqs> discussed
> asynchronous responses, but the WG didn't act on it...instead an ability to
> compare datastores to detect what didn't get applied in RFC 9144
> <https://datatracker.ietf.org/doc/rfc9144/>.
>
> Kent // contributor
>
>
>
>
>
>
> Thanks,
>
> Jonathan
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>