RE: RE: Review of EPON-04
"Romascanu, Dan \(Dan\)" <[email protected]> Tue, 25 Jul 2006 11:58:47 +0300
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <AAB4B3D3CF0F454F98272CBE187FDE2F0AE426D5@is0004avexu1.global.avaya.com> |
Thanks to Lior for the editing and to David for the detailed review. David, can you please verify EPON-04 and let us know if your comments were addressed? We would like to have your advise whether the document is in good enough shape to be submitted to the IESG for approval. Thanks and Regards, Dan > -----Original Message----- > From: Lior Khermosh [mailto:[email protected]] > Sent: Monday, July 24, 2006 12:03 AM > To: David T. Perkins; [email protected] > Subject: [Hubmib] RE: Review of EPON-04 > > Hi, > I am grateful for the serious review and the comments. Thanks > for the hard work done. > Please see my responses to the comments below and the revised > document attached. I am submitting this document as a draft. > Best regards, > Lior > > > -----Original Message----- > From: David T. Perkins [mailto:[email protected]] > Sent: Saturday, May 27, 2006 1:51 AM > To: [email protected] > Cc: Lior Khermosh > Subject: Review of EPON-04 > > HI, > > My comments are below. > > General comments: > 1) The updated document looks much better than the -03 version. > 2) It runs through both SMICng and smilint with no problems. > 3) I read through the document fairly quickly, and didn't > try to verify all the references to other documents. > 4) There are many grammar problems throughout the document, > and, thus, the document would be much improved by > a pass from a "copy editor" for technical documents. > [LK] I have done a deep review of the text and tried to > improve it dramatically (it actually took me most of the time > for this version). I hope it is in an appropriate level. > > 5) The interface model that the document covers is quite > unusual, and thus requires more work in this document > to describe it than other well known and simple interfaces. > 6) This version resolved many of issues from the previous > revision. However, I still have concerns with a > few corner cases. These include: > a) discontinuity of counters > b) dependencies of stacked interfaces [LK] Please see > specific comment below. I hope it resolves the concerns. > 7) I believe that the document needs to be updated and > reviewed at least one more time. > > Specific Comments: > 0) The interface type should be ethernetCsmacd(6) as specified > in RFC 3635. > [LK] Done. > > 1) The abstract and the overview paragraphs are different. > The abstract includes management of P2MP networks, > which is not included in the overview. > [LK] Fixed the abstract. > > 2) The terminology and abbreviations need to be checked > for completeness. I noticed the following that need > to be added: > FEC - forward error correction > P2MP - point to multipoint > [LK] Done > > 3) In section 1.3, "management I/F" should be written out > as "management interface". In the next sentence, I believe > that instead of text "The MIB document", it should read > "The IEEE MIB document", since IETF MIB documents don't > have "packages". > [LK] Done > > 4) The most important goal for section 1 is to describe the > interface model. This version is so much better than > the previous version. However, I'm still somewhat > confused. The figure in section 1.2.1 and in 1.2.5 > show typical devices having OLT and ONU interfaces. > I'd like to see two more figures and interface table > dumps. These are: > An "ONU modem": > -------- > ONU interface | ONU | 10megabit interface > --------------| Modem |-------------------- > --------- > Does this device have two or three entries in the IF table? > And does it have an entry in the IF stack table. I believe > that there are 3 IF entries, and one IF stack entries. > For example in IF table: > ifIndex=1 - interface for 10megabit interface > ifIndex=2 - interface for the optical interface > ifIndex=200 - interface for the ONU interface > And then in IF stack table: > ifStackHigherLayer=200, ifStackLowerLayer=2 - map between > the physical and the ONU > > An "headend" with 1 gigibit ethernet interface, and > two "OLT" interfaces: > -------- > 1st OLT interface | Head | gigE interface > ------------------| end |-------------------- > | | > ------------------| | > 2nd OLT interface | | > --------- > With no currently connected ONUs, I believe that there > would be the following IF table and IF Stack table entries: > For example in IF table: > ifIndex=1 - interface for gigE interface > ifIndex=2 - interface for 1st optical interface > ifIndex=3 - interface for 2nd optical interface > ifIndex=200 - interface for the 1st OLT broadcast interface > ifIndex=300 - interface for the 2nd OLT broadcast interface > And then in IF stack table: > ifStackHigherLayer=200, ifStackLowerLayer=2 - map between > the 1st physical and its broadcast OLT > ifStackHigherLayer=300, ifStackLowerLayer=3 - map between > the 2nd physical and its broadcast OLT > If two ONUs connected to the first OLT, then the following > would be added: > For example in the IF table: > ifIndex=201 - interface for the 1st ONU of 1st OLT > ifIndex=202 - interface for the 2nd ONU of 1st OLT > And in the IF stack table: > ifStackHigherLayer=201, ifStackLowerLayer=2 - map between > the 1st physical and 1st ONU > ifStackHigherLayer=202, ifStackLowerLayer=2 - map between > the 1st physical and 2nd ONU > > It seems that for "ONU modems" that there is not a > an interface instance for the physical interface, > where there is one for "headend" devices? > > I suggest that you do the following: > a) in section 1.3, take the paragraph that starts with > "At the OLT", and end it after the second sentence. > b) Add the following paragraphs and figures: > ------ > To illustrate the interface modeling, consider > two devices. The first device has two > physical interfaces, is typically located at > a consumer's site, and may be called a "ONU modem". > This is shown in figure X below: > -------- > ONU interface | ONU | 10megabit interface > --------------| modem |-------------------- > --------- > Figure X: ONU modem > > This device would have 3 entries in the IF table, > for example: > ifIndex=1 - interface for 10megabit interface > ifIndex=2 - interface for the optical interface > ifIndex=200 - interface for the ONU interface > > The second device has three physical interfaces, > is typically located at the provider's site, and > may be called a "headend". This is shown in > figure Y below: > > --------- > 1st OLT interface | Head | gigE interface > ------------------| end |-------------------- > | | > ------------------| | > 2nd OLT interface | | > --------- > Figure Y: headend > > This device would have 5 entries (when no attached ONUs) > in the IF table, for example: > ifIndex=1 - interface for gigE interface > ifIndex=2 - interface for 1st optical interface > ifIndex=3 - interface for 2nd optical interface > ifIndex=200 - interface for the 1st OLT broadcast interface > ifIndex=300 - interface for the 2nd OLT broadcast interface > > If two ONUs connected to the first OLT interface, then > for example, the following entries would be added to > the IF table: > ifIndex=201 - interface for the 1st ONU of 1st OLT > ifIndex=202 - interface for the 2nd ONU of 1st OLT > > ------ > > c) Continue with a slight change of the sentence that starts > with "Therefore the Interface". Rewrite it to be something > like: > ------ > For each physical interface, there would be an entry in > the tables of the MAU MIB module[RFC3636] and Etherlike > MIB module[RFC3635]. And additionally, there would be > entries for the virtual links of the ONU and OLT interfaces. > ------ > d) Update the figures and tables through the remainder of the > document to match the ifIndex assignments. > [LK] I accept the observations and the examples. I > incorporated the text in the document. > > 5) The end of section 1.3, which starts with sentence "As an > example provided below are the values for the MPCP" should > be moved to section 2 - where the MIB structure is discussed. > [LK] OK. > > 6) The figures labeled "Table 1" through "Table 4" are useful, > but due to their size are problematic. I suggest that > only index columns, columns that linkage to other tables, > and columns what are different between ONU and OLT entries > be included. > [LK] I tried to do that, but it looked to me unclear. I think > that as the tables are set as examples for the values it is > more illustrative to put all data in them. My mind filters > the structure and the relevant data. Unless you insist on > that I would really rather keep it this way. > > > 7) The first sentence after "Table 2" sort of looks like it should > be a section head. > [LK] It is just a new paragraph, discussing the creation and > deletion of entries in the table. Rephrased it to be more clear. > > 8) The value for dot3MpcpRemoteMACAddress in "table 3" should > be 6 octets of zero (and not one). For example: > 00:00:00:00:00:00 > [LK] OK > > 9) There needs to be a footnote, or text that explains the > meaning of values OLT_MAC_Address, ONU{1,2,3}_MAC_Address, > and BRCT_MAC_Address > [LK] OK > > 10) The paragraph after "Table 4" seems to be misplaced, > and should come before "Table 2". > [LK] Correct. > > 11) Section 2 ("MIB structure") is weak. Moving the text from > section 1.3 should help. > [LK] I guess you mean the example from comment 5? > > 12) How the "extended package" tables were related was not > well explained in section 2 (nor in their definition). > It took me a while to figure out that object > dot3ExtPkgObjectReportMaximumNumQueues affected > the number of entries in tables dot3ExtPkgQueueTable > and dot3ExtPkgQueueSetsTable. And that object > dot3ExtPkgObjectReportMaximumNumThreshold affected > the number of entries in table dot3ExtPkgQueueSetsTable. > In general, I couldn't completely figure out > the use of the tables in the "extended package" > nor the expected values. > [LK] I have added the following clarification text into the > description of the tables: > The queue table: > dot3ExtPkgQueueTable OBJECT-TYPE > SYNTAX SEQUENCE OF Dot3ExtPkgQueueEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of the extended package objects for queue > management. The [802.3ah] MPCP defines a report of the > occupancy of the transmit queues for the feedback BW > request from the ONUs. These queues serve the uplink > transmission of the ONU and data is gathered there until > the ONU is granted for transmission. > The management table of the queues is added here mainly > to gather some statistics of their operation. This table > is not duplicating existing management objects of > bridging queues, specified in [802.1d], since the ONU > may not be a bridge device, with embedded bridging > queues and the existence of the transmit queuing > mechanism is implied in the [802.3ah] spec. > The format of the REPORT message, as specified > in [802.3], is presented below: > +-----------------------------------+ > | Destination Address | > +-----------------------------------+ > | Source Address | > +-----------------------------------+ > | Length/Type | > +-----------------------------------+ > | OpCode | > +-----------------------------------+ > | TimeStamp | > +-----------------------------------+ > | Number of queue Sets | > +-----------------------------------+ /|\ > | Report bitmap | | > +-----------------------------------+ | > | Queue 0 report | | > +-----------------------------------+ | repeated for > | Queue 1 report | | every > +-----------------------------------+ | queue_set > | Queue 2 report | | > +-----------------------------------+ | > | Queue 3 report | | > +-----------------------------------+ | > | Queue 4 report | | > +-----------------------------------+ | > | Queue 5 report | | > +-----------------------------------+ | > | Queue 6 report | | > +-----------------------------------+ | > | Queue 7 report | | > +-----------------------------------+ \|/ > | Pad/reserved | > +-----------------------------------+ > | FCS | > +-----------------------------------+ > > The 'Queue report' field reports the occupancy of each > uplink transmission queue. > The number of queue sets defines the number of the > reported sets, as would be explained in the description > of the dot3ExtPkgQueueSetsTable table. For each set the > report bitmap defines which queue is present in the > report, meaning that although the MPCP REPORT message > can report of up to 8 queues in a REPORT message, the > actual number is flexible. The Queue table has a > variable size which is limited by the > dot3ExtPkgObjectReportMaximumNumQueues object as an > ONU can have fewer queues to report. > The entries in the table are control and status > indication objects for managing the queues of an EPON > interface which are gathered in an extended package as > an addition to the objects which are based on the > [802.3ah] attributes. > Each object has a row for every virtual link and for > every queue in the report. > Typically the number of expected virtual links in a PON > is like the number of ONUs, which is 32-64, plus an > additional entry for broadcast LLID (with a value of > 0xffff). > In the [802.3ah] the LLID is a 2bytes register and the > number of LLIDs is limited by that. > The number of queues is between 0 and 7 and limited by > dot3ExtPkgObjectReportMaximumNumQueues." > > And the queue_set table: > dot3ExtPkgQueueSetsTable OBJECT-TYPE > SYNTAX SEQUENCE OF Dot3ExtPkgQueueSetsEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of Extended package objects used for the > management of the queue_sets. Entries are control and > status indication objects of an EPON interface which > are gathered in an extended package as an addition to > the objects based on the [802.3ah] attributes. The > objects in this table are specific for the queue_sets > which are reported in the MPCP REPORT message as defined > in [802.3ah] clause 64. > The [802.3ah] MPCP defines a report of the occupancy of > the transmit queues for the feedback BW request from the > ONUs. These queues serve the uplink transmission of the > ONU and data is gathered there until the ONU is granted > for transmission. > The management table of the queues is added here mainly > to gather some statistics of their operation. This table > is not duplicating existing management object of > bridging queues, specified in [802.1d], since the ONU > may not be a bridge device, with embedded bridging > queues and the existence of the transmit queuing > mechanism is implied in the [802.3ah] spec. > The format of the REPORT message, as specified > in [802.3], is presented below: > +-----------------------------------+ > | Destination Address | > +-----------------------------------+ > | Source Address | > +-----------------------------------+ > | Length/Type | > +-----------------------------------+ > | OpCode | > +-----------------------------------+ > | TimeStamp | > +-----------------------------------+ > | Number of queue Sets | > +-----------------------------------+ /|\ > | Report bitmap | | > +-----------------------------------+ | > | Queue 0 report | | > +-----------------------------------+ | repeated for > | Queue 1 report | | every > +-----------------------------------+ | queue_set > | Queue 2 report | | > +-----------------------------------+ | > | Queue 3 report | | > +-----------------------------------+ | > | Queue 4 report | | > +-----------------------------------+ | > | Queue 5 report | | > +-----------------------------------+ | > | Queue 6 report | | > +-----------------------------------+ | > | Queue 7 report | | > +-----------------------------------+ \|/ > | Pad/reserved | > +-----------------------------------+ > | FCS | > +-----------------------------------+ > > As can be seen from the message format, the ONU device > reports of the status of up to 8 queues and it can > report in a single MPCP REPORT message of a few sets > of queues. > The number of queue_sets defines the number of the > reported sets, and it can reach up to a value of 8. It > means that a device can hold a variable number of sets > between 0 to 7. > The dot3ExtPkgQueueSetsTable table has a variable > queue_set size which is limited by the > dot3ExtPkgObjectReportMaximumNumThreshold object as an > ONU can have fewer queue_sets to report. > The 'Queue report' field reports the occupancy of each > uplink transmission queue. The queue_sets can be used to > report the occupancy of the queues in a few levels as to > allow granting, in an accurate manner, of only part of > the data available in the queues. A Threshold is > defined for each queue_set to define the level of the > queue which is counted for the report of the occupancy. > The threshold is reflected in the queue_set table by the > dot3ExtPkgObjectReportThreshold object. > For each queue set, the report bitmap defines which > queues are present in the report, meaning that > although the MPCP REPORT message can report of up to 8 > queues in a REPORT message, the actual number is > flexible. > The dot3ExtPkgQueueSetsTable table has a variable queue > size which is limited by the > dot3ExtPkgObjectReportMaximumNumQueues object as an ONU > can have fewer queues to report. > Each object has a row for every virtual link, for each > queue in the report and for each queue_set in the queue. > Typically the number of expected virtual links in a PON > is like the number of ONUs, which is 32-64, plus an > additional entry for broadcast LLID (with a value of > 0xffff). > In the [802.3ah] the LLID is a 2bytes register and the > number of LLIDs is limited by that. > The number of queues is between 0 and 7 and limited by > dot3ExtPkgObjectReportMaximumNumQueues. > The number of queues_sets is between 0 and 7 and limited > by dot3ExtPkgObjectReportMaximumNumThreshold." > > 13) In section 2, the same terminology should be used. There > is used "MIB objects", "MIB module", and "managed object". > [LK} Done. Used "MIB objects". > > 14) Section 3.1 is quite useful (and required by all interface > MIB module documents). (Note "Ether-like" is misspelled > as "Ehter-like" in one place that I saw.) > Missing is a discussion and example of the IF stack table > (and the inverted stack table). Also missing is a discussion > of what happens to counters when operation is stopped. > [LK] Added the following text to the section: > For the ifStack and ifInvStack added the examples: > For the ONU example: > The ifStack and ifInvStack tables related to this example > for the ONU > will be: > > ifStackTable: > > ifStackHigherLayer=100, ifStackLowerLayer=1 - map between the > physical interface and the ONU > > ifInvStackTable: > > ifStackLowerLayer=1, ifStackHigherLayer=100,- map between > the ONU and > the physical interface > > For the OLT example: > The ifStack and ifInvStack tables related to this example > for the OLT > will be: > > ifStackTable: > > ifStackHigherLayer=265535, ifStackLowerLayer=2 - map > between the OLT > physical interface and its broadcast virtual interface > > ifStackHigherLayer=200001, ifStackLowerLayer=2 - map > between the OLT > physical interface and its virtual interface of the 1st ONU > > ifStackHigherLayer=200002, ifStackLowerLayer=2 - map > between the OLT > physical interface and its virtual interface of the 2nd ONU > > ifStackHigherLayer=200003, ifStackLowerLayer=2 - map > between the OLT > physical interface and its virtual interface of the 3rd ONU > > ifInvStackTable: > > ifStackLowerLayer=2, ifStackHigherLayer=265535, - map between the > broadcast interface of the OLT and the OLT physical interface > > ifStackLowerLayer=2, ifStackHigherLayer=200001 - map > between the OLT > virtual interface of the 1st ONU and the OLT physical interface > > ifStackLowerLayer=2, ifStackHigherLayer=200002 - map > between the OLT > virtual interface of the 2nd ONU and the OLT physical interface > > ifStackLowerLayer=2, ifStackHigherLayer=200003 - map > between the OLT > virtual interface of the 3rd ONU and the OLT physical interface > > For the counters when operation stops: > The interface MIB document describes the possible behavior of > counter when an interface is re-initialized in quite a clear > manner using the ifCounterDiscontinuityTime indicator. Please > see [RFC2863] section 3.1.5 p.11. The counters of the EPON > MIBs should be handled in a similar manner. I will add the > clarification text and the relevant reference to the section > and add in the counters description a reference for using > ifCounterDiscontinuityTime . > > > 15) Section 3.2 mentions the "amended MAU MIB document", but > the references specifies the current MAU MIB > document. I suggest that you specify the new MAU I-D > in the references (if available). > [LK] Done. The reference is to the new version > http://www.ietf.org/internet-drafts/draft-ietf-hubmib-rfc3636b is-03.txt. 16) The abbreviations in the MODULE-IDENTITY specification need to be checked and updated for completeness. [LK} Done 17) The MPCP stats table has stats for both OLTs and ONUs, and counters that only have meaning on one of the OLT or ONU. In the later case, the text says the value is always zero. For example, object dot3MpcpDiscoveryWindowsSent always has a value of zero on ONUs, and object dot3MpcpTxRegRequest always has a value of zero on OLTs. This is a valid approach, but somewhat confusing. Another approach would be to split the table (and other similar table) into three tables for both, OLT, and ONU stats. Or to split into two tables with some columns duplicated (but of course with different descriptors). I'd like to hear opinions from others on this. [LK] I think that duplicating tables for ONU and OLT tables will make the MIB document unreadable. Since there are so many common attributes my selection was to have them in a single table and specify when a zero value is received. I think the IEEE 802.3ah used the same method and I tried to be consistent with that. 18) In general, there is an inconsistent description specified per object as to whether or not the value is always zero (a place holder). This should be cleaned up, since it is confusing that different words are used. The read questions whether or not the same thing is being said, but just using different words. [LK] Done in some cases. Please note that there are nuances there, meaning that the behavior is not the same in all cases. 19) At first, I didn't understand why table dot3OmpEmulationTable is present. It's single object dot3OmpEmulationType appears to me to be the same as object dot3MpcpMode. However, looking at the MODULE-COMPLIANCE definitions, I see the need since for interpreting values in table dot3OmpEmulationStatTable you need to know if the interface is an OLT or ONU. This is not well explained in section 2. Also, maybe table dot3MpcpStatTable should AUGMENT table dot3MpcpControlTable; table dot3OmpEmulationStatTable should AUGMENT table dot3OmpEmulationTable. Table dot3EponFecTable doesn't need another table to indicate if the interface is a OLT or ONU, since the stats apply to both. [LK] Added explanation to section 2 regarding the OLT/ONU type selection for each table. As for the statistics table augmenting the control table, my opinion was that the topics were distinct enough to create a separation. I tried to order the objects in a readable manner. 20) There appear to be some character set problems in the description for object dot3EponFecPCSCodingViolation. [LK] Done 21) You should probably say that the value 'unknown(1)' cannot be written to object dot3EponFecMode. [LK] My assumption was that the value can be assigned in initializing, for non FEC support state or type not yet known by management until the al initialization information is known. 22) You should probably rewrite the description of object dot3EponFecBufferHeadCodingViolation so it is clear that the value is meaningful only when in 1000 Mbps operation, and zero otherwise. [LK] Agree. 23) Object dot3ExtPkgObjectReset is an action object to reset "EPON" interfaces. What does a reset do to counters? Is there an object that counts the number of resets or provides a timestamp of last reset operation? Does a reset of one of the virtual interfaces reset only it, or the physical interface? [LK] The reset can cause Discontinuities in the value of the counters as in re-initialization of the management system as indicated by ifCounterDiscontinuityTime. Mainly the object is for a reset operation so a count of the events and a timestamp was not added. I looked into the MAU MIB (RFC3636) and saw a similar definition there. Do you think it should be added? A reset for a virtual interface resets only the virtual interface and not all the rest. It has sense so that a virtual link which is mal-functioning can be reset without affecting the operation of other virtual interfaces. Added clarification to the text of the document describing the operation. 24) Object dot3ExtPkgObjectPowerDown causes an interface to be powered down or up. How does this work for the virtual interfaces? [LK] A power down/up of a virtual interface affects only the virtual interface and not all the rest. It has sense so that a virtual link which needs a certain handling can be powered down and then powered up without disrupting the operation of other virtual interfaces. A clarification text is added to the description of the object. 25) Object dot3ExtPkgObjectNumberOfLLIDs seems silly (useless). Please explain. [LK]dot3ExtPkgObjectNumberOfLLIDs provides the number of registered LLIDs. The LLID value itself can be non monotonic and some entries in the table can be registered and some not. 26) What happens to counters and instances in the FEC table when the value of object dot3ExtPkgObjectFecEnabled is changed? [LK] I agree. Need to add such a description. Although the counter itself should not changed by management but when the interface is not supporting FEC the counting will stop. Generally the FEC counters are referring to the receive path. The counters: dot3EponFecPCSCodingViolation - not affected by FEC mode. dot3EponFecCorrectedBlocks - stops counting when Rx_FEC is not enabled dot3EponFecUncorrectableBlocks - stops counting when Rx_FEC is not enabled dot3EponFecBufferHeadCodingViolation - stops counting when Rx_FEC is not enabled The objects: dot3EponFecAbility indicates the FEC ability and is not affected by the FEC mode, dot3EponFecMode indicates the FEC mode for combined RX and TX. Added text to the description of the object. 27) Object dot3ExtPkgObjectReportMaximumNumQueues is not well described. Also, it SYNTAX value should probably be Unsigned32(0..7). What happens if it is changed, to counters in the tables dot3ExtPkgQueueTable and dot3ExtPkgQueueSetsTable. [LK] Hope that the new explanation on the queues provides the proper description. Agreed on the SYNTAX. 28) I don't understand the function of object dot3ExtPkgObjectRegisterAction. Does it cause instances to be created or deleted? [LK] The object changes the LLID state as specified in the IEEE802.3ah clause 64. The action that can be done on an LLID as described in the [802.3] are none (1) - Not doing any action register (2) - registering an LLID which request to register (in registering mode (dot3MpcpRegistrationState registering (2)). deregister (3) - deregisters an LLID which is registered (dot3MpcpRegistrationState registered (3) ). reregister (4) - reregister an LLID which is registered (dot3MpcpRegistrationState registered (3) ). The behavior of an ONU at each one of the states is described in the [802.3ah] clause 64 registration state machine Figure 64-22. As for the MIB document the status of the LLID is reflected in this object and in dot3MpcpRegistrationState modes. A clarification text is added to the description of this object. 29) The index dot3QueueIndex is not well explained in table/row for the Queue table. [LK] dot3QueueIndex is the index of the queue table denoting the rows of the table which reflect the queues as reported in the MPCP REPORT message. Clarified the text to the following: DESCRIPTION "An object that identifies an index for the queue table reflecting the queue index of the queues which are reported in the MPCP REPORT message, as defined in [802.3ah] clause 64. The number of queues is between 0 and 7 and limited by dot3ExtPkgObjectReportMaximumNumQueues." 30) I couldn't figure out objects dot3ExtPkgObjectReportNumThreshold and dot3ExtPkgObjectReportMaximumNumThreshold other than one of them controlled the number of queue sets. [LK] The dot3ExtPkgObjectReportNumThreshold defines the number of threshold for each queue in the report message. This defines the number of queue sets for this queue. The dot3ExtPkgObjectReportMaximumNumThreshold defines the maximal number of thresholds for each queue in the report message. This defines the maximal number of queue_sets for this queue, which is indeed a limit to the dot3QueueSetIndex index. I hope that the explanation of the queue_set table clear the use of the object. 31) I believe that the syntax of object dot3ExtPkgObjectReportMaximumNumThreshold should be Unsigned32(0..7). [LK] Agreed 32) It doesn't seem to make sense that there would be entries in table dot3ExtPkgOptIfTable for virtual interfaces. [LK] As written in the section 1.3, in the reasoning for the selection of a separate ifIndex for the virtual ports, the reason for having a separate row for each virtual link is that the OLT has a separate link for each one of the ONUs. For instance, they could be in different distances with different link budgets and different receive powers, therefore having different power alarms. It is quite similar to a case of different physical interfaces. I will add the explanation to the table description. --- that's all Regards, /david t. perkins