Re: [netmod] explicit mount

[Juergen Schoenwaelder <[e-mail]>]

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.

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