To: idr@merit.edu
Subject: BGP4 -17 version
Date: Mon, 25 Mar 2002 07:31:31 -0800
From: Yakov Rekhter <yakov@juniper.net>
Sender: owner-idr@merit.edu
Folks,
In view of the last paragraph in the attached, how about if 9.2.1.1
be replaced with the following:
9.2.1.1 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
acceptable.
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 <roque@juniper.net>
To: Alex Zinin <azinin@nexsi.com>
cc: <idr@merit.edu>
Subject: Re: RFC Violation
Alex Zinin writes:
> Pedro,
> I see your point. Note that when you are sending a WITHDRAWN, you
> know it is a bad news.
Alex,
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
differently.
Pedro.
------- End of Forwarded Message