[replies directed to idr ietf.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.)
--John
> To: idrmerit.edu
> Subject: BGP4 -17 version
> Date: Mon, 25 Mar 2002 07:31:31 -0800
> From: Yakov Rekhter <yakovjuniper.net>
> Sender: owner-idrmerit.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 <roquejuniper.net>
> To: Alex Zinin <azininnexsi.com>
> cc: <idrmerit.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
_______________________________________________
Idr mailing list
Idrietf.org
https://ww
w1.ietf.org/mailman/listinfo/idr
|
