Subject: RE: Alarm Report Control (ARC)

From: "Thomas, Steven C (Steve)" <[email-masked]>
Date: Wed, 31 Jan 2001 16:22:02 -0500

Hey all,

As I understand the ARC issue, it is more a notification issue than an alarm
issue.  BUT there is a problem in only viewing it as notification.
Specifically, if a fault condition is active for a managed object when its
ARC control is set from OFF(NALM) to ON(ALM), a notification SHOULD be sent.
As I understand Notification Filters, just viewing it as a notification
would not get it sent.

I believe that a manager COULD implement the equivalent functions as what is
desired by ARC by setting/changing entries in the
snmpNotifyFilterProfileTable, but it would be pretty ugly and indirect.
Also this approach would be controlled by the manager and I think the intent
of ARC control is to move that control down to the device.

Cheers,
Steve

-----Original Message-----
From: Sharon Chisholm [mailto:[email-masked]]
Sent: Wednesday, January 31, 2001 8:05 AM
To: Dan Romascanu; Huynh, An-Ni (Anni); [email-masked]';
[email-masked]
Cc: [email-masked]
Subject: RE: Alarm Report Control (ARC)

hi

Is this an alarm control or a notification control? If
it is more general to notifications, it might also work
somewhere like the SNMP-TARGET-MIB.

Sharon 

-----Original Message-----
From: Dan Romascanu [mailto:[email-masked]]
Sent: Wednesday, January 31, 2001 2:16 AM
To: 'Huynh, An-Ni (Anni)'; [email-masked]'; [email-masked]
Cc: [email-masked]
Subject: RE: Alarm Report Control (ARC)

Anni,

So, if I understand well your proposal is to add otnOTSnAlarmReportControl
object from draft-stewart-atommib-opticalmib-00.txt to the current Alarm
MIB. Is that true?

Regards,

Dan

> -----Original Message-----
> From:	Huynh, An-Ni (Anni) [SMTP:[email-masked]]
> Sent:	Wed January 31 2001 0:15
> To:	[email-masked]'; [email-masked]; 'Dan Romascanu'
> Cc:	[email-masked]
> Subject:	RE: Alarm Report Control (ARC)
> 
> Dan:
> 	ARC is a generic feature to control when a notification should be
> sent depending
> 	on the administrative condition, it is not intended for Optical
> device only,
> 	I don't think we need to have an specific optical alarm mib.
> 	That is why it was suggested that this topic be address in the
> DISMAN WG since
> 	the group is working on alarm mibs (generic or itu specific).
> 	
> Anni
> 
> 
> > ----------
> > From: 	Dan Romascanu[SMTP:[email-masked]]
> > Sent: 	Tuesday, January 30, 2001 2:46 PM
> > To: 	[email-masked]'; Huynh, An-Ni (Anni);
> > [email-masked]
> > Cc: 	[email-masked]
> > Subject: 	RE: Alarm Report Control (ARC)
> > Sensitivity: 	Confidential
> > 
> > Faye,
> > 
> > If you are reading the two drafts in the proposal, you can see that we
> are
> > proposing a modular architecture. The Alarm MIB defines generic alarm
> > management, while a relationship mechanism is defined for model specific
> > alarms that need to extend the generic mechanism. The ITU Alarm MIB is
> one
> > such example, an Optical Alarm MIB could be another one, and the ARC
> > feature
> > could be supported in this MIB.
> > 
> > Regards,
> > 
> > Dan
> > 
> > 
> > > -----Original Message-----
> > > From:	[email-masked] [SMTP:[email-masked]]
> > > Sent:	Tue January 30 2001 20:25
> > > To:	[email-masked]; [email-masked]
> > > Cc:	[email-masked]
> > > Subject:	RE: Alarm Report Control (ARC)
> > > Sensitivity:	Confidential
> > > 
> > > Dear disman WG,
> > > 
> > > I just saw the latest draft of Alarm MIB from Sharon.  I browse the
> > draft
> > > and I am not quite sure it covers the ARC feature which is required to
> > > manage an optical interface.  Can someone please let us (AToMMIB) know
> > if
> > > this can be achieved with the existing draft or there is additional
> > work?
> > > 
> > > 
> > > Our plan is to provide a pointer in our MIB to your Alarm MIB if a
> > > mechanism
> > > is provided to manage ARC.  If not, we will continue to put the ARC
> > > feature
> > > in the Optical MIB.  
> > > 
> > > Please see An-ni's email attached.  Thank you very much for your help.
> > > 
> > > -faye
> > > 
> > > -----Original Message-----
> > > From: Huynh, An-Ni (Anni) [mailto:[email-masked]]
> > > Sent: Monday, January 29, 2001 2:59 PM
> > > To: 'DISMAN WG'
> > > Cc: 'AToM MIB WG'
> > > Subject: Alarm Report Control (ARC)
> > > Sensitivity: Confidential
> > > 
> > > 
> > > 
> > > Hi.
> > > 
> > > I am the editor of the Optical Interface MIB for Optical Transport
> > Network
> > > device
> > > (a working document in  AToM MIB WG).  
> > > 
> > > In the original draft  "draft-stewart-atommib-opticalmib-00.txt"
> > > one of the MIB object is to configure the setting of  Alarm Report
> > Control
> > > (ARC).
> > > 
> > > In the last IETF meeting, some members from the AToM MIB WG view that
> it
> > > is a generic feature and suggested to address ARC in the DISMAN WG.  
> > > Is the DISMAN WG interested in accepting ARC into the framework of the
> > WG?
> > > 
> > > Regards,
> > > 
> > > Anni Huynh
> > > [email-masked]
> > > +1 732 615-5402
> > > -----------------------------------------
> > > Some background information on ARC:
> > > *	Reference:  ITU-T Recommendation M.3100 Amendement 3.
> > > *	What is ARC?
> > > ARC is an mandatory capability for new optical devices.  The ability
> to
> > > turn on/off  alarm reproting shall be supported over its management
> > > interfaces.
> > > There are 4 states: 
> > > 		ALM - alarm reporting is turned on, 
> > > 		NALM - alarm reporting is turned off
> > > 		NALM-TI - Inhibit alarm for a specified time interval
> > > 		NALM-QI - Inhibit alarm until the resource is qualified as
> > > problem free.
> > > 
> > > *	Why ARC?
> > > 1.	For network provisioning:  During the network setup/tear
> down, 
> > > alarm reporting needs to be turned off  for customer testing and other
> > > activities. 
> > > Once the managed entity is problem free, alarm reporting is
> > automatically
> > > turn on.
> > > 2.	For network maintenance: Maintenance technician can
> selectively turn
> > > on/off 
> > > alarm reporting per managed entity for troubleshooting.
> >

---

From: Tammy Ferris <[email-masked]>
Date: Wed, 31 Jan 2001 18:49:10 -0600

Steve,
I was the editor for the ARC work done in the ITU and T1.  I have a couple of
questions and comments to your e-mail and I also wanted to let everyone know
that I am working to get a "final" T1 version of ARC
requirements/analysis/design uploaded to the T1M1 site.  The version currently
loaded has everything but a minor bug fix to the state diagram.  If anyone needs
to know the contribution number, let me know.

You and others have discussed this being an alarm versus a notification
suppression feature.  Can you clarify for me exactly what you mean by an alarm
vs a notification?  What are the implications of the differences in the DISMAN
context?

In studying this problem in T1, we also considered the possibility of putting
some or all of the functionality in the management systems.  However it was
ruled out for various reasons.  I think it is important to keep the
functionality in the Agent at this time.

Also see additional comments below.
Tammy

> ARC control is set from OFF(NALM) to ON(ALM), a notification SHOULD be sent.

***Tammy
Not only should the notification be sent in this scenario, but it is required to
be sent in the ITU version.
***Tammy