Subject: RE: Alarm #40 - Potential Solution

From: "David T. Perkins" <[email-masked]>
Date: Fri, 26 Apr 2002 12:06:10 -0700

HI,

Your examples "only work" because those notification types include
the "canonical" resource identifier. Consider a new notification
type, say, called linkStatusChange, that has only variables
ifAdminStatus and ifOperStatus. And lets assume that for interface
resources, the canonical resource identifier is an instance of
ifIndex. You would have to translate from instances of ifAdminStatus
(or ifOperStatus) to instances of ifIndex.

I don't know how you would use two variables to do the translation.

At 02:26 PM 4/26/2002 -0400, you wrote:

><Dave Perkins>
>In general, is the algorithm for determining resourceID something
>like the following:
>  Check to see if the variable is a column in one of the
>  tables that the implementation has support for, such as
>  a column in the ifTable. If so, then really don't need to
>  have any knowledge about the notification. All that is
>  needed is to transform the variable to a canonical variable
>  that would be used for the resourceID. For example,
>  variable ifAdminStatus.23 (in a notification), would be
>  converted to ifIndex.23 for the value of resourceID.
>
>Please let us know in detail how you envision the algorithm
>to function.
></Dave Perkins>
>
>Actually, I'm suggesting something quite different from
>what you are describing.
>
>What I'm suggesting is replacing the assumption that users
>know what varbinds in a notification identify the resource,
>with a bitmap that tells them.  Notifications without resource
>identifiers are today treated as alarms against the device,
>and under this scheme I would see this as having a value of
>0, or nothing set, for alarmModelResourceIdentifiers.
>
>The user knows which varbinds identify the resource under
>alarm and can then correlate between raise/clear instances
>without having to understand the content of the fields.
>
>Some examples:
>
>1.  linkDown would set bit 0, to point at ifIndex
>
>   Once you have matched against the correct alarm model,
>   you just check alarmActiveVariable*.1 to see if it
>   matches notification.varbind.1 
>
>   linkDown NOTIFICATION-TYPE
>           OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
>           STATUS  current
>           DESCRIPTION
>               "A linkDown trap signifies that the SNMPv2 entity,
>               acting in an agent role, has detected that the
>               ifOperStatus object for one of its communication links
>               is about to enter the down state from some other state
>               (but not from the notPresent state).  This other state
>               is indicated by the included value of ifOperStatus."
>       ::= { snmpTraps 3 }
>
>2. mplsTunnelUp would set bit 0 and 1 (and 2 and 3
>   if these next two parameters are part of identifying
>   the resource - I'd have to read the MIB)
>
>   Once you have matched against the correct alarm model,
>   you just check alarmActiveVariable*.1 to see if it
>   matches notification.varbind.1 and check alarmActiveVariable*.2 
>   to see if it matches notification.varbind.2
>
>  mplsTunnelUp NOTIFICATION-TYPE
>   OBJECTS     {
>      mplsTunnelIndex,
>      mplsTunnelInstance,
>      mplsTunnelIngressLSRId,
>      mplsTunnelEgressLSRId,
>      mplsTunnelAdminStatus,
>      mplsTunnelOperStatus
>   }
>   STATUS      current
>   DESCRIPTION
>        "This notification is generated when a
>          mplsTunnelOperStatus object for one of the
>          configured tunnels is about to leave the down state
>          and transition into some other state (but not into
>          the notPresent state).  This other state is
>          indicated by the included value of
>          mplsTunnelOperStatus."
>   ::= { mplsTeNotifyPrefix 1 }
>
>Sharon
What is the canonical resource identifier in the above example?
Also, the above looks like "bad" notification design because it
appears to include redundant index objects, which is bad. 

Regards,
/david t. perkins

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 27 Apr 2002 10:03:50 +0200

>>>>> David T Perkins writes:

David> Your examples "only work" because those notification types
David> include the "canonical" resource identifier. Consider a new
David> notification type, say, called linkStatusChange, that has only
David> variables ifAdminStatus and ifOperStatus. And lets assume that
David> for interface resources, the canonical resource identifier is
David> an instance of ifIndex. You would have to translate from
David> instances of ifAdminStatus (or ifOperStatus) to instances of
David> ifIndex.

David> I don't know how you would use two variables to do the
David> translation.

I agree with Dave's concerns in general. Notifications which would
work for automatic alarm identification need to be designed for this
purpose.  And this constitutes a major change in the way we were
defining notifications so far.

Without special purpose notifications (and hopefully some guiding
rules how to design them), there will always be magic involved and
thus the alarm MIB must be "notification aware" in order to produce
sensible alarms. Perhaps this is not even that bad as it might sound
at first glance.

I think we need to make a clear decision to either require that
notifications have a certain structure to make automatic alarm
determination feasible or to accept that sensible alarms can only
be determined by alarm MIBs that understand specific notification
formats.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>