Re: ISPACs

Vadim Antonov <avg@pluris.com> Thu, 05 December 1996 05:52 UTC

Received: from cnri by ietf.org id aa28659; 5 Dec 96 0:52 EST
Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa02071; 5 Dec 96 0:52 EST
Received: from alink.net (ns.alink.net [207.135.127.66]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id PAA26832 for <cidrd@iepg.org>; Thu, 5 Dec 1996 15:41:30 +1100
Received: from quest.pluris.com (avg@quest.pluris.com [207.135.126.68]) by alink.net (8.8.0/8.7.3) with ESMTP id UAA08450 for <cidrd@iepg.org>; Wed, 4 Dec 1996 20:40:59 -0800
Received: (from avg@localhost) by quest.pluris.com (8.6.9/8.6.9) id UAA00904 for cidrd@iepg.org; Wed, 4 Dec 1996 20:40:03 -0800
Date: Wed, 04 Dec 1996 20:40:03 -0800
From: Vadim Antonov <avg@pluris.com>
Message-Id: <199612050440.UAA00904@quest.pluris.com>
To: cidrd@iepg.org
Subject: Re: ISPACs

Nice idea, but i do not think it is practical.  Too complicated,
and the potential yield is small :(

I'd rather fought the battle with CSU vendors and router manufacturers
to change default timing parameters in CSUs and make static routes
persistent by default (and add exponential dampening in line keepalive
protocols).  Those two simple tricks would reduce flap by 90% by
killing its source instead of treating its symptoms.

And then, there's always TWD.

--vadim