Subject: RE: Pairing instances in RMON example

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 24 Apr 2002 14:29:31 +0300

> -----Original Message-----
> From: Randy Presuhn [mailto:[email-masked]]
> Sent: Tuesday, April 23, 2002 6:53 PM
> To: [email-masked]
> Subject: Re: Pairing instances in RMON example
> 
> 
> Hi -
> 
> > From: "Stefan Wallin" <[email-masked]>
> > To: <[email-masked]>
> > Subject: Pairing instances in RMON example
> > Date: Tue, 23 Apr 2002 16:43:29 +0200
> > Message-ID: 
> <[email-masked]>
> > In-Reply-To: <[email-masked]>
> ...
> > 2) However the more general question is:
> > Lets say I define two alarms in the RMON alarmTable:
> > alarmVariable X, risingThreshold 10, fallingthreshold 8
> > alarmVariable Y, risingThreshold 20, fallingthreshold 16
> > 
> > In this case it is extremely important that fallingAlarm 
> Threshold on Y
> > does not clear any active alarm on X.
> > How do we describe that? Miss something in the 
> alarmModelTable to point to
> > resource var-bind in case the generic notifications are not used.
> > (Resembles Perkins ifIndex example). What is the conclusion on the
> > previous issue here?
> ...
> 
> I agree that there's a problem.  For this to work as intended,
> the resource needs to be identified.  At the moment, this looks
> like magic.  Perhaps some of the tricks from the expression
> MIB or the snmpconf work might be appropriate.
> 
>  ------------------------------------------------------

This is a good one. The way it can be solved without too much magic being involved is to add an object to the alarmModelTable that would help distinguish between the two different alarms in the RMON alarmTable, for example by pointing to the specific index. The question is whether we cam make it generic enough, but not too complex to look like magic, or maybe the RMON case is important enough to have something specifically targeting RMON.

Regards,

Dan

---

From: [email-masked]
Date: Wed, 24 Apr 2002 13:50:47 +0200

Hi,
maybe I'm simplifying things but the addition of a row to alarmModelTable 
specifying which var-bind of the alarmModelNotificationId carries the 
resourceid.

The general rule in the mgmt app:
same alarm id AND same resource id -> correlate alarm and alarm clear.

Assumption: alarm id is modelled/used fine-grained so that different event 
types and probable cause have different alarm id's.
In X733 alarm conceptual model an alarm raise and alarm clear is correlated if 
they have same:
-eventtype
-probablecause
-object

The resource identifier to use in this case would be a reference to the 
alarmTable row, (note, not the value of the alarmVariable since we can have 
several measurements on the same alarmVariable).
This is carried by var-bind 1 in risingAlarm, oops, an index variable. Does not 
matter could as well use var-bind 2 since it would embed the index.

regards Stefan

Citerar "Romascanu, Dan (Dan)" <[email-masked]>:

> This is a good one. The way it can be solved without too much magic being
> involved is to add an object to the alarmModelTable that would help
> distinguish between the two different alarms in the RMON alarmTable, for
> example by pointing to the specific index. The question is whether we cam
> make it generic enough, but not too complex to look like magic, or maybe the
> RMON case is important enough to have something specifically targeting
> RMON.
> 
> Regards,
> 
> Dan
>