The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Jun> msg00161



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

LDP-MIB & VPN-MIB

  • From: Joan Cucchiara <jcucchia@CrescentNetworks.com>
  • Date: Thu, 27 Jun 2002 20:48:59 -0400
  • CC: mpls@UU.NET, "Ash, Gerald R (Jerry), ALASO" <gash@att.com>, "Nguyen, Mai-Uyen T, ALCNS" <mtnguyen@att.com>, "D'Souza, Kevin L, ALCNS" <kld@att.com>, "Lai, Wai S (Waisum), ALASO" <wlai@att.com>
  • Organization: Crescent Networks


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.

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


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.


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