Subject: RE: Proposal for MPLS-VPN-MIB enhancements

From: "Lai, Wai S (Waisum), ALASO" <[email-masked]>
Date: Wed, 13 Nov 2002 18:51:30 -0500

Tom,

   Regarding (1) about the practical use of the dropped-route count,
here are some examples:
1. Engineering of the routing table - to properly tune its size via
   the max threshold.
2. Understanding of customer demand for prefix routes - increase in
   demand could be due to growth of the business, or re-homing.
   Re-engineering effort might be needed if this is the case.
3. Trouble shooting and understanding the customer service impact -
   customer might inject too many routes due to provisioning errors. 
4. Router resource management to optimize router performance - the
   overflow counts can be summerized at the per router level for
   forcasting and capacity planning.

   Regarding (2) about VRF/RD/RT association, the proposal is to
associate RT with the RD index and not the VRF name index.
Currently, the mplsVpnVrfRouteTargetTable table is key on the VRF
name, but one VRF name could have two or more RD number assigned to it.
Also, while the mplsVpnRouteTarget uses the same format as the
mplsVpnRouteDistinguisher, it does not provide the RD index.
An explicit association between RT and RD is needed.

   In this connection, I believe that some clarification of the
example in "Defining the VPN," page 8, is needed.  Clearly, the
first "100:1" in mplsVpnVrfTable is the RD number.  However, the
second "100:1" in mplsVpnVrfRouteTargetTable should be the RT number
and not RD number, am I correct?  If this is the case, then giving
the same number to RD and RT may cause ambiguity in the example.

Thanks, Wai Sum.

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Wednesday, August 21, 2002 1:36 PM
To: Lai, Wai S (Waisum), ALASO
Cc: [email-masked]
Subject: Re: Proposal for MPLS-VPN-MIB enhancements

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

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

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

         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

>Comments are welcome.
>Thanks, Wai Sum.

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