The MPLS WG Archive

["Chung, Li-Jin W, ALCNS" <lic@att.com>]

Joan,

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

Thanks,

Li Chung

-----Original Message-----
From: Joan Cucchiara [mailto:jcucchia@CrescentNetworks.com]
Sent: Thursday, June 27, 2002 8:49 PM
To: Chung, Li-Jin W, ALCNS
Cc: mpls@UU.NET; 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