It depends on the length of those TCP sockets. If you were load-balancing the increasingly common video-over-http, it would be very unacceptable.
yes. i believe i said that my preferred approach works really well with UDP and marginally well with current WWW. video over http is an example of an application who wouldn't like its ECMP recalced many times per month (which is the worst case; my actual experience is less-than-once-per-month.)
... The limits are anywhere from just 6 ECMP routes to 32 (though of course you could do staggered load-balancing using multiple CEF devices). I'm open to correction on the 32, but it's the highest I've yet come accross.
this is the more interesting scaling limit. i know of a company with ~150 recursive name servers all answering at the same IP address. ECMP won't help at that level. i believe that even a hardware load balancer would have to be multistage at that level, but once you've got multiple levels then the Powered Boxes aren't Extra any more and i wouldn't prefer an ECMP design.
... This *is* possible with many load-balancers (plug: Including Apache's own load-balancing proxy), but with OSPF I'm forced to drop *all* sessions to the cluster 20 times (or yes I could do 10 nodes at a time, but you get the picture).
yes.
I *like* OSPF ECMP load-balancing, it's *great*, and I use it in production, even load-balancing a tonne of https traffic, but in my opinion you are over-stating its abilities. It is not close to the capabilities of a good intelligent load-balancer. It is however extremely cost-effective and good enough for a lot of usage, as long as it's taken with some operational and engineering considerations.
or if, as in my case, the primary app is UDP based. your points are well taken in the case of large scale TCP though.