I'd pretty much come to the conclusion that TE tunnels weren't really going to achieve the throttling objective over the slow backup link.
I guess the time for IGP to re-establish routing following a link failure is in the order of a few minutes, TE fast reroute I suppose will reduce that to seconds? Even if a few minutes, this is probably quicker/preferable to the current arrangement of manual bypass!
I only got my test lab working properly late this afternoon, a quick test by unplugging the active link did appear to cause a re-establishment faster than I could run the test, i.e. in the order of a few seconds. I need to do more testing to confirm my initial results.
Would a bridged mesh of VPLS tunnels solve the problem of the low bandwidth backup link? Could queues be setup with different bandwidth allocations to apportion the available bandwidth by link? This would use (R)STP to prevent a loop and weighting factors should force the slow speed link to be the hot standby.
The Wiki page for TE tunnels has a confusing statement in the section "Forwarding Traffic onto TE tunnels"
Note that RSVP TE tunnels are unidirectional - it is not necessary to have matching tunnel for reverse direction on tail-end router.
Surely if the tunnels are unidirectional then a matching tunnel MUST be created for the reverse direction on the tail-end router?
Or does this mean TE tunnels are unidirectional in setup, but bidirectional in data transfer?