Rob Shakir <[email protected]> wrote: > > Hi Martin, > > Thanks for the reply. > > Martin Bjorklund <mailto:[email protected]> > > August 28, 2015 at 02:33 > > So the idea is that this structure is defined in one module, > > ietf-something-structure, right? > > > > And then different oam protocol modules augment this structure? > > > > How does this help you find the modules that augment this structure? > Yes, this is the intention. By then generating the tree of the overall > structure, then I can see what different containers are created > there. It's not perfect (and hey, this suggestion is a *draft* for a > reason - but yet again, there are not alternatives) - but the fact > that the modules augment a common path adds some information that they > are grouped to providing the same functionality, not > disparate. ietf-routing does the same thing, it gives me the fact that > at /routing/routing-instance/routing-protocols there are a bunch of > control-plane protocols that are related to routing.
Ok. So your proposal doesn't help with the problem of locating relevant YANG modules, but once their located, it is easier to find the ones related to a specific function, b/c they would augment a common path. Is this what you mean? > >>>> “Just read through the modules” is not acceptable answer when > >>>> considering making things easy to use for YANG model consumers. > >>> But how does the top-level node /device (sorry, but I really have to > >>> ask this) solve this problem? I *really* do not understand this. > >>> Even with your solution you'd have a set of modules that augment this > >>> structure, right? How do I know what these other modules are? > > You didn't answer this question. So I repeated it above and below ;) > Right. There was really a reason NOT to answer it. /device is > irrelevant. It does not matter But this is the what we have been arguing about! Remove /device and we can put this behind us and move forward. > - it is simply how *this proposal* > chooses to group things, based on the fact that we think that > operators logically configure devices when dealing with these > models. Sure, an operator configure devices. > From your comments on NCS below, it seems to me that if we'd > made this a list, then there'd be significantly less concern? No that would be even worse! If every device had a list of exactly one device (itself), the operator would have to do the equivalent of: $ ssh rtr2 ... > config # device device rtr2 interface eth0 On most routers you don't do this. You just do: > config # interface eth0 Or in an orchestrator like NCS you'd have to do the equivalent of: $ ssh orchestrator ... > config # devices device rtr2 data devices device rtr2 interface eth0 This just doesn't make any sense. > I just > can't understand why this is something to get hung up on. If /device > isn't the right root, please show me what is - and WHY it's better. Just use '/'. The point is that *on the device* a root of /device doesn't make any sense. I am all for a common model of a device list to be used in the NSM/OSS/..., but that is a separate issue. > Structuring configuration and operational around some idea that all > the configuration belongs to a physical device seems very, very > logical to me. Further defining groups so that we have an > understanding of how to build a coherent set of models for the > functionalities required of that device seems a very clear next step > after this. > > Thanks, this is what I remember you mentioned in Dallas. > > > > But what does this really mean? Are you proposing: > > > > 1) to define one model ietf-something that contains this proposed > > structure, which then other modules augment? > > > > 2) to define one single ietf model, period. no augments by the > > ietf. > > > > 3) to define the structure more loosely in text, and use this > > structure when new models are developed? > > > > 4) something else? > As part of iterating on this idea, we are working to understand the > practicalities of (1). This is exactly the approach that ietf-routing > is taking for routing protocol modules. Thanks for the clarification. > >> The layout of the sets of functions that we have, and how they are > >> grouped, is the important thing. The fact that we are configuring a > >> device makes /device a good starting point. I think this is how you > >> implemented NEDs in NCS too...? > > No, each NED (device) is modelled according to its native "model". So > > for example the IOS NED has /interface, /ip, /xconnect, etc. > > > > 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! > If we are really just debating whether > /devices/device is a list or whether it's a container, I'm even more > confused than I was before. Please see my earlier comment. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
