Curtis,
I have one inline comments.
Leah
> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]
> Sent: Wednesday, May 09, 2001 8:18 AM
> To: Yufei Wang
> Cc: 'curtis@workhorse.fictitious.org'; 'van@packetdesign.com';
> 'xiaoxipe@cse.msu.edu'; 'irtf-rr@puck.nether.net'
> Subject: Re: interesting Infocom paper on traffic engineering via
> routing metrics
>
> MPLS can put the A-E traffic on one leg and the A-F traffic on the
> other leg but cannot accurately balance the load.
I do not believe that this is the case. IF we build two MPLS tunnels,
A-B-D-F and A-B-C-D-E, we
can put the A-E traffic on the leg, and A-F traffic on the other leg. But
there are other
ways of building the tunnels for load balancing. For example, we can build
two tunnels from
B to D, B-C-D and B-D. Since these two tunnels share the same source and
destination nodes, we
can set the bandwidth of these two tunnels to be the same to do equal load
balacing between
B-C-D and B-D.
> The only technique
> so far that can accurately balance the load is OMP. With lots of MPLS
> LSP, the CR based MPLS/TE load balance is generally not as good but
> "good enough". With OSPF and ECMP metrics can be set so that load
> balance is not as good as MPLS/TE. Some consider the ability of the
> IGP to load balance to be good enough. Others don't consider it good
> enough and consider IGP load balance too hard to manage and that was a
> principle motivation for MPLS/TE.
>
> With IGP load balance there can also be extremely poor load balance
> after a failure in the topology until all of the costs are changed.
>
> Curtis
>
>
> > > Many simple topologies cannot be optimized by setting IGP
> metrics but
> > > can easily be optimized using MPLS. For example:
> > >
> > > C E
> > > / \ /
> > > A---B---D--F
> > >
> > > The largest traffic contributors are A-E and A-F. The
> bottlenecks are
> > > B-C or B-D where the available capacity of B-C and B-D
> are unequal and
> > > the flows A-E and A-F are unequal. It is easy to pick values that
> > > where neither ECMP or putting all of the flows on one leg
> would do as
> > > well as a traffic engineered solution.
>
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT