Re: [netmod] schema mount and YANG library

[Martin Bjorklund <[e-mail]>]

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

Ok.  I'm ok with keeping the inline case as it is.  However, I think
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
> >
> 
>