RE: FW: EPON MIB comments

Lior, Matt, other, 

Please comment. 

Regards,

Dan



> -----Original Message-----
> From: Glen Kramer [mailto:[email protected]]
> Sent: 11 January, 2005 2:29 AM
> To: Romascanu, Dan (Dan); 'Lior khermosh'; [email protected]
> Subject: RE: [Hubmib] 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
> > > >
> > >
> > >
> > >
> > >
> 
> 
>