[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,
This is a continuation of a message that I sent 7/31/2003:
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 the ordered list for an IF table entry
2) find next element (if any) in the ordered list for an IF table entry
of a specified element
3) find previous element (if any) in the 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
the ordered list for an IF table entry
5) Insert an element in the ordered list for an IF table entry after
a specified element (or as the first element in the list)
6) Delete an element from the ordered list for an IF table entry
7) Determine if an item is an element of the ordered list for
an IF table entry (isMember function)
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 7 entries with index values
of 34, 78, 103, 142, 187, 205, 609, 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, 609
These result in the following values for indices:
(0,0,205) (0,205,78) (0,78,34) (0,34,986)
(98,0,609) (98,609,205) (98,205,142) (98,142,103)
And since the first three columns in table are index columns (and
not-accessible), then the OID values for the accessible columns
in lexi-graphical order are (which is different than the linked
order are):
mplsFTNMapRowStatus.0.0.205 mplsFTNMapStorageType.0.0.205
mplsFTNMapRowStatus.0.34.986 mplsFTNMapStorageType.0.34.986
mplsFTNMapRowStatus.0.78.34 mplsFTNMapStorageType.0.78.34
mplsFTNMapRowStatus.0.205.78 mplsFTNMapStorageType.0.205.78
mplsFTNMapRowStatus.98.0.609 mplsFTNMapStorageType.98.0.609
mplsFTNMapRowStatus.98.142.103 mplsFTNMapStorageType.98.142.103
mplsFTNMapRowStatus.98.205.142 mplsFTNMapStorageType.98.205.142
mplsFTNMapRowStatus.98.609.205 mplsFTNMapStorageType.98.609.205
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"."F"."G" (the last item returned)
will typically not return the next ordered item in the association.
Instead, to retrieve the next in the linked list after
mplsFTNMapRowStatus."I"."F"."G", the argument to the GETNEXT
must be mplsFTNMapRowStatus."I"."G".0 and not
mplsFTNMapRowStatus."I"."F"."G". Instead of retrieving
the items in linked order, a "normal" sequence of GETNEXTs
(or GETBULK) of mplsFTNMapRowStatus."I".*.* can be used to
retrieve all items in the association for IF entry "I",
which can then be put in the "link order" by the management
application.
Since the mapping table is not "locked" during retrieval,
items can be inserted or deleted. We must determine if this
results in "bad things" to occur (such as looping in the
management app or skipping over a "chunk" of the entries)?
The object mplsFTNMapTableLastChange is provided to indicate
to a management application that a deletion, addition, (or
modification) has occurred. When retrieving items in linked
order, this object must be retrieved along with object
mplsFTNMapRowStatus (or mplsFTNMapStorageType). If the
value of object mplsFTNMapTableLastChange changes, then
the retrieval should be restarted.
If a simple GETNEXT (or GETBULK) retrieval approach is
used, then value of object mplsFTNMapTableLastChange must
be retrieved before all of the instances of object
mplsFTNMapRowStatus (or mplsFTNMapStorageType) are retrieved,
and then afterwards, and if different, then the retrieval
should be redone.
If there are many modification operations occurring on the
mapping table, the retrieval may take a very long time. This
should be a highly unusual situation except when a management
app is creating a new list for an IF instance. And in such
a situation, the mapping table is effectively "locked" from
retrieval of all IF instance links, even though only the links
for one IF instance are being updated. This may or may not
be a problem - it depends on the number of entries in the
mapping table and the frequency of updates and retrievals.
3) Due to the indexing, given the OID for an existing instance of
object mplsFTNMapRowStatus, such as mplsFTNMapRowStatus."I"."F"."G",
it is not easy to find the instance of the object that predeeds
it. That is, find the instance of mplsFTNMapRowStatus."I"."u"."F"
when the values of "I" and "F" are known, and the value of "u"
is unknown. A management app has to retrieve all of the items
for value of "I" until instance "I"."u"."F" is retrieved.
4) Due to the indexing, there is no easy way to determine the
index of the last item in the linked list for IF instance "I".
And likewise, there is no way from the objects to easily
determine the number of elements in the association. In both
cases, the answer is determined by retrieving all elements
in the association.
5&6) Where the indexing is highly efficient in reducing the number of
SNMP operations is for adding or deleting an element from the
association for an IF instance. Assume that no other management
app is modifying the mapping table (or table mplsTFNTable).
Consider the table shown above, and item with index of
187 in table mplsTFNTable is to be inserted as the second
item in the linked list for IF instance 98. Below is
shown the before and after linked lists and then the
instance 98.*.* slice from table mplsFTNMapTable:
Linked list instances
Before: (98,0,609)(98,609,205)(98,205,142)(98,142,103)
After: (98,0,609)(98,609,187)(98,187,205)(98,205,142)(98,142,103)
Notice that the second index of the previous second item in the
linked list changes to identify the new second item, and that
the index values for none of the other items have changed.
Lexi-ordered instances of slice 98.*.*
before:
mplsFTNMapRowStatus.98.0.609 mplsFTNMapStorageType.98.0.609
mplsFTNMapRowStatus.98.142.103 mplsFTNMapStorageType.98.142.103
mplsFTNMapRowStatus.98.205.142 mplsFTNMapStorageType.98.205.142
mplsFTNMapRowStatus.98.609.205 mplsFTNMapStorageType.98.609.205
after:
mplsFTNMapRowStatus.98.0.609 mplsFTNMapStorageType.98.0.609
mplsFTNMapRowStatus.98.142.103 mplsFTNMapStorageType.98.142.103
mplsFTNMapRowStatus.98.187.205 mplsFTNMapStorageType.98.187.205
mplsFTNMapRowStatus.98.205.142 mplsFTNMapStorageType.98.205.142
mplsFTNMapRowStatus.98.609.187 mplsFTNMapStorageType.98.609.187
The "strangeness" is that the insertion via a SET to mplsFTNMapStorageType.98.609.187 (to insert it after entry
with index 609 in table mplsFTNTable), cause as a side-effect
the instance of mplsFTNMapRowStatus.98.609.205 to change to
98.187.205! This next item is a little tricky (and the MIB document
doesn't cover this!), that only when the RowStatus is made
'active' does the renumber occur! That is the insertion
does not take place when the RowStatus has the value of
'notReady' or 'notInservice'. Note that the MIB document
does not describe the behavior when a SET occurs where
the index of the "previous" item does not exist and the
value for RowStatus is 'createAndWait'. Also, not sure why
there is no defval on the StorageType column, but then again
the StorageType value is an illusion (and I would just eliminate
the column). Note also when the value of the RowStatus column
is set to 'notInService', index renumbering occurs (and this
is not specified in the MIB document)!
For deletion, a single SET operation can be done to remove
an entry from the association. When this is done, the
re-indexing occurs (if needed (none is needed when the
last item in the linked list is deleted)). For an example,
consider the example above for addition, but in reverse order.
7) To determine if an item in table mplsFTNTable is an element
in a specific association (or in any association), then all of
the elements must be retrieved (or until the element is found).
Now that we have gone over all the operations, it's time to
take a look at the design assumptions and goals specified in
the MIB document that were used by the MIB designer in choosing
the design. First, at the highly abstract level, we see that
the MIB module represents an association between two tables.
And the association requires an ordered list (a sequence) and
not an unordered list (a set). (Note that the Bridge MIB module
uses a set to specify all of the ports that are members of
a VLAN.) The other management interfaces for the device
must also allow management of the association. And it is
very common to see in command line interfaces (CLIs), operations
to manage associations. In some CLIs, there are explicit
operations for adding (inserting) and deleting elements to
a sequence (which represents the association). In other CLIs,
there only the operation of adding an element to a sequence
(which is always added at the end of the sequence), and deleting
the complete sequence. That is, there is no deletion of
specific elements of a sequence, nor inserting elements at a
specific point in a sequence. If a CLI user wants to insert
at a specific point, or delete a specific element, then the
sequence must be deleted in it's entirety, and then recreated
as desired.
Given this behavior in industry leading platforms, I have concerns
that the first requirement specified in section 5.2.1 is not
real-world. Likewise, I believe that the second requirement
specified in section 5.2.1 is not realistic, if followed
by management applications will result in suboptimal
performance! This claim is based on the view as to how
a management app should be written. I believe that configuration
information should be retrieved when needed (or in anticipation
of need), and stored in data structs in the management app
that efficiently supports its operations, and allows
efficiently determination if the configuration data held by
the management is "stale" (out of date with the configuration
data on the management device, and the device is the
authoritative source). Retrieving the configuration data
should be efficient, but should also not put too great
a burden on the managed device for retrieval or for
storage (identification of instances). Thus, a careful balance
needs to be selected in MIB design between the choices
that allow low cost implementation on the managed system
resource manager and any mediation needed by the access
routines used between the SNMP agent and the resource
manager. (Readers - I hope I have not lost you with this
terminology!) From my experience, the choice is clear
and it MUST favor lowering the costs in the managed system
over the costs of the management application.
So far, I haven't said anything about the costs of supporting
this design approach in the managed system. In a system
the entries in tables mplsFTNTable and mplsFTNMapTable
could be implemented in software or in hardware. I haven't
had an opportunity to ask the actual designers. So, this
is left as additional work to do. But in just "paper"
analysis, to walk an association in linked order, means
to do a GETNEXTs of mplsFTNMapRowStatus.I.f.0 instances.
Finding the list for IF entry I is probably a direct lookup.
However, finding the "next" for mplsFTN entry requires
a scan of the internal list that implements the association.
This will not be cheap if the list is long or if the
cost to find the previous is expensive (such as in
a hardware implementation, there would be no need
to have the previous). And it will probably require
special "hand coding", which may result in bugs
and/or interoperability problems. But, these may
similar to costs with supporting other objects.
So, I suggest that some gentle push back be applied
after a few more examples are given, to make sure
that this design pattern can be cost effectively
supported in systems or software and hardware
designs.
Regards,
/david t. perkins