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

From: [email-masked]
Date: Wed, 17 Feb 1999 13:14:37 -0500 (EST)

>Alan,
>
>At 11:48 AM 02 17, 1999 -0500, Alan Luchuk wrote:
>
>>> I think this depends on whether there is a management application that
>>> periodically polls the results and/or relies on a notification to
>>> be sent when a ping fails to detect when a network resource becomes
>>> unavailable. I think it would be useful to define a notification in the
>>> ping MIB to report when a ping fails. Should the notification be sent
>>> every time a probe fails? Just the first time or periodically? Sending it
>>> every time a probe fails could result in a large amount of notifications
>>> being sent into management consoles for example. Sending it just on the
>>> first failure isn't sufficient given the nature of notifications. What
>>> would you suggest?
>>
>>I would suggest that a notification be sent if ALL of the ping retries
>>(as specified by pingProbeCount) FAIL.  The rationale is that if ANY of
>>the pings succeed, then we've established "connectivity" with the ping'ed
>>host (perhaps with degraded network performance).  Or conversely, if ALL 
>>of the pings FAIL, we've lost "connectivity" with the ping'ed host.
>
>I'm not sure if I agree. Suppose I instruct the PING MIB to send 5 Ping
>requests
>and the last 2 Ping requests time out. This might indicate a significant
>network 
>connectivity failure. 

It might indicate a connectivity failure that host, but then again, it 
might be random chance.  But when it's time to test that host again (as 
specified by pingFrequency), if all connectivity is lost to that host, 
then presumably ALL pings would fail, and the notification would be sent.
The trick is to carefully set the pingFrequency so that the notification 
is sent and the network operators know there is a problem before any of 
the users notice, without flooding the network with gratuitous pings.

>Whether or not it matters that 1 or a couple of more Ping requests get lost
>depends on the known state of the network. When I have a congested network
>I probably don't care much a few lost Ping requests. So, in this scenario,
>your solution (i.e., send trap when all of the ping requests fail) might be
>useful.
>
>However, if I (think to) have a "clean" network one or more lost Ping requests
>are probably interesting to consider. In this scenario your solution is
>probably
>not very useful.

Agreed.  I guess I'd live with a "dirty" network, that loses a few pings
occasionally.  But what I really don't want is users/customers ringing my 
phone off the hook with complaints about service outages  :-)

>My suggestion to solve this problem is:
>- only send a Trap when one or more Ping requests time out
>- add an object in the pingTable indicating whether a trap should be
>  send in case one or more Ping requests time out (a bit similar to the 
>  ciscoPingTrapOnCompletion object)

Perhaps the object could specify how many pings must fail before sending
the trap.

Bob Stewart suggested an enumeration for notification with the following 
values:    none, probeFail, testFail, and completion.  Adding a knob to 
allow these different settings seems like a reasonable way to accomodate 
the different needs.

Regards,
--Alan