RE: FW: EPON MIB comments

My comments are in the text.


-----Original Message-----
From: Matt Squire [mailto:[email protected]] 
Sent: Tuesday, January 11, 2005 3:28 AM
To: Romascanu, Dan (Dan); [email protected]; Lior khermosh;
[email protected]
Subject: RE: [Hubmib] FW: EPON MIB comments



My comments are dispersed throughout.   

> 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. 

Counters in .1D are defined to reflect operation at the 802.1 level -
counters in the .3 MIBs should reflect behavior at the .3 level.
Although both may define "DropFrames", the dropping point and therefore
the actual semantics of the counter would be different.  I'm not arguing
that EPON needs or does not need a DropFrame counter, only that if it
does define one, it has nothing to do with the 802.1D DropFrame counter.


[Lior] Please see other mail.

> > Another example is alarm related attributes:
> > >    eponDeviceDyingGaspAlarmState
> > >    eponDeviceDyingGaspAlarmEnabled
> > >    eponDeviceCriticalEventState
> > >    eponDeviceCriticalEventEnabled
> > >    eponDeviceLocalLinkFaultAlarmState
> > >    eponDeviceLocalLinkFaultAlarmEnabled

In the first revision of the OAM MIB, these states were directly
reflected.  In the -02 revision, all event information was shoved into a
new "EventLog" table.  So transition in these are flags are reflected
there.  I can add them back as separate objects, I just don't want to go
back and forth.  In the transition to the -02 version, the
enable/disable of the events reflected in flags was <stupidly> removed.
Can add that back as removing it was unintentional.  

[Lior] Then I will remove from the EPON device MIB objects.

> > >    eponDeviceTemperatureEventIndicationState
> > >    eponDeviceTemperatureEventIndicationEnabled
> > >    eponDevicePowerVoltageEventIndicationState
> > >    eponDevicePowerVoltageEventIndicationEnabled

Where are these objects reflected in the management clause of 802.3ah?
I'm not a fan of adding new things at this stage of the game.  Temp and
voltage measurements and events aren't generally within the purview of
802.3.   

> > >    eponDeviceGlobalEventState
> > >    eponDeviceGlobalEventEnabled
> > >    eponDeviceErroredSymbolPeriodEventState
> > >    eponDeviceErroredSymbolPeriodEventEnabled
> > >    eponDeviceErroredFrameEventState
> > >    eponDeviceErroredFrameEventEnabled
> > >    eponDeviceErroredFramePeriodEventState
> > >    eponDeviceErroredFramePeriodEventEnabled
> > >    eponDeviceErroredFrameSecondsSummaryEventState
> > >    eponDeviceErroredFrameSecondsSummaryEventEnabled

The configuration (enable/disable/thresholds/etc.) are covered in the
dot3OamEventConfigTable, so I don't see any benefit/need for change from
these - we got 'em.  
[Lior] Then I will remove from the EPON device MIB objects.

> > >    eponDeviceOrganizationSpecificEventState
> > >    eponDeviceOrganizationSpecificEventEnabled

The thought was controls like these weren't useful.  There can be a
plethora of organization specific events from a group of different
organizations.  IMHO, each organization should define their controls as
one switch doesn't cover all, at least not well.  

[Lior] I tend to agree with this argument I will remove from the EPON
device MIB objects.

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