EPON MIBs

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

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

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

4. 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 IETF Seoul Plenary meeting 3/2004

5. 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 IETF Seoul Plenary meeting 3/2004

6. 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) IETF Seoul Plenary meeting 3/2004

7. 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 IETF Seoul Plenary meeting 3/2004

8. 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 IETF Seoul Plenary meeting 3/2004

9. 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. IETF Seoul Plenary meeting 3/2004

10. 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 IETF Seoul Plenary meeting 3/2004

11. 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. IETF Seoul Plenary meeting 3/2004

12. 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. IETF Seoul Plenary meeting 3/2004

13. 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. IETF Seoul Plenary meeting 3/2004

14. 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. IETF Seoul Plenary meeting 3/2004

15. 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. IETF Seoul Plenary meeting 3/2004

16. 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 IETF Seoul Plenary meeting 3/2004