1. Data Modeling IETF68 - Prague
Dr. Michael Alexander
Department of Information Systems
Wirtschaftsuniversität Wien

2. Agenda Use Cases Problem Statement Backward Compatibility Scope
Core
Secondary
Non-in-scope
Functional Coverage

3. Agenda II Requirements on Others Approach Process Integration
Open Items
References

4. Use Cases Designing and Implementing Functional Coverage
Element Managers (EMSs)
Network Managers (NMSs)
Operations Support Systems (OSSs)
CLIs
Functional Coverage
Configuration
Alarms
Current-historical performance
Inventory
Accounting management
Security

5. Problem Statement
Every device, EMS, NMS, Alarm manager, inventory manager tends to have its
ITS OWN DATA MODEL
Popular access method focus
“we manage with SNMP, CLI, CORBA etc, “ …
NM sometimes secondary outside of carrier because of high cost of proper enterprise NM
Flatness of SMI/MIBs
Try building a multi-device EMS/NMS from it …
Behavior weekly expressed in MIBs
Time it takes to model a new device, add additional release support is excessive

6. Problem Statement II
"Although some positive sentiment was expressed for defining a kind of "super SMI" metalanguage to aid in the definition of a general API, it was not clear whether the current crop of supporting protocols had sufficient semantic commonality to be used in this way. The matter remains open for investigation."
Vince Cerf RFC 1109 (1989)

7. Backward Compatibility
Axiom:
Backward compatibility with MIBs SHALL be preserved
Building on MIB base
Man hours in existing MIBs ...
Conversion of MIBSs to DM Models
Into namespace, free form variant
Reverse imports of DM Models into MIBs not feasible

8. Independence from Access Method
Data Models need to be independent of access methods
„Talking to a device via SNMP || CLI || NETCONF || CORBA || XML-RPC || Batch Config Transfer“ is relatively insignificant in time/resources relative to designing-implementing-maintaining data models ...
A clean data model of a 5000 managed objects device can be talked to in ANY of the above access methods provides the device has an agent that exposes the objects

9. Scope: Core I Initial focus: Must: Equipment hierarchy
Rack/ Power supplies/ shelf/ slot/ port/ facility/ protocols…/ services
Must: Base network types: IP, SDH/SONET, ATM, Ethernet
Proposed initial focus: IP-Routing, Ethernet, SDH/SONET, ATM
Proposed initial services: Barebones SIP, Ethernet VLANs, DiffServ (as a service in the models)

10. Scope: Core II Layer Description Layer VII
Device/Line/Service/Protocol Instance
Layer VI
Device/Line/Service/Protocol Model
Layer V
Device/Line/Service/Protocol Type Meta Model derived from class model
Captures behavior, rules
Layer IV
Device/LineService/Protocol Class Meta Model
Alarm template class model
Layer III
Namespaces/Meta model (realize definition files, build NM)
Derive from existing CLI (option?) or design anew
Constructs etc.
Alarm template meta model
Layer II
Object Model (prototype methods-operations, data types)
Layer I
Access Method (snmp, cli, netconf, cmip, corba, xml-rpc, soap ...)

11. Scope: Secondary Unique equipment/line locator
Schema for it
Registry
- tirks providers (function code)
Alarm template registries
Protection, failover modeling (1+1, 1:n, 1:1, etc.)
Device/service/protocol models to be defined in the respective areas / WGs
Needs namespace/metamodel
Otherwise chaos results …

12. NOT in Scope Business Support Systems (BSS) Workflow
Trying to solve the remaining 20%“ to 100% of networks/services from the onset ...

13. Requirements on Others-Dependencies
No initial requirements but of:
Netconf RPC/method call
Coarse grained operations on the device’s protocol agent significantly reduce level of complexity: provision_subscriber () vs. 100 Sets …
Consecutively elegant integration into protocol specifications natural
Management gets much easier for protocol designers if Protocol Class Meta Model is derived from

14. Approach Talking Points
"80% easier to understand, 90% less time", VERY SIMPLE upper layer models …
Applies if you have thousands/ten thousands of NEs and small …
Not a monolithic model ...
No device class/service xsds etc. without meta models …
Leave 100% to all-inclusive models …
Process is crucial ...
.net example ...
Fostering exposure of methods in NEs …
One draft rules them all does not work here …
Many folks not used to meta modeling …
Overspecify ...
Good expressiveness necessary ...
Good but not perfect coverage, completeness, correctness … Iterate …
Not going to solve the world … but 80% of it ;)
Human readable schemata and models a key criterion
Models will do some things like IP very well …
Use of 2-3 sample stacks: e.g. ATM stack or Site-to-Site IPSec Tunnels/POS/MPLS/SONET-SDH …
Sensible abstraction, decomposition where necessary …
integration-produce something that fits together …
importance of meta models/frameworks ...

15. Process-Cycle Time
Complexity is significantly higher than for many protocols (not TCP)
Just as much an organization and process exercise
Expected high intial flow of changes until steady-state, still comperatively many changes as part of regular process in regular update cycle
Device/Line/Service/Protocol Models should be shifted to respective areas
Branches
Folding of normative schema extensions into main as much as possible
Allow private branches
Allow specialization without folding
Target time: 1 year for first iteration
Cycle time:
Device/Line/Service/Protocol Instances: on discretion of equipment/nm vendors
Device/Line/Service/Protocol Model: initial: 6 months, steady-state 6 months
Synced with protocols
All meta models: initial: 6 months, steady-state 8-9 months
Object model and data types: initial: 6 months, steady-state 3-4 years or longer

16. Open Items Rules language State model inclusion and language
(1) and (2) .. equivalent to not having reached the moon and wanting to go to another galaxy ...

17. Towards a BOF Terminology Is the problem worth working on
In NM time gets wasted when differing terminologies are used ...
Is the problem worth working on
Is the problem defined well enough
For a BOF …
Creating layer V models first is futile
need to be converged …
Jumpstarting the effort:
e.g. basing it on IOS/JUNOS CLI (evaluate legal, practical possibility)
MIB to XML conversion to be formalized NOW
<draft-chisholm-netconf-model-06.txt > is close to a Layer II object model
Should a BOF be held at IETF69

18. References
RFC SMI RFC SNMP RFC Concise MIB Definitions RFC XML Schema RFC Netconf W3C Namespaces in XML, 1999 W3C XML 1.0 4th Edition, 2006 <draft-alexan-datamod-00.txt> <draft-atarashi-ngo-consider-architecture-00.txt> <draft-chisholm-netconf-model-06.txt> <draft-okita-ngo-diffservdatamodel-00.txt> <draft-iijima-ngo-vlandatamodel-00.txt> <draft-romascanu-netconf-datatypes-01.txt>