Rob/Martin,
On February 26, 2016 6:01:23 AM Robert Wilton <[email protected]> wrote:
On 26/02/2016 07:25, Martin Bjorklund wrote:
Robert Wilton <[email protected]> wrote:
On 25/02/2016 08:43, Martin Bjorklund wrote:
Juergen Schoenwaelder <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
