Martin, On 8/26/2015 6:41 AM, Martin Bjorklund wrote: > Lou Berger <lber...@labn.net> 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 <lber...@labn.net> wrote: >>>> Martin, >>>> >>>> See below. >>>> On 08/19/2015 05:27 AM, Martin Bjorklund wrote: >>>>> Hi, >>>>> >>>>> Lou Berger <lber...@labn.net> 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 > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod