Re: BGP-4 changes
rwoundy@vnet.ibm.com Tue, 03 September 1996 23:00 UTC
Received: from ietf.org by ietf.org id aa00242; 3 Sep 96 19:00 EDT
Received: from cnri by ietf.org id aa00237; 3 Sep 96 19:00 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa15738; 3 Sep 96 19:00 EDT
Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id SAA10104
for idr-outgoing; Tue, 3 Sep 1996 18:34:16 -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 SAA10099 for <bgp@merit.edu>;
Tue, 3 Sep 1996 18:34:13 -0400 (EDT)
Sender: ietf-archive-request@ietf.org
From: rwoundy@vnet.ibm.com
Received: by interlock.ans.net id AA18902
(InterLock SMTP Gateway 3.0 for bgp@ans.net);
Tue, 3 Sep 1996 18:34:10 -0400
Message-Id: <199609032234.AA18902@interlock.ans.net>
Received: by interlock.ans.net (Internal Mail Agent-1);
Tue, 3 Sep 1996 18:34:10 -0400
Date: Tue, 03 Sep 96 18:34:16 EDT
To: curtis@ans.net, jgs@ieng.com, bgp@ans.net
Subject: Re: BGP-4 changes
X-Orig-Sender: owner-idr@merit.edu
Precedence: bulk
*** 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. 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
- Re: BGP-4 changes John G. Scudder
- Re: BGP-4 changes Curtis Villamizar
- Re: BGP-4 changes John G. Scudder
- Re: BGP-4 changes Yakov Rekhter
- Re: BGP-4 changes Curtis Villamizar
- BGP-4 changes Yakov Rekhter
- Re: BGP-4 changes Rich Woundy
- Re: BGP-4 changes Yakov Rekhter
- Re: BGP-4 changes John G. Scudder
- Re: BGP-4 changes rwoundy
- Re: BGP-4 changes rwoundy
- RE: BGP-4 changes rwoundy
- Re: BGP-4 changes rwoundy
- Re: BGP-4 changes Yakov Rekhter
- Re: BGP-4 changes Yakov Rekhter
- Re: BGP-4 changes Yakov Rekhter
- Re: BGP-4 changes John G. Scudder
- Re: BGP-4 changes Curtis Villamizar
- RE: BGP-4 changes NITTMANN Michael (MSMail)
- RE: BGP-4 changes John G. Scudder
- Re: BGP-4 changes Curtis Villamizar