Re: Addr: Local Preference Computation
Dimitry Haskin <dhaskin@baynetworks.com> Fri, 23 August 1996 15:34 UTC
Received: from ietf.org by ietf.org id aa29687; 23 Aug 96 11:34 EDT
Received: from cnri by ietf.org id aa29683; 23 Aug 96 11:34 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa09017; 23 Aug 96 11:34 EDT
Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id KAA13309
for idr-outgoing; Fri, 23 Aug 1996 10:50:14 -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 KAA13304 for <bgp@merit.edu>;
Fri, 23 Aug 1996 10:50:11 -0400 (EDT)
Received: by interlock.ans.net id AA01022
(InterLock SMTP Gateway 3.0 for bgp@ans.net);
Fri, 23 Aug 1996 10:50:09 -0400
Received: by interlock.ans.net (Internal Mail Agent-2);
Fri, 23 Aug 1996 10:50:09 -0400
Received: by interlock.ans.net (Internal Mail Agent-1);
Fri, 23 Aug 1996 10:50:09 -0400
Date: Fri, 23 Aug 96 10:50:02 EDT
Sender: ietf-archive-request@ietf.org
From: Dimitry Haskin <dhaskin@baynetworks.com>
Message-Id: <9608231450.AA10815@pobox.BayNetworks.com>
To: bgp@ans.net, rwoundy@vnet.ibm.com
Subject: Re: Addr: Local Preference Computation
X-Orig-Sender: owner-idr@merit.edu
Precedence: bulk
Richard, > To: BGP Working Group <bgp@ans.net> > Subject: Addr: Local Preference Computation > > Folks, > > Well, here it is; your comments are solicited... > > -- Richard Woundy, IBM > > > Incorporating Multiple Policy Criteria into the Local Preference > ================================================================ > > Richard Woundy > IBM > rwoundy@vnet.ibm.com > 8/23/96 > > > Summary > ------- > > Most current BGP router implementations introduce other tie-breakers, > besides the tie-breakers listed in (RFC-1771), to the BGP path selection > process. These other tie-breakers usually include shortest AS path > length and lowest origin code, and are hard-coded into the router > software. Because the existence and the ordering of such tie-breakers > are not standardized nor universally accepted, I-BGP route loops are > likely when routers from different vendors are deployed in a single BGP > autonomous system. > > This memo recommends an approach in which the ISP's policies concerning > AS path length, origin code, and other factors, are folded into the > I-BGP local preference value. The BGP border router calculates the local > preference using a linear function with user-configurable weighting > factors. As an additional feature, the router operator may specify > additional policy statements that increment or decrement (not merely > set) the local preference value. > > This idea was originally suggested by Paul Traina in the IDR Working > Group meeting at the Montreal IETF (June 1996), but the author accepts > responsibility for all errors in this memo. > With all respect, this idia has been suggested to IDR WG a number of times in the past. Indirectly it is alluded to in RFC-1772 (Section 6). Bay has been using bgp path attribute parameters to calculate LOCAL_PREF in its BGP-4 implementation since the intial BGP-4 release a few years ago. On a more constructive note, Bay has been using the following simple equation to calculate LOCAL_PREF (if it is not explicitly set by a policy): LOCAL_PREF = 8191 - (<ORIGIN> == IGP ? 0 : 4096) - <AS path weight> <AS path weight> is a sum of weight values associated with AS numbers listed in the route's AS_PATH attribute. These weight values can be configured or, if not configured, default to 8. Dimitry
- Re: Addr: Local Preference Computation Curtis Villamizar
- Re: Addr: Local Preference Computation John G. Scudder
- Re: Addr: Local Preference Computation Joel Halpern
- Re: Addr: Local Preference Computation John G. Scudder
- Re: Addr: Local Preference Computation Curtis Villamizar
- Addr: Local Preference Computation rwoundy
- Re: Addr: Local Preference Computation Dimitry Haskin