RE: Clarifications in EPON Device MIB

Raj,
Indeed the MPCP is using sync time which is the addition of both. Without
intervening with MPCP considerations the optical devices has separate agc
and cdr times which from management perspective are very interesting to be
exchanged. (please note that the 802.3ah in clasue 60 and 65 refer to them
as different parameters which only the added time is complying). In order to
comply to the MPCP I will add an attribute for sync time but my opinion is
that agc and cdr time should also be maintained for management.


Best regards,
Lior

  -----Original Message-----
  From: Rajagopalan Subramanian [mailto:[email protected]]
  Sent: Thursday, February 19, 2004 3:48 PM
  To: 'Lior Khermosh'; '[email protected]'
  Cc: Hariprasad V. Nair
  Subject: RE: Clarifications in EPON Device MIB


  Hello Mr.Khermosh,



  One more query in addition to the ones I sent few days back.



  3.  In the dot3MpcpEntry table : there are two fields
dot3MpcpReceiverSettlingTime and  dot3MpcpCdrLockTime.

  We donot have any reference to these in the 802.3ah drafts.  If I am not
wrong, these two are replaced by the ‘SyncTime’ in the draft 1.414 itself.
Should we reflect this in the MIB too?



  Or am I missing something?!



  Thanks

  Raj.



  -----Original Message-----
  From: Rajagopalan Subramanian
  Sent: Monday, February 16, 2004 5:49 PM
  To: 'Lior Khermosh'; '[email protected]'
  Cc: Hariprasad V. Nair
  Subject: RE: Clarifications in EPON Device MIB



  Hello Mr. Khermosh,



  Thanks for your reply. I am forwarding the earlier questions posted by me
and your reply for that,  to the mailing list.



  Few more questions on your reply :



  1. Currently, as far as I know,  the standard 802.3ah does not suggest a
de-asserting mechanism.



  While standard specify a way to report the Critical link event, link fault
and Dying  Gasp events in the form of Flags field in the OAMPDU, it does not
talk about resetting them.

  Similar is the case for all the Errored Events though an assertion and
de-assertion is possible in this case without deviating from the standard, I
think.

  However all the Global Events, Temperature and Voltage specific events and
the Vendor SpecificAlarm Events,  are not defined in the standard. Can they
be optional then?



  2. One thing I missed to point out in my previous mail : Attribute
eponDeviceObjectOrganizationSpecificEventState seems to be identical to the
eponDeviceObjectVendorSpecificEventState attribute. Or are they different?
Please clarify.



  Thanks

  Raj Subramanian.





  -----Original Message-----
  From: Lior Khermosh [mailto:[email protected]]
  Sent: Sunday, February 15, 2004 12:34 PM
  To: Rajagopalan Subramanian
  Subject: RE: Clarifications in EPON Device MIB



  Dear Mr. Subramanian,



  Thank you very much for your comments. They are very helpful. I would like
to ask the permission to send the comments and replies to the hubmib
reflector for the interest of all people.



  eponDeviceObjectOnuLoopback – As defined now it is redundant and should be
removed.



  From eponDeviceObjectDyingGaspAlarmState :

  When the dyingGaspAlarm state is removed the dying gasp alarm is reset.

  I added it to the text.



  eponDeviceObjectTemperatureEventIndicationState,
eponDeviceObjectPowerVoltageEventIndicationState ,
eponDeviceObjectGlobalEvent0State…………………. eponDeviceObjectGlobalEvent7State



  The alarms are not defined at the 802.3ah draft. I will remove this
reference. However I still think that as alarms and event for device in
access system they are needed so I suggest to keep them. I will add a
description.



  eponDeviceObjectVendorSpecificAlarmState,
eponDeviceObjectVendorSpecificEventState

  The alarms are not defined at the 802.3ah draft. I will remove this
reference. However I still think that as alarms and event for device in
access system they are needed. Iwill add a description.



  The difference in my opinion is:



  Alarm:

  When the value of the alarm input is above the threshold defined for the
alarm the alarm is asserted. When the condition is below that threshold the
alarm is de-asserted.



  Event:

  When the indication of the event input occurs the event is asserted. When
the input is removed that event is de-asserted.



  Event is more referring to a system condition while alarm indicates a bad
thing happening in the system.



  eponDeviceObjectPowerDown

  I think it is. An ONU might have a battery back up and when the device is
starting to get down it indicates Power down. In my opinion it is a very
important indication for the carrier.





  Best regards,

  Lior Khermosh







    -----Original Message-----
    From: Rajagopalan Subramanian [mailto:[email protected]]
    Sent: Wednesday, February 11, 2004 6:51 AM
    To: '[email protected]'
    Cc: Rajagopalan Subramanian
    Subject: Clarifications in EPON Device MIB

    Hello Mr.Khermosh,



    I have few questions in the Device MIB that you had proposed as part of
the draft-ietf-hubmib-efm-epon-mib-00. I would appreciate  if you can help
me get it clarified.



    eponDeviceObjectOnuLoopback –

    In what way is this attribute different from the one defined in the EFM
MIB, dot3OamLoopbackCommand. In an implementation should both of these be
supported?





    From eponDeviceObjectDyingGaspAlarmState (Entry 8) to
eponDeviceObjectOrganizationSpecificEventState(Entry 27) –

    The SYNTAX in the MIB attribute says it’s a TruthValue and the
description says that ‘this bit should be asserted when we receive the
corresponding event’. My question is : The bit will be set when we receive
an event but when will we reset it ? It cannot be always ‘1’ whenever the
user reads this attribute, right?





    eponDeviceObjectTemperatureEventIndicationState,
eponDeviceObjectPowerVoltageEventIndicationState ,
eponDeviceObjectGlobalEvent0State…………………. eponDeviceObjectGlobalEvent7State

    The description says ‘ this event defines the state of the *respective*
event of the OAM Alarm Indications as specified in the [802.3ah] clause 57.

    But I could not locate these attributes in the Draft2.0 version of the
standard. Can you give me pointers as to where I should be looking into?



    eponDeviceObjectVendorSpecificAlarmState,
eponDeviceObjectVendorSpecificEventState

    The description for these two attributes are Identical.  I could not a
VendorAlarm and a VendorEvent, separately in the clause 57. Can you give
some info please?



    eponDeviceObjectPowerDown

    Is setting the PowerDown a valid scenario for the EPON?



    Thanks for your time.



    Regards,

    Raj Subramanian

    Centillium India,

    Bangalore, INDIA

    +91 80 25523575