Re: [netmod] explicit mount

[Ladislav Lhotka <[e-mail]>]

> On 25 Feb 2016, at 09:00, Martin Bjorklund <[e-mail]> wrote:
> 
> 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.

The wording in 6020bis also allows a *server* to ignore extensions. So both the client and server could just guess what extensions the other party supports.

As you now, I have never been a friend of the excessive care of old clients (at this stage of YANG development, at least), but it is really funny to have sec. 11 in 6020bis and, at the same time, permit extensions that fundamentally change how YANG works.

Optional extensions are OK for a protocol but not so much for a schema language.

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

Imagine that ietf-interfaces mounts trees for different technologies instead of waiting for augments. Then every revision would support a fixed set of technologies, and every new technology would require ietf-interfaces to be updated.

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

Well, CLRs… But there are actually use cases where you might want to add stuff to multiple instances of a node defined in a grouping, for example:

grouping foo-common { ... }

container foo {
  uses foo-common;
  ...
}

container foo-state {
  config false;
  uses foo-common;
  ...
}

Then somebody may want to add (different) subtrees to both instances of a node that's defined inside foo-common. With YSDL it's trivial.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C