Subject: OSPF rfc 2328 :Must:Should : Inactivity timer

From: Erblichs <[email-masked]>
Date: Wed, 24 Apr 2002 09:45:57 -0700

Group I am looking for a consensus on how literally, the OSPF
standardized RFCs need to be followed.

In standard RFC language there is a section that says the
requirement to follow certain sections or subsections of
a RFC. This section uses words such as "May", "Should", "Must",
etc. This older doc doesn't follow that type of language.

With implimentations of my past there was a architecture
design doc and at least a implimentation doc. The implimentation
could differ from the architecture design, but still impliment
like functionality. I associate the RFCs as more of a arch
doc and that implimentations can vary as long as they
impliment like functionality and have a like external behaviour.

So, I have had a few converstations with various people
not in this discussion group and would like to get a consensus.

For instance ...

in the rfc2328, section 10 Neighbor Data struct,
their is a specified item as Inactivity timer. This forces
a single timer per neighbor per this functionality. I propose
that it should be sensible that if there are alternate
solutions.  Assuming that their are a number of neighbors per
interface, it would be a simple matter to place all hello
protocol speaking neighbors on this interface together within
say a link list and be able to walk the list. A single periodic
timer would be created for all neighbors on this list that would
decrement the interface hello interval time. If a hello is
recieved before multiple hello intervals time, then the value
is reset to the interface RouterDeadInterval secs. The assumption
here is that I prefer to do a lookup, and neighbor walking once
per hello interval vs repeated timer creations, timer cancels per
neighbor, etc.

The end result is the same, if you don't see a hello from
a neighbor within the timeframe, you are going to do the
same work as if the single neighbor Inactivity timer fired.

So, am I wrong here where each item MUST be followed to
a strict same implimentation stardard? And SHOULD there be
clauses within such docs that these items are SHOULDs and
not MUSTs?

Mitchell Erblich

---

From: Acee Lindem <[email-masked]>
Date: Wed, 24 Apr 2002 15:42:27 -0400

Mitchell,

It would be an understatement to say I don't think this is
a good idea. First, if I understand your algorithm correctly (which
I may not), you'll be off by an average of 1/2 the hello interval.
Second, this scheme will encourage synchronization of neighbor
events.

If timers are expensive in your implementation, you can still do it with a
single timer (of granularity 1 second) or a timer that you keep resetting
to the minimum neighbor inactivity expiration time.

Thanks,
Acee

--
Acee

---

From: Erblichs <[email-masked]>
Date: Wed, 24 Apr 2002 16:44:31 -0700

I am only talking about local reception of the processing
        of hellos and the ability to cancel the local procedure
        that would be called if there was no hellos seen
        in deadrouter time. No statement on the local xmit'ion
        of hellos is made.

        For the sake of agreement, the granularity could
        be 1 sec, 1/2 sec of walking the rcv hello protocol
        neighbor list. But all that depends on the
        setting of hellointerval for the interface. If
        the hellointerval was 10 secs, walking it every
        2 sec or 3 secs may not be a issue. It could
        be a CLI setting per interface.

        Let me re-state this to the unlikely extreme
        simple case....
        Assume that there are 1000 routers on the same
        interface using the hello protocol of 3 secs
        hellointerval and 9 secs for deadrouter time.
        ---And yes hello rcv events would tend to be
        synchronized per 3 secs. But this is only for routers
        going away. And don't we want to have our routers
        databases synchronized. At every 3 sec mark in this
        example I would inform every adj router (via my hellos)
        that I lost at least 2-way state with a set of routers.

        This would mean that on the avg every like interface
        would experience the pairing of 333 cancel timer calls
        and 333 create_timer calls every sec. Just for this
        specified functionality...

        Doesn't this seem to be abit non-scalable? Alot
        of un-neccessary overhead?

        By starting with my simplistic suggestion, their would
        be 1 timer firing every 3 secs, decrementing a initial
        9 secs value per neighbor on this list. Only if a hello
        has not been seen for at least 3 looping values, will
        it be processed with the set of deadrouter timer
        procedures.

        Which comes back to the original two questions? Basicly
        is the per neighbor deadinterval timer functionality
        a requirement (a MUST)?

        Mitchell Erblich
        =======================

---

From: Acee Lindem <[email-masked]>
Date: Thu, 25 Apr 2002 10:35:39 -0400

Erblichs,

In your original E-mail I thought you implied the timer granularity
for checking for inactive routers would be the hello interval. I
agree that with a timer granularity of 1 second you can provide
the same external behavior as a single inactivity timer per neighbor.
Thanks,
Acee

--
Acee