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).
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;
...
}
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
