Re: [netmod] explicit mount

[Martin Bjorklund <[e-mail]>]

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

This would be pretty complicated.  Suppose I define my own beautiful
structure like this:

  container my-interfaces {
    x:mount-point "if" {
      x:mount-module "ietf-interfaces";
    }
  }
  container my-routing {
    x:mount-point "rtr" {
      x:mount-module "ietf-routing";
    }
  }

Note that with the mount-point defined in my draft, each mount-point
becomes itw own "jailed" or "chrooted" tree.  So references cannot
cross mount points.

In this case, we have references between ietf-routing and
ietf-interfaces.  How would they work?  What happens with the
references if I do:

  container my-interfaces1 {
    x:mount-point "if1" {
      x:mount-module "ietf-interfaces";
    }
  }
  container my-interfaces2 {
    x:mount-point "if2" {
      x:mount-module "ietf-interfaces";
    }
  }
  container my-routing {
    x:mount-point "rtr" {
      x:mount-module "ietf-routing";
    }
  }


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

This is the logical device use case - Chris replied to this.

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

See above.  Another use case is what we are using in our NCS software,
and ODL is using - a manager/controller/orchestrator that mounts the
data models of the devices it manages/controls/orchestrates.  These
models are not known at design time.


> BTW, in your example on page 10, should
> 
>        <name>device-root</name>
> be
>        <name>logical-device</name>
> 
> ?

Yes.

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

Well, I think that the current mount-point w/ a chrooted behaviour
simplifies this a lot.


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

Hopefully this is clear now from the use cases we have presented.


/martin


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