RE: New draft and mailing list available on Information Modeling in the IETF

["Weiss, Walter" <WWeiss@lucentctc.com>]

Dan,

First off, let's be clear on what an information model is. An information
model is nothing more than an organization of information (data elements).
In other words, it is a data structure whose contents or organization convey
a set of predefined semantics. Therefore, an information model can be used
to represent any number of concepts including a procedure call, a policy, an
API, a data structure in a protocol, or a data structure within a method. A
data structure can be concrete or abstract depending on what the model is
being used for. In this context, the main difference between the modeling
activity we are proposing here and the one described in
draft-ietf-policy-qos-info-model-00.txt [PQIM], is that [PQIM] seeks to
describe QoS in abstract non-implementation specific terms, whereas the
model we propose seeks to instrument various services concretely.

Let me try this with an analogy. In [PQIM], everything is reduced to
conditions and actions. The conditions are based on the arrival of a packet
with particular characteristics while the actions are things that can be
performed on the packet. This could be considered akin to the meanderings of
a peanut through the digestive tract. The treatment of the peanut is a
function of many possible criteria: chemical composition, size, the number
of other peanuts ingested, etc. If you used the peanut as the basis for
managing the body, you would at least do a reasonable job at describing the
digestive tract. However, other components that influence digestive
decisions such as body fat and endorphin levels would be completely missing.
In addition, other components that we may wish to manage that are not part
of the digestive tract are beyond the purview of the peanut.

In contrast, the NIM proposal is attempting to instrument the various organs
from the perspective of the nervous system, which interacts with all the
systems in the body, not just the digestive tract. Further, we would like to
instrument the common elements of all nervous systems recognizing variations
in individual nervous systems will exist.

To move back to the world of routers we recognize that there are many
variations in the design of forwarding engines. It is assumed that where
commonality exists, a common model should be used and where divergence
exists, specific refinements to the model are required. As such,
configuration elements that are more general, like maximum queue depths, can
be instrumented in a general way and configured across a broad set of
devices while specific variations in forwarding engine design, like priority
vs. bandwidth queuing, can be instrumented and configured within a narrower
context of devices.

Therefore, the goal of this proposal is not to define configuration objects
in terms of any specific management model whether it is policy, procedural
(CORBA), directory based, agents, or web. Rather, it is hoped that this
model can be used for all these activities, hopefully reducing the effort
involved in standardizing interfaces for all these various paradigms.

Finally, we believe that [PQIM] seeks to start from the high-level (a UI)
and work it's way down. The model we are proposing is taking a bottom up
approach by defining interfaces first and allowing these interfaces to be
the basis for many possible configuration and management paradigms including
low-level policies. If [PQIM] moves forward, it would certainly be desirable
for this work and [PQIM] to meet somewhere in the middle. 

As to your question about algorithmic translation, we would like to define
the model such that it is easily mapped to a variety of different management
paradigms. Experience has shown that in some cases (for example the mapping
of CIM to LDAP), the mapping can be complex due to specific limitations
within the paradigm. This suggests that some mappings will be more difficult
then others. However, many of us expect at least a subset of the mappings to
be algorithmic.

I would also like to add that one of the key issues that many of the policy
related activities are struggling with is how to determine the capabilities
of a system. The problem is that capability determination exists at many
different levels. For example, we may want to describe the capability of a
switch to support DiffServ, or we may want to describe a capability as the
number of queues supported in an interface, or we may want to describe a
capability to indicate if a source UDP port numbers can be filtered, or we
may want to describe whether a filter supports a range or a list or a bit
mask, or even whether the bit mask is at the packet level or the field
level. The granularity of the policy will determine the granularity of the
capabilities that the policy relys on. We believe that an information model,
such as the one described in the requirements draft, can be used to define
capabilities at all the levels I have described above.

regards,

-Walter


ps. The draft has been posted to the internet drafts directory and can be
found at:
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-durham-nim-req-00.tx
t

Note possible URL wrapping in the line above due to variations in mailer
implementations.

> -----Original Message-----
> From: Dan Romascanu [mailto:dromasca@lucent.com]
> Sent: Tuesday, March 14, 2000 2:05 PM
> To: 'Weiss, Walter'
> Cc: 'nim@ops.ietf.org'
> Subject: RE: New draft and mailing list available on Information
> Modeling in the IETF
> 
> 
> Walter, 
>  
> I spent my morning reading your draft, and the QoS info model draft -
> draft-ietf-policy-qos-info-model-00.txt. Can you please comment on the
> relationship between the two? would the QoS Info model draft meet your
> requirements? What is not covered by this model draft?
>  
> My other comment is that the key lies in providing the tools for an
> algorithmic translation of the data model into a MIB, PIB, schema or
> something else. IMO, Draft-ietf-policy-qos-info-model-00.txt 
> defines a good data structure for the scope of modeling the QOS data
> and going to write for example an SNMP MIB is a trivial
> exercise. The problem is that I miss the part that describes 
> the device capabilities and I wonder how your proposal overcomes this 
> crucial issue.
> 
> Regards,
> 
> Dan
> 
> 
> 
> > > -----Original Message-----
> > > From:	Weiss, Walter 
> > > Sent:	Friday, March 10, 2000 5:00 AM
> > > To:	'ietf@ietf.org'
> > > Subject:	New draft and mailing list available on 
> Information Modeling
> > > in the IETF
> > > 
> > > In recent years, working groups have come under pressure to define
> > > multiple, parallel data structures for managing various 
> technologies
> > > (DHCP, DiffServ, MPLS, etc.) through different protocols 
> (SNMP, LDAP,
> > > COPS, etc.) and network management paradigms (directories, agents,
> > policy,
> > > etc.). A new mailing list has been established to 
> consider possible
> > means
> > > for reducing the burden on working groups by defining protocol and
> > > management paradigm independent configuration/management data
> > definitions
> > > that could subsequently be mapped to the various 
> protocols. To consider
> > > the viability of this approach and determine if there is 
> sufficient
> > > interest to create a working group, a new mailing list has been
> > > established:
> > > 
> > > mailing list : nim@ops.ietf.org
> > > [un]subscribe: nim-request@ops.ietf.org
> > > archive: ftp://ops.ietf.org/pub/lists
> > > 
> > > 
> > > In addition, a requirements document for a network 
> information modeling
> > > activity has been written and submitted to the IETF. This 
> draft can be
> > > found at
> > > 
> > > web:
> > > ftp://ftp.intel.com\/pub/outgoing/draft-durham-nim-reqs-00.txt
> > > 
> > > ftp:
> > > ftp.intel.com\pub\outgoing\draft-durham-nim-reqs-00.txt
> > > 
> > > regards,
> > > 
> > > -Walter
>