Re: BGP-4 changes

Curtis Villamizar <curtis@ans.net> Wed, 04 September 1996 06:53 UTC

Received: from ietf.org by ietf.org id aa14130; 4 Sep 96 2:53 EDT
Received: from cnri by ietf.org id aa14125; 4 Sep 96 2:53 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa03303; 4 Sep 96 2:53 EDT
Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id CAA15886 for idr-outgoing; Wed, 4 Sep 1996 02:27:48 -0400 (EDT)
Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by merit.edu (8.7.5/merit-2.0) with SMTP id CAA15881 for <bgp@merit.edu>; Wed, 4 Sep 1996 02:27:44 -0400 (EDT)
Received: by interlock.ans.net id AA28112 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Wed, 4 Sep 1996 02:27:42 -0400
Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 4 Sep 1996 02:27:42 -0400
Message-Id: <199609040627.CAA04725@brookfield.ans.net>
To: rwoundy@vnet.ibm.com
Cc: curtis@ans.net, jgs@ieng.com, bgp@ans.net
Reply-To: curtis@ans.net
Subject: Re: BGP-4 changes
In-Reply-To: Your message of "Tue, 03 Sep 1996 18:34:16 EDT." <199609032234.AA18902@interlock.ans.net>
Date: Wed, 04 Sep 1996 02:27:31 -0400
Sender: ietf-archive-request@ietf.org
From: Curtis Villamizar <curtis@ans.net>
X-Orig-Sender: owner-idr@merit.edu
Precedence: bulk

In message <199609032234.AA18902@interlock.ans.net>et>, rwoundy@VNET.IBM.COM write
s:
> *** Resending note of 08/31/96 15:15
> Subject: Re: BGP-4 changes
> John,
> 
> I now have second thoughts about changing the MED value; stripping the
> attribute is of course still OK.  The problem is not route loops,
> but non-deterministic routing (i.e. not predictable).
> 
> >As far as I'm concerned, being able to strip the attribute at the border
> >achieves this goal fine.  Either or both is OK with me.
> 
> >In private email Curtis mentioned a case (which in retrospect I should have
> >seen) where we should be able to strip MED after route selection but before
> >export into IBGP.  The case applies when I have a router facing two
> >neighbors across a DMZ.  I want to consider the MED to get the next hop
> >"right" across the DMZ, but I want to use shortest-path inside my AS.  I
> >believe that this stays loop-free since we only consider MED once we
> >have already decided to choose an external route.
> 
> Let's assume that a router considers the original EBGP MED in the
> route selection process, but sends the modified MED in the
> IBGP export.  Further assume a provider modifies the MED to value
> 0 at two border gateways (A & B), in order to try to draw traffic to
> the nearest of these two exits.

Removed MED attribute completely, not modified.

> Suppose border A gets an external BGP route with MED X first.  With no
> competition from B, border A installs the route and exports into IBGP
> with MED 0.  Border B will see this same route only with MED 0.
> 
> Later, border B receives its route with MED Y (same prefix, same
> neighbor AS, same preference, etc.).  So long as Y > 0 (it usually
> is), then border B will reject the external in favor of the internal
> route from A.
> 
> Note that acceptance of the internal route from A over the external
> route of B is based totally on timing issues -- first come, first
> served.  It only occurs when the MED value is decreased -- that's why
> stripping the MED is OK, since missing MEDs have value -1.
> 
> To fix this, one might use the modified MED value for both route
> selection and IBGP export, but one throws away useful information
> as Curtis and John mention above (for optimizing local external
> route selection).
> 
> Do we need the ability to change the MED attribute value, or is
> it sufficient to be able to remove the MED attribute?  Can we get
> away with modifying local preference instead of changing the MED
> value?
> 
> -- Richard Woundy, IBM

If you removed MED completely, with the current rule changes (sounds
like professional sports commission) you don't get a routing loop.

John didn't write anything about changing MED and I didn't write
anything about changing MED to John.

Curtis