Subject: Re: Link Flap Damping

From: "Manral, Vishwas" <[email-masked]>
Date: Sat, 27 Jul 2002 06:14:43 -0400

Hi Manav,

Though I do not remember the details(and things have changed a lot there),
in RPR(802.17) there is something called a "Wait To Restore"(WTR) timer. A
failed link is required to show no failure for the given period of time
before being declared working.

Thanks,
Vishwas

-----Original Message-----
From: Manav Bhatia [mailto:[email-masked]]
Sent: Friday, July 26, 2002 12:12 PM
To: [email-masked]
Subject: Re: Link Flap Damping

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

---

From: Yasuhiro Ohara <[email-masked]>
Date: Sat, 27 Jul 2002 21:04:03 +0900

All,

The L2's link flap dampen feature is not enough, since L3 (i.e. OSPF)
uses its own method to detect link flap. Even if the L2 do not trigger
up/down events to OSPF process, there will still be a case where a
OSPF process detects link flaps by Hello.

If one want to say "L2 flap dampening feature is enough to prevent
OSPF to flap", we have to remove Hello. This is obviously not what we
want.

regards.
yasu

VishwasM> Hi Manav,
VishwasM>
VishwasM> Though I do not remember the details(and things have changed a lot there),
VishwasM> in RPR(802.17) there is something called a "Wait To Restore"(WTR) timer. A
VishwasM> failed link is required to show no failure for the given period of time
VishwasM> before being declared working.
VishwasM>
VishwasM> Thanks,
VishwasM> Vishwas
VishwasM>
VishwasM> -----Original Message-----
VishwasM> From: Manav Bhatia [mailto:[email-masked]]
VishwasM> Sent: Friday, July 26, 2002 12:12 PM
VishwasM> To: [email-masked]
VishwasM> Subject: Re: Link Flap Damping
VishwasM>
VishwasM>
VishwasM> Hi Vishwas,
VishwasM> Are you aware of any vendor implementing link flap damping in the hardware?
VishwasM>
VishwasM> If there are such implementations out there and it is not a standard then
VishwasM> cant it create problems out there in the wild when you can snoop HELLOs
VishwasM> coming from the other end but find them not being delivered to your OSPF
VishwasM> instance because of which the adjacency never comes up?
VishwasM>
VishwasM> Infact understanding the fact that those HELLOs are not being delivered to
VishwasM> your local OSPF daemon will itself take up some time !!!
VishwasM>
VishwasM> Regards,
VishwasM> Manav
VishwasM> ----- Original Message -----
VishwasM> From: "Manral, Vishwas" <[email-masked]>
VishwasM> To: <[email-masked]>
VishwasM> Sent: Friday, July 26, 2002 10:48 AM
VishwasM> Subject: Re: Link Flap Damping
VishwasM>
VishwasM>
VishwasM> || >       than in OSPF.
VishwasM> | I agree here. Infact check the mail I sent to the list some time back.
VishwasM> |
VishwasM> http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I
VishwasM> =
VishwasM> | -3 where I agree to what you have said, link flap is best dealt with the
VishwasM> | lower layer, the closer to hardware the better.
VishwasM> |
VishwasM> | >   2. The OSPF specified MinLSInterval is 5 seconds (RFC 2328, appendix
VishwasM> B).
VishwasM> | This
VishwasM> | >        is already quite a long time and I don't think further dampening
VishwasM> is
VishwasM> | required.
VishwasM> | There is a difference here. MinLSInterval does prevent the same LSA from
VishwasM> | being originated too soon. However this does not prevent the entire
VishwasM> | adjacencies to have to be reformed/broken. Damping the flap can prevent
VishwasM> us
VishwasM> | from doing this(in case the thing is not done at a lower layer).
VishwasM> |
VishwasM> | >   3. OSPF is an IGP and, as such, an OSPF instance should span a single
VishwasM> | routing
VishwasM> | >       domain under a single administrative authority. Hence, it should
VishwasM> be
VishwasM> | possible
VishwasM> | >       to address and remedy link flapping issues.
VishwasM> | Agreed !!!
VishwasM> |
VishwasM> | >   4. I haven't heard a requirement for such a feature from a network
VishwasM> | operator
VishwasM> | > (public or enterprise). Has anyone?
VishwasM> | Not exactly, but I guess the study by Cengiz and Steve on faster
VishwasM> convergence
VishwasM> | does talk about advantages of asymmetricaly damping Up/Down events, where
VishwasM> | and how it is done I guess is left to the implementor. This was presented
VishwasM> at
VishwasM> | one of the recent NANOG meetings. The study was done on the Qwest
VishwasM> backbone.
VishwasM> |
VishwasM> | In our draft(with the AT&T folks) we did find this feature useful in case
VishwasM> of
VishwasM> | congestion/scalability conditions too. Infact I guess Nokia also did a
VishwasM> study
VishwasM> | on this and came with similar results.
VishwasM> |
VishwasM> | Thanks,
VishwasM> | Vishwas

---

From: "Manral, Vishwas" <[email-masked]>
Date: Sat, 27 Jul 2002 09:33:29 -0400

Hi Yasu,

If both ends of a link do have a link damping feature what problem would it
still not solve. The hellos would not be causing any flap if the lower layer
itself has taken care that the flap, because it would not convey a link up
event till the link showed no failure for some time(as in RPR example
below).

Yes, for congestion case something may be required. We have put that down in
our draft congestion-control draft.

Thanks,
Vishwas

-----Original Message-----
From: Yasuhiro Ohara [mailto:[email-masked]]
Sent: Saturday, July 27, 2002 5:34 PM
To: [email-masked]
Subject: Re: Link Flap Damping

All,

regards.
yasu

VishwasM> Hi Manav,
VishwasM>
VishwasM> Though I do not remember the details(and things have changed a lot
there),
VishwasM> in RPR(802.17) there is something called a "Wait To Restore"(WTR)
timer. A
VishwasM> failed link is required to show no failure for the given period of
time
VishwasM> before being declared working.
VishwasM>
VishwasM> Thanks,
VishwasM> Vishwas
VishwasM>
VishwasM> -----Original Message-----
VishwasM> From: Manav Bhatia [mailto:[email-masked]]
VishwasM> Sent: Friday, July 26, 2002 12:12 PM
VishwasM> To: [email-masked]
VishwasM> Subject: Re: Link Flap Damping
VishwasM>
VishwasM>
VishwasM> Hi Vishwas,
VishwasM> Are you aware of any vendor implementing link flap damping in the
hardware?
VishwasM>
VishwasM> If there are such implementations out there and it is not a
standard then
VishwasM> cant it create problems out there in the wild when you can snoop
HELLOs
VishwasM> coming from the other end but find them not being delivered to
your OSPF
VishwasM> instance because of which the adjacency never comes up?
VishwasM>
VishwasM> Infact understanding the fact that those HELLOs are not being
delivered to
VishwasM> your local OSPF daemon will itself take up some time !!!
VishwasM>
VishwasM> Regards,
VishwasM> Manav
VishwasM> ----- Original Message -----
VishwasM> From: "Manral, Vishwas" <[email-masked]>
VishwasM> To: <[email-masked]>
VishwasM> Sent: Friday, July 26, 2002 10:48 AM
VishwasM> Subject: Re: Link Flap Damping
VishwasM>
VishwasM>
VishwasM> || >       than in OSPF.
VishwasM> | I agree here. Infact check the mail I sent to the list some time
back.
VishwasM> |
VishwasM>
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I
VishwasM> =
VishwasM> | -3 where I agree to what you have said, link flap is best dealt
with the
VishwasM> | lower layer, the closer to hardware the better.
VishwasM> |
VishwasM> | >   2. The OSPF specified MinLSInterval is 5 seconds (RFC 2328,
appendix
VishwasM> B).
VishwasM> | This
VishwasM> | >        is already quite a long time and I don't think further
dampening
VishwasM> is
VishwasM> | required.
VishwasM> | There is a difference here. MinLSInterval does prevent the same
LSA from
VishwasM> | being originated too soon. However this does not prevent the
entire
VishwasM> | adjacencies to have to be reformed/broken. Damping the flap can
prevent
VishwasM> us
VishwasM> | from doing this(in case the thing is not done at a lower layer).
VishwasM> |
VishwasM> | >   3. OSPF is an IGP and, as such, an OSPF instance should span
a single
VishwasM> | routing
VishwasM> | >       domain under a single administrative authority. Hence,
it should
VishwasM> be
VishwasM> | possible
VishwasM> | >       to address and remedy link flapping issues.
VishwasM> | Agreed !!!
VishwasM> |
VishwasM> | >   4. I haven't heard a requirement for such a feature from a
network
VishwasM> | operator
VishwasM> | > (public or enterprise). Has anyone?
VishwasM> | Not exactly, but I guess the study by Cengiz and Steve on faster
VishwasM> convergence
VishwasM> | does talk about advantages of asymmetricaly damping Up/Down
events, where
VishwasM> | and how it is done I guess is left to the implementor. This was
presented
VishwasM> at
VishwasM> | one of the recent NANOG meetings. The study was done on the
Qwest
VishwasM> backbone.
VishwasM> |
VishwasM> | In our draft(with the AT&T folks) we did find this feature
useful in case
VishwasM> of
VishwasM> | congestion/scalability conditions too. Infact I guess Nokia also
did a
VishwasM> study
VishwasM> | on this and came with similar results.
VishwasM> |
VishwasM> | Thanks,
VishwasM> | Vishwas

---

From: Erblichs <[email-masked]>
Date: Sat, 27 Jul 2002 10:45:36 -0700

Ummm,

        I wasn't sure whether I wanted to get involved in this great
        discussion...

        Has anyone seen or invisioned an interaction with "link flap
        dampening" and Moy's OSPF implimentation where he attempts to
        accelerate bi-directional status? Chapt 1, p.2 1.1.1 Optimizations

        Basicly, can a damped link on one side prevent this acceleration
        to occur?

        And should this accelerated method bunch the load on a router and
        thus counter-intuitive to congestion control? Especially with a
        set of routers all coming up at the same time and then the
        bunching of adjacency formations.

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

---

From: Acee Lindem <[email-masked]>
Date: Sat, 27 Jul 2002 17:21:33 -0400

> OSPF to flap", we have to remove Hello. This is obviously not what we

Yasu,

Normally, it is the link up event that is dampened at layer 2 and it is
normally done in a such a way that the OSPF hello packets will
not be received or will be dropped at a low level.

Thanks,
Acee

--
Acee

---

From: Manav Bhatia <[email-masked]>
Date: Mon, 29 Jul 2002 10:03:26 +0530

Hi Vishwas,
Implementing link damping feature at L2 will work only if both the ends of
the link do that. I explained a problem with only one end doing that in one
of my previous mails on the list. There is no backward compatibility and
all the routers would have to be upgraded simultaneously to let peace reign
inside your routing domain. This can be avoided if link flap damping is
correctly and smartly implemented in L3 wherein it can be negotiated while
exchanging the HELLOs with the adjacent router. Even if both ends don't do
that, the side implementing flap damping can atleast inform the sys admin
as to why the adjacency is not coming up with the router at the other end
and the additional time it will take for the adjacency to come provided the
link remains sane till then.

Secondly, in my opinion we must penalize a link more if it flaps severely
or more often than a link which flaps lesser number of times and less
vigorously. Using the WTR we don't differentiate between the two cases
since both of them are advertised if they remain stable for some time
period which is specified in the WTR. And there seems to be no way of doing
that since there is no concept of history being maintained with the
individual links.

Also if L2 flap damping is good enough then why at all do we need to do
that in BGP?

We must understand that informing BGP of the correct next hop (usually
redistributed from the IGPs) is very essential and of utmost importance as
a single change in the IGP next hop can cause a next hop change in many
thousands of BGP routes resulting in massive flaps causing penalties in
forms of money to the provider, besides bringing a lot of instability to
the network.

Moreover it can be put as a generic feature which can work well for both
links flapping and routes redistributed from outside OSPF domain flapping.

I strongly believe that such a feature is best suited at L3!

Regards,
Manav

----- Original Message -----
From: "Manral, Vishwas" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, July 27, 2002 7:03 PM
Subject: Re: Link Flap Damping

| Hi Yasu,
|
| If both ends of a link do have a link damping feature what problem would
it
| still not solve. The hellos would not be causing any flap if the lower
layer
| itself has taken care that the flap, because it would not convey a link
up
| event till the link showed no failure for some time(as in RPR example
| below).
|
| Yes, for congestion case something may be required. We have put that down
in
| our draft congestion-control draft.
|
| Thanks,
| Vishwas
|
| -----Original Message-----
| From: Yasuhiro Ohara [mailto:[email-masked]]
| Sent: Saturday, July 27, 2002 5:34 PM
| To: [email-masked]
| Subject: Re: Link Flap Damping
|
|
| All,
|
| The L2's link flap dampen feature is not enough, since L3 (i.e. OSPF)
| uses its own method to detect link flap. Even if the L2 do not trigger
| up/down events to OSPF process, there will still be a case where a
| OSPF process detects link flaps by Hello.
|
| If one want to say "L2 flap dampening feature is enough to prevent
| OSPF to flap", we have to remove Hello. This is obviously not what we
| want.
|
| regards.
| yasu
|
| VishwasM> Hi Manav,
| VishwasM>
| VishwasM> Though I do not remember the details(and things have changed a
lot
| there),
| VishwasM> in RPR(802.17) there is something called a "Wait To
Restore"(WTR)
| timer. A
| VishwasM> failed link is required to show no failure for the given period
of
| time
| VishwasM> before being declared working.
| VishwasM>
| VishwasM> Thanks,
| VishwasM> Vishwas
| VishwasM>
| VishwasM> -----Original Message-----
| VishwasM> From: Manav Bhatia [mailto:[email-masked]]
| VishwasM> Sent: Friday, July 26, 2002 12:12 PM
| VishwasM> To: [email-masked]
| VishwasM> Subject: Re: Link Flap Damping
| VishwasM>
| VishwasM>
| VishwasM> Hi Vishwas,
| VishwasM> Are you aware of any vendor implementing link flap damping in
the
| hardware?
| VishwasM>
| VishwasM> If there are such implementations out there and it is not a
| standard then
| VishwasM> cant it create problems out there in the wild when you can
snoop
| HELLOs
| VishwasM> coming from the other end but find them not being delivered to
| your OSPF
| VishwasM> instance because of which the adjacency never comes up?
| VishwasM>
| VishwasM> Infact understanding the fact that those HELLOs are not being
| delivered to
| VishwasM> your local OSPF daemon will itself take up some time !!!
| VishwasM>
| VishwasM> Regards,
| VishwasM> Manav
| VishwasM> ----- Original Message -----
| VishwasM> From: "Manral, Vishwas" <[email-masked]>
| VishwasM> To: <[email-masked]>
| VishwasM> Sent: Friday, July 26, 2002 10:48 AM
| VishwasM> Subject: Re: Link Flap Damping
| VishwasM>
| VishwasM>
| VishwasM> || >       than in OSPF.
| VishwasM> | I agree here. Infact check the mail I sent to the list some
time
| back.
| VishwasM> |
| VishwasM>
|
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I
| VishwasM> =
| VishwasM> | -3 where I agree to what you have said, link flap is best
dealt
| with the
| VishwasM> | lower layer, the closer to hardware the better.
| VishwasM> |
| VishwasM> | >   2. The OSPF specified MinLSInterval is 5 seconds (RFC
2328,
| appendix
| VishwasM> B).
| VishwasM> | This
| VishwasM> | >        is already quite a long time and I don't think
further
| dampening
| VishwasM> is
| VishwasM> | required.
| VishwasM> | There is a difference here. MinLSInterval does prevent the
same
| LSA from
| VishwasM> | being originated too soon. However this does not prevent the
| entire
| VishwasM> | adjacencies to have to be reformed/broken. Damping the flap
can
| prevent
| VishwasM> us
| VishwasM> | from doing this(in case the thing is not done at a lower
layer).
| VishwasM> |
| VishwasM> | >   3. OSPF is an IGP and, as such, an OSPF instance should
span
| a single
| VishwasM> | routing
| VishwasM> | >       domain under a single administrative authority.
Hence,
| it should
| VishwasM> be
| VishwasM> | possible
| VishwasM> | >       to address and remedy link flapping issues.
| VishwasM> | Agreed !!!
| VishwasM> |
| VishwasM> | >   4. I haven't heard a requirement for such a feature from
a
| network
| VishwasM> | operator
| VishwasM> | > (public or enterprise). Has anyone?
| VishwasM> | Not exactly, but I guess the study by Cengiz and Steve on
faster
| VishwasM> convergence
| VishwasM> | does talk about advantages of asymmetricaly damping Up/Down
| events, where
| VishwasM> | and how it is done I guess is left to the implementor. This
was
| presented
| VishwasM> at
| VishwasM> | one of the recent NANOG meetings. The study was done on the
| Qwest
| VishwasM> backbone.
| VishwasM> |
| VishwasM> | In our draft(with the AT&T folks) we did find this feature
| useful in case
| VishwasM> of
| VishwasM> | congestion/scalability conditions too. Infact I guess Nokia
also
| did a
| VishwasM> study
| VishwasM> | on this and came with similar results.
| VishwasM> |
| VishwasM> | Thanks,
| VishwasM> | Vishwas

---

From: Manav Bhatia <[email-masked]>
Date: Mon, 29 Jul 2002 10:40:02 +0530

Hi Vishwas,

When the light goes out on the SONET link then it can be easily detected by
the hardware and we can thus comfortably debounce/hold down this event in
or close to the hardware to reduce churn in the upper layers. The problem
comes with the Ethernet technologies deployed so vastly in the POPs where
the above is somewhat difficult since as of now there are no data link
layer signaling protocols (none that i am aware of !) which can inform us
cleanly that we cant talk to our other neighbor. If a wire falls out of my
router then we can come to know of it immediately but if it happens to fall
out of the other end's router then there is no way that i can come to know
of it.

Eventually the software detection (aka HELLOs) has to be used. There is no
way that this can be obviated given the ubiquitous presence of Ethernets
all around us.

We thus ultimately need some sort of flap damping mechanism at the software
layer aka L3.

Regards,
Manav

----- Original Message -----
From: "Manral, Vishwas" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, July 27, 2002 3:44 PM
Subject: Re: Link Flap Damping

| Hi Manav,
|
| Though I do not remember the details(and things have changed a lot
there),
| in RPR(802.17) there is something called a "Wait To Restore"(WTR) timer.
A
| failed link is required to show no failure for the given period of time
| before being declared working.
|
| Thanks,
| Vishwas
|
| -----Original Message-----
| From: Manav Bhatia [mailto:[email-masked]]
| Sent: Friday, July 26, 2002 12:12 PM
| To: [email-masked]
| Subject: Re: Link Flap Damping
|
|
| 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

---

From: "Manral, Vishwas" <[email-masked]>
Date: Mon, 29 Jul 2002 07:06:44 -0400

Hi Manav,

First, some good news. ;-) I hear IEEE is working on failure notification
for Ethernet.

As I see link flap damping, it has nothing to do with the other end but our
own interface. So when we know that we are consistently flapping, we can
have some way to prevent it. I guess all that you say, does not come into
the picture at all in that case.

In OSPF because we have a 3-way handshake hello mechanism, the link would
not come up, and be used for routing table calculation, if either end damped
it.

We can, for precaution sake do flap damping at OSPF layer. Ways to do it
could be: -

http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I=
-3

and

we could actually advertize the link metric with value 0xffff for such
links. So in case there is no other path to a destination the link can still
be used.

We could probably have more opinions on this. Alex/John ??

Thanks,
Vishwas

-----Original Message-----
From: Manav Bhatia [mailto:[email-masked]]
Sent: Monday, July 29, 2002 10:40 AM
To: [email-masked]
Subject: Re: Link Flap Damping

Hi Vishwas,

Regards,
Manav

----- Original Message -----
From: "Manral, Vishwas" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, July 27, 2002 3:44 PM
Subject: Re: Link Flap Damping

| Hi Manav,
|

---

From: Yasuhiro Ohara <[email-masked]>
Date: Tue, 30 Jul 2002 12:53:17 +0900

Hi Manral, Erblichs, Acee:

Forgive me to reply by this all-in-one message for some of previous
e-mails.

First, I have some prerequisions about this discussion. I guess we all
want to decrease Hello-Interval and Dead-Interval to make convergence
more faster, is this right ? I don't think Hello-Interval should be 10
seconds because that's too long. And I am so impatient that I cannot
wait for 40 seconds for my communication being revived each time the
network topology changes.

If we keep this in mind things may be changed bellow.

VishwasM> Hi Yasu,
VishwasM>
VishwasM> If both ends of a link do have a link damping feature what
VishwasM> problem would it still not solve. The hellos would not be
VishwasM> causing any flap if the lower layer itself has taken care
VishwasM> that the flap, because it would not convey a link up event
VishwasM> till the link showed no failure for some time(as in RPR
VishwasM> example below).

What would it be done with the Hellos going through the link which is
down but kept from notifying the upper layer ? It is obviously not
good for L2 switches to keep this traffic in its own buffer and
re-send it. (I believe all of the L2 flap dampening technology won't
do this.)

So, hellos may be dropped anyway whether L2 dampening feature is on or
not (off).

VishwasM> Yes, for congestion case something may be required. We have
VishwasM> put that down in our draft congestion-control draft.

Yes, I've read the draft and it'll be very effective where hello/dead
are 10/40s (or similar). But none of this will solve the problem
essentially.

  - Throttle setup of adjacency
    I guess prioritizing the adjacencies is the most bothering thing
    for network operators. The future world enforcing this to be
    involved is not attractive ...
  - DSCP marking of hello/ack
    This is for congestion and can do nothing with link down.
  - Use other control packets than hello as detect link live-ness
    This is also mainly for congestion I guess.
    Frequency of other control packets than hello is another critical
    issue for OSPF scalability and should be decreased. But in the
    other hand (ideally) the dead interval may not be so long to
    wait these kind of "OSPF update" to occur. Hence we should think
    we can use only the hellos to detect link flaps.

# By the way, though the draft inform me a lot of valuable things,
# I could not understand one part of it. 4.1.2's end paragraph says:
# "Maintaining sequence number counters for different packet types
# may solve this issue" but what is the sequence number and how a
# implementation take care the packet reordering ?

erblichs> Has anyone seen or invisioned an interaction with "link flap
erblichs> dampening" and Moy's OSPF implimentation where he attempts
erblichs> to accelerate bi-directional status? Chapt 1, p.2 1.1.1
erblichs> Optimizations
erblichs>
erblichs> Basicly, can a damped link on one side prevent this
erblichs> acceleration to occur?
erblichs>
erblichs> And should this accelerated method bunch the load on a
erblichs> router and thus counter-intuitive to congestion control?
erblichs> Especially with a set of routers all coming up at the same
erblichs> time and then the bunching of adjacency formations.

Could you explain more detail about this ? I understood this as a
feature to simply make the adjacency to come up faster, and nothing
has to do with the flap dampening.

acee> Normally, it is the link up event that is dampened at layer 2
acee> and it is normally done in a such a way that the OSPF hello
acee> packets will not be received or will be dropped at a low level.

OK, so I feel I can't admit L2's link flap dampening more and more.

If the link up event is dropped and does not come up during the link
physically flaps until someone take care of the link's problem, and if
the link is the only one to reach a place (this is usual case), the
place will be unreach very long time. I guess it's not acceptable.

Today we implicitly dampen the flaps by keeping the hello/dead
interval long (like 10/40s). The result of this dampened link while
flaps is *UP*, realizing "Best effort" Internet policy because some
packet may reach still through the flapping link.

Are we really change this thing ? Can someone easily drop being
unaware of how important the link's live-ness is, even partially ?

VishwasM> Hi Manav,
VishwasM>
VishwasM> First, some good news. ;-) I hear IEEE is working on failure
VishwasM> notification for Ethernet.
VishwasM>
VishwasM> As I see link flap damping, it has nothing to do with the
VishwasM> other end but our own interface. So when we know that we are
VishwasM> consistently flapping, we can have some way to prevent it. I
VishwasM> guess all that you say, does not come into the picture at
VishwasM> all in that case.
VishwasM>
VishwasM> In OSPF because we have a 3-way handshake hello mechanism,
VishwasM> the link would not come up, and be used for routing table
VishwasM> calculation, if either end damped it.

No, I don't think so.

In usual case below:

  [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].
There are still possibilities of dropping Hellos. If the hello/dead
intervals are so short, the frequency of OSPF calculation will be
MinLSInterval (5sec). The network where the route changes each 5 secs
are not acceptable.

Yes, we have one major conflict in OSPF routing:
"Converge fast but don't let a link flap".

VishwasM> We can, for precaution sake do flap damping at OSPF
VishwasM> layer. Ways to do it could be: -
VishwasM>
VishwasM> http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I=-3
VishwasM>
VishwasM> and
VishwasM>
VishwasM> we could actually advertize the link metric with value
VishwasM> 0xffff for such links. So in case there is no other path to
VishwasM> a destination the link can still be used.

That's very similar to what I am looking for ;p)

But how did you recognize the flap ? All I want to know is this.
How did you distinct the flap from the link completely down, when
dead-interval have elapsed without receiving Hello ? How immediately
could you recover the link's availability when the link's flaps
vanished ?

It is worth writing I-D  for experimental/informational use, even
though I admit it's an implementation issue.

VishwasM> We could probably have more opinions on this. Alex/John ??

Really waiting for your reply.

regards !
yasu

---

From: Acee Lindem <[email-masked]>
Date: Tue, 30 Jul 2002 10:05:44 -0400

All,

I think we're digesting too much on the issue of whether or not a
given layer 2 technology can detect a link status change or loss of
connectivity. For the sake of argument, let's say that there are cases
where the layer 2 technology/implementation either doesn't support
link flap dampening or can't reliably detect layer 3 connectivity
loss/gain.

Yasu, Manav,

Irrespective of what is configured for the hello and router dead intervals,
the current value of MinLSInterval is 5 seconds. Even if adjacent routers
can lose and form an adjacency faster than the 5 second interval, they will
not re-originate their router LSAs any faster and routes will not flap. Do you
really feel there is a strong requirement for further dampening? If so, is
this requirement from a network operator? It would seem the best tact
would be to progressively delay link up event processing and/or neighbor
adjacency formation (bad news should always be propagated quickly). Anyway,
I'm not convinced it is necessary but that's not to say you shouldn't proceed.

Thanks,
Acee

--
Acee

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 31 Jul 2002 10:23:04 +0530

Acee and Vishwas,

| I think we're digesting too much on the issue of whether or not a
| given layer 2 technology can detect a link status change or loss of
| connectivity. For the sake of argument, let's say that there are cases
| where the layer 2 technology/implementation either doesn't support
| link flap dampening or can't reliably detect layer 3 connectivity
| loss/gain.

This is not the only issue. What i am looking for is a unified approach
which can take care of both the flapping links/routers and flapping routes
redistributed from outside OSPF domain. This is very important because each
time a router recieves some LSAs it requires SPF computation which takes up
some CPU resources. There is some time delay before it actually triggers
the SPF computation and the time it recieves the LSAs. Now if the CPU is
too busy performing SPF calculation then it may miss out sending HELLOs
which may falsely bring down some adjacenices. In the worst case because of
these new LSAs originated, more adjacencies may go down for the CPU is busy
running the SPF.

Even if we provide link flap damping at L2 there is no way that we can ever
identify flapping routes redistributed from outside OSPF domain.

And once again, if L2 flap damping is enough then why do we have the
concept of route flap damping in BGP which we know is widely used and
deployed.

IGPs are crucial for the operation of BGP since it uses the information
provided by the IGPs to calculate the nexthop to reach the exit router. IGP
calculates the best next hop to reach the exit router and if IGP changes
then we have to change the next hop in tens of thousands of BGP routes
which are being advertised to the whole world. And there is no flap damping
mechanism which exits in BGP which can detect changes in the next hop of
BGP routes and somehow damp them or straighten them out.

|
| Irrespective of what is configured for the hello and router dead
intervals,

We dont care for these values in the current context.

| the current value of MinLSInterval is 5 seconds. Even if adjacent routers
| can lose and form an adjacency faster than the 5 second interval, they
will
| not re-originate their router LSAs any faster and routes will not flap.

What if it happens every 7 secs.

| Do you
| really feel there is a strong requirement for further dampening? If so,
is
| this requirement from a network operator?
| It would seem the best tact
| would be to progressively delay link up event processing and/or neighbor
| adjacency formation (bad news should always be propagated quickly).
Anyway,
| I'm not convinced it is necessary but that's not to say you shouldn't
proceed.

Another problem which exists with damping enabled at L2 is that the
interface becomes unusable and the networks on the other side of this
interface get isolated when we declare the link as down. It is not limited
to only OSPF. Things will become clear with this diagram below.

----------------
| Internet cloud |
----------------
           |
   -----------
   |  Rtr A    |
   -----------
          | link A
----------------
| local network |
----------------

If for e.g. link A is flapping for some reason or the router is crashing
after some time period (30 secs ~ 30 mins) then if link flap damping is
enabled at L2 then after some threshold is reached link A will be declared
as down. It will continue to be declared down till some figure of merit
falls below another threshold and we start using it again. During the
period when this link is being damped the local network cannot reach the
internet cloud and vica versa. This is not at all desirable. Our intention
is to just let OSPF remain undisturbed with the continued perturbations we
see on this link A. Implementing link flap damping at L3 will enable us to
do just that.

Second, link flap damping can be enabled at L2 only if the link flaps in
milli secs or a time of some nearby order. What if it flaps every 30 mins.
Is it then proper to declare the link as down? No .. but from the OSPF
perspective if the nexthop is very vital and is being exported to BGP then
the system administrator can set it so.

It should be possible to configure flap damping to handle short term severe
route flaps and chronic milder route flaps (a pattern of occasional drops
over a long time period). The former would require a fast decay and low
threshold (allowing a small number of consecutive flaps to cause a
link/route to be suppressed, but allowing it to be reused after a
relatively short period of stability).  The latter would require a very
slow decay and a higher threshold and might be appropriate for links/routes
for which there was an alternate path of similar bandwidth.

A less aggressive suppression can be applied to the case where no alternate
path exists  In the simplest case, a more aggressive suppression should be
applied if any alternate route/path exists.

It might also be desirable to configure a different set of thresholds for
routes which rely on switched services and may disconnect at times to
reduce connect charges.  Such routes might be expected to change state
somewhat more often, but should be suppressed if  continuous state changes
indicate instability.

All of these arguments lead me to believe that the place best to damp any
flaps is L3.

Thanks and Regards,
Manav

---

From: Erblichs <[email-masked]>
Date: Wed, 31 Jul 2002 09:20:12 -0700

Group,

        My questions are in two directions, dampening
        and congestion.

        Has anybody even read, looked, executed Moy's OSPF
        implimentation?
        Moy's optimatization applies to neighbor conversations.

        If you dampen a link coming up with a hello packet
        on that link, then it won't be seen depending on the
        amount of time the link is dampened. Thus, his optimation
        could be wasted in my opinion.

        But my 2nd thought has to due with congestion and that
        a percentage of these neighbor conversations becoming
        adjacencies.

        By speeding up to the 2-way state, if a number of hellos
        are recieved, then Moy's implimentation will send out
        immediate hellos.

        This may be okay for a couple of hellos
        recvd at once, but if the router becomes the DR or BDR,
        then a number of adjs will try to be formed and lead
        to the adj congestion limits.

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

---

From: Yasuhiro Ohara <[email-masked]>
Date: Thu, 1 Aug 2002 02:15:42 +0900

Hi erblichs,

None of us are trying to dampen Hello packets itself. So the dampening
feature will be nothing to do with the Moy's optimization.

About the congestion from simultaneous adjacencies bringing up,
I guess and hope dampening feature touches nothing (it does neither
solve the problem nor aggravate the problem). The techniques described
in congestion-control draft will be used for it.

regards,
yasu

erblichs> Group,
erblichs>
erblichs>         My questions are in two directions, dampening
erblichs>         and congestion.
erblichs>
erblichs>
erblichs>         Has anybody even read, looked, executed Moy's OSPF
erblichs>         implimentation?
erblichs>         Moy's optimatization applies to neighbor conversations.
erblichs>
erblichs>         If you dampen a link coming up with a hello packet
erblichs>         on that link, then it won't be seen depending on the
erblichs>         amount of time the link is dampened. Thus, his optimation
erblichs>         could be wasted in my opinion.
erblichs>
erblichs>         But my 2nd thought has to due with congestion and that
erblichs>         a percentage of these neighbor conversations becoming
erblichs>         adjacencies.
erblichs>
erblichs>         By speeding up to the 2-way state, if a number of hellos
erblichs>         are recieved, then Moy's implimentation will send out
erblichs>         immediate hellos.
erblichs>
erblichs>         This may be okay for a couple of hellos
erblichs>         recvd at once, but if the router becomes the DR or BDR,
erblichs>         then a number of adjs will try to be formed and lead
erblichs>         to the adj congestion limits.
erblichs>
erblichs>         Mitchell Erblich
erblichs>         ===========================