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

[Andy Bierman <[e-mail]>]

On Thu, Oct 3, 2019 at 5:30 PM Qin Wu <[e-mail]> wrote:

>
>
> *发件人:* netmod [mailto:[e-mail]] *代表 *Andy Bierman
> *发送时间:* 2019年9月27日 11:42
> *收件人:* Schönwälder, Jürgen <[e-mail]>
> *抄送:* [e-mail]
> *主题:* 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 <
> [e-mail]> 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.
>
>
>


No.  The /modules-state subtree has status "deprecated" in RFC 8525.
It is not desirable to list non-NMDA only modules in the new /yang-library
so the deprecated tree will never go away as long as the server intends to
support non-NMDA clients.

NMDA has this MUST requirement:



   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 "foo" module will be listed in /yang-library and /modules-state.

The temporary "foo-state" module will be listed only in /modules-state.


(I don't see much value in implementing /yang-library but if think you need it

then go ahead ;-)



/js
>
>
>
> Andy
>
>
>


Andy


>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>
>