ly now gaining traction, such as projects to extend the YANG models to 1588-2019; the telecom pro- files; and frequency synchronization. Once such standards become stable, they will be quickly ad- opted. It will soon become commonplace to configure and monitor SyncE and PTP clocks with a single, unified approach and in a completely vendor-agnostic manner. 12.5 Troubleshooting and Field Testing Congratulations, the timing network has passed all the acceptance criteria and is in production, SO a job well done by all. The celebrations have died down and the project is coming to an end. But now the question is, "What happens when something goes wrong?" This section covers the highlights of how the operations staff can help keep the network aligned and the application people happy. Obviously, some of what can go wrong depends on the behavior and quality of the implementation on the devices you have, but the authors feel that there are some les- sons to pass on that apply generally. 12.5.1 Common Problems The most obvious problems are those relating to configuration. Much of the configuration of PTP is very straightforward; the problem is that many people configure it without knowing what every fea- ture and flag does. The following section on troubleshooting covers a few of the mismatches between master and slave that cause problems, and many of them come down to configuration. So, check the basics first, such as to confirm the values of domain numbers and message rates (if they are configurable) and to ensure that the configured interface is the one passing the PTP traffic. The next lesson is not to overcomplicate the solution. It is not uncommon to see people configure a cross-linked grid of nodes and every interface is configured as a possible source of SyncE and PTP. The thinking is that if a backup link is good, then three or four of them must be better. This is not the case, and doing SO is just asking for never-ending instability that is usually traced back to timing loops caused by unfathomable topologies. Des