Subject: RE: LDP-MIB & VPN-MIB

From: "Chung, Li-Jin W, ALCNS" <[email-masked]>
Date: Tue, 2 Jul 2002 12:25:00 -0400

Joan,

Thank you for your feedback. Please see my comments below.

Thanks,

Li Chung

-----Original Message-----
From: Joan Cucchiara [mailto:[email-masked]]
Sent: Thursday, June 27, 2002 8:49 PM
To: Chung, Li-Jin W, ALCNS
Cc: [email-masked]; Ash, Gerald R (Jerry), ALASO; Nguyen, Mai-Uyen T,
ALCNS; D'Souza, Kevin L, ALCNS; Lai, Wai S (Waisum), ALASO
Subject: Re: LDP-MIB & VPN-MIB

Hello,

"Chung, Li-Jin W, ALCNS" wrote:
> 
> Hi.,
> 
> I am new to this list. So, if what I say here has been addressed by
other means please let me know.
> Recently, I have studied draft-ietf-mpls-ldp-mib-08 and
draft-ietf-ppvpn-mpls-vpn-mib-03 and have identified some potential
enhancement areas for our future considerations. I would like to get
your feedback if these areas of observations make sense to you.
> 
> In the LDP-MIB,
> (1) The variables in the following two notifications do not have the
information related to the IfIndex in the IF-MIB, this will prolong the
proactive fault management cycle time for operators.
> 1. mplsLdpSessionUp &
> 2. mplsLdpSessionDown
> 
> I would like to suggest to include "mplsLdpConfGenericIfIndexOrZero"
or equivalent of such variable in the notification object.

The mplsLdpEntityLdpId, mplsLdpEntityIndex, and mplsLdpPeerLdpId
(which are included) would give an operator a clear indication of which
port.  Operators would be creating Entities on each LSR and 
assign the LDP Identifiers, so in this specific case they would
have created the Entity (and assigned the mplsLdpEntityLdpId) and the
Peer (and assigned the mplsLdpPeerLdpId), so they should have the info
needed.

*	from Li: 
*	A few observations of your suggestions: 
*	(1) The above suggested variables are not in the notification
spec. today. So, you and I would agree that some more variables need to
be added to the notification. 
*	(2) If there are multiple L2 interfaces between two peers that
running LDP, we need to know which physical interface that causes the
LDP session down/up trap.  The above three variables does not provide
specific physical interface information. The logical interface
information is useful but they are more difficult for the operator to
perform troubleshooting.
*	(3)  Based on the description/definition of the above variables,
none of them has any indication of association with IfIndex in the
If-MIB. And, IfIndex in the If-MIB will be one object which could
provide the mapping between the Physical Interface and logical interface
of LDP entity. That is why I would suggest to add IfIndex/IfDescr
variable in the notification message. 
> 
> (2)  There is no specification on how to retain the counters when an
LDP-entity/session is broken and then reestablished again. Because of
such, some implemenation will remove the entire entry statistics when an
LDP-session is broken and when the same session is re-established again
the counter will be treated as a new counter. Some accumulation of such
old and new counters need to be specified.

There are 2 tables of counters.  

The first table of counters, mplsLdpEntityStatsTable, contain counters
of an Entity because these are counters which are received when a
session
is attempted/initializing.  These counters will help determine whether
or not the
session ever gets established.  These counters do not have a
discontinuity
time associated with them because seeing these is an indication that the
Session is not being established.  So, in other words, if you see these
counters increasing, that could be an indication that something is
misconfigured
with the corresponding Entity.  If you don't see a Session being
established on
this entity, then these counters are meant to help figure out why.

	from Li:
*	How? One possible implementation of such MIB (since one vendor
implement such way) is that when a session is established then went
down, all records related to this "down" session are removed. These
include: all objects in the mplsLdpEntityStatsTable as well as all
objects in the mplsLdpSesStatsTable are removed from the statistics.
When the same session is re-established again, it assigns to another
session number (the next session number in sequence), so from the
session number perspective in the LDP-MIB report, it is a brand new
session and has no knowledge/linkage that this new session number is
associated with an OLD session number. So, your suggestion of the above
"help figure out why" does not really work in such implementation. I am
looking for a way in the MIB to insure such linkage is guaranteed.
Otherwise, the above two statistics table does not provide meaningful
information from my perspective. 
*	A suggested linkage is to add IfIndex on top of the Peering
entry in the session index. So it will provide a more "solid" mapping
relationship.
*	Another suggestion is to find a way not to remove the OLD
session statistics when a session goes down so we are able to "figure
out why".

The second table of counters, mplsLdpSesStatsTable, contain
counters on a session.  These counters may have a discontinuity (i.e.
session up/down)
but that is noted in the mplsLdpSesDiscontinuityTime object which
corresponds to the entry.
*	 from Li:
*	Please see my comment above.

Li Chung

Hope that help,
  -Joan

> 
> In the VPN-MIB,
> 
> (1) Although there is a notification  of  VRF maximum route threshold
exceeded, there is no counter of number of routes dropped due to such
threshold exceeds. I would like to suggest to add a counter of such
dropped routes for capacity planning and for threshold tunning.
> 
> (2) From what I can tell, in the route target table, there is no
mapping for the associated RD. I would like to suggest to add such
association between VRF, RD and RT in the RT table.
> 
> Please let me know if you have any comments.
> 
> Thanks,
> 
> Li Chung

---

From: Joan Cucchiara <[email-masked]>
Date: Tue, 02 Jul 2002 21:24:33 -0400

Hi,

> be added to the notification.

Since these are indices (mplsLdpEntityLdpId, mplsLdpEntityIndex and
mplsLdpPeerId) these are part of the varbind and are available in the
notification.  

> variable in the notification message.

For the points 2 and 3 above, you are asking for the ifIndex then of the
phy layer, is that correct?

This information should already be at the NMS (assuming the NMS is
monitoring the device), so why does it need to be included in the
notification?  In other words, there is the age-old tradeoff between
the agent doing this work or the NMS doing it.  (In my opinion this
is a discussion for the mibs email list -- rather than the MPLS email
list).

> information from my perspective.

I don't understand what you mean by "removed". 

An Entity contains all the config info for a session.
The peer table represents the peer to that session and the session
table gives you the state and other relevant info learned as the 
session is negotiated and established.

The counters in the mplsLdpEntityStatsTable are errors which denote
that the Entity might be misconfigured because the Peer and Entity
aren't able to establish the session (at this point there might NOT
be any entry in the mplsLdpSessionTable for the session.)

Once the session is able to be established (and appears in the
mplsLdpSessionTable, a corresponding entry will also appear in the
mplsLdpSesStatsTable
(note the AUGMENTS relationship).  These counters are tied to the
discontinuity object which is updated when the session is interrupted
(e.g. goes down).

This was modeled somewhat after the ifDiscontinuity object in the
IF-MIB.

> entry in the session index. So it will provide a more "solid" mapping

Which IfIndex?  (What is the ifType that this ifIndex corresponds to?)

> *       Please see my comment above.

If you are asking about having a sort of history table, that would
be one way to accomplish what you want, but am not sure this is 
very meaningful.  At any rate, it is outside the scope of the
LDP MIB.  Although, could certainly be added in subsequent document/MIB
module.

-thanks, 
Joan