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

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Thu, 19 Jun 2003 12:56:17 -0500

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, 

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

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

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

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.  

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

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).  

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

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 19 Jun 2003 14:34:02 -0400

> Which of the 3 LDP requirements constitute 'many' that need 

	All of the requirements you listed below with
the exception of the ones pertaining to VPN.

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

	Of course you aren't proposing specific changes to
anything. What we are saying is that is what you need to 
do in order to accomplish what you want in this case. The
LDP MIB is not a place for redefining how LDP works. 

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

	This is not something that should go into the existing
LDP MIB because the LDP protocol does not support the
counters/concepts required to count these things regardless
of what has been suggested. If you look at the specific details 
of what is being proposed in the draft (which I and others have 
done numerous times now) they CANNOT be achieved with 
the current standard LDP.

> 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).  
	
	I have not read any emails that claimed support for 
or acknowledged these requirements either.

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

	So then go ahead and propose a MIB based on those
changes. There is nothing preventing you or anyone else
on the co-author list of the draft in question from doing 
this.

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

	And these will be addressed in the PPVPN MPLS VPN MIB 
when Harmen and I get around to editing the MIB, assuming there
is consensus to make these additions. And as you can see, I 
have been a little busy with the base MIBs for the last 
few months. *)

	--Apparently self-appointed OAM/MIB-czar

---

From: Eric Gray <[email-masked]>
Date: Fri, 20 Jun 2003 13:47:52 -0400

Tom and others,

    This discussion seems skewed a bit because of different perspectives that people
are speaking from.

    First of all, it is not the case that a protocol specification must necessarily define
counters and knobs for every detail of how the protocol should be managed. It is
often the case that people would prefer this to be the case, however, requiring it to
be the case would be a sure fire way to delay specification of protocol standards
well beyond some window of utility for a standard - meaning that placing too many
barriers in the way of defining standards leads to de facto standards.

    For example, in this discussion, what exactly is it that LDP _should_ have defined
to support the requirements that Jerry points out?  I do not think that the protocol
should be involved in the business of keeping track of the enabled status of potential
protocol peers - it should be sufficient from a protocol perspective to know whether a
protocol peer is currently visible.

    Also, the protocol specification should not specify what happens to protocol
management data (counters and knobs) during the period in which the protocol
itself is not active - except to the extent that proper protocol behavior absolutely
depends on such specification.

    My sense is that it is perfectly within the purview of a management specification
to make statements about this kind of behavior as long as such statements are not
actually incompatible with underlying protocol specifications. It would then be up
to implementers to determine whether or not their implementation supports these
capabilities.

    And it is equally reasonable to assert that specifying required behaviors may
be the task of some subsequent management specification. In the same way that
requiring full manageability of a protocol can unnecessarily delay the protocol
specification process, requiring complete satisfaction of evolving management
requirements in current management specifications can unnecessarily delay the
management specification process.

    My 2 cents worth...

--
Eric Gray

---

From: [email-masked]
Date: Sat, 28 Jun 2003 15:45:50 -0400

Hi Eric,

>barriers in the way of defining standards leads to de facto standards.

I would have to agree with this sentiment.  One aspect of the LDP
Specification
was the use of TLVs.  Using TLVs and defining them so clearly, made writing
the LDP-MIB straightforward.  Many of the objects come directly from
the TLVs.  Also, this approach allows the protocol to be extensible which is
also good.  As new TLVs are added, so to can new MIB Module(s).

>protocol peer is currently visible.

And this is reflected in the mplsLdpPeerTable of the LDP-MIB.  Additionally, 
an NMS (SNMP Manager) can display an LPD Session-based topology by querying 
each Agent/LSR and then each Peer to build up such a topology.

>to implementers to determine whether or not their implementation supports
these

Agreed.

>management specification process.

Very astute statements above.  In point of fact, the LDP-MIB's one and only
goal is to support the LDP Specification.  4 years, and 4 MIB Modules 
later (not to mention draft-ietf-mpls-tc-mib-07.txt) and several MIB doctor
reviews and 3 working group last calls later,  I believe that it does this.   
Adding additional requirements would indeed delay this MIB, or worse, 
cause it to be put in the dustbin.   

MIBs, by their nature, are added to in the form of MIB Modules, and
that can certainly be done with additional requirements.  

  -Joan