Subject: [Hubmib] RE: Response to EPON-MIB-04

From: "Lior Khermosh" <[email-masked]>
Date: Tue, 7 Feb 2006 21:39:12 +0200

David,
The IF,MAU and etherLike interfaces tables are all duplicated for the
virtual links at the OLT. 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.
So as for the example from your mail the parameters for the IF table:
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 

In the draft03 I had a single row in the table for each ifIndex. The
indexing for the virtual links was generated by using the ifIndex for
the virtual links. After the last comment session I have changed the
tables to include a row for each link index assuming that the P2MP
layers are single and not divided to virtual likes - This is presented
in the following layering diagram from the IEEE spec:

      +==========================================+
      |               Higher layers              |
      +==========================================+
      |               802.1D Bridge              |
      +==========================================+
      | MAC client|        ...        |MAC client|
      +==========================================+
      |           MAC Control - (MPCP)           |            *NEW*
      +==========================================+
      |    MAC    |        ...        |    MAC   |
      +==========================================+
      |           P2P Emulation (P2PE)           |            *NEW*
      +==========================================+
                      |            |
                      |    GMII    |
                      |            |
      +==========================================+
      |                    PCS                   |
      +==========================================+
      |                    FEC                   |            *NEW*
      +==========================================+
      |                    PMA                   |
      +==========================================+
      |                    PMD                   |
      +==========================================+
                      |            |
                      |    MDI     |
                      |            |
                    /===================/
                   /       Media       /
                  /===================/

The second thoughts I have is to return to the former indexing
(therefore splitting from management perspective the management layers
of the MPCP and P2PE and FEC to N virtual layers one for each virtual
link. The advantage is that the tables are more clean and
straightforward.
 
Best regards,
Lior

-----Original Message-----
From: David T. Perkins [mailto:[email-masked]] 
Sent: Tuesday, February 07, 2006 6:30 PM
To: Lior Khermosh
Cc: Romascanu, Dan (Dan); Hub MIB
Subject: RE: Response to EPON-MIB-04

HI,

Please describe a simple situation, and provide a list of the instances.
Then I can help you with the indexing in the MIB object definitions.

Also descsribe what events cause a new instance to be created or
deleted.

Regards,
/david t. perkins

On Tue, 7 Feb 2006, Lior Khermosh wrote:

>  
> Dan,
> Please see answers in line.
> 
> Also during this session I had some second thoughts on some of the 
> changes I have integrated in the last review. Specifically as to use a

> linkIndex inside the MIB tables instead of using the ifIndex of the 
> virtual links. Although it is not exactly as the IEEE layering for the

> EPON (the MPCP and P2PE layers are a single layer and not N virtual
> links) the specification of the MIB is more simpler and more neat. 
> There are no multiple rows for each virtual link and the duplication 
> is generated by the ifIndex for the virtual links (like it was in 
> draft 03). That way it is more similar to the tables which will be 
> held for the virtual MACs management. I am still considering it and I 
> will try to discuss it with David and then provide the draft ASAP.
> 
> 
> Best regards,
> Lior
> 
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: Monday, January 23, 2006 9:06 AM
> To: David T. Perkins; Lior Khermosh
> Cc: Hub MIB
> Subject: RE: Response to EPON-MIB-04
> 
> David,
> 
> Thank you for the review and the latest comments. 
> 
> Lior,
> 
> Can you please address David's questions? 
> 
> I believe that David is asking for clarifications, maybe an example 
> that would clarify his question 1. This new text could expand Section 
> 3 'Relationship of the EFM EPON MIB to other MIBs'. By the way, 
> 'Relation to other MIB Modules' would be a better name for this
section.
> >> Changed.
> 
> With respect to David's question #2, the text 'Rows at the table are 
> created by direct SNMP management setting." seems wrong. David's 
> question is correct, if rows in these tables are created dynamically 
> by management operations on the specific table, you need to use
"RowStatus"
> objects for the specific table. If this was not the intention, the 
> text should be eliminated and you should mention in the DESCRIPTION 
> clauses in each table how each row shows up, maybe as result of 
> operations performed on other tables, or corresponding to existing 
> ports on the device, or something else.
> >> I removed the creation by management. The rows are created when a
> virtual link is established (ONU registers) and deleted when a virtual

> link is deleted (ONU deregisters). I have added clarification in the 
> text.
> 
> I am also feeling very uncomfortable with holding discussions around a

> non-submitted draft.  I would like to ask Lior to submit draft 04 
> immediately. If the issues cannot be clarified and a revised draft 
> submitted in the next couple of days, it can be as it was distributed 
> on the mailing list last December.
> 
> Regards,
> 
> Dan
> 
> 
>  
>  
> 
> > -----Original Message-----
> > From: David T. Perkins [mailto:[email-masked]]
> > Sent: Friday, January 20, 2006 9:01 AM
> > To: [email-masked]
> > Cc: Romascanu, Dan (Dan); 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
> >      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
> >      c) how the values of the above objects determined?
> >      d) what happens when the value of ifAdmin is set to
> >          'up(1)', 'down(2)', and 'testing(3)'?
> >      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.)
> >      f) how many entries would be in table ifMauTable,
> >         and would be the value of columns in the table.
> >      g) Are the stack and inverted stack tables used?
> >         If so, show the stacking relationships.
> >      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.
> >      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.
> >  2) Which tables in the MIB module allow rows to be created
> >     and or deleted, and if so, then how? (Note the the phrase
> >     "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 (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.
> >     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.
> >     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.
> >  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.
> >      b) I didn't check to see if all the abbreviations were
> >      actually used. If not, then I would remove them.
> >      c) I thought CPE was customer premises equipment section 1.2.3 
> > - I was confused. Does "Gate messages"
> >      start a new subsection?
> >  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.
> >  section 4 - tables 1 thru 3. The column head should be
> >      IEEE802.3ah attribute and not "object"
> >  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.
> >  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!)
> >  Do the objects dot3MpcpOperStatus and dot3MpcpAdminStatus
> >      ever have different values. If not, then you should
> >      have one object.
> >  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.)  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".
> >  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 durring negotiation (can't it change)?
> >  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!)
> >  Enum names in DESCRIPTION for object dot3ExtPkgObjectPowerDown -
> >      The enum names start with lower-case letters and not
> >      upper-case.
> >  Queues - I really don't understand the queues. Could some
> >      intro text be added.
> >  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.
> > 
> > 
> > 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.
> **********************************************************************
> **
> **********************************************************************
> ** This footnote confirms that this email message has been scanned by 
> Passave mail scanner for the presence of malicious code, vandals & 
> computer viruses.
> **********************************************************************
> **
> 

************************************************************************
This footnote confirms that this email message has been scanned by
Passave mail scanner for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************************************************************************
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-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 8 Feb 2006 16:11:58 +0200

Lior,

I am not sure that you addressed part of David's query - 'Also describe
what events cause a new instance to be created or deleted' - or in other
words what events determine new rows to be created or rows to be deleted
in the tables? 

Thanks and Regards,

Dan

> From: Lior Khermosh [mailto:[email-masked]]

---

From: "Lior Khermosh" <[email-masked]>
Date: Wed, 8 Feb 2006 17:07:58 +0200

Dan,
I haven't responded yet to all the questions in David's mail. I will
send the full response after clearing the indexing issue.
Generally my intention is to make the creation and deletion of rows of
the link based table when ONU registers (a virtual link established) and
deregisters (a virtual link deleted) similar to TCP connections
creation/deletion case.  Rows in general tables are created in
initialization. I will remove any direct creation by management . I am
updating the tables descriptions accordingly.

Best regards,
Lior

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Wednesday, February 08, 2006 4:12 PM
To: Lior Khermosh; David T. Perkins
Cc: Hub MIB
Subject: RE: Response to EPON-MIB-04

Lior,

Thanks and Regards,

Dan

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 8 Feb 2006 17:08:36 +0200

I am referring to the question that David asked in the (short) mail
yesterday, not in the (long) review mail a while ago. 

Regards,

Dan

> Sent: Wednesday, February 08, 2006 5:08 PM
> To: Romascanu, Dan (Dan); David T. Perkins
> Cc: Hub MIB
> I haven't responded yet to all the questions in David's mail. 
> I will send the full response after clearing the indexing issue.
> Generally my intention is to make the creation and deletion 
> of rows of the link based table when ONU registers (a virtual 
> link established) and deregisters (a virtual link deleted) 
> similar to TCP connections creation/deletion case.  Rows in 
> general tables are created in initialization. I will remove 
> any direct creation by management . I am updating the tables 
> descriptions accordingly.
> 
> Best regards,
> Lior
> 
> 
> I am not sure that you addressed part of David's query - 
> 'Also describe what events cause a new instance to be created 
> or deleted' - or in other words what events determine new 
> rows to be created or rows to be deleted in the tables? 
> 
> Thanks and Regards,
> 
> Dan
> 
> 
>  
>  
> 
> This footnote confirms that this email message has been 
> scanned by Passave mail scanner for the presence of malicious 
> code, vandals & computer viruses.
> This footnote confirms that this email message has been 
> scanned by Passave mail scanner for the presence of malicious 
> code, vandals & computer viruses.

---

From: "Lior Khermosh" <[email-masked]>
Date: Wed, 8 Feb 2006 17:41:05 +0200

The response is actually quite similar. 
In initialization the rows in the general tables are created, and for
the IF, MAU and etherLike interfaces tables entries with the OLT and ONU
ifIndex are created.
1)
In initialization
The parameters for the IF table:

And from the EPON MIB: 
EPOM MPCP param table:
dot3MpcpLinkID 0 
dot3MpcpRemoteMACAddress 0 
dot3MpcpRegistrationState unregistered
dot3MpcpMaximumPendingGrants 4
dot3MpcpTransmitElapsed   0
dot3MpcpReceiveElapsed    0
dot3MpcpRoundTripTime     0

And at the OLT:
ifIndex		100000				

FOR THE VIRTUAL LINKS:
ifIndex		65535                                                
ifDescr		"I/F description"      
ifType		gigabitEthernet (117)       
ifMtu			MTU size (1522)       
ifSpeed		1000000000       
ifPhysAddress	OLT_MAC_Address       
ifAdminStatus	up       
ifOperStatus	Up       
ifLastChange	up_time            
ifInOctets		BRCT_octets_number       
ifInUcastPkts	BRCT_unic_frame_num    
ifInNUcastPkts	BRCT_non_unic_frame_num
ifInDiscards	BRCT_disc_frame_numr    
ifInErrors		BRCT_err_frame_num      
ifInUnknownProtos BRCT_unknw_frame_num   
ifOutOctets		BRCT_octets_number          
ifOutUcastPkts	BRCT_unic_frame_num    
ifOutNUcastPkts	BRCT_non_unic_frame_num 
ifOutDiscards	BRCT_disc_frame_num    
ifOutErrors		BRCT_err_frame_num      
ifOutQLen		BRCt_queue_frame_num       

And from the EPON MIB: 
No rows

2)
When ONU1 is registered:

The parameters for the IF table:

And from the EPON MIB:
One row 
EPOM MPCP param table:
dot3MpcpLinkID 1 
dot3MpcpRemoteMACAddress OLT_MAC_ADDRESS 
dot3MpcpRegistrationState registered
dot3MpcpMaximumPendingGrants 4
dot3MpcpTransmitElapsed   10
dot3MpcpReceiveElapsed    10
dot3MpcpRoundTripTime     100

ifIndex		1				65535

ifDescr		"I/F description"		"I/F description"      
ifType		gigabitEthernet (117)	gigabitEthernet (117)       
ifMtu			MTU size (1522)		MTU size (1522)       
ifSpeed		1000000000			1000000000       
ifPhysAddress	OLT_MAC_Address		OLT_MAC_Address       
ifAdminStatus	up				up       
ifOperStatus	Up				Up       
ifLastChange	ONU1_up_time 		up_time            
ifInOctets		ONU1_octets_number	BRCT_octets_number

ifInUcastPkts	ONU1_unic_frame_num	BRCT_unic_frame_num    
ifInNUcastPkts	ONU1_non_unic_frame_num	BRCT_non_unic_frame_num
ifInDiscards	ONU1_disc_frame_num	BRCT_disc_frame_numr    
ifInErrors		ONU1_err_frame_num	BRCT_err_frame_num      
ifInUnknownProtos ONU1_unknw_frame_num	BRCT_unknw_frame_num   
ifOutOctets		ONU1_octets_number 	BRCT_octets_number

ifOutUcastPkts	ONU1_unic_frame_num	BRCT_unic_frame_num    
ifOutNUcastPkts	ONU1_non_unic_frame_num	BRCT_non_unic_frame_num 
ifOutDiscards	ONU1_disc_frame_num	BRCT_disc_frame_num    
ifOutErrors		ONU1_err_frame_num	BRCT_err_frame_num      
ifOutQLen		ONU1_queue_frame_num	BRCt_queue_frame_num

And at the OLT:
ifIndex		100000				

And from the EPON MIB:
One row 
EPOM MPCP param table:
dot3MpcpLinkID 1 
dot3MpcpRemoteMACAddress ONU1_MAC_ADDRESS 
dot3MpcpRegistrationState registered
dot3MpcpMaximumPendingGrants 4
dot3MpcpTransmitElapsed   10
dot3MpcpReceiveElapsed    10
dot3MpcpRoundTripTime     100

2)
When ONU1, ONU2, ONU3 are registered:

The parameters for the IF table:

And from the EPON MIB:
One row 
EPOM MPCP param table:
dot3MpcpLinkID 1 
dot3MpcpRemoteMACAddress OLT_MAC_ADDRESS 
dot3MpcpRegistrationState registered
dot3MpcpMaximumPendingGrants 4
dot3MpcpTransmitElapsed   10
dot3MpcpReceiveElapsed    10
dot3MpcpRoundTripTime     100

And at the OLT:
ifIndex		100000				

And from the EPON MIB:
3 row 
EPOM MPCP param table:
dot3MpcpLinkID 1 						2
3			
dot3MpcpRemoteMACAddress ONU1_MAC_ADDRESS		ONU2_MAC_ADDRESS
ONU3_MAC_ADDRESS	 
dot3MpcpRegistrationState registered		registered
registered		
dot3MpcpMaximumPendingGrants 4			4
4			
dot3MpcpTransmitElapsed   10				10
10
dot3MpcpReceiveElapsed    10				10
10
dot3MpcpRoundTripTime     100				60
20

.

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Wednesday, February 08, 2006 5:09 PM
To: Lior Khermosh; David T. Perkins
Cc: Hub MIB
Subject: RE: Response to EPON-MIB-04

Regards,

Dan

> the link based table when ONU registers (a virtual link established) 
> and deregisters (a virtual link deleted) similar to TCP connections 

> I am not sure that you addressed part of David's query - 'Also 
> describe what events cause a new instance to be created or deleted' - 
> or in other words what events determine new rows to be created or rows

> to be deleted in the tables?
> 
> Thanks and Regards,
> 
> Dan
> 
> 
>  
>  
>

---

From: "Lior Khermosh" <[email-masked]>
Date: Sat, 11 Feb 2006 09:36:57 +0200

OK 

-----Original Message-----
From: David T. Perkins [mailto:[email-masked]] 
Sent: Friday, January 20, 2006 7:43 PM
To: Lior Khermosh
Cc: [email-masked]; Hub MIB
Subject: Re: [Hubmib] Response to EPON-MIB-04

HI,

Just saw one more small item. The MIB module is named
"DOT3-EFM-EPON-MIB". I suggest that the name "DOT3-EPON-MIB"
be used instead.

Regards,
/david t. perkins

---

From: "Lior Khermosh" <[email-masked]>
Date: Mon, 13 Feb 2006 09:58:02 +0200

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-masked]] 
Sent: Friday, January 20, 2006 9:01 AM
To: Lior Khermosh
Cc: [email-masked]; Hub MIB
Subject: Response to EPON-MIB-04

HI,

easily fixed. Unfortunately, there are a couple of fundamental issues
that remain. These are:
>> 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.

And the OLT interface:
ifIndex		100000				

>> Object are determined for each virtual MAC

>> 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.

>>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.

>>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.

>> 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.

>> 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.

>> 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.

>> 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).

    details 
>> Please see the response above.

(or indicate the object definition where the
>> 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.

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.

>> attributes. Changed
>> I will put them in.
>>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."

>> Please look at the clarification added after the former comments.

>> OK. Replaced with ifIndex.

>> 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.

     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
>> The description of the index in each table refer the ifIndex to the
virtual links established at the OLT case. 

     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.

>> OK. Replaced with ifIndex.

>> 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  

Subject: [Hubmib] RE: Response to EPON-MIB-04
From: "Lior Khermosh" <[email-masked]>
To: "Romascanu, Dan \(Dan\)" <[email-masked]>, "David T. Perkins" <[email-masked]>
Cc: "Hub MIB" <[email-masked]>
Date: Tue, 7 Feb 2006 15:34:26 +0200

Dan,

Also during this session I had some second thoughts on some of the
changes I have integrated in the last review. Specifically as to use a
linkIndex inside the MIB tables instead of using the ifIndex of the
virtual links. Although it is not exactly as the IEEE layering for the
EPON (the MPCP and P2PE layers are a single layer and not N virtual
links) the specification of the MIB is more simpler and more neat. There
are no multiple rows for each virtual link and the duplication is
generated by the ifIndex for the virtual links (like it was in draft
03). That way it is more similar to the tables which will be held for
the virtual MACs management. I am still considering it and I will try to
discuss it with David and then provide the draft ASAP.

Best regards,
Lior

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Monday, January 23, 2006 9:06 AM
To: David T. Perkins; Lior Khermosh
Cc: Hub MIB
Subject: RE: Response to EPON-MIB-04

David,

Lior,

I believe that David is asking for clarifications, maybe an example that
would clarify his question 1. This new text could expand Section 3
'Relationship of the EFM EPON MIB to other MIBs'. By the way, 'Relation
to other MIB Modules' would be a better name for this section. 

With respect to David's question #2, the text 'Rows at the table are
created by direct SNMP management setting." seems wrong. David's
question is correct, if rows in these tables are created dynamically by
management operations on the specific table, you need to use "RowStatus"
objects for the specific table. If this was not the intention, the text
should be eliminated and you should mention in the DESCRIPTION clauses
in each table how each row shows up, maybe as result of operations
performed on other tables, or corresponding to existing ports on the
device, or something else. 

I am also feeling very uncomfortable with holding discussions around a
non-submitted draft.  I would like to ask Lior to submit draft 04
immediately. If the issues cannot be clarified and a revised draft
submitted in the next couple of days, it can be as it was distributed on
the mailing list last December.  

Regards,

Dan

> easily fixed. Unfortunately, there are a couple of fundamental issues 
> that remain. These are:
> Until the above fundamental issues are resolved, it doesn't make a lot

>      c) I thought CPE was customer premises equipment section 1.2.3 - 
> I was confused. Does "Gate messages"
>      start a new subsection?
>      table. This is done in the queue tables and object dot3LinkIndex.
> 
> 

Subject: RE: Response to EPON-MIB-04
From: "Lior Khermosh" <[email-masked]>
To: "David T. Perkins" <[email-masked]>
Cc: "Romascanu, Dan \(Dan\)" <[email-masked]>, "Hub MIB" <[email-masked]>
Date: Tue, 7 Feb 2006 21:39:12 +0200

David,

And the OLT interface:
ifIndex		100000				

 
Best regards,
Lior

-----Original Message-----
From: David T. Perkins [mailto:[email-masked]] 
Sent: Tuesday, February 07, 2006 6:30 PM
To: Lior Khermosh
Cc: Romascanu, Dan (Dan); Hub MIB
Subject: RE: Response to EPON-MIB-04

HI,

Regards,
/david t. perkins

section.
"RowStatus"

dot3LinkIndex.

Subject: RE: Response to EPON-MIB-04
From: "Lior Khermosh" <[email-masked]>
To: "Romascanu, Dan \(Dan\)" <[email-masked]>, "David T. Perkins" <[email-masked]>
Cc: "Hub MIB" <[email-masked]>
Date: Wed, 8 Feb 2006 17:41:05 +0200

And from the EPON MIB: 
EPOM MPCP param table:
dot3MpcpLinkID 0 

And at the OLT:
ifIndex		100000				

FOR THE VIRTUAL LINKS:
ifIndex		65535                                                

And from the EPON MIB: 
No rows

2)
When ONU1 is registered:

And from the EPON MIB:
One row 
EPOM MPCP param table:
dot3MpcpLinkID 1 

And at the OLT:
ifIndex		100000				

And from the EPON MIB:
One row 
EPOM MPCP param table:
dot3MpcpLinkID 1 

2)

And from the EPON MIB:
One row 
EPOM MPCP param table:
dot3MpcpLinkID 1 

And at the OLT:
ifIndex		100000				

And from the EPON MIB:
3 row 
EPOM MPCP param table:
dot3MpcpLinkID 1 						2
3			

.

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Wednesday, February 08, 2006 5:09 PM
To: Lior Khermosh; David T. Perkins
Cc: Hub MIB
Subject: RE: Response to EPON-MIB-04

Regards,

Dan