Re: SNMPv2's properties

[Bob Stewart <[e-mail]>]

>Yesterday's note seemed to have touched off a small firestorm (or at least
>twinged a nerve or two). Speaking as a commercial user that uses SNMP as
>a means to an end rather than an end itself I have some questions about the
>direction of this technology.

OK.  I'll bite, although "means to an end rather than an end" sounds
suspiciously like starting of with a questionable attitude.

>"The success of SNMPv1 has brought us a problem because our customers
>expect it in everything and they don't expect any cost or performance
>impact because of it. 

They require education.  There is no free lunch.

>We are now looking at systems where there might
>be thousands of managed nodes and several management stations and it is
>clear that the current methodology is just not going to work. On the
>surface v2 looks as if it is extending current methodology without
>addressing these performance issues.

Current methodology indeed has its problems, but that methodology is only
partially dependent on the protocol.  It is far more dependent on the
assistance and intelligence available from then managing systems.  They
represent the more significant failure in methodology, as they do not well
exploit SNMPv1's existing abilities for distribution of control and
monitoring.  A MIB browser or a graphical view of a front panel do not
constitute high-level network management.  Likewise, a NMS that concentrates
all its polling from itself becomes a bottleneck in its own processes.

>"What we need is somthing that has these properties:-
>
>- A low processing and storage overhead in each managed node.

Exactly the thrust of SNMPv1 and SNMPv2.

>- A reliable communications mechanism between the manager and the
>        managed node.

Unless you want to add hardware, you can't get more reliable than acknowledged
datagrams.  Virtual circuits are not more reliable, they simply hide the
retransmissions and acknowledgements.

>- An ability to originate management reports from the managed node (i.e.
>        eliminate polling).

You can implement SNMPv2's Manager-to-Manager MIB in a managed node or a
mid-level manager, for some cost against low overhead.  Having done so, you
can eliminate some polling, but you still need to know if the thing is alive.
"I'm dead" reports have a way of not being sent.

>- An ability to work with several management stations in a controlled manner.

Check.  SNMPv1 and SNMPv2 both have that via MIB objects in the right places.
SNMPv2 includes some standardized objects to help.

>"These problems are not new and seem to have been addressed by IBM in its
>LAN management scheme. ( (a) is this CMIP? and (b) I will wash my mouth
>out with soap in a minute. )

CMIP fails on your first property and adds little or no value (or perhaps
loses) on the others.  What sort of soap do you prefer?

>"Current SNMP has two major failings - its got a low information to overhead
>ratio and its designed to be polled. Its locus of control is also the
>management station so it lacks the inherent capability to support multiple
>managers. 

I won't step any further into the polling tar pit.  The locus of control
properly belongs with the managing systems.  SNMP supports multiple managers
just fine.  Exactly what do you believe it is missing?

>These are significant issues and they could be at least as
>important as notions like security. Does v2 address them?

True.  Yes.

	Bob