Hi Aijun,
> 1） There is no algorithm can assure the different headend selects the > same sets of links[Let’s call the sleep-able set of links ] to power off, > even each headend use the “most-fill” strategy. (such phenomenon can occur in > any topology network, regarding less they are in the same continent or not ) This is incorrect. You seem to want a miracle. Some mechanism that will always save lots of power no matter what the conditions are. The algorithm that we have described is a practical solution. Given enough capacity in the network, given available paths that can support the traffic, given enough redundancy in the network, and given a correct configuration, the PCPPS algorithm consolidates traffic away from power-save-capable links. The algorithm will avoid congestion situations, even at the expense of keeping links awake. > 2） There is no way to assure any third headend avoid using the above > sleep-able set of links, regarding less of how long they have been idle. Again, we do not want such an assurance. That is a non-goal. If a headend wants to use a power-sleep-capable link, it is because it is the best available link for the traffic, based on the path metric and taking PCPPS into account. Therefore, not using such a link would mean using an even worse link or dropping traffic. > 3） There is no way for every headend to exchange their LSP > requirements, to coordinate their path calculation results----“node-wide > bias” doesn’t lead to “network-wide bias”. We do not want headends to exchange their LSP requirements, nor is that necessary. Routers can work together on a common database to make collaborative decisions. This is the essence of all routing protocols, as well as TE. > Based on the above conclusions, how can the operator power off the idle links? The best way, of course, is to let the PCPPS system operate. It will shift traffic away and the put links and components into power-sleep. In addition, we also have a manual mechanism for powering off components, but this is far less elegant. > Please state the above constraints in your document, and relevant solutions, > before proposing any protocol extensions. Asked and answered. The constraints have already been described. We respect normal TE path constraints plus PCPPS metric modifications. Cheers, Tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
