Subject: [netconf] NETCONF session pipelining & concurrency

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 5 Mar 2020 23:49:54 +0000

Hi all,

RFC6241 says the following:

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.

That allows some level of pipelining but has head-of-line blocking issues:
1) some requests could have a rapid response (e.g. error detected in the syntax of the request) and
2) some requests could be a very long time before a response (a commit of a huge config, or a ping RPC that runs 10 x 10s pings and puts the result in the rpc-reply).

What if a server decided to send responses out of order (i.e. as an optimization)? (or we removed the "responses only in the order" clause from the spec). What impact would that have on clients?

A client that doesn't pipeline (i.e. waits for the rpc-reply before issuing the next rpc) wouldn't be affected.

Would clients that pipeline be able to handle out-of-order responses in general?  Consider, for example, a first rpc that is doing a very long commit, followed by a second rpc that is reading a state leaf called "commit-progress" to see what is going on.

Jason