[Netconf] Review of draft-lhotka-netconf-restconf-transactions-00

Qin Wu <bill.wu@huawei.com> Thu, 28 June 2018 11:45 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 446DB130F62 for <netconf@ietfa.amsl.com>; Thu, 28 Jun 2018 04:45:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 i0MwreyZWTFY for <netconf@ietfa.amsl.com>; Thu, 28 Jun 2018 04:44:59 -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 0B9D712777C for <netconf@ietf.org>; Thu, 28 Jun 2018 04:44:59 -0700 (PDT)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A355E8EBA1F44; Thu, 28 Jun 2018 12:44:55 +0100 (IST)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 28 Jun 2018 12:44:56 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.193]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0382.000; Thu, 28 Jun 2018 19:44:51 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "netconf@ietf.org" <netconf@ietf.org>, Ladislav Lhotka <lhotka@nic.cz>
Thread-Topic: Review of draft-lhotka-netconf-restconf-transactions-00
Thread-Index: AQHUDtVsCp81/09Vc0+U9XhrRZtALw==
Date: Thu, 28 Jun 2018 11:44:50 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9AEBA43F@nkgeml513-mbx.china.huawei.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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/EE19I5yHuic61CoWMIXT8Mzf-Ng>
Subject: [Netconf] Review of draft-lhotka-netconf-restconf-transactions-00
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: Thu, 28 Jun 2018 11:45:02 -0000

Hi, Lada:
I like this idea in draft-lhotka-netconf-restconf-transactions-00 and add transaction support for RESTCONF.
use transactions to support robust configuration change involving a number of devices.

I am wondering, how do you write content from client staging 
datastore into readonly intended datastore? Usually if we want 
to see the content in client staging datastore be part of 
intended datastore, we should first run commit operation 
defined in RFC6241, make content in client staging datastore 
be part of running datastore, Any then after validation 
process, the client staging datastore content can be part of intended.
Right?

Second question is do we support rollback operation and allow rollback to some restore checkpoint
Or roll back to factory default setting?

-Qin
-----邮件原件-----
发件人: Ladislav Lhotka [mailto:lhotka@nic.cz] 
发送时间: 2018年6月28日 16:30
收件人: Qin Wu
主题: Re: draft-lhotka-netconf-restconf-transactions-00

On Thu, 2018-06-28 at 02:58 +0000, Qin Wu wrote:
> Hi, Lada:
> Would you like to provide a few comments on 
> draft-wu-netconf-restconf-factory-
> restore-00, chairs want to see some discussion on the list before the meeting.
> I can help provide review on draft-lhotka-netconf-restconf-transactions-00.

Hi Qin,

this mutual review is a good idea, I will do it.

Thanks, Lada

> 
> -Qin
> -----邮件原件-----
> 发件人: Ladislav Lhotka [mailto:lhotka@nic.cz]
> 发送时间: 2018年6月27日 18:04
> 收件人: Qin Wu
> 主题: Re: draft-lhotka-netconf-restconf-transactions-00
> 
> Hi Qin,
> 
> sorry I didn't respond sooner, I am currently out of office. Regarding 
> my coauthoriship, I made no real contribution - just publish it as the 
> only author.
> We'll see what's going to happen, one option might be to combine our 
> drafts later, but it is up to the WG.
> 
> Lada
> 
>  
> On Wed, 2018-06-27 at 04:11 +0000, Qin Wu wrote:
> > Ping your feedback, thanks.
> > 
> > -Qin
> > -----邮件原件-----
> > 发件人: Qin Wu
> > 发送时间: 2018年6月26日 9:52
> > 收件人: 'Ladislav Lhotka'
> > 主题: RE: draft-lhotka-netconf-restconf-transactions-00
> > 
> > Agree with your suggestion, Lada, here is update based on your comments.
> > I add you as coauthor, let me know if you approve to publish this version.
> > 
> > -Qin
> > -----邮件原件-----
> > 发件人: Ladislav Lhotka [mailto:lhotka@nic.cz]
> > 发送时间: 2018年6月25日 22:38
> > 收件人: Qin Wu
> > 主题: RE: draft-lhotka-netconf-restconf-transactions-00
> > 
> > Hi Qin,
> > 
> > I would like to keep it as simple as possible for the initial 
> > presentation to the working group (which I hope will take place in 
> > Montreal). If there is enough interest, and perhaps the draft 
> > becomes a WG item, I am open to discuss additional features.
> > 
> > Cheers, Lada
> > 
> > Qin Wu <bill.wu@huawei.com> writes:
> > 
> > > Lada:
> > > One more idea is to add capability to support restoring the 
> > > configuration to any configuration checkpoint.
> > > e.g., we can roll back the system configuration to a specified 
> > > checkpoint by user label.
> > > Or we can roll back the system configuration to a specified 
> > > checkpoint by checkpoint number.
> > > 
> > > -Qin
> > > -----邮件原件-----
> > > 发件人: Qin Wu
> > > 发送时间: 2018年6月21日 15:22
> > > 收件人: 'Ladislav Lhotka'
> > > 主题: RE: draft-lhotka-netconf-restconf-transactions-00
> > > 
> > > Hi, Lada:
> > > Sorry for late reply.
> > > Here is the strawman proposal on factory default setting.
> > > I come up with two use cases in section 3.2 and section 3.3.
> > > Let me know if the problem space and solution make sense to you.
> > > Any interests to cosign if make sense.
> > > 
> > > -Qin
> > > -----邮件原件-----
> > > 发件人: Ladislav Lhotka [mailto:lhotka@nic.cz]
> > > 发送时间: 2018年6月18日 18:38
> > > 收件人: Qin Wu
> > > 主题: Re: draft-lhotka-netconf-restconf-transactions-00
> > > 
> > > On Mon, 2018-06-18 at 09:57 +0000, Qin Wu wrote:
> > > > -----邮件原件-----
> > > > 发件人: Ladislav Lhotka [mailto:lhotka@nic.cz]
> > > > 发送时间: 2018年6月18日 16:01
> > > > 收件人: Qin Wu
> > > > 主题: Re: draft-lhotka-netconf-restconf-transactions-00
> > > > 
> > > > Hi Qin,
> > > > 
> > > > Qin Wu <bill.wu@huawei.com> writes:
> > > > 
> > > > > Hi, Lada:
> > > > > Interesting draft, it looks client staging datastore you 
> > > > > proposed is a special case of candidate datastore,
> > > > 
> > > > Correct, it is basically a non-shared <candidate>.
> > > > 
> > > > > I am wondering, how do you write content from client staging 
> > > > > datastore into readonly intended datastore? Usually if we want 
> > > > > to see the content in client staging datastore be part of 
> > > > > intended datastore, we should First run commit operation 
> > > > > defined in RFC6241, make content in client staging datastore 
> > > > > be part of running datastore, Any then after validation 
> > > > > process, the client staging datastore content can be part of intended after validation.
> > > > 
> > > > In our implementation (JetConf [*]), we don't have NETCONF 
> > > > underneath, so we want to make the workflow simple and explicit.
> > > > 
> > > > > 
> > > > > Now you propose commit operation and reset operation specific 
> > > > > to RESTCONF, I am wondering how do you write data directly 
> > > > > into intended by merging operation? I am wondering the 
> > > > > operation you proposed take place from <running> to intended 
> > > > > or from <candidate> to <intended>
> > > > 
> > > > Our implementation does the following:
> > > > 
> > > > - edit operations of every user are applied in the staging datastore but
> > > >   also kept in a journal
> > > > 
> > > > - at commit, if <intended> hasn't been modified in the mean time, the
> > > >   users's staging datastore simply becomes the new <intended>
> > > > 
> > > > - if <intended> has been modified, we replay the edit operations from
> > > >   the journal
> > > > [Qin]: Thank for clarification, can you explain what the 'journal' is?
> > > 
> > > It is a record of all operations performed by the user since the 
> > > last reset so that they can be replayed later.
> > > 
> > > >  
> > > > > 
> > > > > Another thought, do you think factory reset operation is needed?
> > > > > In some case, we may need to make running datdstore and 
> > > > > startup datastore to return to factory defaults.
> > > > > Based on RFC6241, we only can use delete-config to return 
> > > > > startup datastore to factory default, however We can not 
> > > > > directly use delete-config to return running datastore into 
> > > > > factory default.
> > > > > Do you think new operation such as factory reset should be 
> > > > > defined for this?
> > > > 
> > > > Possibly, but I think it is a different problem that may be 
> > > > relevant for standard RESTCONF, too.
> > > > 
> > > > [Qin]: Yes, you are right, are you interested in this problem space?
> > > > Let me know if there is a value to document a solution for this.
> > > 
> > > We currently don't have a use case for this but it can certainly 
> > > be useful.
> > > Another related topic is the use of <startup> in RESTCONF.
> > > 
> > > Lada
> > > 
> > > > 
> > > > Thanks, Lada
> > > > 
> > > > [*] https://pypi.org/project/jetconf/
> > > > 
> > > > > Look forward to your reply.
> > > > > 
> > > > > -Qin
> > > > 
> > > > --
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > 
> > > --
> > > Ladislav Lhotka
> > > Head, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> 
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67