Re: [netmod] Y34 - root node

[Andy Bierman <[e-mail]>]

On Fri, Aug 21, 2015 at 6:01 AM, Martin Bjorklund <[e-mail]> wrote:

> Robert Wilton <[e-mail]> wrote:
> > Hi Martin,
> >
> > On 20/08/2015 09:15, Martin Bjorklund wrote:
> > > Andy Bierman <[e-mail]> wrote:
> > >> 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).
> > > 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.
>
> My idea is that you mount the top-level node, and that means that
> everything below it is "copied" into the new location.  I.e.,
> augmentations to the subtree are also copied.  So you would not mount
> any augmentations (that's why the syntax is mount <top-level-node>).
>
>
>
I am only interested in (1) ncx:root approach because this actually works.

Cherry-picking does not work well because
   (a) subtrees are allowed to have constraints on data outside that subtree
   (b) YANG XPath cannot be safely relocated up or down (i.e., move
/interfaces to
   /device/interfaces or move /foo/bar/baz to /foo2/baz


/martin
>


Andy


>
>
> >
> > 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
> > >
> > >     .
> > >
> >
>