Getting to a NetConf Data ModelConsiderations

Andrea Westerinen

Model Development

Two very different aspects of a NetConf data model exist – Semantics and rendering– Each has their own requirements and restrictions

Semantics (English text, UML, ??) -> Rendering – Model dictates content – Language constructs and rules dictate the

rendering

Model Considerations

Scope and coverage Modeling concepts and principles One model, several models, any model, no

model but just translations?

Element or Environment?

Scope may be limited to a single element AND/OR may address the "big picture“, diving down into specific components when necessary

– Example: 20 second access to critical data - Is the problem in the server, the network, the storage or all three?

– To answer, need element details, and information on the interactions between the elements and business priorities

Configurations may span many elements– Desirable for all the elements to understand the "larger"

business goals and how they fit into accomplishing these goals

– Ideally, equipment understands the same config commands– Example: Failing over from LA to Chicago

Other Modeling Questions

Configuration and/or general management – For example, supporting root cause analysis

Relationships – Usage, component, …– General abstractions but specific implementations

Design for evolution and extension (std + proprietary) Only about data, or also about operations

– Not the general NetConf operations, but domain-specific operations with parameters (ex: CreateOrModifyStoragePool)

Is it desirable to fit all the pieces together into a single conceptual model?

Modeling Goals

Predictability– Once the model is learned, the location of specific

data is maintained and therefore "predictable"

“Stable” semantics that can be specialized and extended

Reuse of the model versus redefinition

Conclusions

Broad abstractions exist and have been defined in general models such as DMTF's CIM

– Address backward compatiblity, defining relations, naming, id, access control, etc.

Businesses operate against normalized semantics across many management domains (compute, network and storage)

– Need to scale those semantics to the appropriate scope (whether component, system, groups of systems, enterprise or Internet)

Acceptable to define the model in pieces, but the pieces must not contradict

Build on existing semantics + standards (not recreate)