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

From: "Lior khermosh" <[email-masked]>
Date: Wed, 5 Jan 2005 08:32:25 +0200

[LK] I will change broadcastLLID to broadcastBit I think that is the
attribute used in the spec. So I will clear the definition as follow:
dot3OmpEmulationBroadcastBitPlusOnuLlid OBJECT-TYPE
    SYNTAX  Counter32
    UNITS      "frames"
    MAX-ACCESS  read-only
    STATUS  current
    DESCRIPTION
            "A count of frames received that contain a valid SLD
             field in a OLT, as defined in [802.3ah] clause
             65.1.3.3.1, and pass the CRC-8 check, as defined in
             [802.3ah] clause 65.1.3.3.3, and contain the broadcast
             bit in LLID and the ONU's LLID (frame reflected) as 
             defined in [802.3ah] clause 65. This attribute is 
             mandatory for an ONU and mandatory for an OLT (a
             counter per LLID)."
    ::= { dot3OmpEmulationStatEntry 9}

-----Original Message-----
From: Glen Kramer [mailto:[email-masked]] 
Sent: Tuesday, January 04, 2005 10:06 PM
To: 'Lior khermosh'; 'Romascanu, Dan (Dan)'; [email-masked]
Subject: RE: [Hubmib] FW: EPON MIB comments

[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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf 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,
> 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 
> 7+their definition is too vague and refers to a long list of 
> 7+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

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

---

From: "Lior khermosh" <[email-masked]>
Date: Wed, 5 Jan 2005 13:40:47 +0200

[LK] Why is it referred only to debug mode? It can be needed during
operation also. Anyway management can affect device condition and
malfunctioning can be a result of any write operation even if it is
resetting of some database log/or table. I think that the security
section in the document should point to the proper place and point out
the hazards.
Why is it different in a concept from resetting an alarm table action or
from changing an operational mode? 

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

[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: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 11 Jan 2005 02:34:57 +0200

Lior, Matt, other, 

Please comment. 

Regards,

Dan

> Sent: 11 January, 2005 2:29 AM
> To: Romascanu, Dan (Dan); 'Lior khermosh'; [email-masked]
> Thanks for your response. I didn't try to enforce one-to-one 
> correspondence
> with IEEE spec. But there are attributes defined in EPON MIB 
> now that are
> applicable to non-EPON devices. For example, TxFrames, RxFrames, and
> DropFrames counters (see end of this e-mail) are attributes 
> of any 802.1D
> port. 
> Another example is alarm related attributes:
> These objects are equally applicable to point-to-point fiber 
> links or copper
> links. I believe they should be moved to OAM MIB. 
> 
> Regards,
> Glen
> 
> > From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> > Sent: Monday, January 10, 2005 3:46 PM
> > To: [email-masked]; Lior khermosh; [email-masked]
> > The focus of the EPON MIB  work is on defining management 
> objects for EPON
> > networks. This does not mean however providing a one-to-one 
> mapping to the
> > management attributes defined by the IEEE spec. According 
> to the case we
> > may define less, the same or more objects than the ones 
> defined by the
> > IEEE spec. We can even in some cases define objects that 
> are not EPON
> > specific, if they are helpful and the common management 
> practice is to use
> > them in the management of EPONs. This should however be rather the
> > exception, and if the non-EPON objects become a consistent 
> part of the
> > overall work I would recommend defining a separate MIB 
> module. Duplication
> > is generally considered a bad practice but please be more 
> specific about
> > what objects you consider being already covered in other 
> standard MIBs.
> > 
> > Regards,
> > 
> > Dan
> > (Speaking as chair)
> > 
> > 
> > 
> > 
> > > Sent: 11 January, 2005 1:31 AM
> > > To: 'Lior khermosh'; Romascanu, Dan (Dan); [email-masked]
> > > 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]
> > > > [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.
> > > >
> > > >
> > > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf
> > > > Of Glen Kramer
> > > > Sent: Wednesday, January 05, 2005 3:25 AM
> > > > [GK] Objects eponDeviceStatTxFramesQueue[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.
> > > >
> > > > [LK] The report message in the MPCP refers to such
> > > entities. Please see
> > > > [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: Tue, 11 Jan 2005 08:59:06 +0200

Glen,
We do not have any fundamental agreement. The EPON MIB objects document
is not trying to duplicate all objects from other MIBs and it tries to
fill what the author considered as missing from that for an EPON device.
Such an equipment usually uses many many protocols and higher layer
applications and I believe each one is needed to be covered by its own
MIB objects. So that if it is needed for a device to be a bridge then it
should rely on using the bridge MIB objects.
I think that this state of mind is clearly presented at the beginning of
the document. 
Please note however that the EPON has its special properties so if there
is needed a special consideration due to that, then I think it should be
in this MIB document. Obviously we will find it in objects which are on
the boundary of the L2 EPON. That is why considerations and issues so
often come regarding bridge MIB objects.

Please note that some device MIB objects documents of other standards
(not IEEE) used different approach and did try to define much more - for
instance DOCSIS (RFC2669). In such a document you can find for instance
IP addresses for the devices and reference to services. I think I
clearly do not take this approach in this document.

As for your specific point. You are assuming here that the ONU is a
bridge and therefore holding the 802.1D bridge MIB objects. I tried to
avoid the assumption of this specific implementation in the ONU. 
I think that in order to cover the items described in the MPCP spec
which include description of queues for transmission and reporting we
need these counters and can not assume that they are covered by other
MIB objects.

Lior

-----Original Message-----
From: Glen Kramer [mailto:[email-masked]] 
Sent: Tuesday, January 11, 2005 1:31 AM
To: 'Lior khermosh'; 'Romascanu, Dan (Dan)'; [email-masked]
Subject: RE: [Hubmib] FW: EPON MIB comments

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.

Regards,
Glen

> To: [email-masked]; 'Romascanu, Dan (Dan)'; [email-masked]
> [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.
> 
> 
> Behalf Of Glen Kramer

> [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: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 11 Jan 2005 22:54:37 +0200

> From: Matt Squire [mailto:[email-masked]]
> In the first revision of the OAM MIB, these states were 
> directly reflected.  In the -02 revision, all event 
> information was shoved into a new "EventLog" table.  So 
> transition in these are flags are reflected there.  I can add 
> them back as separate objects, I just don't want to go back 
> and forth.  In the transition to the -02 version, the 
> enable/disable of the events reflected in flags was 
> <stupidly> removed.  Can add that back as removing it was 
> unintentional.  

unintentional - maybe
stupid - I am not so sure :-)

The Alarm MIB (RFC 3877) can be used to define the alarms, their severity status, and also defines a log. We can consider using it, the balance being between the overhead of supporting the full Alarm MIB vs. the benefit of avoiding duplication.

Regards,

Dan

---

From: "Matt Squire" <[email-masked]>
Date: Sun, 16 Jan 2005 15:37:39 -0500

> The Alarm MIB (RFC 3877) can be used to define the alarms, 
> their severity status, and also defines a log. We can 
> consider using it, the balance being between the overhead of 
> supporting the full Alarm MIB vs. the benefit of avoiding duplication.

We talked about this a little bit at one of the IETF meetings a while back.  I had some simple "event status" objects defined at the time, and EPON had defined its own little event log.  The sense of the group was that I should EPON and OAM should define their own little event logs rather then try to leverage the alarm log.  

>From my notes (which I think were turned into your minutes):  
"
6) Event status table.  Currently, event information is stored as a TLV (e.g. an octet array).  The individual field are not pulled out and exposed.  A question was raised as to whether this is good or bad.  The positive aspects are that it results in fewer fields, but on the other side, the fields are probably useful and need to be exposed for a manager.  There seemed to be consensus that the fields should be pulled out of the TLV.  Also that we should be able to create a generic event table rather than one row per event type.
"

Hence we are where we are.  

- Matt