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

From: Hans Sjoestrand <[email-masked]>
Date: Fri, 29 Oct 1999 08:59:26 +0200 (MET DST)

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.

> 
>  >Thomas, we will look for a way of reducing indices but I disagree that
>  >the LDP MIB is overly complex in its structure or even in the objects which
>  >are being used to configure or being collected. The NMS could NOT
>  >associate an LDP Entity, and Peer with a specific Session without some
>  >way to tie these together (indices are being used to do this).
> 
> 	This is all that I ask that this point. I need to go through the new tables
> in detail (perhaps this weekend) again. Perhaps at that point I can give 
> you more
> detailed feedback as to the implementation details of these tables. However,
> as I requested in initial message, I would be interested in hearing back 
> from others
> who have or are in the midst of actually implementing the rev 03 of the LDP MIB
> and as to whether or not they had a difficult time implementing these 
> tables with
> large numbers of indices. It may indeed be the case that I am confused and that
> I just need to suck it up and get the tables to work if that is the only 
> way to
> implement them. I only ask that at this time, that we think about whether or
> not there might be an easier way to accomplish what we are doing here.

In my experience the most CPU-intensive task for the agent is managers
get-nexting through entire tables to find the correct entry. This is
one reason behind the indexing being as is. E.g to find a session that
belongs to an entity, you don't have to scan the whole table, you can
start your get-next at {enityindex wildcards} which is normally almost
a direct hit. So, I actually belive that you save a lot of CPU doing it
this way.

Regards
/// Hasse

> 
>  >I would like to point out that there is some overhead with having
>  >L2-specific tables (such as the mplsLdpAtmSessionTable and 
> mplsLdpFrSessionTable)
>  >to represent different L2 media.  Prior to rev 2,  the ATM information 
> was in the same
>  >tables and the request was to separate it out (which I believe was the 
> correct action.)
> 
> 	Yes, I believe that the structure of the MIB makes logical sense after
> reading it. Objects are layed out in a reasonable grouping. However, as I 
> pointed out,
> this may not make sense in terms of implementation. My point is that if it 
> is easier for
> an implementation to add these columns to an existing  table which is more 
> simply
> indexed, this is the way to go. Let the NMS figure things out on the other end.
> 
> 	I will get more feedback to you after reading the MIB in more detail.
> 
> 	Regards,
> 
> 	--Tom
> 
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 29 Oct 1999 11:37:12 -0400

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

         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.

         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