Re: [netmod] Design-Time schema mount

[Martin Bjorklund <[e-mail]>]

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.

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


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


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