Subject: [Netconf] Question about NETCONF RFC 6241 section 4.5 pipelining

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 24 May 2017 08:33:03 +0000

Hi,

We have a question about the following text about 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."

We tried the following (changes are applied to the running datastore - so no
candidate datastore is involved).

In terminal 1 we have an application that is involved in a transaction in
such a way that  it can either accept or reject an edit-config based on some
input.  As such it also allows to "artificially" extend the duration of the
transaction.

In terminal 2 we start an edit-config to modify the configuration.  The
application in terminal 1 is waiting for our action to let the transaction
complete.

In terminal 3 we do a get-config and we already see the change that is
pending

In terminal 1 we now let the application proceed and choose to reject the
configuration change.

In terminal 2 we see the error message coming back as response to the
edit-config.

In terminal 3 we again do a get-config and now we see the original
configuration.

The text in the RFC is not very explicit whether this pipelining is per
NETCONF session of over all the NETCONF sessions served by that NETCONF
server.  In the latter case the response to the first get-config would only
return once the edit-config has been completed (and hence the pending change
would not be visible).  What is the correct interpretation of this text and
what is the expected behavior in the above sequence?

Best regards - Vriendelijke groeten,

Bart Bogaert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 May 2017 10:43:58 +0200

> completed. The managed device MUST send responses only in the order the

[...]
 
> what is the expected behavior in the above sequence?

I believe the pipelining is per session. To coordinate requests coming
in over multiple session, you have to use locks. So that text should
really say:

OLD:

   NETCONF <rpc> requests MUST be processed serially by the managed
   device.

NEW:

   NETCONF <rpc> requests received over the same session MUST be
   processed serially by the managed device.

This is pretty much inline with pipelining in other protocols such as
SMTP or HTTP.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 24 May 2017 09:06:55 +0000

From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: 24 May 2017 10:44
To: Bogaert, Bart (Nokia - BE/Antwerp) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Question about NETCONF RFC 6241 section 4.5
pipelining

On Wed, May 24, 2017 at 08:33:03AM +0000, Bogaert, Bart (Nokia - BE/Antwerp)
wrote:
> completed. The managed device MUST send responses only in the order 
> the requests were received."

[...]
 
> The text in the RFC is not very explicit whether this pipelining is 
> per NETCONF session of over all the NETCONF sessions served by that 
> NETCONF server.  In the latter case the response to the first 
> get-config would only return once the edit-config has been completed 
> (and hence the pending change would not be visible).  What is the 
> correct interpretation of this text and what is the expected behavior in
the above sequence?

I believe the pipelining is per session. To coordinate requests coming in
over multiple session, you have to use locks. So that text should really
say:

OLD:

NEW:

This is pretty much inline with pipelining in other protocols such as SMTP
or HTTP.

[Bart Bogaert] What is then the expected behavior in case no locks are used
(which was the case in the provided example).  As one can observe a
concurrent session may request the configuration and gets a result that is
still being processed and eventually is not getting stored to the running
datastore as the involved application is rejecting the change (e.g. due to a
restriction that we can't express in YANG and which a client can't find
out).  Is in that case expected that the server keeps a "copy" of the
pending data "separate" to the running datastore in which case the
get-config would not show the pending transaction.  If I'm not mistaken the
same applied to databases: as long as a change has not been committed
reading from the database returns data as stored during the last commit to
the DB.  We observe a different behavior.

Regards, Bart

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 May 2017 13:14:06 +0200

On Wed, May 24, 2017 at 09:06:55AM +0000, Bogaert, Bart (Nokia - BE/Antwerp) wrote:
> 
> What is then the expected behavior in case no locks are used

I think RFC 6241 is silent about this. I do not think RFC 6241 says
that 'applying an edit' has to be atomic and that there must not be
any concurrent read operations - or that overlapping read operations
must continue with a snapshot view if there are concurrent changes to
a datastore. If concurrent access is an issue, use locks. If global
datastore locks are an issue, use partial locks (RFC 5717).

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 24 May 2017 08:37:25 -0700

> This is pretty much inline with pipelining in other protocols such as

I agree with your changes but I think the original intent was that the
input packets need to be buffered
if the server allows multiple concurrent sessions. i.e. -- is it OK for a
server that has accepted
multiple concurrent sessions to simply reject all requests on session 2
because a request is in progress
on session 1?

> /js

Andy

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 29 May 2017 11:57:17 +0000

Andy,

Thanks for this input.  Your response seems to suggest that an implementation 
may choose to queue the new request (even when coming in via another NETCONF 
session) until the previous request was fully handled.  The side effect of 
this could be that a long-running get may block any other action for quite 
some time (and may lead to possible timeouts).

Do I have to conclude that this behavior will be dependent on the NC server 
implementation?  This does not seem to be in favor of predictability.  I think 
the RFC should be clearer on this to avoid any ambiguity.

Regards, Bart

From: Andy Bierman [mailto:[email-masked]]
Sent: 24 May 2017 17:37
To: Juergen Schoenwaelder <[email-masked]>; Bogaert, 
Bart (Nokia - BE/Antwerp) <[email-masked]>; [email-masked]
Subject: Re: [Netconf] Question about NETCONF RFC 6241 section 4.5 pipelining

On Wed, May 24, 2017 at 1:43 AM, Juergen Schoenwaelder 
<[email-masked] 
<mailto:[email-masked]> > wrote:

[...]

OLD:

NEW:

I agree with your changes but I think the original intent was that the input 
packets need to be buffered

on session 1?

/js

Andy

_______________________________________________
Netconf mailing list
[email-masked] <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Tue, 30 May 2017 23:14:04 +0000

The intention is that the various sessions are processed in parallel.
For instance, the text for <kill-session> says:

      When a NETCONF entity receives a <kill-session> request for an
      open session, it will *abort any operations currently in process*,
      release any locks and resources associated with the session, and
      close any associated connections.

Which is only be possible if the server processed the sessions in parallel.

FWIW, this is not an issue for RESTCONF, since it doesn't have sessions,
since one of the hallmarks of REST is that it is stateless.

Kent

On 5/29/17, 7:57 AM, "Netconf on behalf of Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Andy,

Thanks for this input.  Your response seems to suggest that an implementation may choose to queue the new request (even when coming in via another NETCONF session) until the previous request was fully handled.  The side effect of this could be that a long-running get may block any other action for quite some time (and may lead to possible timeouts).
Do I have to conclude that this behavior will be dependent on the NC server implementation?  This does not seem to be in favor of predictability.  I think the RFC should be clearer on this to avoid any ambiguity.

Regards, Bart

From: Andy Bierman [mailto:[email-masked]]
Sent: 24 May 2017 17:37
To: Juergen Schoenwaelder <[email-masked]>; Bogaert, Bart (Nokia - BE/Antwerp) <[email-masked]>; [email-masked]
Subject: Re: [Netconf] Question about NETCONF RFC 6241 section 4.5 pipelining

On Wed, May 24, 2017 at 1:43 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

[...]

OLD:

NEW:

I agree with your changes but I think the original intent was that the input packets need to be buffered
if the server allows multiple concurrent sessions. i.e. -- is it OK for a server that has accepted
multiple concurrent sessions to simply reject all requests on session 2 because a request is in progress
on session 1?

/js

Andy

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf