the closest masters and management of the IP addresses can be complic- ated and burdensome. For Cisco routers running IOS-XR, PTP is enabled on the L3 interface with few lines of configuration (and optional SyncE on the physical interface). Like G.8265.1, the topology is all statically defined and configured, and there is no discovery mech- anism. The slave port is provisioned with the IP addresses of any potential master clocks, and it sets up the unicast negotiation, asking for a stream of Announce messages and then timing messages. However, unlike G.8265.1, this profile allows boundary clocks, and their ports can change state, just like G.8275.1. Based on the Announce message and the configured local priority, the aBMCA will place each port in either master, slave, or passive state. See the earlier sections "The Announce Message" and "Best Master Clock Algorithm" for more details. Again, like G.8275.1, this profile is designed to allow selection of the best reference source based on clock quality traceability (combined with an optional configurable local priority), which helps it establish an optimal network hierarchy for the time distribution. This process is rerun whenever there is a failure event or rearrangement in the network, in order to converge on a new topology. The major difference here is that the best master cannot be "discovered"; it must belong to one of the IP addresses provisioned on the slave port by the operator. Slave T-BC-P T-BC-P 10.2.2.2 Master IP = 10.1.1.1 10.2.2.2 PTP unaware M = Master port network 10.1.1.1 S = Slave port PTP timing flows Figure 7-14 Example Network with G.8275.2 and PTPoIP Although the process is basically the same as G.8275.1, the outcome can be quite different and not optimal. Take the topology illustrated in Figure 7-14. In this case, the operator configures the slave with the IP addresses of two masters. One of those takes a path that is well supported by BCs and the other goes through a network of indeterminate quality. The slave is provisioned to communicate wi