[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: MIB Doctor review of: draft-ietf-mpls-ftn-mib-07.txt
> 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...
Good point.
> 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.
I wouldn't say "never succeed", but it is likely that
it would take a long time if the right conditions occurred.
That is, this is probably only likely during a reconfiguration
of a network or when a device is booting up. In the middle of
this time, the device would be changing the FIB/TFIBs and
perhaps alterning static routes. The NMS might be dumping a
new set of static routes to the device as well (this is BTW
the only time when an NMS would be configuring this
MIB). After that point, routing database churn is kept to
a minimum.
--Tom
> 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
> >
>