Wait, wait. Let's take a bit better effort to define what we're talking about here. Traffic Engineering these days takes one of two forms; one being the ability to multi-home and propagate a particular preference in the [forwarding|reverse] path (given certain parameters), and secondly the ability to establish paths via some MPLS VPN magic (primarily). I think we need to be a little more specific when talk about TE, given the architectural implications. - ferg -- Jon Crowcroft wrote: so your point about TE in previous message was on the money in one sense - customers (oops, sorry end users) bypassing the routes chosen by ISPs who are doin TE may undermine its effectiveness but TE typically operates to optimise for 1 objective function (e.g. loss or throughput) and much measurement shows that even within an ISP and certainly interdomain, the customer can (and some want to) optimise for a different goal which IP and BGP doesnt give ISPs tools to do - e.g. delay or reliability I might agree (loose/lose) source routing might not be the tool for this. how about loose destination routing? I am not just making a joke here- two runaway successes in the intenret, mobile IP and multicast (home agents and PIM RPs), both allow the user to control how traffic _reaches_ them - i think this is a more useful feature than controlling how I can send traffic to someone via someone, neither of whom might want my traffic anywhere near them - one could imagine a number of DoS mitagating tricks if some technique for loose destiantion routeing were devised - and one could use it for the debugging mentioned by someone (just as one uses traceroute and route view servers to gain multiple viewpoints on the net over time...only more directly part of the IP routing "service") LSR: loneliniess of the long distance runner or goalkeepers fear of the penalty? -----aside: oh routing on end systems - Xorp and Quagga work really quite well, and at least in our experience, xorp might end up being quite comercially viable in terms of robust code and interworking... ---- In missive , Vadim Antonov typ ed: >>On Tue, 15 May 2007, Jon Crowcroft wrote: >> >>> if we took ALL routing out of routers, life _would_ be simpler - >> >>That's cute, but does not address the reason why SR is nearly useless in >>the real life - namely that endpoints lack the up-to-date network topology >>information. To specify a path for a packet one has to know what paths >>are available and feasible. >> >>> running path computation on boxed _designed_ to do computation >>> and forwarding on boxeds designed to switch packets fast >>> just sounds like a perfectly reasonable idea to me >> >>Yep. It sounds good until you actually try to put together a working >>network based on that idea. Which immediately uncovers the >>aforementioned problem. >> >>> ISPs and router vendors, which is why they complain so much about every time >>> it when its discussed... >> >>It could be because they do have extensive real-life experience with >>backbone networking and large-scale routing, couldn't it? >> >>> given we havnt actually tried this approach (at the level where end >>> users have access to it) >>You're mistaken. It was tried, and was rightfully rejected because it >>sucked. (BTW, one of the most popular little toys I made was a thingie >>which did domain name-based e-mail routing over UUCP - not by tracking >>global topology maps a la pathalias, but by insertion of the next hop >>lookup step at every transit point. No more stuck e-mail trying to get >>along a precomputed path which has one hop down. That thingie was a smash >>hit in the place where phone lines used to be so notoriously flaky that >>every rain caused a singificant portion of them to get so bad that modems >>couldn't connect.) um, yes, well it sucked because of the fast v. slow path router hardware (it was an early deployment optioon for IP multicast but reversion to other tunneling technqiuues quickly happned when the impact on unicast of having the main processor deal with all the audio/video streaming traffic that Van et al were doing back in 1988 was felt...) - but thats not a network architectural objection its a router hardware design limitation...(and not common to all router hardware designs and not therefore inevitable >>> since the old token/proteon ring and IBM stuff, I think claims about its >>> legitimacy or otherwise are moot >>See many token rings around nowadays? ah, well no - but nor do we see slotted rings which were cheap as ethernet and gave resource guarantees- the best doesnt always win:) >>> as you say, for debugging, it has been quite useful in the past to some people >>> within the service... >>Ah, debugging. It makes zero engineering sense to put a feature used >>primarily in debugging into the expensive and highly optimized fast packet >>path. So what real routers typically do (with rare exceptions) is >>bouncing all packets with IP options to the slow path (i.e. software). v. good point - >>And, of course, the fast path and slow path components use different >>forwarding tables, physically residing in different memories. Which >>sometimes get desynchronized. Or simply broken. When you have couple of >>thousand routers in your network this kind of things tend to happen to you >>now and then. >> >>When you use diagnostic tools relying on the same kind of packets as the >>payload traffic, you have much higher confidence that they show you what >>happens to the real payload. The very first encounter with a fried silicon >>switching engine tends to teach network engineers to use straightforward >>packet probes like ping and traceroute and avoid using fancy stuff in >>their day-to-day work. >>> you know without those pesker users asking for IP adresses >>> and routes and the ability to send data to each other >>> the internet would be a whole lot Gooder >>> and google would clearly do no Evil provably. >>It is useless to portrait network operator guys as control freaks. ISPs >>own their backbones, so it is *their* business decision to select routing >>policies which make economic sense to them. They have to make profit, or >>they are dead meat. Capitalism 101. sure - but if we do build an internet that offers choice (like the phone net does) e.g. because of regulation (oops - sorry, government: bad word in the US:)... >>The pesky customers pay them to get packets delivered, and the ISPs are >>keenly aware of that fact. If there were any significant number of >>customers absolutely positively wanting to control the paths their packets >>take, and willing to pay for that, ISPs would build networks supporting >>this functionality. see above on TE objectives versus customer SLA needs >>The reality is, of course, that customers do not care about paths. They >>care about loss, end-to-end bandwidth and latency. So they actually pay >>money to ISPs to make routing decisions for them. This is called "division >>of labour". yes - i am not trying to disturb that completely cheers jon -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/