RE: FW: EPON MIB comments

Dan,

Thanks for your response. I didn't try to enforce one-to-one correspondence
with IEEE spec. But there are attributes defined in EPON MIB now that are
applicable to non-EPON devices. For example, TxFrames, RxFrames, and
DropFrames counters (see end of this e-mail) are attributes of any 802.1D
port. 
Another example is alarm related attributes:
>    eponDeviceDyingGaspAlarmState
>    eponDeviceDyingGaspAlarmEnabled
>    eponDeviceCriticalEventState
>    eponDeviceCriticalEventEnabled
>    eponDeviceLocalLinkFaultAlarmState
>    eponDeviceLocalLinkFaultAlarmEnabled
>    eponDeviceTemperatureEventIndicationState
>    eponDeviceTemperatureEventIndicationEnabled
>    eponDevicePowerVoltageEventIndicationState
>    eponDevicePowerVoltageEventIndicationEnabled
>    eponDeviceGlobalEventState
>    eponDeviceGlobalEventEnabled
>    eponDeviceErroredSymbolPeriodEventState
>    eponDeviceErroredSymbolPeriodEventEnabled
>    eponDeviceErroredFrameEventState
>    eponDeviceErroredFrameEventEnabled
>    eponDeviceErroredFramePeriodEventState
>    eponDeviceErroredFramePeriodEventEnabled
>    eponDeviceErroredFrameSecondsSummaryEventState
>    eponDeviceErroredFrameSecondsSummaryEventEnabled
>    eponDeviceOrganizationSpecificEventState
>    eponDeviceOrganizationSpecificEventEnabled
>    eponDeviceEventControl

These objects are equally applicable to point-to-point fiber links or copper
links. I believe they should be moved to OAM MIB. 

Regards,
Glen

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email protected]]
> Sent: Monday, January 10, 2005 3:46 PM
> To: [email protected]; Lior khermosh; [email protected]
> Subject: RE: [Hubmib] FW: EPON MIB comments
> 
> Glen,
> 
> The focus of the EPON MIB  work is on defining management objects for EPON
> networks. This does not mean however providing a one-to-one mapping to the
> management attributes defined by the IEEE spec. According to the case we
> may define less, the same or more objects than the ones defined by the
> IEEE spec. We can even in some cases define objects that are not EPON
> specific, if they are helpful and the common management practice is to use
> them in the management of EPONs. This should however be rather the
> exception, and if the non-EPON objects become a consistent part of the
> overall work I would recommend defining a separate MIB module. Duplication
> is generally considered a bad practice but please be more specific about
> what objects you consider being already covered in other standard MIBs.
> 
> Regards,
> 
> Dan
> (Speaking as chair)
> 
> 
> 
> 
> > -----Original Message-----
> > From: Glen Kramer [mailto:[email protected]]
> > Sent: 11 January, 2005 1:31 AM
> > To: 'Lior khermosh'; Romascanu, Dan (Dan); [email protected]
> > Subject: RE: [Hubmib] FW: EPON MIB comments
> >
> >
> > Lior,
> >
> > I think we have a fundamental disagreement on the scope of
> > this document. I
> > argue that this MIB should only include EPON-specific
> > objects, i.e., objects
> > that you would not find in any other MIB. This would include
> > statistics for
> > MPCP messages, LLIDs, and so on. I believe that EPON devices should
> > implement multiple MIBs: OAM MIB, Bridging MIB, and EPON-specific MIB.
> > It seems to me that your approach is to define a single MIB that would
> > include (or duplicate) all objects that *MAY BE* used in
> > EPON, even though
> > these objects may already have been defined elsewhere.
> >
> > For example, counters of transmitted, received, and dropped
> > frames per queue
> > are not EPON-specific. Any port (according to 802.1D) may have up to 8
> > queues behind it and would count these statistics. I don't think these
> > objects belong to EPON-specific MIB.
> >
> > Before further discussing specific comments, I'd like to ask for a
> > clarification from the task force on the scope of this document.
> >
> > Regards,
> > Glen
> >
> > > -----Original Message-----
> > > From: Lior khermosh [mailto:[email protected]]
> > > Sent: Wednesday, January 05, 2005 11:08 PM
> > > To: [email protected]; 'Romascanu, Dan (Dan)';
> > [email protected]
> > > Subject: RE: [Hubmib] FW: EPON MIB comments
> > >
> > > [LK] of course it does not refer to the counters. It refers to the
> > > queues. The counters are an outcome of these entities.
> > > As indeed you say they are useful parameters. As it is not
> > defined in
> > > the EFM MIB objects I added them to the device MIB objects.
> > >
> > >
> > > -----Original Message-----
> > > From: [email protected]
> > [mailto:[email protected]] On Behalf
> > > Of Glen Kramer
> > > Sent: Wednesday, January 05, 2005 3:25 AM
> > > To: 'Lior khermosh'; 'Romascanu, Dan (Dan)'; [email protected]
> > > Subject: RE: [Hubmib] FW: EPON MIB comments
> > >
> > >
> > > [GK] Objects eponDeviceStatTxFramesQueue[0-7],
> > > eponDeviceStatRxFramesQueue[0-7], and
> > > eponDeviceStatDroppedFramesQueue[0-7]
> > > are not specific to EPON. These objects exist for other
> > devices, such as
> > > bridge ports. There is no need to duplicate these objects
> > here. Besides,
> > > neither 802.3ah nor 802.1D standards require exactly 8 queues to be
> > > implemented. I recommend removing these objects.
> > >
> > > [LK] The report message in the MPCP refers to such
> > entities. Please see
> > > section 64.3.6.2 for report message format. These counters refer to
> > > that.
> > >
> > > [GK] The REPORT message does not refer directly of indirectly to any
> > > such entities. I attached the clause 64.3.6.2. Would
> > appreciate if you
> > > could point where and how this clause refers to count of
> > transmitted,
> > > received, and dropped frames.
> > > I agree that these are useful parameters. But my point is
> > that they are
> > > already defined and are not EPON-specific. There is no need
> > to duplicate
> > > them in this MIB.
> > >
> > > Regards,
> > > Glen
> > >
> >
> >
> >
> >