RE: RE: Comments resolution for EPON MIBs -draft-ietf-hubmib-efm-epon-mib-02.txt
"Lior khermosh" <[email protected]> Fri, 4 Mar 2005 22:49:29 +0200
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <[email protected]> |
Dan,
Here are my suggestions:
3.2
Change dot3MpcpMode to read-only
3.4
Keep the objects and add a note that they have a fixed value of 32TQs
3.8
The resolution of 3.7 and 3.8 results in clearing the naming for the
following 4 objects:
dot3OmpEmulationBroadcastBitNotOnuLlid 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.3] clause
65.1.3.3.1, and pass the CRC-8 check, as defined in
[802.3] clause 65.1.3.3.3, and contain broadcast bit
in LLID and not the ONU's LLID (frame accepted) as
defined in [802.3] clause 65 .
This attribute is mandatory for an OLT and for an ONU."
::= { dot3OmpEmulationStatEntry 7}
dot3OmpEmulationOnuLLIDNotBroadcast 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.3] clause
65.1.3.3.1, and pass the CRC-8 check, as defined in
[802.3] clause 65.1.3.3.3, and contain the ONU's LLID
as defined in [802.3] clause 65. This attribute is
mandatory for an ONU and mandatory for an OLT (a
counter per LLID)."
::= { dot3OmpEmulationStatEntry 8}
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.3] clause
65.1.3.3.1, and pass the CRC-8 check, as defined in
[802.3] clause 65.1.3.3.3, and contain the broadcast
bit in LLID and the ONU's LLID (frame reflected) as
defined in [802.3] clause 65. This attribute is
mandatory for an ONU and mandatory for an OLT (a
counter per LLID)."
::= { dot3OmpEmulationStatEntry 9}
dot3OmpEmulationNotBroadcastBitNotOnuLlid 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.3] clause
65.1.3.3.1, and pass the CRC-8 check, as defined in
[802.3] clause 65.1.3.3.3, and and does not contain
the ONU's LLID as defined in [802.3] clause 65.
This attribute is mandatory for an ONU"
::= { dot3OmpEmulationStatEntry 10}
3.11
eponDeviceObjectDeviceReadyMode
Keep the object as is. My opinion is that writing could dangerous but
needed for debugging, and so it can be for many write objects.
3.15
eponDeviceStatTxFramesQueue[0-7],
eponDeviceStatRxFramesQueue[0-7], and
eponDeviceStatDroppedFramesQueue[0-7]
Keep the objects as is. They are specified in the IEEE802.3ah and the
devices are not forced to be bridges so we can not count on the bridge
objects.
Best regards,
Lior
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Romascanu, Dan (Dan)
Sent: Thursday, March 03, 2005 4:35 PM
To: Lior khermosh; [email protected]; Edward Beili; Matt Squire; Glen
Kramer; [email protected]
Subject: [Hubmib] RE: Comments resolution for EPON MIBs
-draft-ietf-hubmib-efm-epon-mib-02.txt
Lior,
At this phase you need to provide clear proposals for comments
resolution (which does not mean that you need to accept them all). Can
you please be clear wrt. what you are suggesting for 3.2, 3.4, 3.8
(first issue), 3.11, 3.15?
Wrt. 3.9, it is enough to specify that the object always returns
'running' on a read operation.
Regards,
Dan
> -----Original Message-----
> From: Lior khermosh [mailto:[email protected]]
> Sent: 02 March, 2005 7:09 PM
> To: [email protected]; Romascanu, Dan (Dan); 'Edward Beili';
> 'Matt Squire'; 'Glen Kramer'; [email protected]
> Subject: Comments resolution for EPON MIBs -
> draft-ietf-hubmib-efm-epon-mib-02.txt
>
>
> Hi all,
> Here is the list if comments received on the
> draft-ietf-hubmib-efm-epon-mib-02.txt document and their proposed
> resolution. The comments were provided through this reflector.
> Comments are categorized according to their commenter. I tried to
> capture the entire discussion on each item. My final line is the
> proposed resolution.
>
> I want to take the opportunity here and thank again all commenters for
> the time and effort they have invested in reading and commenting.
>
> Thanks,
> Lior
>
>
> 1) Charles Chen [mailto:[email protected]]
>
> 1.1) I have a question regarding some counters of
> eponDeviceStatTable. I
> thought only the ONU has eight queues, which it can report to the OLT.
> So the ONU can have counters for respective queues. However, the
> counters defined in the table include those at the OLT. Do you assume
> that the OLT also have eight queues? Then how the queue information is
> passed from ONU to OLT or vice versus? How can we ensure the
> consistence
> between queues at ONU and those at OLT? Do you assume that we
> could use
> 802.1Q information to achieve this? Is this defined anywhere
> in 802.3ah?
>
> [LK]
> Actually the OLT counting of the queue model was assumed to
> be the same
> as the ONU but indeed it is not forced by the 802.3ah. I will
> remove in
> the description the reference to the OLT.
>
> 2)
>
> Long thread of discussion regarding "RE: [Hubmib] RE: EFM OAM MIB and
> the DateAndTime TC"
>
> OAM adopted suggestion by Dan :
>
> - add a Timestamp object
> - keep the current object, but change the SYNTAX to DateAndTimeOrZero,
> so that it returns zero if the managed entity does not have a clock
> capability Later, when some implementation experience will be
> achieved,
> we can deprecate one of the objects.
>
> [LK] I will practice the same for the EPON DateAndTime
> objects. 0 value
> indicated that there is no clock capability.
>
>
>
>
> 3) Glen Kramer [[email protected]]
>
>
> 3.1. In tables in section 7, object names that are split across lines
> lost a letter. [LK] Will be fixed
>
> 3.2. 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.
>
> [LK] Although I am generally in favor of extending management
> flexibilities I am willing to accept this observation regarding the
> great difference between an OLT and an ONU and as result the pointless
> in a configuration option. So unless anyone IS planning to make a
> device which can be an OLT or an ONU (please shout - objection) I
> will make it
> a read only attribute.
>
>
> 3.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.
>
> [LK] Agreed
>
> 3.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.
>
> [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.
>
> [LK] As opposed to other constants in the MPCP the switching time
> parameter has a meaning in management perspective as to BW management.
> It defines the efficiency of the link and therefore is in interest to
> the entire network. That is the reason why I considered that there is
> a sense in defining these attributes.
>
>
> 3.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.
>
> [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)
>
> [LK] Thanks. The dot3ControlInUnknownOpcodes is the necessary counter.
>
>
> 3.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).
>
> [LK] Agreed
>
> 3.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.
>
> 3.8. dot3OmpEmulationNotBroadcastLLIDNotOnuId. This object is
> redundant,
> as the dot3OmpEmulationBadLLID will count the same frames. I recommend
> removing dot3OmpEmulationNotBroadcastLLIDNotOnuId from this draft.
>
> [LK] 7+8 ) 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.
>
> [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}
>
>
> 3.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".
>
> [LK] 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.
>
> 3.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.
>
> [LK] Agreed
>
> 3.11. 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.
>
> [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?
>
>
> 3.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).
>
> [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.
>
>
> [LK] O.K. I see what you mean and that is not my intention. I want to
> refer to a general power down mode without referring to a specific
> implementation. So I will remove the reference for receiving data from
> link. eponDeviceObjectPowerDown OBJECT-TYPE
> SYNTAX TruthValue
> MAX-ACCESS read-write
> STATUS current
> DESCRIPTION
> "Setting this variable to True(1) will cause Device to be
> entered into Power down mode. Setting this variable to
> False(0) will cause the device to go out of power down
> mode. When getting True(1) the device is in power down.
> when getting False(0) the device is not in power down.
> Writing can be done all the time.
> This attribute is relevant for an OLT and an ONU."
> DEFVAL { false }
> ::= { eponDeviceControlEntry 5 }
>
>
>
> 3.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?
>
> [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
> "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 }
>
> [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.
>
> [LK] OK
>
>
> 3.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.
>
> [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.
>
> [LK] You are right. It seems like the definition of the table mixes 2
> things which were not my intention. My intention was not to hold a MAC
> address table as in a bridge (which is well covered in the bridge MIB
> objects and I had no intention to replica) but to hold a log of ONUs
> and their status. The description of the table is indeed confusing and
> I will clear it. I think that the MIBs in the table are O.K. I added
> the last 3 sentences for clarification in the last draft and they
> should be
> removed as confusing.
>
> Should be:
> eponDeviceRemoteMACAddressLLIDTable OBJECT-TYPE
> SYNTAX SEQUENCE OF EponDeviceRemoteMACAddressLLIDEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "A table of read-only value that identifies the
> source_address and LLIDs parameter of the remote devices
> in the network. This MacAddress value, as defined in
> [802.3ah], 30.3.5.1.5, is updated on reception of a
> valid frame with a unicast destination Field or
> (1) a destination Field equal to the reserved multicast
> address for MAC Control specified in [802.3ah] Annex
> 31A, (2) lengthOrType field value equal to the reserved
> Type for MAC Control as specified in [802.3ah] Annex
> 31A. (3)an MPCP subtype value equal to the subtype
> reserved for MPCP as specified in [802.3ah] Annex 31A,
> and an LLID as allocated by the OLT. The table is
> defined as Remote MAC address - LLID (RMadL)
> The table is relevant only for an OLT device"
> ::= { eponDeviceControlObjects 2 }
>
> [DR]
> Please clean up the grammar of this DESCRIPTION clause,
> otherwise it is
> hard to understand. Expressions like 'a table of read-only value that
> identifies...' or 'the table is defined as Remote MAC
> Address...' do not
> make too much sense to me. I can guess that you are referring to the
> objects (columns) in the table, but I will leave to you
> clarifying this
> text.
>
> [LK]
> eponDeviceRemoteMACAddressLLIDTable OBJECT-TYPE
> SYNTAX SEQUENCE OF EponDeviceRemoteMACAddressLLIDEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "A read-only table of objects that identifies the source
> MacAddress and LLIDs parameter of the remote devices in
> the network.
> This MacAddress value, as defined in [802.3],
> 30.3.5.1.5, is updated on reception of a valid frame
> with:
> (1) a unicast destination Field or a destination Field
> equal to the reserved multicast address for MAC Control
> specified in [802.3] Annex 31A.
> (2) lengthOrType field value equal to the reserved
> Type for MAC Control as specified in [802.3] Annex
> 31A.
> (3)an MPCP subtype value equal to the subtype reserved
> for MPCP as specified in [802.3] Annex 31A,
> and an LLID as allocated by the OLT.
> This table is denoted as 'Remote MAC address - LLID'
> (RMadL) table.
> The table is relevant only for an OLT device."
> ::= { eponDeviceControlObjects 2 }
>
>
> 3.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.
>
> [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.
>
> [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.
>
> [GK]
> 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.
>
> [LK]
> 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.
>
> Counters in .1D are defined to reflect operation at the 802.1 level -
> counters in the .3 MIBs should reflect behavior at the .3 level.
> Although both may define "DropFrames", the dropping point and
> therefore the actual semantics of the counter would be different. I'm
> not arguing
> that EPON needs or does not need a DropFrame counter, only that if it
> does define one, it has nothing to do with the 802.1D
> DropFrame counter.
>
>
> 3.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
>
> [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.
>
> [MS] Alarms exist in OAM MIB.
>
> [DR] I agree with Glen and Matt, although reflecting the objects from
> the management clause of 802.3ah is not a requirement. I made the
> comment at IETF-59 that RFC 3433 (Entity Sensor MIB) would be a better
> solution for temperature and voltage indication.
>
> [LK] Dan. Thanks for the detailed comment. I will verify the coverage
> and remove the objects from the EPON device MIB and create a reference
> instead.
>
>
>
> 4) Romascanu, Dan (Dan) [[email protected]]
>
> Technical
>
> T1. As per the revised charter, the new MAU MIB should provide a
> different mechanism for defining new MAU types. I recommend that all
> MAU extensions be taken out of this document and the new MAU MIB and
> extensibility mechanism be referred. This will also lead to changes in
> the IANA section (I believe)
>
>
>
>
> Editorial
>
> E1. The IEEE 802.3ah draft references need to be replaced by
> the name of
> the final IEEE standard, which is now available
>
> E2. Badly formatted title in Section 4.1
>
> E3. Section 4.1, row 4 - unjustified capital T
>
> E4. Replace 'OAM EFM MIB' with 'EFM OAM MIB'
>
> E5. Section 4.1 to 4.6 define requirements without using key
> words such
> as MUST and MAY as required by RFC 2119.
>
> E6. The last phrase in Section 5 needs not be introduced, or must be
> marked for the RFC Editor to be taken out at standard publication.
>
> E7. Acronyms as MPCP, P2MP, etc. need to be expanded at their first
> occurrence (which is I believe in Section 6)
>
> E8. The company designation of the WG chair is Avaya and not
> Avaya Inc.
>
> E9. Missing period in the DESCRIPTION clause of
> eponDeviceObjectFecEnable
>
>
> [LK] Agreed and All will be done.
>
>
>
>
>
>
>
>
>
>
_______________________________________________
Hubmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/hubmib