Subject: [Hubmib] RE: Review of EPON-04

From: "Lior Khermosh" <[email-masked]>
Date: Mon, 24 Jul 2006 00:02:40 +0300

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-masked]] 
Sent: Saturday, May 27, 2006 1:51 AM
To: [email-masked]
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-rfc3636bis-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

 

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

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 25 Jul 2006 11:58:47 +0300

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

> From: Lior Khermosh [mailto:[email-masked]] 
> Sent: Monday, July 24, 2006 12:03 AM
> To: David T. Perkins; [email-masked]
> 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
>  
> 
> [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.
> 
>      b) dependencies of stacked interfaces [LK] Please see 
> specific comment below. I hope it resolves the concerns.
> [LK] I accept the observations and the examples. I 
> incorporated the text in the document.
> 
> [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.
> 
> 
> [LK]  It is just a new paragraph, discussing the creation and 
> deletion of entries in the table. Rephrased it to be more clear.
>    
> [LK] I have added the following clarification text into the 
> description of the tables:
> The queue table:
> 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 

    

    

--- that's all

Regards,
/david t. perkins