Re: [netmod] schema mount and YANG library

[Ladislav Lhotka <[e-mail]>]

On Wed, 2018-01-17 at 09:09 -0500, Lou Berger wrote:
> 
> On 1/17/2018 1:59 AM, Ladislav Lhotka wrote:
> ...
> > > > > > > I think
> > > > > > > it is incumbent upon those revisiting past/closed WG decisions (in
> > > > > > > this case, inline schema being represented by YL) to argue why the
> > > > > > > decision needs to be revisited.
> > > > > > 
> > > > > > I'm repeating my self: b/c the current solution doesn't work well
> > > > > > with
> > > > > > the NMDA.
> > > > > 
> > > > > I simply don't understand how YL-bis works at the root node but
> > > > > doesn't work equally at an inline mount point.  Can you elaborate?
> > > > 
> > > > With NMDA, a server may have one schema for the config datastore and
> > > > another one for operational (one is a superset of the other).  A
> > > > mounted YL can only be present in operational.  Thus, there's no way a
> > > > client can learn the schema for config.
> > > 
> > > If the LNE mounted the full YL-bis at the mount point then you would
> > > have the list of datastores, and the schema associated with each
> > > datastore.  Of course, this would only be available in operational, but
> > > that is the same as a regular server support YL-bis.
> > 
> > YL-bis is different in that it is in fact metadata even though we call it
> > state
> > data.
> 
> I couldn't agree more.  YL and SM are server metadata and are 
> independent of any DS.  They could be accessed via any (as others have 
> suggested), but we are currently choosing to access if via operational 
> state.  With NMDA, I think personally think server meta data should have 
> it's own DS.  This discussion has convinced me that the current proposed 
> alternative, of accessing as operational data is flawed and even access 
> via *any* DS is preferable.

Yes, I would support an extra datastore.

> 
> > In any case, no matter what datastores the server has, YL-bis is the
> > single well-known location from which the schema of all datastores can be
> > retrieved.
> 
> That's a nice idea, but as was discussed in december, the direction 
> being taken doesn't include SM so this statement isn't *currently* true.

I assume SM is also part of metadata, so it would be in the same datastore as
YL.

> 
> > 
> > We could refer to <operational> as the place from which the mounted schemas
> > of
> > NMDA-standard config datastores can be retrieved (except for special cases,
> > one
> > is discussed below). But if there is another config datastore (e.g. dynamic)
> > with an inline mount point instance, it is unclear where to look for the
> > mounted
> > schema.
> 
> Why?  Is it unclear where to look for YL-bis in this case?  Why is SM 
> any different than YL?

NMDA requires that standard config data be also in <operational>, so if we have
a mount point instance in <intended>, there is (mostly) a corresponding instance
in <operational>, which is the place where the embedded YL can be found. I don't
think other non-standard datastores necessarily have this relationship with
<operational>.

> 
> >   With my proposal, the mount point instance will be annotated with
> > @schema-ref that points to a schema in the top-level YL.
> 
> right and as we thrashed out the last time we had discussed this with 
> the whole WG, having inline schema available at the top level was not 
> the preferred solution.

Because we didn't have the metadata annotation that can now refer from any
inline mount point instance to a schema that is placed at the top level. It is
just a simple indirection.

> 
> > 
> > > I thought that the problem with the current solution and NMDA, was that
> > > there is no way to find out what the LNE schema is if the LNE isn't
> > > booted, and hence isn't providing <operational>.  But I'm not sure what
> > > issues that actually causes.  E.g. does it cause issues with
> > > pre-configuration of the LNE?
> > 
> > The issue that this causes is that the schema for the pre-configured LNE
> > isn't
> > known and validity of <intended> is unclear.
> 
> Please elaborate on what you see here as a problem.  Those working on 
> LNE's (including myself) don't see an issue here.

Assume the "root" mount point for LNE is inline. Can you have a pre-provisioned
configuration for a LNE entry? If so, then I assume there is no corresponding
LNE entry in <operational>. If this is correct, then I don't see from where you
get the embedded YL instance. That is, <intended> may contain

  "ietf-logical-network-element:logical-network-element": [
    { "name": "foo",
      "root": { ... pre-provisioned config ... }
    },
    ...
  ]

But if the "foo" LNE isn't booted, then there is no "foo" entry in
<operational>, i.e. also no corresponding instance of the "root" mount point.

Is this reasoning flawed?

Lada

> 
> Lou
> > 
> > Lada
> > 
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67