Re: Optical Crossconnects and IP
Hop-by-hop routing is on its way out....and not soon enough.
Worked fine for the last 20 years. Can you substantiate your assertion? So far all alternatives were shown to bring more problems than improvements.
As for reinventing the virtual circuit, I don't think we can get much lower than this.
I hate to reiterate the obvious, but VCs and global dynamically routed networks don't mix well. --vadim
Vadim Antonov <avg@kotovnik.com> wrote
Hop-by-hop routing is on its way out....and not soon enough.
Worked fine for the last 20 years. Can you substantiate your assertion? So far all alternatives were shown to bring more problems than improvements.
I am certainly not one to forget where we came from. It did, and will, have its place in the network. However, more end to end knowledge is required in a converged network. I am for one looking to ease the load of general traffic engineering. In the giant carrier backbone, it may be better to use your resources wisely, than to overbuild your network. I hear a phrase quite often "Everything is going to IP". Well, before my phone call is on IP, I want some guarantee that its getting from point A to point Z at the rate I'm paying for. On the OXC front: The usage that may become dominant, is more protocol agnostic. The sales of point to point lambda windows makes for a pretty cool application. This looks more to be a "carrier-to-carrier" application. Rather than leasing dark fiber, you can just buy a lambda to complete your ring...etc. We might finally have a good use for all this glass going in the ground. And before I slip too far off topic.... -tm
In message <200005091444.JAA03955@worf.netins.net>, Tony Mumm writes:
However, more end to end knowledge is required in a converged network. I am for one looking to ease the load of general traffic engineering. In the giant carrier backbone, it may be better to use your resources wisely, than to overbuild your network.
I hear a phrase quite often "Everything is going to IP". Well, before my phone call is on IP, I want some guarantee that its getting from point A to point Z at the rate I'm paying for.
Tony: I hope you won't get upset if I use your short comment here to get on a high horse and rant for a moment. Over the past several years, I've heard several people say we need to embed more end-to-end knowledge into the network, as a solution to quality of service, or reliability, or some other valuable function. What I have not heard yet is: 1. A cost-benefit tradeoff. Embedding end-to-end cognizant information into the network has a cost, often in reduced flexibility (e.g., look at how hard it is to add new applications to the telephone network vs. the IP network). 2. A reasoned technical justification that shows that we can't provide the same service with the current service model (which I define roughly as "route based on the contents of the IP header") and that we need to break or bend the current model to do new things. Let me give a concrete example. It is fairly clear that one of the advantages of packet switching is that it allows us to build fairly reliable networks out of much less reliable parts. (Viz: the Internet is getting closer and closer to the reliability of the telephone network, yet no one claims that a Cisco router is as reliable as a #5ESS). Yet, oddly enough, we don't know exactly how reliable each component in an IP network has to be to achieve a given level of reliability (esp. in the face of multiple possible transit paths). If we knew this information we could more rationally budget our resources to build our networks. We could also potentially design IP networks that are *more* reliable than the telephone network, and run telephony and other more demanded services over them. But we haven't asked these kinds of questions... so how can we be confident that putting end2end solutions in the network is the right solution??? Craig
participants (3)
-
Craig Partridge -
Tony Mumm -
Vadim Antonov