Re: [netconf] RPC request Timeout

[Jonathan Hansford <[e-mail]>]

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?

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?

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>?

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?

Thanks,

Jonathan

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
>