Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

Qin Wu <bill.wu@huawei.com> Tue, 03 July 2018 01:36 UTC

Return-Path: <bill.wu@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 303CE130E9D for <netconf@ietfa.amsl.com>; Mon, 2 Jul 2018 18:36:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level:
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 4pw1NgVbd1dN for <netconf@ietfa.amsl.com>; Mon, 2 Jul 2018 18:36:42 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83091130E31 for <netconf@ietf.org>; Mon, 2 Jul 2018 18:36:41 -0700 (PDT)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 7AE96A58B57DE; Tue, 3 Jul 2018 02:36:38 +0100 (IST)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 3 Jul 2018 02:36:39 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.193]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0382.000; Tue, 3 Jul 2018 09:36:34 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Robert Wilton <rwilton@cisco.com>, Andy Bierman <andy@yumaworks.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Kent Watsen <kwatsen@juniper.net>, Ladislav Lhotka <lhotka@nic.cz>, netconf <netconf@ietf.org>
Thread-Topic: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt
Thread-Index: AQHUDgohYkKCob3+QEeCTKJnrpl8VqR0/o0ggAAY6ACAAV+F8IAAiDSAgAEcNQCAAEg30P//ne4AgAO4TyD//6LGAIAAoGCl//97SwAABG7KgAAAfvWAACN6EEA=
Date: Tue, 03 Jul 2018 01:36:33 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9AEC1230@nkgeml513-mbx.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABA9AEB9E31@nkgeml513-mbx.china.huawei.com> <87a7rfjdcx.fsf@nic.cz> <B8F9A780D330094D99AF023C5877DABA9AEBAF17@nkgeml513-mbx.china.huawei.com> <2A66E046-CE29-42B5-A60C-1313357378DE@juniper.net> <B8F9A780D330094D99AF023C5877DABA9AEBD689@nkgeml513-mbx.china.huawei.com> <B8F9A780D330094D99AF023C5877DABA9AEBD700@nkgeml513-mbx.china.huawei.com> <20180630090808.5g232ydinkbsnddg@anna.jacobs.jacobs-university.de> <B8F9A780D330094D99AF023C5877DABA9AEBED1A@nkgeml513-mbx.china.huawei.com> <20180702122254.hrws4cneranwwm3w@anna.jacobs.jacobs-university.de> <B8F9A780D330094D99AF023C5877DABA9AEBF04F@nkgeml513-mbx.china.huawei.com> <20180702140156.m7mlohgzzfe3nr4l@anna.jacobs.jacobs-university.de> <CABCOCHQA-DA7pBMQ6j6DQrUGuYtEkdephQ4WL_O5dC5h49HXWw@mail.gmail.com> <e2e5332e-48ce-5841-3219-1d7c0fb4958d@cisco.com>
In-Reply-To: <e2e5332e-48ce-5841-3219-1d7c0fb4958d@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.33.244]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9AEC1230nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/-jnrJlbYFf6lMUJn2sXNsZnG6ls>
Subject: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 03 Jul 2018 01:36:45 -0000

发件人: Robert Wilton [mailto:rwilton@cisco.com]
发送时间: 2018年7月3日 0:23
收件人: Andy Bierman; Juergen Schoenwaelder; Qin Wu; Kent Watsen; Ladislav Lhotka; netconf
主题: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

On 02/07/2018 17:08, Andy Bierman wrote:


On Mon, Jul 2, 2018 at 7:01 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>> wrote:
I suggest to try to make the proposal simpler, not more complex.
+1

IMO the only thing needed is 1 simple identity named "factory".
Yes, I basically agree.

In addition, when a device boots then <startup> is initialized to <factory> if it doesn't exist.  Or alternatively, <running> is initialized to <factory> if <startup> doesn't exist.
A client can use an RPC to copy <factory> to <startup> or to <running> if they want, but then can never write to <factory> (although factory could change via a software update).

[Qin]: Good summary, this is exactly what we like to propose.

Existing protocol operations can be used (e.g, copy-config from factory to running).
Now RESTCONF is datastore aware, it looks like we need to add a "copy-config" RPC (or should it just be "copy"?) to RESTCONF to allow the contents of one datastore to be copied to another datastore.  Such an RPC should be entirely generic and not tied to the factory datastore in anyway.

[Qin]: Yes, one of our thoughts is to define a generic operation, e.g., copy-datastore, delete-datastore, maybe compare-datastore, all these operations are datastore level instead of data node level.

Possibly, related to this, it might be worth considering if there are any other operations in NETCONF that should be supported in RESTCONF and to do that as a single update to the protocol rather than lots of piecemeal extensions.

Thanks,
Rob





/js

Andy


On Mon, Jul 02, 2018 at 01:56:54PM +0000, Qin Wu wrote:
>
>
>
> 发件人: Juergen Schoenwaelder
> 收件人: Qin Wu<bill.wu@huawei.com<mailto:bill.wu@huawei.com><mailto:bill.wu@huawei.com<mailto:bill.wu@huawei.com>>>
> 抄送: Kent Watsen<kwatsen@juniper.net<mailto:kwatsen@juniper.net><mailto:kwatsen@juniper.net<mailto:kwatsen@juniper.net>>>;Ladislav Lhotka<lhotka@nic.cz<mailto:lhotka@nic.cz><mailto:lhotka@nic.cz<mailto:lhotka@nic.cz>>>;netconf<netconf@ietf.org<mailto:netconf@ietf.org><mailto:netconf@ietf.org<mailto:netconf@ietf.org>>>
> 主题: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt
> 时间: 2018-07-02 20:23:06
>
> On Mon, Jul 02, 2018 at 12:16:27PM +0000, Qin Wu wrote:
> > Good point and suggestion. Here is my thought:
> > In case :startup capability is supported, the factory datastore can be copied into <startup>, restart is not needed since we have loaded content of factory datastore into startup. Startup will be updated with running each time the running is altered. In case of system fatal error, we will consider copy factgory datatore into <startup> again for restore.
>
> I doubt this will work. If you copy <factory> to startup> and
> subsequently <running> to <startup>, there is a copy of <running> left
> in <startup>, i.e., the copy of <factory> to startup> had no effect.
> [Qin] To address this issue, we can introduce multiple target data sores in the new operation factory restore operation, copy factory datastore to startup and running in one operation, the source will be set to the same factory datastore.
>
> > In case the restart is needed or device power on is needed, the factory datastore as source may not be set, instead, URL is set as source, the content of source identified by URL can be loaded into target datastore during restart or device repower on. In this case, the proposed factory datastore
> > and new operation can work together with zero touch bootstrapping procedure proposed in draft-ietf-netconf-zerotouch.
>
> URLs are an optional capability so far and I do not know what "URL is
> set as source" means to me. What is target datastore here? I am not
> sure how data flows.
> [Qin] see device power on procedure defined in zero touch netconf WG draft, factory restore scheme, in my opinion can be integrated into it. The target datastore(s) can be set to any datasore(s) you want to return factory default.
>
> > In case :writable-running capability is supported, the factory datastore can be directly copied into <running>, in case of multiple conceptual flows, we can consider to copy one factory datastore into multiple <running> targets.
> > In case :candidate capability is supported, the factory datastore can be first copied into <candiate> and then the <candidate> is committed into <running>, in this case, startup is not touched.
>
> What are multiple <running> targets? What are "multiple conceptual flows"?
> I am confused.
> [Qin] see above, in the above cases,multiple datasores can be set to <startup> and <running> And all other datastore that need to set to factory default. That means in the new operation, multiple target list can be included. If multiple factory defaults are allowed,multiple sources can be included as well.
>
> Not sure multiple target running case exists,if we can copy one source to multiple instances distributed in multiple logical network elements, that will be great.
> /js
>
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <https://www.jacobs-university.de/>

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

_______________________________________________
Netconf mailing list
Netconf@ietf.org<mailto:Netconf@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf





_______________________________________________

Netconf mailing list

Netconf@ietf.org<mailto:Netconf@ietf.org>

https://www.ietf.org/mailman/listinfo/netconf