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

"Bogaert, Bart (Nokia - BE/Antwerp)" <bart.bogaert@nokia.com> Thu, 16 August 2018 07:19 UTC

Return-Path: <bart.bogaert@nokia.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5ED130F8E for <netconf@ietfa.amsl.com>; Thu, 16 Aug 2018 00:19:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49uHYcm58ndJ for <netconf@ietfa.amsl.com>; Thu, 16 Aug 2018 00:19:14 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03on0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe08::704]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8724D130EF5 for <netconf@ietf.org>; Thu, 16 Aug 2018 00:19:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=djCVryCHxLj/FXS56mzD6P0tE6HnIJvysn7jL/BmZ+M=; b=pR9UXURKn+0eHH2UnlLQ9fqeBibRJXAXvzJ9D9/anZF28iq6jpvoQhsx5XKXPVHPo1sVXJ27ffOjMxO3QoiVjCxEs5YOdazG88SGBTiNzzzRYOPowXbsLn2WyLFxqKsPW9qmdHb7esI/PxxiK9iWGWSHKXrq5Jh036Nh/snCdR0=
Received: from AM0PR07MB3939.eurprd07.prod.outlook.com (52.134.82.147) by AM0PR07MB4370.eurprd07.prod.outlook.com (52.133.61.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1059.19; Thu, 16 Aug 2018 07:19:11 +0000
Received: from AM0PR07MB3939.eurprd07.prod.outlook.com ([fe80::8928:b367:ac4f:3ec4]) by AM0PR07MB3939.eurprd07.prod.outlook.com ([fe80::8928:b367:ac4f:3ec4%7]) with mapi id 15.20.1059.017; Thu, 16 Aug 2018 07:19:11 +0000
From: "Bogaert, Bart (Nokia - BE/Antwerp)" <bart.bogaert@nokia.com>
To: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: No standard way to deal with a maximum number of NETCONF session supported by a server?
Thread-Index: AdQ1MLhXFPcnkaklQyqbt7bchkn1MA==
Date: Thu, 16 Aug 2018 07:19:11 +0000
Message-ID: <AM0PR07MB39390C64E436B2A81DFFCC06943E0@AM0PR07MB3939.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com;
x-originating-ip: [135.245.212.97]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB4370; 6:jVt++kN8U19BsIFV+vgc9ozGc53TzFRUt/ZN5WNuSfqjrGpd2z5CSK8TEM2g1nU9UehH+jck7t1YfD4TmJ7HA03/nUxDSxEQbLbXY8V+2QKBqcY8VucskBD29akzHYDtiHd0KP7ZVOAAlnmv9k7NNEniM2hw84Ny4//k+eU88aWbKs1wnt97GP0q1bKcOlDhI6TJZwKTkDr1TRKyRElhCwX9s6/Q7P3kzIrnnoBcNssj0hHgxjMainFox2vCIs4lZpLKxesIHNJ7jueTANnnVpht84Cpi9/oUGK1ftjAy7zMbhm6jACwuglty6XXT2ZOhlLQww+NFY4XATLUzdb90vUkyYXy3FpVW1qQUlbot1DmpO2pGqsl8QzPdalwVYYXLS9vKDRLJXiklmXboI7CTR7vAdyVWA2H7SyTCrftQmsucjFmmnClftWhMLBUrIdUcNm8kTS7fpqBH13z1RGBbg==; 5:uPi9vuuW5UtkZnrzHAeQomn47FpF+Q3zIL9MoxvfWPe2Jz0Ml2uWRIxh28c7LzDPcT7PyyWlaFvzEdkbNIg1pXBs0+EG8mMbafoMFTl3DJDxmTT6yzPZnbb141ovgBTJ7DjI5LUZWnshrnL9GIhO9N4cBAa7Nhx4vFnCAJVk5f0=; 7:N8IbdAy6h1/82E0O8WsxitDINTWBgvC03Oxac7SUMTg1GxgCJ42WfqnUtAbtb2W8H+JxnJ7OeOblD/RViLAjdCHWxYSrgBnd+Nciu1MHKYI8uMxwnn1aZxD6ouiX4Ph2fV80pbT4l+0DAii+56m5tMC3K3u7EwHPvgBaM48R9Q7d7Ype4Ef6IqqGR4QSB15gF/ZwTvqQgMhaZkprBz30G/uwnyWSbGBF6v4UdwJjIWCRNtPqj0AxIay+mKSVQv9R
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 5676c36f-1e11-46a0-dbf5-08d603489050
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:AM0PR07MB4370;
x-ms-traffictypediagnostic: AM0PR07MB4370:
x-microsoft-antispam-prvs: <AM0PR07MB4370AAAAFA194F3C868DB2E2943E0@AM0PR07MB4370.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231311)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(201708071742011)(7699016); SRVR:AM0PR07MB4370; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4370;
x-forefront-prvs: 07665BE9D1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(136003)(39860400002)(366004)(199004)(189003)(86362001)(6916009)(3846002)(5630700001)(68736007)(8936002)(102836004)(5660300001)(1730700003)(81166006)(186003)(478600001)(81156014)(6116002)(8676002)(2906002)(790700001)(2351001)(9686003)(6436002)(6306002)(54896002)(256004)(55016002)(5640700003)(14454004)(7696005)(105586002)(33656002)(53936002)(97736004)(99286004)(2900100001)(6506007)(74316002)(25786009)(2501003)(26005)(5250100002)(7736002)(486006)(106356001)(476003)(66066001)(316002)(43043002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4370; H:AM0PR07MB3939.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: r8ZBe9QLxAdJz09TEoGlwswHgFHT2FhmjEg+QnJ80b2v+kZ4kuD+/wk7bsHY8/iRjI54q24ah05szP3IU9l5Q46C44f04UsLhxUjAaUJ5JzXFOYIQarnRbzfbOMrfssX+tvT8llliEQsJEzabhltM1JC6y9vIPAJrRSw4XAOFPMuvp0mzN73f+AD5AKasICem3fwSVq9iYmDXC5m9L+iTpE+/H57oUNx8EbxJEp5furqsL14uPBpF56e22zJg2yoBIac1kuDgwCCwVsxHLyfEr7SH6dKTtW0N8yrrWblUcJUwWRvnI2DjLWggi9xRhI4rV42/ieBcQkoKmJlzGOgPJHrHl53aA8LrhJz1ed5TtCrTgJWFUceb8+4EoIY/3ryYtLztZ8Dsg4rsFI1ElWiGg==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM0PR07MB39390C64E436B2A81DFFCC06943E0AM0PR07MB3939eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5676c36f-1e11-46a0-dbf5-08d603489050
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2018 07:19:11.2180 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4370
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ysEmoE3yXHKPLkKaZ96SEvtCWdw>
Subject: [Netconf] No standard way to deal with a maximum number of NETCONF session supported by a server?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2018 07:19:24 -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