| I would disagree and argue that your core needs to be running top of the | range routers with fat pipes with spare bandwidth, for a large network if | you run out of CPU or bandwidth your routers will simply fall over. Which CPU are you worried about? My top-of-the-range routers all seem to have more than a dozen in them... The bandwidth I'm worried about right now is on the memory busses; the optical people who make things that blink lights really quickly are well ahead of IP's present needs. | (plus [QoS] will slow down the routing process). Which routing process? Assuming you mean packet forwarding will be slowed down, that really depends on architecture (more modern ones won't show a measurable slowdown, and even less modern ones don't care much about work-conserving fancy queueing - consider Villamizar's projections on SFQ vs CPU/state). Assuming you mean signalling - well - it depends on how you do it. Static support for preset "flavours" (DSCP, diff-serv code points is the jargon - sorry :) ), a small number of priority levels for WFQ or WRED, and so forth is pretty easy to set up. Reservations- based signalling (RSVP et al) is a bit harder, and also consumes more non-human resources. However, I would worry more about QoS signalling slowing down human processes, such as debugging problems and handling complexity, than I would about QoS slowing down high-end packet processing equipment. That said, since detecting blinking lighs fast enough is not presently a constraint on growth, a toolset whose principal use is combatting situations in which there is a bandwidth constraint seems more like an unnecessary frill than essential equipment. Sean.