e to be smart enough to know what to do when something fails. One ap- proach to network recovery is to have all the routing decisions made at one central place by either a technician or a cleverly programmed computer. When a link fails, the network operator or facilities program figures out how to route its traffic and executes the change. This is a difficult environment to govern, and of course, one has to plan for what will happen when it is the administration center itself that fails. The other approach is to have individual network nodes take over their routing func- tions, with each node programmed with the proper response to a link failure. These self-healing networks are hard to design and often difficult to provision, but they have no central processor that acts as a single point of failure for the entire network. One of the difficult points of designing decentralized self-healing networks is that each node working independently still has to contribute to a whole network working well. Usually, the first response of a decentralized network to a link failure is fine: Each end point does the right thing and reroutes its calls over the route the designers planned for the failure. Later on, when some of the links are overloaded from the over- flow and there is another failure, the system may not fail so gracefully. Figuring out all the multiple states of a network in transition after a failure is a daunting task. As a re- sult, when a second failure does occur, circumstances may arise that the designers did not foresee at all. Switches, cross-connects, and wireless base stations all have software systems that also can be overworked during a link or component failure. One problem that can arise due to an error in network design is called a glare con- dition. A glare condition occurs when two parts of a telephone system are both waiting for the other component to do something, A simple example of a glare condition in a set- ting familiar to many telephone users is a clash between call waiting and three-way calli