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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>om>, Cristina Radulescu-Banu writ
es:
> ------- 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-B
> an
> 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.
>    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This means don't send LOCAL_PREF to an EBGP peer.

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

The preconfigured policy information is then put into the LOCAL_PREF
attribute.  This text should be more clear.  It seems that everyone
who has already implemented BGP4 agrees on the interpretation but the
text was never very clear.

Don't send LOCAL_PREF to an EBGP peer.  Don't accept LOCAL_PREF from
an EBGP peer.  Decide what your preference is based on configured
policy.  Then put that into LOCAL_PREF.  Then use LOCAL_PREF as the
first value in a comparison.

Curtis