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.