Subject: RE: ARC MIB Improvement

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Mon, 26 Mar 2001 22:08:22 -0500

Tammy,

I couldn't see how the "subset" approach be an improvement of the MIB.
How does one know a particular subset consists of what alarm conditions?
Moreover, each resource (of resource type) will have its own set of subsets,
correct?

In the current approach, each alarm condition to be controlled correspondent
to a row in the ARC table. If a resource has n alarm conditions to be
controlled, then there will be n rows in the table. I think, in most
situations, there will be at most couple alarm conditions to be controlled
for a resource at a moment. So, I think the current approach is simplier
than the "subset' approach.

If you really need to indicate "all" alarm conditions for a given resource,
may be a specific value of "ConditionProbableCause" (which is the syntax of
arcAlarmType) be can defined (such as 99999) to represent all. Will this
meet the need?

Regards,
Kam

-----Original Message-----
From: Tammy Ferris [mailto:[email-masked]]
Sent: Monday, March 26, 2001 10:12 AM
To: Huynh, An-Ni (Anni)
Cc: [email-masked]'
Subject: Re: ARC MIB Improvement

An-Ni,
How about something like the following:
alarmSet OBJECT-TYPE  SYNTAX  INTEGER    {
              allAlarms (0),
              alarmSubset1 (1),
              alarmSubset2 (2),
              alarmSubset3 (3),
              alarmSubset4 (4),
              alarmSubset5 (5),
              alarmSubset6 (6),
              alarmSubset7 (7)
              }
      MAX-ACCESS read-write
      STATUS       current
      DESCRIPTION
               " Identifies the set of alarms to be controlled."
       ::= { TBD TBD }

With the above, there is still the flexibility to configure a subset.  How
this
configuration occurs could be left out of the standard or a generic way
specified.

What do you think?
Tammy

"Huynh, An-Ni (Anni)" wrote:

> Tammy:
>
>         This makes a big difference!!!
>         So, when ARC is activated to an managed entity (resource), all
> associated alarms are
>         suppressed/deferred.
>
>         Is there any need to have ARC per alarm types?  Can we eliminate
> this?
>
> Anni
> > ----------
> > From:         Tammy Ferris[SMTP:[email-masked]]
> > Sent:         Friday, March 23, 2001 10:09 PM
> > Cc:   [email-masked]'
> > Subject:      Re: ARC MIB Improvement
> >
> >
> > Kam,
> > I would like some way to specify "all" alarm types which is the default
> > and
> > expected to be the most typical setting for ARC  and also better matches
> > the ITU
> >
> > model.
> > Tammy
> >
> > "Lam, Hing-Kam (Kam)" wrote:
> >
> > > All,
> > >
> > > At the end of the ARC MIB presentation on Monday (3/19), I briefly
> > mentioned
> > > about the possible improvement of the MIB but didn't have time to go
> > into
> > > details. Here are the details of improving the 00 version (
> > > http://www.ietf.org/internet-drafts/draft-lam-disman-arcmib-00.txt ).
> > >
> > > (1) As Dave suggested before, the ARC table will only have rows with
ARC
> > > state values other than ALM. That is, once a resource transitions from
a
> > ARC
> > > mode state (i.e., NALM, NALM-QI[-CD], or NALM-TI) to the ALM state,
the
> > > entry will be deleted automatically from the ARC table.
> > >
> > > (2) Remove the arcNalmTITimeInterval and the arcNalmCDTimeInterval
> > objects
> > > to outside of the ARC table. Outside of the table allows these two
> > interval
> > > to be used as default values for all applicable resoruces. In this
way,
> > the
> > > ARC table will be reduced from 6 columns to 4 columns only. The 4
> > columns
> > > are arcIndex (identifying the resource), arcAlarmType (i.e., the
> > condition
> > > to be controlled, e.g., LOS), arcState (NALM, NALM-TI, or NALM-QI),
and
> > > arcNalmTimeRemainding.
> > > At the creation of an ARC entry for a resource, the initial value for
> > > arcNalmTimeRemainding will be the value of arcNalmTITimeInterval (if
the
> > ARC
> > > state is NALM-TI) or arcNalmCDTimeInterval (if the ARC state is
NALM-QI)
> > or
> > > zero (if the ARC state is NALM).
> > > On the other, at the creation of an ARC entry, the manager may specify
a
> > > value for arcNalmTimeRemainding to override the default value, if
> > needed.
> > > This change will make the table smaller and also avoid holes in the
> > table if
> > > TI and QI are not supported for a resource.
> > >
> > > (3) Change the arcNalmTimeRemainding object from read-only to
> > read-write.
> > > This will allow the manager to increase or decrease the value when the
> > > resource is in the NALM-TI or the NALM-QI-CD (if supported) state.
This
> > is
> > > particularly useful in the case of performing maintenance on the
> > resource
> > > when the technician needs to increase or decrease the allowed time.
> > >
> > > I believe that (1) will make the ARC MIB scale better. (2) will
simplify
> > the
> > > MIB. Both (2) and (3) meet the ARC requirements better.
> > > Any comments?
> > >
> > > Regards,
> > > Kam
> >

---

From: Tammy Ferris <[email-masked]>
Date: Tue, 27 Mar 2001 11:26:43 -0600

Kam,
See comments below.
Tammy

> I couldn't see how the "subset" approach be an improvement of the MIB.

***
See other e-mail, previous one I sent and one from An-Ni.
***

> How does one know a particular subset consists of what alarm conditions?

***
I left this outside of scope and implementation specific.
***

> Moreover, each resource (of resource type) will have its own set of subsets,

***
This may or may not be true depending on implementation.
***

> than the "subset' approach.

***
I agree that some implementations only have a few conditions that can be
reported for the resource.

I think both solutions have their own set of problems which make them less than
perfect.  Which one is simpler is not clear to me.

This solution, I think, makes timer management easier.

Your currently documented solution makes it more clear what conditions are being
suppressed.

I can support either solution, give that timer management issues are address.
***

> arcAlarmType) be can defined (such as 99999) to represent all. Will this

***
This solution would work for me.
***