MIB quality WAS Re: Basic Question....
James Smilanich
Karl;
I think you're making my arguement for me. If a company can't
develop a proprietary MIB, why NOT use an RFC compliant one? Assuming,
of course, one exists for the type of equipment that you are interested in.
Jim
Karl Auerbach (ka...@cavebear.com) wrote:
[snip]
:
: This is getting away from scripts/Java/etc... but...
:
: A lot of devices are hardly SNMP compliant -- some aren't even IP complant.
:
[snip]
:
: And mib implementation quality isn't steller either. I daily use devices
: that have agents that have mib items that they don't bother to increment.
:
--
Jim Smilanich | "A man should be able to pilot a starship, plan an
jsm...@winternet.com | invasion, diaper a baby..... specialization is for
Winternet is my access | insects!" -- Lazarus Long
provider, so don't blame|
them for my opinions! |
Karl Auerbach
>
> I think you're making my arguement for me. If a company can't
> develop a proprietary MIB, why NOT use an RFC compliant one? Assuming,
> of course, one exists for the type of equipment that you are interested
> in.
It's amazing how many folks haven't even got the full system group of
MIB-II. Experience has indicated to me that, one should not depend on
having even the standard groups being properly implemented (or complete.)
--karl--
Telfo...@aol.com
In a message dated 96-06-10 10:22:21 EDT, jsm...@winternet.com (James
Smilanich) writes:
> One MAJOR reason a vendor would never make my short list during an
> evaluation cycle. Am I really alone in insisting that my vendors do the
> job right? :(
>
No, but there is a serious trade-off in getting products out within
scheduled time-frames. Should I license agent software from
a firm which has continually proven to provide buggy code and
which will force us to spend a lot of time in debugging, should the
engineer start from scratch, or should we start with some public
domain distribution which will have its own problems? In any
of the cases the last bug is never removed, QA can only extend
the mean time until the next bug is found.
And then there are occasionally issues exactly what the nature
of the bug is.
In MA, Baybank supplies a large fraction of ATMs. Passwords
have significance to 6 digits but may be longer. Mobil stations
accept Baybank debit cards, but used to reject full passwords
when they were longer than 6 digits because only 6 digits were
significant. Which organization was in violation of the spec?
The architecture of SNMP in comparison with web server
based approaches seems to lend itself to this sort of problem.
For VLAN routers such as Cisco, Xylan and TTI provide,
the definition of MIB variables with respect to interfaces
and bridging can quite reasonably be described
as completely broken. Doing the job right in the face of
such confusion can be problematic.
Joachim Martillo
Inventor of the VLAN
President
Telford Tools, Inc.
"Garage Mechanics for the I-Way"
17 Pleasant Hill Ave.
Dorchester/Mattapan, MA 02126-2813
V: 617-298-1617
F: 617-298-1745
E: Telfo...@aol.com
James Smilanich
Karl Auerbach (ka...@cavebear.com) wrote:
: It's amazing how many folks haven't even got the full system group of
: MIB-II. Experience has indicated to me that, one should not depend on
: having even the standard groups being properly implemented (or complete.)
One MAJOR reason a vendor would never make my short list during an
evaluation cycle. Am I really alone in insisting that my vendors do the
job right? :(
James Smilanich
Telfo...@aol.com wrote:
: In a message dated 96-06-10 10:22:21 EDT, jsm...@winternet.com (James
: Smilanich) writes:
: > One MAJOR reason a vendor would never make my short list during an
: > evaluation cycle. Am I really alone in insisting that my vendors do the
: > job right? :(
: >
: No, but there is a serious trade-off in getting products out within
: scheduled time-frames. Should I license agent software from
: a firm which has continually proven to provide buggy code and
: which will force us to spend a lot of time in debugging, should the
: engineer start from scratch, or should we start with some public
: domain distribution which will have its own problems? In any
: of the cases the last bug is never removed, QA can only extend
: the mean time until the next bug is found.
[snip of ATM card password problem. I don't know the spec, so I don't
feel qualified to respond. Besides, I'm not sure what it has to do with
SNMP. Joachim?]
: The architecture of SNMP in comparison with web server
: based approaches seems to lend itself to this sort of problem.
Can you tell us why you think so?
Keep in mind that I was responding to Karl's note about companies
that still were unable to even get MIB-II out the door correctly. Not
minor bugs, but seriously broken implementations. In my mind, that is an
indication of a company that just plain doesn't have its act together.
That is not meant as a slam at you or your company. You have
chosen to go with a different approach and avoid SNMP altogether. You
have every right to do so. I don't agree with you, but that is a
different issue from a company that can't pick up public domain code that
has worked for quite a while (MIB-II) and get it ported correctly. If a
company can't even do that, I personally would have a hard time trusting
any of their code. That is why I said that such a company would not make
my short list during an evaluation cycle.
: For VLAN routers such as Cisco, Xylan and TTI provide,
: the definition of MIB variables with respect to interfaces
: and bridging can quite reasonably be described
: as completely broken. Doing the job right in the face of
: such confusion can be problematic.
If there are no standards written for managing VLAN using SNMP
yet, I am not surprised that they have chosen enterprise specific
solutions. However, once a standard is available, I would insist that my
vendor support it. Either that, or I would take my dollars elsewhere.
James Smilanich
Telfo...@aol.com wrote:
: In a message dated 96-06-10 15:03:13 EDT, jsm...@winternet.com (James
: Smilanich) writes:
: I read the non-sense about cell-switch routers -- I guess the next
: forthcoming
: standard -- and I doubt whether it will ever work, but it may become a
: standard.
Care to say why?
: My approach is correct, and when I have product, I may try to have it
: standardized. In any case, I am making sure it will interoperate with
: all current ATM implementations as I have done with my VLAN router.
: I would think such approach makes far more sense to the customer.
: After all OSI has clearly demonstrated that implementations completely
: compliant with the standards often do not interoperate.
Too true. However, I don't place SNMP in that category. In my
experience as an end user SNMP works fine if both the NMS and the agents
behave correctly.
In another posting, you mentioned that you regarded the SNMP MIB
for something else as broken, and the implication was that you also
regarded SNMP itself as fundamentally flawed. (I hope I'm not mangling
your meaning too much in my paraphrasing.)
So far, I have seen several assertions from you regarding SNMP vs.
HTML, but no concrete analysis or real world examples that I can relate
to. I would really like to know why you think SNMP is such a bad choice,
but so far I'm having a hard time understanding your position. If you
don't mind, please try to put together a bullet list of the pros and cons
of SNMP vs. HTML. If we have made the wrong choice as concerns management
tools, I want to know.
Telfo...@aol.com
> If there are no standards written for managing VLAN using SNMP
>yet, I am not surprised that they have chosen enterprise specific
>solutions. However, once a standard is available, I would insist that my
>vendor support it. Either that, or I would take my dollars elsewhere.
I am somewhat baffled by this fixation with standards. Using standard
solutions makes sense when it makes sense. For this reason OSI
is essentially dying a lingering death.
I read the non-sense about cell-switch routers -- I guess the next
forthcoming
standard -- and I doubt whether it will ever work, but it may become a
standard.
My approach is correct, and when I have product, I may try to have it
standardized. In any case, I am making sure it will interoperate with
all current ATM implementations as I have done with my VLAN router.
I would think such approach makes far more sense to the customer.
After all OSI has clearly demonstrated that implementations completely
compliant with the standards often do not interoperate.
Joachim Martillo
Telfo...@aol.com
> That is not meant as a slam at you or your company. You have
>chosen to go with a different approach and avoid SNMP altogether. You
>have every right to do so. I don't agree with you, but that is a
>different issue from a company that can't pick up public domain code that
>has worked for quite a while (MIB-II) and get it ported correctly. If a
>company can't even do that, I personally would have a hard time trusting
>any of their code. That is why I said that such a company would not make
>my short list during an evaluation cycle.
Actually, we do support SNMP, and this implementation has
gotten high marks in compliance in the past. The model of
packet switching devices which the MIB designers had
was problematic and makes representing the configuration
and statistics of ours and other devices somewhat less
than perspicuous.
A web server approach helps to avoid the problems associated
with the limitations of the standard MIBs and the basic problems
associated with the SNMP SMI.
There is a basic problem in a standards based approach
when the standard, like MAP and many parts of ISO
OSI, belong more to the problem set than to the solution
set.
Tim Taylor/GB/3Com
Here's an idea, what about writing some cgi-bin program/script that performs
some simple segment auto-discovery and creates an HTML "map" of the deivces on
the users local net. If these devices were then managable
(configured/monitored) via embedded HTTP/HTML agent servers, a user could
follow a link from the 'map' to the device, and back.
A bit Heath Robinson?
Tim
George McKee
Aware that even angels have been burned in this discussion, I'll contribute
a customer's perspective.
Joachim Martillo <Telfo...@aol.com> wrote, among other things:
>
> I am somewhat baffled by this fixation with standards. Using standard
> solutions makes sense when it makes sense. For this reason OSI
> is essentially dying a lingering death.
>
It appears to me that many people forget the layered nature of protocols,
and end up advocating or dismissing a single layer as the universal cure
or universal disease. SNMP normally has 4 layers: a transport layer (UDP),
an encoding layer (BER), and data representation layer (ASN.1) and a
content layer (the MIBs).
HTTP is a transport layer; it seems straightforward to me to define a new
MIME type (and possibly a new encoding to replace BER) that would permit
the delivery of SNMP data and content by a Webserver. This would of course
not help anyone except those who need to get UDP through an application-level
firewall that prohibits UDP, and who could use SHTTP to protect the
content of data elements. The enormous overhead of HTTP-based connection
setup and teardown makes this a crazy idea.
HTML is a display language. It has nothing to do with communication between
a network management station and the managed devices and everything to do
with communication between the management station and the user. HTML would
be a fine method of programming the user display, replacing the X Window
System protocols and widget libraries or Microsoft's Windows API, but it
shouldn't be confused with a means of representing and modifying the
configuration state and operational state of a device.
In my view, SNMP's greatest achievement is in its definition of a standard
data representation language, including the design tradeoffs that must be
made between implementability and expressive power. In the process of
making that tradeoff, the SNMP designers gave up significant expressive
power, which has made Martillo's life difficult given the products he's
chosen to develop. CMIP used a more expressive version of ASN.1, and
paid for it with an almost insurmountable implementation barrier. But
replacing a standard data representation language by none at all, and
replacing the network management station by a user interface based on
vt100/telnet or HTML/HTTP makes the life of the administrator harder
rather than easier.
Why is this? Because configuration and diagnosis are only two thirds of
network management. The final third is monitoring, and human staff are
too valuable to spend their time looking at displays with thousands of
lights and meters trying to figure out if everything is all right.
Staff get bored and distracted, and need sleep sometime. They should
spend their time on interesting work like enhancing the system and
solving problems, not staring at displays in a Homer Simpson-ish daze.
Network monitoring must be automated, and thanks to SNMP and network
management stations, Compaq's IM Enterprise Management Center looks
nothing like the control room of a nuclear power plant. Thanks to
standard data representation and encoding languages, the effort involved
in adding another vendor's device to our monitoring systems is not
overwhelming. Thanks to standard data representation and encoding
languages, we have 6 displays in our EMC instead of 20, and still make
an effective presentation of the status of our hundreds of servers and
hundreds of routers and concentraters. The EMC managers, however, are
still unhappy, because they want ONE display that shows the consolidated
state of everything. In Europe and Asia, as well as the Americas.
And they would like to include tens of thousands of PCs if it's not
too much to ask, please.
Now ASN.1 has its limitations, and you might think that an RPC-based
protocol might work better; after all they have encoding layers (XDR)
and data representation languages (IDL), so they should support monitoring
automation. But we've tried RPC-based monitoring products, and they don't
work in an environment of our scale. I have great sympathy for the
network providers who want to manage portions of tomorrow's Internet,
with millions of nodes rather than thousands.
What is needed for scalability is a standard architecture that can
sustain hierarchical layering, in which management stations can autonomously
exchange information about structure changes as well as status changes.
Object-oriented languages such as Java are a step in the right direction, but
Java (and even JavaScript) don't have dynamic class management, in which
an executing program can revise its own subclassing structure without
invoking a compiler. Nor am I convinced that one can do without
multiple inheritance. Python has these features, but has other
idiosyncrasies that make it unacceptable. Scheme and its cousins
are too amorphous, but I like their formal semantics, which is important
for proving network-critical code correct.
Protocol design and language design are both difficult subjects on their
own. When they merge in the form of standard protocols for communicating
changes to network descriptions, things get doubly difficult. But we need
this stuff ASAP, if not sooner.
Cheers,
- George McKee
--
Job:Systems Programmer, Corporate Internet Infrastructure, Compaq Computer Corp.
Internet: mc...@imail.Compaq.com
X.400: N=George McKee/C=US/A=Infonet/P=Compaq/O=IM Hou/OU=Sys Soft
Voice: +1 713 518 7991 Fax: +1 713 514 2236
USPS: Compaq Computer Corp., P.O. Box 692000 M020303, Houston TX 77269-2000 USA
Disclaimer: if I'm wrong, it's not Compaq's fault....
Geoff Carpenter 8-862-1970
Ref: Your note of Tue, 11 Jun 1996 13:19:06 -0400 (attached)
>Network monitoring must be automated, and thanks to SNMP and network
>management stations, Compaq's IM Enterprise Management Center looks
>nothing like the control room of a nuclear power plant.
Once upon a time when we had decent IS support, our local networking
staff maintained their awareness of the state of the infrastructure
through alphanumeric pagers they carried with them. They did not
stare for hours on end at displays but instead roamed at will while
being kept abreast of problems and their resolution.
For it to be feasible, the software had to pinpoint the point of failure
and not flood the staff with pages about devices that were unreachable
merely because they were behind a device that had failed.
It worked quite well. Wish I could take credit for it, but it was
Rob Lehman (now at ANS) who designed and implemented that application.
>I have great sympathy for the
>network providers who want to manage portions of tomorrow's Internet,
>with millions of nodes rather than thousands.
>
>What is needed for scalability is a standard architecture that can
>sustain hierarchical layering, in which management stations can autonomously
>exchange information about structure changes as well as status changes.
>Object-oriented languages such as Java are a step in the right direction, but
>Java (and even JavaScript) don't have dynamic class management, in which
>an executing program can revise its own subclassing structure without
>invoking a compiler. Nor am I convinced that one can do without
>multiple inheritance. Python has these features, but has other
>idiosyncrasies that make it unacceptable. Scheme and its cousins
>are too amorphous, but I like their formal semantics, which is important
>for proving network-critical code correct.
Been there, done that, sold it. Back in 1990, we were commissioned to
develop network management tools that would scale to handle the
hypothetical NREN. In 1991, the core of the technology was selected for
OSF's DME...but subsequently pulled to prevent it from competing with
with software licensed from a third party. It was used in IBM products
and licensed to IBM customers on a special request basis, but in 1995
Affiniti Group International acquired an exclusive license to all of
the NSFNET-derived network management software IBM Research developed.
In 1992, we published a paper describing how the transparently
distributed nature of the technology could be used to exploit pools of
processors (Lehman, et. al, "Concurrent Network Management with a
Distributed Management Tool", USENIX LISA VI, October 1992). While
the numbers are obsolete today (1,300 threads created per second in 1992
on a RISC System/6000 Model 560 compared to 11,000 threads created per
second on a 166 MHz Pentium today), I haven't seen another technology
surpass what we developed for the NSFNET back then.
The paper briefly touched on the support for multiple inheritance,
tagged data, "primitive" data types such as sparse arrays, associative
arrays and native language messages, but I don't recall it mentioning
the support for reflection, meta classes or dynamically loadable
architecture-neutral object code. If you want a copy of the paper,
I can provide it.
It's dangerous to draw conclusions, but it sounds like the capabilities
you are looking for are in what we put into production use back in 1991.
You can't get it any longer from IBM Research, but if you really have
need for a transparently distributed object-oriented system that was
developed to manage what was to be the core of the Internet, you might
contact Affiniti Group International (908-872-2240) and ask them about
it...
Geoff Carpenter
IBM Research -- Yorktown Heights, NY