RE: FW: EPON MIB comments (dot3MpcpRxNotSupportedMpcp)

[LK] Thanks. The dot3ControlInUnknownOpcodes is the necessary counter.


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


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

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

[GK] Aha! So it is simply a counter of "not supported MAC Control
opcodes". In this case, this object is not EPON specific, but general
for all Ethernet MIBs. Furthermore, this object already exists
(dot3ControlInUnknownOpcodes) 

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