Subject: LDP MIB last call

From: Vijay Srinivasan <[email-masked]>
Date: Thu, 9 Mar 2000 10:30:19 -0800

We would like to commence the last call for:

Definitions of Managed Objects for the Multiprotocol Label Switching, Label
Distribution Protocol (LDP)
draft-ietf-mpls-ldp-mib-05.txt

Last call will end on Friday, March 17.  Please send your comments to the
list.

Regards,
- Vijay

---

From: Jhilmil Kochar <[email-masked]>
Date: Thu, 16 Mar 2000 14:50:59 +0530

Hi,
    I have certain comments and doubts on the LDP Mib draft -05. Some of
these might have been discussed before or already known to authors. In
such case please indicate the resolutions and the reasoning behind them.

1. MplsLabel : Textual-convention. The description says
"For an ATM label the lower 16-bits represents the VCI,
             the next 8-bits represents the VPI and the remaining
             bits MUST be zero."
The VPI should be represented by 12 bits rather than 8 bits.

2. mplsLdpEntityEntry: Some of the objects in this table should have a
default value assigned as specified by LDP draft. Examples of such
objects are mplsLdpEntityWellKnownDiscoveryPort,
mplsLdpEntityMaxPduLength, mplsLdpEntityKeepAliveHoldtimer.

3. mplsLdpEntityEntry: The object mplsLdpEntityWellKnownDiscoveryPort is
(I assume) for UDP Hello discovery only. What about TCP port for
connections? That does not seem to be covered. Am I missing something?

4. mplsLdpEntityEntry: There are two objects mplsLdpEntityRowStatus and
mplsLdpEntityAdminStatus in entity table and the requirement of both
being present in the same table is not very clear. Probably
mplsLdpEntityAdminStatus is redundant and can be removed.

5. mplsLdpEntityFrameRelayParmsEntry: object mplsLdpEntityFrLen has
incorrect syntax. seventeenDlciBits is missing from the same.

6. mplsLdpEntityPeerEntry: It is not clear why the entries in this table
should not be present in session table. As far as I can make out these
parameters and also the parameters in session table are passed in init
message between peers, hence the purpose for keeping them in separate
tables is not clear. One possible reasoning I could come up with was
that one gives peer information that is non-negotiable and other gives
peer information that is negotiated. But then this rule does not hold
true for all entries. Please clarify.

7.mplsLdpSessionEntry: This is indexed by 3 parameters
 INDEX       { mplsLdpEntityLdpId,
                       mplsLdpEntityIndex,
                       mplsLdpPeerLdpId
                     }
What is the requirement of having mplsLDPEntityIndex here? There has
been discussion on this topic before and I am not clear on the
resolution. Please clarify my doubts. What I understood from the LDP
draft was that one LDP session is uniquely identified by local and
remote LDPId, hence a third index should not be required. Please explain
the scenario in which this may be required.

8. mplsLdpFailedInitSessionThresholdExceeded NOTIFICATION-TYPE: has a
typo in description.
""This notification is generated when the value of
             the 'mplsLdpEntityPVLimitMismatchTrapEnable' object.."

9. mplsLdpSessionUp and mplsLdpSessionDown two notification types are
redundant. Only one is required. This notification gives the session
state and 'operational' indicates session up and any other state
indicates session down. Hence only one notification need be generated
when the state moved to / from operational.

Thanks and regards
Jhilmil

Vijay Srinivasan wrote:

> Definitions of Managed Objects for the Multiprotocol Label Switching,
> Label Distribution Protocol (LDP)
> Last call will end on Friday, March 17.  Please send your comments to
> the list.
>
> Regards,
> - Vijay

--

------------------------------
Jhilmil Kochar
Ficon Technology
E-mail:[email-masked]
Web: www.ficon-tech.com

---

From: Hans Sjöstrand <[email-masked]>
Date: Thu, 16 Mar 2000 14:47:43 +0100

Hi Jhilmil, 

Thanks for the help, some comments inline. 

> The VPI should be represented by 12 bits rather than 8 bits.

Agree. and the reference 3 should be the LDP spec instead of the ATM. 
this comments applies to the LSR MIB aswell. 

> mplsLdpEntityMaxPduLength, mplsLdpEntityKeepAliveHoldtimer.

Agree in principle. It however only DiscoveryPort that is specified 
in other specs. 
mplsLdpEntityWellKnownDiscoveryPort = 646

Max PDU lenth is really implementation specific. But I see no reason to
have any other default value than maximum? 

mplsLdpEntityMaxPduLength = 65535 ?

We could have one for the Keep alive also. But I couldn't find any 
reference in any other spec. I have a vague memory of seing 40 sec 
in a older version of specs (or maybe TDP). Could we use 40 sec?
mplsLdpEntityKeepAliveHoldtimer = 40 ?

> connections? That does not seem to be covered. Am I missing something?

No, it seams resonable to add that. I see (maybe academic) need f having 
these possible to be set independantly. Could add
mplsLdpEntityWellKnownTcpConnectionPort with 646 as default

> mplsLdpEntityAdminStatus is redundant and can be removed.

This was discussed on the list, adn I'm not sure of the outcome. My
private opinion is that fideling with rowStatus should be avoided to
acheive a 
admState like behaivoir. I think the resolution was to clarify the
description. correct Joan? 

> incorrect syntax. seventeenDlciBits is missing from the same.

This wasa change in 05 due to comments, see the changes section:
   The following items were changed as a result of the Frame Relay Forum
   dropping support for 17-bit DLCIs:  the MplsLabel TC description has
   been modified, and other Frame Relay Object descriptions were also
   modified (as specified in this section).
> the scenario in which this may be required.

This has been debated in length on the list and offline before. I have
to revisit soem of the emails to find the conclusions to that. 

>              the 'mplsLdpEntityPVLimitMismatchTrapEnable' object.."

To be fixed

> when the state moved to / from operational.

A modelling choise simply. Some management systems like different traps
for different events. Could be done either way.   

> > Last call will end on Friday, March 17.  Please send your comments to

regards
/// Hasse

---

From: Jhilmil Kochar <[email-masked]>
Date: Tue, 21 Mar 2000 13:02:55 +0530

Hi Hans,

> mplsLdpEntityMaxPduLength = 65535 ?

LDP draft sec 3.1
"Prior to completion of the negotiation the maximum
     allowable length is 4096 bytes."
and sec 3.5.3
"A value of 255 or less
         specifies the default maximum length of 4096 octets."
Shouldn't the default value by 4096?

regards
Jhilmil
--

---

From: Hans Sjöstrand <[email-masked]>
Date: Tue, 21 Mar 2000 16:05:16 +0100

> Shouldn't the default value by 4096?

That is the value mentioned if you study the LDP spec. That is a value
that should be considered safe for all implementations, i.e low value. 

The value that is set to default in the mib is going to be the initial
value for the negotiation. And that negotiation can only take the value
down, so it should be a high value. 

thats the reasoning behind
> > have any other default value than maximum?

On the other hand, what LDP PDU is bigger than 4096? Not many. And TCP
will handle the fragmentation. So I could go for 4096 if you could give
a reason?

regards
/// Hasse

---

From: "Sumit Garg" <[email-masked]>
Date: Tue, 21 Mar 2000 14:02:07 -0800

Hi Hans,

> will handle the fragmentation. So I could go for 4096 if you

Well, if I recall the draft correctly - one LDP PDU can be
multiple LDP messages; so I see the 4096 limit being hit easily
...

Regards
Sumit