RE: Clarifications in EPON Device MIB

Raj,
 
>1. Currently, as far as I know,  the standard 802.3ah does not suggest
a de-asserting mechanism. 
 
Isn't a deasserting mechanism also useful? For instance if the link is
bad the alarm might be received a lot of times. A deassertion option
will allow to remove such alarm.
 
> Can they be optional then?
How would then you suggest to define them. will a separate conformance
group do?
 
> 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.
 
We can remove one but add a mechanism to insert OUI to identify a vendor
- in the event.
 
Best regards,
Lior
 
-----Original Message-----
From: Rajagopalan Subramanian [mailto:[email protected]] 
Sent: Monday, February 16, 2004 2:19 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