Re: Addr: Local Preference Computation

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

At 1:22 AM -0400 8/23/96, [e-mail] wrote:
>Folks,
>
>Well, here it is; your comments are solicited...
[...]

Rich,

Thanks for getting the ball rolling on this.  Here is the concern I have
with any scheme which aims to stick everything into localpref:  The dynamic
range is way too small.

The examples you've given do indeed put path length and origin nicely into
a range which is well within the 32 bits we've got to work with in
localpref.  The problem is other path attributes which influence path
selection.  Some such attributes are indeed things which divide routes
into, as you've put it, equivalence classes.  Presumably the number of
equivalence classes in such cases will be relatively small.  However, other
new attributes can be expected to be metric-like, e.g. DPA.  These
typically may each have a range which is equal to that of localpref.  To
jam all this into the 32 bit localpref, presumably you have to (a) scale
them down (potentially losing resolution you needed), (b) restrict their
range (which will not be reasonable in some cases), or (c) not use them.  I
don't find any of these options terribly appealing.

One possible solution might be to introduce the notion of an extended
localpref, analogous to preference2 (and beyond) in gated.  That is, if you
fill up the 32 bit localpref, tack on another 32 bits which are less
significant than the first 32, and so on until you have enough.  Doing this
in a network with "old" routers which don't understand extended preferences
would still invite routing loops, but at least it would define an extension
mechanism once all routers can understand extended prefs.

Another possible solution of course is to argue that in real life 32 bits
is plenty (sound familiar?).  I for one still need to be convinced.

The other point is attributes which aren't globally comparable, e.g. MEDs,
and DPAs in their first (and more reasonable, IMO) incarnation.  I think
that it is probably not reasonable to require that for ever after, all BGP
attributes must be globally comparable.  How can this be addressed in a
world where everything is based on comparison of opaque integers?  Is it
worth throwing out this baby with the interoperability bathwater?  I
suppose you could kludge around this somehow.  For example, if you allow
UserFunction() to be a function of not only the current route but also the
current RIB, you can run an election and bias the preference of the winner
high enough to beat all other routes.  (As described this sounds
suspiciously like it could result in two routers with differing notions of
"best" engaging in ballot-box stuffing for their favored candidates until
the metric overflows, though.)

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