[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Re: BGP path hunting, MRAI timer and Path Length Damping

Thanks Sriram for this quote from RFC 4098:

  http://tools.ietf.org/html/rfc4098#section-3.12

It makes no reference to RFC 1771's specific exclusion of
withdrawals from the MRAI mechanism.  However, that exclusion
was in a separate paragraph so the authors may have missed it or
considered it unimportant.

The text you quoted was added to the I-D between February and
June 2002.


http://tools.ietf.org/html/draft-ietf-bmwg-conterm-02#section-4.5.2


Below my signature is how the RFC 1771 text:

  http://tools.ietf.org/html/rfc1771#section-9.2.3.1

differs from the same section in RFC 4271:

  http://tools.ietf.org/html/rfc4271#section-9.2.1.1

I wonder if router behaviour really did change before January
2006's RFC 4271.

The change regarding MRAI and withdrawals is in the the I-D
versions which lead to RFC 4271 17 (Jan 2002) and 18 (Oct 2002):

http://tools.ietf.org/html/draft-ietf-idr-bgp4-17#section-9.2.1.1
http://tools.ietf.org/html/draft-ietf-idr-bgp4-18#section-9.2.1.1

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.

Thanks John for the pointer to the "Delayed Choice in Routing
Convergence" paper of late 2000 or early 2001, I guess:


http://www.cs.toronto.edu/syslab/courses/csc2209/06au/papers/bgp.pdf

I read some of it with great interest.  I don't have time to
read it all now.

On page 186 the authors write that some routers used a single 30
second timer for all updates to a particular peer, which tended
to greatly slow down convergence.

This paragraph makes me think their research was in the days
when most or all routers did not delay withdrawals with the MRAI
timer:

   At least one major router vendor has made an implementation
   decision to apply MinRouteAdver to both announcements and
   withdrawals. A discussion of the motivation and engineering
   tradeoffs for applying MinRouteAdver to withdrawals is
   outside the scope of this paper and remains an active area
   of our current research.

So this research probably is not directly relevant to the
pattern of behavior I worked out in the previous messages.

I would really appreciate someone with more experience with BGP
checking how I worked out that behavior.

If that pattern is the sole or primary cause of "path hunting",
then it seems that this significant problem can be attributed to
the change in the BGP RFC, maybe the I-Ds which lead to it and
whatever decisions "one major router vendor" made around late 2000.

  - Robin



RFC 1771 >> RFC 4271

   The parameter MinRouteAdvertisementInterval determines the
   minimum amount of time that must elapse between advertisement

+  and/or withdrawal

   of routes to a particular destination from a single BGP
   speaker. 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 from a single BGP speaker that
   advertise feasible routes

+  and/or withdrawal of unfeasible routes

   to some common set of destinations received from BGP speakers
   in neighboring autonomous systems 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 single BGP speaker
   that advertise feasible routes

+  and/or withdrawal of unfeasible routes

   to some common set of destinations received from BGP speakers
   in neighboring autonomous systems 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,

-  this procedure does not apply for routes receives from other
-  BGP speakers in the same autonomous system.

+  either (a) the MinRouteAdvertisementIntervalTimer used for
+  internal peers SHOULD be shorter than the
+  MinRouteAdvertisementIntervalTimer used for external peers,
+  or (b) the procedure describe in this section SHOULD NOT
+  apply to routes sent to internal peers.

-  To avoid long-lived black holes, the procedure does not apply
-  to the explicit withdrawal of unfeasible routes (that is,
-  routes whose destinations (expressed as IP prefixes) are
-  listed in  the WITHDRAWN ROUTES field of an UPDATE message).

   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
   MinRouteAdvertisementIntervalTimer, the last route selected
   SHALL be advertised at the end of
   MinRouteAdvertisementIntervalTimer.





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