Or, on top of that, how traffic engineering can be performed with shim6..
-igor (firmly in the shim6 does not adress *most* of the issues camp)
Shim6 doesn't do what most end user sites would like to think of as traffic engineering. For a multihomed site, traffic engineering is about inbound or outbound traffic loading. Affecting inbound traffic distribution means that there needs to be a site-specific locus of control that is capable of causing all of the hosts within the domain to alter the destination address that their correspondents are using. This was seen as extremely complicated. Similarly, outbound traffic engineering would require a locus of control that has knowledge of the site's external routing tables and can affect the destination addresses used by the site's hosts. This also seems extremely complicated. Then, there is the inherent conflict: what happens when the remote traffic engineering conflicts with the local traffic engineering? All in all, site traffic engineering is NOT going to be an easy problem to solve in a hop-by-hop forwarding paradigm based on clever manipulation of L3 locators. Architecturally, what one would really like is to not worry about the traffic engineering problem per-se. Rather, what is needed is a mechanism that allows congestion control and mechanisms to feed into the address selection algorithms, so that when a link does become saturated, some traffic (but not all! ;-), shifts to alternate addresses. Tony [Firmly in the camp that not all issues have simple, pragmatic solutions -- and thus not all issues should be solved.]