Re: Alarms oddity ...

["Steven L. Waldbusser" <[e-mail]>]

Excerpts from mail: 4-Dec-91 Alarms oddity ... Robin [e-mail] (1744)
> Doing some testing on our alarms implementation I come across the following
> problem.  The problem only occurs when both rising and falling thresholds are
> equal.  What should be the behaviour when alarmValue stays equal to both
> thresholds.  Ours just started to oscillate (i.e. send alternate
> rising/falling traps on every interval) :-(.


This isn't a problem.  The threshold description in the MIB says:
>>	When the
>>	current sampled value is greater than or equal to
>>	this threshold, and the value at the last sampling
>>	interval was less than this threshold, a single
>>	event will be generated.

Let me emphasize "...and the value at the last sampling interval was
less than this threshold, ..."
If the value arrived at the common threshold value from "above"
("below"), the probe will generate a single falling (rising) alarm. 
Nothing more will be generated while in that state.
End of controversy?  (or else I missed something).

Excerpts from mail: 9-Dec-91 Re: Alarms oddity ... Gary
[e-mail].h (3087)
> If we allow risingThreshold to equal fallingThreshold, than that built
> in "hysteresis"
> disappears.  Of course its also true that 
> 	<risingThreshold == fallingThrshold + 1)
> doesn't give a whole lot more protection from "trap storms" than the
equality case.  

There is an important case where risingThreshold == 1 and
fallingThreshold == 0.  This is useful for a deltaValue of a counter
that is expected not to rise (such as an error counter).  A rising alarm
is generated when the counter begins to count and a falling alarm is
generated when it stops.  I took care to check the boundary conditions
for these rules specifically to make sure this mode was possible.

The concern about trap storms is valid.  The architecture of the alarm
group is quite stable because the traps are limited to one per second. 
Unfortunately, the other trap generated is the packetMatch trap, which
is inherently unstable in the "alwaysReady" state.  In this state, the
probe is very unstable and could accidently be triggered to generate a
packet for every packet seen on the wire.

The packet match trap could easily have been generated using an alarm
with risingThreshold == 1 and fallingThreshold == 0 (as I described
earlier).  This alarm could sample channelMatches or
bufferControlCapturedPackets.  When the MS gets the rising event, it can
begin polling for the captured packets (or other information) and stop
when it receives the falling event.  When RFC1271 comes around for
elevation to draft standard in roughly six months, I am going to lobby
for us to deprecate the unstable packetMatch trap and it's associated
logic and replace it with this mechanism.


Steve

P.S.
Excerpts from mail: 10-Dec-91 Re: Alarms oddity ... Robin
[e-mail] (1527)
> If we go for this one then we'll have to add that constraint into the MIB.
> The other solutions didn't require any modifications to the MIB.  Agent
> implementors could pick either 1 or 2.

I hope this is a moot point, but all three suggestions required
modifications to the MIB.