RE: FW: EPON MIB comments (dot3MpcpMode)

[LK] Although I am generally in favor of extending management
flexibilities I am willing to accept this observation regarding the
great difference between an OLT and an ONU and as result the pointless
in a configuration option.
So unless anyone IS planning to make a device which can be an OLT or an
ONU (please shout - objection) I will make it a read only attribute.

-----Original Message-----
From: Glen Kramer [mailto:[email protected]] 
Sent: Tuesday, January 04, 2005 9:04 PM
To: 'Lior khermosh'; 'Romascanu, Dan (Dan)'; [email protected]
Subject: RE: [Hubmib] FW: EPON MIB comments (dot3MpcpMode)


Lior,

I am going to break this large e-mail into separate threads, so it is
easier to follow the discussion per comment. This one is about
dot3MpcpMode.


[GK] dot3MpcpMode object should be read-only as is its counterpart in
802.3ah (aMPCPMode attribute).

[LK] 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.

[GK] dot3MpcpMode specifies whether the device is an OLT or an ONU.
*ALL* MPCP state machines defined by IEEE 802.3ah are specified either
for the OLT or ONUs. There are no common state machines. It is not
possible to change a configuration parameter and force the OLT to behave
as the ONU or the ONU to behave as the OLT. If in a network, the
management somehow forces the mode change for an EPON device, this will
result in EPON malfunction. In addition, physical layer parameters are
different for these devices: OLT has burst-mode receiver and normal
transmitter and ONUs have normal receiver and burst-mode transmitter. 


Regards,
Glen



> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Lior khermosh
> Sent: Saturday, January 01, 2005 12:33 PM
> To: 'Romascanu, Dan (Dan)'; [email protected]
> Cc: 'Glen Kramer'
> Subject: RE: [Hubmib] FW: EPON MIB comments
> 
> 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 
> 7+their definition is too vague and refers to a long list of 
> 7+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
> 
> 
> _______________________________________________
> Hubmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/hubmib