[[e-mail]: Re: [[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], [e-mail]
Reply-To: [e-mail]
Subject: Re: [[e-mail]: Re: BGP4 stuff: Local Preference Computation] 
In-Reply-To: Your message of "Thu, 05 Sep 1996 13:04:58 EDT."
             <[e-mail]> 
Date: Thu, 05 Sep 1996 14:55:28 -0400
From: Curtis Villamizar <[e-mail]>

In his  message Thu, 05 Sep 1996 14:55:28 -0400, Curtis Villamizar writes:

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.

This is exactly what I have done; (it's pretty clear in RFC; the
confusing thing was the message about  Local Preference Computation,
which I think should be the Degree of Preference Computation )

	BTW, one of the device I tested doesn't accept ANY Update
packet if the LOCAL_PREF is not defined, even if the 2 peers are in
different AS . So, for them this LOCAL_PREF is mandatory. I think 
a good thing which should appear in RFC is  the one "John
G. Scudder" pointed out, that the LOCAL_PREF should be FORBIDDEN on 
external links. 


Curtis

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

-- 
			Cristina

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