Subject: RE: Alarm Report Control (ARC)

From: Dan Romascanu <[email-masked]>
Date: Wed, 31 Jan 2001 09:16:05 +0200

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: "Mark Stewart" <[email-masked]>
Date: Wed, 31 Jan 2001 09:44:26 -0500

Dan,

We are not proposing to add any specific objects defined in the
optical MIB to the alarm MIB being worked on in DISMAN. We are
interested in contributing to the effort to get the ARC functionality
defined by ITU integrated into the alarm MIB effort of DISMAN.

We would like to see a generic alarm MIB that provides a flexible
mechanism to control alarms on objects using an ARC approach for
future OTN systems.

We can provide the requirements for ARC and work with the DISMAN
WG to enhance the alarm MIB.

- Mark