Subject: RE: LDP MIB last call

From: Joan Cucchiara <[email-masked]>
Date: Thu, 16 Mar 2000 10:13:55 -0500

> -----Original Message-----
> From: Hans Sjöstrand [mailto:[email-masked]]
> Sent: Thursday, March 16, 2000 8:48 AM
> To: Jhilmil Kochar
> Cc: [email-masked]'; [email-masked]
> Subject: Re: LDP MIB last call
> 
> 
> Hi Jhilmil, 
> 
> Thanks for the help, some comments inline. 
> 
> Jhilmil Kochar wrote:
> > 
> > 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.
> 
> Agree. and the reference 3 should be the LDP spec instead of the ATM. 
> this comments applies to the LSR MIB aswell. 
> 
> > 
> > 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.
> 
> 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 ?
> 
> > 
> > 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?
> 
> 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
> 
> > 
> > 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.
> 
> 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? 

From my recollection the thinking was that there are different levels
of user access which could be done if both objects were kept.

For example, a user which is allowed to set RowStatus (and AdminStatus)
versus a user that is allowed only to set AdminStatus.

AdminStatus has a subset of the functionality which RowStatus does.

We could add more text to describe this.

> 
> > 
> > 5. mplsLdpEntityFrameRelayParmsEntry: object mplsLdpEntityFrLen has
> > 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).
> > 
> > 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.

The split between the two tables were for values used in
an active Session, versus values which were ignored by the
session (although a session is still created).  

The objects in the EntityPeer Table are related
to PathVectorLimit and are used to generate a trap if a
mismatch occurs.  The Session uses the PathVector value which
is in the Entity Table if there is a mismatch between the
two values.

We probably should add more text here then, if this is
not clear.

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

We were asked to add this because some companies wanted it.
Your implementation may not actually use this, but still it
needs to be supported.  This is a standard MIB afterall and
so needs to accomodate as many folks as possible.

Not having it would mean that others could not implement the
LDP MIB, whereas if your implementation does not need it, supporting
it does not limit your implementation other than the overhead.

As Hans said this has been discussed on the list quite a bit in
about the June/July/August time frame.  Most notably the Minutes
of the Oslo meeting.

One company which is doing MPLS using PPP for example, expressed that
they needed mplsLdpEntityIndex.  

Hope that helps, and thanks for the feedback.

 -Joan

> 
> > 
> > 8. mplsLdpFailedInitSessionThresholdExceeded 
> NOTIFICATION-TYPE: has a
> > typo in description.
> > ""This notification is generated when the value of
> >              the 'mplsLdpEntityPVLimitMismatchTrapEnable' object.."
> 
> To be fixed
> 
> > 
> > 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.
> 
> A modelling choise simply. Some management systems like 
> different traps
> for different events. Could be done either way.   
> 
> > 
> > Thanks and regards
> > Jhilmil
> > 
> > Vijay Srinivasan wrote:
> > 
> > >
> > >
> > > 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
> > 
> > --
> > 
> > ------------------------------
> > Jhilmil Kochar
> > Ficon Technology
> > E-mail:[email-masked]
> > Web: www.ficon-tech.com
> 
> regards
> /// Hasse
>

---

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

Hi Joan,

> We probably should add more text here then, if this is

More text would be helpful. Does this mean there there will always be a
one-one mapping beween a Peer entry and a session entry? ie one LDP Peer can
have only one session with the entity? The indexing for both is the same,
but the draft does not explicitly mention this.

Thanks and regards
Jhilmil

--