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" <VishwasMNETPLANE.COM>
To: <OSPFDISCUSS.MICROSOFT.COM>
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:yasuSFC.WIDE.AD.JP]
| Sent: Saturday, July 27, 2002 5:34 PM
| To: OSPFDISCUSS.MICROSOFT.COM
| 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:manavSAMSUNG.COM]
| VishwasM> Sent: Friday, July 26, 2002 12:12 PM
| VishwasM> To: OSPFDISCUSS.MICROSOFT.COM
| 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" <VishwasMNETPLANE.COM>
| VishwasM> To: <OSPFDISCUSS.MICROSOFT.COM>
| 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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]