Subject: [Netconf] No standard way to deal with a maximum number of NETCONF session supported by a server?

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 16 Aug 2018 07:19:11 +0000

Hi,

I was looking for some information on how can be dealt with a situation where a server may implement that only a maximum number of parallel NETCONF sessions can be supported.  With respect to interop between different products it would be good to have a common mechanism to deal with a situation like this.  There is nothing mentioned about this in the NETCONF protocol itself and I did not find a suitable error code in the NETCONF error list that could be included as information in the rpc-reply to a hello rpc.

Is this situation expected to be dealt with during the connection setup on the transport level carrying the NETCONF RPCs?

Is there any discussion/conclusion that we can refer to for this specific case?

Thanks and regards, Bart

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Aug 2018 09:36:07 +0200 (CEST)

Hi,

"Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]> wrote:
> Hi,
> 
> I was looking for some information on how can be dealt with a
> situation where a server may implement that only a maximum number of
> parallel NETCONF sessions can be supported.  With respect to interop
> between different products it would be good to have a common mechanism
> to deal with a situation like this.  There is nothing mentioned about
> this in the NETCONF protocol itself and I did not find a suitable
> error code in the NETCONF error list that could be included as
> information in the rpc-reply to a hello rpc.

Note that <hello> is not an rpc with an rpc-reply, but sent
immediately when the session has been established.

Unfortunately, the protocol doesn't have any mechanism for the server
to indicate to the client that the session could not be established.

It is also not possible to indicate the reason that an established
session is terminated, e.g. due to idle timeout or a kill-session.

It would have been nice if the server could send an <error> message in
these cases.

/martin

> Is this situation expected to be dealt with during the connection
> setup on the transport level carrying the NETCONF RPCs?
>

---

From: "Bogaert, Bart (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 16 Aug 2018 08:26:51 +0000

Martin,

Thanks for the feedback.  Are there any plans to extend this in the protocol?

Regards, Bart

-----Original Message-----
From: Martin Bjorklund <[email-masked]> 
Sent: Thursday, August 16, 2018 9:36 AM
To: Bogaert, Bart (Nokia - BE/Antwerp) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] No standard way to deal with a maximum number of NETCONF session supported by a server?

Hi,

> information in the rpc-reply to a hello rpc.

Note that <hello> is not an rpc with an rpc-reply, but sent immediately when the session has been established.

Unfortunately, the protocol doesn't have any mechanism for the server to indicate to the client that the session could not be established.

It is also not possible to indicate the reason that an established session is terminated, e.g. due to idle timeout or a kill-session.

It would have been nice if the server could send an <error> message in these cases.

/martin