Re: [netmod] Y34 - root node

[Andy Bierman <[e-mail]>]

On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund <[e-mail]> wrote:

> Robert Wilton <[e-mail]> 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).


>
> /martin
>


Andy