Subject: oscillation, total ordering, and always-compare-med

From: "John G. Scudder" <[email-masked]>
Date: Fri, 7 Jun 2002 11:51:58 -0400

A couple of replies, aggregated.

--John

At 4:14 PM -0400 6/6/02, Jeffrey Haas wrote:
>Without taking this to the more complicated cases, the argument that
>the operational community makes is that "always-compare-med" is a form
>of denial of service.

"Denial of service" overstates the case.  By definition, for the MEDs 
of two ISPs to clash (which does _not_ happen often), they must be 
MEDs for the same prefix, and the paths must be considered 
equally-desirable by all previous criteria.  If one defines "service" 
as "the delivery of packets to the network depicted by that prefix", 
then it's clearly not being denied in that case -- one 
equally-desirable path is merely being picked over another.  The 
argument may even be made that the policy of the prefix owner is not 
even being subverted, because if the prefix owner preferred to 
receive traffic via one or the other of the ISPs in question, they'd 
pad their AS path in one of the directions, and in doing so would 
render the MED question moot.

If I were still an ISP I think this argument would be sufficient to 
convince me to turn on always-compare-med everywhere in my network 
(perhaps after auditing my routing tables).  But I'm not, so there 
you have it.

Certainly always-compare-med changes MED semantics, but "denial of 
service" it ain't.

At 11:55 AM -0700 6/6/02, Pedro Roque Marques wrote:
>There is a simple answer, which is to address the current MED
>behaviour. MEDs as current specified make it so that there isn't
>possible to establish a global ordering between BGP paths. The
>protocol when originally designed implicit required such property.
>
>Given a global ordering of paths within an ibgp mesh no persistent
>osciallation will occur and the protocol as originally specified will
>be stable.

Yep.  And of course always-compare-med gives us total ordering (at 
the admitted cost of changing the MED semantics).

>In order to achieve this, of course, one needs to encounter an
>solution to the problem that MEDs are supposed to solve.

By this I take it you are saying one needs a solution which (a) gives 
us total ordering over all BGP routes, (b) scales as well as current 
(hierarchical) IBGP and (c) gives us the exact semantics MEDs are 
intended to provide (i.e., the semantics they do provide in a full 
IBGP mesh).

I would be extremely surprised (though happy) if there exists a 
solution which satisfies all these criteria.  Perhaps one of the 
researchers on the list would like to do a proof of this statement 
for their next SIGCOMM paper.  (While a proof would be nice, the fact 
that nobody's done it yet is at least some evidence.)

>One possible solution is to mandate 'always-compare-med' behaviour
>which will make paths have a global ordering. I remember there was
>strong reaction against this from the operational folks but i'm not
>quite sure what the arguments where (would apreciate if somebody could
>refresh my memory).

As many folks already know, personally always-compare-med is my 
preferred solution because instead of trying to band-aid over the bug 
in the protocol, it eliminates it in a clean, cheap and efficient 
manner.  However, as Pedro says there has been strong resistance to 
the idea from operational folks, hence the current round of 
discussion.

Also, it bears repeating that the always-compare-med solution can be 
deployed _now_ by anyone who wants to, since many (most? all?) 
vendors already provide an always-compare-med knob.  So for anyone 
who is prepared to use it, a solution exists today.

---

From: Andrew Partan <[email-masked]>
Date: Sat, 22 Jun 2002 01:01:50 -0400

On Fri, Jun 07, 2002 at 11:51:58AM -0400, John G. Scudder wrote:
> By definition, for the MEDs of two ISPs to clash (which does _not_
> happen often), they must be MEDs for the same prefix, and the paths
> must be considered equally-desirable by all previous criteria.

It can happen a lot - it all depends on where you are and where
you are looking.  If, say, you are a customer of Sprint and UUNET
and you are looking towards other ASs that are also customers of
both Sprint and UUNET, then all of those prefixes will be otherwise
equal.  But the MEDs from Sprint and UUNET may be on completely
different scales and not comparable.

> convince me to turn on always-compare-med everywhere in my network 

MFN tried (tries?) to use always-compare-med, but it was a huge
pain in the rear - especially when you tried to figure out what to
add (or subtract) to the MEDs from one ISP to make them roughly
comparable to the MEDs from another ISP.  And what you had to do
to make them roughly comparable changed from time to time.  Very
ugly & non-scaleable.

	--asp