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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

I had asked Dave to review, cause I thought (and still 
wonder) that these guys have done some REALLY WEIRD
indexing stuff, and SNMP SETs to create a row or
to delete a row will have side effects that cause
existing other entries in the table to be "re-indexed",
that is their index values will change as a result.
The authors claims it was inspired by material they
read in Dave's book "Understanding SNMP MIBs"

Dave has taken a look at it and thinks it is "valid" what
they did. Not sure why he put "valid" in double quotation marks?

Anyway, the latest doc that describes this is at:

   www.psg.com/~bwijnen/draft-ietf-mpls-ftn-mib-08.txt

I am specifically worried about the sections 5.2 through 6.5
and of course the mplsFTNMapTable itself in the MIB module.

If some of you could take a look and comment asap, I
would appreciate it very much.

Feel free copy your potential comments to the people listed
on Davids copy list as well.

Thanks,
Bert 

-----Original Message-----
From: David T. Perkins [mailto:dperkins@dsperkins.com]
Sent: donderdag 31 juli 2003 19:28
To: Wijnen, Bert (Bert)
Cc: tnadeau@cisco.com; arunv@force10networks.com;
cheenu@alumni.princeton.edu; Alex Zinin (E-mail); George Swallow
(E-mail); Loa Andersson (E-mail); mreview@ops.ietf.org
Subject: RE: MIB Doctor review of: draft-ietf-mpls-ftn-mib-07.txt


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