Subject: Alarm Report Control (ARC)

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Mon, 29 Jan 2001 17:59:00 -0500

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: [email-masked]
Date: Tue, 30 Jan 2001 10:24:41 -0800

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.

Regards,

Anni Huynh
[email-masked]
+1 732 615-5402

*	Why ARC?

---

From: Dan Romascanu <[email-masked]>
Date: Tue, 30 Jan 2001 21:46:47 +0200

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

> 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)

---

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Tue, 30 Jan 2001 17:15:16 -0500

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]

---

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

> From:	Huynh, An-Ni (Anni) [SMTP:[email-masked]]
> Sent:	Wed January 31 2001 0:15
> To:	[email-masked]'; [email-masked]; 'Dan Romascanu'

---

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

Mark,

Let us try to get beyond the generalities level. Sharon and myself are the
editors of the DISMAN Alarms MIB. The drafts have just been published. They
are the result of a decent level of the discussions in the WG list in the
last two months. Your comments and contributions are very welcome. What are
your editorial proposals?

Regards,

Dan

> From:	Mark Stewart [SMTP:[email-masked]]
> Sent:	Wed January 31 2001 16:44
> To:	Dan Romascanu
> Cc:	'Huynh An-Ni (Anni)'; [email-masked]';
> [email-masked]; [email-masked]
> Subject:	Re: Alarm Report Control (ARC)
> 
> 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
> 
> Dan Romascanu wrote:
> > 
> > Anni,
> > 
> > > > If you are reading the two drafts in the proposal, you can see that
> we
> > > are
> > > > alarms that need to extend the generic mechanism. The ITU Alarm MIB
> is
> > > one
> > > > > I just saw the latest draft of Alarm MIB from Sharon.  I browse
> the
> > > > draft
> > > > > 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?
> > > > >
> > > > >
> > > > > is provided to manage ARC.  If not, we will continue to put the
> ARC
> > > > > feature
> > > > > in the Optical MIB.
> > > > >
> > > > > In the last IETF meeting, some members from the AToM MIB WG view
> that
> > > it
> > > > > Is the DISMAN WG interested in accepting ARC into the framework of
> the
> > > > WG?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Anni Huynh
> > > > > [email-masked]
> > > > > +1 732 615-5402
> > > > > ARC is an mandatory capability for new optical devices.  The
> ability
> > > to

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 31 Jan 2001 09:55:26 -0500

Dan,

In the opticalmib-00 version, the ARC setting is defined as an object of the
monitored entity (e.g., otnOTSnAlarmReportControl for the OTSn,
otnOMSnAlarmReportControl for the OMSn, etc.).

Now we think there may be a better way to model the ARC settings. That is
using a separate table. Each entry will including information such the
monitored entity (or entities), the alarm, and the corresponding ARC
setting. In this way, we don't modify the entity MIBs.

What do you think?

Regards,
Kam

-----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,

Regards,

Dan

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 31 Jan 2001 10:31:38 -0500

Dan,

I don't fully understand the alarm MIB and the itu alarm mib yet, in
particular the alarmDetailsTable. But do you think make sense to incorporate
a ARC table into the alarm mib or itu alarm mib to support the ARC
functionality? Entries of the ARC table will include information such the
monitored entity (or entities), the alarm, and the corresponding ARC
setting.

Regards,
Kam

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

Mark,

Regards,

Dan

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 31 Jan 2001 08:05:17 -0500

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,

Regards,

Dan

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 31 Jan 2001 11:07:13 -0500

Sharon,

This is for controlling alarmed-related notifications.

Kam

-----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]

hi

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,

Regards,

Dan

---

From: Dan Romascanu <[email-masked]>
Date: Wed, 31 Jan 2001 18:11:01 +0200

Hi Kam,

Yes. Adding the relevant objects in alarmDetailsTable to support the ARC
capability would be the way to go. However, I would first like to clarify if
ARC is really a function that belongs to the Alarm MIB or some other place -
see the question in the mail from Sharon.

Regards,

Dan

> From:	Lam, Hing-Kam (Kam) [SMTP:[email-masked]]
> Sent:	Wed January 31 2001 17:32
> To:	'Dan Romascanu'; 'Mark Stewart'
> Cc:	Huynh, An-Ni (Anni); [email-masked]';

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 31 Jan 2001 14:35:33 -0500

Dan,

One of the functional requirements of ARC is: allow suppression of reporting
(notification) of alarm on a per monitored instance base. Take SONET/SDH as
an example, one may want to suppress the reporting of AIS alarm on a
particular low order path (VT) instance for a certain time period (i.e., put
this VT instance in the NALM-TI state) for the purpose of path setup or
maintenance. Once the time period expired, it will automatically transition
into the ALM state (i.e., notification of alarm, if any, is now allowed).

To my understanding, the alarmDetailsTable and the ituAlarmTable) specify
the possible alarm types of a system irrespective to particular entity types
nor instances. Note that a alarm type may occur to different entity types
and instances. For example, in the 2558 SONET/SDH MIB, AIS can occur to a
Line, a high order path, or a low order path (VT). Given that, how do we
model the ARC setting into the alarmDetailsTable? Any ideas?

Regards,
Kam

-----Original Message-----
From: Dan Romascanu [mailto:[email-masked]]
Sent: Wednesday, January 31, 2001 11:11 AM
To: Lam, Hing-Kam (Kam); 'Dan Romascanu'; 'Mark Stewart'
Cc: Huynh, An-Ni (Anni); [email-masked]';

Hi Kam,

Regards,

Dan

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 31 Jan 2001 12:18:43 -0800 (PST)

Hi -

I'm forwarding a non-subscriber posting to the disman
mailing list.  Subscription instructions are at
http://www.ietf.org/html.charters/disman-charter.html

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------

> Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
> 	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA15936
> 	for <[email-masked]>; Wed, 31 Jan 2001 06:44:32 -0800 (PST)
> Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
> 	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f0VEh8j24863
> 	for <[email-masked]>; Wed, 31 Jan 2001 08:43:09 -0600 (CST)
> Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1])
> 	by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA27516
> 	for <[email-masked]>; Wed, 31 Jan 2001 09:45:29 -0500 (EST)
> Received: from metros1.ral.lucent.com (h135-92-100-10.lucent.com [135.92.100.10])
> 	by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA27504
> 	for <[email-masked]>; Wed, 31 Jan 2001 09:45:29 -0500 (EST)
> Received: from lucent.com ([135.92.107.57]) by
>           metros1.ral.lucent.com (Netscape Messaging Server 4.15) with
>           ESMTP id G817NK00.23N; Wed, 31 Jan 2001 09:45:20 -0500 
> Message-ID: <[email-masked]>
> Date: Wed, 31 Jan 2001 09:44:26 -0500
> From: "Mark Stewart" <[email-masked]>
> Organization: INS - Metro Optical Networking
> X-Mailer: Mozilla 4.75 [en] (Win98; U)
> X-Accept-Language: en,pdf
> MIME-Version: 1.0
> To: Dan Romascanu <[email-masked]>
> CC: "'Huynh An-Ni (Anni)'" <[email-masked]>,
>         "[email-masked]'" <[email-masked]>,
>         [email-masked], [email-masked]
> References: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> Dan,
>

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 31 Jan 2001 12:21:29 -0800 (PST)

Hi -

Yet another non-subscriber post to the disman WG list.
Subscription instructions are available at
http://www.ietf.org/html.charters/disman-charter.html

> 	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA16022
> 	for <[email-masked]>; Wed, 31 Jan 2001 07:12:32 -0800 (PST)
> 	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f0VFB8s05401
> 	for <[email-masked]>; Wed, 31 Jan 2001 09:11:08 -0600 (CST)
> Received: by MAIL with Internet Mail Service (5.5.2653.19)
> 	id <D6T0K7PF>; Wed, 31 Jan 2001 07:06:22 -0800
> Message-ID: <D698467B7BF5D411B53000D0B789103B0198C0@MAIL>
> From: Lakshmi Raman <[email-masked]>
> To: "'Dan Romascanu'" <[email-masked]>,
>         "'Huynh, An-Ni (Anni)'"
> 	 <[email-masked]>,
> Date: Wed, 31 Jan 2001 07:06:20 -0800
> MIME-Version: 1.0
> X-Mailer: Internet Mail Service (5.5.2653.19)
> Content-Type: text/plain;
> 	charset="iso-8859-1"
>
> Dan,
> Not completely. One needs to take that definition and make it
> a generic one. It is not a lot of change. It is more taking away for
> example in the name that it is OTN specific.
> In the ITU world, this is a feature added to any entity where
> the actual reporting is suspended for a time. Each entity in OTN MIB
> has this feature included. If there is a general definition then
> every one can use it was the idea from that meeting.
> Lakshmi
>
>

---

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]

hi

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,

Regards,

Dan

---

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

Hey,

If a new table was created in the alarm MIB, you propose it would include:
"monitored entity (or entities), the alarm, and the corresponding ARC
setting"

Would the monitored entity need to be a general OID, or is this specific to
interfaces (at least for now)?  Could this table be indexed by ifIndex and
cover all of the issues needed for the Optical Interface?

Does the table need to have the alarm in it as well? Is the intent of ARC to
suppress all alarms from that managed entity, or just specified ones?

Thanks,
Steve

-----Original Message-----
From: Lam, Hing-Kam (Kam) 
Sent: Wednesday, January 31, 2001 10:32 AM
To: 'Dan Romascanu'; 'Mark Stewart'
Cc: Huynh, An-Ni (Anni); [email-masked]';

Dan,

Regards,
Kam

-----Original Message-----
From: Dan Romascanu [mailto:[email-masked]]
Sent: Wednesday, January 31, 2001 9:54 AM
To: 'Mark Stewart'
Cc: 'Huynh An-Ni (Anni)'; [email-masked]'; [email-masked];

Mark,

Regards,

Dan

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 31 Jan 2001 17:24:33 -0800 (PST)

Hi -

And another.

|Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
|	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id RAA21866
|	for <[email-masked]>; Wed, 31 Jan 2001 17:07:31 -0800 (PST)
|Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
|	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f11167305573
|	for <[email-masked]>; Wed, 31 Jan 2001 19:06:07 -0600 (CST)
|Received: from merkita.com (ip120.minneapolis12.mn.pub-ip.psi.net [38.31.45.120])
|	by scaup.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id RAA20310;
|	Wed, 31 Jan 2001 17:08:06 -0800 (PST)
|Message-ID: <[email-masked]>
|Date: Wed, 31 Jan 2001 18:58:18 -0600
|From: Tammy Ferris <[email-masked]>
|X-Mailer: Mozilla 4.6 [en] (Win98; I)
|X-Accept-Language: en
|MIME-Version: 1.0
|To: "Thomas, Steven C (Steve)" <[email-masked]>
|CC: "Lam, Hing-Kam (Kam)" <[email-masked]>,
|        "'Dan Romascanu'" <[email-masked]>,
|        "'Mark Stewart'" <[email-masked]>,
|        "Huynh, An-Ni (Anni)" <[email-masked]>,
|        "[email-masked]'" <[email-masked]>,
|        [email-masked], [email-masked]
|Subject: Re: Alarm Report Control (ARC)
|References: <76B2C11F0337D3118A670008C7F9DBC703BB4E7D@OH0012EXCH002U>
|Content-Type: multipart/mixed;
| boundary="------------C3C049649AD08ADAE573ADF7"
|
|This is a multi-part message in MIME format.
|--------------C3C049649AD08ADAE573ADF7
|Content-Type: text/plain; charset=us-ascii
|Content-Transfer-Encoding: 7bit
|
|Steve,
|I am still trying to understand what is being proposed here for the IETF,
|certainly the three attributes you specify here (monitored entity, alarm, ARC
|setting) don't look to be enough to meet the requirements specified and agreed
|to by all of the network and service providers in the ITU and in T1.
|
|The intent for ARC was not to restrict it to interfaces alone at a generic
|level.  The T1/ITU version does not make that restriction.
|
|The T1/ITU version of ARC allows the manager to configure the list of
|problems/alarms that are to be controlled.
|Tammy
|
|"Thomas, Steven C (Steve)" wrote:
|
|> Hey,
|>
|> If a new table was created in the alarm MIB, you propose it would include:
|> "monitored entity (or entities), the alarm, and the corresponding ARC
|> setting"
|>
|> Would the monitored entity need to be a general OID, or is this specific to
|> interfaces (at least for now)?  Could this table be indexed by ifIndex and
|> cover all of the issues needed for the Optical Interface?
|>
|> Does the table need to have the alarm in it as well? Is the intent of ARC to
|> suppress all alarms from that managed entity, or just specified ones?
|>
|> Thanks,
|> Steve
|>
|> -----Original Message-----
|> From: Lam, Hing-Kam (Kam)
|> Sent: Wednesday, January 31, 2001 10:32 AM
|> To: 'Dan Romascanu'; 'Mark Stewart'
|> Cc: Huynh, An-Ni (Anni); [email-masked]';
|> [email-masked]; [email-masked]
|> Subject: RE: Alarm Report Control (ARC)
|>
|> Dan,
|>
|> I don't fully understand the alarm MIB and the itu alarm mib yet, in
|> particular the alarmDetailsTable. But do you think make sense to incorporate
|> a ARC table into the alarm mib or itu alarm mib to support the ARC
|> functionality? Entries of the ARC table will include information such the
|> monitored entity (or entities), the alarm, and the corresponding ARC
|> setting.
|>
|> Regards,
|> Kam
|>
|> -----Original Message-----
|> From: Dan Romascanu [mailto:[email-masked]]
|> Sent: Wednesday, January 31, 2001 9:54 AM
|> To: 'Mark Stewart'
|> Cc: 'Huynh An-Ni (Anni)'; [email-masked]'; [email-masked];
|> [email-masked]
|> Subject: RE: Alarm Report Control (ARC)
|>
|> Mark,
|>
|> Let us try to get beyond the generalities level. Sharon and myself are the
|> editors of the DISMAN Alarms MIB. The drafts have just been published. They
|> are the result of a decent level of the discussions in the WG list in the
|> last two months. Your comments and contributions are very welcome. What are
|> your editorial proposals?
|>
|> Regards,
|>
|> Dan
|>
|> > -----Original Message-----
|> > From: Mark Stewart [SMTP:[email-masked]]
|> > Sent: Wed January 31 2001 16:44
|> > To:   Dan Romascanu
|> > Cc:   'Huynh An-Ni (Anni)'; [email-masked]';
|> > [email-masked]; [email-masked]
|> > Subject:      Re: Alarm Report Control (ARC)
|> >
|> > 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
|> >
|> > Dan Romascanu wrote:
|> > >
|> > > 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.
|> > > > >
|
|--------------C3C049649AD08ADAE573ADF7
|Content-Type: text/x-vcard; charset=us-ascii;
| name="tferris.vcf"
|Content-Transfer-Encoding: 7bit
|Content-Description: Card for Tammy Ferris
|Content-Disposition: attachment;
| filename="tferris.vcf"
|
|begin:vcard 
|n:Ferris;Tammy
|tel;cell:612-327-7829
|tel;fax:763-550-9439
|tel;work:763-5775946
|x-mozilla-html:FALSE
|adr:;;;;;;
|version:2.1
|email;internet:[email-masked]
|fn:Tammy Ferris
|end:vcard
|
|--------------C3C049649AD08ADAE573ADF7--
|
|

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 31 Jan 2001 17:23:08 -0800 (PST)

Hi -

I'm forwarding still another non-subscriber post to the disman WG
mailing list.  Subscription instructions are available at
http://www.ietf.org/html.charters/disman-charter.html

|Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117])
|	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA21844
|	for <[email-masked]>; Wed, 31 Jan 2001 16:59:31 -0800 (PST)
|Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
|	by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f110w7Z03465
|	for <[email-masked]>; Wed, 31 Jan 2001 18:58:07 -0600 (CST)
|Received: from merkita.com (ip120.minneapolis12.mn.pub-ip.psi.net [38.31.45.120])
|	by scaup.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id QAA12141;
|	Wed, 31 Jan 2001 16:58:56 -0800 (PST)
|Message-ID: <[email-masked]>
|Date: Wed, 31 Jan 2001 18:49:10 -0600
|From: Tammy Ferris <[email-masked]>
|X-Mailer: Mozilla 4.6 [en] (Win98; I)
|X-Accept-Language: en
|MIME-Version: 1.0
|To: "Thomas, Steven C (Steve)" <[email-masked]>
|CC: "'Sharon Chisholm'" <[email-masked]>,
|        Dan Romascanu <[email-masked]>,
|        "Huynh, An-Ni (Anni)" <[email-masked]>,
|        "[email-masked]'" <[email-masked]>,
|        [email-masked], [email-masked]
|Subject: Re: Alarm Report Control (ARC)
|References: <76B2C11F0337D3118A670008C7F9DBC703BB4E7C@OH0012EXCH002U>
|Content-Type: multipart/mixed;
| boundary="------------03D19EFB6BF79C7E3C4C6A12"
|
|This is a multi-part message in MIME format.
|--------------03D19EFB6BF79C7E3C4C6A12
|Content-Type: text/plain; charset=us-ascii
|Content-Transfer-Encoding: 7bit
|
|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
|
|"Thomas, Steven C (Steve)" wrote:
|
|> 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.
|
|***Tammy
|Not only should the notification be sent in this scenario, but it is required to
|be sent in the ITU version.
|***Tammy
|
|> 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.
|> > >
|
|--------------03D19EFB6BF79C7E3C4C6A12
|Content-Type: text/x-vcard; charset=us-ascii;
| name="tferris.vcf"
|Content-Transfer-Encoding: 7bit
|Content-Description: Card for Tammy Ferris
|Content-Disposition: attachment;
| filename="tferris.vcf"
|
|begin:vcard 
|n:Ferris;Tammy
|tel;cell:612-327-7829
|tel;fax:763-550-9439
|tel;work:763-5775946
|x-mozilla-html:FALSE
|adr:;;;;;;
|version:2.1
|email;internet:[email-masked]
|fn:Tammy Ferris
|end:vcard
|
|--------------03D19EFB6BF79C7E3C4C6A12--
|
|