Re: [netmod] Design-Time schema mount

[Ladislav Lhotka <[e-mail]>]

> On 26 Aug 2016, at 14:38, Martin Bjorklund <[e-mail]> wrote:
> 
> Ladislav Lhotka <[e-mail]> wrote:
>> Martin Bjorklund <[e-mail]> writes:
>> 
>>> Hi,
>>> 
>>> [replying to the first post in this (old) thread; the thread got a bit
>>> off-topic]
>>> 
>>> Balazs Lengyel <[e-mail]> wrote:
>>>> Hello,
>>>> 
>>>> As I understand it, Schema-mount today does not support an important
>>>> use-case which we definitely need, but others also indicated they
>>>> want.
>>>> 
>>>> I want to specify off-line in design time which models will be mounted
>>>> where. Many of my nodes know in design-time what their model structure
>>>> will be, so I want a way to be able to document this in YANG.
>>> 
>>> I'd like to understand this use case in more detail.  You say that
>>> that a "node knows in design-time" that YANG models it will use.  Thus
>>> it seems natural to be able to specify which other modules to mount in
>>> the YANG module itself.
>> 
>> Did you have a chance to look into my slides from Berlin? I sketched some
>> solutions there.
> 
> Well, that's a *solution*.  I'd like to understand the *problem* first ;)
> 
>>> The problem I see with this is that it is very limited to the use case
>>> where each implementation defines its own YANG modules.  Suppose you
>>> have such a model, for example:
>>> 
>>>   module A {
>>>     ...
>>>     mount ... {
>>>       mount-module B;
>>>       mount-module C;
>>>     }
>>>  }
>>> 
>>> [pseudo-code for module A that specifies that it mounts B and C]
>>> 
>>> Now, suppose you take this module A to another implementation, and it
>>> needs to augment something into module C; essentially this means that
>>> it would like to mount B, C and new module D.   This will not be
>>> possible unless it modifies module A.
>> 
>> Not necessarily, D could contain an augment with a target specified by a
>> schema node identifier that uses nodes from both A and C.
> 
> Not if B and D are defined as standalone modules, e.g. if B is
> ietf-interfaces and D is ietf-ip.

Right, we cannot have everything.

> 
>> Imagine that instead of "ietf-ip" augmenting "ietf-interfaces" it would
>> be the other way around: "ietf-interfaces" mounts "ietf-ip". Then the
>> augment in ietf-ipv6-router-advertisements
>> 
>>  augment "/if:interfaces-state/if:interface/ip:ipv6" { ... }
>> 
>> needn't be changed.
> 
> This would be an entirely different kind of mount!  The current mount
> doesn't work like that; it doesn't give you visibility into the
> combined models - by design.

Of course this is a different kind of mount.

> 
> 
>> The major problem with this IMO is that it needs a new YANG statement. 
>> 
>>> 
>>>> In
>>>> today's proposal the only way to find the Yang-Mounts is to read it
>>>> from the live node.
>>>> 
>>>> * OAM integrators or operators want to be able to write CLI scripts
>>>>  and Netconf messages without accessing (expensive) real nodes. For
>>>>  this they need to know the mounts
>>>> * We want to generate some fancy documentation from YANG automatically
>>>>  in design-time.
>>> 
>>> In a way this is no different from the situation today - in order to
>>> learn what YANG modules a device supports you need to connect and
>>> parse the <hello> message (or ietf-yang-library data in the near
>>> future).  This info could also be made available off-line in a file.
>> 
>> Yup. So we just need some machine-readable description of the structure
>> of mounted schemas.
>> 
>>> 
>>> It should certainly be possible to define a file format that a device
>>> somehow could "publish" off-line that contained all the info that is
>>> available at run-time.  This file format could be exactly the same as
>>> you would get if you did a NETCONF <get/> operation with some filter
>>> to only retreive the ietf-yang-library data at the mount points.
>> 
>> Well, if you have multiple levels of mounts, it will get messy: you
>> wouldn't know which yang-library data belongs to which mount point.
> 
> Why not - imagine that you do a full <get/> on such a device, it will
> return the nested yang library data just fine.

Well, yes, if you are prepared to parse and process arbitrary data for which you don't know the schema. I think the schema and instance data (= <get/> reply) are different things and we should treat them so: the complete schema description should IMO have a well-known (meta-)schema, even if we express it with YANG.  

Lada

> 
> 
> /martin
> 
> 
>> I believe some variation on YSDL could work, and as I wrote in another
>> thread, we could also incorporate datastores: after defining the
>> (multilevel) schemas, each datastore will get one assigned - and they
>> can also share them where needed.
>> 
>> Lada
>> 
>>> 
>>> 
>>> 
>>> /martin
>>> 
>>> 
>>>> 
>>>> * Many use cases need the possibility to mount schemas, but do not
>>>>  need the added complexity of schema changes in run-time.
>>>>  Notwithstanding the case of "YANG Features", for me the model schema
>>>>  is a mostly static description of a nodes capabilities. Most of the
>>>>  time I do not want to worry about the node changing its schema on
>>>>  the fly.
>>>> 
>>>> 
>>>> For this I propose 2 YANG extensions
>>>> 
>>>> extension schema-mount {
>>>> description "Indicates that a YANG Module is to be mounted into
>>>> another module.
>>>> The argument specifies the name of the module to be mounted.";
>>>> argument mounted-module;
>>>> }
>>>> 
>>>> extension schema-mount-target {
>>>> description "Specifies the target node under which a YANG module is to
>>>> be mounted.
>>>> The statement can only be used inside a schema-mount statement.
>>>> The argument follows the same rules as an augment statement's target.
>>>> argument target-node;
>>>> }
>>>> 
>>>> The two extension statements can be placed in a separate module or the
>>>> mounted module.
>>>> 
>>>> I don't insist on the solution, but I need the off-line/design-time
>>>> specification of yang-mount to be possible. IMHO the design-time mount
>>>> use-case is more important than the dynamic-mount.
>>>> 
>>>> regards Balazs
>>>> --
>>>> Balazs Lengyel                       Ericsson Hungary Ltd.
>>>> Senior Specialist
>>>> Mobile: [phone]              email: [e-mail]
>>> 
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>> -- 
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C