The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Nov> msg00128



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Load balancing draft

  • From: "Thomas D. Nadeau" <tnadeau@cisco.com>
  • Date: Tue, 19 Nov 2002 17:45:30 -0500
  • Cc: "'MPLS@UU.net'" <MPLS@UU.NET>

At 04:29 PM 11/19/2002 -0500, David Allan wrote:


>Tom:
>
> > >The concept of avoiding the reserved labels in an MPLS hash
> > as a "best
> > >way" makes some sense,
> >
> >
> >          Does this mean that we then have to mandate how IP
> > (L2TPV3) does traffic distribution too?  What is next?
>
>L2TPv3 from what I can tell does not have a mechanism by which I could
>distinguish any type of PE-PE probe of a PW so the example is moot. I can
>only use payload probes (I.610, ICMP, whatever).
>I think that this
> > solution looks
> > good in theory, but in practice there are huge problems with it.
>
>Only problem I can think of is that one cannot simply hash an arbitrary
>length of the MPLS frame. The implementation is a bit more complex, that's
>the price of testabilty.

         Not necessarily. I think you can test/trace the paths using LSP ping,
but of course, there is a price to pay for that too; there is no free lunch.
The advantage of the latter is that it works with all of the hardware
deployed today.

> > >though it would probably only be gradually available as
> > hardware changes.
> >
> >          Kireeti or you made a good point that
> > this solution is not evolutionary; it is revolutionary as it
> > will require
> > hardware changes.
>
>Many things eventually migrate to hardware. Some formerly hardware functions
>migrate to microcode. This years core LSR is next years edge box. Are we
>saying that MPLS is frozen in time based upon last year or the year before's
>implementation? If so, lets skip draft and simply promote everything to STD
>and go home.

         No, I am saying that there are always going to be low-end platforms
that have hardware limitations and thus might not be able to use the load
share algorithm you specify in this document.  What do we do for those?
I think we are just back in the situation that we are in today: proprietary
load balancing.  It works for IP and other technologies, why do we need
to mandate an algorithm here?

>On the surface it might sound reasonable to
> > say that well, hardware will evolve and as it does it must support
> > this sort of load-balancing. However, the fact of the matter is that
> > one size does not fit all in this case, and thus this will be a burden
> > on both existing and future implementations.
>
>At the moment you're stipulating that one size fits all. That's what the
>draft was trying to avoid.

         No, I am saying that what we have today is many sizes
fit all (in the case of load balancing) because that is a reality
of routers/switches.

         --Tom


>rgds
>Dave
><snipped to the end>

Success is relative; the more success, the more relatives. -Anonymous