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

Andy Bierman <andy@yumaworks.com> Fri, 27 September 2019 03:42 UTC

Return-Path: <andy@yumaworks.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 78322120098 for <netmod@ietfa.amsl.com>; Thu, 26 Sep 2019 20:42:42 -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=ham 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 r_VK7tC3BAYz for <netmod@ietfa.amsl.com>; Thu, 26 Sep 2019 20:42:40 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 77FE312001A for <netmod@ietf.org>; Thu, 26 Sep 2019 20:42:39 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id j19so1062106lja.1 for <netmod@ietf.org>; Thu, 26 Sep 2019 20:42:39 -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=696v3bjwHclarHbPlLZXOdJU1dKkujAT4V3pF3yGhCQ=; b=KrzEw1GgBn4YSJrgCRkscgRoUlZnSNcl0iVZjJ1qlMOpAP9OyJH+Jdl+YciFLmRNVb QizCviF34Rjv62nEVd9oeo8m0xq1WumUEp6CfkeE+TrNYpKmZzxkgOrP9dCXUmYqt6Ty 8ZNsb3kMXTUCwivD49R5mRvgXU6E9VxCVMByvuutQpdq7ScSwXFFVoh71Z34IAJqrbLQ jUfhH13Ba2deoCr63CtYGIk3dFu0l3uOTPDPhTn/hI/IH2Ot0BuHu5xG+nxL0UPRWKh/ mrERKywsT3zWcID7e/3UAfP4oEx6kB8JdOAuxdFcOrhNv8pg5oyLoPkfycgxbbY9NC7o M7hQ==
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=696v3bjwHclarHbPlLZXOdJU1dKkujAT4V3pF3yGhCQ=; b=Xy9WJyJlSy6oFJFgQzvolXaMdtZ22AWnnaJArNEZfJwexmfp6adRRuM3hzXAc71OZR d5gcI/IM/owPbS1ILBI462/9hoNS9BH5m/kOZY138AogZLin3EdFe5aNH/w5QnvD+/l+ qBOhpHs6CZzGbf5eonH6XG6TD87e7SU3AwnDymijokeSklWNXfUiQilHIUzRXrpfVNN0 aikfeckgvrav2Bld7o2GuLBd6k5cC1JGHkRHwa3JHV485zoVAgnBN2kIjVBAaeTkdZsH 3MPJDtpgtJAyx/1TYxE3JevLE9oA3XCiONcEj/TW4l6WgISeApL7ACZOKpRoWI6Hb2fX F1cg==
X-Gm-Message-State: APjAAAXbjUlJ56/Mdb0oMs8wurSBhenUaB2SIIbgZjID5JfSDc38buzc dDf46fNvLP/o3NmGKYr9MzOuJ9tWFXqRqBlcujgEsQ==
X-Google-Smtp-Source: APXvYqwgoSkQmAb8sOxH1FsLwl+ZXh5VZ7t6Z2IZcKSlqOyDJ22lMqfIctS8KSD7nBmnETxySGEN27h0R+2uUEkA1Lo=
X-Received: by 2002:a2e:8684:: with SMTP id l4mr1182583lji.116.1569555757577; Thu, 26 Sep 2019 20:42:37 -0700 (PDT)
MIME-Version: 1.0
References: <87h84z4kmw.fsf@nic.cz> <20190926.085644.1268671875357328723.mbj@tail-f.com> <9bc06f9f3f1c87c79ccce4e1c4d40755c804875a.camel@nic.cz> <20190926.094526.272771637371098799.mbj@tail-f.com> <MN2PR11MB4366078636D6030398489551B5860@MN2PR11MB4366.namprd11.prod.outlook.com> <CABCOCHQzmDjH+7wqFmrSsnaD0T_Q1LPsDi0yuY9Ow2gSvef4SA@mail.gmail.com> <01c701d57485$400d8d40$4001a8c0@gateway.2wire.net> <CABCOCHRse2RJkoQ1r6pf+F4qP8MUn+4ypBY3M5zH+0QWoqBpuQ@mail.gmail.com> <20190926183514.6jxnybluwdubrzvy@anna.jacobs.jacobs-university.de>
In-Reply-To: <20190926183514.6jxnybluwdubrzvy@anna.jacobs.jacobs-university.de>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 26 Sep 2019 20:42:26 -0700
Message-ID: <CABCOCHSWt-v2PZm88_TvCfwBsveHF8z7NxbZDen5vxLWcm6Nkw@mail.gmail.com>
To: =?UTF-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= <J.Schoenwaelder@jacobs-university.de>
Cc: tom petch <ietfc@btconnect.com>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000062d09d059380ad27"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/kC8LmHUtN66GnXZxjqr4fOQjtyw>
Subject: Re: [netmod] =?utf-8?q?What=27s_the_problem_with_NMDA=3F_was_Re=3A_?= =?utf-8?b?562U5aSNOiDnrZTlpI06IFBsZWFzZSBjbGFyaWZ5IGltcGxlbWVudGF0aW9u?= =?utf-8?b?IGFib3V0IOKAmHdoZW7igJk=?=
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, 27 Sep 2019 03:42:43 -0000

On Thu, Sep 26, 2019 at 11:35 AM Schönwälder, Jürgen <
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).


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