Re: [netmod] schema mount and YANG library

[Ladislav Lhotka <[e-mail]>]

Robert Wilton <[e-mail]> writes:

> On 17/01/2018 16:40, Martin Bjorklund wrote:
>> Ladislav Lhotka <[e-mail]> wrote:
>
> <snip>
>
>>>> Ok.  I'm ok with keeping the inline case as it is.  However, I think
>>> I don't agree. The metadata annotation solves real issues.
>> One issue with the annotation is that since the schema might be
>> different in different datastores, it means that the client needs to
>> read the annotation in all datastores, and then fetch the schemas.  So
>> it is a bit more difficult to work with for a client.
> I'm still not convinced that I really understand all the arguments here:
>
> Using YLbis over YL seems to have obvious benefits to me, in that I 
> perceive that it gives a cleaner data model.  But I also understand 
> Lou's concerns - although its not clear to me whether Lou's primary 
> concern is timing, or the fact that implementations are forced to use
> YLbis.

Note that it is only the migration to YLbis that implies changes in the
appendices of LNE and NI. The metadata annotation for inline mount
points doesn't require any change in any existing draft I am aware of.

>
> I also agree with Juergen that from an YLbis authors perspective YLbis 
> is quite close.  I believe that the YANG model itself has been agreed 
> (at the interim meeting in Nov/Dec), and hence really what is left is 
> just tidying/enhancing the descriptive text in the document.
>
> I don't really understand the benefits of the metadata annotations. It

My take is this:

Section 3.2 currently requires that "every instance of the [inline]
mount point that exists in the parent tree MUST contain a copy of YANG
library data". This was indeed the original idea that however doesn't
work with NMDA.

Lou's suggestion was that for inline mount point instances in
configuration datastores, the (embedded) YANG library will be available
under the corresponding mount point instance in <operational>. The
problem with this is that the corresponding instance needn't always
exist because

- NMDA mentions situations (e.g pre-provisioning) where an instance in
  <intended> has no corresponding instance in <operational>

- Only "base" NMDA config datastores are required to keep a copy of
  their data in <operational>. Other datastores IMO needn't follow this
  rule, or the relationship with <operational> needn't be so
  straightforward.  

Lou argued that this is not a problem for LNE and NI, but I think it is
not sufficient provided that schema mount is intended as a general
mechanism.

The metadat annotation solves this. Moreover, it allows for keeping all
schema-related metadata in one place that we can possibly think of as a
metadata datastore.

A use-schema-type mount point will then have a leafref to the mounted
schema directly in the metadata (i.e. fixed at implementation time)
whereas every instance of an inline-type mount point supplies the
same leafref at run time via the annotation. This is IMO a much cleaner
architecture.  

> feels like this is going to be more hassle because a client will have to 
> query each datastore separately rather than getting the information in a 
> single operation.

But then the client would get schemas for all datastores, even those it
is not interested in.

Assume we have an inline mount point "root" (a container), and let's say
the schema for all NMDA config datastores is the same but <operational>
has a different schema. The *all* config datastores will contain just this
instance:

    <root schema-ref="root-schema">

and <operational> can have

    <root schema-ref="root-oper-schema">

Thanks to module sets in YLbis this can be expressed very efficiently
and I don't see how this could be a hassle for a client.

>
> A regular (without SM) NMDA NC/YANG server supports multiple datastores, 
> but that information is only exposed via one so them (i.e. 
> <operational>).  So, in a server supporting inline SM, it seems quite 
> natural to me for the mounted schema information to also only be 
> available via the mounted <operational>.  This seems to mirror the 
> standard NC/YANG+YL behavior, and also seems to naturally recurse if 
> required.

Not really. The difference is that the regular YL is unconditionally
present in a fixed location in <operational>. In contrast, to get the
embedded YL for an inline mount point instance in a config datastore, it
is necessary to determine a corresponding mount point instance in
<operational>, which is IMO not always possible. The metadata annotation
will point to the appropriate schema right away from the config datastore. 

>
> Hence, for me, I see the choice as:
> 1) do we publish the existing model now (perhaps also mark the draft as 
> experimental) followed by an updated draft with the NMDA compatible
> module?
> 2) do we publish both models in a single draft (e.g. with the existing 
> model in an appendix)?
> 3) do we only publish a single version of the draft with an NMDA 
> compliant solution.

I support #3.

Lada

>
> Thanks,
> Rob
>
>

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