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.