Subject: Re: [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 18:26:01 -0500 (EST)

I think what you said is what I mean. You would have to be
aware of when you last sent something on each such adjacency to know
whether you can postpone a hello on that adjacency.

If you don't like that, would this be easier on the implementation?
Having a nonzero queue
of stuff to that adjacency would be sufficient information that
you don't need to send a Hello on that adjacency. So, for instance,
if the queue is empty, send a Hello...what harm is there since you're
not doing anything anyway. But if the queue is nonempty, then you
can skip actually transmitting that Hello.

Radia

	X-Sender: [email-masked]
	To: Radia Perlman - Boston Center for Networking <[email-masked]>
	From: Jeff Learman <[email-masked]>
	Subject: Re: [Isis-wg] comment on draft-parker-short-isis-hold-times-00.txt
	Cc: [email-masked]
	Mime-Version: 1.0

	Perhaps I'm missing something, but ...
	
	>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.
	
	  ... 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

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

---

From: Dave Katz <[email-masked]>
Date: Tue, 27 Feb 2001 17:55:04 -0800 (PST)

All of this is a tad trickier in routers with silicon-based forwarding.

Note that this still requires a sufficiently lively scheduler to make
sure things happen within tight timeframes, which is the biggest impediment
to this subsecond stuff.

   X-JNPR-Received-From: outside
   From: Radia Perlman - Boston Center for Networking <[email-masked]>
   Reply-To: Radia Perlman - Boston Center for Networking <[email-masked]>
   Cc: [email-masked]
   MIME-Version: 1.0
   Content-Type: TEXT/plain; charset=us-ascii
   Content-MD5: Es5/WdGPyzDkEWfIBuXoJA==
   X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc 
   Sender: [email-masked]
   Errors-To: [email-masked]
   X-BeenThere: [email-masked]
   X-Mailman-Version: 2.0rc1
   Precedence: bulk
   List-Help: <mailto:[email-masked]?subject=help>
   List-Post: <mailto:[email-masked]>
   List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	   <mailto:[email-masked]?subject=subscribe>
   List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
   List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	   <mailto:[email-masked]?subject=unsubscribe>
   List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
   Date: Tue, 27 Feb 2001 18:26:01 -0500 (EST)

   Radia

	   Is that what you mean?

	   Thanks,
	   Jeff

---

From: Bora Akyol <[email-masked]>
Date: Tue, 27 Feb 2001 20:09:08 -0800 (PST)

I would second Dave here, keeping these timers on a per next hop basis and
then generating these interrupts when these timers expire while doing line
rate forwarding is a tad tricky.

On a SONET link, it is fairly easy to detect that your neighbor has gone
down and notify your peers. On an ethernet I do recognize this gets
harder, but can we make do with a software based keep-alive mechanism that
doesn't involve the forwarding plane?

Regards

Bora