Subject: Re: Link Flap Damping

From: "Manral, Vishwas" <[email-masked]>
Date: Tue, 23 Jul 2002 00:44:45 -0400

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

---

From: Erblichs <[email-masked]>
Date: Tue, 23 Jul 2002 09:23:12 -0700

Group,

        I totally agree with Vishwas. However, I think if you
        keep knowledge of objects beyond the "link down" event
        instead of just deleting them. This knowledge would allow
        you to properly characterize the "link up" as being a NEW
        event and the amount of damping.

        Thus in my opinion a first "link up" event or a "link up"
        after a configurable considerable amount of time, needs
        minimal or no damping.

        Mitchell Erblich
        ======================

---

From: Acee Lindem <[email-masked]>
Date: Thu, 25 Jul 2002 14:38:45 -0400

I really don't think adding this feature  to OSPF is necessary for the
following reasons:

   1. Dampening the delivery/processing of "link up" events is a very good idea.
       However,  I believe that this should be done locally at layer 2 rather
       than in OSPF.
   2. The OSPF specified MinLSInterval is 5 seconds (RFC 2328, appendix B). This
        is already quite a long time and I don't think further dampening is required.
   3. OSPF is an IGP and, as such, an OSPF instance should span a single routing
       domain under a single administrative authority. Hence, it should be possible
       to address and remedy link flapping issues.
   4. I haven't heard a requirement for such a feature from a network operator (public
       or enterprise). Has anyone?

It may make sense to dampen/control route redistribution  (aka route import/export).
RFC 1765 is an example. Another example from our implementation is the
ability to configure the maximum number of redistributed routes and the rate
at which  external route changes are introduced into a routing domain.

Thanks,
  Acee

--
Acee