Re: [netmod] explicit mount

[Lou Berger <[e-mail]>]

Rob,
    I think chris spoke to this (indirectly) in an earlier mail -- that
the current approach of not specifying is most flexible from a future
proof stand point, i.e., we really don't want to specify based on what
exists in today's rapidly moving environment.

We have also discussed the possibilities of defining 'example profiles'
which would be what you'd expect to see from different classes of
devices, e.g., an wrt box vs a tier 1 PE - which could be informative.

Lou

PS Interfaces do need to show in NIs, check out the augmentations
defined as part of the model.  But I think your general point is still
valid.

On 2/26/2016 9:40 AM, Robert Wilton wrote:
> Lou, Martin,
>
> Is the network-instance schema-mount (from 
> draft-rtgyangdt-rtgwg-device-model) an example of where it would be 
> useful to indicate which modules would be expected to be mounted at that 
> point?
>
> Certainly it would seem that there are particular modules that you would 
> expect to be mounted at that point (e.g. routing) and other modules that 
> you would not (e.g. interfaces/hardware/etc).
>
> Rob
>
>
> On 26/02/2016 11:13, Lou Berger wrote:
>> Rob/Martin,
>>
>>
>> On February 26, 2016 6:01:23 AM Robert Wilton <[e-mail]> wrote:
>>
>>>
>>> On 26/02/2016 07:25, Martin Bjorklund wrote:
>>>> Robert Wilton <[e-mail]> wrote:
>>>>> On 25/02/2016 08:43, Martin Bjorklund wrote:
>>>>>> Juergen Schoenwaelder <[e-mail]> wrote:
>>>>>>> On Thu, Feb 25, 2016 at 09:23:57AM +0100, Martin Bjorklund wrote:
>>>>>>>
>>>>>>>>> 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.
>>>>>>> Could be the same here.
>>>>>>>
>>>>>>>> In this case, we have references between ietf-routing and
>>>>>>>> ietf-interfaces.  How would they work?
>>>>>>> How do they work in your solution? If interfaces is jailed and 
>>>>>>> routing
>>>>>>> is jailed, how does routing refer to the interfaces?
>>>>>> My solution does not support "name module mount".  It only supports
>>>>>> mouting of a "complete" set of modules (that are chrooted) - simply
>>>>>> because this is what we understand, have implemented, and have been
>>>>>> running for the last ~5 years.  (The same goes for ODL, I believe).
>>>>> I have been wondering whether "name module mount" is really about
>>>>> mounting only specific modules, or actually allowing the mounting
>>>>> schema to statically indicate which modules are guaranteed to be
>>>>> present.  I.e. specifically it doesn't explicitly prohibit other
>>>>> modules/data nodes from potentially also being mounted at the same
>>>>> path, but in the normal case you wouldn't expect them to be present.
>>>> This was my thinking as well.  But then the "random rearrangemt of
>>>> modules to get a more beautiful layot" use case doesn't apply.
>>>>
>>>> And if you start to do "ymnt:require-module" you probably also need to
>>>> specify "required-feature" and "required-revision"...
>>> Yes, I don't know if you would have to require those, but I can see that
>>> it would be useful to at least allow them.
>>>
>>>> So, before exploring possible solutions, it would be great if we
>>>> agreed on the problem to solve.  Does anyone have a use case for
>>>> explicit naming of modules to be mounted in the schema?
>>> I might be mistaken, but an example use case of this may have been given
>>> in the Yokohama L3SM WG meeting.
>>>
>>> That WG has a desire to build service level YANG models, and for such
>>> models I think that there are some scenarios where it may be desirable
>>> to build those service level models by reusing some of the device level
>>> YANG modules (e.g. perhaps QoS, ACLs, or BGP may have been mooted)
>>> rather than having to independently develop closely related copies of
>>> those YANG modules located at different schema paths which might
>>> potentially diverge over time.
>>>
>> L3SM and bgp was the case I referred to in the interim and commonly 
>> use as an example. (Although I wasn't part of the Yokohama discussion 
>> you mentioned.)
>>
>>> However, if this was the scenario considered then it is unclear to me
>>> whether you would want to mount the entirety of a QoS device level
>>> model, or would just want parts of it.  Arguably groupings may be a
>>> better solution here, but their usefulness depends on whether the device
>>> level model has been constructed in a way to make reuse of parts of that
>>> model feasible.
>>>
>> This probably would work if we had augmentable groupings or maybe 
>> "root less" containers -- need to think a bit more about the latter....
>> Lou
>>> Rob
>>>
>>>
>>>>
>>>> /martin
>>>>
>>>>
>>>>> My reasoning is that you don't want to have to statically specify in
>>>>> the mounting schema all augmentations, deviations and features.  But I
>>>>> also don't think that the mounting schema can guarantee that the
>>>>> mounted schema will always exactly implement the module(s) specified
>>>>> in the schema mount and all features without any augmentations or
>>>>> deviations.
>>>>>
>>>>> So for this to be useful, it means that there has to be a dynamic
>>>>> mechanism to determine exactly what modules has been mounted
>>>>> (e.g. like the ietf-yang-structural-mount module or ysdl).
>>>>>
>>>>> Given this, I think that you could possibly end up with just one
>>>>> "schema mount" with a couple of options:
>>>>>
>>>>> The first option would be an explicit list of modules that are
>>>>> guaranteed to be mounted at that location (or "*" to indicate a
>>>>> "complete" set of modules (that are chrooted).
>>>>>
>>>>> The second option would indicate where the runtime details of the
>>>>> mounted modules can be found: this option might indicate whether
>>>>> details of the mounted modules can be found inline in the data tree at
>>>>> the mount point using yang-library, or separately in the
>>>>> ietf-yang-structural-mount module/ysdl.
>>>>>
>>>>> Rob
>>>>>
>>>> .
>>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
>> .
>>
>