nanog mailing list archives

Re: Optical Crossconnects and IP


From: Tony Li <tli () procket com>
Date: Thu, 11 May 2000 10:54:30 -0700



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



Current thread: