Subject: RE: more requirements statements

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Tue, 27 Mar 2001 13:19:11 -0500

Tammy:

I think our different views are caused by terminlogy. Can we stick we
the term defined in the dataflow diagram (condition vs active alarm)?
Somehow face-to-face discussions go much smoother than email.

I believe the capability you are addressing is how to map a device
information to whatever view a network admin wants to see and notified.
This falls into the active alarm module. (Sharon, I hope that I am not
too far from yours views).

I'd like you to share your expertise in the alarm management and explain
why a network admin wants to dynamically reassign the severity level
of a condition or an active alarm.  Maybe I am missing something here.

See comment inline too.

Regards,

Anni

> ----------
> From: 	Tammy Ferris[SMTP:[email-masked]]
> Sent: 	Tuesday, March 27, 2001 12:11 PM
> To: 	Huynh, An-Ni (Anni)
> Cc: 	Sharon Chisholm; disman; 'Dan Romascanu'
> Subject: 	Re: more requirements statements
> 
> An-Ni,
> As with Dan's comment, I haven't a clue what you mean either by the
> following:
> > You seem to be transferring some of the functions of alarms to
> conditions.
[Anni] I meant the functionality you talk about is more at the active mib
module.
Condition and active alarm are addressing different scopes.
As you have pointed out later that you want it be remoted from the resource
as far
as possible. 

I think we violently agree on this.

> Also, ..
> 
> > > > 3) Ability to reflect condition escalations and de-escalations
> accross
> > > > condition and alarm MIBs as a result of agent's decision to do so or
> > > > administrative decision to do so (i.e. change in severity or change
> > > > condition to be alarm condition or not)
> > > >
> > >       [Dan]  Again - I do not think that this mechanism should be
> > > replicated both at the levels of the alarms and of the conditions. I
> am
> > > not
> > > sure that the mechanism of dynamic escalation is needed at all - and
> if it
> > > is needed why apply it both for alarms and for conditions?
> > [Anni]  Again, I agree with Dan.
[Anni]   I am talking about the dynamic escalation is not applicable at the
condition level.

> > Tammy, the mechanism of dynamic escalation is not needed for condition
> at
> > all.
> > First of all, I think the dynamic escalation/descalation of a alarm (NOT
> > CONDITION)
> > is an overkill.  Why a network admin wants to DYNAMICALLY change the
> > severity level of an alarm?
> >
> > Secondly, even you have a good use case that it is an important feature,
> it
> > is really
> > part of the active alarm module.  There, an user can map the alarm
> > information to
> > something else.  I still think it is overkill.
> >
> 
> ****
> I am supprised that you have a problem with this.  I would encourage you
> to talk
> to other Lucent folks to understand this need.  In addition, I will try to
> explain further here.
[Anni]  It depends on who you are talking to. :-)    It also depends on
where they are
coming from.

> To be clear, dynamic allocation is not required.  Some agents do this and
> some
> do not.  Administrative escalations/de-escalations are a different story.
> 
> In either case, the model must support the ability to reflect what the
> current
> view of a problem is at any given time.  This is a must or severity
> becomes
> meaningless.
[Anni] That is what the condition mib is for.

> If it is determined that severity is not assigned to a condition, then I
> can
> agree that administrative severity changes do not apply to conditions.
[Anni] I suppose that the severity of an alarm type at a certain type of
interface or 
entity should be quite static within the same network operator (i.e. Service
Provider)
environment.  It may vary from SP to SP.  The condition profile offer an
mechanism 
to do so, which I think should be vendor specific, and should not be
standardized.

> We could not get a US consensus position in T1 that an 'alarm' in ARC did
> not
> have a severity associated with it.  Any 'alarm' in ARC must have the
> minimum
> information available (alarm type (e.g. LOS), time of occurance, and
> severity).
> Alarm is the term used in ARC, but per our slice and dice, should be
> translated
> to condition.  This is a US standards position, as such it cannot be
> argued
> against at the ITU.  I don't know if the same is true of the IETF.
> Tammy
> 
>

---

From: Tammy Ferris <[email-masked]>
Date: Tue, 27 Mar 2001 15:29:48 -0600

An-Ni,
Another face to face would really be great to clarify these things, I agree.

I am not sure that we are talking about terminology differences though.  Let us
test that theory some more. And I will try to provide further explaination. In
your diagram (this is a good diagram for discussion) you show audible/visuals
driven by the Condition MIB.  The last thing I want to see as an operator is a
device that has a crical alarm LED lit and having it report to the OSS that the
alarm is minor (via SNMP notification and/or active alarm MIB). (I appologize
for the technology specific terminology here and can translate if necessary)

We could decide for now that administrative configuration of condition
severities is out of the scope of the work.  I would be okay with that as the
model could easily be extended at a future date if needed.  My preference would
be to do it now with the same group who developed the rest to keep terminology,
style, etc. consistent.

Even if we decide not to do the above, I would be very uncomfortable not
defining behavior relating to escalation and de-escalation and how the
interaction would work between the condition MIB and the alarm MIB.

I think if we can't build a model that allows for that type of thing then it is
not adequate for generic alarm management.  This is so much in practice that it
cannot be ignored.  It is not the same as creating some fancy requirement that
no one will ever build to.  People are alreading building it.  Several products
exist with this functionality.  Many industry experts already understand this
functionality.

I will try another example:
Some systems assign severity based on the number of users that would be affected
by the failure.  Over time, the number of users can vary therefore the severity
of the failure will vary.  For systems and some resources doing this, the number
of users does not vary frequently, for others it does.

I really hope we can develop a model that accommodates both in addition to the
most simple case where severity never changes and only default values are used,
is simple, and is consistent with standards and common practice to the extent
possible.

It makes sense to me that changes in severity assignment should be reflected at
the point where severity is assigned.  In your diagram, I see this happening in
the Condition MIB.

You and Dan seem to think severity assignment is happening in the Alarm MIB.
Likewise, I would like to understanding why you think so.  Can you provide more
explaination please.

I am not precluding an override in the alarm MIB.  Maybe it needs to be in both
places for different reasons, or maybe it can be shared.  I have not made up my
mind. An override at the alarm MIB is above and beyond what is required in the
standard models I am familiar with, however distributed management and Sharon's
application of the mapper are not functionally a part of the those standards and
may require this.  It seems to me worth further study.

Tammy