The MPLS WG Archive

["Naidu, Venkata" <Venkata.Naidu@Marconi.com>]

Neil,

-> So that I can better understand what you mean here, can you 
-> please then
-> explain:
-> -	how you are going to know how to load balance when we have IP
-> clients and other clients of the LSPs (eg the XoverMPLS PWE3 drafts)

  I agree on this issue here - ECMP has inherent limitations.
  But load balancing is useful when we know what we are doing.
  So making it a configurable options is the way to solve
  the issue.

  IRTF Routing drafts reads... 
     4.7 Dynamic Load Balancing 

        Past history has shown that using the routing system to perform 
        highly dynamic load balancing among multiple more-or-less-equal 
        paths usually ends up causing all kinds of instability, etc, in 
        the network.  Thus, we do not require such a capability. 

        However, this is an area that is ripe for additional research, 
        and some believe that the capability will be necessary in the 
        future. Thus, the architecture and protocols should be 
        "malleable" enough to allow development and deployment of 
        dynamic load balancing capabilities, should we ever figure out 
        how to do it.   

  What I don't agree - "Just because MPLS is connection oriented
  and simple/fast label lookup doesn't mean that we shouldn't do
  load balancing. There is no requirement that we must do 
  load balancing using constraint based routing".

  You can do load balancing using plain old IP routing and signaling
  protocols which uses that routing (like LDP).

-> -	how pkt misordering is avoided for clients that expect ordered
-> delivery?

  Are you expecting that all connection-oriented protocols must
  assure ordered delivery ? In the interest of end-to-end Internet
  design, I expect all transport/session layer protocols will take 
  care of ordered delivery of packets to applications.

-> -	how correctly behaving load-balancing is ensured, ie 
-> how are defects in the load balancing detected/diagnosed?

  It is difficult to debug - even in case of *classical* IP ECMP.
  This is not a new issue with MPLS ECMP.
  
  RFC2991 reads...
   Debugging
         Common debugging utilities such as ping and traceroute are much
         less reliable in the presence of multiple paths and may even
         present completely wrong results.

-> -	where is all the above specified?

  As I said before, whether to do load balancing or not 
  is _not_ an interoperability issue. It's the best interest
  of any vendor. No *specification* required - *requirements*
  may be sufficient.

--
Venkata

-> > -----Original Message-----
-> > From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com]
-> > Sent: 27 June 2002 22:03
-> > To: 'Shahram Davari'; 'Eric Osborne'; George Sheng
-> > Cc: scullptor@yahoo.com; mpls@UU.NET
-> > Subject: RE: your mail
-> > 
-> > 
-> > Shahram,
-> > 
-> > -> > ECMP is inherent in the architecture. 
-> > -> 
-> > -> What? ECMP is a kludge to overcome LDP's inability to TE. If 
-> > -> you think about it doing hashing of multiple labels and 
-> > -> perhaps IP header in the middle of an LSP actually defeats 
-> > -> the purpose of MPLS, which was supposed to be have a simple 
-> > -> label lookup in the core.
-> > 
-> >  Who said that ECMP will be achieved only by hashing labels
-> >  or IP header? I think you are thinking IP ECMP methods
-> >  (RFCs 2991 and 2992) to solve MPLS ECMP. You can do ECMP
-> >  in what ever way a vendor likes - after all, it is for
-> >  load balancing. You can still achieve simple label lookup at
-> >  the core by using appropriate ECMP technique(s).
-> > 
-> > --
-> > Venkata.
-> > 
->