Re: [netmod] Y34 - root node

[Ladislav Lhotka <[e-mail]>]

> On 21 Aug 2015, at 15:01, 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>).

But what about normal modules that refer to nodes in the mounted module? Their XPath expressions and leafrefs would be incorrect.
I think they must be mounted to the same root, too.

Lada

> 
> 
> /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
>>> 
>>>    .
>>> 
>> 
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C