Subject: Notes: Sept 10, 2001 Alarm Management Design Meeting

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 24 Sep 2001 09:45:49 -0400

Disman Alarm MIB Teleconference - September 10th

Attendees
---------
Sharon Chisholm, Anni huynh, Kam Lam, Dave Perkins 

Discussion on condition profiles
--------------------------------
Anni drafted up condition profiles and sent it out
just before the meeting. She included some concept 
of physical type, but is concerned that this will change 
too often.

M3100 is very flexible and she is not sure
how to generalize it.  She feels that if it
is too flexible, it won't be useful.
She would like to restrict the content.

Who defines the profiles? agent or manager.
Anni thinks agent.

There was discussion of making the profiles read-only.

Discussion on how smart the agent is
------------------------------------
The question was raised as to what expectations were 
being set for how smart the agent is? Severity of 
alarm depends on if it is service affecting, and 
therefore a more dynamic thing. There are rules, 
and it can get complicated.

Under certain circumstances, such as using bridging 
in a vlan, there is topology information, the device 
can't be aware of.

There was discussion on the concepts of alarm detection
points and perceived severity. There is not an expectation
that the device is aware of any of this extra information. 
That would be alarm correlation, which we have defined as 
out of scope.

Its important to make sure we manage people's
expectations by making sure the documents
are clear as to what is possible with these
MIBs and what can't be done.

More discussion on condition profiles
-------------------------------------
The question was raised as to what the intention of 
condition profiles is. It was indicated that the agent
needs to know the severity.

The scope of the condition profile is to the device, not
the network.

There was discussion of local correlation versus suppression.
Is Alarm suppression on resources within scope?
Either we solve it, or define it out of scope.

The IETF has not dealt with the concept of pre-provisioning.
Can condition profiles name things which don't exist?
Profiles should not be discussion specific instances, so
they should be able to.

A specific instance of this would be suppressing alarms 
for a card that is being hot swapped or inserted.

Slot versus card?  Can we suppress alarms on physical component at a
slightly
higher level?  If we can suppress on the slot, then when we should be able
to
suppress on a non-present card.

This can be done if the entity MIB is used as the physical model.

It was asked what level of resources are we currently defined
to suppress on then? The answer was not immediately clear.

Moving Forward
--------------
Action Everyone: Review the condition profiles Anni sent out.

Next Meeting, October 2nd at 11am eastern (North America).

Action Sharon: Set up bridge for meeting. 

Bridge for Next Meeting: 613-763-6338  Passcode  296119  

Sharon Chisholm
Preside Management
Nortel Networks
Ottawa, Ontario