The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Jun> msg00113



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

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

  • From: "Thomas D. Nadeau" <tnadeau@cisco.com>
  • Date: Wed, 18 Jun 2003 14:03:33 -0400
  • Cc: "'Lai, Wai S \(Waisum\), ALABS'" <wlai@att.com>, "'Chung, Li-Jin W, ALABS'" <lic@att.com>, <ppvpn@nortelnetworks.com>, "'Van der Linde, Harmen, ALABS'" <hvdl@att.com>
  • Importance: Normal
  • Organization: Cisco Systems


	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


> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] 
> 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; ppvpn@nortelnetworks.com
> 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
> 
> -----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:loa@pi.se]
> 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 <loa@pi.se>
> To: MPLS WG <mpls@UU.NET>
> CC: Loa Andersson <loa@pi.se>, Bert Wijnen <bwijnen@lucent.com>, Alex 
> Zinin <zinin@psg.com>
> 
> 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.
> 
> 
>