[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: NIM requirements/conventions (was Re: Methods in the NIM requ irements)


Sent: Sunday, May 07, 2000 5:09 PM, Harald wrote:
> At 15:43 05.05.2000 -0400, Weiss, Walter wrote:
> >My view here is that the model is not describing the system 
> per se. Rather,
> >it is describing the interfaces for interacting with 
> (determining the status
> >and changing the the operational characteristics of) the system.
> to me, this is a system description that just happens to not 
> include a 
> description of what cannot be seen through the interfaces.
I'm ok with this interpretation. As I implied in my previous mail to John,
what we desperately need right now is a set of management interface
definitions that is consistent across all the management protocols/paradigms
being deployed currently. The fact that there are other interfaces to
systems that are not used for management (like the ones I described between
Routing and RSVP in my last mail) is interesting from a modeling
perspective, but a distraction from the current set of problems that we need
to tackle right now. I would not be opposed to expanding the model in
subsequent iterations of the model to expand the model to encompass more of
the system. Nor do I see the same set of issues with methods that I
described in the management interfaces.

> >If we bias the model strongly towards deployment through APIs, we
> >would be inclined to use methods pervasively because 
> programmatic interfaces
> >are defined in terms of function calls. If we were to bias the model
> >strongly towards repository oriented applications, we would 
> strongly favor
> >an attribute model.
> Once we need to describe the characteristics of the system 
> when a specific 
> implementation strategy is used, that strategy is part of the 
> characteristics of the system, not an implementation strategy.
> It is (I think) not possible to implement a "pull" model and 
> a "push" model 
> of a network function that give a network with exactly the 
> same external 
> behavior, unless that behavior is very simple.
> The typical modelling hierarchy is where
> +-----------------------------------------+
> | traffic-engineered network              |       "user"
> |                                         |<------interface
> +-----------------------------------------+
> can typically be implemented as both
> +-----------------------------------------+
> | +------------+ SNMP    +-------------+  |       "user"
> | | controller |-------> | routers     |  |<------interface
> | +------------+         +-------------+  |
> +-----------------------------------------+
> and
> +-----------------------------------------+
> | +------------+  LDAP   +-------------+  |       "user"
> | | repository |<------- | routers     |  |<------interface
> | +------------+         +-------------+  |
> +-----------------------------------------+
> but the implementations will probably have characteristics that
> are different, and observably so.
> I think we need model description methods that fit well with both the
> "inner" system and the "outer" system of all 3 drawings above.
I agree. That is why I suggested that we add the requirement that we
consider the possible management paradigms as part of the model. That way,
if we conclude that a specific part of the model is not viable for a
specific paradigm, we can specifically say so and describe what, if
anything, must change in order for that part of the model to be

> >So we have to ask ourselves a question. Do we assume that 
> the protocols (and
> >paradigms) will be altered to fit the ideal info model or do 
> we adjust the
> >info model to optimize the mappings to the broadest cross-section of
> >paradigms and protocols/repositories/programmatic interfaces.
> I would posit that the issue is different:
> The *world* will not change to accomodate our info model.
> The info model needs to be able to describe real systems.
> If we can abstract from that modelling exercise changes to 
> the protocols we 
> use that will make the world a better place, by making our 
> networks easier 
> to operate, those changes will hopefully be made.
> But a modelling tool that cannot describe the real world at 
> some level of 
> abstraction is not terribly useful.
> My opinion.
This is fair. I would suggest that some of the concepts inherent in
information models (for me, particularly inheritance and containment) make
the world a better place. If we use these, we can expect protocols to follow
suit. However, you can't define an information model in a vacuum by
examining the system alone. My past experiences in modeling suggest that
compromises in the model are inevitable if the model is to be deployed over
existing protocols. The phrases "instance explosion," and "reference
explosion" come to mind. That does not mean that the model has to fit
perfectly into each paradigm or protocol. Rather, if there is a desire to
accommodate algorithmic mappings of the model to various
protocols/paradigms, the limitations in the algorithms also imply
limitations on the model. I would prefer to see us develop algorithmic
mappings to speed up the process of converting an info model into an SNMP
MIB or a COPS PIB. Otherwise, the mapping of the model to a specific
protocol may take longer than specifying the model. The mapping algorithms
in turn limit the flexibility and the full potential of information models.
Some type of middle ground must be found to make this endeavor successful.