Re: BGP-4 changes

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>om>, Yakov Rekhter writes:
> Folks,
> 
> How about if we'll use John's text (with some minor editorial
> changes) ?
> 
> Add to 5.1.4:
> 
>   When a route with the MULTI_EXIT_DISC attribute is received over an
>   external link it must be possible (based on local configuration) to
>   remove or override the value of the attribute. This shall be done
>   prior to determining the degree of preference of the route.

This is fine.  It actually makes sense to be able to add an offset if
MED is being used to load balance the other AS but some control over
load in the local AS is also desirable.  I would put that in the spec
as a protocol requirement though.

In private mail John mentioned he wanted to be able to disable MED to
accomodate existing implementations that do the selection differently.
It might actually be worth mentioning this.

> Replace 9.1.2.1 with the following:
> 
> 
>    In its Adj-RIBs-In a BGP speaker may have several routes to the same
>    destination that have the same degree of preference. The local
>    speaker can select only one of these routes for inclusion in the
>    associated Loc-RIB. The local speaker considers all routes
>    with the same degress of preference, both those received from 
>    internal peers, and those received from external peers.
> 
>    The following tie-breaking procedure assumes that for each candidate
>    route all the BGP speakers within an autonomous system can ascertain
>    the cost of a path (interior distance) to the address depicted by the
>    NEXT_HOP attribute of the route.
> 
>    The tie-breaking algorithm begins by considering all equally
>    preferable routes and then selects routes to be removed from
>    consideration.  The algorithm terminates as soon as only one
>    route  remains in consideration.  The criteria must be applied
>    in the order specified.
> 
>       a) Remove from consideration routes with less-preferred
>       MULTI_EXIT_DISC attributes, according to the following
>       procedure:
> 
>       for m = all routes still under consideration
>           for n = all routes still under consideration
>               if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
>                   remove route m from consideration
> 
>       In the pseudo-code above, MED(n) is a function which returns
>       the value of route n's MULTI_EXIT_DISC attribute.  If route n
>       has no MULTI_EXIT_DISC attribute, the function returns the
>       highest possible MULTI_EXIT_DISC value, i.e. 2^32-1.
> 
>       Similarly, neighborAS(n) is a function which returns the
>       neighbor AS from which the route was received.
> 
>       b) Remove from consideration any routes with less-preferred
>       interior cost, according to the following procedure.  If the
>       BGP speaker has no notion of the cost of a path, skip this
>       step (equivalently, consider all routes to have equal costs).
> 
>       for m = all routes still under consideration
>           for n = all routes in still under consideration
>               if (cost(n) is better than cost(m))
>                   remove m from consideration
> 
>       In the pseudo-code above, cost(n) is a function which returns
>       the cost of the path (interior distance) to the address
>       depicted by the NEXT_HOP attribute of the route.
> 
>       c) If at least one of the candidate routes was received from
>       an external peer from a neighboring autonomous system, remove from
>       consideration all routes which were received from internal
>       peers.
> 
>       d) Remove from consideration all routes other than the route
>       that was advertised by the BGP speaker whose BGP Identifier
>       has the lowest value.
> 
> Yakov.

You forgot the statement that any algorithm that produces an
equivalent result is acceptable.  You might mention that this
particular algorithm is inefficient.

This wording is clear and it is excellent if it a goal to word the
spec using such that it describes the most inefficient algorithm
possible, even if a very efficient algorithm exists that is easy to
explain and understand.  If that is not a goal, then the wording is
adequate since it is clear enough that loops will be avoided by anyone
who reads attentively and dutifully implements what they read.

Regardless of what description is used, I'd like to see a description
of the loop problems and the reasons for some of these rules in the
selection process, to prevent someone from mistakenly thinks that
comparing the current best route to the new route is an equivalent
algorithm.  Would you prefer this in the route selection section, in
an appendix, or a separate informational RFC.

Curtis