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