Subject: Re: draft-ietf-mpls-ldp-mib-03.txt - large number of indexes

From: Hans Sjoestrand <[email-masked]>
Date: Mon, 1 Nov 1999 13:07:05 +0100 (MET)

Hi,

Thomas D. Nadeau wrote:
> At 08:59 AM 10/29/99 +0200, Hans Sjoestrand wrote:
> >Thomas D. Nadeau wrote:
> > >       Hi Joan,
> > >
> > >  >GetNext will retrieve the next object.  I don't quite understand what
> > >  >you mean by wild-card the rest of the index.  You do a get-next you 
> > receive
> > >  >the next object.  Typically, the just-retrieved object is used in the
> > >  >next get-next to retrieve the next object, and so forth.
> > >
> > >       My point is that *I* have to write the get-next routine to find 
> > the next
> > > object. There is no auto-magic way of doing it. My point is that in the 
> > worst-
> > > case (ie: the table with 7 indices), one has to iterate over 7 indices to
> > > locate
> > > the appropriate first object, and then again to find the one after that,
> > > which gets
> > > more complicated then just finding the first item since the table can be
> > > sparse,
> > > and now in 7 dimensions. After discussing this with a college who has just
> > > implemented most of the 01 version,  I understand that the code for rev 03
> > > is not going to be pretty with respect to nexting over 7 indices.
> >
> >The get-next routine is standard stuff and easy to implement in a
> >generic way if only the databasestructures is designed to cope with the
> >snmp-sort order. I could agree that that might be hard to do since the LDP mib
> >is moving target as long as it's in draft state.
> 
> 
>          Might I ask whether or not you have implemented these tables, and 
> whether
> or not they were as easy to implement as you say they should be?

No, I have not implemented these specific tables yet. In the same time
lets make it clear that I'm not trying to protect my own implementation
but are trying to find the best solution for the final mib. But I've made  
lots of other tables with 7 indexes so the principle remains i think.

> 
>          Next, let me first say that I agree with your point above, but you 
> are assuming
> that the data structures are designed in such a way as to make linear 
> access easy,
> which I believe is a flaw in your argument. I have worked on numerous 
> systems where
> the data structures were designed well before the network management was even
> though of being implemented.  If I have a possible 7 indexes for an object, 
> and I am
> given a next request containing all 7 indexes, I believe and correct me if 
> I am wrong,
> that in the worst case, I will have to iterate over 7 lists of data 
> structures if the item I am
> finding the "next" of is found late in the lists. This iteration must take 
> place for every
> get-next or get which is received. This is not so efficient in my mind. I 
> would rather
> present a larger list of entries in a table for an NMS to iterate over, 
> thereby pushing
> the processing off onto the NMS, instead of having the agent spin over all 
> of these
> lists every time a get-next is issued.

Maybe I have been a little naive on the complexity that indexes causes. The 
implementation we most often use in case of "patching datastructures" is to use 
a shadow table which is snmp-structured and references into the other 
datastructures. Because of the support out agent gives I have never been dealing 
with tedious get-next programming. We haven't seen any performance decrease in case
of heavy indexing. 

> 
>          I do see your point of reducing network traffic by having the NMS 
> make more
> constrained requests, and thereby perhaps interrupting the agent fewer 
> times over-all.
> I also hope that you see and agree with my point in having each 
> interruption make the
> least amount of impact possible. I am not arguing for singly-indexed tables 
> to replace
> all of the tables in the LDP MIB.  I believe that tables having more than 3 
> indexes
> are terribly difficult to implement. I also agree with you that reducing 
> the amount of
> interruptions that an agent receives for any given table is an important 
> issue. What I
> am requesting is that we reduce the number of indexes in these tables to 
> say 2 or 3
> to balance both of the points made above. While I think that having any 
> more than
> say 3-4 indexes creates terribly difficult tables to implement, I also 
> agree completely
> that singly-indexed tables are also overkill in the other direction.
> 
>          --Tom

Understand your point and are willing to discuss your proposal when you
make one, we are always open to good suggestions. However, I don't see 
heavy indexing on it's own as a major problem. I know of several
independant implementation that haven't complained, so I doubt that 
we will change the model because of implementation problems in one. 
We have spend quite a while on this without finding a smarter solution.
The dependencies between entety, peer, adj etc are quite complex.

Regards
/// Hasse

---

From: Robert Schmitt <[email-masked]>
Date: Mon, 01 Nov 1999 10:51:47 -0500

Regards
/// Hasse

Yes, indeed they are.  I would only add a singular point that I think
that in the set of INDEXs that appear throughout the LDP MIB, i.e

mplsLdpEntityLdpId
mplsLdpEntityIndex
mplsLdpPeerLdpId
mplsLdpPeerIndex

mplsLdpEntityLdpId is unquestionably required
mplsLdpEntityIndex is required to support PLATFORM wide Entities
mplsLdpPeerLdpId is the REMOTE mirror corresponding to the mplsLdpEntityIndex
                 and is also required.

     however

The above three values are sufficient to uniquely identify a PEER and therefore
mplsLdpPeerIndex is redundant (and adds unnecesarry complexity). If this
statement overlooks, something, I would appreciate a reply.

Thank you

+----------------------------------+------------------------------+
            |           |          |         Robert Schmitt
            |           |          |       [email-masked] 
           |||         |||         |         Chelmsford, MA
          |||||       |||||        |          978-244-3076
      ..:|||||||:...:|||||||:..    |        
      C i s c o  S y s t e m s     |        
+----------------------------------+------------------------------+

---

From: Joan Cucchiara <[email-masked]>
Date: Mon, 01 Nov 1999 13:56:55 -0500

So I think we have reached agreement that the
issue of a large number of indices is an efficiency
issue (i.e. more compares),correct?  
(as opposed to an issue with getNext algorithm complexity).

> statement overlooks, something, I would appreciate a reply.

You may be correct.  I added this index (mplsLdpPeerIndex) thinking it
was necessary as a way to differentiate per-platform Peers but, in
retrospect, agree with you that it does not seem necessary, since I
don't think a per-platform Peer could be (or needs to be) differentiated
from 
"this LSR's point of view".  In other words, it is perfectly acceptable
to see a per-platform Peer as a entry in the Peer Table identified
solely
by its LdpId.  

Thank you for your comments, we will look into taking 
this index (mplsLdpPeerLdpIndex) out.

	-Thanks, Joan

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 01 Nov 1999 19:30:07 -0500

>(as opposed to an issue with getNext algorithm complexity).

         I think that this is (at least partially) the point I was
trying to make originally. I guess that I was not clear enough and
need to work my communication skills. :P  I think that it is clear
that the larger the indexes are, the more compares are required
to take place, which increases the amount of work required by the
agent. One other important point which we sometimes overlook
here is that as we increase the complexity of the design, this also
inevitably increases the complexity of the implementation,
and therefore the potential for implementation error. I guess that
I just believe in trying to keep things as simple as possible,
not only for time-to-market concerns, but also with regard to
quality.

         --tom