RE: Addr: Re: BGP-4 - revised I-D

["NITTMANN Michael (MSMail)" <[e-mail]>]

... just one little thing:

incorporating the AS path length into local pref calculation is reasonable 
for boiler plate situations. But it happened to me often to chose a longer 
path with less latency over a shorter path.
Path length is really not a good measure. The old method I used was 
padding,which looks ugly and gives then also skewed statistics when looking 
at a traffic matrix.

Can we have a button then to chose how the components are weighted? I would 
really like to get away from the AS path 'length', more to an AS wide 
override for routes. 

A gadget I would like is an rtt and packet loss measurement capability for 
certain paths. Thus I can weigh my backbone according to meetpoint load 
effects. Currently the only way to do this is by using Tivoli and 
reconfiguring routers. That's ok, but if we could get this into the routing 
engine itself this would be really nice.

... most of the original article deleted ...

Regards

Mike

----------
From:  [e-mail][SMTP:[e-mail]]
Sent:  Wednesday, August 21, 1996 1:39 PM
To:  Curtis Villamizar
Cc:  BGP Working Group; Tony Li
Subject:  Addr: Re: BGP-4 - revised I-D

>Date: Tue, 20 Aug 1996 21:24:02 -0400
>From: Curtis Villamizar <[e-mail]>

>Yakov,

>BGP4 is great stuff but for it to advance, we really should clean up
.....cut.....
>environments, but mostly when mixing implementations.

Curtis,

I agree with this 100%, but I disagree with the details below.

>First, here are conditions that can cause routing loops.  These all
>involves differences in route selection criteria or route selection
...cut...

I think Paul Traina had the best idea here: incorporate the AS path
length and origin code selection criteria into the local pref value
(therefore, leave the main BGP spec as is).

I think I now understand how the local pref computation *could* work;
maybe I can send a note about it to the mailing list today.

>   c. Differences in interpretation of a missing MED and poor choice
>      of behavior covering a missing MED.  Without going into details
>      (see below) preferring a route with no MED over one with a
>      MED can cause route loops.  Not considering MED at all in
>      comparing routes with MED to routes without can cause route
>      loops.  This is addresses by the changes you've made.

I think at least one more change is needed in the new draft: removing
the clause "if the local system is configured to take into account MEDs"
I thought we agreed in Montreal that this configuration option does
not exist in today's routers, does not provide value-add to providers,
and can result in routing loops when internal peers are misconfigured
with respect to each other.  The reason why it does not provide value
add is that providers can change MEDs in BGP updates (ala "route-map")
to a uniform value (say 0), which effectively makes the path selection
step of comparing MEDs into a perpetual tie.

Should this be revisited (i.e. did I see consensus where none existed)?

Also, I thought we agreed that a missing MED on a route would be equal
to, not worse than, a MED of -1 on a route. The reason was to avoid a
separate check of whether the MED existed, with the (trivial) penalty
of losing one out of 2**32 MED values.

...cut...

the MED:

yes, I am running into problems there allthe time. What is missing is a real 
coupling: if I set a preferred path into an As, that AS should reconfigure 
to honor that preferred path automatically. 

Currently the only way to achieve something like this is in a static way, 
calling up the peers and asking for favours. Well, most have overloaded 
staff, or not the experience at all to address such a configuration issue.

An exchange and automatic adatpation of a preferred path, need some 
optimizing negotiation of course, is also good for meetpoint load balancing 
per peer AS. This would bring us away from everyone and his dog going 
through mae-e all the time. With a good backbone it is unimportant to what 
meetpoint I go (e.g. ATM cloud as a center).

In my opinion, the MED story should be resurrected. It was a good idea in 
the first place. Only the negotiation piece between routing engines was 
missing.
Yes, this is not simple.

Mike