Subject: RE: I-BGP Oscillations

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 7 Jun 2002 11:10:10 -0400

->   Why not, IBGP Dampening is what I have been thinking aboute since
-> this problem was first exposed to IETF....

> The problem with dampening is that you're just hiding the churn (making it
> slower), not fixing it. :-(

By dampening the route that is oscillation due to MED in a certain
configuration. You either remove the MED attribute affecting the decision
process and thus allow other routes to get preference or you completely
remove the route from being a candidate if its oscillating too much. Thus
you totally disable the oscillation and churn condition. Broadcasting other
routes to stop an oscillating route might affect the decision process and
stop the churn, but its like hitting a
nail with a sledge hammer.  Why should we expose the network to more
redundant
routes? I am sure, we will have many more legitimate opportunities to do so,
but
not to stop a bug in the protocol.

Please review proposed workaround solutions sited in section 4.3 (item 2, 3)
and section 5.2 (item 1,2) of draft-ietf-idr-route-oscillation-01.txt. I
dont think what I am proposing is very far from these solutions being done
automatically by
the MED induced route oscillation detection mechanism.

-> Note that the answer 'ibgp dampening' that is certain to pop up in
-> peoples minds by association is a bit misleading.

> I agree that iBGP dampening is not the answer.  However, a
> "dampening-like" (no penalties) mechanism to detect the oscillation and
> then act on it, would work.  Obviously, the oscillation characteristics of
> a MED churn are not the same as the ones of "normal" flapping.

Can you be more specific on what you mean by "MED churn are not the same as
the ones of "normal" flapping:.

> We had run some numbers a while back (maybe a year and a half ago) on data
> from backbones experiencing the MED churn, and found that only about 1-2%
> of the routes were **candidates** to oscillate.  IMHO, the state and extra
> information is not significant. ;-)

what was the frequency of oscillation?
 
What was the impact to the router that you tested? 

Also, what was the memory consumption levels during this period of
instability?

Thanks,

Ben

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 7 Jun 2002 13:49:49 -0400 (EDT)

On Fri, 7 Jun 2002, Abarbanel, Benjamin wrote:

Ben:

-> Please review proposed workaround solutions sited in section 4.3 (item
-> 2, 3) and section 5.2 (item 1,2) of
-> draft-ietf-idr-route-oscillation-01.txt. I dont think what I am
-> proposing is very far from these solutions being done automatically by
-> the MED induced route oscillation detection mechanism.

I think someone else mentioned before that the potential workarounds in
the idr-route-oscillation draft were not considered acceptable by network
operators -- at least not at the time we first brought the issue up at
IETF and NANOG...

-> -> Note that the answer 'ibgp dampening' that is certain to pop up in
-> -> peoples minds by association is a bit misleading.
->
-> > I agree that iBGP dampening is not the answer.  However, a
-> > "dampening-like" (no penalties) mechanism to detect the oscillation and
-> > then act on it, would work.  Obviously, the oscillation characteristics of
-> > a MED churn are not the same as the ones of "normal" flapping.
->
-> Can you be more specific on what you mean by "MED churn are not the
-> same as the ones of "normal" flapping:.

In short... For the MED churn to occur, you need a group of routes to meet
the "requirements" (they're changing because of each other)...in "normal"
flapping, each route flaps independently (even though they may all flap
for the same reason: a peer reset, for example).

-> > We had run some numbers a while back (maybe a year and a half ago) on data
-> > from backbones experiencing the MED churn, and found that only about 1-2%
-> > of the routes were **candidates** to oscillate.  IMHO, the state and extra
-> > information is not significant. ;-)
->
-> what was the frequency of oscillation?

Because of our implementation, close to one minute. ;-)  But when we saw
it in a multi-vendor backbone, the frequency varied (mostly faster).

-> What was the impact to the router that you tested? Also, what was the
-> memory consumption levels during this period of instability?

They were live routers. ;-)  No visible changes in performance, memory
utilization, etc..  Some transient loops and constantly changing routes
was what brought our attention to it. :-)

:-)

Alvaro.