Re: BGP-4 changes
Yakov Rekhter <yakov@cisco.com> Fri, 30 August 1996 15:11 UTC
Received: from ietf.org by ietf.org id aa25733; 30 Aug 96 11:11 EDT
Received: from cnri by ietf.org id aa25729; 30 Aug 96 11:11 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa08217; 30 Aug 96 11:11 EDT
Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id KAA28066
for idr-outgoing; Fri, 30 Aug 1996 10:34:12 -0400 (EDT)
Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by
merit.edu (8.7.5/merit-2.0) with SMTP id KAA28057 for <bgp@merit.edu>;
Fri, 30 Aug 1996 10:34:06 -0400 (EDT)
Received: by interlock.ans.net id AA12889
(InterLock SMTP Gateway 3.0 for bgp@ans.net);
Fri, 30 Aug 1996 10:34:05 -0400
Received: by interlock.ans.net (Internal Mail Agent-1);
Fri, 30 Aug 1996 10:34:05 -0400
Message-Id: <199608301437.HAA02081@hubbub.cisco.com>
To: bgp@ans.net
Cc: "John G. Scudder" <jgs@ieng.com>
Subject: Re: BGP-4 changes
Date: Fri, 30 Aug 96 07:33:59 PDT
Sender: ietf-archive-request@ietf.org
From: Yakov Rekhter <yakov@cisco.com>
X-Orig-Sender: owner-idr@merit.edu
Precedence: bulk
Folks,
How about if we'll use John's text (with some minor editorial
changes) ?
Add to 5.1.4:
When a route with the MULTI_EXIT_DISC attribute is received over an
external link it must be possible (based on local configuration) to
remove or override the value of the attribute. This shall be done
prior to determining the degree of preference of the route.
Replace 9.1.2.1 with the following:
In its Adj-RIBs-In a BGP speaker may have several routes to the same
destination that have the same degree of preference. The local
speaker can select only one of these routes for inclusion in the
associated Loc-RIB. The local speaker considers all routes
with the same degress of preference, both those received from
internal peers, and those received from external peers.
The following tie-breaking procedure assumes that for each candidate
route all the BGP speakers within an autonomous system can ascertain
the cost of a path (interior distance) to the address depicted by the
NEXT_HOP attribute of the route.
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.
a) Remove from consideration routes with less-preferred
MULTI_EXIT_DISC attributes, according to the following
procedure:
for m = all routes still under consideration
for n = all routes still under consideration
if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
remove route m from consideration
In the pseudo-code above, MED(n) is a function which returns
the value of route n's MULTI_EXIT_DISC attribute. If route n
has no MULTI_EXIT_DISC attribute, the function returns the
highest possible MULTI_EXIT_DISC value, i.e. 2^32-1.
Similarly, neighborAS(n) is a function which returns the
neighbor AS from which the route was received.
b) Remove from consideration any routes with less-preferred
interior cost, according to the following procedure. If the
BGP speaker has no notion of the cost of a path, skip this
step (equivalently, consider all routes to have equal costs).
for m = all routes still under consideration
for n = all routes in still under consideration
if (cost(n) is better than cost(m))
remove m from consideration
In the pseudo-code above, cost(n) is a function which returns
the cost of the path (interior distance) to the address
depicted by the NEXT_HOP attribute of the route.
c) If at least one of the candidate routes was received from
an external peer from 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.
Yakov.
- Re: BGP-4 changes John G. Scudder
- Re: BGP-4 changes Curtis Villamizar
- Re: BGP-4 changes John G. Scudder
- Re: BGP-4 changes Yakov Rekhter
- Re: BGP-4 changes Curtis Villamizar
- BGP-4 changes Yakov Rekhter
- Re: BGP-4 changes Rich Woundy
- Re: BGP-4 changes Yakov Rekhter
- Re: BGP-4 changes John G. Scudder
- Re: BGP-4 changes rwoundy
- Re: BGP-4 changes rwoundy
- RE: BGP-4 changes rwoundy
- Re: BGP-4 changes rwoundy
- Re: BGP-4 changes Yakov Rekhter
- Re: BGP-4 changes Yakov Rekhter
- Re: BGP-4 changes Yakov Rekhter
- Re: BGP-4 changes John G. Scudder
- Re: BGP-4 changes Curtis Villamizar
- RE: BGP-4 changes NITTMANN Michael (MSMail)
- RE: BGP-4 changes John G. Scudder
- Re: BGP-4 changes Curtis Villamizar