Subject: Re: <draft-ietf-disman-remops-mib-03.txt>

From: [email-masked]
Date: Mon, 22 Feb 1999 10:51:29 -0500 (EST)

>> Specifically, it seems impossible to configure the current ping MIB to
>> periodically ping specified IP addresses and report when the ping fails.
>
>I get the impression that you are thinking of launching a recurring,
>periodic ping to watch for disconnects.

Yup.  That's exactly what I would like to do.

>If you do, please do it very carefully -- I have this mental image of
>hundreds, thousands, millions of such devices all pinging all over the
>network and wasting bandwith, burning router cycles, and clogging exchange
>points with ICMP echo messages.

Yes, overloading the internet with periodic pings produced by devices that 
implement the ping MIB is indeed possible.  But overloading the internet 
with periodic pings produced by the UNIX shell scripts that (I believe)
many network analysts already are writing/using also is possible.

The point of my request for this capability in the ping MIB is simply
that I believe (I could be wrong) many network analysts are already 
writing UNIX shell scripts to provide the periodic ping functionality.
I believe the we can acknowledge this is already being done and provide a 
standards-based mechanism for doing it, or let network analysts continue
to write yet another UNIX shell script solution each time the periodic 
ping functionality is needed.

I'm comfortable believing the folks on the DISMAN working group have
more network management experience than I do.  If the consensus of the 
DISMAN working group is that this functionality is a bad thing to 
provide in the PING MIB, I can align with that.  However, if the PING MIB 
is intentionally hobbled to prevent it from being triggered by the SCHED 
MIB (and hobbled so that you couldn't depend upon the PING configuration 
being saved across reboots), then I would be disappointed because I believe
the hobbled PING MIB has more limited utility, while the utility of having 
periodic ping capability would still be left for proprietary solutions.

The absence of a standards-based MIB for doing periodic PINGS didn't 
stop Cisco from developing and selling a proprietary solution to this
problem.  My point is that I believe this functionality is useful (and
common) enough that it should standardized.

>In general one should try to avoid testing for problem unless there is
>some other indication that such a test is needed.
>
>You might want to run you tests only at such times as other traffic is not
>flowing and which would otherwise notice the network noise or
>disconnection.
>
>(In other words, don't depend exclusively on SNMP or pings to notice when
>the net is broken.)

I'd love to have a conversation (off-line) about better tools than
pro-active pings to identify when the net is broken.  But if the choice
is having users ring my telephone when they can't access something, or 
sending a few pings per minute over Ethernet and T1 WAN links, I'll
use the bandwidth.

Regards,
--Alan