Subject: Proposal for MPLS-VPN-MIB enhancements

From: "Lai, Wai S (Waisum), ALASO" <[email-masked]>
Date: Mon, 19 Aug 2002 17:16:26 -0400

I would like to propose the following enhancements for consideration in
draft-ietf-ppvpn-mpls-vpn-mib-04:

(1) Currently, there is the mplsNumVrfRouteMaxThreshExceeded
notification
when the VRF maximum route threshold is exceeded.  It is suggested to
add
a counter for the number of routes dropped due to such threshold being
exceeded.  The reporting of such a count is useful for capacity planning
and for threshold tunning purposes.

(2) In the mplsVpnVrfRouteTargetTable table, it appears that there is no
explicit mapping between the route targets (RT) and their associated
Route
Distinguisher (RD).  It is suggested to add such association between
VRF,
RD, and RT in this table.

Comments are welcome.
Thanks, Wai Sum.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 21 Aug 2002 13:35:34 -0400

>and for threshold tunning purposes.

         What practical purpose do you see in counting routes that are
not added beyond knowing that you have exceed that operator-defined
threshold?

>Route Distinguisher (RD).  It is suggested to add such association between
>VRF, RD, and RT in this table.

         What do you mean by an explicit mapping -- an index? The
current RouteTarget table contains the associated RD for each
RT entry:

MplsVpnVrfRouteTargetEntry ::= SEQUENCE {
      mplsVpnVrfRouteTargetIndex      Unsigned32,
      mplsVpnVrfRouteTargetType       INTEGER,
      mplsVpnVrfRouteTarget           MplsVpnRouteDistinguisher,
      mplsVpnVrfRouteTargetDescr      DisplayString,
      mplsVpnVrfRouteTargetRowStatus  RowStatus
    }

         --Tom

>Thanks, Wai Sum.

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.

---

From: "Van Der Linde, Harmen, ALCNS" <[email-masked]>
Date: Thu, 22 Aug 2002 11:39:51 -0400

Wai,

Regarding:

> I would like to propose the following enhancements for 
> consideration in draft-ietf-ppvpn-mpls-vpn-mib-04:
> 
> notification when the VRF maximum route threshold is exceeded.  
> It is suggested to add a counter for the number of routes dropped 
> due to such threshold being exceeded. The reporting of such a 
> count is useful for capacity planning and for threshold tunning purposes.

For capacity planning one would typically analyze resource usage 
statistics such as performance and utilization counts instead of
exception counts like nr of routes exceeded in this case.

Can you explain why, for traffic engineering purposes, you want 
to know about the nr of dropped VRF routes instead of simply
monitoring the actual nr of VRF routes? Maintaining the nr of
dropped VRF routes seems to be rather expensive in terms of
memory/implementation and I don't see how that can be justified.

Note that route-limit threshold values are usually set as a 
fixed percentage and are not derived from the nr of VRF routes
or nr of dropped VRF routes.

regards,

Harmen

---------------------------------------------------
 Harmen van der Linde
 AT&T - Frame Relay Network Mgnt Platform Planning 
 Room C2-3C34
 200 Laurel Ave
 Middletown, NJ 07748
 Work: 732-420-1916 
 Home: 732-706-2838
 Cell: 732-809-3007
---------------------------------------------------