Hi Martin,
On 20/08/2015 09:15, Martin Bjorklund wrote:
Andy Bierman <[email protected]> wrote:
On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund <[email protected]> wrote:
Robert Wilton <[email protected]> wrote:
On 18/08/2015 18:22, Andy Bierman wrote:
This is how languages like SMIv2 and YANG work.
A conceptual object is given a permanent "home" within the tree of
object identifiers.
Moving data is very expensive, since any clients working with the old
data
will break as soon as the data is moved.
I am not convinced the IETF can or should come up with a set of
containers
that covers every possible topic that can be modeled in YANG.
I mostly agree, but having some more structure/advice as to where to
place YANG modules may be helpful. I'm thinking more along the lines
of broad categories rather than precise locations.
+1
If someone wants to builds a YANG controller node that is managing
the configuration for a network of devices then wouldn't they want
a particular device's interface configuration to be located
somewhere like /network/device/<device-name>/interfaces/interface?
Ideally, they would be able to use the same YANG definitions that
are defined for /interfaces/ but root them relative to
/network/device/<device-name>/.
Yes -- some of us (like Martin) have pointed this out many times.
The "device" container on an NE does not help at all wrt/
aggregation on a controller. "/device" or "/" work the same for this
purpose.
Actually, I would argue that / works better. On the controller, you
probably have a list of devices you control (this is how our NCS
works, and how ODL works (I have been told)):
container devices {
list device {
key name;
// meta-info about the device goes here, things like
// ip-address, port, auth info...
container data {
// all models supported by the devices are "mounted" here
}
}
}
So on the controller, the path to interface "eth0" on device "foo"
would be:
/devices/device[name='foo']/data/interfaces/interface[name='eth0']
if we also have a top-level "/device" container we'd have:
/devices/device[name='foo']/data/device/interfaces/interface[name='eth0']
What would the real resource location for
"/network/device/<device-name>/interfaces/interface" be?
I don't think there is such a thing as a "real" location. The path is
scoped in the system you work with; in the controller it might be as I
illustrated above, in the device it starts with /interfaces, but in a
controller-of-controllers it might be:
/domains/domain[name='bar']/devices/device[name='foo']/data
/interfaces/interface[name='eth0']
Currently we have a proprietary way of "relocating" YANG modules, and
ODL has its "mount", and I think Andy has some other mechanism. Maybe
the time has come to standardize how mount works, and maybe then also
standardize the list of devices in a controller model.
+1
We just need to standardize a "docroot within a docroot".
This is not relocation of subtrees within the datastore, this is just
mounting
a datastore somewhere within a parent datastore.
In YANG validation terms, you simply adjust the docroot to the nested mount
point,
and the replicated datastore can be used as if it were stand-alone.
This would allow any sort of encapsulation of datastores and not add any
data model complexity to devices which do not have virtual servers
(most of them).
Compared to the mount draft, I would like to decouple the schema
information from the instance population mechanism. I.e., I'd like a
mechanism that simply defines the schema, not necessarily how the data
is populated (in the mount draft data was fetched from a remote
server, but IMO that is just one of several use cases).
Yes, I agree that these could/should be decoupled. Although I note that
the mount draft does also allow for local mounts, although this does not
seem to be intended to be the mainline case.
I can think of two ways to do this.
1) Your "ycx:root" statement. This is open-ended, so we could do:
list logical-element {
key name;
leaf name { ... }
yang-root true;
}
From a schema perspective, any top-level node from any data model
could be used within the logical-element list.
2) Cherry-picking:
list logical-element {
key name;
leaf name { ... }
mount if:interfaces;
mount sys:system;
...
}
I think that that it makes the overall schema more useful if it
explicitly states what schema is used for the mounted nodes, although
possibly a wildcard mount could still be allowed.
I wasn't quite sure how it would work if you wanted to mount a schema
that has augmentations. Would you have to list all supported
augmentations in the mount point as well? Otherwise you wouldn't know
what the full schema is.
Thanks,
Rob
Or maybe combine them into one "mount" statement:
mount *; // allow any top-level node
mount sys:system; // allow this specific top-level node
/martin
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
