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

["Thomas D. Nadeau" <tnadeau@cisco.com>]

> -----Original Message-----
> From: Cheenu Srinivasan [mailto:cheenu_srinivasan@hotmail.com] 
> Sent: Monday, August 04, 2003 10:39 PM
> To: Wijnen, Bert (Bert); David T. Perkins
> Cc: tnadeau@cisco.com; arunv@force10networks.com; 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
> 
> 
> Dave, Bert, 
> 
> Please see my responses inline. A lot of Dave's analysis is 
> very interesting/useful but in this email I have tried to 
> focus on potential issues that he has mentioned and hence I 
> have liberally snipped through the comments.
> 
> > > 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.
> 
> That is quite accurate. We did not find an easier way to meet 
> these objectives.
> 
> > > However, it is unusual, and uses side-effects, both
> > > which can confuse agent and management application designers.
> 
> Applications written to work with this MIB will need to 
> understand its behavior and follow the rules.
> 
> > > 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.
> 
> > > 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.
> 
> Traversing the list in reverse, O(1) access to the last 
> element etc. were not deemed necessary/important for the 
> application this is targeting.
> 
> > 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.
> 
> The intent was as Bert has conjectured, i.e. if you try 
> create an entry referring to a non-existent prev entry the 
> set shd fail, so we don't have all these issues about when to 
> adjust the next item. It will be done as soon as a create succeeds.
> 
> This is a good point that needs to be made explicit and I 
> will try to add suitable text. Is 'inconsistentName' the 
> right error code to return in the above situation?
> 
> > > 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.
> 
> I am not sure about what a good defval for this would be. I 
> would tend to think 'nonVolatile' since it is configuration 
> data and can add this if there's agreement.
> 
> > 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.
> 
> The intent was for the reindexing to only happen when (legal) 
> rows are created and rows are destroyed. A row which is not 
> in the 'active' state will simply not have any effect on 
> packet processing even if it is in the middle of a list of 
> rules. I will make this explicit.
> 
> <SNIP>
> > > 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.
> 
> We went over this some time back before we decided that it 
> was very important not to have to reindex items in order to 
> insert a rule => a linked list is the inevitable choice.
> 
> > > 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. 
> 
> Actually, the larger the number of rules applied to an 
> interface the harder it gets if we cannot do constant time 
> insertions in the list.
> 
> > > 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.
> 
> The MIB has been around for a while and there are 
> implementations out there. But I don't have the specifics 
> available. Perhaps, one of the other authors can chime up ...

	Having implemented an earlier version of the MIB
(~3 revisions ago), I will say that if your code is 
inefficient or tricky at addressing/finding entries in your 
TFIB or FIB, then you may have issues with this MIB. Given 
this, I will say taht we did have to make some minor adjustments
to TFIB/FIB accessor functions for efficiency. Once this was 
done things seem to work pretty smoothly. Also note that
these changes were related to the indexing changes we 
made to the LSR MIB. My implementation which is read-only,
maps one label to one non-TE LSP, so there are absolutely 
no linked list issues with the rules I create. In the case of 
TE, we do map more than one prefix to a TE tunnel entry,
but that is done using indexes that are chosen
to be efficient internally, so there were no performance
issues there.

	--Tom