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

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

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

Thanks,
Cheenu