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

[Andy Bierman <[e-mail]>]

On Fri, Sep 27, 2019 at 3:40 AM Rob Wilton (rwilton) <[e-mail]>
wrote:

> Hi,
>
> > -----Original Message-----
> > From: netmod <[e-mail]> On Behalf Of Schönwälder, Jürgen
> > Sent: 26 September 2019 19:35
> > To: Andy Bierman <[e-mail]>
> > Cc: [e-mail]
> > 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://www.jacobs-university.de/>
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
>