Subject: Notification doubling, part 2: wire traffic

From: "Ayers, Mike" <[email-masked]>
Date: Thu, 1 Mar 2001 15:16:34 -0600

Many recent posts have allude to the potential for the alarm model
to cause notification doubling, which would bog down wire traffic.

	Reality check.

	Even after new notifications have been defined to permit an alarm
which has been constructed partially from existing notifications, it should
be a minority case that both the original notifications and the constructed
alarms would be sent down the same wire.  After all, once higher level
information is available, who wants the raw data?

	However, many system administrators are understandably paranoid and
do want all the raw data (notifications) with the interpreted data (alarms).
In this case a simple principle applies:  More data needs more bandwidth.

	Has anyone heard of the NotifyFilterProfileTable?  Just wondering,
because there seems to be this idea that every notification that gets
generated will hit the wire.  This should not be true.  Managers are capable
of, and responsible for, controlling the notifications that they receive.
Likewise, notifications on/off switches, like the objects snmpAlarmGenNotify
and snmpItuAlarmGenNotify, are not necessary and should not be used.

/|/|ike /+yers
Test Engineer
BMC Software
                                             Beware of geeks bearing gifts.

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 4 Mar 2001 11:41:51 -0500

hi

Even if the duplicated notification does not get sent,
the device really still needs to support it.  This
is both for legacy systems and for customer bids
requiring compliance to RFC2233, RFCXXXX, etc.

The manager might end up having to support both for the
same reasons.

Sharon

-----Original Message-----
From: Ayers, Mike [mailto:[email-masked]]
Sent: Thursday, March 01, 2001 4:17 PM
To: [email-masked]'
Subject: Notification doubling, part 2: wire traffic

	Reality check.

/|/|ike /+yers
Test Engineer
BMC Software

---

From: "Ayers, Mike" <[email-masked]>
Date: Mon, 5 Mar 2001 19:03:11 -0600

> From: Sharon Chisholm [mailto:[email-masked]]
>

	There are two implications here with which I take issue:

	1.)  Managers which will handle alarms may only have extra
notifications to worry about - not true.  These managers will have to adopt
all the new logic of the alarm model; relative to that, the inclusion of
some new notifications is small change.

	2.)  There are existing standard MIBs with alarms in them.  There
aren't.

	Any (reasonable) management system which supports the alarm MIB will
also support notifications, regardless of the alarm model we agree upon.

/|/|ike

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 6 Mar 2001 07:36:36 -0500

hi

<sharonC-1>
> The manager might end up having to support both for the
<sharonC-1>

<mikeA>

</mikeA>

<sharonC-2>
No.  I'm actually saying something completely different here. I am talking
about the need for alarm-based managed systems to live in the same network
as traditional notification/event systems.

If I am working on device A and I add support of alarms, the need for
traditional notification/event based management does not go away. If
I think I have customers who are going to continue using traditional
management, them I'm going to want to support both method in my product.
This likely will mean supporting the notifications/events which currently
exist in the popular RFCs.

Likewise if I am a manager, I can expect to have devices in the network
that support alarms, but also those that don't.  I need to be able to
manage both.

All this can be done in such a way, as you mentioned in a previous email,
to prevent the actual bits on the wire, but it does not save the development
complexity.

Sharon
<sharonC-2>

---

From: "Ayers, Mike" <[email-masked]>
Date: Tue, 6 Mar 2001 12:04:01 -0600

Errr - what's your point?  From my reading, we're just agreeing that
the alarm MIB will be something new.

/|/|ike

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 6 Mar 2001 13:16:52 -0500

hi

I think this is a sign this thread has gotten too long.

This all started with discussions about whether or not
defining alarms in a separate naming space would
necessitate the support and use of both traditional
notifications/events and these "new" alarms.

You commented that the bits on the wire could be prevented.
I replied that even so, both devices and managers will
still most likely have to support both management methods.

My point is that since notifications/events and alarms
are sharing the same universe, I'd like to see a solution
which acknowledges this and reduces the complexity in this
situation.  I think this can be done in a way to make the
"no notifications" camp happy as well.

Sharon

-----Original Message-----
From: Ayers, Mike [mailto:[email-masked]]
Sent: Tuesday, March 06, 2001 1:04 PM
To: Chisholm, Sharon [CAR:5K32:EXCH]; Ayers, Mike;
[email-masked]'
Subject: RE: Notification doubling, part 2: wire traffic