Subject: RE: ARC MIB Improvement

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Mon, 26 Mar 2001 10:41:40 -0500

Tammy:

I would like to carefully evaluate the trade-off between flexibility vs
simplicity.
Before we go to much into the details, could you give me an example and
application
scenario why we need to suppress a subset of alarms but not all?

Anni

> ----------
> From: 	Tammy Ferris[SMTP:[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: Mon, 26 Mar 2001 15:41:13 -0600

An-Ni, Dan, and others,
Per comments about complexity, I agree that it should always
be a goal to keep
things simple.  I also believe that solutions must be able
to solve problems
(even if they are complex problems) that they are intended
to solve.  I think
this matches up with what Randy was saying and what others
have said.  It would
be helpful to identify ways to evaluate complexity so that
it is not completely
subjective, but in the absence of that, I am willing to
accept a guage from the
people most active in the work.  If active participants
cannot understand the
solution then there is definitely more work to be done. 
Going forward, it would
be helpful, if someone has a feeling the model is too
complex specifics on how
improvements can be made would be helpful (improvements not
being throwing baby
out with the bath water ;))

An-Ni - when I first read this e-mail (Friday night) my
initial reaction was to
say, lets do what you propose.  It is simple and will work
with many
implementations.  And, for the the life of me, I couldn't
remember why we made
the list configurable.... so I pulled out my old notes and
tried to be the devil
advocate against what you were proposing and what I was
feeling at the moment
comfortable agreeing to.  I knew that if we put it in, there
was some reason
behind it that could not be successfully argued against (and
being an engineer
it bothered me that I could not remember the reason off the
top of my head).

What we found, in doing the ARC work, is that many vendors
already implemented
ARC types of functionality.  What we also found is that what
vendors considered
alarmable conditions and what alarm conditions needed to be
suppressed during
network configuration and maintenance and when varied.  For
example, some
vendors allowed loopback activations to be declared alarm
conditions but did not
want them suppressed during ARC periods.  Other examples
were discussed in T1
but will not be repeated as they were quite complex and we
did not iron out all
of the details as a group but acknowledged that things are
not always so simple
as needing to suppress all alarm conditions.

I then challenged myself to think of any case where a single
alarm condition
would need to be throttled.  Valid or not, I came up with
the following:
sometimes a problem can manifest itself as an alarm
condition that keeps raising
and clearing.  In such cases, after a work order is
generated, it seems useful
to me to control the alarm reporting of this condition until
the problem is
repaired.

Getting back to simplicity.. I think that besides worrying
about making things
too complex, we should also worry about not over-simplifying
things such that we
lose ability to do useful things and just end-up
readdressing them later.  I
think that subsets should meet all expressed needs that I
have heard or could
think of yet simplifies the interface such that
configuration is not required
for all applications.  For example, the subsets could be
well-known subsets for
a given implementation.  For another example, a specific
implementation may only
support suppression of all alarms.  Yet, the door is open
for implementations
that require it, to configure the subsets.

Dan - A subset mean a subset (mathimatical definition of
subset) of all alarms.
Or, in other words, a list of alarms to be supressed.  The
subset could be a
single alarm.

Per Dan's comment, the 7 configurable subsets was a
completely arbitrary
number.  I like the numbers 3 and 7 and I thought then
number 3 might be too
restrictive.  Any other opinions about how many would keep
things simple yet
useful are welcome.

I further like this solution in that no functionality from
the ITU model is lost
in going to the SNMP model so can design functional models
independent of
whether devices are using SNMP, CMIP, or CORBA.  This makes
the management model
simpler.  And in the spirit of keeping things simple.... ;)
Tammy