Re: [netmod] Design-Time schema mount

[Andy Bierman <[e-mail]>]

Hi,

I agree with Martin about not specifying which YANG modules
can be mounted under some mount point, in the YANG module.

The mount point needs some basic properties (like "config root", "opstate
root", whatever).
Then data nodes are classified somehow (e.g. config=true/false) and that
determines
what content can be mounted under that mount-point.

The combination of modules on the server needs to be a deployment decision
to
prevent issues like Martin describes below.


Andy


On Fri, Aug 26, 2016 at 5:38 AM, 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.
>
> > 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
> >
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>