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

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Wed, 18 Jun 2003 12:42:33 -0500

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

-----Original Message-----
From: Lai, Wai S (Waisum), ALABS 
Sent: Thursday, June 12, 2003 2:52 PM
To: Loa Andersson; MPLS WG
Cc: Chung, Li-Jin W, ALABS; Ash, Gerald R (Jerry), ALABS
Subject: RE: WG last call on LSR and LDP MIB modules - setting dates

I would like to bring to your attention, once again, the requirements in
http://ietf.org/internet-drafts/draft-lai-mpls-mib-rqmts-00.txt

For the LDP and possibly the LSR MIBs, requirements are specified in the above I-D, which include, for example, requirements for performance and fault management so as to lessen dependence on the NMS.  Such capabilities should be considered based on the requirements, and if appropriate, should be included in the appropriate MIBs.

Thanks, Wai Sum

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Thursday, June 12, 2003 4:24 AM
To: MPLS WG
Subject: WG last call on LSR and LDP MIB modules - setting dates

Folks,

the time for this wg call has been extended to June 24th noon CET.

/Loa

-------- Original Message --------
Subject: Re: WG last call on LSR and LDP MIB modules - CORRECTION!
Date: Tue, 10 Jun 2003 08:12:00 +0200
From: Loa Andersson <[email-masked]>
To: MPLS WG <[email-masked]>
CC: Loa Andersson <[email-masked]>, Bert Wijnen <[email-masked]>, Alex 
Zinin <[email-masked]>

All,

a misunderstanding between me and the authors resulted in that the
wrong version of the LDP mib module was sent to this wg last call.

The correct version is

<draft-ietf-mpls-ldp-mib-11.txt>

this has just been sent for publication (and with a copy to the
mailing list).

My take is that we continue the wg last call as planned, but as
soon as I see the LDP mib being published I will extend the last
call period. This way will get both a head start and the required
period of time.

/Loa

Loa Andersson wrote:

 > All,
 >
 > this is to initiate a two week wg last call on
 >
 >         Multiprotocol Label Switching (MPLS) Label Switching
 >         Router (LSR) Management Information Base
 >         <draft-ietf-mpls-lsr-mib-10.txt>
 >
 > and
 >         Definitions of Managed Objects for the Multiprotocol Label
 >         Switching, Label Distribution Protocol (LDP)
 >         <draft-ietf-mpls-ldp-mib-10.txt>
 >
 > this wg last call ends June 22nd, and is limited to the changes in the
 > IDs since the previous wg last call, as well as interdependencies between
 > the two mib modules and the mib modules listed below.
 >
 > For the LSR MIB please re-read the mail I sent to the list June 6 called
 > "prequeal to WG last call on the LSR mib module"
 >
 > A usual silence will be understood as support, but this would not
 > necessarily stop you from giving positive comments. Please do.
 >
 > There are more MIB modules coming up for wg last call and that have been
 > through wg last call, all of those will have interdependencies.
 >
 > 1. the TC mib module are wg last called and updated, but waiting for the
 >    others to be ready for IESG review
 >    <draft-ietf-mpls-tc-mib-07.txt>
 > 2. the TE link MIB module is in wg last call (to end June 13)
 >    <draft-ietf-mpls-telink-mib-02.txt>
 > 3. the management overview has been through wg last call and has been
 >    updated
 >    <draft-ietf-mpls-mgmt-overview-05.txt>
 >
 > Two other MIB modules are in the pipe and new version will be released
 > shortly
 >
 > 5. The TE mib module  <draft-ietf-mpls-te-mib-nn.txt>
 > 6. The FTN mib module <draft-ietf-mpls-ftn-mib-nn.txt>
 >
 > It is important that we complete this process of reviewing and updating
 > before the ID cut off date (June 30) for the Vienna meeting.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 18 Jun 2003 14:03:33 -0400

Jerry,

	I do fully agree with Harmen's statement
that the MIBs need to be wrapped up ASAP and
appreciate his feedback as an operator.  I think
that we are well on this track.

	To address your statement about requirements,
as discussed previously offline with yourself
and the MIB co-authors, many of the requirements
you listed below require changes to the LDP protocol 
itself. Given this, I suggest that you consult with 
other SPs in the WG on these requirements to make sure 
that they are consistent. I personally have not been hearing 
any of these requirements from other SPs that participate
in the MPLS WG.  In addition, I suggest that you 
direct your requirements to the authors of the LDP 
specifications and propose extensions/additions there 
first because the MIBs cannot manage what the protocols
will not provide. The remaining requirements you listed 
below apply specifically to the PPVPN-MPLS-VPN MIB and not
to the base MPLS MIBs which are in WG last call presently.

	--Tom

> 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]
> 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. 
> 
> 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."
> 
> For the LDP and possibly the LSR MIBs, requirements are 
> specified in the above I-D, which include, for example, 
> requirements for performance and fault management so as to 
> lessen dependence on the NMS.  Such capabilities should be 
> considered based on the requirements, and if appropriate, 
> should be included in the appropriate MIBs.
> 
> Thanks, Wai Sum
> 
> a misunderstanding between me and the authors resulted in 
> that the wrong version of the LDP mib module was sent to this 
> wg last call.
> 
> The correct version is
> 
> this has just been sent for publication (and with a copy to 
> the mailing list).
> 
> My take is that we continue the wg last call as planned, but 
> as soon as I see the LDP mib being published I will extend 
> the last call period. This way will get both a head start and 
> the required period of time.
> 
> /Loa
> 
> Loa Andersson wrote:
> 
>  > All,
>  >
>  > this wg last call ends June 22nd, and is limited to the 
> changes in the  > IDs since the previous wg last call, as 
> well as interdependencies between  > the two mib modules and 
> the mib modules listed below.  >  > For the LSR MIB please 
> re-read the mail I sent to the list June 6 called  > 
> "prequeal to WG last call on the LSR mib module"  >  > A 
> usual silence will be understood as support, but this would 
> not  > necessarily stop you from giving positive comments. 
> Please do.  >  > There are more MIB modules coming up for wg 
> last call and that have been  > through wg last call, all of 
> those will have interdependencies.  >  > 1. the TC mib module 
> are wg last called and updated, but waiting for the
>  > Two other MIB modules are in the pipe and new version will 
> be released  > shortly  >  > 5. The TE mib module  
> <draft-ietf-mpls-te-mib-nn.txt>  > 6. The FTN mib module 
> <draft-ietf-mpls-ftn-mib-nn.txt>  >  > It is important that 
> we complete this process of reviewing and updating  > before 
> the ID cut off date (June 30) for the Vienna meeting.
> 
> 
>

---

From: [email-masked]
Date: Thu, 19 Jun 2003 08:36:52 -0400

>that we are well on this track.

Agreed.

>will not provide. The remaining requirements you listed 

My read of the draft is that the authors are indeed requesting 
changes to the LDP protocol.  One example is the
discussion on sessions being enabled/disabled.  As Tom points out, 
this is not in the MIB because it is not in the protocol.

Additionally, there are several claims made about the NMS but
these are not given in any context.  For example, 
is not clear how many nodes are on the network, how many nodes an NMS 
is monitoring, if an out-of-band management network is being 
used, what other MIBs are supported on the device
and being polled for by the NMS? etc.  
Context would be helpful to better understand what the problem
is that is trying to be solved.  Why does the NMS have problems
with the LDP-MIB and not with the polling for other MIBs?  That
does not make sense to me.  

A question was made privately to one of the authors at the Atlanta IETF that
perhaps a MIB which stores LDP counter information in a history table
(such as is done in SONET) could be useful to them?  I did not receive
any response to this question.  So I am asking again, 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.   

 -Joan