Re: [netmod] schema mount and YANG library

[Ladislav Lhotka <[e-mail]>]

On Wed, 2018-01-17 at 17:40 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka <[e-mail]> wrote:
> > On Wed, 2018-01-17 at 17:18 +0100, Martin Bjorklund wrote:
> > > Lou Berger <[e-mail]> wrote:
> > > > 
> > > > 
> > > > On January 17, 2018 9:42:43 AM Martin Bjorklund <[e-mail]>
> > > > wrote:
> > > > 
> > > > > Lou Berger <[e-mail]> wrote:
> > > > > > 
> > > > > > 
> > > > > > On 1/17/2018 3:20 AM, Martin Bjorklund wrote:
> > > > > > > Lou Berger <[e-mail]> wrote:
> > > > > > > > 
> > > > > > > > On 1/16/2018 11:15 AM, Robert Wilton wrote:
> > > > > > > > > On 16/01/2018 15:50, Martin Bjorklund wrote:
> > > > > > > > > > Lou Berger <[e-mail]> wrote:
> > > > > > > > > > > On 1/16/2018 10:13 AM, Martin Bjorklund wrote:
> > > > > > > > > > > ... (trimming to topic)
> > > > > > > > > > > > > > > > > > > rejectected by the WG multiple times. 
> FWIW
> > > > > > > > > > > > > > > > > > > there are drafts
> > > > > > > > > > > > > > > > > > > already
> > > > > > > > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > No at all. The first and last time I
> proposed
> > > > > > > > > > > > > > > > > > this was on 15
> > > > > > > > > > > > > > > > > > December
> > > > > > > > > > > > > > > > > > 2017:
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > https://www.ietf.org/mail-archive/web/netmod
> /cur
> > > > > > > > > > > > > > > > > > rent/msg19753.html
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Oh, I certainly would call you proposing that
> the
> > > > > > > > > > > > > > > > > schema for
> > > > > > > > > > > > > > > > > inline
> > > > > > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > part of the rest of the schema Mount module
> well
> > > > > > > > > > > > > > > > > before
> > > > > > > > > > > > > > > > > that. I'm
> > > > > > > > > > > > > > > > > sure
> > > > > > > > > > > > > > > > > I can dig up mail / slides it really
> necessary...
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > I don't think this has been proposed before. 
> All
> > > > > > > > > > > > > > > > previous
> > > > > > > > > > > > > > > > proposals
> > > > > > > > > > > > > > > > were basically variants on what is now "use-
> schema", 
> > > > > > > > > > > > > > > > which works
> > > > > > > > > > > > > > > > fine
> > > > > > > > > > > > > > > > when all instances have the same schema.  This
> new
> > > > > > > > > > > > > > > > proposal
> > > > > > > > > > > > > > > > solves
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > issue with different schemas in different
> instances.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I thought the previous proposals that as well, so
> > > > > > > > > > > > > > > don't see
> > > > > > > > > > > > > > > material
> > > > > > > > > > > > > > > difference - at least from the usage standpoint. I
> > > > > > > > > > > > > > > also don't see
> > > > > > > > > > > > > > > why
> > > > > > > > > > > > > > > the previous arguments that resulted in consensus
> for
> > > > > > > > > > > > > > > using Yang
> > > > > > > > > > > > > > > Library underneath the an in line Mount Point
> don't
> > > > > > > > > > > > > > > apply.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > B/c it doesn't work well with the NMDA.  You can't
> mount
> > > > > > > > > > > > > > yang
> > > > > > > > > > > > > > library
> > > > > > > > > > > > > > in the configuration datastores; it has to be
> mounted in
> > > > > > > > > > > > > > operational.
> > > > > > > > > > > > > > With meta-data, you can actually report the correct
> > > > > > > > > > > > > > schema even in
> > > > > > > > > > > > > > running.  (This is actually true also for pre-NMDA
> > > > > > > > > > > > > > systems).
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Understood and agree there is nothing new here and the
> > > > > > > > > > > > > current
> > > > > > > > > > > > > version
> > > > > > > > > > > > > of SM (including inline) has the same limitation as
> > > > > > > > > > > > > rfc7895, and I'd
> > > > > > > > > > > > > expect it to behave the same once we have rfc7985bis
> -- in
> > > > > > > > > > > > > fact the
> > > > > > > > > > > > > inline case "just works" with YL-bis as defined today.
> > > > > > > > > > > 
> > > > > > > > > > > Martin,
> > > > > > > > > > > 
> > > > > > > > > > > you didn't respond to this point.
> > > > > > > > > > 
> > > > > > > > > > I agree, it works for non-NMDA servers. But see below.
> > > > > > > > > > 
> > > > > > > > > > > > > The argument I recall being the key point on inline
> was
> > > > > > > > > > > > > handling the
> > > > > > > > > > > > > large variety of possible different implementation
> > > > > > > > > > > > > approaches for
> > > > > > > > > > > > > modules using inline.
> > > > > > > > > > > > 
> > > > > > > > > > > > I think these still are covered.
> > > > > > > > > > > > 
> > > > > > > > > > > > > For example an LNE that is implemented using
> > > > > > > > > > > > > VMs which can be managed by the host at different
> times of
> > > > > > > > > > > > > the VMs
> > > > > > > > > > > > > operational life cycle based on customer/provider
> > > > > > > > > > > > > requirements.  I
> > > > > > > > > > > > > really don't see how YL-bis has any bearing on this
> point
> > > > > > > > > > > > > and
> > > > > > > > > > > > 
> > > > > > > > > > > > Using the new proposed meta data annotation together
> with
> > > > > > > > > > > > the new YL
> > > > > > > > > > > > means that SM can support the use case above also in an
> NMDA
> > > > > > > > > > > > server.
> > > > > > > > > > > > I think the new proposed solution covers more use cases
> than
> > > > > > > > > > > > the
> > > > > > > > > > > > previous solution.
> > > > > > > > > > > 
> > > > > > > > > > > how so?  The inline mount point would contain YL-bis and
> have
> > > > > > > > > > > the same
> > > > > > > > > > > information there, just scoped for the mount point.  It's
> true
> > > > > > > > > > > a
> > > > > > > > > > > client would need to understand the mount point's schema
> only
> > > > > > > > > > > upon
> > > > > > > > > > > parsing the YL under the mount point and this schema could
> not
> > > > > > > > > > > be
> > > > > > > > > > > shared across inline mount points.  But this is as was
> > > > > > > > > > > discussed in
> > > > > > > > > > > the past and unchanged from YL.
> > > > > > > > > > > 
> > > > > > > > > > > > Do you think that there is any use case that the
> proposed
> > > > > > > > > > > > solution
> > > > > > > > > > > > cannot handle, but the previous solution did?
> > > > > > > > > > > 
> > > > > > > > > > > yes.  with VM/container technologies the YL / schema can
> > > > > > > > > > > change under
> > > > > > > > > > > the mount point from time to time during normal operation
> > > > > > > > > > > (i.e.,
> > > > > > > > > > > during runtime, no reboot) and, in some implementations,
> may
> > > > > > > > > > > require
> > > > > > > > > > > some level of rpc operation to access even the schema. 
> The
> > > > > > > > > > > new (and
> > > > > > > > > > > previously proposed approach) of having inline schema
> > > > > > > > > > > available from
> > > > > > > > > > > the top level greatly complicates these cases.  Also keep
> in
> > > > > > > > > > > mind that
> > > > > > > > > > > there will be cases where the ability to access
> information
> > > > > > > > > > > under an
> > > > > > > > > > > inline mount point will dynamically change in operation
> (and
> > > > > > > > > > > top level
> > > > > > > > > > > YL would need to remove schema information for the inline
> > > > > > > > > > > mount
> > > > > > > > > > > point.)  As before, from the usage standpoint, these
> changes
> > > > > > > > > > > don't
> > > > > > > > > > > provide a whole lot of value and seem to optimizing for
> > > > > > > > > > > something not
> > > > > > > > > > > needed in the inline case.
> > > > > > > > > > 
> > > > > > > > > > I think this is an implementation issue, rather than a
> problem
> > > > > > > > > > with
> > > > > > > > > > the proposed mechanism, and it is present in the current
> > > > > > > > > > solution as
> > > > > > > > > > well.  An implementation that can handle dynamically
> changing
> > > > > > > > > > mounted
> > > > > > > > > > YLs in the current solution can do that in the new solution
> as
> > > > > > > > > > well.
> > > > > > > > > > 
> > > > > > > > > > > > > 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.
> > > > > > > > 
> > > > > > > > exactly my point.
> > > > > > > 
> > > > > > > Yes, you're right.  But it requires the usage of YL-bis.
> > > > > > > 
> > > > > > > > > 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>.
> > > > > > > > 
> > > > > > > > I've never heard anyone mention this issue/limitation.
> > > > > > > 
> > > > > > > This has been dicussed, but this does not change with the
> introduction
> > > > > > > of the meta annotation; if the server has off-line knowledge of
> the
> > > > > > > instance's schema then it can populate an inline YL as well as the
> > > > > > > meta annotation and corresponding SM data.
> > > > > > > 
> > > > > > > > My
> > > > > > > > understanding of the previously raised objections were (a) that
> the
> > > > > > > > full schema can't be obtained by just reading the top level YL
> and
> > > > > > > > (b)
> > > > > > > > that when multiple inline mount points have the same schema the
> > > > > > > > information can't be combined using a shared schema approach as
> is
> > > > > > > > taken in base SM.
> > > > > > > 
> > > > > > > Right.  Both these issues are addressed by using a meta
> annotation.
> > > > > > 
> > > > > > But when we discussed this the last time having inline schema
> > > > > > available at the top level (in the SM module), the general consensus
> > > > > > was that having YL under inline was the preferred approach.
> > > > > 
> > > > > What is new now is that we have an indirection; each instance has its
> > > > > own pointer to the schema at the top level.  In the previous
> > > > > discussion, having the schema at the top level implied that all
> > > > > instances shared the same schema, and *that* was rejected.
> > > > > 
> > > > 
> > > > Indirection was possible at the previous time and is part of the
> > > > current scheme Mount definition. Yes, you need to use different mount
> > > > points to reference different schema, but take a look at the ni
> > > > document that's exactly what we are doing there. So I don't believe
> > > > this is the point that caused the previous proposal to be rejected.
> > > > 
> > > > > > Lada
> > > > > > stated that he didn't like the approach, but would go with the WG
> > > > > > decision.  Why are we reopening this closed discussion -- many
> months
> > > > > > after we closed the issue?  Most who contributed, notably users,
> have
> > > > > > moved from SM assuming it's a solved problem.
> > > > > > 
> > > > > > At this point, I think the case needs to be made why the existing
> > > > > > mechanisms in the draft are broken vs how they might be improved. My
> > > > > > understanding is that there was one issue that could be clarified by
> > > > > > the proposed text I included when restarting this discussion.
> > > > > > 
> > > > > > What else is *broken* in the current draft?
> > > > > 
> > > > > My main concern is actually the YL version.  I strongly think SM need
> > > > > to use YL-bis rather that the old YL, so that it can support NMDA.
> > > > > 
> > > > 
> > > > Right now to SM is independent of Yang Library version and can run
> > > > with either.
> > > 
> > > No this is not correct.  SM uses a grouping from the old YANG
> > > library (for the "use-schema" case), and talks about mounting
> > > "modules-state" ("inline" case).
> > > 
> > > > I certainly would expect use of Yang Library bis and nmda
> > > > to have advantages.
> > > > 
> > > > > The implementation effort for supporting the new YL in clients and
> > > > > servers is minimal, esp. when compared to the efforts involved in
> > > > > supporting SM.
> > > > > 
> > > > > Adding an indirection is (for me) less important, but it has the
> > > > > benefit of solving the two issues (a) and (b) above, and I haven't
> > > > > seen any technical problem with it.
> > > > > 
> > > > 
> > > > (A) has implementation implications and those participating in the
> > > > discussion at the time expressed as not being worth the cost.
> > > > I don't believe b was seen as a significant issue either.
> > > > 
> > > > > Do you have any technical concerns with using an annotation as an
> > > > > indirection?
> > > > > 
> > > > 
> > > > The technicsl issue I have with the approaches the same one that was
> > > > raised when debated previously, ie the implementation overhead of
> > > > requiring inline schemas to be available at the top level.
> > 
> > Could you specify where this overhead comes from? Does it matter whether you
> > place some data inside the data tree or somewhere at the top level and point
> to
> > it from inside the tree?
> > 
> > > 
> > > 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.

But it doesn't mean that the schemas *must* be different, and it is easy to
figure out when they are the same. Also, modules sets in YLbis can further help
avoid redundant parsing of the same modules.

Lada

> 
> 
> /martin
> 
> 
> 
> > 
> > Lada
> > 
> > > we need to use the new YL-bis, so that we can support the NMDA.
> > > 
> > > 
> > > /martin
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > 
> > > > From a process perspective, I don't think it's fair to those who
> > > > provided input or contributed in the past in order to get scheme mount
> > > > to satisfy their requirements to reopen something that is not
> > > > broken. Particularly because a number of those contributors are
> > > > implementers and users who are now focused on other topics.
> > > > 
> > > > Lou
> > > > 
> > > > > 
> > > > > /martin
> > > > > 
> > > > 
> > > > 
> > > 
> > > _______________________________________________
> > > netmod mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netmod
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67