Re: Network Management


Glenn Trewitt (trewitt@miasma.stanford.edu)
23 Nov 1987 2344-PST (Monday)


[Sorry about the long note, but I've been waiting to hear a statement
from the NetMan vendors subgroup to hear just what it is that's going
on. Now I've heard, so now I have something to comment on.]

Fascinating. All of this talk about what CMIP privides.

When listening to the two main proponents of CMIP in the Network
Management meetings (up until the last one, of course, which I did not
attend), I have heard a lot of statements about what "CMIP Provides".
Yet the proposals about what CMIP is to do are constantly changing.

At the last meeting in Tokyo, where CMIP was to be voted up from its
current "Draft Proposal" status, it was rejected. My understanding is
that this was the second time it was rejected, and that there is
considerable dissent about just what CMIP will do, and how will it do
it.

Nowhere else but at the NetMan meetings have I heard such definite
statements about what CMIP "is" and "does" and "provides". In talking
to some people at Sydney University, I heard estimates of 3-4 years
until the ISO monitoring effort produces anything concrete. Surely
they aren't TCP/IP lackeys? I do know them to be very practical,
however.

While I understand the vendors' concerns, I don't agree with the way
these concerns color their outlook on ISO migration and short- to
medium-term managment solutions.

The only thing that ISO management offers that is not included in
monitoring proposals such as HEMS or SGMP is an overall architectural
definition. This architecture defines the framework that monitoring
protocols (such as CMIP or HEMP) operate within. There is no reason
that HEMS can't fit into the ISO framework. Many hours were spent
discussing how that could be done. Some members of the committee
refused to accept the notion that HEMS could conform to the
architecture, even though the protocol looks quite different than CMIP.
Or, I should say, "what CMIP currently looks like".

Architecture aside, the two protocols provide similar services (HEMS
offers some not in CMIS). Both will require two major implementation
efforts, and each of these efforts will require far more effort than
the implementation of HEMS, and probably even more than CMIP.

1) Servers for extracting data from protocol implementations (kernel
data structures, etc). Interfaces between protocol modules and the
server will be at a very low level and likely will be peculiar to the
OS primitives available. There is far more dependency upon environment
here than upon the querying mechanism (HEMP or CMIP).

2) Application programs for manipulating this virtual data base.
These include programs to keep track of what's going on in the network,
systems to produce coherent summaries of network activity from many
points of view, specialized "assistants" to help ferret out problems,
and finally, programs to do high-level control operations, rather than
mucking around down in the dirt. None of these applications depends in
the slightest upon the underlying monitoring protocol, except at the
very lowest subroutine call level.

This is all a lot of work, and it completely overshadows the cost of
implementing either of these protocols, much less migrating from one to
the other.

But there is one difference between the two systems. HEMS is specified
now, and CMIS isn't. Plus, CMIS may not be recognizable as CMIS by the
time it is nailed down. Defining a network management on the basis of
a protocol that changes several times a year simply means that the
Network Management WG will end up defining yet another protocol,
something that was NOT in its original charter.

Please note that I have not touched upon the technical merits (or lack
thereof) of either system. As one of the authors of HEMS, I am quite
biased about which one I prefer. I do, however, feel that the
decisions that Craig and I made in designing HEMS have been validated
by Craig's implementation experience. This is something that can't be
said of CMIS, which is strictly a paper design right now.

If anybody is interested in a discussion of the technical aspects of
the two systems, I would be happy to oblige.

Another issue I would like to see explored is the apparent domination
of the Network Management WG by the "vendors", to the exclusion of the
"non-vendors". My impression is that there is a lot of writing going
on right now, none of which I am seeing discussed in the open forums
available for it (such as available for it (such as netman@amadeus or gwmon@sh.cs.net). I
never heard a word about the meeting, except second hand, by accident.
What I did hear is that it specifically excluded non-vendors. Now, I
suppose that it's fine for vendors to share their concerns with each
other, but it seems like a rather dramatic change of course happened at
that meeting. Several of the people in attendance had never attended a
NetMan meeting before, and several people (including myself) who had
attended the meetings from the beginning were excluded.

Since when have vendors been in charge of (pre-)defining Internet
standards?

        - Glenn Trewitt

P.S. I'll probably regret this in the morning. :-)



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:57 GMT