Subject: draft-ietf-mpls-ldp-mib-03.txt - learned labels

From: Bob Thomas <[email-masked]>
Date: Tue, 26 Oct 1999 09:54:01 -0400 (EDT)

Hi,

I may have missed it, but draft-ietf-mpls-ldp-mib-03.txt does not
appear to provide a means to obtain outgoing labels learned
via LDP by an LSR.

Specifically, the LIB table appears to contain only those outgoing labels
being used for MPLS forwarding.

I would have expected the LIB table for this MIB to contain all labels
learned via LDP from peers.  This does not appear to be the case.  For
example, in liberal retention mode an LSR will retain, presumably in
its LIB, every label it has learned and retained regardless of whether
the label is currently being used for forwarding.

Thanks,
Bob

---

From: Joan Cucchiara <[email-masked]>
Date: Wed, 27 Oct 1999 09:28:08 -0400

Hi Bob,

> the label is currently being used for forwarding.

Yes, we should and will add this to the next rev.

	Thanks, Joan

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 28 Oct 1999 09:05:32 -0400

Hi,

	I finally had the opportunity to read over the 03 version of
the LDP draft MIB yesterday in the context of implementing it
and was concerned over the number of indexes per table. I believe
one table in the 03 rev actually has 7 or 8 indexes. I  would like to get
some feedback from folks who are implementing the LDP MIB in both
its previous and current revision, specifically in terms of the ease of
implementation, but also in terms of how bogged down their agent
might get when walking through these tables.

	Has it occurred to anyone out there that having more than say 3
indexes on any particular table makes it not only extremely difficult to
implement, but also to verify its correctness. In particular, I am 
referring to
the get-next operation. Receiving a get-next request on a column and say one
of the middle indexes, and having to wild-card the rest of the index is pretty
complicated to get right. The other thing I am worried about is that the CPU
time it takes for an agent to shuffle through a 6+ indexed table might be
significant. Perhaps there any easier way to structure the tables, maybe
by combining some of the tables together in to simpler tables?

	The structures of these tables reminds me of a passage from
Dave Perkins' book on the design of SNMP MIBs, where we recommends
that the design of a MIB be as simple as possible for an agent to implement,
and pushing the processing off onto the managers. His reasoning is that
the CPUs of agents are probably doing something other than processing
SNMP code (ie: forwarding packets), so the agents should do as little as 
possible.
He also suggests that the first-pass of the design of any MIB may only reflect
an ease of management approach for  the manager versus the actual
implementation, and only after going back and scrutinizing the design will
these issues be raised.

	Regards,

	--Tom

---

From: Joan Cucchiara <[email-masked]>
Date: Thu, 28 Oct 1999 11:23:32 -0400

> one table in the 03 rev actually has 7 or 8 indexes. I  would like to get

yes, the mplsLdpAtmSessionTable has 7 indices.

 INDEX       { mplsLdpEntityLdpId,
                       mplsLdpEntityIndex,
                       mplsLdpPeerLdpId,
                       mplsLdpPeerIndex,
                       mplsLdpSessionIndex,
                       mplsLdpSessionAtmLabelRangeLowerBoundVpi,
                       mplsLdpSessionAtmLabelRangeLowerBoundVci

                     }

This is the only table with 7 indices the
others have less.  

I don't find this so unusual.  The AToM MIB's CrossConnect tables
have quite a few indices (rfc 2515).  1695, the predecessor or 2515
has been around a number of years.

> by combining some of the tables together in to simpler tables?

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.  

> implementation, and only after going back and scrutinizing the design will

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

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

It would be more helpful if you pointed out specific objects which you
believe the NMS could infer and should not be included in the MIB.  

	Thanks, Joan

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 28 Oct 1999 11:51:09 -0400

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