The MPLS WG Archive

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



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

RESEND plain text: Load balancing draft

  • From: "David Allan" <dallan@nortelnetworks.com>
  • Date: Thu, 21 Nov 2002 11:15:43 -0500
  • Cc: George Swallow <swallow@cisco.com>, "Don Fedyk" <dwfedyk@nortelnetworks.com>, Alia Atlas <aatlas@avici.com>, Shahram Davari <Shahram_Davari@pmc-sierra.com>, "'MPLS@UU.net'" <MPLS@UU.NET>


 Tom:
 
 Not entirely true, any point where there is useful 
 predictability reduces the number of possible faults that may 
 only be caught by random process. IMHO that is useful.
 
 cheers
 Dave
 
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> > Sent: Thursday, November 21, 2002 10:59 AM
> > To: Fedyk, Don [BL60:1A00:EXCH]
> > Cc: George Swallow; Fedyk, Don [BL60:1A00:EXCH]; Allan, David
> > [CAR:NS00:EXCH]; Alia Atlas; Shahram Davari; 'MPLS@UU.net'
> > Subject: Re: Load balancing draft
> > 
> > 
> > 
> > >George
> > >
> > >Let me restate. You Said "All load balancing done in 
> > prescribed manner." 
> > >Which is certainly restrictive. The Draft for load balancing 
> > says  not to 
> > >use certain fields. That is not the same. So I added different 
> > >implementations for load balancing following the draft still 
> > have freedoms 
> > >and different vendors can choose different algorithms.
> > 
> >          Not really. If you want things to work the way the 
> > draft aspires
> > them to, then everyone in the MPLS domain must use the same,
> > predictable load balancing algorithm.  Going halfway doesn't work,
> > and is arguably no better than what we have today.
> > 
> >          --Tom
> > 
> > 
> > >Hope that makes it clear,
> > >Don .
> > >George Swallow wrote:
> > >
> > >>Don -
> > >>
> > >>This seems to a non-sequitor.  I don't see how this comment 
> > relates to
> > >>what I wrote below.  Were you trying to answer some other message?
> > >>
> > >>...George
> > >>
> > >>
> > >>
> > >>>George to be fair I heard Dave say  that the load 
> > balancing should not 
> > >>>use certain fields which are part of the label stack. This 
> > does not 
> > >>>require that balancing be done in a prescribed manner, 
> > freedom is still 
> > >>>there. Instead load balancing should be correct with 
> > respect to all of 
> > >>>MPLS formats  including reserved labels.
> > >>>
> > >>>Don
> > >>>
> > >>>George Swallow wrote:
> > >>>
> > >>>
> > >>>
> > >>>>>If you look at my post from rather late last night, I'd 
> > question the 
> > >>>>>lighter
> > >>>>>overhead assertion. This discussion is really orthogonal 
> > to the probe
> > >>>>>frequency and is more concerned with the probe 
> > quantity/quality to 
> > >>>>>determine
> > >>>>>there is a problem. Goodness and scalability (and again 
> > my favorite 
> > >>>>>"bounded
> > >>>>>detection time") can be expressed as how authoritative a 
> > test result is in
> > >>>>>proportion to the messages expended. Also the fewer 
> > heuristics required to
> > >>>>>interpret the test results, the more reliable the 
> > overall system is....
> > >>>>>
> > >>>>>
> > >>>>My only point is that if your measurement is based on the 
> > assumption
> > >>>>that all load-balancing is being done in a prescribed 
> > manner, then the
> > >>>>quality of that measurement is very much dependent on the 
> > certainty
> > >>>>that all of the nodes in the path are actually behaving 
> > according to
> > >>>>that assumption.  On node behaving differently could 
> > reroute a large
> > >>>>portion (or all) of the probes.  Thus the measurement 
> could be far
> > >>>>
> > >>>>
> > >>>>from the actual behavior.
> > >>>
> > >>
> > >>==================================================================
> > >>George Swallow       Cisco Systems                  (978) 497-8143
> > >>                     250 Apollo Drive
> > >>                     Chelmsford, Ma 01824
> > >>
> > >>
> > >
> > 
> > Success is relative; the more success, the more relatives. 
> -Anonymous
> > 
> > 
> > 
>