Subject: RE: Some comments on LDP MIB

From: Theimer Thomas <[email-masked]>
Date: Tue, 31 Aug 1999 10:27:57 +0200

Hasse,

	thanks for the clarification. Please find my replies embedded below.

	Regards, Thomas

	Hans Sjöstrand [SMTP:[email-masked]] wrote:
>  
> We are still working on an 02 of the mib, comments are always welcome.
> Answers on your issues are embedded below. 
> 
> Theimer Thomas wrote:
> > 
> > Page 11, MplsLdpEntityEntry
> > 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.
> 
> 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. 
> 
	[Theimer Thomas]  That is not sufficient for proper initialisation,
as the VPI values may be different on either endpoint if the LSRs are
indirectly connected through an ATM VP. Therefore, if two LSRs are
indirectly connected, they must ignore the VPI field upon reception, and
they should set the VPI to zero upon transmission of the initialisation
message. See also section 3.5.3. Initialization Message of the LDP spec:

       When peer LSRs are connected indirectly by means of an ATM VP,
       the sending LSR should set the Minimum and Maximum VPI fields to
       0, and the receiving LSR must ignore the Minimum and Maximum VPI
       fields.								   

> > 
> > 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.
> 
> 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?
	[Theimer Thomas]  Thanks for the clarification. I would really
suggest to modify this, as it completely destroys the effect of negotiation
with the peer. If these parameters need to be modified, this should be done
directly at the peer, not by changing the parameters originally received
from the peer.

---

From: "Hans Sj�strand" <[email-masked]>
Date: Tue, 31 Aug 1999 11:42:34 +0200

>        0, and the receiving LSR must ignore the Minimum and Maximum VPI

Must admit that I mised this one. Would something like this be
sufficient? 

     mplsLdpEntityPeerLsrConnectivity OBJECT-TYPE
         SYNTAX      INTEGER {
                         direct(1),
                         indirect(2)
                     }
         MAX-ACCESS  read-create
         STATUS      current
         DESCRIPTION
             "The peer LSR may be connected indirectly by means of an 
              ATM VP so that the VPI values may be different on either 
              endpoint."
         DEFVAL { direct }
         REFERENCE
             "draft-ietf-mpls-ldp-05.txt, Section 3.5.3"
         ::= { mplsLdpEntityEntry ? }

> directly at the peer, not by changing the parameters originally received

I do agree. This could defenetly be a source for incompatibility. 

regards
/// Hasse