Re: load-sharing/load-balancing 2 T1s (fwd)
Paul Traina <pst@cisco.com> Sat, 09 March 1996 18:46 UTC
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11758;
9 Mar 96 13:46 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11750;
9 Mar 96 13:46 EST
Received: from p-o.ans.net by CNRI.Reston.VA.US id aa07933; 9 Mar 96 13:46 EST
Received: by p-o.ans.net id AA21526
(5.65c/IDA-1.4.4 for bgp-outgoing); Sat, 9 Mar 1996 18:22:09 GMT
Message-Id: <199603091822.KAA16039@puli.cisco.com>
To: bgp@ans.net
Subject: Re: load-sharing/load-balancing 2 T1s (fwd)
In-Reply-To: Your message of "Sat, 09 Mar 1996 09:40:46 PST."
<199603091740.JAA13576@greatdane.cisco.com>
Date: Sat, 09 Mar 1996 10:22:01 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Paul Traina <pst@cisco.com>
X-Orig-Sender: bgp-owner@ans.net
Precedence: bulk
Reply-To: bgp@ans.net
From: Tony Li <tli@cisco.com> Subject: Re: load-sharing/load-balancing 2 T1s (fwd) Why does BGP pick only one route when it has several options? 90% historical reasons. I don't consider those reasons historical. There's no practical way, with the currently specified BGP-4 to carry the kind of information you need to even make equal-cost path determinations, much less unequal-cost load sharing. However, that's really not necessary. That sort of determination is a local matter between two ASs, so it's reasonable (not pretty, but reasonable) to run an IGP instance to cover those local pipes and have your IGP route you across the DMZ and take care of the load sharing. In the general case, it was very difficult with BGP3 to select multiple paths and not lie about the AS path. Such lies have the obvious bad consequence. ;-( More sophisticated behavior is obviously possible. But requires more CPU cycles. ;-) Among other things. For what it's worth, Yakov and I have already discussed this heavily and we have something up or sleeves for making this work well in the general case, however it will require a non-standard protocol extension and is still in the whiteboard stage. [The rest of this note is inappropriate for the mailing list in general, however since it's good for the protocol as a whole...sorry] Should cisco customers be interested in seeing time allocated to this activity, please contact your sales or marketing representatives and tell them that this is important to you. Remember, development time is not an infinite resource. As with all features if we do this, we don't do something else, which means that there has to be customer support for such work to continue.
- Re: load-sharing/load-balancing 2 T1s (fwd) Tony Li
- Re: load-sharing/load-balancing 2 T1s (fwd) Tony Li
- Re: load-sharing/load-balancing 2 T1s (fwd) bmanning
- Re: load-sharing/load-balancing 2 T1s (fwd) Erik Sherk
- Re: load-sharing/load-balancing 2 T1s (fwd) Paul Traina
- Re: load-sharing/load-balancing 2 T1s (fwd) David Whipple
- Re: load-sharing/load-balancing 2 T1s (fwd) Ravi Chandra
- Re: load-sharing/load-balancing 2 T1s (fwd) Paul Traina