RE: Response to EPON-MIB-04
"Lior Khermosh" <[email protected]> Tue, 7 Feb 2006 21:39:12 +0200
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <63DC5157D93D3046B78E8DDD9130C4E023DB70@passmail> |
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 protected]]
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 protected]]
> 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 protected]]
> > Sent: Friday, January 20, 2006 9:01 AM
> > To: [email protected]
> > 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.
************************************************************************