Bora, | 1) I believe that all of the problems that are claimed to be solved by | TE can also be solved by a well-designed network architecture and a good | routing protocol. Unfortunately for the Internet, the development and | research on IP routing protocols that are load-sensitive has come to a | halt. I know that there are people working on these including some of us | at Pluris, but in general, there is strong pushback on anyone that even | suggests that a load-sensitive routing protocol is a better solution | than TE. You should understand that that pushback is based on a technical history. There have been many experiments with load sensitive link state routing protocols. All of them, from the original days of the ARPAnet, have resulted in instability, with oscillations in the traffic matrix and high CPU loading as all of the routers SPF frequently to keep up. Personally, I believe that there is a solution buried somewhere in control theory, but the industry hasn't hit on the right human that knows enough about control theory AND routing protocols to make this work. This has been a pet peeve of mine since about 1987, and yes, everytime someone says that the answer is 'more thrust', we have an educational discussion. | 2) In terms of a management perspective, I think that it is clearly | advantageous to manage a single network with no overlay topology. ATM | was not even close to this and MPLS although closer still does not meet | the goal of the unified network. I am still trying to figure out what | exactly is wrong with a combination of fast/dense/scalable routers and | optical equipment without an overlay architecture. As an aside, I don't | think managing on the order of 5000-10000 LSPs in a core backbone is | easy at all. I don't think anyone is suggesting that managing 5000 of anything is easy. First, you don't need 5000 LSPs to perform traffic engineering. Only enough to redirect traffic away from hot spots. Second, this needs to be automated. This is a small subset of the fact that all of our network management needs automation. Otherwise, we can't possibly hope to get the operator expertise to continue to scale the network. Tony