Re: [netmod] Y34 - root node

[Robert Wilton <[e-mail]>]

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.

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