Subject: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.txt

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Tue, 27 Feb 2001 17:38:22 -0500 (EST)

I sent minor typos, etc., to the authors, but we had an interesting
discussion about the following idea, which is now sufficiently
baked to mention to the list.

An extension to the problem of quickly detecting a neighbor is
down, while perhaps avoiding false declarations of down if
the hello process can't be immediately scheduled to sub-second
timing...

Suppose receipt of data on an adjacency reset the hello timer?

Various thoughts on that:
   You might even avoid sending as many hellos, if you know that you've
   recently sent data to that adjacency
   
   On LANs, where the hello is multicast but data is unicast, the data
   to the DIS would be the data that counted, not data to some other
   adjacency on that LAN
   
   To allow other information in the Hello to change (area address, etc.)
   the sender could be required to occasionally send hellos. So, for
instance,
   you'd want to detect him down very very quickly (so perhaps the
expiration
   for that might be subsecond, with either hellos or data resetting that
   timer), but for changing the information in a hello, this would not
   need to be so timely...it would be OK to be tens of seconds, so
   the sender could postpone sending hellos for awhile, but not
   indefinitely, if he's sending traffic.
   
   If the info changed at a router, that router could instantly issue
   a hello with the new information, but since that might get lost, it's
   still necessary to occasionally refresh the info in the hello.

So to implement this: need an option in the Hello to say "I'm cool
with receipt of data messages instead of Hellos". If your neighbor
says that, then you don't have to send hellos in a timely way if
you're sending traffic.

The receiver should reset timer on receipt of either Hello or data.

The transmitter still would send Hellos periodically, but not
with sub-second requirement if there's traffic. Instead, if
the Holding Timer you tell your neighbor is less than, say, 5 seconds,
and your neighbor is willing to accept data in lieu of Hellos, then
you can postpone sending Hellos, but not longer than, say, 30 seconds.
I think 5 and 30 could be architectural constants rather than yet
more parameters.
   
Radia

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Jeff Learman <[email-masked]>
Date: Tue, 27 Feb 2001 18:07:40 -0500

Perhaps I'm missing something, but ...

>says that, then you don't have to send hellos in a timely way if

  ... you don't have to send hellos in a timely way if you're sending
  traffic *via that adjacency*.  So you'd need to
  keep a new timer per adjacency of when you last sent data, and send
  a Hello (either to that adjacency, or a broadcast) on timeout.
  [Sorry, I don't remember whether the original proposal indicated
  whether the hellos were direct or broadcast.]

Is that what you mean?

Thanks,
Jeff