Lou Berger <lber...@labn.net> wrote: > > > On 1/16/2018 11:15 AM, Robert Wilton wrote: > > > > On 16/01/2018 15:50, Martin Bjorklund wrote: > >> Lou Berger <lber...@labn.net> 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. /martin > Yes both increase client operations/work, but > without incurring the server side implementation overhead that is > implied in this approach. -- Again, I don't see how YL-bis or NMDA > changes any of this. > > > But I'm not sure what > > issues that actually causes. E.g. does it cause issues with > > pre-configuration of the LNE? > Assignment of host resources takes place at the root level, not the > within the context of the inline mount point, other preprovisiong can > be handled via the inline/managed mechanisms defined in the LNE > module. We looked at this in detail for multiple server/vendor > implementations and agreed the current mechanisms work even if not > optimal in all cases. > > Lou > > > Thanks, > > Rob > > > > > >> With the proposed solution, there can be different schema-ref pointers > >> in config and operational (if needed). > >> > >> > >> /martin > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> . > >> > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
