Getting to a NetConf Data Model Considerations

1
Getting to a NetConf Data ModelConsiderations

• Andrea Westerinen

2
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, ??) -gt Rendering
• Model dictates content
• Language constructs and rules dictate the
  rendering

3
Model Considerations

• Scope and coverage
• Modeling concepts and principles
• One model, several models, any model, no model
  but just translations?

4
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

5
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?

6
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

7
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)