[resend] RE: Response to EPON-MIB-04

David,
Thanks for the comments. Please see some answers embedded in line.

Attached is also an updated draft. I am also submitting it.

Please note that I have decided to go back in the indexing method and to
use the ifIndex of the virtual links as the rows index instead of using
the link index which was defined at last response. Please see the
attached mails for that.


Thanks,
Lior
 

-----Original Message-----
From: David T. Perkins [mailto:[email protected]] 
Sent: Friday, January 20, 2006 9:01 AM
To: Lior Khermosh
Cc: [email protected]; Hub MIB
Subject: Response to EPON-MIB-04

HI,

Comments on draft-ietf-hubmib-efm-epon-mib-04.txt - dtp:19-jan-2006

The document is much improved. However, it is not yet ready for
submission to the IESG. The changes introduced many grammar and some
spelling errors (and a couple of formatting problems), which can be
easily fixed. Unfortunately, there are a couple of fundamental issues
that remain. These are:
 1) if an "SNMP MIB walk" was done on the
     a) IF table
     b) bridge table
     c) MAU table
     d) stack table (and inverted stack table)
     e) etherLike interfaces table
     d) and tables defined in the MIB module
   what would be the answers to the following questions for
   OLTs and for ONUs (for both, assume that each has a 1Gig Eth
   interface and an optical interface, and for the OLT, there
   are 3 ONUs connected to the optical interface):
     a) how many entries would be in the IF table
>> At each ONU 1. At the OLT 3+1. Each one has a different ifIndex. The
MAC is virtually duplicated. So the number of entries is the number of
virtual entries + an additional entry for the broadcast.
Only the MAC address at the OLT is not duplicated as the physical I/F is
the same. It is specified in the IEEE802.3ah 64.1.2.

     b) what would the values be for each column in the
         IF table. That is, what are the values of the
         following objects: ifIndex, ifDescr, ifType,
          ifMtu, ifSpeed, ifPhysAddress, ifAdminStatus,
          ifOperStatus, ifLastChange, ifInOctets, ifInUcastPkts,
          ifInNUcastPkts, ifInDiscards, ifInErrors, 
          ifInUnknownProtos, ifOutOctets, ifOutUcastPkts,
          ifOutNUcastPkts, ifOutDiscards, ifOutErrors,
          ifOutQLen
>> 
At the ONU in working mode:
ifIndex   1
ifDescr   "I/F description"
ifType    gigabitEthernet (117) 1000base-Px
ifMtu     MTU size (1522)
ifSpeed   1000000000
ifPhysAddress   ONU_MAC_Address
ifAdminStatus   up
ifOperStatus    Up
ifLastChange    up_time 
ifInOctets      ONU1_octets_number
ifInUcastPkts   ONU1_unicast_frame_number
ifInNUcastPkts  ONU1_non_unicast_frame_number
ifInDiscards    ONU1_discard_frame_number
ifInErrors      ONU1_error_frame_number
ifInUnknownProtos ONU1_unknown_frame_number
ifOutOctets      ONU1_octets_number 
ifOutUcastPkts   ONU1_unicast_frame_number
ifOutNUcastPkts  ONU1_non_unicast_frame_number
ifOutDiscards    ONU1_discard_frame_number
ifOutErrors      ONU1_error_frame_number
ifOutQLen        ONU1_queue_frame_number

at the OLT in working mode the interfaces associated with the virtual
links:
ifIndex		1				2
3                      	65535

ifDescr		"I/F description"		"I/F description"
"I/F description"      	"I/F description"      
ifType		gigabitEthernet (117)	gigabitEthernet (117)
gigabitEthernet (117)  	gigabitEthernet (117)       
ifMtu			MTU size (1522)		MTU size (1522)
MTU size (1522)        	MTU size (1522)       
ifSpeed		1000000000			1000000000
1000000000             	1000000000       
ifPhysAddress	OLT_MAC_Address		OLT_MAC_Address
OLT_MAC_Address        	OLT_MAC_Address       
ifAdminStatus	up				up
up                     	up       
ifOperStatus	Up				Up
Up                     	Up       
ifLastChange	ONU1_up_time 		ONU2_up_time
ONU3_up_time           	up_time            
ifInOctets		ONU1_octets_number	ONU2_octets_number
ONU3_octets_number     	BRCT_octets_number       
ifInUcastPkts	ONU1_unic_frame_num	ONU2_unic_frame_num
ONU3_unic_frame_num 	BRCT_unic_frame_num    
ifInNUcastPkts	ONU1_non_unic_frame_num	ONU2_non_unic_frame_num
ONU3_non_unic_frame_num	BRCT_non_unic_frame_num
ifInDiscards	ONU1_disc_frame_num	ONU2_disc_frame_num
ONU3_disc_frame_num 	BRCT_disc_frame_numr    
ifInErrors		ONU1_err_frame_num	ONU2_err_frame_num
ONU3_err_frame_num  	BRCT_err_frame_num      
ifInUnknownProtos ONU1_unknw_frame_num	ONU2_unknw_frame_num
ONU3_unknw_frame_num 	BRCT_unknw_frame_num   
ifOutOctets		ONU1_octets_number 	ONU2_octets_number
ONU3_octets_number      BRCT_octets_number          
ifOutUcastPkts	ONU1_unic_frame_num	ONU2_unic_frame_num
ONU3_unic_frame_num 	BRCT_unic_frame_num    
ifOutNUcastPkts	ONU1_non_unic_frame_num	ONU2_non_unic_frame_num
ONU3_non_unic_frame_num BRCT_non_unic_frame_num 
ifOutDiscards	ONU1_disc_frame_num	ONU2_disc_frame_num
ONU3_disc_frame_num  	BRCT_disc_frame_num    
ifOutErrors		ONU1_err_frame_num	ONU2_err_frame_num
ONU3_err_frame_num    	BRCT_err_frame_num      
ifOutQLen		ONU1_queue_frame_num	ONU2_queue_frame_num
ONU3_queue_frame_num   	BRCt_queue_frame_num       

And the OLT interface:
ifIndex		100000				
ifDescr		"I/F description"		
ifType		gigabitEthernet (117)	
ifMtu			MTU size (1522)		
ifSpeed		1000000000			
ifPhysAddress	OLT_MAC_Address		
ifAdminStatus	up				
ifOperStatus	Up				
ifLastChange	OLT_up_time 		
ifInOctets		OLT_octets_number	
ifInUcastPkts	OLT_unic_frame_num	
ifInNUcastPkts	OLT_non_unic_frame_num	
ifInDiscards	OLT_disc_frame_num	
ifInErrors		OLT_err_frame_num	
ifInUnknownProtos OLT_unknw_frame_num	
ifOutOctets		OLT_octets_number 	
ifOutUcastPkts	OLT_unic_frame_num	
ifOutNUcastPkts	OLT_non_unic_frame_num	
ifOutDiscards	OLT_disc_frame_num	
ifOutErrors		OLT_err_frame_num	
ifOutQLen		OLT_queue_frame_num
                                            

     c) how the values of the above objects determined?
>> Object are determined for each virtual MAC

     d) what happens when the value of ifAdmin is set to
         'up(1)', 'down(2)', and 'testing(3)'?
>> When the ifAdmin is:
up(1) The virtual I/F is up and ready for operation.
down(2) The virtual I/F is down and not ready for operation.
testing(3) The virtual I/F is in testing mode.

     e) the table dot1dBasePortTable has the mapping of
        bridge ports to interfaces (and "circuit" on that
        interface). What would the values be for the
        objects dot1dBasePortIfIndex and dot1dBasePortCircuit
        when the OLT supported bridging? (By the way,
        document "Definitions of Managed Objects for Bridges"
        was recently updated and, thus, the refs should
        have RFC 4188 and not 1493.)
>>If the OLT supports bridging then The virtual physical I/Fs are the
bridge virtual ports. 
The values for dot1dBasePortIfIndex would be the number of the ifIndex
for the virtual port (1 for LLID1, 2 for LLID2,...)
I don't think that the dot1dBasePortCircuit is needed at this case as
there is an ifIndex so it will receive the 0 value.
>> Updated the reference number. Thanks.

     f) how many entries would be in table ifMauTable,
        and would be the value of columns in the table.
>>For the ONU there is a single row for the ifMauTable. At the OLT there
is a row for each virtual link (3+1 in the example above), ifMauIfIndex
has a value for each virtual link.

     g) Are the stack and inverted stack tables used?
        If so, show the stacking relationships.
>> At  the ONU I don't think there is a need to use the stack and
inverted stack tables. At the OLT, the OLT interface and the virtual
links associated with it are stacked as the OLT interface is the higher
layer of all other interfaces related to the virtual links. The stack
and inverted stack table are used for this purpose.


     h) How many entries are in the etherLike tables
        dot3StatsTable, dot3CollTable, dot3PauseTable,
        and dot3HCStatsTable and what would the values
        be of columns in the tables.
>> Similar to the above model for the ONU there is a single row for each
table. At the OLT there is a row for each virtual link (3+1 in the
example above), ifIndex identifies the virtual links. For instance the
statistics are calculated for each one of the virtual links.

     i) How many entries would be in the tables defined
        in this document, which are:
        dot3MpcpGlobalTable, dot3MpcpParamTable,
        dot3MpcpStatTable, dot3OmpEmulationTable,
        dot3OmpEmulationStatTable, dot3EponFecTable,
        dot3ExtPkgGlobalControlTable,
        dot3ExtPkgControlTable, dot3ExtPkgQueueTable,
        dot3ExtPkgQueueSetsTable and
        dot3ExtPkgOptIfTable.
>> At the ONU
dot3MpcpControlTable		1
dot3MpcpStatTable			1
dot3OmpEmulationTable		1
dot3OmpEmulationStatTable	1
dot3EponFecTable			1
dot3ExtPkgControlTable		1
dot3ExtPkgQueueTable		1 X (1 to 8)
dot3ExtPkgQueueSetsTable	1 X (1 to 8) X (1 to 8)
dot3ExtPkgOptIfTable		1

>> At the OLT
dot3MpcpControlTable		1
dot3MpcpStatTable			4 
dot3OmpEmulationTable		4 
dot3OmpEmulationStatTable	4 
dot3EponFecTable			4 
dot3ExtPkgControlTable		4 
dot3ExtPkgQueueTable		4  X (1 to 8)
dot3ExtPkgQueueSetsTable	4  X (1 to 8) X (1 to 8)
dot3ExtPkgOptIfTable		1 

In the general case 4 is N+1.



 2) Which tables in the MIB module allow rows to be created
    and or deleted, and if so, then how? (Note the the phrase
>> All tables allow creation and deletion of rows. At the ONU and at the
OLT, for the OLT interface and the broadcast virtual interface the
creation of the rows is done during initialization. For the virtual
interfaces at the OLT, rows are created when the virtual link is created
(ONU registers) and deleted when the virtual link is deleted (ONU
deregisters).

    "Rows at the table are created by direct SNMP management
    setting." is used in the DESCRIPTION for many tables.
    However, there was no information provided as to what
    this means. (I'm guessing that my original comments
    were not completely understood. What I was asking for
    was to include in the DESCRIPTION clause whether or
    not an SNMP SET could be done to columns in a table
    to create or delete a row, and if so, to provide the
    details 
>> Please see the response above.

(or indicate the object definition where the
    details were provided). For example, the TCP connection
    table does not support SNMP SETs to create rows in
    the table. Rows are created as TCP connections
    are created by processes running on the system.
>>OK
    However, an SNMP SET can be done on object tcpConnState 
    with value 'deleteTCB(12)' to terminate a TCP
    connection (which results in the row being deleted
    from the table). There are plenty of examples of
    using a "RowStatus" object to create and delete
    rows in tables (see the SNMPv3 RFCs, such as RFC 3413).
    In the RMON MIB modules, there are examples of
    control tables and data tables. A row creation
    (or deletion) in a control table results in
    row creation (or row deletion) in data tables.
>> Actually the TCP connection model is a very good reference for this
MIB. Rows are automatically created and deleted by system tasks. I think
that it is better to create/delete the rows when ONUs
register/deregister and not hold rows with a status indication as I
think that there is no meaning for a row if there is no ONU registered
to it. A totally different ONU can register in that LLID with the
different parameters when the row is active again.

    Describing how instances are created and deleted,
    (by system operation or configuration, and/or
    via management operations) is a key piece of
    information for the DESCRIPTION clauses of
    tables and rows.

Until the above fundamental issues are resolved, it doesn't make a lot
of sense to spend much time on other issues such as grouping and
conformance.

Note that I did spot a bunch of easy to fix items that I'm listing
below:
 section 1 - the text for the abstract is Ok. I just don't
     get the term "registers" here.
>> attributes. Changed
 section 1.1 - It's great to have a list of abbreviations.
     a) However in documents that contain MIB modules, typically
     the modules are extracted, and thus all the explanatory
     is not available. To help, there is a little redundancy
     that is added to the document of putting KEY definitions
     and terms in the DESCRIPTION clause for the MIB module.
>> I will put them in.
     b) I didn't check to see if all the abbreviations were
     actually used. If not, then I would remove them.
>>OK
     c) I thought CPE was customer premises equipment  section 1.2.3 - I
was confused. Does "Gate messages"
     start a new subsection?
>> Rephrased:
>>"The OLT send control messages (GATE messages) allowing ONUs to
transmit and defining when the transmission occurs and >> what is its
duration."

 section 3 (3.1-3.4) - This is still a little skimpy!
     Look at RFC 2863, sections 3.1.1-3.1.18 & 4. Also
     look at RFC 3635, section 3.2 and contained subsections.
>> Please look at the clarification added after the former comments.


 section 4 - tables 1 thru 3. The column head should be
     IEEE802.3ah attribute and not "object"
>>OK
 In the MIB module, there are several ASN.1 comments that
     that are used to group the definitions. They start
     out with phrase "Editor's note:". I believe the
     grouping is useful, but I'd drop the "Editor's note:"
     phrase. Note the first one is slightly out of order.
     It should be moved to immediately before the
     definition of OID dot3EponMpcpObjects.
>>OK

 Object dot3MpcpID - the DESCRIPTION needs to be translated
     from GDMO speak to something meaningful in SMIv2.
     (I commented on this before, and still don't see the
     usefulness of the object!)
>> OK. Replaced with ifIndex.

 Do the objects dot3MpcpOperStatus and dot3MpcpAdminStatus
     ever have different values. If not, then you should
     have one object.
>> Probably in most cases it will be in the same conditions. However for
the there might be some difference in up and down time where the
operational status is different due to the system transition. 
I think it is according to the guidance of RFC2863 3.1.13. That is
besides of the fact that the adminStatus is used for changing the state
by the writing operation.
   

 I really don't follow whether or not you can create LLIDs
     via SNMP. It doesn't seem possible to me, just like
     you can't create TCP connections. Thus, I don't understand
     the object dot3LinkIndex. (And note: a table that
     allows row creation uses "read-create" (and not "read-write")
     for all writable objects in the table.)  
>> The TCP connection model is quite a similar model indeed for this
case.
My intention was to at the OLT create an entry in these tables whenever
a virtual link is establish by ONU registration and delete it when the
link goes down when the ONU deregisters. At the ONU and for the
broadcast link creation is done at initialization. Please note that a
after an ONU deregisters a different ONU (physical entity) can register
within the same logical link. Therefore the entries in the tables are
not always existing with an active status indication (like the TCP
connection case), because they can have different values when they are
reactivated. Therefore whenever an link is created or deleted the
entries in the table are created or deleted. 
 
Entries in parallel tables - I asked you to describe the
     expected number of entries in tables. However, many of
     the tables in the MIB module are related, and the text
     was just copied. Instead, if there is a "base table"
     that determines the number of entries, and additional
     tables that have additional info, you should say
     something like "The rows in this table are match the
     rows in table X".
>> The description of the index in each table refer the ifIndex to the
virtual links established at the OLT case. 

 Transient condition in table dot3MpcpParamTable - it appears
     that this table tries to capture the transient values
     during the time a OLT and ONU are setting up a relationship
     and determining an LLID. Is this a long enough running
     activity that it can be seen, and what LLID value is
     used during negotiation (can't it change)?
>> No intention to capture such transient. The initial reason was to
allow setting of a LinkID which is available for the management for
reading.


 Object dot3OmpEmulationID - the DESCRIPTION needs to be translated
     from GDMO speak to something meaningful in SMIv2.
     (I commented on this before, and still don't see the
     usefulness of the object!)
>> OK. Replaced with ifIndex.

 Enum names in DESCRIPTION for object dot3ExtPkgObjectPowerDown -
     The enum names start with lower-case letters and not
     upper-case.
>>OK

 Queues - I really don't understand the queues. Could some
     intro text be added.
>> The 802.3ah MPCP uses for the feedback BW request from the ONUs a
report of some queues occupancy. These queues serve the ONU transmission
and data is gathered there until the ONU is granted from transmission.
Since the existence of such queuing mechanism is implied in the spec and
an ONU may not be a switch device, a management section is added here
for the queues, mainly to gather some statistics of their operation.
Text is added to the table description.
 
 Indexing - this is somewhat subjective. I don't believe that
     it is proper to define an object in one table (which is not
     an index in that table) and use it for an index in another
     table. This is done in the queue tables and object dot3LinkIndex.
>> OK. Fixed. Each table is using the ifIndex and if there is another
index it is specified in the table.


NOTE: this review was not complete. I didn't try to compile the MIB
module or run the document through the nit checker. Also, I didn't look
at the compliances.

-- that's it

Regards,
/david t. perkins  


 
 





************************************************************************
This footnote confirms that this email message has been scanned by Passave mail scanner
for the presence of malicious code, vandals & computer viruses.
************************************************************************

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