RE: 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
> > 
> 
> 
> 
>