Re: [netmod] Y34 - root node

[Martin Bjorklund <[e-mail]>]

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


/martin



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