Re: [netmod] explicit mount

[Ladislav Lhotka <[e-mail]>]

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

2. It is more flexible: modules can be combined in different ways, and using the same "mounting" module with different sets of mounted modules would require different versions of the mounting module. 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.

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