Subject: Re: Link Flap Damping

From: Andreas Heiner <[email-masked]>
Date: Wed, 3 Jul 2002 13:30:54 +0300

Hi

comments in-line

> Subject: Re: Link Flap Damping
> 
> 
> 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)
>
[ side issue
I'm not quite sure what you mean with "optimal routing". Intuitively optimality in this context is "getting as much traffic through as fast as possible", but with dynamic traffic demands optimality is not well defined. Moreover, the cost assignment is relatively arbitrary (one administrator may say hops, others reliability etc.), so in my opinion "optimal routing" is rather arbitrary. I prefer to use "as good as possible", or even better, "good enough" routing. Gives you way more flexibility. In the end, the only thing users are interested in is good (enough) service, not optimal service
(the STAR protocol by Garcia-Luna-Aceves (http://www.soe.ucsc.edu/people/faculty/jj.html) also uses this principle)
]

> 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 ...
> ]
> 
...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

> regards.
> yasu

---

From: Swati Rastogi <[email-masked]>
Date: Thu, 4 Jul 2002 05:40:50 -0700

Hi Mitchell,
Consider the following scenario ..

-------------------
| network cloud x |
-------------------
         |
         |
   --------------
   | router ABC |-----------
   --------------          |
         |                 |
         |2                |3
   ---------------      --------------
   | router abc  |      | router abc'|
   ---------------      --------------
         |                 |
         |------------------
         |
---------------------
|   network cloud y |
---------------------

Now the link between router abc and ABC is constantly
flapping after some time period. Say initially the
link is up. Since the cost between ABC-abc is less
than ABC-abc' the path ABC-abc will be chosen. Now the
link goes down. Traffic will be blackholed till
RouterDeadInterval after which the new path ABC-abc'
will be taken. Now suppose the link comes up again
after some time. Again the adjacency will form between
abc-ABC and SPF will be run. ABC-abc will be selected
over BC-abc' since the cost is less. All the data
traffic will be re-routed thru ABC-abc. Now again if
it goes down then we wait for RouterDeadInterval
before we identify that the router is down. SPF is
again triggered and ABC0-abc' is selected and traffic
is re-routed. This can go on for a long time thereby
severly damaging our throughput. We need a mechanism
by which ABC recognizes that abc is unstable and that
when it comes up again after flapping for many times
.. its presence should be ignored. It should be
ignored till the time ABC takes to be confident that
the offending router/link will now not crash again!

In most of the implementations the lower layers will
inform ospf of a link going down and it will actually
never have to wait for RouterDeadInterval before
knowing that the remote speaker is down. But there can
be cases (however very rare) when we dont receive the
HELLOs. Traffic congestion in the network, system
crashes, etc.

IMHO we must have a mechanism to damp such flapping
links/routers.

What do others say?

Regards,
Swati

----- Original Message -----
From: "Erblichs" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 04, 2002 3:52 AM
Subject: Re: Link Flap Damping

| 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

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

---

From: Andreas Heiner <[email-masked]>
Date: Mon, 22 Jul 2002 10:31:10 +0300

> -----Original Message-----
> From: ext Andreas Heiner [mailto:[email-masked]]
> Sent: 03 July, 2002 13:31
> To: [email-masked]
> I'm not quite sure what you mean with "optimal routing". 
> Intuitively optimality in this context is "getting as much 
> traffic through as fast as possible", but with dynamic 
> traffic demands optimality is not well defined. Moreover, the 
> cost assignment is relatively arbitrary (one administrator 
> may say hops, others reliability etc.), so in my opinion 
> "optimal routing" is rather arbitrary. I prefer to use "as 
> good as possible", or even better, "good enough" routing. 
> Gives you way more flexibility. In the end, the only thing 
> users are interested in is good (enough) service, not optimal service
> (the STAR protocol by Garcia-Luna-Aceves 
> (http://www.soe.ucsc.edu/people/faculty/jj.html) also uses 
> this principle)
> ]
> 
> > swatirstogi>
> 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
> 
> > regards.
> > yasu
> > 
>

---

From: Manav Bhatia <[email-masked]>
Date: Fri, 26 Jul 2002 12:11:57 +0530

Hi Vishwas,
Are you aware of any vendor implementing link flap damping in the hardware?

If there are such implementations out there and it is not a standard then
cant it create problems out there in the wild when you can snoop HELLOs
coming from the other end but find them not being delivered to your OSPF
instance because of which the adjacency never comes up?

Infact understanding the fact that those HELLOs are not being delivered to
your local OSPF daemon will itself take up some time !!!

Regards,
Manav
----- Original Message -----
From: "Manral, Vishwas" <[email-masked]>
To: <[email-masked]>
Sent: Friday, July 26, 2002 10:48 AM
Subject: Re: Link Flap Damping

|| >       than in OSPF.
| I agree here. Infact check the mail I sent to the list some time back.
|
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I
=
| -3 where I agree to what you have said, link flap is best dealt with the
| lower layer, the closer to hardware the better.
|
| >   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.
| There is a difference here. MinLSInterval does prevent the same LSA from
| being originated too soon. However this does not prevent the entire
| adjacencies to have to be reformed/broken. Damping the flap can prevent
us
| from doing this(in case the thing is not done at a lower layer).
|
| >   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.
| Agreed !!!
|
| >   4. I haven't heard a requirement for such a feature from a network
| operator
| > (public or enterprise). Has anyone?
| Not exactly, but I guess the study by Cengiz and Steve on faster
convergence
| does talk about advantages of asymmetricaly damping Up/Down events, where
| and how it is done I guess is left to the implementor. This was presented
at
| one of the recent NANOG meetings. The study was done on the Qwest
backbone.
|
| In our draft(with the AT&T folks) we did find this feature useful in case
of
| congestion/scalability conditions too. Infact I guess Nokia also did a
study
| on this and came with similar results.
|
| Thanks,
| Vishwas

----
"When you are courting a nice girl an hour seems like a second. When you
sit on a red-hot cinder a second seems like an hour. That's relativity."

-Albert Einstein, on relativity

---

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 31 Jul 2002 07:58:51 -0400

Hi Manav,

As Acee pointed out, if you still feel there is a desired requirement for
further dampening and can compensate for the added complexity, go ahead and
draft it.

Thanks,
Vishwas

-----Original Message-----
From: Manav Bhatia [mailto:[email-masked]]
Sent: Wednesday, July 31, 2002 11:15 AM
To: [email-masked]
Subject: Re: Link Flap Damping

Hi Manral,

| >
| >  [sw1]-[sw2]-[sw3]
| >    |           |
| >    R1         R2
| >
| > If L2 switch [sw2] or the link connected to it flaps, R1 and R2 would
| > not be able to recognize the flaps even if there's some conversation
| > about the link's (L2) information above [sw1], [sw2] and [sw3].
| If the link is flapping on sw2, sw2 would damp it wouldn't it. If we did
| have flap dampening at layer 2. then the two ends R1 and R2, would not
form
| an adjacency. By the way L2 damping would help not only OSPF but all
other
| protocols above L2.

not exactly.

link flap damping implemented at L2 will only work if the time period of
the flap is high and the duration is small. What can be done if an
interface fails after every 10 mins and takes 20 seconds to come up. Will
we flap the link at L2 after 30 mins (hypothetical figures) when its has
flapped thrice for some 10 mins? We will thus be blocking all the traffic
which might otherwise flow over this link. If we do it at the L3 then we
can specify which all applications needs to do the damping and rest of the
things work normally following the traditional best delivery model.

I can cite cases when we may like to continue with a flapping link than
having no link/communication channel at all. If you decided to let L2 take
care of link flap damping then it can  adversely affect BGP functioning
under some circumstances. BGP may continue to use this link as the last
resort claiming reachability to some destinations through it and assigning
it a higher MED and announcing this to its external peers. The system
administrator can then suitably set the route flapping parameters
associated with that link and things will work out fine for him!

Thanks and Regards,
Manav