Subject: Fw: Link Flap Damping

From: Yasuhiro Ohara <[email-masked]>
Date: Wed, 3 Jul 2002 18:26:29 +0900

Swati, it seems you failed to post this mail to ML.
And the link to the document:

    http://www.fictitious.org/ospf-omp/ospf-omp.txt
    http://www.fictitious.org/omp/

regards.
yasu

Subject: Re: Link Flap Damping
From: Swati Rastogi <[email-masked]>
To: Yasuhiro Ohara <[email-masked]>
Date: Wed, 3 Jul 2002 02:01:32 -0700 (PDT)

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

OSPF will stop using a particular link/route only if
it finds that the particular link/router is *very*
unstable. This is the same as that followed by BGP.
Each time a link/router flaps there is a figure of
merit (call it penalty) associated with the
link/router which should be increased. If it goes
beyond one threshold we know that the link is really
really BAD and that we mustn't use it. Otherwise if
the frequency of flapping is not much then OSPF will
still recognize it and use it.

With time the Fig of Merit will reduce (say
exponentially).

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

But the same happens in BGP. Even if there is only one
route to a destination and if it flaps then the whole
of network cannot reach that particular destination.
Flap Damping is regardless of whether we have
substitute backup routes or not.

OR you can also do another thing. Damp the
routes/links if you know that you have some other
routes to reach those destinations.

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

I thought it applied to the general routing as a
whole.

>     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 ?

Oh yes we can certainly advertise some redistributed
routes from OSPF directly to BGP after applying some
suitable filters.

> Should we advertise some aggregated
> route ? Even in the
>     case directly advertised, BGP flap dampening
> will do something ...

NOt many BGP speakers run route flap damping and even
if they do then it is only for its EBGP peers and not
IBGP.

>     But I'm not confident I'm a little short in
> operations ... :p)
>
> 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.

Can you give me a link to any such document. It will
be nice and instructive reading for me.

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

what has been vexing me since i started pondering over
this issue is the apparent difference between BGP and
OSPF .. wherin this scheme works fine in BGP but will
fail for OSPF :-(

Any Clues anyone?
> regards.
> yasu

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

---

From: Amit Srivastava <[email-masked]>
Date: Wed, 3 Jul 2002 03:28:55 -0700

Hi All,
   I have a simple doubt:-

Suppose i have two n/w's one router is common on both
the n/w let us call it as R0.Now R0 is in full state
with both R1 and R2 routers on differnet n/w's
          Now suppose that R1 crashes suddenly so the
LSA's of this router would remain in the R0 and R2.Now
after router dead interval the R0 can flush the LSA's
of R1 by originating new LSA with cost as
infinitly.Now zebra is now doing like this.
         Does any one know how the CISCO is doing is
CISCO performing the above approach or not.
Regards
Amit

---

From: Anton Smirnov <[email-masked]>
Date: Wed, 3 Jul 2002 14:08:13 +0200

Amit,
   R0 must not flush R1's LSA only on the ground that they lost direct
neighborship. This LSA (s) should reside in LSDB until they are MAXAGEd. R0
and/or R2 may only update their own LSA(s) to reflect change in set of
neighbors.
   That is what standard requires to do and what - I hope - both Cisco and
Zebra do.
   There are nuances, though, for DC connections. But I think you are
talking about usual broadcast networks.

Anton

---

From: Enrico Dutti <[email-masked]>
Date: Wed, 3 Jul 2002 16:59:00 +0200

Hi,

I'm looking for the document:
  draft-ietf-ospf-extattr-00.txt
but I'm not able to find it... Can anyone help?
If it's not possible it would be enough to know the scope of type 8 LSAs...
Thank you very much

Enrico Dutti