[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Re: BGP path hunting, MRAI timer and Path Length Damping
[replies directed to firstname.lastname@example.org; rrg bcc'd]
On Jun 21, 2007, at 11:22 AM, Robin Whittle wrote:
Tony, can you tell us the background for this change to the
scope of the MRAI timer? I imagine there was a strong reason,
since the removed text talks about avoiding long-lived
black-holes as being the reason to exempt withdrawals from the
MRAI delay system.
Well I'm not Tony but a perusal of the IDR mailing list from 2002
quickly reveals the below message which introduces substantially the
same text as is found in RFC 4271. In the cited text, Pedro argues
that one cannot readily distinguish in BGP between "good news" and
"bad news" and thus it makes no sense to treat withdraws differently.
(N.b. the archive at ietf.org seems to only extend back to June 1,
2003. I've already suggested the IDR co-chairs look into this.)
Subject: BGP4 -17 version
Date: Mon, 25 Mar 2002 07:31:31 -0800
From: Yakov Rekhter <email@example.com>
In view of the last paragraph in the attached, how about if 188.8.131.52
be replaced with the following:
184.108.40.206 Frequency of Route Advertisement
The parameter MinRouteAdvertisementInterval determines the
minimum amount of time that must elapse between advertisement
and/or withdrawal of routes to a particular destination by a
BGP speaker to a peer. This rate limiting procedure applies on
a per-destination basis, although the value of
MinRouteAdvertisementInterval is set on a per BGP peer basis.
Two UPDATE messages sent by a BGP speaker to a peer that advertise
feasible routes and/or withdrawal of unfeasible routes to some
common set of destinations MUST be separated by at least
MinRouteAdvertisementInterval. Clearly, this can only be achieved
precisely by keeping a separate timer for each common set of
destinations. This would be unwarranted overhead. Any technique
which ensures that the interval between two UPDATE messages sent
from a BGP speaker to a peer that advertise feasible routes
and/or withdrawal of unfeasible routes to some common set of
destinations will be at least MinRouteAdvertisementInterval,
and will also ensure a constant upper bound on the interval is
Since fast convergence is needed within an autonomous system,
either (a) the MinRouteAdvertisementInterval used for internal
peers SHOULD be shorter than the MinRouteAdvertisementInterval
used for external peers, or (b) procedure describe in this
section SHOULD NOT apply for routes sent to internal peers.
This procedure does not limit the rate of route selection, but
only the rate of route advertisement. If new routes are selected
multiple times while awaiting the expiration of
MinRouteAdvertisementInterval, the last route selected SHALL be
advertised at the end of MinRouteAdvertisementInterval.
------- Forwarded Message
Date: Tue, 05 Mar 2002 10:50:02 -0800
From: Pedro Roque Marques <firstname.lastname@example.org>
To: Alex Zinin <email@example.com>
Subject: Re: RFC Violation
Alex Zinin writes:
> I see your point. Note that when you are sending a WITHDRAWN, you
> know it is a bad news.
A link up event will often cause a router to send withrawns as it
changes it's best path from one that it's policy and/or ibgp flooding
rules allow it to advertise to one that is rejected.
The inverse is true for a link down event...
I still maintain that it is not possible in BGP to distinguish if an
update corresponds to a link up/down event... or what information you
wish to send fast/slow.
I also believe that it is a major mistake to threat advertisements
differently than withrawns, specially from a queuing/timing point of
view. The only thing you are going to get out of that is weird
blackholes and more instability...
AFAIK, no major vendor implements their advertisement
rate-controller/queueing in a way as to threat updates and withrawns
------- End of Forwarded Message
to unsubscribe send a message to firstname.lastname@example.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg