Yes, you understand my meaning. :-) And yes, I think we do definitely need reconcile how we define a traffic "path" -- does it mean bidirectional? Only? These are the mind-bending issues that we are left with, given the legacy packet-forwarding based on destination reachability. Perhaps we need to clean-slate that entire assumption altogether? - ferg -- Jon Crowcroft wrote: which reminds me, BGP is totally backwards if you want to control qos, and yet MPLS which has the right model for path engineering has the wrong model for interdomain how do we reconcile needs (complexity) of interdomain relationships in terms of controling transit traffic etc , and needs for engineering paths for sources - ones a sink and the other a source based activity - i know there;'s lots of BGP workaround hacks (esp since various VOIP things make demands) but are there any architecturally pleasant ideas around? In missive <20070516.001750.784.350796@webmail24.lax.untd.com>, "Fergie" typed: >>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 >> >>