Juergen Schoenwaelder <[email protected]> wrote:
> On Wed, Feb 24, 2016 at 10:30:40PM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder <[email protected]> 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > > Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
> > >
>
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
