Subject: Alarm #40 - Potential Solution

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 26 Apr 2002 08:00:29 -0400

hi

I know I have not sent out the updated issues list yet, but
the following is issue is being tracked as #40

Alarm #40 Identify where to find resource identifier (in notification)
          when defining alarm model

I had previously said that I did not think it would be practical to
completely solve this problem. Now I think a mechanism like the
following is simple, but goes a long way:

    alarmModelResourceIdentifiers OBJECT-TYPE 
        SYNTAX BITS                  
        ACCESS read-only 
        DESCRIPTION 
            "This object identifies which varbinds within 
             the notification identified by alarmModelNotificationId 
             are used to uniquely identify this resource.

           For SNMPv1 traps, a 1 indicates the first varbind. For
           NOTIFICATION-TYPE, a 1 indicates the first real varbind
           after the required varbinds of sysUptime and SNMPTrapOID." 
        ::= { alarmModelEntry X } 

I suspect, for completeness, it would also need some discussion about 
identifying the host portion of the resource.

Sharon Chisholm
Preside Management
Nortel Networks
Ottawa, Ontario

---

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

HI,

While I defer judgement on whether this approach works, I do believe
that the DESCRIPTION text needs an some updates.
1) It repeats a common terminology confusion....
   notifications, defined using the NOTIFICATION-TYPE construct, are
   sent using the TRAP PDU type in SNMPv1, or the v2TRAP and INFORM
   PDU types in SNMPv2c and SNMPv3. (That is, saying NOTIFICATION-TYPE
   in the text below is just incorrect terminology usage. And I believe
   that Sharon understands the technology, but I wish she would
   get her fingers trained to type out the appropriate terminology.)
2) The object uses the BITS pseudo type to select 0, 1, or more items
   in the varBind list. The bits in the BITS type are numbered
   starting at zero. Because of this, the DESCRIPTION text may
   confuse the reader, since it talks about numbering from one.
   Also, I'm pretty interested in the choice of BITS instead of
   using unsigned to choose a single item in the varBind list.
   The DESCRIPTION text didn't really address this.

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.

>identifying the host portion of the resource.
Regards,
/david t. perkins

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 26 Apr 2002 14:26:57 -0400

hi

<Dave Perkins>

</Dave Perkins>

Yes, I caught the second one after I sent the email. I thought I
cut and paste the text for the first point from the corrected text,
but apparently I did not - oops. I'd be sure to fix both if we 
decide to go this route. I'm just trying to see if people like
the general approach.

<Dave Perkins>

</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

Regards,
/david t. perkins

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 26 Apr 2002 15:28:21 -0400

hi

Arg. Well, I think you've just demonstrated how annoying
that SMI rule is. ;-)

Ok, well it could be done with two bitmaps
    1) Variable OIDs to match on  ifOperStatus.3 = Don't Care
    2) Values of variables to match on  ifIndex.3 = 3

But now the simple solution is a bit less simple.

Sharon

-----Original Message-----
From: David T. Perkins [mailto:[email-masked]]
Sent: Friday, April 26, 2002 3:06 PM
To: Chisholm, Sharon [CAR:NM50:EXCH]
Cc: [email-masked]
Subject: RE: Alarm #40 - Potential Solution

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.

>   ::= { mplsTeNotifyPrefix 1 }
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: Randy Presuhn <[email-masked]>
Date: Fri, 26 Apr 2002 16:50:34 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> From: "Sharon Chisholm" <[email-masked]>
> To: [email-masked]
> Date: Fri, 26 Apr 2002 15:28:21 -0400
...
> But now the simple solution is a bit less simple.
...

As a technical contributor...

I think the "positional" approach to identifying the
varbind for resource ID extraction is making things more
complicated than they need to be.

There are three broad cases:
   1) The varbinds don't reveal the resource ID; the
      identity of the resource is simply implied by the
      notification type.  Example: authenticationFailure.

   2) The name portion of one of the variable bindings
      identifies the resource, though perhaps not directly.
      Here, for a given notification type, one needs to:

      a) figure out which variable binding is the interesting one

      b) extract the portion of the name that has the index we want

      c) tack that onto an object identifier "base" to form an
         appropriate rowpointer

   3) The value portion of one of the varible bindings
      identifies the resource, though perhaps not directly.
      Do any such things exist?

In the interest of keeping things relatively simply, I'm
proposing two objects for the AlarmModelTable specifically
for resource identification.   These cover (1) and (2) in a
fully general way, without requiring any magic or specific
knowledge of different notification types in the alarm MIB
implementation.

Graphically:

   +--------------------------------+--------------+
   | name                                          |
   |                                               |
   | (Prefix)                       |  (Indexes)   |
   +--------------------------------+--------------+
   / use alarmModelVarbindSubtree1  /       
   \ to match, split prefix / index \      |
   / 0.0 matches any prefix, yields /      V
   \ empty indexes                  \
   +--------------------------------+--------------+
   | use alarmModelResourceSubtree  | Indexes      |
   | to supply new base.  (0.0 just |              |
   | passes through "prefix"        |              |
   +--------------------------------+--------------+

The operation of these two objects can be summarized in a
simple table:

...ResourceSubtree #    alarmModelVarbindSubtree
                   #        0.0        |   not 0.0
-------------------#-------------------+-----------------------
  not 0.0          # resulting name is | resulting name is the
                   # ResourceSubtree   | concatenation of the
                   #                   | ResourceSubtree and the
                   #                   | index from the varbind
                   #                   | name (the part following
                   #                   | the matching initial part)
-------------------#-------------------+-----------------------
   0.0             # pass name through | pass through matching
                   # untouched         | portion of name
-------------------#-------------------+-----------------------

   alarmModelVarbindSubtree  OBJECT-TYPE
      SYNTAX  OBJECT IDENTIFIER
      MAX-ACCESS   read-create
      STATUS       current
      DESCRIPTION
        "The name portion of each VarBind in the notification,
         in order, is compared to the value of this object.
         If the name is equal to or a subtree of the value
         of this object, for purposes of computing the value
         of AlarmActiveResourceID the 'prefix' will be the
         matching portion, and the 'indexes' will be any
         remainder.  The examination of varbinds ends with
         the first match.
        "
      DEFVAL { {0 0} }
      ::= { whatever }

   alarmModelResourceSubtree  OBJECT-TYPE
      SYNTAX  OBJECT IDENTIFIER
      MAX-ACCESS   read-create
      STATUS       current
      DESCRIPTION
        "The value of AlarmActiveResourceID is computed
         by appending any indexes extracted in accordance
         with the description of alarmModelVarbindSubtree
         onto the value of this object.  If this object's
         value is 0.0, then the 'prefix' extracted is used
         instead.
        "
      DEFVAL { {0 0} }
      ::= { whatever }

Three concrete examples:

1) if I receive an authenticationFailure, I'd like the
   resource to be 1.3.6.1.6.3.15.1.1, so I configure:
        alarmModelVarbindSubtree = 0.0
        alarmModelResourceSubtree = 1.3.6.1.6.3.15.1.1

2) if I receive a linkDown that contains SDLC physicalFailures
   statistics, I'd like to have my alarm refer to the right ifEntry:
        alarmModelVarbindSubtree = 1.3.6.1.2.1.41.1.1.3.1.1
        alarmModelResourceSubtree = 1.3.6.1.2.1.2.2.1.1

3) if the first varbind is always going to point to the
   right thing, then I just:
        alarmModelVarbindSubtree = 0.0
        alarmModelResourceSubtree = 0.0

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street Tel:
 +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------