Subject: RE: [Hubmib] FW: EPON MIB comments

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 11 Jan 2005 01:46:15 +0200

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-masked]]
> Sent: 11 January, 2005 1:31 AM
> To: 'Lior khermosh'; Romascanu, Dan (Dan); [email-masked]
> 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-masked]]
> > Sent: Wednesday, January 05, 2005 11:08 PM
> > To: [email-masked]; 'Romascanu, Dan (Dan)'; 
> [email-masked]
> > 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-masked] 
> [mailto:[email-masked]] On Behalf
> > Of Glen Kramer
> > Sent: Wednesday, January 05, 2005 3:25 AM
> > To: 'Lior khermosh'; 'Romascanu, Dan (Dan)'; [email-masked]
> > 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
> > 
> 
> 
> 
> 

_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "Glen Kramer" <[email-masked]>
Date: Mon, 10 Jan 2005 16:28:39 -0800

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

> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: Monday, January 10, 2005 3:46 PM
> To: [email-masked]; Lior khermosh; [email-masked]
> 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)
> 
> 
> 
>