Subject: Some comments on LDP MIB

From: Theimer Thomas <[email-masked]>
Date: Fri, 27 Aug 1999 16:13:08 +0200

Below please find some comments on draft-ietf-mpls-ldp-mib-01.txt. I hope
they can still be considered for the next revision of the document.

Regards, Thomas
---------------------------------

Page 8, AtmVpIdentifier
The description seems to suggest that only the ATM UNI format is applicable
to MPLS (i.e. VPI range 0/1 to 255). Perhaps a comment on the NNI format
(i.e. VPI range 0/1 to 4095) should be added for the sake of completeness
(btw, the syntax specifies (0..4095)).

Page 9, mplsLdpLsrPathVectorLimit
What is the exact purpose of this parameter ? Is it an upper limit on the
path vector length, having a similar effect as the hop count limit ? That
should be clarified in the description.

Page 11, MplsLdpEntityEntry
Would it not be useful to add an admin status per LDP entity ? Thus, LDP
could be enabled separately on each interface.
For the ATM case, I think we need to know if the peer LSR is directly or
indirectly connected (i.e. via an ATM VP). This must be configured either as
part of the MPLS interface configuration or as part of the LDP entity for
ATM. Currently, there is no such parameter in the MIB.

Page 16, mplsLdpEntityConfAtmLabelRangeLowerBoundVPI &
mplsLdpEntityConfAtmLabelRangeLowerBoundVCI
Why are these defined as not-accessible ? They should be read-create like
the upper bounds.

Page 17, mplsLdpEntityStatsTable
There is a typo in the description, the entity table is called
mplsLdpEntityTable, not mplsLdpConfEntityTable.

Page 19 ff, mplsLdpPeerTable
Most entries in this table are defined as read-create. My understanding is
that these are the values received from the LDP peer during session
initialisation. Therefore, they should be read-only, as changing these
values does not seem to be of any use here.

Page 22, mplsLdpPeerConfAtmLabelRangeTable
See previous comment. These should be read-only.

Finally, I would like to suggest to move all interface-specific objects away
from the protocol-specific part of the MIB. Configurable parameters like
label ranges, VC directionality, merge capability etc. should appear only
once inside the MPLS MIB, in an interface-specific section (as long as they
are really protocol-independent).

---

From: "Hans Sj�strand" <[email-masked]>
Date: Tue, 31 Aug 1999 09:23:40 +0200

We are still working on an 02 of the mib, comments are always welcome.
Answers on your issues are embedded below. 

> they can still be considered for the next revision of the document.

You are right, I copied this from a old version of the ATM TC draft. Now
it is an RFC and should be imported from rfc2514 where the TC has
correct wording. 

> should be clarified in the description.

The best way to do this is probably to add a REFERENCE to the LDP spec,
section 2.8 where the path vector limit is described. 

> ATM. Currently, there is no such parameter in the MIB.

I would agree about the admin state, it could prove useful. Also in the
case where some of the parameters can't be changed on an active session. 

I don't see the immediate need for parameters for indirectly connected
peers. What cases are not covered by simply restricting the label range
to the VP or VPs used. 

> Why are these defined as not-accessible ? They should be read-create like

These are the indexes of the table and are therefore defined as
not-accessible. They are set in when the row is created.  

> mplsLdpEntityTable, not mplsLdpConfEntityTable.

Thanks, to be corrected

> See previous comment. These should be read-only.

The reason to have these parameters is to allow for static configuration
of peers. THis was particulary useful in the early days, and we have to
decide if we want to maintain that flexibility. The question was raised
also in Oslo. What is your option Joan?

> are really protocol-independent).

This is one solution to the problem to make the LDP mib bearer
independant (i.e less ATM centric) as we said in Oslo. Sounds like you
have some more specific proposal on how to do it, please cheer your
ideas with us. 

Regards
/// Hasse