Freek Dijkstra wrote:
Evangelos wrote about the "Model" object:
Can we call them "Views" instead of "Models"? "Model" is a quite overloaded word, especially in a semantic context.
But otherwise, thanks for writing this up. This is really close to work currently under development in the IDC project.
Currently, I see two concepts here: an (administrative) network domain, and a filtered view. The relational difference is that a device can only be part of ONE "domain", but part of MULTIPLE "views".
Agreed.
Evangelos, does that mean you like to have both a "domain" object for grouping, and another "view" object that gives you a filtered view of the contents of this group? Or do you only want one "View" object that is just some grouping of network elements? A "view" can be more than a simple grouping or filtering; it could be a complete restructuring of the network elements. The most common use case in the control plane world would be reducing a network to a simpler topology, and possibly obfuscating device and interface names, to safely provide the data to an untrusted party.
In general, a domain might offer different views of its topology with varying complexity and parameters, each targeted to a different class of applications. I think that's what Aurelin is shooting for, and I think it's a great idea. Anyway, here's what I think that sort of structure would look like: - Domain --- View (type = "monitoring") ------ Network Element ------ Network Element -------- Network Element ------ .... --- View (type = "controlplane") ------ Network Element ------ Network Element ------ .... --- View (type = "export") ------ Network Element -------- Network Element ------ Network Element ------ .... and so on and so forth.
Do we need a third "network" concept for grouping, besides (or instead of) "domain" and "view"? If so, what would be the relation between devices and such "network" and how is that different from "domain" or "view"?
I'm on the fence as to whether we need a separate "network" concept. We might need to model administrative domains that run multiple independent networks. Examples: the GEANT testbed network vs the GEANT production network, or ESnet Science Data Network vs ESNet IP core vs ESnet optical testbed. Devices may belong to multiple of these "networks", too. I kindof think that each of these may be safely modeled as an administrative domain of its own, but that breaks the device->single domain relation. Or, we can describe each with its own View, which makes for a simpler schema but may not be 100% semantically correct. Any feedback is appreciated.
Did the IDC project made such choices already?
(My opinion: I like to see at least an (admin)domain object, and possibly a "view" object. I don't yet see a need for a "network" object different from a "domain" object. Nevertheless, Aaron presented exactly those two, and I love to hear that argument).
We haven't made hard choices per se. We're working on automatically "abstracting" network topologies for export. The abstracted view of the topology needs to be made persistent.. so we came up with a database construct similar to the above.