is probably not the right thing to do. Difference in interface speeds between the master port and the slave port is not possible in the hop-by-hop scenario because they are connected to each other. With a PTPoIP model, an un- aware node between the master and slave port can change the interface speed (for example, from 1 GE to 10 GE). The differences in the method and rate of serialization will introduce asymmetry (potentially hundreds of nanoseconds). Routing protocols can cause issues that might not be visible to operations staff, the biggest risk being that the forward path and reverse path take different routes. That doesn't happen fre- quently, but there may be no hint that something is wrong, and it may be very hard to track down. Rings are a good way to provide redundancy with the minimum number of links, but a ring must allow both SyncE and PTP to reverse direction based on the source of the best time signal. This places requirements on both SyncE and PTP. Not paying careful attention to configuration in these topologies can also cause timing loops (more SO for SyncE and PTPoIP than PTP over Ethernet [PTPoE]). Using bundled interfaces with PTPoIP can cause asymmetry issues. See the Chapter 11 section "Partial Timing Support with G.8275.2 and GMs at the Edge" for a detailed treatment of this topic because there are several aspects to consider. That is a summary of the issues to consider concerning the topology when making decisions on the form of PTP to use. The next aspect to consider is the specific type of technology used to carry the timing signal. 9.8 Packet Transport One of the major tasks in building a timing distribution network is to ensure that the underlying transport network is not working against what the designer is trying to achieve. It has been men- tioned previously that major support is needed from the transport network, and the requirements can be summarized as follows: Ability to carry frequency in some physical form (SyncE/eSyncE for Ethernet) Not introduce excessive PDV once the PTP m