The MPLS WG Archive

["Ash, Gerald R (Jerry), ALABS" <gash@att.com>]

Loa, All,

> I had to read back a bit to understand the impact of the input from
> Wai Sum and Jerry. The working group last call has ended but I would
> nevertheless like to make this comment:
> 
>   - the draft-lai-mpls-mib-rqmts-00.txt includes requirements that
>     will make changes to the LDP necessary

Loa, I'm surprised that you would just parrot this claim without technical backup.  This is merely an unsubstantiated assertion by 2 of the MPLS MIB authors, to deflect the requirements in yet one more creative way.  No response was made to Eric Gray's post requesting specifics to back this up http://cell.onecall.net/mhonarc/mpls/current/msg00130.html.

Various posts over the past year have requested specific MPLS MIB extensions to meet identified gaps (see below).  When the specifics were rejected, then a different approach was tried to request designers to propose enhancements to meet requirements http://cell.onecall.net/mhonarc/mpls/2003-May/msg00006.html, again without any forward motion.  

Despite all this effort to meet a few critical SP requirements, no attempt has been made to address the requirements or the specific MIB enhancement proposals:

Li Chung initially posted specific enhancements/needs to the MPLS list on June 27, 2002 http://cell.onecall.net/mhonarc/mpls/2002-Jun/msg00159.html.  Go back and review the thread, the specific extensions were not addressed.

Wai Sum Lai initially posted to the ppvpn list on August 19, 2002 (message attached below, ppvpn archives don't go back that far).  The specific extensions were not addressed, Tom requested and got substantiation of the needs, but that was the end of the discussion.

> - the LDP MIB is based on the current LDP spec, thus it is my take
>    that the draft is outside the scope of the current last call

No changes to the LDP spec are proposed or needed.  Therefore the requirements and proposed extensions, made for one year on the list, are well within the LDP MIB discussion window.  They merely haven't been seriously addressed.

>    the authors are advised to take these comments into consideration
>    only to the extent they don't involve changes that is not reflected
>    the current LDP version

Since none of the requirements propose (or intend) changes to the LDP spec, the authors of the LDP MIB should therefore take into full consideration all of the requirements.
 
> - on the other hand this discussion is within wg charter, and my
>    suggestion is we continue the discussion on the mailing list and
>    in Vienna to see if there is support for this draft.
> 
> - IF there is interest we adopt the requirement spec as wg doc,
>    and decide how we proceed with the extensions and changes necessary
>    in the base documents

The requirements spec is the latest attempt to get high-priority MPLS MIB requirements into the MPLS MIBs.  Again, these gaps/needs/requirements are based on extensive testing of MPLS MIBs by a large carrier with a very large MPLS deployment, wherein a quality implementation of these MIBs, and MPLS OAM in general, are absolutely required to meet critical operational needs going forward.

Jerry

> -----Original Message-----
> From: Lai, Wai S (Waisum), ALASO 
> Sent: Monday, August 19, 2002 5:16 PM
> To: ppvpn@ppvpn.francetelecom.com
> Subject: 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 tuning 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.