Re: Call for censensus on path forward

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

>>>>> On Sat, 21 Sep 2002 20:18:34 +0900, Glenn Mansfield Keeni <[email protected]> said:

Glenn> So the question is, why do we need Aggregate MIBs ?

My view on Glenn's draft is that if small-sampling-period data
gathering is needed, then we need something "like" Glenn's MIB.
Defining new PDUs which are still subject to network transmission
delays will not help if micro-second sampling is needed.

I do not know if micro-sampling itself is needed, as I've never needed
it, but I can see cases where it might be useful.  It's likely to be a
chicken-and-egg problem as well, because it certainly won't be usable
until a solution is designed for it.

Now, my personal view of the MIB itself is that the goal is right, but
the particular data delivery mechanism is not what I would have
picked.  I would prefer to see data delivered via normal operations
(eg, a TRAP/INFORM or their replacements [note that I was intending to
put a replacement in my draft]) rather than compressed into an OCTET
STRING.  The notifications that went out would likely need contain
repeated instances of data, or else you'd have to handle micro-second
delivered INFORMs.  As an example, I think if you wanted to measure
something every 1ms you should then do so and then send out the
combined/conglomerate results every 1s in one large notification.

As far as archiving the data so that if the network was down and thus
the notification was unable to be successfully delivered, there are
two ways of solving this problem that already exist and I'm not sure
we need another one.  The first is that INFORMs typically allow the
notion of a retry, but that's not necessarily a solution people want
to use if the downtime is long.  However, we already have the
NOTIFICATION-LOG-MIB which is designed for archiving notifications for
later retrieval [although some people have found problems with it, it
doesn't mean we should abandon it for a new approach.  We should fix
any problems with it as it'll benefit more than just this single
problem-area].

So, if a need is demonstrated for fast-polling, then I do see
something "like" Glenn's MIB as being necessary.  Glenn is right in
the fact that it doesn't "conflict" with the other operation documents
on the table.  They'd likely work together.

-- 
Wes Hardaker
Network Associates Laboratories