Hi Robert, Thank you for your comments.
> 1. Do we really see that carrying power consumption for the power groups is > something that belongs in link state protocol and flooded to all nodes vs > something that should be done with streaming telemetry to power optimizing > controller ? Yes, given where we are. Many networks today continue to avoid the controller approach. Several have tried that path and found it unsatisfactory. Pragmatically, those who make it work seem to be networks that have a large programming staff and are willing to devote many resources to the care and feeding of the controller. They are very much in the minority. We can have this debate, but it’s pretty off-topic for LSR and will not change reality. > 2. Why does the subject draft consider only RSVP-TE when reporting "Sleeping > Bandwidth" ? Besides wouldn't allocated by RSVP-TE link bandwidth simply time > out after 15 sec when refresh is not seen on the "sleeping link" ? We would be happy to consider other signalling mechanisms if you like. The point is to move traffic off of links and then let them sleep and later restore links when capacity is required. The goal, of course, is to do this without noticeable packet loss. > 3. To accomplish your overall objective I see authors lean towards path > computation as the only way. How about a completely different approach based > on demand vs capacity (possibly with queuing) monitoring and graceful link, > line card draining and natural link/line card bypass via SPF without any > necessity of CSPF ? We await the Internet draft with the details of your proposed architecture. Until then, power conservation seems to suggest that effective traffic consolidation is an excellent tool for network power reduction. Tony _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
