[netconf] system configuration sync mechanism

"maqiufang (A)" <maqiufang1@huawei.com> Wed, 23 June 2021 03:43 UTC

Return-Path: <maqiufang1@huawei.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 A34EE3A26E7 for <netconf@ietfa.amsl.com>; Tue, 22 Jun 2021 20:43:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 snMh-vMW00Bc for <netconf@ietfa.amsl.com>; Tue, 22 Jun 2021 20:43:44 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 111093A26E5 for <netconf@ietf.org>; Tue, 22 Jun 2021 20:43:44 -0700 (PDT)
Received: from fraeml744-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4G8ppB4gBVz6K6TK for <netconf@ietf.org>; Wed, 23 Jun 2021 11:36:18 +0800 (CST)
Received: from dggeme768-chm.china.huawei.com (10.3.19.114) by fraeml744-chm.china.huawei.com (10.206.15.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Wed, 23 Jun 2021 05:43:41 +0200
Received: from dggeme770-chm.china.huawei.com (10.3.19.116) by dggeme768-chm.china.huawei.com (10.3.19.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Wed, 23 Jun 2021 11:43:39 +0800
Received: from dggeme770-chm.china.huawei.com ([10.8.68.58]) by dggeme770-chm.china.huawei.com ([10.8.68.58]) with mapi id 15.01.2176.012; Wed, 23 Jun 2021 11:43:39 +0800
From: "maqiufang (A)" <maqiufang1@huawei.com>
To: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] system configuration sync mechanism
Thread-Index: Addn4K+zt1m84GV6QrqhDxVqt12upw==
Date: Wed, 23 Jun 2021 03:43:39 +0000
Message-ID: <38c3aa805f1846d0ad0e5ac67a82cfa1@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.123.93]
Content-Type: multipart/alternative; boundary="_000_38c3aa805f1846d0ad0e5ac67a82cfa1huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/n_XJHcAwnU2Lx_6yOGassJeARoM>
Subject: [netconf] system configuration sync mechanism
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG 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: Wed, 23 Jun 2021 03:43:49 -0000

Dear all,
One of the open issues of draft https://datatracker.ietf.org/doc/html/draft-ma-netconf-with-system-02 is about how to synchronize the system configuration into <running>.
I think we could have 2 options.
Option 1: Any update in <system> will be synced up into <running> automatically
  PRO:

       o  effective for the client: there is no need for the client to retrieve the referenced system configuration from <operational> and then copy it into <running> manually.
  CON:
            o   implementation complexity

Option 2: To define a RPC operation to propagate <running> with <system>
  PRO:
       o  client-driven: it totally depends on the client when and how to populate <running>.
  CON:
       o  The client needs to :

o   spend energy to detect the <system> update and operate the RPC every time the client references the system configuration or the system configuration is in the when/must statement.

o   subscribe the <system> update and copy it into <running> whenever an update is detected.

I incline to the view that this issue involves some kind of trade-off, which is hard to distinguish the preference.
Maybe both options can be reserved and differentiated by different modes, so that the server implementer may choose from.
Any thoughts?


Best Regards,
Qiufang Ma