Re: [netmod] Y34 - root node

[Ladislav Lhotka <[e-mail]>]

Andy Bierman <[e-mail]> writes:

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

The current definition of datastore is too general, so I don't know what
datastore inside datastore means. What's clear is that a single module
cannot just be mounted anywhere. For example, if ietf-interfaces is
mounted under /device and ietf-ip straight under /, then I don't see how
references and XPath expressions could be reliably modified to work as
expected.

That's why I think only self-contained packages can be mounted, and
inside them all references can be prepended with the mount root.

Lada

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

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