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

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 28 Oct 1999 12:02:25 -0400

[I appologize, but my last message did not include the quotes for Joan's
  replies.]

	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.

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

 >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