Hi Martin,
Thanks for the reply.
Martin Bjorklund <mailto:m...@tail-f.com>
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.
“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 - 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. 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? 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.
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.
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. 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.
Cheers,
r.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
