Agenda suggestions?

Curtis Villamizar curtis at ans.net
Wed Jan 25 17:02:07 UTC 1995


In message <199501251514.KAA03501 at merit.edu>, yakov at watson.ibm.com writes:
> Ref:  Your note of Wed, 25 Jan 1995 05:57:53 -0500
> 
> >Routing flaps considered harmful...
> A while ago Curtis proposed a scheme for holddowns that
> has a property that a holddown time associated with
> a route increases with the frequency of this route
> flapping -- so that frequently flapping routes getting
> progressively long timeouts.
> 
> Yakov.

Yakov,

Thanks for remembering that.  Do you also remember where I put the
sources?  :-)  [need a bigger disk].

That work got put on a low priority and has never resurfaced to the
top of the queue.  I had written some code for rcp_routed and then put
it on hold since gated was eminent.  The plan at the time was to wait
until Dennis got gated's BGP real solid and stable and then finish
that code and hook it in.  Cisco (Tony Li, maybe Paul) were not
thrilled with the proposal because it added state (an empty 4 byte
pointer for stable routes, a small struct for unstable ones).

The BGP WG overall response was an enthusiastic yawn and encouragement
to come back when some code was written, so it was never officially
submitted.  At the time that seemed reasonable since I was writing
code and seemed likely to come back.

I did find the source and put the files up for ftp in case anyone
cares to look.  It is at:

   ftp://ftp.ans.net/pub/papers/route-dampen.ps
   ftp://ftp.ans.net/pub/papers/route-dampen.txt

Or use your favorite browser to visit the abstracts file first:

  ftp://ftp.ans.net/pub/papers/abstracts.html

That was the proposal then.  Do we want to resurect this?  If so, why?
Are we trying to convince someone to do an implementation?  I wish I
had the time to do one for gated BGP.  I'm not sure Paul has the time
and I'm not sure Cisco is convinced that they can afford an increase
in state.

This is a solution at the protocol implementation level, which is
probably the best kind since it automatically kicks in when something
flaps.  Similar techniques could be applied to an IGP in originating
LSAs.  There is also the manual administrative solution of taking
flakey links down and fixing problems when they occur.  With the
manual solutions, like aggregation, the provider needing the benefit
is not the one that needs to address the problem.

If we want to talk about the larger topic of keeping route flap under
control, I'll come moderately prepared to talk about this if we want
to bring it up.  If Sean has some "how bad is it" slides, then maybe
he can lead the discussion.  I haven't had time to keep the external
route flap reporting running all the time and don't have time to
summarize it, but anyone that wants to do an analysis is welcome to
the raw data.

Curtis



More information about the NANOG mailing list