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. > > >
- Re: BGP:tie-breaking algorithm enhancement propos… Alexey Zinin
- BGP:tie-breaking algorithm enhancement proposal Alvaro Retana