Re: Addr: Local Preference Computation

["John G. Scudder" <[e-mail]>]

Joel,

At 11:46 AM -0400 8/24/96, Joel Halpern wrote:
>I have been reading the local-pref/MED discussion, and trying to tie it
>back to my understanding of the assumptions that had been made originally.
>
>As I understood things, the point of "local-pref" was to ensure that all
>border routers of an AS made the same choice of path for a given destination.
>This would then allow the appropriate BGP advertisement to be generated by
>all AS boundary routers.

Sort of.  All the border routers don't have to make the *same* choice,
though they do have to make a *consistent* choice, where consistent means
"loop free".  Localpref allows one border router to tell all the other
routers what policy it applied to a route it imported.  This is good
because it allows each border router to only have to worry about the policy
for its direct neighbors, not all the neighbors of the whole AS.  (The
latter has obvious scaling problems on several axes.)

(As a small digression, I kind of hate the use of the word "policy" as a
forty-dollar word to mean "preference".  Saying that we use localpref to
export our "policy" is confusing because it sounds like maybe it has more
semantics than it does.  It's just an integer.  End digression.)

>If I am reading the discussion right, the routing loops occur because
>the local-pref value is not the only thing being used.  Therefore,
>internal routers (who do not have the full policy of the external border
>routers) are getting confused about what is happening?

This is not quite how I would put it.  I'd say, rather, that the problem is
that we use IBGP as a defacto IGP.  In fact it seems to have some of the
criteria of a link-state IGP insofar as external routing information is
sent AS-wide using IBGP and each router in the AS is then responsible for
independently computing its next hops based on that information.  (This is
pretty similar to link state advertisements getting flooded around, only
the mechanism for doing it is cruder than the flooding a real link state
protocol uses.)

If you think of it that way, you'll see that, like with your favorite
link-state IGP, it's critical that all the internal guys use absolutely
identical criteria for route selection.  Unfortunately this doesn't seem to
have fully sunk in until a bit late in the game.

If IBGP was really just for hauling path attributes around, and the IGP
carried the actual forwarding stuff, then we wouldn't have this problem.
(We'd have others, but that's another rathole.)

By the way, the problem is also not quite that "the local-pref value is not
the only thing being used" but rather that there are dissimilar lists of
things being used.  In fact RFC 1771 specifies a whole list of things to be
used after localpref, in the (rather likely) event of a localpref tie.
This, in itself, is good.  The two problems are (a) one of the specified
tie-breakers, MED, is underspecified, and (b) some folks add their own
nonstandard tie-breakers.

The attraction of putting stuff into localpref is that localpref *does*
work right but isn't used for enough.  If everyone agreed that their custom
knobs would just be a way to bias the localpref rather than sticking
non-interoperable lower-order tie-breakers in, then we could interoperate
happily, since localpref is a nice opaque integer which we can compare
without regard to the exact method used to compute it.

>1) I would strongly suggest that the discussion would be helped by an
>    explicit statement in each proposal of how the fields (MED an and
>    local-pref) are to generated and compared for route selection.

I kinda think that much of the point is that computation of localpref
should be an implementation-specific thing.  The stuff which has been
floated so a seems to be in the nature of (as I think Curtis said) a sample
algorithm to prove that this is reasonable.  If this is right then I don't
think that we need to focus on explicit methods for generation of localpref.

RFC 1771 and follow-ons already are quite clear on how to compare
localpref.  MED does need to be fixed.

To my way of thinking the open questions are not exactly the ones you pose
above, but rather:

- Is putting everything into localpref sufficiently flexible to provide
everything that vendors will want to offer their customers?  Or will they
again be tempted to put other stuff into the route selection process?  If
the latter, is there some generic/standard/safe way to let them do this?
(q.v. my off-the-cuff notion of extended localprefs).

- What's the right thing to do with MED?  (I think there is not too much
debate on this.)

- Do we need to have a way to introduce other MED-like things, which I
think can't be stuffed into localpref (someone please prove me wrong).  Is
there some way to do this which will guarantee loop-free interoperability
between different implementations?

>2) If the old assumptions are no longer applicable, I would appreciate
>    an explanation of why.  The most obvious cause would be that some
>    underlying precept turns out not to be the case.  For example, the
>    local-pref stuff is basically based on assuming similarity of policy
>    mechanisms on all border routers of an AS. Does that no longer obtain?

I'm not sure what you mean by "assumes similarity of policy mechanisms" but
it doesn't sound quite right to me.  Perhaps you could explain this more if
you want to pursue this train of thought.

I trust I make myself obscure?

Regards,

--John

--
John Scudder                        email:  [e-mail]
Internet Engineering Group, LLC     phone:  [phone]
122 S. Main, Suite 280              fax:    [phone]
Ann Arbor, MI  41804                www:    http://www.ieng.com