Subject: Link Flap Damping

From: Swati Rastogi <[email-masked]>
Date: Tue, 2 Jul 2002 03:56:33 -0700

Hi,
We have this concept of route flap damping in BGP
while no such equivalent exists in OSPF. If we have a
neighbor which is constantly flapping then we must
give preference to another router if it is more
stable. We must tolerate flapping for some time but if
the figure of merit (it is increased by a fixed value
each time router flaps) goes beyond some pre defined
threshold then all the LSAs originated by the
offending router should be suppressed.

What do others think on this? Why isnt a feature
similiar to this supported by OSPF?

Is it because we want faster convergence in IGPs?

Regards,
Swati

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

---

From: Yasuhiro Ohara <[email-masked]>
Date: Wed, 3 Jul 2002 05:37:53 +0900

I also thought that the feature similar to BGP flap dampenning can be
added to OSPF.

What I don't agree with you is to suppress LSA or to suppress link
description. It may be the only link to the router/network. In the
case we (at least I) want the connectivity to there *up* even if the
link is flapping or congesting. It maybe better to keep the link
description available (while link is flapping). By doing so we can
reduce LSA changes and route/topology computation on all routers in
OSPF domain.

# I think it is too heavy to check if the link is the only path to
# some networks from others...

Another idea is a route preference for multi-path route. Which path to
prefer in a equal cost multi path is left to the calculating router's
own. If we have enough multi path, it will be a great help for
stability of the network. Is there any feature for this already ?

Waiting for a following. thanks.

yasu

swatirstogi> Hi,
swatirstogi> We have this concept of route flap damping in BGP
swatirstogi> while no such equivalent exists in OSPF. If we have a
swatirstogi> neighbor which is constantly flapping then we must
swatirstogi> give preference to another router if it is more
swatirstogi> stable. We must tolerate flapping for some time but if
swatirstogi> the figure of merit (it is increased by a fixed value
swatirstogi> each time router flaps) goes beyond some pre defined
swatirstogi> threshold then all the LSAs originated by the
swatirstogi> offending router should be suppressed.
swatirstogi>
swatirstogi> What do others think on this? Why isnt a feature
swatirstogi> similiar to this supported by OSPF?
swatirstogi>
swatirstogi> Is it because we want faster convergence in IGPs?
swatirstogi>
swatirstogi> Regards,
swatirstogi> Swati
swatirstogi>
swatirstogi>
swatirstogi>
swatirstogi>
swatirstogi> __________________________________________________
swatirstogi> Do You Yahoo!?
swatirstogi> Sign up for SBC Yahoo! Dial - First Month Free
swatirstogi> http://sbc.yahoo.com

---

From: Swati Rastogi <[email-masked]>
Date: Tue, 2 Jul 2002 22:05:09 -0700

Hi Yasu,

> reduce LSA changes and route/topology computation on

You are reducing LSA changes at the cost of providing
sub-optimal (and in the worst case incorrect and
false) routing. You still claim reachability to a
router which you are no longer are connected to
(during the period when the link is down)

The downstream peers will falsely assume that u still
have reachability to some networks and they will in
turn advertise this to their peers. This will create
havoc if one of the OSPF routers is redistributing
routes into BGP

One of the most fundamental rules of routing which i
learnt long back was that we must advertise the bad
news at the earliest. The same happens in BGP. Certain
implementations maintain a MinAdvertismentInterval
timer which when triggers causes a BGP speaker to
advertise all its UPDATE messages to its peers. This
timer is not honoured in case of sending UPDATE
messages containing withdrawn/non feasible routes.

The same should hold true for OSPF. Why should one
router keep the link description up when it knows that
it is down?

Your comments please.

> stability of the network. Is there any feature for

THis is another issue as to what the behaviour should
be when we have multipath routes. I strongly recommend
using a path which i know has been more stable in the
past. I may (given some suitable metrics) also select
a route which i know is of more cost if i know that it
is more stable than a route/link which i know is
*highly* unreliable. How we determine whether the
route/link is unreliable or not is left on the
implementation.

What do others say?

Regards,
Swati Rastogi

---

From: Yasuhiro Ohara <[email-masked]>
Date: Wed, 3 Jul 2002 16:28:59 +0900

swatirstogi> You are reducing LSA changes at the cost of providing
swatirstogi> sub-optimal (and in the worst case incorrect and
swatirstogi> false) routing. You still claim reachability to a
swatirstogi> router which you are no longer are connected to
swatirstogi> (during the period when the link is down)
swatirstogi>
swatirstogi> The downstream peers will falsely assume that u still
swatirstogi> have reachability to some networks and they will in
swatirstogi> turn advertise this to their peers. This will create
swatirstogi> havoc if one of the OSPF routers is redistributing
swatirstogi> routes into BGP
swatirstogi>
swatirstogi> One of the most fundamental rules of routing which i
swatirstogi> learnt long back was that we must advertise the bad
swatirstogi> news at the earliest. The same happens in BGP. Certain
swatirstogi> implementations maintain a MinAdvertismentInterval
swatirstogi> timer which when triggers causes a BGP speaker to
swatirstogi> advertise all its UPDATE messages to its peers. This
swatirstogi> timer is not honoured in case of sending UPDATE
swatirstogi> messages containing withdrawn/non feasible routes.
swatirstogi>
swatirstogi> The same should hold true for OSPF. Why should one
swatirstogi> router keep the link description up when it knows that
swatirstogi> it is down?
swatirstogi>
swatirstogi> Your comments please.

I believe IGP has different logic from EGP's.

  - about "providing sub-optimal" and "why link description up":

    I'm thinking about link flapping caused by congestion.
    If a link flaps, your feature will not allow OSPF to route any
    traffics to the link entirely. We still have a lot of links which
    do not have alternatives. In case no alternatives, I think that
    we prefer to deactivate the feature and let the traffic thru the
    link by "best effort" until we upgrade the link or prepare
    alternatives.

[a little bit off topic:
    I once thought that "we should not worry about congestions,
    because we have Diffserv technology and link monitor packet (such
    as Hello in OSPF) should go beyond the others priority".
    But now I wonder if this is true: in Diffserv world, some class's
    packet go through normally and the other class's packet may not.
    What is that the hello monitors ? Do we really want to keep the
    reachability in that case ? Hello should monitor each class's link
    path separately ...
]

  - about "bad news earlier":

    The "bad news earlier" logic is from that EGP is more severe than
    IGP about inactive route. If an AS advertise unavailable route
    then the AS doing illegal by consuming other AS's network, by
    calling meaningless traffic in. It is entire Internet's implied
    policy. In intra-AS/IGP, (I think) there's no such consideration
    for others exists: just fast convergence. I mean I have a little
    bit different feeling in your words "The same should hold true for
    OSPF".

  - about "havoc case":

    Do we advertise BGP route directly created by an OSPF route in
    general ? Should we advertise some aggregated route ? Even in the
    case directly advertised, BGP flap dampening will do something ...
    But I'm not confident I'm a little short in operations ... :p)

swatirstogi> THis is another issue as to what the behaviour should
swatirstogi> be when we have multipath routes. I strongly recommend
swatirstogi> using a path which i know has been more stable in the
swatirstogi> past. I may (given some suitable metrics) also select
swatirstogi> a route which i know is of more cost if i know that it
swatirstogi> is more stable than a route/link which i know is
swatirstogi> *highly* unreliable. How we determine whether the
swatirstogi> route/link is unreliable or not is left on the
swatirstogi> implementation.

I read on the Internet that we have failed at changing OSPF cost
dynamically because it will not be stable due to traffic shift over
some paths. So your approach can not be applied by dynamic way.
I am just trying to save the duration between errors and human repairs
which is some pathological.

regards.
yasu

---

From: Erblichs <[email-masked]>
Date: Wed, 3 Jul 2002 15:22:20 -0700

Swati,

        My two cents..

        I guess you could think that route flapping
        is implicitly partially supported by a
        number of features in OSPF.

        1) The requirement to first set up a 2-way
           connection between link partners.

        2) The requirement to wait a certain amount
        of time before elections are done.

        3) That database description synchronization
        is a multiple step process. Before routes are
        exchanged.

        4) We will re-xmit until we get an ack or
        until dead-router-interval.

        5) Etc...

        And that in a multi-access topology for OSPF
        only adjs will be established between a subset of
        the routers. Where BGP just about requires a mesh
        topology (yes, exceptions are route reflectors, etc).

        Thus, the dependence is on the interval of the
        flap. If the time while down is so short, it may
        be acting somewhat in a "demand-circuit" like mode.
           Why would we want to penalize the router when it
           meets the dead router interval requirement?

        If the time while up is so short, it hopefully
        cannot form an adjcency.. yes, worse case if it was
        elected the DR and could not form adjs because it was
        flapping..

        So, what would you be protecting and hopefully not force
        longer convergence or flooding intervals.

        Mitchell Erblich
        ---------------------

---

From: Yamate Keiichirou <[email-masked]>
Date: Thu, 4 Jul 2002 20:02:00 +0900

Hello, Yasu.

  I think that newly implimentation of "Link Flap Dampimg" rises 4 issues.

  First issue is RouterDeadInterval. In OSPF, it is dampened that
Hellos dropped by collision or any reasons by RouterDeadInterval
timer. Thus when OSPF operators want to dampen link states to Down,
it should be accomplished simply by large RouterDeadInterval, rather
than implimentation any unusual logics.

  Second issue is about IGPs' primary responsibility. I think that IGPs
have two primary responsibilities of 1) notice new reachabilities
rapidly and 2) notice new UNreachability rapidly. Thus, when
implimentations want to dampen that Hellos not received recently from
particular router, it should be ensured that the neighboring router is
yet alive against of no Hellos received.

  Third issue is LSDB synchronization. When it is occured that the
router has received no Hellos from particular router, if both router
are continuously operating, it is likely that Link State Databases are
not synchronized between two routers.  Thus the link between these
routers should be considered to be Down because LSDB unsynchronization
means two unrelyability of that LSDB in at least one of routers is
unreliable and that routing entries in one of routers is unreliable,
and at result it means that the router should be omitted from routing
domain. It is accomplished to omit unreliable router from routing
domain by link to such router Down.

  Fourth issue is routing traffic preference. Where routing domain has
only one data traffic class (i.e. routing domain has no QoS), OSPF
Hello reachability implies phisical, logical, and traffic reachability
of the only one class. But where routing domain has multiple traffic
classes (i.e. routing domain has some QoS), OSPF Hello indeed implies
reachability of none of these classes. On the other hand, routing
traffic should be prefered to any other data traffics because routing
traffic supports all of data traffics with reachability
notation. Thus, where routing domain has any QoS, routing traffic
should be in the first class of QoS and it will be ensured that none
of routing traffics would be dropped by collision with any other
traffics.

---
yamate.

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 4 Jul 2002 17:30:07 +0530

Hello Yamate,
|
|   First issue is RouterDeadInterval. In OSPF, it is dampened that
| Hellos dropped by collision or any reasons by RouterDeadInterval
| timer. Thus when OSPF operators want to dampen link states to Down,
| it should be accomplished simply by large RouterDeadInterval, rather
| than implimentation any unusual logics.

AFAIK the intention is to damp the flapping link which cannot be done by
simply increasing the RouterDeadInterval. If its value is increased then we
suffer from low convergence wherein a router takes larger time in
recognizing that a peer ospf router has gone down. This is definitely not
desired. What can perhaps be done is - each time a link flaps a figure of
merit should be increased. This value should be decayed with time so that
if the link remains stable for a long time (configurable) we can delete
whatever past history we were maintaining for that link. If the link again
flaps - increase the penalty. This goes on till the penalty reaches some
upper threshold upon which it is deemed to be unstable. Now the router
implementing flap damping should not include this router in its router LSA
(because we know from the past that it is very unstable and there is a high
probability that it will go down again). This router waits for some time.
If it finds that the router/link is now stable (its not flapping anymore)
it should originate a new router LSA wherein it mentions this link/router.

This will only affect the normal working if the link/router is flapping
very frequently (subjective).

|
|   Second issue is about IGPs' primary responsibility. I think that IGPs
| have two primary responsibilities of 1) notice new reachabilities
| rapidly and 2) notice new UNreachability rapidly.

I guess that is what the routing protocols were designed for.

| Thus, when
| implimentations want to dampen that Hellos not received recently from
| particular router, it should be ensured that the neighboring router is
| yet alive against of no Hellos received.

This point was not very clear to me. Can you please expound on this?

|
|   Third issue is LSDB synchronization. When it is occured that the
| router has received no Hellos from particular router, if both router

did not received HELLOs since how long? If it is the RouterDeadInterval
then the remote ospf speaking router will be assumed to be dead (or state
down).

Regards,
Manav

---

From: Yasuhiro Ohara <[email-masked]>
Date: Thu, 4 Jul 2002 23:14:17 +0900

Erblichs:

erblichs>         Thus, the dependence is on the interval of the
erblichs>         flap. If the time while down is so short, it may
erblichs>         be acting somewhat in a "demand-circuit" like mode.
erblichs>            Why would we want to penalize the router when it
erblichs>            meets the dead router interval requirement?

I guess it's not true in real world: some vendor's OSPF is triggered
by link's electrical up/down. Then it will be down regardless of
router dead interval.

Note: I think that link's electrical up/down trigger is not bad; it's
      needed for faster convergence.

erblichs>         If the time while up is so short, it hopefully
erblichs>         cannot form an adjcency.. yes, worse case if it was
erblichs>         elected the DR and could not form adjs because it was
erblichs>         flapping..

That's also not true, because adjacency can be outcome as the end
result of transaction which consists of (as you said) retransmissions.

yamate, manav:

manav> |   First issue is RouterDeadInterval. In OSPF, it is dampened that
manav> | Hellos dropped by collision or any reasons by RouterDeadInterval
manav> | timer. Thus when OSPF operators want to dampen link states to Down,
manav> | it should be accomplished simply by large RouterDeadInterval, rather
manav> | than implimentation any unusual logics.
manav>
manav> AFAIK the intention is to damp the flapping link which cannot be done by
manav> simply increasing the RouterDeadInterval. If its value is increased then we
manav> suffer from low convergence wherein a router takes larger time in
manav> recognizing that a peer ospf router has gone down. This is definitely not
manav> desired. What can perhaps be done is - each time a link flaps a figure of
manav> merit should be increased. This value should be decayed with time so that
manav> if the link remains stable for a long time (configurable) we can delete
manav> whatever past history we were maintaining for that link. If the link again
manav> flaps - increase the penalty. This goes on till the penalty reaches some
manav> upper threshold upon which it is deemed to be unstable. Now the router
manav> implementing flap damping should not include this router in its router LSA
manav> (because we know from the past that it is very unstable and there is a high
manav> probability that it will go down again). This router waits for some time.
manav> If it finds that the router/link is now stable (its not flapping anymore)
manav> it should originate a new router LSA wherein it mentions this link/router.
manav>
manav> This will only affect the normal working if the link/router is flapping
manav> very frequently (subjective).

I agree with manav. There must be more information from history of the
link, but today we use only snapshot information of the link.

manav> |   Second issue is about IGPs' primary responsibility. I think that IGPs
manav> | have two primary responsibilities of 1) notice new reachabilities
manav> | rapidly and 2) notice new UNreachability rapidly.
manav>
manav> I guess that is what the routing protocols were designed for.
manav>
manav> | Thus, when
manav> | implimentations want to dampen that Hellos not received recently from
manav> | particular router, it should be ensured that the neighboring router is
manav> | yet alive against of no Hellos received.
manav>
manav> This point was not very clear to me. Can you please expound on this?
manav>
manav> |
manav> |   Third issue is LSDB synchronization. When it is occured that the
manav> | router has received no Hellos from particular router, if both router
manav>
manav> did not received HELLOs since how long? If it is the RouterDeadInterval
manav> then the remote ospf speaking router will be assumed to be dead (or state
manav> down).

The adjacency breaks and the failure of LSDB synchronization is
absolutely different things. If we have alternative paths, LSDB stays
synchronized. And again, retransmission/acknowledgement will do
something even on the flapping link about the LSDB synchronization
(this will make us calm about using LSAs from the other side of
flapping link.)

Of course as manav saying, if router dead interval have past those
LSAs will be implicitly out of SPF calculation.

regards.
yasu

---

From: Yamate Keiichirou <[email-masked]>
Date: Fri, 5 Jul 2002 15:25:54 +0900

Manav writes:
(snip)
> it should originate a new router LSA wherein it mentions this link/router.

  I agree that there is some cases that it is useful to consider
flapping link Down by dampening Link Up.  I'd been misunderstanding
about flapping link to be considered either Up or Down.

> This point was not very clear to me. Can you please expound on this?

  This means, when an router receive no Hellos, it can't be
distinguished why it occurs, either neighboring router down, link
down, or collision.
  But where flapping link to be considered Down, there is no need to
distinguish it because any either reasons should cause the link to
Down. So I agree it is likely no probrem in above.

> (this will make us calm about using LSAs from the other side of

  It is noted that topology/LSDB/SPF are reliable on assumption that
any adjacencies ensure particular responsibilities, includeing LSDB
synchronization.  In other words, topology's reliability is
constructed with responsibility on each adjacencies in the routing
domain, and any adjacency SHOULD NOT depend on topology reliability.
When some adjacencies rely on topology and topology relies on the
adjacencies, then undesirable reliability (or unreliability) loop
might be occured.

  Thus, such adjacencies should be omited from Router-LSA to advertise
their dis-functionality wherever it is also reachable with any other
adjacencies.

----
[email-masked].