Re: [Netconf] Solicit comments on inline action capability for NETCONF

Qin Wu <bill.wu@huawei.com> Tue, 10 July 2018 01:01 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 94648130EB0 for <netconf@ietfa.amsl.com>; Mon, 9 Jul 2018 18:01:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 JwdAbqpjIibA for <netconf@ietfa.amsl.com>; Mon, 9 Jul 2018 18:01:03 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 B5FD5127148 for <netconf@ietf.org>; Mon, 9 Jul 2018 18:01:02 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D224A105E26FF for <netconf@ietf.org>; Tue, 10 Jul 2018 02:00:57 +0100 (IST)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 10 Jul 2018 02:00:58 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.13]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0382.000; Tue, 10 Jul 2018 09:00:48 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>, "Zhengguangying (Walker)" <zhengguangying@huawei.com>
CC: "netconf@ietf.org" <netconf@ietf.org>, Rohit R Ranade <rohitrranade@huawei.com>, Aijun Wang <wangaijun@tsinghua.org.cn>
Thread-Topic: Solicit comments on inline action capability for NETCONF
Thread-Index: AdQTOvQ+DGsUYeJXQ/uaFzBxunpGvAABkhagAAO3KjAAAum+QAAAi6mgAHUafGAArYOooA==
Date: Tue, 10 Jul 2018 01:00:48 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9AEFA14E@nkgeml513-mbx.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABA9AEC24AC@nkgeml513-mbx.china.huawei.com> <991B70D8B4112A4699D5C00DDBBF878A6BBC8F99@dggeml510-mbx.china.huawei.com> <B8F9A780D330094D99AF023C5877DABA9AEC379E@nkgeml513-mbx.china.huawei.com> <991B70D8B4112A4699D5C00DDBBF878A6BBC90C8@dggeml510-mbx.china.huawei.com> <B8F9A780D330094D99AF023C5877DABA9AEC395F@nkgeml513-mbx.china.huawei.com> <567b64b502cf47cd84bf9f53f760a8fa@XCH-RTP-013.cisco.com>
In-Reply-To: <567b64b502cf47cd84bf9f53f760a8fa@XCH-RTP-013.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_B8F9A780D330094D99AF023C5877DABA9AEFA14Enkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/83P3cXxbMMYDvjFyPF-eXxQyCOM>
Subject: Re: [Netconf] Solicit comments on inline action capability for NETCONF
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: Tue, 10 Jul 2018 01:01:06 -0000

Thanks Eric for valuable comments, see reply inline.

-Qin
发件人: Eric Voit (evoit) [mailto:evoit@cisco.com]
发送时间: 2018年7月6日 22:38
收件人: Qin Wu; Zhengguangying (Walker)
抄送: netconf@ietf.org; Rohit R Ranade; Aijun Wang
主题: RE: Solicit comments on inline action capability for NETCONF

Hi Qin
Hi Walker,

From: Qin Wu, July 4, 2018 2:19 AM
发件人: Rohit R Ranade
发送时间: 2018年7月4日 14:01
收件人: Qin Wu
抄送: netconf@ietf.org<mailto:netconf@ietf.org>; Zhengguangying (Walker)
主题: RE: Solicit comments on inline action capability for NETCONF


[Qin]:Yes, invoking action on configuration datastore is our key use cases,e.g., batch operation on 100 interfaces and enable Interface statistics and
Then set MTU value to a specific interface. Enable interface statistics on 100 interfaces will happen first and then MTU value setup.
These operations have no conflict risk and can execute in any order in one transaction, it will be great to introduce this multi-sub operations in one transaction.
[Rohit R Ranade] But why must this happen in single transaction ? If done as two separate RPC what is the impact ?


[Qin]: Improve transaction efficiency is one of important motivations. Separate action from <edit-config> operation, you still need to handle action that is part of <config> element within
<edit-config> operation.

<Eric> Interesting thread.   Two questions:

(1) With multiple transactions in one, I initially read this as you might want to support the edit config failing if the action fails (i.e., an error coming result from the action on the operational datastore).  And the result is that the aggregate transaction would fail across datastores.

Now looking at your responses on this thread, it looks like that your use case is non-interdependent configuration actions.  Based on that, which of the following do you want to considering in scope?  And if only (a), you should likely add more to the scope statement.

(a) single datastore edit and actions, where each atomic edit will complete or fail independently
(b) single datastore edit and actions, where the full operation fails if any component fails

[Qin]: It depends error-options we select, I think we may support either (a) or (b). The error options are defined in section 7.2 of RFC6241.
(c) cross datastore edit and actions, where the full operation fails if any component fails

(2) Do you see any cases where the action operation must occur after the edit config?  I.e., the action depends on a successful edit config happening first.
[Qin]: Good question, before NMDA is introduced, we support converting learned configuration into static configuration, static configuration can be injected into <running> through <edit-config>,
In this case, we can use action to do such conversion and then use <edit-config> to edit the content into <running>.

Thanks,
Eric

In Some other cases when action is invoked in operational state datastore, we can use <operational> to get learned configuration and translate them into static configuration.
[Rohit R Ranade] We can still do this. We can get learned configuration from <operational>, and if need to translate to static we can always create such configuration in <running>

[Qin]:Have we already had standard mechanism to translate learned into static? I see none.

With Regards,
Rohit R Ranade

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Qin Wu
Sent: 04 July 2018 07:32
To: netconf@ietf.org<mailto:netconf@ietf.org>
Subject: [Netconf] Solicit comments on inline action capability for NETCONF

Hi, Folks:
We have posted inline action capability draft on Jun 28:
https://www.ietf.org/mail-archive/web/netconf/current/msg14823.html



One comment we received from the list is:

https://www.ietf.org/mail-archive/web/netconf/current/msg14863.html

The v-(01) is uploaded to address this comment.
Therefore we would like to draw you attention again on this draft

https://tools.ietf.org/html/draft-zheng-netconf-inline-action-capability-01
We would like to receive more review and feedback on this draft, thanks.

-Qin