Re: [netmod] explicit mount

[Martin Bjorklund <[e-mail]>]

Ladislav Lhotka <[e-mail]> wrote:
> 
> > On 24 Feb 2016, at 23:39, Juergen Schoenwaelder <[e-mail]> wrote:
> > 
> > On Wed, Feb 24, 2016 at 10:30:40PM +0100, Martin Bjorklund wrote:
> >> Juergen Schoenwaelder <[e-mail]> wrote:
> >>> On Tue, Feb 23, 2016 at 04:08:06PM +0100, Martin Bjorklund wrote:
> >>>> Hi,
> >>>> 
> >>>> In yesterday's meeting, Lou (I think?) mentioned a use case for mount
> >>>> that is not documented in draft-rtgyangdt-rtgwg-device-model; the need
> >>>> for being able to specify modules to mount directly in the schema.
> >>>> Something like this:
> >>>> 
> >>>>  container root {
> >>>>    ymnt:mount-point "lne" {
> >>>>      ymnt:mount-module "ietf-interfaces";
> >>>>    }
> >>>>  }
> >>>> 
> >>>> It would be useful if the use case for this could be described in more
> >>>> details.  Is it a requirement to be able to specify this in the
> >>>> schema, or could it be done (as Chris mentioned) in the RFC text?
> >>>> 
> >>>> The reason I ask is that it is probably not as simple as the example
> >>>> above.  First, you probably need to specify a revision of the module
> >>>> to be mounted.  Or a min-revision.  Then probably a set of features
> >>>> that must be enabled.  And so on.  It turns out that there is already
> >>>> a proposal for specifying such a "conformance profile" - YANG Packages
> >>>> (see draft-bierman-netmod-yang-package).  Maybe it would be better to
> >>>> re-use packages?
> >>> 
> >>> We are talking schema mount, right?
> >> 
> >> Yes.
> >> 
> >>> So why would features matter?
> >> 
> >> If you want to mount a certain module, and that module has
> >> feature-conditional subtrees, you may want to make sure that those
> >> features are supported.  If these features are not specified in the
> >> schema, we need to invent some mechanism for the server to advertise
> >> them for the mounted subtree.  This is the job for the inline
> >> ietf-yang-library, or /mount-points state data in the structural-mount
> >> draft.
> >> 
> >> My point is that while this idea (list the module you want to be
> >> mounted) seems simple, there are some issues to solve.  Hence I would
> >> like to understand the use case before suggesting a solution.
> > 
> > A schema in general does not explain which features an implementation
> > of that schema supports. A static schema mount is fully consistent
> > with that.
> > 
> > Yes, the current YANG library may not expose features that apply to a
> > certain mounted schema but this I do not see this as something that
> > makes things more complicated from the schema point of view.
> > 
> > I think the use cases are rather obvious. I build a device and I like
> > to rearrange existing models into a beautiful hierarchy (for some
> > definition of beauty). Or I deal with some form of virtualization and
> > I write a bunch of nested containers and lists that express this and
> > then I mount existing YANG models into this hierarchy. In cases like
> > this, I know exactly which model I want to mount where at design time.
> > 
> > In your I-D (if I got this right), you only declare mount-points in
> > the schema and then an implementation can mount whatever it likes on a
> > mount-point. What is the use case for this? Why is it a feature to not
> > express in the schema at design time what can be expected behind a
> > mount point?
> > 
> > BTW, in your example on page 10, should
> > 
> >       <name>device-root</name>
> > be
> >       <name>logical-device</name>
> > 
> > ?
> > 
> > There are likely many other questions that are largely independent of
> > the question whether the schema is fixed in a schema at schema design
> > time or only discoverable at runtime. (How do protocols interpret
> > instance-identifiers crossing mount points, how do you mix chrooted
> > and non-chrooted behaviour, what about edit-configs crossing mount
> > points, how does this all play with NACM, etc. Nobody expected this to
> > be easy.)
> > 
> > Since you and Lada thought way more about this than I ever did, there
> > may be a reason why you both propose to make this runtime data driven
> > instead of having a piece of YANG defining how schemas are mounted
> > together.
> 
> Three reasons:
> 
> 1. I wanted a mechanism that requires no change in YANG (and, as I
> said, using an extension for this is taboo for me).

But *not* using an extension is as bad for the poor client as having
an extension it just ignores!  In both cases the old client sees a
normal data model, and in both cases the data model is in fact
extended via mount.

> 2. It is more flexible: modules can be combined in different ways,

Agreed.

> and using the same "mounting" module with different sets of mounted
> modules would require different versions of the mounting module.

I don't understand what you try to say here.

> I
> guess the motivation is similar as for NVDL: 
> 
> http://petrnalevka.blogspot.cz/2010/05/nvdl-breath-of-fresh-air-for-compound.html
> 
> 3. This mechanism seems incompatible with groupings, or at least I
> cannot imagine how such a mount could be handled inside a grouping.
> 
> BTW, the last item also applies to Martin's mount-point extension:
> if it appears inside a grouping, then the same mount point may end
> up in different places and the whole concept breaks down.

If a mount-point is defined in a grouping, that grouping can only be
used once in a module.  The mount-point name gets bound to the module
that uses the grouping.  I will clarify this in my draft.


/martin




> 
> Lada
> 
> > 
> > /js
> > 
> >>> Yes,
> >>> there might be interesting versioning issues but how are they
> >>> different from an augmentation putting data under root? I naively
> >>> considered such a 'static schema defined mount' the simplest case,
> >>> then the 'augmented schema defined mount' naturally following from the
> >>> way augmentations work:
> >>> 
> >>>  augment /some:root {
> >>>    ymnt:mount-point "lne" {
> >>>      ymnt:mount-module "ietf-interfaces";
> >>>    }
> >>>  }
> >>> 
> >>> The 'dynamic runtime defined mounts' may be most flexible but then
> >>> they require me to read runtime data in order to adapt to the schema
> >>> structure, which has its own set of complexities.
> >> 
> >> I agree.
> >> 
> >> 
> >> /martin
> >> 
> >> 
> >>> Yes, the versioning
> >>> issues go away since I have to adapt to each implementation
> >>> dynamically but there is surely a cost involved with that as well.
> >>> 
> >>> Am I missing something?
> >>> 
> >>> /js
> >>> 
> >>> -- 
> >>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> >>> Fax:   [phone]         <http://www.jacobs-university.de/>
> >>> 
> > 
> > -- 
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <http://www.jacobs-university.de/>
> > 
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
>