EPON MIBs Lior Khermosh Passave Technologies lior

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

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

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

DOT 3 -EFM-EPON-MIB • MIBs update according to the final IEEE 802. 3 ah 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 IEEE 802. 3 ah 2/17/2004 - IETF 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 IEEE 802. 3 ah 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 2/17/2004 - IETF 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) 2/17/2004 - IETF Seoul Plenary meeting 3/2004

Comments - Raj Subramanian - backup • 1. Currently, as far as I know, the standard 802. 3 ah 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 Specific. Alarm 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 2/17/2004 - IETF Seoul Plenary meeting 3/2004 mechanisms. Turning the specific solution to a more generic throttling mechanism. Take it to the WG list discussion

Comments - Raj Subramanian - backup • 2. One thing I missed to point out in my previous mail : Attribute epon. Device. Object. Organization. Specific. Event. State seems to be identical to the epon. Device. Object. Vendor. Specific. Event. State 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 2/17/2004 - IETF Seoul Plenary meeting 3/2004

Comments - Raj Subramanian - backup • epon. Device. Object. Onu. Loopback – • In what way is this attribute different from the one defined in the EFM MIB, dot 3 Oam. Loopback. Command. In an implementation should both of these be supported? • Editor’s reply: epon. Device. Object. Onu. Loopback – As defined now it is redundant and should be removed. 2/17/2004 - IETF Seoul Plenary meeting 3/2004

Comments - Raj Subramanian - backup • From epon. Device. Object. Dying. Gasp. Alarm. State (Entry 8) to epon. Device. Object. Organization. Specific. Event. State(Entry 27) – • The SYNTAX in the MIB attribute says it’s a Truth. Value 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 2/17/2004 - IETF Seoul Plenary meeting 3/2004

Comments - Raj Subramanian - backup • epon. Device. Object. Temperature. Event. Indication. State, epon. Device. Object. Power. Voltage. Event. Indication. State , epon. Device. Object. Global. Event 0 State…………………. epon. Device. Object. Global. Event 7 State • The description says ‘ this event defines the state of the *respective* event of the OAM Alarm Indications as specified in the [802. 3 ah] clause 57. • But I could not locate these attributes in the Draft 2. 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. 3 ah 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. 2/17/2004 - IETF Seoul Plenary meeting 3/2004

Comments - Raj Subramanian - backup • epon. Device. Object. Vendor. Specific. Alarm. State, epon. Device. Object. Vendor. Specific. Event. State • The description for these two attributes are Identical. I could not a Vendor. Alarm and a Vendor. Event, separately in the clause 57. Can you give some info please? • Editor’s reply: The alarms are not defined at the 802. 3 ah 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. 2/17/2004 - IETF Seoul Plenary meeting 3/2004

Comments - Raj Subramanian - backup • epon. Device. Object. Power. Down • Is setting the Power. Down 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. 2/17/2004 - IETF Seoul Plenary meeting 3/2004

Comments – Jayaprakash Kulkarni - backup • Is there any specific reason that you have included epon. Device. Object. Onu. Register. Status when dot 3 Mpcp. Registration. State 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. 2/17/2004 - IETF Seoul Plenary meeting 3/2004

Comments – Jayaprakash Kulkarni - backup • epon. Device. Object. Modes is defined as read-write, should it be a readonly value instead? • epon. Device. Object. Oam. Mode is also defined as read-write. • Will epon. Device. Object. Modes suffice to identify if the device is a oam. Server or oam. Client? 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 No. OAM. We can add the OAM disabling/enabling in addition to that. 2/17/2004 - IETF Seoul Plenary meeting 3/2004

Author’s information Lior Khermosh Passave Technologies, – – – – – Ackerstein Towers, Tower A, 6 th 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 2/17/2004 - IETF Seoul Plenary meeting 3/2004