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

Joan,

> perhaps a MIB which stores LDP counter information in a=20
> history table (such as is done in SONET) could be useful...
> why wouldn't a history table solve some of the issues? =20
> If history tables would be thought useful, this could be=20
> proposed to the working group in a separate MIB module,=20
> 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. =20

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