RE: FW: EPON MIB comments

Glen,
We do not have any fundamental agreement. The EPON MIB objects document
is not trying to duplicate all objects from other MIBs and it tries to
fill what the author considered as missing from that for an EPON device.
Such an equipment usually uses many many protocols and higher layer
applications and I believe each one is needed to be covered by its own
MIB objects. So that if it is needed for a device to be a bridge then it
should rely on using the bridge MIB objects.
I think that this state of mind is clearly presented at the beginning of
the document. 
Please note however that the EPON has its special properties so if there
is needed a special consideration due to that, then I think it should be
in this MIB document. Obviously we will find it in objects which are on
the boundary of the L2 EPON. That is why considerations and issues so
often come regarding bridge MIB objects.

Please note that some device MIB objects documents of other standards
(not IEEE) used different approach and did try to define much more - for
instance DOCSIS (RFC2669). In such a document you can find for instance
IP addresses for the devices and reference to services. I think I
clearly do not take this approach in this document.

As for your specific point. You are assuming here that the ONU is a
bridge and therefore holding the 802.1D bridge MIB objects. I tried to
avoid the assumption of this specific implementation in the ONU. 
I think that in order to cover the items described in the MPCP spec
which include description of queues for transmission and reporting we
need these counters and can not assume that they are covered by other
MIB objects.

Lior
  
 


-----Original Message-----
From: Glen Kramer [mailto:[email protected]] 
Sent: Tuesday, January 11, 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
>