Re: [netmod] What's the problem with NMDA? was Re: RE: RE: Please clarify implementation about ‘when’

Qin Wu <bill.wu@huawei.com> Fri, 04 October 2019 00:30 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27EA1208A4 for <netmod@ietfa.amsl.com>; Thu, 3 Oct 2019 17:30:12 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 m-Tw2JADqz_3 for <netmod@ietfa.amsl.com>; Thu, 3 Oct 2019 17:30:08 -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 90CE8120889 for <netmod@ietf.org>; Thu, 3 Oct 2019 17:30:08 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 568CFCBDEB954AF8EAA3; Fri, 4 Oct 2019 01:30:06 +0100 (IST)
Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 4 Oct 2019 01:30:05 +0100
Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.72]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0439.000; Fri, 4 Oct 2019 08:30:02 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Andy Bierman <andy@yumaworks.com>, =?utf-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= <J.Schoenwaelder@jacobs-university.de>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: =?utf-8?B?W25ldG1vZF0gIFdoYXQncyB0aGUgcHJvYmxlbSB3aXRoIE5NREE/IHdhcyBS?= =?utf-8?B?ZTogUkU6IFJFOiBQbGVhc2UgY2xhcmlmeSBpbXBsZW1lbnRhdGlvbiBhYm91?= =?utf-8?B?dCDigJh3aGVu4oCZ?=
Thread-Index: AdV6SwHJ5djgEz41Ro6B0xRmwbQx9A==
Date: Fri, 4 Oct 2019 00:30:01 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAA934036B@dggeml511-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.45.28.11]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA934036Bdggeml511mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/hRLChCi1Smg-YooT_j6BvdlVPeY>
Subject: Re: [netmod] =?utf-8?q?What=27s_the_problem_with_NMDA=3F_was_Re=3A_R?= =?utf-8?q?E=3A_RE=3A_Please_clarify_implementation_about_=E2=80=98when?= =?utf-8?b?4oCZ?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Oct 2019 00:30:13 -0000

发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Andy Bierman
发送时间: 2019年9月27日 11:42
收件人: Schönwälder, Jürgen <J.Schoenwaelder@jacobs-university.de>
抄送: netmod@ietf.org
主题: Re: [netmod] What's the problem with NMDA? was Re: 答复: 答复: Please clarify implementation about ‘when’



On Thu, Sep 26, 2019 at 11:35 AM Schönwälder, Jürgen <J.Schoenwaelder@jacobs-university.de<mailto:J.Schoenwaelder@jacobs-university.de>> wrote:
On Thu, Sep 26, 2019 at 10:44:01AM -0700, Andy Bierman wrote:

> The IETF has completely punted the problem of converting data for a
> configuration datastore to the schema tree for <operational>.

I am not sure. The <operational> model consists of the applied
configuration plus any config false extras. NMDA simplifies things
since there is now a single tree structure instead of two if you have
to handle models where applied configuration can be different than
intended config. If I configure /foo/bar in <running>, I can check
/foo/bar in <operational> whether it exists and matches what I
configured.

> Deviations may be different.  A leaf may be string in 1 tree and
> decimal64 in the other. There is an incorrect assumption that
> software developers will deal with these corner-cases (correctly and
> consistently).

Not really true for applied config. And with non NMDA, there is no
guarantee either that /foo/bar and /foo-state/bar use the same type
and semantics.


different deviation modules in each module-set are allowed in the YANG library.
That makes it kind of mandatory for the client to support it, or choose to
not conform to the standard.




> The other big problem is an untested NMDA transition strategy that is not
> well understood by vendors.
> Should non-NMDA (/foo-state) be visible to <get-data> or just <get>?

Perhaps there is more explanation necessary. The idea here is that an
NMDA client should not bother to search for /foo-state, it should send
a <get> for /foo/state in operational.

Yes, NMDA requires updates to clients. Whether these are visible or in
which form they are visible to application logic likely depends on the
client design. But yes, NMDA is not for free for clients. But once you
have updated, we believe NMDA actually makes things simpler and more
consistent.

> Using the YANG library to separate the modules relies on the assumption that
> the client is capable of managing each datastore independently (instead of
> 1 schema tree per server).

Yes, YANG library can express pretty complex server model
organizations.  This does not mean that all server have to use server
model organizations.  I assume that also many clients will not be
interested to understand the entire server model, they likely want to
check the existance of only those pieces that they care about.

I am not trying to revive debates on the value of NMDA or the solution,
but more flexibility for the server means more complexity for the client.
IMO this is contributing to the slow adoption of NMDA.

I hope the industry will find a transition solution (NMDA Lite) that fully supports
the protocol operations, but uses the same module-set(s) in the YANG library
for all datastores.  If this is the expected norm for servers then clients that support it
will work.  (I would like to hear about even one NMDA implementation
that supports complex YANG libraries).

[Qin]: Should Non-NMDA client fall back to RFC7895 YANG library or adopt new YANG library in RFC8525 and assume same module-set(s), schema for all datastores?
RFC7895 has already been obsoleted.

/js

Andy


--
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/>