Subject: RE: WG last call on LSR and LDP MIB modules - setting dates

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Fri, 20 Jun 2003 08:25:59 -0500

Joan,

> perhaps a MIB which stores LDP counter information in a 
> history table (such as is done in SONET) could be useful...
> why wouldn't a history table solve some of the issues?  
> If history tables would be thought useful, this could be 
> proposed to the working group in a separate MIB module, 
> but would be outside the scope of the present LDP-MIB.

Thanks for your suggestion.  I presume this is regarding requirements R1 and R2 below, correct?  If so, it does appear useful and we'd like to work with you to define details and progress.

Thanks,
Jerry

P.S. Correction to requirements below, R3 is a VPN requirements, not an LDP requirement.  

>> -----Original Message-----
>> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
>> Sent: Wednesday, June 18, 2003 1:43 PM
>> To: Wijnen, Bert (Bert); Loa Andersson; MPLS WG
>> Cc: Ash, Gerald R (Jerry), ALABS; Lai, Wai S (Waisum), ALABS; 
>> Chung, Li-Jin W, ALABS; [email-masked]
>> Subject: RE: WG last call on LSR and LDP MIB modules - setting dates
>> 
>> Bert, Loa, All,
>> 
>> I'd like to follow up on Wai Sum's comments below, and 
>> encourage that high-priority MPLS-MIB problems/requirements 
>> identified through extensive testing be addressed in the MPLS 
>> MIB modules.
>> 
>> The MPLS MIB problems/requirements are identified in 
>> http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.tx
>> t, and are critical operator requirements stemming from 
>> detailed lab testing by Li Chung and others at AT&T.  
>> MPLS-VPNs aren't going to operate as well as needed until and 
>> unless these requirements are met.  It is expected that 
>> operators wishing to use the same MPLS MIBs would have 
>> similar concerns.
>> 
>> The I-D does not propose specific MIB extensions based on the 
>> requirements.  Rather, such extensions are left to the MIB 
>> designers, in order to avoid past discussions of why specific 
>> extensions won't work.  But so far there is no help or 
>> response from MIB designers on how to meet the requirements, 
>> even though the problems have been identified on email lists 
>> for more than one year. 
>> 
>> Here is a summary of requirements (R1,R2,R3 LDP related; 
>> R4,R5 VPN related):
>> 
>> R1. It is required to capture the signaling usage/performance 
>> of the LDP Entities, as well as the traffic usage/performance 
>> of the LDP Sessions. 
>> R2. It is required to ensure persistency 
>> of information in the LDP-MIB Entity Table and Entity 
>> Statistics Table, whenever an LDP Entity is disabled and then 
>> re-enabled. 
>> R3. It is required that a count be reported of 
>> mplsNumVrfRouteMaxThreshExceeded notification when the 
>> operator-defined VRF maximum route threshold is exceeded. 
>> R4. It is required to have an explicit mapping between VRF, RD, 
>> and RT in the mplsVpnVrfRouteTargetTable table. 
>> R5. It is 
>> required to track the number of BGP prefixes on the PE-CE 
>> link, and that the BGP neighbor maximum-prefix limit on the 
>> PE-CE link be used to limit the number of eBGP routes 
>> injected in the VRF.
>> 
>> I agree with Harmen Van der Linde, "We need to get this MPLS 
>> MIB module, together with the MPLS LDP and MPLS VPN modules, 
>> standardized ASAP. There is a critical need for these MPLS 
>> MIB modules for management of MPLS-enabled networks, which 
>> are currently being deployed by many service providers."
>> 
>> Bert threatened at IETF-56 to start over on MPLS MIBs if not 
>> finished by IETF-57.
>> 
>> We need the MPLS MIB designers to meet critical requirements 
>> and complete ASAP.
>> 
>> Thanks,
>> Jerry