Tony Have you reviewed the following paper? A. Khanna and J. Zhinky, "The Revised Arpanet Routing Metric" SIGCOMM 89. I believe this paper discusses what was wrong with the first two incarnations of the Arpanet routing protocol as well as solutions to them. The stats that are towards the end are quite interesting. Maybe Craig Partridge at BBN will know more about this, I will CC him in this email. Let me know if you can't find a copy, I have a hard copy that I can forward to you. Also see more comments within: Regards Bora Tony Li wrote:
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.
If there was a desire to work on such a routing protocol in the community, we would definitely like to help. In the meantime, I will keep on working on such a protocol with a small group of people here.
| 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.
This last point is interesting: "Redirecting traffic from hot spots" This now is truly ad-hoc and only achieves short term fixes and a human intervention. I thought one of the purposes of TE was to reduce the amount of management necessary. There is a paper from INFOCOM or SIGCOMM (I am not sure) on the modification of OSPF metrics for TE which formalizes what some ISPs have been doing for a while. This paper is somewhat interesting in the fact, it also is a human intervention method but does not involve MPLS at all. The paper's title is "Internet Traffic Engineering by optimizing OSPF Weights" by Fortz and Thorup.
Tony