I would like to inject some sanity into the traffic engineering discussion by reminding about some small fact of life: Nobody knows how to measure how what the demanded/available bandwidth ratio is when the circuit is overloaded. In a steady more, utilization is s 100%; packet loss is not an accurate gauge, by any means (it depends on delays, agressiveness os sources, queue manageent policies, timing of source starts, and phase of the moon). What it means that by and large traffic engineering is done by seat of the pants. An attempt to create a close control loop with that kind of source information is somewhat problematic. And so is "wavelength on demand". When circuits aren't overloaded, traffic engineering yields zero benefit. --vadim PS I just love engineers spending untold hours and companies spending billions on a technology of questionable worth and little theoretical foundations, instead of spending a small fraction of it on research first. PPS Pluris core technology allows to treat traffic as a liquid - unlike simple IP routing it works by splitting aggregated streams, which can be sent along different paths. It makes any VC-based traffic engineering and associated hardware overhead simply unnecessary. I'm more than a little disappointed by the fact that this is apparently lost in the mind of the company's current architects. (Admittedly, it still requires some work on algorithms, but at least routing of colored liquids is much easier computationally than routing of VCs).