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


--
to unsubscribe send a message to rrg-request@psg.com 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