Andy Bierman <a...@yumaworks.com> writes: > On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund <m...@tail-f.com> wrote: > >> Robert Wilton <rwil...@cisco.com> 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.
The current definition of datastore is too general, so I don't know what datastore inside datastore means. What's clear is that a single module cannot just be mounted anywhere. For example, if ietf-interfaces is mounted under /device and ietf-ip straight under /, then I don't see how references and XPath expressions could be reliably modified to work as expected. That's why I think only self-contained packages can be mounted, and inside them all references can be prepended with the mount root. Lada > > 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). > > >> >> /martin >> > > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod