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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
