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

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

To: bwijnen@lucent.com, dperkins@dsperkins.com
Subject: RE: MIB Doctor review of: draft-ietf-mpls-ftn-mib-07.txt
From: "Cheenu Srinivasan" <cheenu_srinivasan@hotmail.com>
Date: Mon, 04 Aug 2003 09:13:27 -0400
Bcc:
Cc: tnadeau@cisco.com, arunv@force10networks.com, zinin@psg.com, swallow@cisco.com, loa.andersson@utfors.se, mreview@ops.ietf.org
Reply-to: cheenu@alumni.princeton.edu

David,

Thanks for your detailed comments.

I will go through your and Bert's remarks and respond in detail
later (it will take some time to do justice to them).

Cheenu
--
Cheenu Srinivasan
Holmdel, NJ

From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "David T. Perkins" <dperkins@dsperkins.com>, cheenu@alumni.princeton.edu
CC: tnadeau@cisco.com, arunv@force10networks.com, "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, "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Subject: RE: MIB Doctor review of: draft-ietf-mpls-ftn-mib-07.txt
Date: Mon, 4 Aug 2003 11:36:05 +0200

Dave, thank you very much for a detailed review/analysis.
I think this will help a lot.
Inline

> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: maandag 4 augustus 2003 7:50
> 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,
>
> 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
>
Dave, I am not sure this alligns with the ordered list you gave above?
You have (for iface 98) 103 as the FIRST in the sequence. I.e. you
showed a sequence of:
98 103, 205, 142, 609
Maybe you meant:
98 609, 205, 142, 103
And then it all looks conistent again.... well except for the story
below where you seem to assume 103 as the first entry again.

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

I think that is a VERY good point. It is kind of "normal" way
of working in many cases (or so one could think). But in this
case there are more severe reasons to do so.

Cheenu,
May be the DESCRIPTION clause for mplsFTNMapTableLastChange can
be updated to indicate that it not only serves as a indication if
the manager needs to pay attention to the table, but that it also
needs to be used by the manager to do GETNEXTs, so that a manager
can see when the table changed and so it can detect if possible
re-indexing happened while it is walking the table.

I think what Dave saus is that a manager, instead of just
doing a GETNEXT(mplsFTNMapRowStatus.m.n.o), the manager
should always do a
GETNEXT(mplsFTNMapTableLastChange.0,mplsFTNMapRowStatus.m.n.o)
and then make sure that the returned LastChange value is still
the same one it got on the first GETNEXT when it started to
figure out the sequence of FTN rules applied to an interface.

>
> 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.
>
It would be good to add some text (somehwere) to estimate how
many FTN rules would (in normal) situations be applied to one
interface, and indeed add some text to explain the implications
if such a list would become a large/long list.

> 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.
>
One could make a not of that, but not sure if a manager ever needs
to know that. Does it? I guess in that case it might as welk GETBULK
the whole table?

> 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.
>
yep. May want to write that down somewhere.

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

Mmm... I had assumed (but indeed it is not written down explicitly)
that the re-indexing on insert/delete would happen as soon as the
row gets created/deleted, no matter what the value for RowStatus
was/is. Of course the inserted entry would only be applied if the
RowStatus is active, but I would assume that the mre fact that the
row gets inserted (or deleted) makes the re-indexing occur.
Might be good to document that explicitly though.

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

As I said, for creatAndWait, I would just do the re-idnexing.
But when one tries to create an entry for which the prevIndex
does not exist, then probably the best would be to return a
inconsistentName Error, Dave, do you agree on that????
If so, then pls spell it out in the DESCRIPTION clause.

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

A DEFVAL of nonVolatile (or volatile for that matter, whichever
the MIB designers think is best) would indeed be goodness in
my view.

Dave, there MUST be a indication of what the persistence behaviour
of a row (or all rows) in a table is. One can do that with a
Table/Entry DESCRIPTION clause that says something aka "all entries
in this table are supposed to be persistent, so they re-appear after
a restart or reboot" (which would be required if the StorageType
object is removed) or one can do a StorageType object. These MIB
authors have chosen RowStatus, and that is fine by me (and the
collective set of MIB doctors I believe).

> 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)!
>
Dave, I am not sure that that would be smart. If we do the renumbering
when the RowStatus changes in and out of 'active' state, then for
sure there are many more potential cases when re-indexing occurs.
And that would be BAD I think.

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

Well, that is something that the WG might discuss (if they have
not already done so). Not sure that we as MIB-doctors should/can
declare what is or is not a real-world requirement, can we?
Of course you seem to have a good explanation as to why you think so,
and so maybe this should be offered for consideration on the MPLS
WG mailing list. But we cannot just dictate it.

> 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.
>
Dave, good points. My thinking here is that it probably depends
a lot on: how many rules would normally (or maximum) be applied
on one interface. I believe I did ask this question already in
earlier emails to the authors, but I did not yet get an answer
I believe. I can certainly see that if
- there are potentially 100s (let alone 1000s) of rules that can
be applied to one interface at any point in time
- a lot of additions/deletion of rules (e.g. it is a very dynamic set)
that the design may then certainly be problemematic.

So authors/editors, pls let us know your thinking about that.

> 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.
>
I was assuming that most of the participants in this whole MPLS MIB
discussions are people who are certainly implementing at the managed
device. So I would assume/hope/think that that side of the picture
has gotten (and will continue to get) proper attention and evaluation.
Authors/editors, pls do speak up if I am mistaken here.

Bert
> Regards,
> /david t. perkins
>

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

Prev by Date: RE: MIB Doctor review of: draft-ietf-mpls-ftn-mib-07.txt
Next by Date: Re: How to specify InetAddressType COMPLIANCE requirements
Previous by thread: RE: MIB Doctor review of: draft-ietf-mpls-ftn-mib-07.txt
Next by thread: Re: MIB Doctor review of: draft-ietf-mpls-ftn-mib-07.txt
Index(es):
- Date
- Thread