[[e-mail]: Re: BGP4 stuff: Local Preference Computation]

[Cristina Radulescu-Banu <[e-mail]>]

------- Start of forwarded message -------
Return-Path: <[e-mail]>
To: [e-mail] (Cristina Radelescu-Banu 617/890-1001)
Cc: [e-mail], [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: BGP4 stuff: Local Preference Computation 
In-Reply-To: Your message of "Wed, 04 Sep 1996 15:34:29 EDT."
             <[e-mail]> 
Date: Wed, 04 Sep 1996 18:54:46 -0400
From: Curtis Villamizar <[e-mail]>

	In message received from Curtis Vilamizar, he wrote:

In message <[e-mail]>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.

	At least from what I read, it doesn't seem like that.
	I will quote from RFC 1771:

         e) LOCAL_PREF (Type Code 5):

            LOCAL_PREF is a well-known discretionary attribute that is a
            four octet non-negative integer. It is used by a BGP speaker
            to inform other BGP speakers in its own autonomous system of
                                               ~~~~~~~~~~~~~~~~~~~~~~~
            the originating speaker's degree of preference for an
            advertised route. Usage of this attribute is described in
            5.1.5.

and:

	5.1.5   LOCAL_PREF

   LOCAL_PREF is a well-known discretionary attribute that shall be
   included in all UPDATE messages that a given BGP speaker sends to the
   other BGP speakers located in its own autonomous system. A BGP
                                 ~~~~~~~~~~~~~~~~~~~~~~~~~
   speaker shall calculate the degree of preference for each external
   route and include the degree of preference when advertising a route
   to its internal peers. The higher degree of preference should be
   preferred. A BGP speaker shall use the degree of preference learned
   via LOCAL_PREF in its decision process (see section 9.1.1).

   A BGP speaker shall not include this attribute in UPDATE messages
   that it sends to BGP speakers located in a neighboring autonomous
   system. If it is contained in an UPDATE message that is received
   from a BGP speaker which is not located in the same autonomous
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                    
   system as the receiving speaker, then this attribute shall be
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   ignored by the receiving speaker.
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

9.1.1 Phase 1: Calculation of Degree of Preference
 
	   For each newly received or replacement feasible route, the local BGP
   speaker shall determine a degree of preference. If the route is
   learned from a BGP speaker in the local autonomous system, either the
                                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
   value of the LOCAL_PREF attribute shall be taken as the degree of
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   preference, or the local system shall compute the degree of
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   preference of the route based on preconfigured policy information. If
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   the route is learned from a BGP speaker in a neighboring autonomous

   system, then the degree of preference shall be computed based on
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   preconfigured policy information.  The exact nature of this policy
   information and the computation involved is a local matter.  The
   local speaker shall then run the internal update process of 9.2.1 to
   select and advertise the most preferable route.

> 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.

	If a LOCAL_PREF is not set, I don't see where is the problem, 
the Degree of Preference being computed without taking into account
the LOCAL_PREF. 

Curtis

------- End of forwarded message -------

-- 

	This is the same in RFC 1771, and in
draft-ietf-idr-bgp4-03.txt, isn't it?

...............................................................................
Cristina Radulescu-Banu : Midnight Networks 200 Fifth Avenue Waltham MA 02154
[e-mail]  : Vox 617/890-1001 Fax 0028 The Best in Network Software
	
   I'm trying so much to communicate my thoughts by speaking that I
		     can't move my arms anymore.