Subject: RE: Comments on the Analysis of Alarm MIBs

From: Dan Romascanu <[email-masked]>
Date: Thu, 1 Mar 2001 16:02:39 +0200

David,

I violently agree with everything that you wrote. However, you did not
answer my question. Why not use existing notifications wherever they fit? I
understand that linkDown may or may not mean an alarm condition, but
doubling the number of traps for each case when it does mean alarm condition
seems to me excessive.

The strategy that we propose is initiating a 'controlled poling' of the
alarm tables each time when a notification that may mean an alarm is being
sent. this seems preferable to sending two notifications for the same alarm
- the 'existing' and your new alarm notification.

Regards,

Dan

> -----Original Message-----
> From:	David T. Perkins [SMTP:[email-masked]]
> Sent:	Wed February 28 2001 21:04
> To:	[email-masked]
> Cc:	Dan Romascanu
> Subject:	RE: Comments on the Analysis of Alarm MIBs
>
> HI,
>
> on the below...
>
> At 02:58 PM 2/28/2001 +0200, Dan Romascanu wrote:
> <stuff cut>
> >        [Dan]  There are always notifications in place wherever the MIB
> >authors considered necessary that they are needed. Why not relate the
> alarms
> >to the existing notifications, as in our proposal? The general alarm
> >notification either risks to duplicate the number of traps, or requires a
> >parallel number of objects to turn the notifications off.
> >
> >        [Dan]  Regards,
>
> It would be great if this approach could be used, but it cannot. There are
> many counter examples to show that it WIL NOT WORK. One that we have
> discussed several times is the linkUp and linkDown notifications.
>
> These notifications may be sent (but of course, may be filtered and
> not sent by the notification filtering mechanism defined in RFC 2573).
>
> Sending a linkDown notification DOES NOT by itself indication
> that there is an alarm condition. A linkDown only means that ifOperStatus
> transitioned to 'down' or 'lowerLayerDown'. This may occur due to
> a fault (which is results in an alarm condition), or may occur
> because ifAdminStatus was set to down (which is not a fault and not
> an alarm condition).
>
> Regards,
> /david t. perkins
>