Subject: FW: Non-member submission from [Thippanna Hongal <hongal@yagosys. com>]

From: "Appelbaum, Muriel" <[email-masked]>
Date: Fri, 28 Jan 2000 13:16:58 -0600

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Friday, January 28, 2000 10:31 AM
To: [email-masked]
Subject: BOUNCE [email-masked]: Non-member submission from
[Thippanna Hongal <[email-masked]>]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 31 Jan 2000 13:13:31 +0100

>>>>> Thippanna Hongal <[email-masked]> Muriel writes:

hongal> I do not see any confusion over the explanation in RFC
hongal> regarding the non-existent time.

hongal> My question is a specific case of one schedule and one table.

hongal> I have a single row and which does calendar schedule for 60
hongal> times in hour.  For 2hrs of non existant time I have to do
hongal> SNMP SET for 60 * 2 times at the end of 3 PM.  This might lead
hongal> to net congestion.

It only leads to "agent congestion" since the sets are performed on
local MIB variables only. A calendar schedule can hav a maximum
resolution of minutes. Hence, you can have 60 sets per minute in one
hour of non existant time (which is the usual time difference for
daylight savings time). Sure, multiple entries can cause lots of sets
to happen when time jumps forward. But you are not required to do them
all simultaneous. If your agent is single-threaded, then you will
process them in a serialized order anyway. All what is required is
that you process the events in the same order they were scheduled.

hongal> What I have done in my implementation is if that case exists
hongal> then I have done SET operation to work once and a LOG message
hongal> will be generated about this saying rest of the 119 SET
hongal> operations are not done because of repeated large number of
hongal> SET operations.  This LOG message is generated for each
hongal> schedules which have large number of SET operation to be done
hongal> during the nonexistent time.

Whether this is good or bad depends on what your set operations
trigger. In some cases, just doing a single set might be OK, in 
other cases, your optimization may create inconsistencies.

I think we need to define a common way to deal with this situation.
The intention of the text currently in RFC 2591 is that all events
that fire during non existant time are processed. If we keep that
position and your implementation does not behave this way, then it is
not conforming to the RFC.

So the real question here is whether the behaviour described in RFC
2591 should be changed or not. Any opinions?

hongal> At this time I would like to add another implementation
hongal> feature.

hongal> If a schedule fails to do its intended operation for certain
hongal> number of time then schedOperStatus is set to DISABLED.  While
hongal> considering the number of times , I consider the interval
hongal> between the schedules too.

This may be a useful addition. Any comments from the WG? Is there
interest to add such a capability? Any suggestions for a concrete
definition?

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: Thippanna Hongal <[email-masked]>
Date: Mon, 31 Jan 2000 16:46:05 -0600

> 2591 should be changed or not. Any opinions?

At this time  I have no data about the side effects of  'agent congestion'
on our
router due to non existent time SET operation for the above specific case.

In my opinion this feature can be made user configurable  in future to avoid
such possible
congestion if those congestion are harmful to the main device operation.

I have a luxury of  making this feature turn-off and turn-on through CLI
commands

I hope user configurability  through CLI  does not make our implementation
to not to confirm with  the RFC. Let me know if it is.

> interest to add such a capability? Any suggestions for a concrete

In this case the question  of when to turn off the schedule
, I mean how many failures are acceptable can be left to the user to
decide based on his requirement. User configurable new object could help
decide about it.

hongal

> /js

I subscribed to the disman WG general mailing list.

--
thanks
hongal