The MPLS WG Archive

["Natale, Robert C (Bob)" <bnatale@lucent.com>]

Hi Mike,

I might taken this too far in the direction of issues
for the "MIBs list" rather than this list...if so, let
me know.

Speaking w/o reference to any particular instance of anything:

   1. A given MIB design may be less efficient than
      it could be, overall or wrt specific managed
      objects.  That's true.

   2. A given implementation of a MIB (aka, an agent)
      may be less efficient than it could be, overall
      or wrt specific managed objects and/or specific
      management operations.  That's true much more
      frequently than #1 (in my judgment).

   3. A given management application may be more or
      less efficient in its use of a MIB and/or SNMP,
      and/or may offer a UI that limits (or drives)
      its users to inefficient use of the tool.  This
      is very frequently true, although there are
      notable examples of well-designed SNMP management
      applications too (and maybe a growing number of
      them).

   4. As Adrian pointed out, even where all of the
      above factors may be highly efficient, external
      factors may impair perceived performance.

While we would need to apply standard experimental
controls to determine the cause of poor performance
in a given case, I believe there is a prima facie
case for saying that #2 and #3 are often the source
of inefficient performance where SNMP and/or MIBs are
(mistakenly) identified as the cause.

Be that as it may, of course, I am all in favor of
better designed MIBs and, more importantly (IMHO),
MIBs that expose higher-order management capabilities
to applications.  The downside of that preference is
that agent implementation will become even more
critical.

Cheers,

BobN

-----Original Message-----
From: Shevenell, Michael (Mike) [mailto:mshev@aprisma.com]
Sent: Thursday, June 12, 2003 1:18 PM

Hi Adrian,
  In our experience the getnext performance is 
beyond slow. In some cases the response to the 
first getnext doesn't return even after several
minutes (with the CPU at 100%). My understanding
from following parts of this discussion was that 
the poor performance was due to the indexing mechanism 
in previous versions of the LSR MIB. So I'm in favor of "something" which
would make the reading feasible in our situation. Draft 10 proposed an
approach to improving 
this so I'm interested.
  I can't personally comment on the comparison to ATM...
	Mike

-----Original Message-----
From: Adrian Farrel [mailto:afarrel@movaz.com]
Sent: Thursday, June 12, 2003 12:29 PM
To: Shevenell, Michael (Mike)
Cc: 'mpls@uu.net'
Subject: Re: prequeal to WG lat call om the LSR mib
module[mplsInSegmentTable]


Hi Mike,

> As a provider of management solutions... We'd "prefer"
> to have a simple solution but we MUST have a working
> solution. Although the proposed change makes the
> instancing a bit more complex, the getnext performance
> of the current mplsXCTable is so slow that its practically
> unreadable in any reasonably sized network.

Not sure what you're saying here with regard to the getnext performance.

It is of the nature of a complex network (or more precisely, a busy switch)
that
it has a lot of cross-connect information. You want to read all of the
information, but there is a lot of information.

It would, presumably, be possible to aggregate the information so that it
can be
read in one block not row by row. Is this what you're talking about?

How does this compare with your experience of using MIB modules to manage
ATM
equipment?

Adrian