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

Robert Wilton <rwilton@cisco.com> Thu, 19 July 2018 12:07 UTC

Return-Path: <rwilton@cisco.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 61D9D1294D7 for <netconf@ietfa.amsl.com>; Thu, 19 Jul 2018 05:07:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 sX7wEX6y7ZWG for <netconf@ietfa.amsl.com>; Thu, 19 Jul 2018 05:06:58 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7C3127332 for <netconf@ietf.org>; Thu, 19 Jul 2018 05:06:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17325; q=dns/txt; s=iport; t=1532002017; x=1533211617; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=xZsEioliECBDtj70vx+KliHthtIv2LjVZTAbAW4vFrk=; b=hGzeUo3PizW9OdR4JOfn//hqyh5rflUlDN0QYNFsqyVc5+7Hs2IhJ0KP 2NZD2xTH3xRtgQmB36k9IxMHt5W1OvmHhBUkU7IcJCA8k3LpqLKa9kkX3 LuB5FGl6wUDYmuHUCs8QtAOfQCFfWC5HxevSkMvYUWgBaco8ifn3lz2gz s=;
X-IronPort-AV: E=Sophos;i="5.51,374,1526342400"; d="scan'208,217";a="5279380"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2018 12:06:56 +0000
Received: from [10.61.241.77] ([10.61.241.77]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w6JC6tTN000731; Thu, 19 Jul 2018 12:06:55 GMT
To: Qin Wu <bill.wu@huawei.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <B8F9A780D330094D99AF023C5877DABA9AF56E33@nkgeml513-mbx.china.huawei.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <48099631-578b-4ab8-c775-2bc9dea58bb0@cisco.com>
Date: Thu, 19 Jul 2018 08:06:55 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA9AF56E33@nkgeml513-mbx.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------94C1EC3E11ACA9175D937A8F"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.61.241.77, [10.61.241.77]
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/4y8PlSXsfTdZy7GNamQAgtwbg2M>
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: Thu, 19 Jul 2018 12:07:00 -0000

Hi Qin,

On 19/07/2018 07:51, Qin Wu wrote:
>
> Hi, Robert:
>
> *发件人:*Robert Wilton [mailto:rwilton@cisco.com]
> *发送时间:*2018年7月17日20:09
> *收件人:*Qin Wu <bill.wu@huawei.com>; netconf@ietf.org
> *抄送:*Eric Voit (evoit) <evoit@cisco.com>
> *主题:*Re: [Netconf] Solicit comments on inline action capability for 
> NETCONF
>
> Hi Qin,
>
> Having read this draft, I can understand what the draft is proposing, 
> but I don't currently understand why this is useful.  Specifically, I 
> don't find the example that is in the draft as compelling.  If the 
> desire is to set the MTU and enable the interface as one configuration 
> operation, then wouldn't the client just configure both mtu and 
> enabled leaves at the same time.  Why is a separate action required 
> here to enable the interface?
>
> So I'm struggling to think of actions that apply to configuration 
> datastores where the same behaviour cannot just be achieved via a 
> simple configuration manipulation.  One use case could be wanting to 
> repeat the same configuration on many interfaces at the same time, but 
> for this, I think that a configuration templating solution would be 
> preferable rather than using actions, and a templating would probably 
> just reused edit-config/edit-data.  So, if you have some other more 
> concrete examples of actions that apply to configuration datastores, 
> that might be helpful.
>
> [Qin]: Good point, but I am not sure action and configuration 
> templating can always exchangeable and serve the same purpose.
>
Sure, so please can you provide the example of where it isn't 
exchangeable, so that can be discussed/evaluated.

> Another question (which I think is similar to the one that Eric has 
> also asked) is whether to have transactions that mix configuration 
> operations and action operations on <operational>.  E.g. perhaps 
> enable an interface and reset the counters at the same time, or 
> perform some config change and establish a dynamic subscription at the 
> same time.  But I question how robust this would end up being (I'm not 
> generally a fan of distributed transactions - they never seem to be as 
> robust as they claim to be).  Perhaps one for future thought and 
> discussion.
>
> [Qin]: we are not looking for complicating transaction, we are not 
> looking for multiple operations leading to unexpected consequence. The 
> case we are focusing on is when action can be used with other 
> operation in the compatible way,
>
So, why can't the NMS or controller just sequence these actions?

> The idea will be close to workflow handling. Operation can be arranged 
> in sequence. Maybe have other cases.
>
OK, but please can you concrete examples of what is not working today.  
E.g. what actual system operation is being performed that either doesn't 
work today, or is not reliable, or is too complex, and would benefit 
from this.

Thanks,
Rob

> Thanks,
> Rob
>
> On 03/07/2018 22:01, Qin Wu wrote:
>
>     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
>
>
>
>
>     _______________________________________________
>
>     Netconf mailing list
>
>     Netconf@ietf.org <mailto:Netconf@ietf.org>
>
>     https://www.ietf.org/mailman/listinfo/netconf
>