Getting to a NetConf Data Model Considerations 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)