Re: [netmod] Design-Time schema mount

Martin Bjorklund <mbj@tail-f.com> writes:

> Hi,
>
> [replying to the first post in this (old) thread; the thread got a bit
> off-topic]
>
> Balazs Lengyel <balazs.lengyel@ericsson.com> 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.

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

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.

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.

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: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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