Subject: [netconf] RPC request Timeout

From: "Jonathan Hansford" <[email-masked]>
Date: Mon, 21 Mar 2022 08:59:44 +0000

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

Thanks,

Jonathan

---

From: Kent Watsen <[email-masked]>
Date: Mon, 21 Mar 2022 13:15:23 +0000

Hi Jonathan,

> On Mar 21, 2022, at 4:59 AM, Jonathan Hansford <jonathan=[email-masked]> 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? 
> 
> 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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>

---

From: "Jonathan Hansford" <[email-masked]>
Date: Mon, 21 Mar 2022 15:34:01 +0000

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" <[email-masked]> wrote:

>Hi Jonathan,
>
>>On Mar 21, 2022, at 4:59 AM, Jonathan Hansford 
>><jonathan=[email-masked]> wrote:
>>
>>Hi,
>>
>>Once the netconf manager sends a rpc request to the managed device, 
>>how long should it wait for the rpc-reply?
>>
>>retry, number of retries, presumably followed by closing the session 
>>if it is still open)?
>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
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Mar 2022 10:44:27 -0700

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

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

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

> <rpc> requests one might typically expect it to send while awaiting an
A small number (like 3), but this is really implementation specific, so who
knows.

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

> Jonathan

Andy

> On Mar 21, 2022, at 4:59 AM, Jonathan Hansford <
> jonathan=[email-masked]> wrote:
>
> Hi,
>
> 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)?
> 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