Rob Shakir <r...@rob.sh> wrote: > > Martin, > > Apologies, I switched to a new client and, wow, yes, it's not > readable. I reported a bug and switched clients again... I *hope* this > one is more readable (and it was when I checked last).
Thank you Rob! > I'll put aside questions of whether the questions I'm asking are > completely fair. Apologies. They're written from my perspective of > problems I'm actually experiencing. > > Martin Bjorklund <mailto:m...@tail-f.com> > > August 27, 2015 at 15:45 > > 1) As a consumer of YANG models, how do I identify the set of models > > that provide a set of functionality? > > > > I think that neither your proposed solution or what we have today (7 > > published modules) solves this problem. > I respectfully disagree. By defining some form of structure for the > models, I can have a logical grouping that gives me some pointers as > to where to find the right things that I need. I want to configure > OAM, great, let's go look at > /device/logical-network-elements/logical-network-element/network-instances/network-instance/oam-protocols > - because that's where all OAM stuff happens to live. 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? > If I have to > rather look through / to find a subset of some ping functionality in > one module, and some in another, it's not clear to me how I even start > to find the right thing - because at the moment one type of ping lives > in one module, and another in a completely different one, even though > they're almost identical in terms of management plane interface. I agree this sounds like a bad design. I absolutely agree that it is necessary to look at how a generic X is handled before doing a model for a specific instance of X. For example, it is probably useful to define how interfaces in general are managed before creating a model for ethernet interfaces. And maybe useful to think about how routing protocols in general are handled before doing a model for bgp. [...] > >> “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 ;) > > > > Now, I should add that the way I see your solution is a YANG module > > that defines a structure of NP-containers. You (or was it Anees?) > > then mentioned that we shouldn't focus so much on the *YANG module*; > > it was the structure that was important. > > > First off, we drew a picture [0] that showed the set of modules that > we figured we might need. These break down into various bits of device > functionality. To make this more accessible as something that could be > shown in a draft, we expressed it in YANG and used pyang to draw out > the tree. 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? > 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 /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
