Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00

[Lou Berger <[e-mail]>]

Martin,

On 8/26/2015 6:41 AM, Martin Bjorklund wrote:
> Lou Berger <[e-mail]> wrote:
>> Martin,
>> 	Sorry for the delayed response, was away for a bit.  Not sure if any of
>> this is OBE as just starting to catch up on mail.
>>
>> On 08/20/2015 03:58 AM, Martin Bjorklund wrote:
>>> Lou Berger <[e-mail]> wrote:
>>>> Martin,
>>>>
>>>> See below.
>>>> On 08/19/2015 05:27 AM, Martin Bjorklund wrote:
>>>>> Hi,
>>>>>
>>>>> Lou Berger <[e-mail]> wrote:
> [...]
>
>>>> Deeper in the hierarchy the path becomes more significant, but you
>>>> weren't really questioning this.
>>> I am all for significant nodes in the path!  
>> This is really good/useful to hear.  If disagreement is limited to the
>> top level node, it's much easier (but not easy ;-) problem to solve.
>>
>>> My point is that /device
>>> is insignificant.
>> I think the fundamental discussion here, is who get's to say what's
>> significant and we have (at least) two opposing views on this point.
>>
>> From my standpoint it comes down to how you view full set of models that
>> may be seen.  From the device view, you might only (or, more likely,
>> mostly) see models under /device -- so device doesn't add much value.
>> BUT from the controller/NMS/EMS (or whatever you want to call it) view,
>> you're likely to see all the models
> Agreed, but see below.
>
>> so /device plays a much more
>> significant role in identifying logical model
>> organization/understanding.  -- That said, I'm much more of a device
>> person than an NMS builder, so I'm also willing to trust the opinion of
>> folks who are clearly doing significant work on the controller/NMS
>> side.
> [This was briefly discussed in another mail thread, and I'll repeat it
> here.]
Thanks.

> 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']
>
>
> (here you again can see that the "device" node in the device model
> doesn't make much sense)

if there are siblings, it could still make sense...

>
> 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 then you might also have a
> controller-of-controllers. where the path might be:
>
>   /domains/domain[name='bar']/devices/device[name='foo']/data
>     /interfaces/interface[name='eth0']
>
> Pushing all these concepts down into the device model clearly doesn't
> help...

So, I think it would be good to hear from the openconfig folks on this
point.  Perhaps they'll respond via e-mail, perhaps it'll have to wait
for the interim...

Thanks,
Lou
>
> /martin
>