1. 2/17/2004IETF Seoul Plenary meeting 3/2004 EPON MIBs Lior Khermosh – Passave Technologies lior.khermosh@passave.com

2. 2/17/2004 - 2IETF Seoul Plenary meeting 3/2004 Agenda EPON MIBs –DOT3-EFM-EPON-MIB –EPON-DEVICE-MIB

3. 2/17/2004IETF Seoul Plenary meeting 3/2004 EPON MIBs

4. 2/17/2004 - 4IETF Seoul Plenary meeting 3/2004 HubMIB EFM documents EFM general MIB document (includes OAM MIBs) –http://www.ietf.org/internet-drafts/draft-ietf-hubmib- efm-mib-00.txthttp://www.ietf.org/internet-drafts/draft-ietf-hubmib- efm-mib-00.txt EFM Copper MIBs –http://www.ietf.org/internet-drafts/draft-ietf-hubmib- efm-cu-mib-00.txthttp://www.ietf.org/internet-drafts/draft-ietf-hubmib- efm-cu-mib-00.txt EFM EPON MIBs –http://www.ietf.org/internet-drafts/draft-ietf-hubmib- efm-epon-mib-00.txthttp://www.ietf.org/internet-drafts/draft-ietf-hubmib- efm-epon-mib-00.txt

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

6. 2/17/2004IETF Seoul Plenary meeting 3/2004 DOT3-EFM-EPON-MIBs

7. 2/17/2004 - 7IETF Seoul Plenary meeting 3/2004 DOT3-EFM-EPON-MIB Includes the MIBs objects for managing devices and interfaces that conform to the Ethernet Passive Optical Networks (EPON) standards as defined in [802.3ah]. The document contains a list of management entities based on the registers defined in the [802.3ah] Annex 30A and mainly partitioned accordingly The document also provides amendments to the 802.3 MAU MIBs documents for the EFM device type addition.

8. 2/17/2004 - 8IETF Seoul Plenary meeting 3/2004 Relation to other Interfaces MIBs Relationship to the Interfaces MIB, the Ethernet- like Interfaces MIB and the MAU MIBEFM EPON interfaces require implementation of Interfaces MIB [RFC2863], Ethernet-like Interfaces MIB [RFC2665] and MAU-MIB [RFC3636]. –The MIBs defined in this document are an extension for these MIBs.

9. 2/17/2004 - 9IETF Seoul Plenary meeting 3/2004 Relation to other Interfaces MIBs Relationship to the Generic EFM MIBEFM EPON interfaces require implementation of Generic EFM MIB [draft-ietf-hubmib-efm-mib]. –This documents defines general EFM attributes and managed objects that are referred in the document.

10. 2/17/2004 - 10IETF Seoul Plenary meeting 3/2004 MIB structure The EFM EPON MIBs defines the objects used for configuration and description of the [802.3ah] P2MP section. These MIB objects are included of three MIB groups. –The MPCP MIBs –The OMPEmulation MIBs –The MAU MIBs

11. 2/17/2004 - 11IETF Seoul Plenary meeting 3/2004 MIB structure - The MPCP MIBs MIBs related to [802.3ah] clause 64 Multi Point Control Protocol attributes. In this MIB group: –The dot3MpcpTable defines the objects used for the configuration and description of the status of MPCP compliant interfaces. –The dot3MpcpStatTable defines the statistics group for MPCP compliant interfaces.

12. 2/17/2004 - 12IETF Seoul Plenary meeting 3/2004 MIB structure – The OMPEmulation MIBs MIBs related to [802.3ah] clause 65 point to point emulation attributes. In this MIB group: –The dot3OmpEmulationTable defines the objects used for the configuration and description of the status of OMPEmulation compliant interfaces. –The dot3OmpEmulationStatTable defines the statistics group for OMPEmulation compliant interfaces.

13. 2/17/2004 - 13IETF Seoul Plenary meeting 3/2004 MIB structure – The MAU MIBs including MAU type definitions and EPON MAU managed object related to [802.3ah] clause 60 and clause 65. –The dot3EponMauTable defines the objects used for the configuration and description of the status of MAU EPON compliant interfaces. –The dot3EponMauType defines the Type group for [802.3] EPOM MAUs. Editor note - The MAU Type object should probably be with other 802.3 MAU type objects [RFC 3636].

14. 2/17/2004 - 14IETF Seoul Plenary meeting 3/2004 The MPCP MIBs (backup) dot3MpcpTable –dot3MpcpAdminState –dot3MpcpMode –dot3MpcpLinkID –dot3MpcpRemoteMACAddress –dot3MpcpRegistrationState –dot3MpcpTransmitElapsed –dot3MpcpReceiveElapsed –dot3MpcpRoundTripTime –dot3MpcpMaximumPendingGrants –dot3MPCPAdminControl –dot3MpcpOnTime –dot3MpcpOffTime –dot3MpcpReceiverSettlingTime –dot3MpcpCdrLockTime –dot3MpcpSyncTime –dot3MpcpReportThreshold

15. 2/17/2004 - 15IETF Seoul Plenary meeting 3/2004 The MPCP MIBs (backup) dot3MpcpStatTable – dot3MpcpMACCtrlFramesTransmitted –dot3MpcpMACCtrlFramesReceived –dot3MpcpDiscoveryWindowsSent –dot3MpcpRegistrationAttempts –dot3MpcpDiscoveryTimeout –dot3MpcpTxRegRequest –dot3MpcpRxRegRequest –dot3MpcpTxRegAck –dot3MpcpRxRegAck –dot3MpcpTxReport –dot3MpcpRxReport –dot3MpcpTxGate –dot3MpcpRxGate –dot3MpcpTxRegister –dot3MpcpRxRegister –dot3MpcpRxNotSupportedMPCP –dot3MpcpTxFramesQueue0-7 –dot3MpcpRxFramesQueue0-7 –dot3MpcpDroppedFramesQueue0-7

16. 2/17/2004 - 16IETF Seoul Plenary meeting 3/2004 OMPEmulation MIBs (backup) dot3OmpEmulationTable –dot3OmpEmulationID –dot3OmpEmulationType dot3OmpEmulationStatTable –dot3OmpEmulationSPDErrors –dot3OmpEmulationCRC8Errors –dot3OmpEmulationBadLLID –dot3OmpEmulationBroadcastLLIDNotOnuID –dot3OmpEmulationOnuLLIDNotBroadcast –dot3OmpEmulationBroadcastLLIDPlusOnuId –dot3OmpEmulationNotBroadcastLLIDNotOnuId

17. 2/17/2004 - 17IETF Seoul Plenary meeting 3/2004 The MAU MIBs (backup) dot3EponMauTable –dot3EponMauPCSCodingViolation –dot3EponMauFecMode –dot3EponMauFECCorrectedBlocks –dot3EponMauFECUncorrectableBlocks –dot3EponMauBufferHeadCodingViolation

18. 2/17/2004 - 18IETF Seoul Plenary meeting 3/2004 The MAU MIBs (backup) The dot3EponMauType –eponMauType1000BasePXOLT –eponMauType1000BasePXONU –eponMauType1000BasePX10DOLT –eponMauType1000BasePX10DONU –eponMauType1000BasePX10UOLT –eponMauType1000BasePX10UONU –eponMauType1000BasePX20DOLT –eponMauType1000BasePX20DONU –eponMauType1000BasePX20UOLT –eponMauType1000BasePX20UONU

19. 2/17/2004 - 19IETF Seoul Plenary meeting 3/2004 Open Issues MIBs update according to the draft evolution –Update to draft 3.1

20. 2/17/2004IETF Seoul Plenary meeting 3/2004 DOT3-EFM-EPON-MIB Comments

21. 2/17/2004 - 21IETF Seoul Plenary meeting 3/2004 Comments – Dan Romascanu A. Technical A1. It is recommended to use Integer32 or Unsigned32 rather than INTEGER for objects which indicate an integer value, with the exception of enumeration objects. A2. unknown object identifier label `dot3EfmeponMIB' in the first MIB module. A3. There is a left-over bracket in the definition of eponDeviceObjectOnuLoopback which prevents correct compilation of the MIB module. A4 It would be very useful to add a section defining the relationship between the objects in this MIB and the management objects defined in IEEE 802.3 ah A5. The MIB content needs to be aligned with the latest IEEE 802.3ah draft (3.1?)

22. 2/17/2004 - 22IETF Seoul Plenary meeting 3/2004 Comments – Dan Romascanu B. Editorial - major B1. The formatting instructions have not been followed in a manner consistent with other Internet-Drafts. For example - left side alignment of text B2. Each MIB module should be contained in one document section or subsection and not be divided in subsections. B3. There should be both a copyright notice at the beginning of the document, and a copyright section at the end of the document. B4. The abstract section should not include references B5. The Security section needs to include the complete and explicit list of writeable objects, not only examples.

23. 2/17/2004 - 23IETF Seoul Plenary meeting 3/2004 Comments - Raj Subramanian 3. In the dot3MpcpEntry table : there are two fields dot3MpcpReceiverSettlingTime and dot3MpcpCdrLockTime. We do not 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? Editor’s reply: 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.

24. 2/17/2004 - 24IETF Seoul Plenary meeting 3/2004 Comments – Jayaprakash Kulkarni Two minor comments on latest draft-ietf-hubmib-efm- epon-mib-00.txt >>EfmeponMIB MODULE-IDENTITY Should it be dot3EfmeponMIB ? >>eponDeviceObjects OBJECT IDENTIFIER ::= { eponDevice 1} eponDevice is not defined, this might be eponDeviceObjectMIB? Editor’s reply: I accept the comments.

25. 2/17/2004IETF Seoul Plenary meeting 3/2004 EPON-DEVICE-MIBs

26. 2/17/2004 - 26IETF Seoul Plenary meeting 3/2004 EPON-DEVICE-MIB Includes the MIBs objects for managing of EPON form a device perspective, which are connected directly to the IEEE 802.3ah layer2 specifications.

27. 2/17/2004 - 27IETF Seoul Plenary meeting 3/2004 MIB structure The EPON Device MIBs defines the objects used for configuration and description of management objects for EPON compliant Devices. The eponDeviceTable defines the objects used for the configuration and description of the EPON compliant devices.

28. 2/17/2004 - 28IETF Seoul Plenary meeting 3/2004 EPON Device MIB (backup) eponDeviceTable –eponDeviceObjectReset –eponDeviceObjectModes –eponDeviceObjectFecEnabled –eponDeviceObjectOamMode –eponDeviceObjectOnuRegisterStatus –eponDeviceObjectPowerDown

29. 2/17/2004 - 29IETF Seoul Plenary meeting 3/2004 EPON Device MIB (backup) eponDeviceTable –eponDeviceObjectDyingGaspAlarmState –eponDeviceObjectCriticalEventState –eponDeviceObjectLocalLinkFaultAlarmState –eponDeviceObjectTemperatureEventIndicationState –eponDeviceObjectPowerVoltageEventIndicationState –eponDeviceObjectVendorSpecificAlarmState –eponDeviceObjectVendorSpecificEventState –eponDeviceObjectGlobalEvent0State to eponDeviceObjectGlobalEvent7State –eponDeviceObjectErroredSymbolPeriodEventState –eponDeviceObjectErroredFrameEventState –eponDeviceObjectErroredFramePeriodEventState –eponDeviceObjectErroredFrameSecondsSummaryEventState –eponDeviceObjectOrganizationSpecificEventState

30. 2/17/2004 - 30IETF Seoul Plenary meeting 3/2004 Open Issues Focusing of the Device MIBs targets Receive inputs from Telcos Add relation to current device MIBs –optical device MIBs (Link indications, optical components status,…) –Other similar access units MIBs ? MIBs update according to the draft evolution –Update to draft 3.1

31. 2/17/2004IETF Seoul Plenary meeting 3/2004 EPON-DEVICE-MIB Comments

32. 2/17/2004 - 32IETF Seoul Plenary meeting 3/2004 Comments - Raj Subramanian 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.

33. 2/17/2004 - 33IETF Seoul Plenary meeting 3/2004 Comments - Raj Subramanian 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

34. 2/17/2004 - 34IETF Seoul Plenary meeting 3/2004 Comments - Raj Subramanian 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.

35. 2/17/2004 - 35IETF Seoul Plenary meeting 3/2004 Comments - Raj Subramanian 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

36. 2/17/2004 - 36IETF Seoul Plenary meeting 3/2004 Comments - Raj Subramanian 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.

37. 2/17/2004 - 37IETF Seoul Plenary meeting 3/2004 Comments - Raj Subramanian 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.

38. 2/17/2004 - 38IETF Seoul Plenary meeting 3/2004 Comments - Raj Subramanian 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.

39. 2/17/2004 - 39IETF Seoul Plenary meeting 3/2004 Comments – Jayaprakash Kulkarni Is there any speicifc 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.

40. 2/17/2004 - 40IETF Seoul Plenary meeting 3/2004 Comments – Jayaprakash Kulkarni 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.

41. 2/17/2004 - 41IETF 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