Re: BGP:tie-breaking algorithm enhancement proposal

Alexey Zinin <zinin@amtsun.amt.ru> Fri, 28 January 2000 10:27 UTC

Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA19881 for <idr-archive@nic.merit.edu>; Fri, 28 Jan 2000 05:27:04 -0500 (EST)
Received: by segue.merit.edu (Postfix) id ADB4B5DDA9; Fri, 28 Jan 2000 05:26:36 -0500 (EST)
Delivered-To: idr-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56) id 8DBC25DDA5; Fri, 28 Jan 2000 05:26:36 -0500 (EST)
Received: from amtsun.amt.ru (amtsun.amt.ru [212.111.64.19]) by segue.merit.edu (Postfix) with ESMTP id 9F8F85DDA3 for <idr@merit.edu>; Fri, 28 Jan 2000 05:26:33 -0500 (EST)
Received: (from zinin@localhost) by amtsun.amt.ru (8.8.8/8.7.3.1) id NAA05213; Fri, 28 Jan 2000 13:26:15 +0300 (MSK)
From: Alexey Zinin <zinin@amtsun.amt.ru>
Message-Id: <200001281026.NAA05213@amtsun.amt.ru>
Subject: Re: BGP:tie-breaking algorithm enhancement proposal
To: aretana@cisco.com
Date: Thu, 28 Jan 0100 13:26:15 +0300
Cc: idr@merit.edu
In-Reply-To: <Pine.GSO.4.10.10001270936070.4293-100000@aretana-u10.cisco.com> from "Alvaro Retana" at Jan 27, 0 10:04:52 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: 8bit
Sender: owner-idr@merit.edu
Precedence: bulk

Alvaro:

I know of at least one IX which has suffered and still
is suffering from this change in the path selection
process (I was handling this case).

I think what you propose may be a useful enhancement, but any
changes to the route selection algo must be implemented
with a configuration option, allowing to revert to standard
behavior, since people may (and actually do) rely on the Router-ID
as the determinating factor.

Alex.

> 
> 
> The current BGP4 draft (draft-ietf-idr-bgp4-09) reads:
> 
> -------------------------------------------------------------------
> 9.1.2.1 Breaking Ties (Phase 2)
> .....
>    The tie-breaking algorithm begins by considering all equally
>    preferable routes and then selects routes to be removed from
>    consideration.  The algorithm terminates as soon as only one route
>    remains in consideration.  The criteria must be applied in the order
>    specified.
> 
> .....
>       c) If at least one of the candidate routes was received from an
>       external peer in a neighboring autonomous system, remove from
>       consideration all routes which were received from internal peers.
> 
>       d) Remove from consideration all routes other than the route that
>       was advertised by the BGP speaker whose BGP Identifier has the
>       lowest value.
> -------------------------------------------------------------------
> 
> I would like to propose the following enhancement (to be put in place of
> the last step listed above):
> 
>       d) If the remaining routes are all external, remove from consideration 
>       all routes except the one that was received first and any others with 
>       the same BGP Identifier as it (the one received first).
> 
>       e) Remove from consideration all routes other than the ones advertised 
>       by the BGP speaker whose BGP Identifier has the lowest value.
> 
> 
> 
> In summary, the change will allow a BGP speaker to keep the oldest
> external route as the best path, if all the other conditions are the same.  
> Except for the case where more than one route is received from the same
> eBGP peer.
> 
> In keeping the oldest external, the number of unnecesary routing updates
> can be lowered.  Note that by advertising a new bestpath (if all the
> attributes, except the BGP Identifier, are the same), the exit point will
> not change.
> 
> In the case where the BGP Identifier is the same, then the "normal"
> procedure is used.
> 
> Any/all comment are welcome. :-)
> 
> Alvaro.
> 
> 
>