Subject: Fwd: RE: Alarm Report Control (ARC)

From: Randy Presuhn <[email-masked]>
Date: Fri, 2 Feb 2001 11:46:52 -0800 (PST)

Hi -

I'm forwarding a non-subscriber post to the disman WG list.
Subscription instructions are available 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 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 LAA29635
> 	for <[email-masked]>; Fri, 2 Feb 2001 11:25:49 -0800 (PST)
> Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1])
> 	by babbler.bmc.com (8.10.2/8.10.2) with SMTP id f12JStZ17873
> 	for <[email-masked]>; Fri, 2 Feb 2001 13:28:55 -0600 (CST)
> Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1])
> 	by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA07965
> 	for <[email-masked]>; Fri, 2 Feb 2001 14:26:39 -0500 (EST)
> Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36])
> 	by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA07944
> 	for <[email-masked]>; Fri, 2 Feb 2001 14:26:38 -0500 (EST)
> Received: by NJ7460EXCH001H with Internet Mail Service (5.5.2650.21)
> 	id <1D8BWPLJ>; Fri, 2 Feb 2001 14:26:38 -0500
> Message-ID: <[email-masked]>
> From: "Rutt, T E (Tom)" <[email-masked]>
> To: "Lam, Hing-Kam (Kam)" <[email-masked]>,
>         "'Dan Romascanu'"
> 	 <[email-masked]>,
>         "'Mark Stewart'" <[email-masked]>,
>         "Thomas, Steven C (Steve)" <[email-masked]>,
>         "Huynh, An-Ni (Anni)" <[email-masked]>
> Cc: "[email-masked]'" <[email-masked]>,
>         [email-masked], [email-masked]
> Subject: RE: Alarm Report Control (ARC)
> Date: Fri, 2 Feb 2001 14:08:48 -0500
> MIME-Version: 1.0
> X-Mailer: Internet Mail Service (5.5.2650.21)
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> 
> 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
> 
> 	----------
> 	From:  Huynh, An-Ni (Anni) [SMTP:[email-masked]]
> 	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];
> [email-masked]
> 	Subject:  RE: Alarm Report Control (ARC)
> 
> 	Steve:
> 
> 		See comment inline.
> 
> 	Anni
> 
> 	> ----------
> 	> From: 	Thomas, Steven C (Steve)
> 	> Sent: 	Wednesday, January 31, 2001 4:29 PM
> 	> 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?
> 	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
> 	> suppress all alarms from that managed entity, or just specified
> ones?
> 	Is it for specified one. See above.
> 
> 	> 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: Tammy Ferris <[email-masked]>
Date: Fri, 02 Feb 2001 14:45:58 -0600

All,
I agree with Tom.  using IfIndex would not be sufficient for all cases but only for
interfaces.
Tammy

Tammy Lehtinen Ferris
Merkita Incorporated
(763)577-5946