[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: Re: [RMONMIB] I-D ACTION:draft-ietf-rmonmib-raqmon-pdu- 08.txt]
On Fri, Jan 14, 2005 at 07:08:34PM -0500, David B Harrington wrote:
> > In SNMP terms, they needed to implement a notification originator
> > application, something the SNMPv3 architecture rightfully allows
> > these days.
>
> And there was only one application generating the notifications? That
> would not trigger the scalability issue I am concerned with.
A few. As I wrote, this was test equipment for cellular networks
which was feeding every few minutes at best events into an event
driven manager. BTW, another example are probably the many scripts
running on tons of Unix boxes calling "snmptrap" somewhere to feed
something into a management system. Even operators write this stuff
sometimes.
> > I think this is a clear example demonstrating that
> > (a) the SNMPv3 architecture got it right to split managers and
> > agents into smaller functional pieces
>
> Agreed.
Good.
> > and that (b) dogmas such
> > as "you have to do trap-directed polling" seriously restrict
> > very valid usage of SNMP technology.
>
> I don't think we should restrict SNMP to trap-directed polling; I
> think we should discuss when and how event-driven management with SNMP
> is acceptable, and identify the scalability issues of the approach.
> Before we publish guidelines that seem to encourage its usage, we need
> to be sure the usage doesn't cause problems, and without some guidance
> about HOW to use it, and HOW NOT to use it, I think we would be doing
> a disservice to the SNMP community.
This is the core of the problem - the SNMP community has a tendency
to prevent the usage of the technology unless it is very very very
sure people use it in exactly the way it was supposed to be used by
some "SNMP correctness committee". A high-level discussion <quote>
how event-driven management with SNMP is acceptable</quote> is IMHO
a waste of time. There are valid scenarios I can write down where
this is useful and that is I think sufficient to post the "two
character" errata. Everything really depends on the specificis of
the given problem and I fail to see that you can abstract the
specifics of the problems away and still come to useful conclusions.
The RMON example that triggered this discussion does in my view _not_
primarily have a problem with sending a stream of notifications - I
think they can even tolerate some loss. The proposal fails (in my
view) on the efficiency/simplicity side.
/js
P.S. The MIB review guidelines have text about notifications and
throttling in section 4.7 and I believe this is about right
in what we need. This paragraph documents understood "best
current practice". If you think something is missing, feel
free to send concrete text.
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany