Re: BGP4 stuff: Local Preference Computation

Curtis Villamizar <curtis@ans.net> Wed, 04 September 1996 23:34 UTC

Received: from ietf.org by ietf.org id aa12178; 4 Sep 96 19:34 EDT
Received: from cnri by ietf.org id aa12172; 4 Sep 96 19:34 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa18237; 4 Sep 96 19:34 EDT
Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id SAA07068 for idr-outgoing; Wed, 4 Sep 1996 18:55:23 -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 SAA07063 for <bgp@merit.edu>; Wed, 4 Sep 1996 18:55:20 -0400 (EDT)
Received: by interlock.ans.net id AA20691 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Wed, 4 Sep 1996 18:55:18 -0400
Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 4 Sep 1996 18:55:18 -0400
Message-Id: <199609042254.SAA07748@brookfield.ans.net>
To: Cristina Radelescu-Banu 617/890-1001 <cristina@midnight.com>
Cc: bgp@ans.net, rwoundy@vnet.ibm.com, jgs@ieng.com
Reply-To: curtis@ans.net
Subject: Re: BGP4 stuff: Local Preference Computation
In-Reply-To: Your message of "Wed, 04 Sep 1996 15:34:29 EDT." <199609041934.PAA00467@rasarit.midnight.com>
Date: Wed, 04 Sep 1996 18:54:46 -0400
Sender: ietf-archive-request@ietf.org
From: Curtis Villamizar <curtis@ans.net>
X-Orig-Sender: owner-idr@merit.edu
Precedence: bulk

In message <199609041934.PAA00467@rasarit.midnight.com>om>, Cristina Radulescu-Ban
u writes:
> 
> 	I have some problems in implementing BGP4, and if you could
> clarify some of them , this would be great.
> 
> 	I understood that LOCAL_PREF is used as degree of preference only for
> the BGP4 speakers located in the SAME Autonomous System. The Degree of

That's MED.  LOCAL_PREF has always been compared regardless of AS.

> Preference is something totally different, it is used both for the BGP
> Peers in the same and in the neighbor AS (it can use in its
> computation the LOCAL_PREF, that's true), and one of the devices I
> tested computes the Degree of Prefence with formula:
> 
> 	TotalASPolicyWeight+ PeerWeight + DefaultWeight
> 
> where DefaultWeight = the weight added to each route when computing 
> the degree of preference for the route (LOCAL_PREF)-if you have
> any-because it's an discretionary attribute-, and
> if you consider it because it was received from a peer in the
> same AS)
> 	You can assign weight to each AS in the AS_PATH => this way you have th
> e
> TotalASPolicyWeight; 
> 
> PeerWeight = the weight that is added to all routes received from the specifi
> ed peer

You can assign LOCAL_PREF any way you want.  Rich just made a
suggestion since preferring shorter AS paths if you have no other way
to decide which route is better is a popular idea in some circles.

> 	For me this is pretty clear, to take in account 
> the AS and the Peer when you compute the Deegre of Preference.
> 
> 	After the router has done the computation for this Degree of
> Preference, the Local Pref  assigned to the route take the value of
> the Degree of preference already computed. If an internal peer
> received that route, it may or may not
> take as Local Pref the LOCAL_PREF already received (it can compute
> another Degree of Pref based on this Local Pref); If an external peer
> received it, it ignores it and does the Degree of Pref computation for
> the route again, without taking in account any Local Pref.
> 
> 	Yes, sometimes the Local Pref can be computed (if the internal
> peer choose this)but the one which is computed is always the DEGREE OF
> PREFERENCE, which is different form Local Pref.
> 
> This is totally different from what I saw in the messages
> exchanged, about the Local Pref Computation, which I think should be
> the Degree of Preference Computation; what is the right thing to be?
> 
> 	Thanks in advance,
> 
> 	Cristina 

IMO Yakov has obscured the use of LOCAL_PREF by referring to degree of
local preference when "value of the LOCAL_PREF attribute" belongs in
the draft.  This might be left over from early use of BGP4 where some
people didn't set local-pref at all.

Curtis