Re: [netmod] schema mount and YANG library

[Lou Berger <[e-mail]>]

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.

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

Lou

>
>
> /martin
>