Hi Kurtis, Thanks very much for your input.... <<<snip>>>
Right, I got your point here, now. Although section 5.12 in -02 addresses requirements for some policy control such as "- Bandwidth control to ensure LSPs don't ask for BW over their allocation ". But this pertains to the signaling plane only. Once TE LSPs are established, I am not sure if there is any mechanism toady to throttle down the traffic along the TE paths (except congestion indications provided by packet drops (Tail, random, etc.) or longer delay/jitter (RTCP for certain type of media traffic)) if the load offered onto the TE path exceeds what's requested and causes congestion. Obviously, the differseve PHB installed along the path will manage congestions based upon allocation and priorities of each class on the data forwarding plane.You still have the same problem if you have TE paths from both ISPs on the same links. In the case of congestion, which ISPs TE backs down?Good point. we will structure something to address that. For the example above tho, I don't think SPs would establish traffic engineered trunks (TE tunnels) for one specific customer. Instead, the TE path is established for aggregated traffic from customers that can be grouped into a particular class of traffic (diffserv class).There is not with a single word described any risks, alternatives or problems. I can see a number of complexity problems, as well as problems with ISP agreeing on how traffic and priority is split between different customers. For example if each provider have two VPN customers with sites in each-others networks, if inter-AS links get congested, which of the two customers should be throttled? Etc, I think this is more a political than a engineering problem.
So the traffic can the be managed by class at each PHB based upon its priority and allocation. Preemption may also be configured to resolve TE setup or holding conflicts.