Subject: RE: Alarm Report Control (ARC)

From: "Huynh, An-Ni (Anni)" <[email-masked]>
Date: Mon, 5 Feb 2001 11:14:19 -0500

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
> ----------
> From: 	Dan Romascanu[SMTP:[email-masked]]
> Sent: 	Sunday, February 04, 2001 7:05 AM
> To: 	Rutt, T E (Tom); Lam, Hing-Kam (Kam); 'Mark Stewart'; Thomas, Steven
> C (Steve); Huynh, An-Ni (Anni)
> Cc: 	[email-masked]'; [email-masked];
> [email-masked]
> Subject: 	RE: Alarm Report Control (ARC)
>
> 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
>
>
> > -----Original Message-----
> > 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];
> > [email-masked]
> > Subject:	RE: Alarm Report Control (ARC)
> >
> > 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 Lehtinen Ferris <[email-masked]>
Date: Mon, 05 Feb 2001 11:19:21 -0600

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