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

Tom,

> the MIBs need to be wrapped up ASAP and ...
> we are well on this track.

Good, hopefully by IETF-57, in order to avoid 'sending them to the =
dust-bin' as Bert has suggested.

> To address your statement about requirements,
> as discussed previously offline with yourself
> and the MIB co-authors,=20

There is about a one-year history/archive of posts to the lists =
regarding these requirements.

> many of the requirements you listed below require=20
> changes to the LDP protocol itself.=20

Which of the 3 LDP requirements constitute 'many' that need LDP changes? =
=20

Obviously we're not proposing LDP protocol changes.  Also, the =
requirements I-D does not propose specific MIB extensions, *in order to =
avoid past discussions of why specific extensions won't work*.  Step-1 =
is to make sure the requirements are understood, and then step-2 is to =
decide how to meet them. =20

Joan has suggested (I believe for requirements R1 and R2) 'a MIB which =
stores LDP counter information in a history table'.  That's a step-2 in =
the right direction.  Furthermore, Adrian has suggested that 'instances =
of entities' is a concept that has been handled in MIBs before and could =
be added in an optional way so that implementations did not have to =
maintain persistent information, but can choose to.

As to R3, it should be clear, a MIB should be straightforward.
=20
> I suggest that you consult with=20
> other SPs in the WG on these requirements to make sure=20
> that they are consistent. I personally have not been hearing=20
> any of these requirements from other SPs that participate
> in the MPLS WG. =20

So that signifies the death-knell pronouncement from the self-appointed =
OAM/MIB-czar?  Perhaps the famous 25 pro-VCCV SPs you often quote (but =
who never speak for themselves) can attest to the MPLS-MIBs =
perfection/no-more-requirements-needed?

There has been no opposition to the requirements R1-R5 we've been =
stating for a long time (except, consistently, from you). =20

> I suggest that you direct your requirements to the=20
> authors of the LDP specifications and propose=20
> extensions/additions there first because the MIBs=20
> cannot manage what the protocols will not provide.=20

We're not proposing any changes to LDP.  As above, Joan is suggesting =
approaches to R1 & R2.  R3 clearly requires no protocol changes.

> The remaining requirements you listed=20
> below apply specifically to the PPVPN-MPLS-VPN MIB and not
> to the base MPLS MIBs which are in WG last call presently.

R3 and R4 need to be addressed, have been there a long time, and do not =
have to wait until last call to be discussed/progressed.

Jerry

> -----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
>=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.txt,=20
> 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. 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. R3. It is required that a count be reported of=20
> mplsNumVrfRouteMaxThreshExceeded notification when the=20
> operator-defined VRF maximum route threshold is exceeded. R4.=20
> It is required to have an explicit mapping between VRF, RD,=20
> and RT in the mplsVpnVrfRouteTargetTable table. 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