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

Andy Bierman <andy@yumaworks.com> Fri, 27 September 2019 16:30 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 3D6AF12099E for <netmod@ietfa.amsl.com>; Fri, 27 Sep 2019 09:30:46 -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 o_gy8wYeCzwg for <netmod@ietfa.amsl.com>; Fri, 27 Sep 2019 09:30:43 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 BAA4B1209A4 for <netmod@ietf.org>; Fri, 27 Sep 2019 09:30:42 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id y3so3107765ljj.6 for <netmod@ietf.org>; Fri, 27 Sep 2019 09:30:42 -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=TJvGeOrKObLnDzXrvPk7/+aj7FREqAvdtmJQNp24wrw=; b=SQtjRWNkn+pYMu3VkqLdtloO4ZE8qZo+yG0/JOOqjtfduNGjy0S+RB3pk5u6CrAGzc TS0VXvtxXL7l2MiEtRnOKxNgKtBSjZXUMbOVsPnCmPAKPaIscQDeaoWX759b1JUm5q+s QIuaMt9Ago3uEWjcrhyKoXc5AFO9EFf6c4x7l2+RhSXN06uxw8epwR3uwta2sSyrU+bd mYmsetGrvC9EmAG5merLb68dv5SK9zOXyUEeddYYpTw0NhQD+YZaJEhHQAJvs8m38ai0 dd5LU+RpMY9K2QpsTql8P+/UfJc+ATIWkRUGWR/YDg91NdOlR2Naxkk5QcvYDksh7coQ h/5Q==
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=TJvGeOrKObLnDzXrvPk7/+aj7FREqAvdtmJQNp24wrw=; b=de2IGzQQZ/YB5dxbUt0WyY3gqiBcN2TMh3rWGIKFsDyU1/glJO+nczWRj8r7hvDxKU i1PxH9w33DB5JVQhJcSUiQ64XGH6IyceEbvkK/ZTOo3wtckHEinMPnQiwA//fTEtZn5D x7ug6hjs2nvphp04nWDyVB8GE9WjHE/6NXWu7TdDQMSghHJj+HWIBQUg0Jtyroxd1lx9 L9W80K2JLmzggDNpdBWA8WuQgJtZLXSsHvLPsC+y/4YauDPq3gLaRUsIjH45kyJQ+VDV O7Ikw3AulPXB9xICJbjZ1BGCdxLkDDNiIyGRtWG2NjvZhgFW5WegFPtoFQIFFDX2bX3Y xE0Q==
X-Gm-Message-State: APjAAAUZG04evHKNCJ+FcMo8jjpqDHOwxV6/wL2txD2MDskdOI782dFq iunehENyISJiKQhAdGvP3JKo0t8DSyVgZPIZTF9sJQ==
X-Google-Smtp-Source: APXvYqxIrnPMksQ16YQPbjrSXDql5e/N6Hv5qCLnHhI275cKV+KZtXBGs6+1U95sIFsasFHQFamC4Itot3I/TfD25qs=
X-Received: by 2002:a05:651c:104b:: with SMTP id x11mr3605472ljm.218.1569601840809; Fri, 27 Sep 2019 09:30:40 -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> <MN2PR11MB4366886642F8F9693F0A22F2B5810@MN2PR11MB4366.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB4366886642F8F9693F0A22F2B5810@MN2PR11MB4366.namprd11.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 27 Sep 2019 09:30:29 -0700
Message-ID: <CABCOCHQhRQWo_PhMV=RtSm76wk3U5SO0tNf-NrdBd4=VjHbJ-Q@mail.gmail.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
Cc: =?UTF-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= <J.Schoenwaelder@jacobs-university.de>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000291c3405938b688d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/mOXa5SKOR9aZFcwXHiEs0ZpKj-I>
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 16:30:46 -0000

On Fri, Sep 27, 2019 at 3:40 AM Rob Wilton (rwilton) <rwilton@cisco.com>
wrote:

> Hi,
>
> > -----Original Message-----
> > From: netmod <netmod-bounces@ietf.org> On Behalf Of Schönwälder, Jürgen
> > Sent: 26 September 2019 19:35
> > To: Andy Bierman <andy@yumaworks.com>
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] What's the problem with NMDA? was Re: 答复: 答复:
> > Please clarify implementation about ‘when’
> >
> > 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.
>
> Indeed.  For non-NMDA, even if /foo/bar and /foo-state/bar are the same
> type in the published model, there is no guarantee that a server won't
> deviate the /foo-state/bar leaf to change its type to differ from /foo/bar,
> and this is allowed.
>
> But NMDA is aiming to be better than this.  One of the fundamental aims is
> that the config and operational values should be comparable, on the same
> relative datastore path and have the same type.
>
> That is why RFC 8342 does not allow a server to change the type of a data
> node in operational, they are only allowed to remove it to indicate that it
> is not supported.
>
> RFC 8342, section 5.3 The Operational State Datastore(operational):
>
>    The datastore schema for <operational> MUST be a superset of the
>    combined datastore schema used in all configuration datastores,
>    except that configuration data nodes supported in a configuration
>    datastore MAY be omitted from <operational> if a server is not able
>    to accurately report them.
>
> The intention here is:
>  - If a server does a deviate "add|replace|delete" deviation on a config
> data node then that same deviation MUST be applied to all datastores that
> contain that data node in their schema (or otherwise operational cannot be
> a superset).
>  - A server MAY have operational datastore specific deviate
> "not-supported" deviations.  The purpose of this is meant to help
> migration, ideally servers would not have these deviations.
>
> Hence, a client/server can construct a single "superset" schema for the
> device, and then the schema for each individual datastore must be a subset
> of that "superset" schema (with the added requirement that there is only a
> single schema for all conventional datastores).
>
>
IMO the new YANG library is the most disruptive and complex way possible to
express
a simple capability "operational value for configuration object foo
supported or not".
I prefer the capabilities module approach in
https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-04
Deprecating the YANG library and starting over is kind of a
bull-in-the-china-shop
approach to advertising some server capabilities.


I appreciate that the new YANG library structurally allows invalid schemas
> to be defined, but then so does the old YANG library as well.  E.g. there
> is nothing in the old YANG library structure to prevent a server from
> reporting that it implements two different revisions of the same YANG 1.1
> module.
>
> Thanks,
> Rob
>
>

Andy


>
> >
> > > 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.
> >
> > /js
> >
> > --
> > 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/>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>