The MPLS WG Archive

["Shevenell, Michael (Mike)" <mshev@aprisma.com>]

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