On 08/28/2015 02:55 PM, Martin Bjorklund wrote:
But, as I have said before, the device abstraction is really
> >important - in the NMS/OSS/controller/whatever. There we have a list
> >of devices, and each device has a name and meta-data and then its real
> >data, so for example we can have:
> >
> > /devices/device[name='rtr4']/ip
> > /devices/device[name='rtr4']/port
> >
> >and then we put all data models from the device under a common
> >container 'data':
> >
> > /devices/device[name='rtr4']/data/interface/
> > /devices/device[name='rtr4']/data/xconnect/
> >
> >If the device had a top-level container "device" this would have been:
> >
> > /devices/device[name='rtr4']/data/device/interfaces
>This approach*DOES* logically structure configuration around the
>concept of a device.
Yes - in the NMS/OSS/controller -*not* on the device!
I will add that at that layer a flat list is probably not going to be
good enough in face of layers and federations. That is definitely a
different issue and one where 'relocating' YANG models becomes important.
At that layer I could not care less if interfaces are enumerated in
/interfaces or /device/interfaces -- I will end up relocating the models
to fit the logical layout anyway, as I will need to have them placed in
a structure which makes sense to my end users.
On the device layer, though, I have to say that /device is just a
redundant layer of abstraction. Stuff augmenting it will fan out just as
it does currently at /. Furthermore we will end up with 'structural
models', which are somewhat of a first-class citizen and 'functionality
models', which have to augment some structural model. I think end users
care more about interaction with the latter.
From OpenDaylight implementation perspective, augmentations are
slightly harder to work with, simply because their underlying concept
does not have a language-level equivalent in Java (but it does in other
languages). For this reason I would advocate not using a structural base
unless it allows us to express a relationship which we couldn't do
otherwise.
Bye,
Robert
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
