Subject: Re: Link Flap Damping

From: Cengiz Alaettinoglu <[email-masked]>
Date: Thu, 8 Aug 2002 14:27:10 -0700

Here is a pointer to the NANOG talk mentioned below.

ISIS Routing on the Qwest Backbone:
a Recipe for Subsecond ISIS Convergence
http://www.nanog.org/mtg-0202/cengiz.html

It has a nice graph on an exponential link flap damping filter.

Cengiz

On Mon, 2002-07-22 at 21:44, Manral, Vishwas wrote:
> Hi Andrepeter,
>
> I haven't really been following the thread but now that you mentioned the
> draft
> http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-01.txt
>
> I would like to add that there are some things that we have mentioned in
> section 4 of the draft that could help in case of "link flaps".
>
> The main point being to give more priority to "link down" than to "link up".
> This could mean that in case of flaps we could signal "link down"
> immediately however damp the "link up" event. Cengiz and Steve Casner
> reached a similar conclusion with respect to ISIS protocol, they even
> presented something related at NANOG.
>
> Thanks,
> Vishwas
>
> > ...deleted...
> > In my opinion the only service OSPF (or any other IGP)
> > provides/should provide is connectivity, i.e. it tells you if
> > a link exists and if it can carry traffic, not how much
> > traffic there is. Route recalculation based on traffic
> > information (congestion gives new cost values) should not be
> > done as it will introduce route flaps.
> > This also holds for a DiffServ world. In a DiffServ world
> > packets are preferentially forwarded, but always such that no
> > single class is starved. Even if some class gets so little BW
> > that de-facto the link is down for that class, one should not
> > declare the link down for that class, as it is equivalent
> > with assigning a high cost for that link. Hence link monitor
> > packets per class make no sense. (Besides, in long
> > simulations with strict priority queueing we never had class
> > starvation)
> > As for Hello in the highest DiffServ class: we tested this
> > idea in simulations for all OSPF packets, and results were
> > excellent, i.e. route table convergence in the order of the
> > half the minimum round trip time (excl. route table
> > recalculations). This idea was also proposed in
> > 'draft-ietf-ospf-scalability-01.txt'.
> >
> > regards,
> >
> > Andrepeter
--
Cengiz Alaettinoglu <[email-masked]>