Subject: RE: [Hubmib] FW: EPON MIB comments

From: "Lior khermosh" <[email-masked]>
Date: Sat, 1 Jan 2005 22:32:51 +0200

Glen,
Thank you very much for the comments and for the time you invested in
reviewing the document. I appreciate it very much.

1. Thanks

2. I believe it is useful to have also a configuration possibility for
this parameter. As a guideline I believe management should have access
to define main modes of the system. Can you please specify why do you
think writing such a parameter is not useful? If we want to be strictly
following clause 30 I can add change the attribute in the device MIBs
objects to read-write but I would rather have it following the
configuration from the EFM MIB objects. 

3. Agreed

4. My believe is that the management entity as a general requires the
knowledge of the PON switching time and does not need to find parameters
in the spec to complete the picture as it is may be probably part of a
more general access system. I think the MIB objects should supply a
visibility of the system major parameters although some are fixed. I can
add the description of 32TQs value to align with the MPCP. 
 
5. dot3MpcpRxNotSupportedMpcp. The meaning here is to 8808 opcode frames
which are not of PAUSE or used by the MPCP protocol. I will clear the
description.

6. Agreed

7+8. If we can see the forwarding rules of the ONU in clause 65 then 
7+there is a behavior for frames with bit broadcast in the LLID where 
7+the LLID is the OLU's LLID (frames is rejected) and when the LLID is 
7+not the ONU's LLID (frame is accepted) as part of the point to point 
7+emulation peer to peer capabilities. This counter counts the first 
7+frame. I have sent in the past comments regarding that to clause 30. 
7+The result was  OnuPonCastLLID and OltPonCastLLID which I think their 
7+definition is too vague and refers to a long list of forwarding rules.

7+A solution for alignment is to make a request to change in the 
7+definition of these attributes in the spec and then unify these 
7+counters in them.

9. As a general logical deductive comment you have here a very good
comment. The problem comes when in devices a reset process can be a very
long process where many different sub-systems are reset. In such a
scenario there is a meaning for being in a reset process. Therefore I
believe that this is an attribute which is needed for a device. I am
open here for suggestions.

10. Thanks.

11. Changing this variable might indeed cause very major changes in the
system. Yet in my opinion it is needed for management. Unfortunately in
true life engineered systems there is a possibility that a system is not
operating well and it is needed to make it inactive immediately. The
purpose of such an attribute is like this. 

12. I guess the question is what is the meaning of power down. I thought
of a condition where the device is in minimal power mode where it is not
transmitting and it is in listening mode so it can be enabled by
activation according to MAC address. Keeping it registered can be done
easily by reducing its SLA to minimal BW but I don't think it  is a
power down mode. Keeping it in listening mode will really make it
possible for the system to reduce power (notice I do not define what is
exactly this mode as it can be implemented as the vendor wishes) yet
have the minimal capability to wake up.  

13. O.K. Would you consider such an object definition instead: I think
it covers multiple thresholds. eponDeviceObjectReportNumThreshold
OBJECT-TYPE
    SYNTAX  Integer32
    MAX-ACCESS  read-write
    STATUS  current
    DESCRIPTION
            "A set of 8 integers, for each LLID, that defines the
             number of thresholds for each Queue in the REPORT
             message, as defined in [802.3ah] 64. Each Queue set
             reporting will provide information on the queue 
             occupancy of frames below the matching Threshold. 
             Writing can be done all the time.
             This attribute is relevant for an OLT and an ONU."
    DEFVAL { 0 }
    ::= { eponDeviceControlEntry 7 }

    eponDeviceObjectReportThreshold OBJECT-TYPE
    SYNTAX  Integer32
    UNITS       "TQ (16nsec)"
    MAX-ACCESS  read-write
    STATUS  current
    DESCRIPTION
            "A multiple set of 8 integers, for each LLID, that 
             defines the thresholds reporting for each Queue in the 
             REPORT message, as defined in [802.3ah] 64. The number 
             of sets is eponDeviceObjectReportNumThreshold. Each 
             Queue set reporting will provide information on the  
             queue occupancy of frames below the matching Threshold.
             The value returned shall be in Time quanta (TQ) which 
             is 16nsec or 2 octets increments.
             Writing can be done all the time.
             This attribute is relevant for an OLT and an ONU."
    DEFVAL { 0 }
    ::= { eponDeviceControlEntry 8 }

14. The OLT and ONUs of an EPON device serves as a distributed virtual
switch where the LLIDs represent bridge ports. This model is behind the
point to point emulation mechanism of clause 65 and of the whole LLID
concept. A bridge have a MAC address to port address table and this
table here serves for exactly the same purpose. It is not a proprietary
implementation. The eponDeviceRemoteMACAddressLLIDControl is a control
attribute for resetting this Table. As a table is a manageable entity I
think such an object is needed. The useDefaultReporting(3) category is a
common option for such attributes as a default setting for tables -
Implementation is according to Vendors preference. I have no special
suggestion for the default value. If people will feel more comfortable I
can remove useDefaultReporting(3) and return in the reading none(1).

15. The report message in the MPCP refers to such entities. Please see
section 64.3.6.2 for report message format. These counters refer to
that.

16. As a general concept we tried to create in the EFM MIB objects a
reflection of the IEEE802.3ah management object keeping as much as we
can aligned to clause 30. There is here an additional section which
refers to device MIB objects. In there I tried to put all things which
are necessary for the management of an EPON device (in an access
network) and was not truly covered by the IEEE802.3ah spec as being a
spec for L2 MAC mainly. So although they are OAM they are in device
level.

Best regards,
Lior

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Romascanu, Dan (Dan)
Sent: Sunday, December 19, 2004 4:22 PM
To: [email-masked]
Cc: Glen Kramer
Subject: [Hubmib] FW: EPON MIB comments

Although these comments from one of the 802.3ae contributors came in
after the WG Last Call deadline, I suggest that we enter them as Last
Call comments and address them accordingly. 

Regards,

Dan

-----Original Message-----
From: Glen Kramer [mailto:[email-masked]]
Sent: 16 December, 2004 9:49 PM
To: Romascanu, Dan (Dan)
Subject: EPON MIB comments

Dan,

I finally read the EPON MIB document. Below are my comments. I am not
sure if it is too late to make use of these, or not. Plsease, feel free
to post these on the reflector.

Regards,
Glen

1. In tables in section 7, object names that are split across lines lost
a letter.

2. dot3MpcpMode object should be read-only as is its counterpart in
802.3ah (aMPCPMode attribute).

3. dot3MpcpRoundTripTime should be defined for the OLT only, similarly
to its counterpart in 802.3ah (aMPCPRoundTripTime attribute).  The ONUs
are not aware of the round-trip times to the OLT.

4. dot3MpcpOnTime and dot3MpcpOffTime. It is not clear from the
description that these objects refer to laser_on and laser_off times.
Also, according to the 802.3ah, these times are constant and fixed at 32
TQ. These objects are not necessary.  Correspondingly, 802.3ah did not
find it necessary to specify such attributes in clause 30.
 
5. dot3MpcpRxNotSupportedMpcp.  The description of this object does not
make sense. If a frame is not supported, it is not an MPCP frame.
Conversely, there exist no unsupported MPCP frames. There is no matching
attribute in clause 30 in 802.3ah and this object should be removed from
this draft as well.

6. Not clear why dot3OmpEmulationSLDErrors is mandatory at the OLT but
optional at the ONU. It is not optional per 802.3ah and is relevant for
both devices. (For comparison, the dot3OmpEmulationCRC8Errors is
mandatory in the OLT and ONUs).

7. dot3OmpEmulationBroadcastLLIDPlusOnuId. It is not clear what the
phrase "broadcast LLID plus ONU's LLID (frame reflected)" means. Should
it simply say "broadcast or unicast LLID"?  Also, there is no relevant
attribute in clause 30 in 802.3ah.

8. dot3OmpEmulationNotBroadcastLLIDNotOnuId. This object is redundant,
as the dot3OmpEmulationBadLLID will count the same frames. I recommend
removing dot3OmpEmulationNotBroadcastLLIDNotOnuId from this draft.

9. The access to eponDeviceObjectReset object should be write-only. If
device is being reset, it cannot generate "reset" response. When the
device can generate the response, it will be running already. Thus, the
only possible response is "running".

10. The object eponDeviceObjectOamMode is not necessary. To get the OAM
mode, the management agent would access OAM MIB. No need to duplicate
objects in different MIBs.

11. eponDeviceObjectDeviceReadyMode object should be read-only.
Modifying device mode through the management may have unpredictable
results (like taking down entire EPON).

12. eponDeviceObjectPowerDown - "Setting this variable to True(1) will
cause Device to be entered into Power down mode where no registration is
allowed and only receiving data from the link.". This object does not
make sense. Setting it to True will cause the device lose the link
(because no transmission is allowed leading to MPCP timeout) and never
register again (because registration is not allowed).

13. eponDeviceObjectReportThreshold. The 802.3ah standard does not limit
number of thresholds to be used.  This object will only return the first
threshold for each queue. What about the rest of thresholds? How to
read/set them?

14. eponDeviceRemoteMACAddressLLIDControl - "Indicates and controls the
resetting of the LLID MAC address log. Setting this object to none(1)
has no action resetLog(2) empties the LLID MAC address log. All data is
deleted. Setting it to useDefaultReporting(3) returns all entries
priorities to their factory-default reporting. Reading this object
always returns useDefaultReporting(3)." The description of this object
seems to match some proprietary EPON device. In the 802.3ah standard,
there is no provision of whether to keep LLID MAC address log. It is not
clear, what does it mean "returns all entries priorities to their
factory-default reporting", since there is no specification for either
"entries" or "factory-default reporting". This object should be removed.

15. Objects eponDeviceStatTxFramesQueue[0-7],
eponDeviceStatRxFramesQueue[0-7], and
eponDeviceStatDroppedFramesQueue[0-7]
are not specific to EPON. These objects exist for other devices, such as
bridge ports. There is no need to duplicate these objects here. Besides,
neither 802.3ah nor 802.1D standards require exactly 8 queues to be
implemented. I recommend removing these objects.

16. The following objects represent non-EPON-specific events and should
be
moved to OAM MIB.   
   eponDeviceSampleMinimum 
   eponDeviceDyingGaspAlarmState
   eponDeviceDyingGaspAlarmEnabled
   eponDeviceCriticalEventState
   eponDeviceCriticalEventEnabled
   eponDeviceLocalLinkFaultAlarmState
   eponDeviceLocalLinkFaultAlarmEnabled
   eponDeviceTemperatureEventIndicationState
   eponDeviceTemperatureEventIndicationEnabled
   eponDevicePowerVoltageEventIndicationState
   eponDevicePowerVoltageEventIndicationEnabled
   eponDeviceGlobalEventState
   eponDeviceGlobalEventEnabled
   eponDeviceErroredSymbolPeriodEventState
   eponDeviceErroredSymbolPeriodEventEnabled
   eponDeviceErroredFrameEventState
   eponDeviceErroredFrameEventEnabled
   eponDeviceErroredFramePeriodEventState
   eponDeviceErroredFramePeriodEventEnabled
   eponDeviceErroredFrameSecondsSummaryEventState
   eponDeviceErroredFrameSecondsSummaryEventEnabled
   eponDeviceOrganizationSpecificEventState
   eponDeviceOrganizationSpecificEventEnabled
   eponDeviceEventControl

_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "Glen Kramer" <[email-masked]>
Date: Tue, 4 Jan 2005 11:04:21 -0800

Lior,

I am going to break this large e-mail into separate threads, so it is easier
to follow the discussion per comment. This one is about dot3MpcpMode.

[GK] dot3MpcpMode object should be read-only as is its counterpart in
802.3ah (aMPCPMode attribute).

[LK] I believe it is useful to have also a configuration possibility for
this parameter. As a guideline I believe management should have access to
define main modes of the system. Can you please specify why do you think
writing such a parameter is not useful? If we want to be strictly following
clause 30 I can add change the attribute in the device MIBs objects to
read-write but I would rather have it following the configuration from the
EFM MIB objects.

[GK] dot3MpcpMode specifies whether the device is an OLT or an ONU. *ALL*
MPCP state machines defined by IEEE 802.3ah are specified either for the OLT
or ONUs. There are no common state machines. It is not possible to change a
configuration parameter and force the OLT to behave as the ONU or the ONU to
behave as the OLT. If in a network, the management somehow forces the mode
change for an EPON device, this will result in EPON malfunction.
In addition, physical layer parameters are different for these devices: OLT
has burst-mode receiver and normal transmitter and ONUs have normal receiver
and burst-mode transmitter. 

Regards,
Glen

> Of Lior khermosh
> Sent: Saturday, January 01, 2005 12:33 PM
> To: 'Romascanu, Dan (Dan)'; [email-masked]
> Cc: 'Glen Kramer'
> Subject: RE: [Hubmib] FW: EPON MIB comments
> 
> Glen,

---

From: "Glen Kramer" <[email-masked]>
Date: Tue, 4 Jan 2005 11:23:20 -0800

[GK] dot3MpcpOnTime and dot3MpcpOffTime. It is not clear from the
description that these objects refer to laser_on and laser_off times. Also,
according to the 802.3ah, these times are constant and fixed at 32 TQ. These
objects are not necessary.  Correspondingly, 802.3ah did not find it
necessary to specify such attributes in clause 30.

[LK] My believe is that the management entity as a general requires the
knowledge of the PON switching time and does not need to find parameters in
the spec to complete the picture as it is may be probably part of a more
general access system. I think the MIB objects should supply a visibility of
the system major parameters although some are fixed. I can add the
description of 32TQs value to align with the MPCP.

[GK] There is a large number of constants specified in MPCP spec. Laser-on
and laser-off constants are not more important that other parameters. Why
would you choose to define MIB objects for some constants and not other? 
If the management entity does not know what "PON switching time" is, it
cannot query dot3MpcpOnTime and dot3MpcpOffTime objects. If the management
is EPON-specific enough to understand that there exists "PON switching
time", it already knows that this is a constant equal 32 TQ. 

Regards,
Glen

---

From: "Glen Kramer" <[email-masked]>
Date: Tue, 4 Jan 2005 11:49:38 -0800

[GK] dot3MpcpRxNotSupportedMpcp.  The description of this object does not
make sense. If a frame is not supported, it is not an MPCP frame.
Conversely, there exist no unsupported MPCP frames. There is no matching
attribute in clause 30 in 802.3ah and this object should be removed from
this draft as well.

[LK] dot3MpcpRxNotSupportedMpcp. The meaning here is to 8808 opcode frames
which are not of PAUSE or used by the MPCP protocol. I will clear the
description.

[GK] Aha! So it is simply a counter of "not supported MAC Control opcodes".
In this case, this object is not EPON specific, but general for all Ethernet
MIBs. Furthermore, this object already exists (dot3ControlInUnknownOpcodes) 

Regards,
Glen

---

From: "Glen Kramer" <[email-masked]>
Date: Tue, 4 Jan 2005 12:05:55 -0800

[GK] Comment #7: dot3OmpEmulationBroadcastLLIDPlusOnuId. It is not clear
what the phrase "broadcast LLID plus ONU's LLID (frame reflected)" means.
Should it simply say "broadcast or unicast LLID"?  Also, there is no
relevant attribute in clause 30 in 802.3ah. 
Comment #8: dot3OmpEmulationNotBroadcastLLIDNotOnuId. This object is
redundant, as the dot3OmpEmulationBadLLID will count the same frames. I
recommend removing dot3OmpEmulationNotBroadcastLLIDNotOnuId from this draft.

[LK] If we can see the forwarding rules of the ONU in clause 65 then there
is a behavior for frames with bit broadcast in the LLID where the LLID is
the OLU's LLID (frames is rejected) and when the LLID is not the ONU's LLID
(frame is accepted) as part of the point to point emulation peer to peer
capabilities. This counter counts the first frame. I have sent in the past
comments regarding that to clause 30.
The result was OnuPonCastLLID and OltPonCastLLID which I think their
definition is too vague and refers to a long list of forwarding rules. A
solution for alignment is to make a request to change in the definition of
these attributes in the spec and then unify these counters in them.

[GK] I understand now the intentions of this object. I must add that its
description needs some work. Also, more appropriate name would be
"dot3OmpEmulationMode1PlusOnuId", because "Broadcast LLID" refers to a very
specific 15-bit value.
Also note that this mode would be used for shared medium emulation, not P2P.

Regards,
Glen

---

From: "Glen Kramer" <[email-masked]>
Date: Tue, 4 Jan 2005 16:17:52 -0800

[GK] eponDeviceObjectDeviceReadyMode object should be read-only. Modifying
device mode through the management may have unpredictable results (like
taking down entire EPON).

[LK] Changing this variable might indeed cause very major changes in the
system. Yet in my opinion it is needed for management. Unfortunately in true
life engineered systems there is a possibility that a system is not
operating well and it is needed to make it inactive immediately. The purpose
of such an attribute is like this.

[GK] We should not confuse MIB with debug functions. I would agree to have
an object that would allow disabling a device. I am against allowing
management changing device mode from notReady to ready or from inProcess to
ready. This would take down the device and very likely would take down the
entire EPON. Device mode should only change according to state machines
defined in IEEE 802.3ah.

Regards,
Glen

---

From: "Glen Kramer" <[email-masked]>
Date: Tue, 4 Jan 2005 16:34:10 -0800

[GK] eponDeviceObjectPowerDown - "Setting this variable to True(1) will
cause Device to be entered into Power down mode where no registration is
allowed and only receiving data from the link.". This object does not make
sense. Setting it to True will cause the device lose the link (because no
transmission is allowed leading to MPCP timeout) and never register again
(because registration is not allowed).

[LK] I guess the question is what is the meaning of power down. I thought of
a condition where the device is in minimal power mode where it is not
transmitting and it is in listening mode so it can be enabled by activation
according to MAC address. Keeping it registered can be done easily by
reducing its SLA to minimal BW but I don't think it is a power down mode.
Keeping it in listening mode will really make it possible for the system to
reduce power (notice I do not define what is exactly this mode as it can be
implemented as the vendor wishes) yet have the minimal capability to wake
up.

[GK] This is very suspiciously seems like fitting of MIB spec to a specific
proprietary implementation. Even if device is not transmitting any user
data, it should periodically transmit MPCP and OAM messages. 
You are trying to define some kind of standby mode without clear explanation
what this mode is or how it can be implemented. I argue that because MPCP
relies on periodic messages, this mode is not possible without breaking IEEE
802.3ah standard.
"Keeping it registered can be done easily by reducing its SLA to minimal
BW..." This is a particular implementation. Device registration has nothing
to do with the provisioned SLA. There is a very formal state machine that
explains steps of EPON device registration.

---

From: "Glen Kramer" <[email-masked]>
Date: Tue, 4 Jan 2005 16:46:15 -0800

[GK] eponDeviceObjectReportThreshold. The 802.3ah standard does not limit
number of thresholds to be used.  This object will only return the first
threshold for each queue. What about the rest of thresholds? How to read/set
them?

[LK] O.K. Would you consider such an object definition instead: I think it
covers multiple thresholds. 

> eponDeviceObjectReportNumThreshold
> OBJECT-TYPE
>     SYNTAX  Integer32
>     MAX-ACCESS  read-write
>     STATUS  current
>     DESCRIPTION

[GK] This is better. For the eponDeviceObjectReportNumThreshold, we need to
describe what happens if this parameter is set to a value greater than the
device can support.  Or maybe we should define a read-only object
eponDeviceObjectReportMaximumNumThreshold that would inform management
entity of the maximum supported number of thresholds.

I would also add read-only object for maximum supported number of queues:
802.1D says that a device can have from 1 to 8 queues.

---

From: "Glen Kramer" <[email-masked]>
Date: Tue, 4 Jan 2005 17:02:17 -0800

[GK] eponDeviceRemoteMACAddressLLIDControl - "Indicates and controls the
resetting of the LLID MAC address log. Setting this object to none(1) has no
action resetLog(2) empties the LLID MAC address log. All data is deleted.
Setting it to useDefaultReporting(3) returns all entries priorities to their
factory-default reporting. Reading this object always returns
useDefaultReporting(3)." The description of this object seems to match some
proprietary EPON device. In the 802.3ah standard, there is no provision of
whether to keep LLID MAC address log. It is not clear, what does it mean
"returns all entries priorities to their factory-default reporting", since
there is no specification for either "entries" or "factory-default
reporting". This object should be removed.

[LK] The OLT and ONUs of an EPON device serves as a distributed virtual
switch where the LLIDs represent bridge ports. This model is behind the
point to point emulation mechanism of clause 65 and of the whole LLID
concept. A bridge have a MAC address to port address table and this table
here serves for exactly the same purpose. It is not a proprietary
implementation. The eponDeviceRemoteMACAddressLLIDControl is a control
attribute for resetting this Table. As a table is a manageable entity I
think such an object is needed. The useDefaultReporting(3) category is a
common option for such attributes as a default setting for tables -
Implementation is according to Vendors preference. I have no special
suggestion for the default value. If people will feel more comfortable I can
remove useDefaultReporting(3) and return in the reading none(1).

[GK] There is no document defining what is "LLID MAC address log". The
phrase "The OLT and ONUs of an EPON device serves as a distributed virtual
switch where the LLIDs represent bridge ports" assumes a particular
implementation.
LLIDs do not represent bridge ports. LLID represent virtual links.  These
links may or may not be connected to a bridge at the OLT. The
eponDeviceRemoteMACAddressLLIDControl attribute refers to an address table
in the bridge and has nothing to do with EPON. Therefore, it should be moved
to the bridge MIB.

Regards,
Glen

---

From: "Glen Kramer" <[email-masked]>
Date: Tue, 4 Jan 2005 17:24:51 -0800

[GK] Objects eponDeviceStatTxFramesQueue[0-7],

[LK] The report message in the MPCP refers to such entities. Please see
section 64.3.6.2 for report message format. These counters refer to that.

[GK] The REPORT message does not refer directly of indirectly to any such
entities. I attached the clause 64.3.6.2. Would appreciate if you could
point where and how this clause refers to count of transmitted, received,
and dropped frames. 
I agree that these are useful parameters. But my point is that they are
already defined and are not EPON-specific. There is no need to duplicate
them in this MIB.
 
Regards,
Glen

---

From: "Glen Kramer" <[email-masked]>
Date: Tue, 4 Jan 2005 17:37:28 -0800

[GK] The following objects represent non-EPON-specific events and should be
moved to OAM MIB.
>    eponDeviceOrganizationSpecificEventEnabled

[LK] As a general concept we tried to create in the EFM MIB objects a
reflection of the IEEE802.3ah management object keeping as much as we can
aligned to clause 30. There is here an additional section which refers to
device MIB objects. In there I tried to put all things which are necessary
for the management of an EPON device (in an access network) and was not
truly covered by the IEEE802.3ah spec as being a spec for L2 MAC mainly. So
although they are OAM they are in device level.

[GK] Lior, any network device is a combination of multiple specs. And
correspondingly, management of a network device comprises many MIBs. EPON
MIB should only cover EPON-specific objects. There exist many other MIBs
that are not EPON-specific, but that must be implemented in EPON devices.
Such objects as eponDeviceDyingGaspAlarmEnabled and
eponDeviceTemperatureEventIndicationState (and all other objects listed
above) are not EPON-specific. They exist in other MIBs.
What I am trying to say is that EPON MIB will not be used as substitution
for other MIBs. It is to be used in EPON devices in addition to other MIBs. 

Regards,
Glen

---

From: prarch <[email-masked]>
Date: Tue, 04 Jan 2005 21:35:31 -0500

A new start up company located in New York, NY in VoIP/Telephony software 
space is looking for software architects and developers.

  1.. Network Management Software product architects
  2.. SNMP/MIB architects and developers
  3.. Voice application product architects
  4.. Voice protocol architects and developers
  5.. Application GUI architects and developers
  6.. Technical marketing and product engineering
  7.. Sales engineers

Please send your resume to [email-masked]

----- Original Message ----- 
From: "Glen Kramer" <[email-masked]>
To: "'Lior khermosh'" <[email-masked]>; "'Romascanu, Dan (Dan)'" 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, January 04, 2005 7:34 PM
Subject: RE: [Hubmib] FW: EPON MIB comments (eponDeviceObjectPowerDown)

> activation

---

From: "Lior khermosh" <[email-masked]>
Date: Thu, 6 Jan 2005 09:07:43 +0200

[LK] of course it does not refer to the counters. It refers to the
queues. The counters are an outcome of these entities. 
As indeed you say they are useful parameters. As it is not defined in
the EFM MIB objects I added them to the device MIB objects.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Glen Kramer
Sent: Wednesday, January 05, 2005 3:25 AM
To: 'Lior khermosh'; 'Romascanu, Dan (Dan)'; [email-masked]
Subject: RE: [Hubmib] FW: EPON MIB comments

[GK] The REPORT message does not refer directly of indirectly to any
such entities. I attached the clause 64.3.6.2. Would appreciate if you
could point where and how this clause refers to count of transmitted,
received, and dropped frames. 
I agree that these are useful parameters. But my point is that they are
already defined and are not EPON-specific. There is no need to duplicate
them in this MIB.
 
Regards,
Glen

---

From: "Lior khermosh" <[email-masked]>
Date: Thu, 6 Jan 2005 09:09:22 +0200

[LK] Can you kindly please refer to the MIBs where all these entities
exist in.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Glen Kramer
Sent: Wednesday, January 05, 2005 3:37 AM
To: 'Lior khermosh'; 'Romascanu, Dan (Dan)'; [email-masked]
Subject: RE: [Hubmib] FW: EPON MIB comments

[GK] The following objects represent non-EPON-specific events and should
be moved to OAM MIB.

[GK] Lior, any network device is a combination of multiple specs. And
correspondingly, management of a network device comprises many MIBs.
EPON MIB should only cover EPON-specific objects. There exist many other
MIBs that are not EPON-specific, but that must be implemented in EPON
devices. Such objects as eponDeviceDyingGaspAlarmEnabled and
eponDeviceTemperatureEventIndicationState (and all other objects listed
above) are not EPON-specific. They exist in other MIBs.
What I am trying to say is that EPON MIB will not be used as
substitution for other MIBs. It is to be used in EPON devices in
addition to other MIBs. 

Regards,
Glen

---

From: "Glen Kramer" <[email-masked]>
Date: Mon, 10 Jan 2005 15:30:35 -0800

Lior,

I think we have a fundamental disagreement on the scope of this document. I
argue that this MIB should only include EPON-specific objects, i.e., objects
that you would not find in any other MIB. This would include statistics for
MPCP messages, LLIDs, and so on. I believe that EPON devices should
implement multiple MIBs: OAM MIB, Bridging MIB, and EPON-specific MIB.
It seems to me that your approach is to define a single MIB that would
include (or duplicate) all objects that *MAY BE* used in EPON, even though
these objects may already have been defined elsewhere. 

For example, counters of transmitted, received, and dropped frames per queue
are not EPON-specific. Any port (according to 802.1D) may have up to 8
queues behind it and would count these statistics. I don't think these
objects belong to EPON-specific MIB.

Before further discussing specific comments, I'd like to ask for a
clarification from the task force on the scope of this document.

Regards,
Glen

> From: Lior khermosh [mailto:[email-masked]]
> Sent: Wednesday, January 05, 2005 11:08 PM
> To: [email-masked]; 'Romascanu, Dan (Dan)'; [email-masked]