Re: [netconf] 答复: [netmod] pls clarify get operation

Andy Bierman <andy@yumaworks.com> Fri, 28 June 2019 15:05 UTC

Return-Path: <andy@yumaworks.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 7E4CE1203FA for <netconf@ietfa.amsl.com>; Fri, 28 Jun 2019 08:05:29 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 XLEgqZKmt1Oi for <netconf@ietfa.amsl.com>; Fri, 28 Jun 2019 08:05:26 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE981203F4 for <netconf@ietf.org>; Fri, 28 Jun 2019 08:05:05 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id y17so4220797lfe.0 for <netconf@ietf.org>; Fri, 28 Jun 2019 08:05:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7IJcUET9DHbQGKJCW8s4xeWb5va0SKG8eoEHh69Aoqk=; b=fwkPmiIqTW9J+GukcsM5XiZQVUXFrg0awhfM16Z9wPE12DbQLFCGamdaA/sY0+hyvy aKglAN1+fMrjEjzC9FTPDhxmf4vYPl4RJAD6MLZequuKmqbQzjTtN5mDM9DcESnfiwTU 7dcOackP0tnmWqgb6Liqe/mNBRfPIaBVMTx1b8nAlOfUo7Nu+CswkQHPYb2BlYzyDxFT 4rqZ4WgLWYJW5oHqQLBIvP3GwDabH12s60UsXm2uNU2/rSneSODmHro8zh0DvGD3VgGM FP8j+RXb2/yYGNvILzyVQJnldFs99I1g0HXktmrTg8v4eLSPaU7aOLC/Y9TgZiSI1evK joow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7IJcUET9DHbQGKJCW8s4xeWb5va0SKG8eoEHh69Aoqk=; b=LaIGDFzYhAp296KKd4KxX5J94rHhcRMl9IN0ZGdeSf3HwLuM4KV5wIlhfG30/wyo4N 9uKgkvPtRDA7CnkY2o83onUla8TnUiXOhsRixQ3iicZ0HKpCDfvlkdNBxDxDJGtlQc1e VuAV+H0SzsmPoEcqVGkyML/reyERVfxsTeXIw9l8h8qimNlY4D+icY1oDXo/etrbxYqX jWobN3zWFktAVNlAemClYFT8JV4l5RWj0LTSCvx9mXjHv3GPhPTpzRLY9x4AsPu56iMM Ir2QX0bQJgp3+rAVS1kH6nUMkIYkj6LpuotFfYBHp/oTqgU7EurgulwahZ19l9vc7u+k px4A==
X-Gm-Message-State: APjAAAVV3f9s/+LVzMTcsQKlIQL/3SfcekuuPLt6NERLdviq92wg+gh2 B2dx4Q2DvCrXivroi2pYErLu2ROvfEebMLHFd++Maw==
X-Google-Smtp-Source: APXvYqwU6uMlqHPlZEMUV+67xmQterfjJnYHsy2KnO1hizjZculoPuGfVEMiODH4tBDVWQG60XhcTSNNm0/FyVaO8/w=
X-Received: by 2002:ac2:514b:: with SMTP id q11mr5357042lfd.33.1561734303542; Fri, 28 Jun 2019 08:05:03 -0700 (PDT)
MIME-Version: 1.0
References: <5756FB984666AD4BB8E1D63E2E3AA3D001ED5E20@dggemm513-mbx.china.huawei.com> <BYAPR11MB2631D3A01E398ADDBB294588B5FC0@BYAPR11MB2631.namprd11.prod.outlook.com> <20190628085014.ljxh73fcmiu6iqx7@anna.jacobs.jacobs-university.de> <5756FB984666AD4BB8E1D63E2E3AA3D001ED6082@dggemm513-mbx.china.huawei.com> <BYAPR11MB2631B6688BB094D93BACAD6AB5FC0@BYAPR11MB2631.namprd11.prod.outlook.com> <5756FB984666AD4BB8E1D63E2E3AA3D001ED63C8@dggemm513-mbx.china.huawei.com>
In-Reply-To: <5756FB984666AD4BB8E1D63E2E3AA3D001ED63C8@dggemm513-mbx.china.huawei.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 28 Jun 2019 08:04:52 -0700
Message-ID: <CABCOCHQmZzvHzOPnQR1MgvaXZod2=uH8wmk8SpsOk4h=MzZv+Q@mail.gmail.com>
To: "Fengchong (frank)" <frank.fengchong@huawei.com>
Cc: "Rob Wilton (rwilton)" <rwilton@cisco.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "netmod@ietf.org" <netmod@ietf.org>, "Zhangwei (SS)" <zhangwei70@huawei.com>, Yangang <yangang@huawei.com>, "netconf@ietf.org" <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000658b5f058c639a5d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/m6maX1L0ofFPyMfvcJ8YGX0wCdc>
Subject: Re: [netconf] =?utf-8?b?562U5aSNOiBbbmV0bW9kXSBwbHMgY2xhcmlmeSBnZXQg?= =?utf-8?q?operation?=
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: Fri, 28 Jun 2019 15:05:30 -0000

On Fri, Jun 28, 2019 at 7:09 AM Fengchong (frank) <
frank.fengchong@huawei.com> wrote:

> Hi Rob,
>     I think IETF solution: migrate to NMDA is unrealistic. The cost of
> migration to NMDA is too expensive, If the entire industry migrates to
> NMDA, the time will be long.
>     This will delay the deployment of the IETF model in the industry.
>     Anyway, even if vendor implements NMDA, the network manager/
> controller or client tools may not support NMDA client.
>     A non-NMDA client only support get/get-config, it still has no way to
> retrieve system-controlled data.
>
>

Although it would have been possible to augment the existing <get>
operation, it is much cleaner
to create a new operation instead. (From standards and implementation POV).

There is a significant amount of work needed to support NMDA in a server.
This effort would be the same whether <get> or <get-data> was used.
The protocol work is the tip of the iceberg.  Updating all the
instrumentation callbacks to
return operational values is the real work -- and exactly the same no
matter what protocol
solution is used. Client complexity is mostly related to the new YANG
library.

Starting over on a new solution would only take longer to deploy.


Andy




>     Generation config false copy for IETF YANG model is not reasonable,
> because published IETF standard YANG should not be changed, moreover, this
> is not friendly to the client or the server.
> -----邮件原件-----
> 发件人: Rob Wilton (rwilton) [mailto:rwilton@cisco.com]
> 发送时间: 2019年6月28日 17:18
> 收件人: Fengchong (frank) <frank.fengchong@huawei.com>om>; Juergen
> Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> 抄送: netconf@ietf.org; netmod@ietf.org; Zhangwei (SS) <
> zhangwei70@huawei.com>
> 主题: RE: [netmod] pls clarify get operation
>
> Hi Frank,
>
> You can't just change definitions in RFCs.  It breaks all existing
> clients/servers.  Besides, what you suggest doesn't really work (path
> clashes between configuration and operational state), unless you return two
> trees ... which starts to look extremely similar to the NMDA architecture
> ...
>
> IETF has already explored this problem and there is already a published
> IETF solution to the problem that you describe: Migrate to NMDA.  The NMDA
> architecture has many other benefits as well (E.g. allows for templating,
> inactive configuration, dynamic configuration, consistent OIR handling).
>
> Thanks,
> Rob
>
>
> -----Original Message-----
> From: Fengchong (frank) <frank.fengchong@huawei.com>
> Sent: 28 June 2019 10:07
> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>de>; Rob
> Wilton (rwilton) <rwilton@cisco.com>
> Cc: netconf@ietf.org; netmod@ietf.org; Zhangwei (SS) <
> zhangwei70@huawei.com>
> Subject: 答复: [netmod] pls clarify get operation
>
> Should we change the definition of get operation? Like this, get operation
> can retrieve all running operational data including running configuration,
> system configuration.
> Otherwise, we have no way to get the information of system-controlled data
> according a NMDA-style YANG module(because has no config false copy )
> unless we implement NMDA.
> -----邮件原件-----
> 发件人: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> 发送时间: 2019年6月28日 16:50
> 收件人: Rob Wilton (rwilton) <rwilton@cisco.com>
> 抄送: Fengchong (frank) <frank.fengchong@huawei.com>om>; netconf@ietf.org;
> netmod@ietf.org; Zhangwei (SS) <zhangwei70@huawei.com>
> 主题: Re: [netmod] pls clarify get operation
>
> Yes, both the NETCONF <get> operation and the RESTCONF GET on the unified
> view of the underlying datastores have limitations and a solution in
> situations where these limitations hurt is to move towards NMDA.
>
> /js
>
> On Fri, Jun 28, 2019 at 08:38:38AM +0000, Rob Wilton (rwilton) wrote:
> > Hi Frank,
> >
> > Pre NMDA:
> >
> >   *   You have a the <running> datastore, along with some others like
> <candidate> and <startup> that you can ignore for the purposes of this
> discussion.
> >   *   The <running> datastore can only contains data for schema nodes
> that are marked as “config true” in YANG (i.e. “rw” in your tree output
> below).
> >   *   The system may also have some operational state data that is
> marked as “config false” in YANG (i.e. “ro” in your tree output below).
> >
> > The NETCONF <get-config> operation returns the contents of the <running>
> datastore.
> > The NETCONF <get> operation returns the contents of the <running>
> datastore combined with all the operational state as well.  Filters can be
> applied to return a subset of the data.
> >
> > Regarding your question about user created configuration vs system
> created configuration, it depends on whether the devices instantiates the
> configuration in <running> or not.  If it does, then it would be returned
> in <get> and <get-config> operations.  If it doesn’t then it would not.
> Different vendors/devices will likely implement this in different ways.
> >
> > Generally, I think that <running> should only contain the configuration
> explicitly configured by the operator’s systems.  But this means that there
> isn’t a clean way to represent system created configuration or applied
> configuration, unless you make a config false copy of every config true
> node in YANG.  This is approach that was taken by the original IETF YANG
> models (e.g. RFC 7223) before they were superseded by NMDA, and also the
> OpenConfig YANG models (but using a different structure – which also
> struggles to cleanly represent system created configuration data).
> >
> > The NMDA architecture was written to solve this problem in a clean way
> without requiring duplication in the YANG data models.
> >
> > Hopefully this helps clarify.
> >
> > Thanks,
> > Rob
> >
> >
> > From: netmod <netmod-bounces@ietf.org> On Behalf Of Fengchong (frank)
> > Sent: 28 June 2019 04:29
> > To: netconf@ietf.org; netmod@ietf.org
> > Cc: Zhangwei (SS) <zhangwei70@huawei.com>
> > Subject: [netmod] 答复: pls clarify get operation
> >
> > Hi all,
> >
> >      Pls clarify this question. I have been confused for a long time.
> >
> > ________________________________
> > 华为技术有限公司 Huawei Technologies Co., Ltd.
> > [Company_logo]
> > 个人签名:冯冲
> > 手 机:13776612983
> > 电子邮件:frank.fengchong@huawei.com<mailto:frank.fengchong@huawei.com>
> > 公司网址:www.huawei.com<http://www.huawei.com>
> > ________________________________
> >  本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁
> > 止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中
> > 的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
> > This e-mail and its attachments contain confidential information from
> > HUAWEI, which is intended only for the person or entity whose address
> > is listed above. Any use of the information contained herein in any
> > way (including, but not limited to, total or partial disclosure,
> > reproduction, or dissemination) by persons other than the intended
> > recipient(s) is prohibited. If you receive this e-mail in error,
> > please notify the sender by phone or email immediately and delete it!
> >
> > 发件人: Fengchong (frank)
> > 发送时间: 2019年6月27日 9:59
> > 收件人: 'netconf@ietf.org' <netconf@ietf.org<mailto:netconf@ietf.org>>;
> > netmod@ietf.org<mailto:netmod@ietf.org>
> > 抄送: Yangshouchuan
> > <yangshouchuan@huawei.com<mailto:yangshouchuan@huawei.com>>; Zhangwei
> > (SS) <zhangwei70@huawei.com<mailto:zhangwei70@huawei.com>>
> > 主题: pls clarify get operation
> >
> > Hi all,
> > In RFC6241, get operation is defined as:
> > 7.7<https://tools.ietf.org/html/rfc6241#section-7.7>.7>.  <get>
> >
> >    Description:  Retrieve running configuration and device state
> >
> >       information.
> > This description is too simply, so I think it should be clarified.
> >
> > The case is: a data node modelled by one yang can be configured by user,
> but also can be created/modified by system or other protocols. If client
> issues get operation to retrieve this node,
> >           The data is created/modified by system or other protocols
> SHOULD be returned?
> >           For example:
> >           Rib can be configured by user and also can be created by
> routing protocols. In RFC 8349, the rib list is defined as:
> >
> >
> >
> >       +--rw ribs
> >
> >          +--rw rib* [name]
> >
> >             +--rw name              string
> >
> >             +--rw address-family?   identityref
> >
> >             +--ro default-rib?      boolean {multiple-ribs}?
> >
> >             +--ro routes
> >
> >             |  +--ro route*
> >
> >             |        ...
> >
> >             +---x active-route
> >
> >             |  +---w input
> >
> >             |  |  +---w v4ur:destination-address?   inet:ipv4-address
> >
> >             |  |  +---w v6ur:destination-address?   inet:ipv6-address
> >
> >             |  +--ro output
> >
> >             |        ...
> >
> >             +--rw description?      string
> >
> >
> >
> >        If client issued get operation to retrieve ribs from non-NMDA
> device, rib instance created by routing protocols should be returned?
> >
> >        Another associated question: If client issued get-config
> operation from non-NMDA device, only user-controlled rib instance should be
> returned?
> >
>
>
>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
>
> --
> 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
> https://www.ietf.org/mailman/listinfo/netconf
>