Re: What frame relay switch is causing MCI/Worldcom such grief?
Vijay - | Traffic flows change faster than the topology in most cases. So, in other words TE is a hack to make up for people's weaknesses in forecasting that leads one into a connectivity graph where the normally-selected logical path between two points is insufficient for the amount of traffic one wants to shuffle between ingress and egress? "Our forecast horizon is shorter than our planning cycle, so therefore we need TE" is probably the most real argument I've run into so far for doing TE, but it's so terribly sad that this is the case. Again, again, again, just like so many other times in the past. The other "compelling reason" I've run into for TE/MPLS is that it allows some people to close the book on the ATM-switch-in-the-middle-of-a- cluster-of-7[05]xx-es hack that was done in response to another famous underprediction of growth about which the people who seem most in favour of MPLS seem the most unforgiving. Ironic, isn't it? | Traffic measurements from end to end (per city flows) are also | easier to measure with the city to city pipe as it were. Uhm, think about that carefully before you declare it a compelling reason - step 1: sort traffic into categories that group together combinations of the 5-tuple, step 2: count this traffic. Possible implementation: add column to FIB table which is of the type struct counter { long long bytes; long long packets } * When a packet matches the FIB row, forward according to directives in the other columns, and then do: FIBLINE.counter->packets++; FIBLINE.counter->bytes += packet_length; Add glue to allow the FIB-creation-system to assign a particular counter per FIB entry, and some stuff to allow for the nice extraction of this information. One might even put it like this "show interface POS 0/1 quasi-vc <identifier>", which should show you a pretty printed summary of what the relevant counter structure contains. In other words, if extracting information about aggregate traffic flows is the means by which someone justifies deploying a pseudo- circuit-switched network like MPLS, I believe the problem lies in poor communications skills when communicating one's needs to one's vendor(s). Sean.
On Mon, 9 Aug 1999 smd@clock.org wrote:
Vijay -
| Traffic flows change faster than the topology in most cases.
So, in other words TE is a hack to make up for people's weaknesses in forecasting that leads one into a connectivity graph where the normally-selected logical path between two points is insufficient for the amount of traffic one wants to shuffle between ingress and egress?
"Our forecast horizon is shorter than our planning cycle, so therefore we need TE" is probably the most real argument I've run into so far for doing TE, but it's so terribly sad that this is the case. Again, again, again, just like so many other times in the past.
The growth is bursty and that taken into conjunction with the fact that sometimes telco's cannot deliver capacity on demand even when the circuits have been ordered years in advance, definitely leads to a situation where either you 1) have way too much capacity because the telco's suddenly delivered and now you're paying for excess or 2) they don't deliver at all, your traffic growth jumped and now you're forcing 4x through a 1x pipe. It also helps the transient pipe cuts, where you have X capacity between two points, and lose half your capacity to backhoe fade. Allowing for the 95th percentile of traffic to pass, rerouting through the not-so-short path will prevents a total meltdown.
The other "compelling reason" I've run into for TE/MPLS is that it allows some people to close the book on the ATM-switch-in-the-middle-of-a- cluster-of-7[05]xx-es hack that was done in response to another famous underprediction of growth about which the people who seem most in favour of MPLS seem the most unforgiving.
Ironic, isn't it?
Life is full of these.
| Traffic measurements from end to end (per city flows) are also | easier to measure with the city to city pipe as it were.
Uhm, think about that carefully before you declare it a compelling reason - step 1: sort traffic into categories that group together combinations of the 5-tuple, step 2: count this traffic.
It is not a very compelling reason, but it is a reason.
In other words, if extracting information about aggregate traffic flows is the means by which someone justifies deploying a pseudo- circuit-switched network like MPLS, I believe the problem lies in poor communications skills when communicating one's needs to one's vendor(s).
Maybe so. /vijay
participants (2)
-
smd＠clock.org -
Vijay Gill