Subject: RE: JointNM

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 10 Aug 2000 07:20:59 -0500

hi

I intentionally decoupled the active alarm list from the mapping
into alarm records since I felt coupling them would hinder the
adoption of the MIB.  I wanted a MIB which could both be supported
on the devices and on the distributed manager.  With the format I
have used, the device can chose not to take on the issues of
mapping notifications into alarm records and properly defining
the raise/clear relationship, but I still end up with an active
alarm list which I can use to manage my network.

The other problems are important and I have no problem with them
being addressed, either by me or someone else, but I don't want to
see it become an all or nothing solution.  

I'd be interested in people's feedback on how often this mapping 
from notifications into alarm records actually gets done.  Aside from
the instance information, I've never seen it as a very dynamic thing
in practise.  I'd also be interested in where people think this translation
should take place: the device, the distributed manager or the end
application.

Sharon

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Thursday, August 10, 2000 7:01 AM
To: [email-masked]
Cc: Klerer, Mark [MTNJ:2217-M:EXCH]; [email-masked];
[email-masked]
Subject: Re: JointNM

>>>>> Wijnen, Bert (Bert) writes:

Bert> There are concerns For example there is an ITU doc Q.821 which
Bert> is very relevant in this area of active alarms, and it seems we
Bert> should not re-invent the weel in IETF. I believe that the Q.821
Bert> also points to some X.7nn documents for mapping of events into
Bert> alarms. Again, that may be relevant work.

I think it is X.733 (which is identical to ISO 10164-4). X.733 is
definately relevant. Some management systems are actually based on the
X.733 model and they usually interface with SNMP agents by mapping
SNMP notifications into X.733 alarm records. This mapping is not
always trivial since there is a big conceptual difference between a
notification (which just describes an event) and an alarm record.

Bert> Now... the only reason why this would be DISMAN work seems to be
Bert> that maybe it has some relation to notificationLog MIB and/or
Bert> event mib?  Anyway.. the WG needs to decide if they want to pick
Bert> up this type of work items.

I believe the X.733 alarm model (though not perfect) is not too bad
and going from there rather than reinventing a different wheel will
make convergence of telco management systems and isp management
systems much easier. In fact, the real technical issue is how you map
notifications into alarm records.

In other words: The biggest problem I have with the proposed document
(despite several more MIB technical issues) is that it is too close to
the SNMP notification logging MIB and ignores to define what the
concept of an alarm really is and how they related to existing
notifications.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Aug 2000 12:57:13 +0200

>>>>> Sharon Chisholm writes:

Sharon> I intentionally decoupled the active alarm list from the
Sharon> mapping into alarm records since I felt coupling them would
Sharon> hinder the adoption of the MIB.  I wanted a MIB which could
Sharon> both be supported on the devices and on the distributed
Sharon> manager.  With the format I have used, the device can chose
Sharon> not to take on the issues of mapping notifications into alarm
Sharon> records and properly defining the raise/clear relationship,
Sharon> but I still end up with an active alarm list which I can use
Sharon> to manage my network.

Sharon> The other problems are important and I have no problem with
Sharon> them being addressed, either by me or someone else, but I
Sharon> don't want to see it become an all or nothing solution.

I think it is necessary to first have agreement what the concept of
an alarm is and how it relates to notifications before you can define
a MIB which holds lists of alarms.

Sharon> I'd be interested in people's feedback on how often this
Sharon> mapping from notifications into alarm records actually gets
Sharon> done.  Aside from the instance information, I've never seen it
Sharon> as a very dynamic thing in practise.  I'd also be interested
Sharon> in where people think this translation should take place: the
Sharon> device, the distributed manager or the end application.

I am familiar with one commercial management system which is used by
several mobile phone operators in Germany (and most likely in other
countries as well). (So I am not talking about a toy here.) It is
based on X.733 alarm concepts and it maps SNMP notifications into
X.733 alarms in two slightly different ways:

(a) You add magic keywords into the MIB module which defines
    notifications. These magic keywords are used by the manager to
    derive statically all the X.733 alarm records information needed
    but not present in a notification definition (e.g. the severity).

(b) You add magic keywords into the MIB module which defines
    notifications. However, this time the magic keywords are used by
    the manager to dynamically retrieve some of the X.733 alarm record
    information from the actual notification which creates or deletes
    an alarm record.

Both approaches are more or less kludges for several reasons - but
they seem to work well enough in practice if the notifications are
defined in suitable way. (I have seen people who were aware of this
mapping strategy and who were defining SMIv2 notifications so that
these mappings become easier...)

/js