Re: [netmod] schema mount and YANG library

[Ladislav Lhotka <[e-mail]>]

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.

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