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

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

I think the bigger worry that Dave and I currently have is the
behaviour as it is seen by a NMS station. So if there are lots
of dynmaic changes to the FTNMapTable, then we think it is
important to tell NMS apps writers to make sure they pick
up LastCahnged object as well... 
And if there are large mapping tables and many dynamic changes, 
then the risk is there that a mgmt app may never succeed to 
properly walk the tables without having to restart all 
continuously.

Thanks,
Bert 

> -----Original Message-----
> From: Cheenu Srinivasan [mailto:cheenu_srinivasan@hotmail.com]
> Sent: dinsdag 5 augustus 2003 15:19
> To: bwijnen@lucent.com; dperkins@dsperkins.com
> Cc: tnadeau@cisco.com; arunv@force10networks.com; zinin@psg.com;
> swallow@cisco.com; loa.andersson@utfors.se; mreview@ops.ietf.org
> Subject: Re: MIB Doctor review of: draft-ietf-mpls-ftn-mib-07.txt
> 
> 
> 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
>