1. 7/27/2004IETF San-Diego Plenary meeting 8/2004 EPON MIBs Lior Khermosh – Passave Technologies lior.khermosh@passave.com

2. 2/17/2004 - 2IETF Seoul Plenary meeting 3/2004 Agenda Changes from last draft

3. 2/17/2004 - 3IETF Seoul Plenary meeting 3/2004 EFM EPON MIBs http://www.ietf.org/internet-drafts/draft-ietf- hubmib-efm-epon-mib-01.txthttp://www.ietf.org/internet-drafts/draft-ietf- hubmib-efm-epon-mib-01.txt Includes: –DOT3-EFM-EPON-MIB –EPON-DEVICE-MIB

4. 2/17/2004 - 4IETF Seoul Plenary meeting 3/2004 DOT3-EFM-EPON-MIB MIBs update according to the final IEEE802.3ah draft 3.3 –Aligning all parameter to the spec. Handle comments from last session: –Editorial –Technical MIB compiling – still editorial issues Adding a section defining the relationship between the objects in this MIB and the management objects defined in IEEE802.3ah

5. 2/17/2004 - 5IETF Seoul Plenary meeting 3/2004 EPON-DEVICE-MIB Add relation to current device MIBs –EFM EPON MIB –optical device MIB –Bridge MIB –Adding device attributes referenced from DOCSIS device MIBs MIBs update according to the final IEEE802.3ah draft 3.3 –Aligning all parameter to the spec. Partitioning the MIBs into the following groups –Control –Statistics –LLID MAC address table –Events –Event Logs

6. 2/17/2004 - 6IETF Seoul Plenary meeting 3/2004 EPON-DEVICE-MIB Handle comments from last session: –Editorial –Technical MIB compiling – still editorial issues. Aligning all parameter to the spec Handle alarms and events according to the event MIB – adding event state, event enable and event logs, Remove overlap from EFM MIBs document in OAM parameters Handling specific comments (in backup slides for details if needed)

7. 2/17/2004 - 7IETF Seoul Plenary meeting 3/2004 Comments - Raj Subramanian - backup 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? –Editor’s reply: 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. –Group: Looking on more generic alarm/event MIBs and adopt the mechanisms. Turning the specific solution to a more generic throttling mechanism. Take it to the WG list discussion

8. 2/17/2004 - 8IETF Seoul Plenary meeting 3/2004 Comments - Raj Subramanian - backup 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. Editor’s reply: Agreed we can add a mechanism to insert OUI to identify a vendor - in the event

9. 2/17/2004 - 9IETF Seoul Plenary meeting 3/2004 Comments - Raj Subramanian - backup 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? Editor’s reply: eponDeviceObjectOnuLoopback – As defined now it is redundant and should be removed.

10. 2/17/2004 - 10IETF Seoul Plenary meeting 3/2004 Comments - Raj Subramanian - backup 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? Editor’s reply: Agreed. De-assertion will be added to the text

11. 2/17/2004 - 11IETF Seoul Plenary meeting 3/2004 Comments - Raj Subramanian - backup 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? Editor’s reply: 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.

12. 2/17/2004 - 12IETF Seoul Plenary meeting 3/2004 Comments - Raj Subramanian - backup 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? Editor’s reply: 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. I will add a description. The difference in my opinion is: Event is more referring to a system condition while alarm indicates a bad thing happening in the system.

13. 2/17/2004 - 13IETF Seoul Plenary meeting 3/2004 Comments - Raj Subramanian - backup eponDeviceObjectPowerDown Is setting the PowerDown a valid scenario for the EPON? Editor’s reply: 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.

14. 2/17/2004 - 14IETF Seoul Plenary meeting 3/2004 Comments – Jayaprakash Kulkarni - backup Is there any specific reason that you have included eponDeviceObjectOnuRegisterStatus when dot3MpcpRegistrationState is available for obtaining the MPCP Registration State? Editor’s reply: I will replace that in a more clear device attribute - maybe something like device ready or ready to transmit/receive data or something like that.

15. 2/17/2004 - 15IETF Seoul Plenary meeting 3/2004 Comments – Jayaprakash Kulkarni - backup eponDeviceObjectModes is defined as read-write, should it be a read- only value instead? eponDeviceObjectOamMode is also defined as read-write. Will eponDeviceObjectModes suffice to identify if the device is a oamServer or oamClient? For enabling/disabling the oam we could have a truth value. Editor’s reply: agree that the device modes can not be configure through the MIB so it is indeed a read-only attribute. I think that as for OAM mode is required to receive from a device a state mode of its OAM where 3 equal options exist - Server client and NoOAM. We can add the OAM disabling/enabling in addition to that.

16. 2/17/2004 - 16IETF Seoul Plenary meeting 3/2004 Author’s information Lior Khermosh Passave Technologies, –Ackerstein Towers, Tower A, 6th floor, –9 Hamenofim St. –Hertzliya Pituach 46725, –ISRAEL –P.O.Box 2089 Hertzliya Pituach 46120 Israel –Tel: +972-9-9717600 Ext: 7181 –Fax: +972-9-9540245 –Mob: +972-55-224054 –lior.khermosh@passave.com