[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: MIB Doctor review of: draft-ietf-mpls-ftn-mib-07.txt

Hi,

Thanks for your detailed analysis.


Bert asked me to review the indexing done in table mplsFTNMapTable
found in document draft-ietf-mpls-ftn-mib-07.txt.


Here are my findings:

The indexing in the table is legal. However, it is unusual and I find
the descriptions inadequate and the descriptors of columns in the table
to be poor choices.

Actually the document under discussion was draft-ietf-mpls-ftn-mib-08.txt
(yet to be published on the ietf website).

While the structure of the MIB hasn't changed between versions 7 and
8 (we hope) the descriptions have be enhanced. I will try and send that
to you this evening (I don't have it at work).


There are many ways to design a mapping table to support the above
specified operations. Since operations can occur concurrently
via SNMP messages from multiple managers and from local management
operations, the MIB design must be able to cope with these
situations. Also, the MIB design must cope with duplicated
SNMP messages and retried operations (which occur when an
SNMP response message is lost).

The indexing scheme for the mapping table appears to be chosen
to cope with concurency, and message duplication and operation
retry. However, it is unusual, and uses side-effects, both
which can confuse agent and management application designers.

You have summarized the requirements/problems we have tried to address
nicely. We could not see another easy way to achieve all these objectives.
If you have suggestions we would be more than happy to look at them.

Look forward to the rest of your analysis. Thanks.

Cheenu
--
Cheenu Srinivasan
Holmdel, NJ
From: "David T. Perkins" <dperkins@dsperkins.com>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
CC: tnadeau@cisco.com, arunv@force10networks.com, cheenu@alumni.princeton.edu, "Alex Zinin (E-mail)" <zinin@psg.com>, "George Swallow (E-mail)" <swallow@cisco.com>, "Loa Andersson (E-mail)" <loa.andersson@utfors.se>, mreview@ops.ietf.org
Subject: RE: MIB Doctor review of: draft-ietf-mpls-ftn-mib-07.txt
Date: Thu, 31 Jul 2003 10:27:41 -0700

HI,

Bert asked me to review the indexing done in table mplsFTNMapTable
found in document draft-ietf-mpls-ftn-mib-07.txt.


Here are my findings:

The indexing in the table is legal. However, it is unusual and I find
the descriptions inadequate and the descriptors of columns in the table
to be poor choices. Also, the indexing design may require high
runtime implementation costs.

Let me back up and describe the problem.

The problem is to associate an ordered list of items from one table
(in this MIB module, table mplsFTNTable) with entries from another table
(in this MIB module, table ifTable from the IF MIB module). A mapping
table (in this MIB module, table mplsFTNMapTable) is used to specify the
associations. Entries in table ifTable are indexed by the value of
object ifIndex, which has data type of positive integer in range
1 to 2^31-1. Entries in table mplsFTNTable are indexed by the value
of object mplsFTNIndex, which has data type of nonnegative integer
in range 1 to 2^32-1.
Table mplsFTNMapTable allows an association to be specified for any
entry in table ifTable with an ordered list entries in table mplsFTNTable.
It also allows an association to specified with the whole of
table ifTable with an order list of entries in table mplsFTNTable.
The whole table is identified by the "special" index value of zero,
and in the descriptions that follow, the reader should just consider
this identification of the whole table as if it were an entry in the
IF table.
The operations that the association supports are:
1) find first element (if any) in ordered list for an IF table entry
2) find next element (if any) in ordered list for an IF table entry
of a specified element
3) find previous element (if any) in ordered list for an IF table entry
of a specified element
4) Note, there is no operation to find the last element (if any) in
ordered list for an IF table entry
5) Insert an element in ordered list for an IF table entry after
a specified element (or as the first element in the list)
6) Delete an element from ordered list for an IF table entry

There are many ways to design a mapping table to support the above
specified operations. Since operations can occur concurrently
via SNMP messages from multiple managers and from local management
operations, the MIB design must be able to cope with these
situations. Also, the MIB design must cope with duplicated
SNMP messages and retried operations (which occur when an
SNMP response message is lost).

The indexing scheme for the mapping table appears to be chosen
to cope with concurency, and message duplication and operation
retry. However, it is unusual, and uses side-effects, both
which can confuse agent and management application designers.

The mapping table, mplsFTNMapTable, has three indices. The first
identifies an entry in the IF table. The second identifies the
previous entry in the ordered list of table mplsFTNTable entries.
The third identifies an entry in the ordered list of table
mplsFTNTable entries. This seems a little strange. So, lets
look at a small example.

Assume the IF table has 2 entries with index values 10 and 98.
Assume the MPLS FTN table has 6 entries with index values
of 34, 78, 103, 142, 205, and 986.
Assume we want the following associations

IF table ordered list of
entry MPLS FTN entries
0 (whole table) 205, 78, 34, 986
98 103, 205, 142

These result in the following values for indices:
(0,0,205) (0,205,78) (0,78,34) (0,34,986)
(98,0,103) (98,103,205) (98,205,142)

1) To find the first entry in the ordered list for IF entry "I",
a GETNEXT with is done with index of "I".0.0 (of an accessible
column, such as the RowStatus column (which is mplsFTNMapRowStatus)).
For example GETNEXT(mplsFTNMapRowStatus.98.0.0) results in
variable mplsFTNMapRowStatus.98.0.103. (Note that if either
no association exists or the IF entry does not exist for
IF entry "I", then the variable returned will either not be for
object mplsFTNMapRowStatus or the entry will not be for entry "I".)

2) To get the next entry in the association for an IF entry,
let "I" be the index of the IF entry and "F" be the index
of MPLS FTN entry in the association.
A GETNEXT(mplsFTNMapRowStatus."I".0."F") returns the next
entry in the ordered association if one exist. Assume the
index of the next MPLS FTN entry is "G". If so, the returned
variable will be mplsFTNMapRowStatus."I"."F"."G".
Note that this is a "new" iteration design pattern. A simple
GETNEXT of mplsFTNMapRowStatus."I".0."F" will typically
not return the next ordered item in the association. However,
a sequence of GETNEXTs (or GETBULK) of mplsFTNMapRowStatus."I".*.*
will return all items in the association for IF entry "I",
which can be ordered by the management application.
Note that during iteration, consider that the last item
retrieved has index "I"."P"."F". Does insertion or deletion
of entries in the association between the time when the item
was retrieved and before retrieval of the next item cause
"bad things" to occur (such as looping in the management app
or skipping over a "chunk" of the entries)?

(The answer to this question, and the completion of the analysis
of the other operations will be completed in the next installment.
Also, I need to talk about the choice of descriptors for index
columns in table mplsFTNMapTable and the runtime costs in
the agent to support indexing approach.

Sorry, I've run out of time, and promised to quickly send
a response on this issue.)

Regards,
/david t. perkins

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus