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

["Cheenu Srinivasan" <cheenu_srinivasan@hotmail.com>]

Just one other note about how changes to the mapping table will affect
a traversal that's in progress.

> > > 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.
>
> I will add a note highlighting how mplsFTNMapTableLastChange can
> be used to ensure that the table hasn't changed while in the middle
> of a walk.
In order to discover the list of items in the linked list, the difference
between the traversal operation and a "normal" getnext is the
difference between these two questions:

 Normal: What is the item next to 'n' in the vector?
 Traversal: What is the item next to 'n' in the linked list?

since we can think of an SNMP table as a vector with
(potential) "holes" in the indexing. Lets assume that the answer
in both cases is m.

In either case we can get an in-progress retrieval operation to
continue infinitely while keeping the table size constant by continually
inserting an entry after 'm' while removing 'n'. The meaning of
'after' is different in the two cases but the problem is identical
in either case.

The only way an agent can handle this situation is by retrieving the
last changed object along with the object of interest from the table.

I don't believe we have introduced a new problem into the
SNMP domain because of the auto-reindexing property of the mapping
table.

So I don't see the need to add a note about the last changed object
particularly for this table (and make people think that somehow there
is a unique problem we are addressing for this table).

I think if we forget about SNMP for a moment and simply compare
operations on a linked list versus a vector this will be clearer.

Please let me know if I am missing something.

Thanks,
Cheenu

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail