Subject: RE: Alarm Report Control (ARC)

From: Dan Romascanu <[email-masked]>
Date: Thu, 1 Feb 2001 15:23:07 +0200

If the table that you are proposing does not include the alarms (type or
instance), I doubt that its place is in the Alarm MIB at all!

Regards,

Dan

> -----Original Message-----
> From:	Thomas, Steven C (Steve) [SMTP:[email-masked]]
> Sent:	Wed January 31 2001 23:30
> To:	Lam, Hing-Kam (Kam); 'Dan Romascanu'; 'Mark Stewart'
> Cc:	Huynh, An-Ni (Anni); [email-masked]';
> [email-masked]; [email-masked]
> Subject:	RE: Alarm Report Control (ARC)
> 
> 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.
> > > > >

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Thu, 1 Feb 2001 09:23:34 -0500

Let me try to give an example. 

In an optical NE, an OTS trail termination point (TTP) could have the
following possible fault conditions: SSF-P (Sever Signal Fail-Payload),
SSF-O (SSF-Overhead), BDI-P (Backward Defect Indicator-Payload), BDI-O,  TIM
(Trace Identifier Mismatch), LOS-P (Loss of Signal-payload), LOS-O, and LOS.

The manager could configure an entry in the ARC table for a particular OTS
TTP instance (#3 say) to no alarm notification (i.e., NALM) for a subset of
the possible fault conditions (LOS & TIM say). This entry of the ARC table
will have the following information:

Entity: OTS TTP #3
Fault conditions: LOS, TIM
ARC state: NALM

I hope this example will illustrate the ARC requirements and help design the
MIB.

Regards,
Kam

-----Original Message-----
From: Dan Romascanu [mailto:[email-masked]]
Sent: Thursday, February 01, 2001 8:23 AM
To: Thomas, Steven C (Steve); Lam, Hing-Kam (Kam); 'Dan Romascanu'; 'Mark
Stewart'
Cc: Huynh, An-Ni (Anni); [email-masked]'; [email-masked];
[email-masked]
Subject: RE: Alarm Report Control (ARC)

Regards,

Dan

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Thu, 1 Feb 2001 12:34:35 -0500

Mark,

For OTS TTP #3 under that ARC setting, 
if LOS occurs on OTS TTP #3, no notification;
if TIM occures on OTS TTP #3, no notification;
if other fault occurs (e.g., SSF-P, etc.), there will be notification.

In M.3100 Amendment 3, there are more detail requirements on the ARC
behaviour based on the order of occurring of a fault condition and its
corresponding ARC setting. Attached is a power pint figure showing the
possible cases. I hope it will help explaining the behavour.

Regards,
Kam

-----Original Message-----
From: Mark Stewart [mailto:[email-masked]]
Sent: Thursday, February 01, 2001 9:36 AM
To: Lam Hing-Kam (Kam)
Cc: 'Dan Romascanu'; Thomas Steven C (Steve); Huynh An-Ni (Anni);
[email-masked]'; [email-masked];
[email-masked]; 'Tammy Ferris'
Subject: Re: Alarm Report Control (ARC)

Lam,

Based on your example then can I assume that the Entity is in a fault
state but no alarm notification is sent.

- Mark

[email-masked];
> > > > > > > In the original draft
"draft-stewart-atommib-opticalmib-00.txt"

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 1 Feb 2001 11:32:53 -0800 (PST)

Hi -

Yet another non-subscriber post.  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 GAA23459
|	for <[email-masked]>; Thu, 1 Feb 2001 06:35:42 -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 f11EYHV12285
|	for <[email-masked]>; Thu, 1 Feb 2001 08:34:17 -0600 (CST)
|Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1])
|	by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA05310
|	for <[email-masked]>; Thu, 1 Feb 2001 09:36:38 -0500 (EST)
|Received: from metros1.ral.lucent.com (h135-92-100-10.lucent.com [135.92.100.10])
|	by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA05298
|	for <[email-masked]>; Thu, 1 Feb 2001 09:36:38 -0500 (EST)
|Received: from lucent.com ([135.92.107.57]) by
|          metros1.ral.lucent.com (Netscape Messaging Server 4.15) with
|          ESMTP id G831X100.F46; Thu, 1 Feb 2001 09:36:37 -0500 
|Message-ID: <[email-masked]>
|Date: Thu, 01 Feb 2001 09:35:42 -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: "Lam Hing-Kam (Kam)" <[email-masked]>
|CC: "'Dan Romascanu'" <[email-masked]>,
|        "Thomas Steven C (Steve)" <[email-masked]>,
|        "Huynh An-Ni (Anni)" <[email-masked]>,
|        "[email-masked]'" <[email-masked]>,
|        [email-masked], [email-masked],
|        "'Tammy Ferris'" <[email-masked]>
|Subject: Re: Alarm Report Control (ARC)
|References: <[email-masked]>
|Content-Type: text/plain; charset=us-ascii
|Content-Transfer-Encoding: 7bit
|
|Lam,
|
|Based on your example then can I assume that the Entity is in a fault
|state but no alarm notification is sent.
|
|- Mark
|
|"Lam, Hing-Kam (Kam)" wrote:
|> 
|> Let me try to give an example.
|> 
|> In an optical NE, an OTS trail termination point (TTP) could have the
|> following possible fault conditions: SSF-P (Sever Signal Fail-Payload),
|> SSF-O (SSF-Overhead), BDI-P (Backward Defect Indicator-Payload), BDI-O,  TIM
|> (Trace Identifier Mismatch), LOS-P (Loss of Signal-payload), LOS-O, and LOS.
|> 
|> The manager could configure an entry in the ARC table for a particular OTS
|> TTP instance (#3 say) to no alarm notification (i.e., NALM) for a subset of
|> the possible fault conditions (LOS & TIM say). This entry of the ARC table
|> will have the following information:
|> 
|> Entity: OTS TTP #3
|> Fault conditions: LOS, TIM
|> ARC state: NALM
|> 
|> I hope this example will illustrate the ARC requirements and help design the
|> MIB.
|> 
|> Regards,
|> Kam
|> 
|> -----Original Message-----
|> From: Dan Romascanu [mailto:[email-masked]]
|> Sent: Thursday, February 01, 2001 8:23 AM
|> To: Thomas, Steven C (Steve); Lam, Hing-Kam (Kam); 'Dan Romascanu'; 'Mark
|> Stewart'
|> Cc: Huynh, An-Ni (Anni); [email-masked]'; [email-masked];
|> [email-masked]
|> Subject: RE: Alarm Report Control (ARC)
|> 
|> If the table that you are proposing does not include the alarms (type or
|> instance), I doubt that its place is in the Alarm MIB at all!
|> 
|> Regards,
|> 
|> Dan
|> 
|> > -----Original Message-----
|> > From: Thomas, Steven C (Steve) [SMTP:[email-masked]]
|> > Sent: Wed January 31 2001 23:30
|> > To:   Lam, Hing-Kam (Kam); 'Dan Romascanu'; 'Mark Stewart'
|> > Cc:   Huynh, An-Ni (Anni); [email-masked]';
|> > [email-masked]; [email-masked]
|> > Subject:      RE: Alarm Report Control (ARC)
|> >
|> > 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.
|> > > > > >
|

---

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Thu, 1 Feb 2001 13:32:50 -0500

Steve:

The problem is well stated.
	"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."
> 
Anni

> ----------
> From: 	Thomas, Steven C (Steve)
> Sent: 	Wednesday, January 31, 2001 4:22 PM
> To: 	'Sharon Chisholm'; Dan Romascanu; Huynh, An-Ni (Anni);
> [email-masked]'; [email-masked]
> 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
> 
> 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
> 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 
> 
> Sent: Wednesday, January 31, 2001 2:16 AM
> To: 'Huynh, An-Ni (Anni)'; [email-masked]';
> [email-masked]
> 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
> 
> 
> 
> > To:	[email-masked]'; [email-masked]; 'Dan Romascanu'
> > 	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,
> > > 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
> > > 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
> > > > 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.  
> > > > 
> > > > I am the editor of the Optical Interface MIB for Optical Transport
> > > Network
> > > > device
> > > > one of the MIB object is to configure the setting of  Alarm Report
> > > Control
> > > > (ARC).
> > > > 
> > > > 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
> > > > 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: 
> qualified as
> > > > 1.	For network provisioning:  During the network setup/tear
> > down,

---

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Fri, 2 Feb 2001 12:52:24 -0500

Steve:

	See comment inline.

Anni

> Sent: 	Wednesday, January 31, 2001 4:29 PM
This table would be indexed by (ifIndex and faultConditionType), the object
arcState
will control the suppression of alarm reporting.

ifIndex should be sufficient to cover ATM, SONET/SDH, and OTN devices.
The faultConditionType (e.g. AIS, LOS, TIM, etc..) specify notifications of
which
fault condition will get suppressed or delayed.

> Does the table need to have the alarm in it as well?
No. arcTable is to control the alarm reporting.
The alarms should be in a separate alarm list.
> Is the intent of ARC to
Is it for specified one. See above.

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 3 Feb 2001 19:38:10 -0500

hi

I would think performance monitoring would be covered
by a performance threshold being surpassed being considered
a fault.  This would therefore result in an alarm.

Events such as initialization are not alarms by our current
definition.

An alarm indicates a fault, which should result in a notification.

Do you think it would help to cover these more specifically
in the document?

Sharon

-----Original Message-----
From: Tammy Ferris [mailto:[email-masked]]
Sent: Friday, February 02, 2001 5:49 PM
To: Thomas, Steven C (Steve)
Cc: Chisholm, Sharon [CAR:5K32:EXCH]; Dan Romascanu; Huynh, An-Ni
(Anni); [email-masked]'; [email-masked];
[email-masked]
Subject: Re: Alarm Report Control (ARC)

Steve,
Given the definitions you provided me, can you explain how performance
monitoring and threshold for performance are handled?

How are events such as initialization events that do not persist get
reported?

Can Faults and Alarms and Notifications be queried?

How is correlation of faults,  alarm, and notifications handled?
Tammy

Tammy Lehtinen Ferris
Merkita Incorporated
(763)577-5946

"Thomas, Steven C (Steve)" wrote:

> Tammy,
>
> I confess that I haven't seen the full ARC work for ITU.  I have only seen
> how it has been reflected in Mark Stewart's optical interface MIB.  Can
you
> point me to a complete copy of it?
>
> Regarding the differences between alarm and notification, the ALARM MIB
> defines the terms as follows:
>
>   Fault
>      Lasting error or warning condition.
>
>   Notification
>      Unsolicited transmissions of management information.
>
>   Alarm
>      Persistent indication of a fault.  A Notification should be sent
>      to indicate the setting of an alarm when the fault first
>      is detected.  A Notification should be sent to indicate the
>      clearing of an alarm when the fault ceases to exist.
>
> I trust that Sharon or Dan will correct me if I'm wrong, but I interpret
> that to mean that an alarm (once defined) is a condition that exists
whether
> any managers know about it or not (via notifications).  Notifications are
> the means of informing managers about the alarm condition being set or
> cleared.
>
> "Tammy Ferris" wrote:
>
> > 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,
> > >
> > ***Tammy
> > Not only should the notification be sent in this scenario, but it is
> required > to
> > be sent in the ITU version.
> > ***Tammy
> >
> > > I believe that a manager COULD implement the equivalent functions as
> what is
Alarm
Romascanu'
be
alarm
the
> > > > > and I am not quite sure it covers the ARC feature which is
required
additional
ARC
WG.
ability
management
> > > > >           NALM-QI - Inhibit alarm until the resource is qualified
as

---

From: Dan Romascanu <[email-masked]>
Date: Sun, 4 Feb 2001 13:56:05 +0200

Hi Kam,

It looks like the place for these fault conditions is in a model-specific
Optical Switches Alarm MIB, and not in the generic Alarm MIB.

Regards,

Dan

> From:	Lam, Hing-Kam (Kam) [SMTP:[email-masked]]
> Sent:	Thu February 01 2001 16:24
> To:	'Dan Romascanu'; Thomas, Steven C (Steve); 'Mark Stewart'
> [email-masked]; [email-masked]; 'Tammy Ferris'

---

From: Dan Romascanu <[email-masked]>
Date: Sun, 4 Feb 2001 14:05:24 +0200

What about using the Entity MIB? A similar method was used by the SMON MIB
(RFC 2613) which defined smonDataSource which extends the semantics of RMON
dataSource that originally mapped only to MIB-II interfaces.

Regards,

Dan

> From:	Rutt, T E (Tom) [SMTP:[email-masked]]
> Sent:	Fri February 02 2001 21:09
> To:	Lam, Hing-Kam (Kam); 'Dan Romascanu'; 'Mark Stewart'; Thomas, Steven
> C (Steve); Huynh, An-Ni (Anni)
> Cc:	[email-masked]'; [email-masked];
> I am concerned that IfIndex is not good enough for identity of resource.
> What about resources
> which do not map to interfaces (cross connects, ethernet bridges etc).
>
> Tom Rutt
> [email-masked]
> ter
>
> 	----------
> 	Sent:  Friday, February 02, 2001 12:52 PM
> 	To:  Lam, Hing-Kam (Kam); 'Dan Romascanu'; 'Mark Stewart'; Thomas,
> Steven C (Steve)
> 	Cc:  [email-masked]'; [email-masked];

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 4 Feb 2001 12:20:14 -0500

hi

I'm up to page 14 of the ARC document, and I would disagree
that this is optical specific, but it is certainly worthy
of its own MIB.  It could also be rolled into the ITU-model MIB,
depending on how big it gets.

Either way, the ARC module would need to interwork with the model-neutral
and ITU-model ones.

Would doing a MIB which extends the Entity MIB with objects like
	arcAlarmManagedEntityReportAdminStatus { on, off }
	arcAlarmManagedEntityReportOperStatus { on, off }
	arcAlarmManagedEntityControlType { externally, operationally, timer
}
make any sense?

Sharon

-----Original Message-----
From: Dan Romascanu [mailto:[email-masked]]
Sent: Sunday, February 04, 2001 6:56 AM
To: 'Lam, Hing-Kam (Kam)'; Thomas, Steven C (Steve); 'Mark Stewart'
Cc: Huynh, An-Ni (Anni); [email-masked]'; [email-masked];

Hi Kam,

Regards,

Dan

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 4 Feb 2001 13:16:50 -0500

hi

The problems with adding the ARC information into alarmDetailsTable
are

1) The Alarm MIB is meant to be model-neutral.  Because ARC is more
   complicated than just turning on and off alarm reporting, it really
   needs to be in a model-specific MIB.

2) The breakdown is a bit different.  The alarmDetailsTable is talking
   about alarms, where ARC is talking about Managed Entities.  Managed
   Entities being a managed system, managed application or managed resource.

But, as a said in a previous email, it might make sense in the ITU Alarm
MIB or in a separate MIB which plays nicely with the other two Alarm MIBs.

Sharon

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

Dan,

particular the alarmDetailsTable. But do you think make sense to incorporate

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,

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: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Mon, 5 Feb 2001 14:07:24 -0500

Hi, Tammy.

I try to be careful with the choice of words. :-)
M.3100 Amendment 3 is a GENERIC Requirement.
Yet, from a generic requirement, we pick and choose what is applicable
for our product applications.

Many of us see that for some of  the enterprise network equipment,
there are ways to suppress alarm notifications during maintenance
or provisioning cycle without having to deal with ARC per managed
entity.

However, Kam Lam did give a good example why ARC is necessary for larger,
transport network devices, where one wants to suppress higher layer's alarms
and
focus on a specific lower layer alarm for network fault isolation, etc...
And I do see the value of it.  That is the scope of the proposed arcTable.

I hope I clarify where I am coming from, and looking forward for a
more generic arcTable proposal from this WG.

Regards,

Anni

> ----------
> From: 	Tammy Lehtinen Ferris[SMTP:[email-masked]]
> Sent: 	Monday, February 05, 2001 12:19 PM
> To: 	Huynh, An-Ni (Anni)
> Cc: 	Rutt, T E (Tom); Lam, Hing-Kam (Kam); 'Mark Stewart'; Thomas, Steven
> C (Steve); 'Dan Romascanu'; [email-masked]';
> Can you please explain further your point about ARC being a special
> feature and
> not generic?  Why do you think it is not applicable to metropolitan or
> enterprise networks?
>
> As metropolitan and enterprise network providers were involved in defining
> this
> feature in T1, I would have to say that I currently don't agree that this
> feature is not applicable in such networks.
> Tammy
>
> Tammy Lehtinen Ferris
> Merkita Incorporated
> (763)577-5946
>
> "Huynh, An-Ni (Anni)" wrote:
>
> > Dan:
> >
> > I agree with you that the ARC does not belong to the generic ALarm MIB.
> >
> > ARC is a special feature that may or may not be implemented by all
> > network devices (especially those for metropolitan or enterprise
> networks).
> >
> > Therefore it is clearner not to put the ARC into entity MIB or SMON MIB.
> > It makes more sense that ARC be a separate table in the model specifc
> ALARM
> > MIB
> > e.g. ituAlarm MIB.
> >
> > Anni
> > > ----------
> > > Sent:         Sunday, February 04, 2001 7:05 AM
> > > To:   Rutt, T E (Tom); Lam, Hing-Kam (Kam); 'Mark Stewart'; Thomas,
> Steven
> Steven
> > > >     > 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
> > > >     This table would be indexed by (ifIndex and faultConditionType),
> the
> > > > object
> > > >     arcState

> > > >     > suppress all alarms from that managed entity, or just
> specified
> > > > ones?
> > > >     > I don't fully understand the alarm MIB and the itu alarm mib
> yet,
> > > > in
> > > >     > functionality? Entries of the ARC table will include
> information
> > > > such the
> > > >     > monitored entity (or entities), the alarm, and the
> corresponding
> > > > ARC
> > > >     > setting.
> > > >     >
> > > >     > Regards,
> > > >     > Kam
> > > >     >
> > > >     > Let us try to get beyond the generalities level. Sharon and
> myself
> > > > are the
> > > >     > 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
> > > >     > > > >       on the administrative condition, it is not
> intended
> > > > for
> > > >     > Optical
> > > >     > > > > device only,
> > > >     > > > > > 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
> > > >     > > > > > > 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
> > > >     > > > > > > 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
> > > >     > > > > > >
> > > >     > > > > > > 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
> > > >     > > > > > > ARC is an mandatory capability for new optical
> devices.
> > > > The
> > > >     > > ability
> > > >     > > > > to
> > > >     > > > > > >           NALM-TI - Inhibit alarm for a specified
> time
> > > > interval
> > > >     > > > > > > Once the managed entity is problem free, alarm
> reporting
> > > > is
> > > >     > > > > > automatically
> > > >     > > > > > > turn on.

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 5 Feb 2001 11:14:05 -0800 (PST)

Hi -

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

> Received: from babbler.bmc.com (babbler.bmc.com [172.17.0.116])
> 	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id UAA18560
> 	for <[email-masked]>; Sat, 3 Feb 2001 20:31:41 -0800 (PST)
> Received: from fw-us-hou-3.bmc.com (localhost [127.0.0.1])
> 	by babbler.bmc.com (8.10.2/8.10.2) with SMTP id f142D8F14870
> 	for <[email-masked]>; Sat, 3 Feb 2001 20:13:08 -0600 (CST)
> Received: from shell16.ba.best.com ([206.184.139.148]) by fw-us-hou-3.bmc.com; Sat, 03 Feb 2001 20:10:03 +0000 (CST)
> Received: from localhost (heard@localhost)
> 	by shell16.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id SAA17276;
> 	Sat, 3 Feb 2001 18:10:48 -0800 (PST)
> X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs
> Date: Sat, 3 Feb 2001 18:10:48 -0800 (PST)
> From: "C. M. Heard" <[email-masked]>
> X-Sender: [email-masked]
> To: Sharon Chisholm <[email-masked]>
> cc: Tammy Ferris <[email-masked]>,
>         "Thomas, Steven C (Steve)" <[email-masked]>,
>         Dan Romascanu <[email-masked]>,
>         "Huynh, An-Ni (Anni)" <[email-masked]>,
>         "[email-masked]'" <[email-masked]>,
>         [email-masked], [email-masked]
> In-Reply-To: <[email-masked]>
> Message-ID: <[email-masked]>
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> 
> On Sat, 3 Feb 2001, Sharon Chisholm wrote:
> No.  A PM threshold crossing is not a fault.  It is a transient
> condition that is reported once when it happens.  The resulting
> notification is an alert (aka event report), not an alarm.
> 
> Faults are standing conditions.  The entry into a fault condition
> causes an alarm report to be generated.  Exit from a fault condition
> causes an alarm clearing report to be generated.  These are not the
> same as alerts.
> 
> One more packet on the VLAN ...
> 
> Mike
> 
>

---

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Mon, 5 Feb 2001 15:38:20 -0500

Tammy:

Comment inline.

Regards,

Anni

> Sent: 	Monday, February 05, 2001 12:10 PM
> To: 	Huynh, An-Ni (Anni)
> Cc: 	Lam, Hing-Kam (Kam); 'Dan Romascanu'; 'Mark Stewart'; Thomas, Steven
> C (Steve); Rutt, T E (Tom); [email-masked]';
> It is my view that anything that emits alarms ought to have a way to
> throttle
> those alarms.  Even something as simple as a piece of equipment that emits
> open
> door alarms when its door is open.  During installation and maintenance
> activities it may be useful to suppress such notifications as no action is
> needed in such cases and therefor unsolicited alerts are not necessary and
> can
> be problematic.
>
During installation and maintenance activities, the alarm notification
suppression should probably
be at the device level (even CircuitPack, or port level) to reduce the alarm
storms.  In this
case, managed entity is more like NodeId/ShelfID/SlotID/PortID.  It looks
familiar (physical entity)!

One the other hand, there is a need ARC at the lower layer for network fault
isolation of an
network connection, In this case ifIndex is an appropriate index.
Note:  For SDH/SONET/OTN, I have checked that all sub-layer types have an
ifType assigned.
I did not look at Ethernet Bridge, so maybe someone can give me an example.

We either treat this two cases separately or we come up with an identifier
where we
can reference to any managed physical and/or logical  entity.

> I saw Tom's example not necessarily being specific to the OTN, but an
> example of
> something else that might emit an alarm that was not an interface.  The
> ODUk is
> not an ethernet bridge.
>
ODUkT is given as an example for OTN device.

> > Tom:
> > Please provide some example where you think the ifIndex is not enough
> for
> > identifying
> > the ethernet bridges.
> >
> > If you are referring to the ODUk (there is no ifIndex for this), I see
> that
> > the tandem connections
> > can be managed under the associated OCh.  It is a matter of how to
> design
> > the ODUkT table
> > in the optical MIB.
> >
> > Regards,
> >
> > Anni
> > > ----------
> > > From:         Rutt, T E (Tom)
> > > Sent:         Friday, February 02, 2001 2:08 PM

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 6 Feb 2001 01:10:44 +0100

I would prefer if we could continue this discussion on just ONE mailing
list.
I propose to use the DISMAN list, because it seems that the work will
be done there (as soon as Randy sends his new charter I can work on that
IESG approval process).

Another point is that maybe you do not need to keep all the old mail in
the posting either. Each of your postings has already accumulated to many
pages for each message.

Bert

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Mon, 12 Feb 2001 08:56:28 -0500

Dan,

The optical-specific fault conditions are just being used as an example for
showing how the "generic" alarm reporting control function works. Any other
fault conditions will be applied in the similar way.

Kam
P.S.
Sorry for replying so later. I was out of the office whole week for a
meeting.

-----Original Message-----
From: Dan Romascanu [mailto:[email-masked]]
Sent: Sunday, February 04, 2001 6:56 AM
To: Lam, Hing-Kam (Kam); Thomas, Steven C (Steve); 'Mark Stewart'
Cc: Huynh, An-Ni (Anni); [email-masked]'; [email-masked];

Hi Kam,

Regards,

Dan