Re: [netmod] schema mount and YANG library

[Ladislav Lhotka <[e-mail]>]

On Wed, 2018-01-17 at 10:43 -0500, Lou Berger 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/curre
> > > > > > > > > > > > > > > nt/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

What Martin and I are talking about is a mount point that is a list node of the
"use-schema" type. There is no way how different entries of this list could have
different schemas.

The same applies to a container mount point that is inside a list. Then you can
also have multiple *instances* of the mount point, and with "use-schema" there
is no way how these instances could have different schemas.

Lada

>  
> 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. 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.
> 
> > 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