RE: FW: EPON MIB comments
"Lior khermosh" <[email protected]>
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <[email protected]> |
Glen,
Thank you very much for the comments and for the time you invested in
reviewing the document. I appreciate it very much.
1. Thanks
2. I believe it is useful to have also a configuration possibility for
this parameter. As a guideline I believe management should have access
to define main modes of the system. Can you please specify why do you
think writing such a parameter is not useful? If we want to be strictly
following clause 30 I can add change the attribute in the device MIBs
objects to read-write but I would rather have it following the
configuration from the EFM MIB objects.
3. Agreed
4. My believe is that the management entity as a general requires the
knowledge of the PON switching time and does not need to find parameters
in the spec to complete the picture as it is may be probably part of a
more general access system. I think the MIB objects should supply a
visibility of the system major parameters although some are fixed. I can
add the description of 32TQs value to align with the MPCP.
5. dot3MpcpRxNotSupportedMpcp. The meaning here is to 8808 opcode frames
which are not of PAUSE or used by the MPCP protocol. I will clear the
description.
6. Agreed
7+8. If we can see the forwarding rules of the ONU in clause 65 then
7+there is a behavior for frames with bit broadcast in the LLID where
7+the LLID is the OLU's LLID (frames is rejected) and when the LLID is
7+not the ONU's LLID (frame is accepted) as part of the point to point
7+emulation peer to peer capabilities. This counter counts the first
7+frame. I have sent in the past comments regarding that to clause 30.
7+The result was OnuPonCastLLID and OltPonCastLLID which I think their
7+definition is too vague and refers to a long list of forwarding rules.
7+A solution for alignment is to make a request to change in the
7+definition of these attributes in the spec and then unify these
7+counters in them.
9. As a general logical deductive comment you have here a very good
comment. The problem comes when in devices a reset process can be a very
long process where many different sub-systems are reset. In such a
scenario there is a meaning for being in a reset process. Therefore I
believe that this is an attribute which is needed for a device. I am
open here for suggestions.
10. Thanks.
11. Changing this variable might indeed cause very major changes in the
system. Yet in my opinion it is needed for management. Unfortunately in
true life engineered systems there is a possibility that a system is not
operating well and it is needed to make it inactive immediately. The
purpose of such an attribute is like this.
12. I guess the question is what is the meaning of power down. I thought
of a condition where the device is in minimal power mode where it is not
transmitting and it is in listening mode so it can be enabled by
activation according to MAC address. Keeping it registered can be done
easily by reducing its SLA to minimal BW but I don't think it is a
power down mode. Keeping it in listening mode will really make it
possible for the system to reduce power (notice I do not define what is
exactly this mode as it can be implemented as the vendor wishes) yet
have the minimal capability to wake up.
13. O.K. Would you consider such an object definition instead: I think
it covers multiple thresholds. eponDeviceObjectReportNumThreshold
OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A set of 8 integers, for each LLID, that defines the
number of thresholds for each Queue in the REPORT
message, as defined in [802.3ah] 64. Each Queue set
reporting will provide information on the queue
occupancy of frames below the matching Threshold.
Writing can be done all the time.
This attribute is relevant for an OLT and an ONU."
DEFVAL { 0 }
::= { eponDeviceControlEntry 7 }
eponDeviceObjectReportThreshold OBJECT-TYPE
SYNTAX Integer32
UNITS "TQ (16nsec)"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A multiple set of 8 integers, for each LLID, that
defines the thresholds reporting for each Queue in the
REPORT message, as defined in [802.3ah] 64. The number
of sets is eponDeviceObjectReportNumThreshold. Each
Queue set reporting will provide information on the
queue occupancy of frames below the matching Threshold.
The value returned shall be in Time quanta (TQ) which
is 16nsec or 2 octets increments.
Writing can be done all the time.
This attribute is relevant for an OLT and an ONU."
DEFVAL { 0 }
::= { eponDeviceControlEntry 8 }
14. The OLT and ONUs of an EPON device serves as a distributed virtual
switch where the LLIDs represent bridge ports. This model is behind the
point to point emulation mechanism of clause 65 and of the whole LLID
concept. A bridge have a MAC address to port address table and this
table here serves for exactly the same purpose. It is not a proprietary
implementation. The eponDeviceRemoteMACAddressLLIDControl is a control
attribute for resetting this Table. As a table is a manageable entity I
think such an object is needed. The useDefaultReporting(3) category is a
common option for such attributes as a default setting for tables -
Implementation is according to Vendors preference. I have no special
suggestion for the default value. If people will feel more comfortable I
can remove useDefaultReporting(3) and return in the reading none(1).
15. 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.
16. As a general concept we tried to create in the EFM MIB objects a
reflection of the IEEE802.3ah management object keeping as much as we
can aligned to clause 30. There is here an additional section which
refers to device MIB objects. In there I tried to put all things which
are necessary for the management of an EPON device (in an access
network) and was not truly covered by the IEEE802.3ah spec as being a
spec for L2 MAC mainly. So although they are OAM they are in device
level.
Best regards,
Lior
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Romascanu, Dan (Dan)
Sent: Sunday, December 19, 2004 4:22 PM
To: [email protected]
Cc: Glen Kramer
Subject: [Hubmib] FW: EPON MIB comments
Although these comments from one of the 802.3ae contributors came in
after the WG Last Call deadline, I suggest that we enter them as Last
Call comments and address them accordingly.
Regards,
Dan
-----Original Message-----
From: Glen Kramer [mailto:[email protected]]
Sent: 16 December, 2004 9:49 PM
To: Romascanu, Dan (Dan)
Subject: EPON MIB comments
Dan,
I finally read the EPON MIB document. Below are my comments. I am not
sure if it is too late to make use of these, or not. Plsease, feel free
to post these on the reflector.
Regards,
Glen
1. In tables in section 7, object names that are split across lines lost
a letter.
2. dot3MpcpMode object should be read-only as is its counterpart in
802.3ah (aMPCPMode attribute).
3. dot3MpcpRoundTripTime should be defined for the OLT only, similarly
to its counterpart in 802.3ah (aMPCPRoundTripTime attribute). The ONUs
are not aware of the round-trip times to the OLT.
4. dot3MpcpOnTime and dot3MpcpOffTime. It is not clear from the
description that these objects refer to laser_on and laser_off times.
Also, according to the 802.3ah, these times are constant and fixed at 32
TQ. These objects are not necessary. Correspondingly, 802.3ah did not
find it necessary to specify such attributes in clause 30.
5. dot3MpcpRxNotSupportedMpcp. The description of this object does not
make sense. If a frame is not supported, it is not an MPCP frame.
Conversely, there exist no unsupported MPCP frames. There is no matching
attribute in clause 30 in 802.3ah and this object should be removed from
this draft as well.
6. Not clear why dot3OmpEmulationSLDErrors is mandatory at the OLT but
optional at the ONU. It is not optional per 802.3ah and is relevant for
both devices. (For comparison, the dot3OmpEmulationCRC8Errors is
mandatory in the OLT and ONUs).
7. dot3OmpEmulationBroadcastLLIDPlusOnuId. It is not clear what the
phrase "broadcast LLID plus ONU's LLID (frame reflected)" means. Should
it simply say "broadcast or unicast LLID"? Also, there is no relevant
attribute in clause 30 in 802.3ah.
8. dot3OmpEmulationNotBroadcastLLIDNotOnuId. This object is redundant,
as the dot3OmpEmulationBadLLID will count the same frames. I recommend
removing dot3OmpEmulationNotBroadcastLLIDNotOnuId from this draft.
9. The access to eponDeviceObjectReset object should be write-only. If
device is being reset, it cannot generate "reset" response. When the
device can generate the response, it will be running already. Thus, the
only possible response is "running".
10. The object eponDeviceObjectOamMode is not necessary. To get the OAM
mode, the management agent would access OAM MIB. No need to duplicate
objects in different MIBs.
11. eponDeviceObjectDeviceReadyMode object should be read-only.
Modifying device mode through the management may have unpredictable
results (like taking down entire EPON).
12. eponDeviceObjectPowerDown - "Setting this variable to True(1) will
cause Device to be entered into Power down mode where no registration is
allowed and only receiving data from the link.". This object does not
make sense. Setting it to True will cause the device lose the link
(because no transmission is allowed leading to MPCP timeout) and never
register again (because registration is not allowed).
13. eponDeviceObjectReportThreshold. The 802.3ah standard does not limit
number of thresholds to be used. This object will only return the first
threshold for each queue. What about the rest of thresholds? How to
read/set them?
14. eponDeviceRemoteMACAddressLLIDControl - "Indicates and controls the
resetting of the LLID MAC address log. Setting this object to none(1)
has no action resetLog(2) empties the LLID MAC address log. All data is
deleted. Setting it to useDefaultReporting(3) returns all entries
priorities to their factory-default reporting. Reading this object
always returns useDefaultReporting(3)." The description of this object
seems to match some proprietary EPON device. In the 802.3ah standard,
there is no provision of whether to keep LLID MAC address log. It is not
clear, what does it mean "returns all entries priorities to their
factory-default reporting", since there is no specification for either
"entries" or "factory-default reporting". This object should be removed.
15. 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.
16. The following objects represent non-EPON-specific events and should
be
moved to OAM MIB.
eponDeviceSampleMinimum
eponDeviceDyingGaspAlarmState
eponDeviceDyingGaspAlarmEnabled
eponDeviceCriticalEventState
eponDeviceCriticalEventEnabled
eponDeviceLocalLinkFaultAlarmState
eponDeviceLocalLinkFaultAlarmEnabled
eponDeviceTemperatureEventIndicationState
eponDeviceTemperatureEventIndicationEnabled
eponDevicePowerVoltageEventIndicationState
eponDevicePowerVoltageEventIndicationEnabled
eponDeviceGlobalEventState
eponDeviceGlobalEventEnabled
eponDeviceErroredSymbolPeriodEventState
eponDeviceErroredSymbolPeriodEventEnabled
eponDeviceErroredFrameEventState
eponDeviceErroredFrameEventEnabled
eponDeviceErroredFramePeriodEventState
eponDeviceErroredFramePeriodEventEnabled
eponDeviceErroredFrameSecondsSummaryEventState
eponDeviceErroredFrameSecondsSummaryEventEnabled
eponDeviceOrganizationSpecificEventState
eponDeviceOrganizationSpecificEventEnabled
eponDeviceEventControl
_______________________________________________
Hubmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/hubmib