 not likely to allow its own CE nodes to run as clocks in the timing domain of an external MSP. Even if the CE SP did allow this, there is no possibility for the CE SP to be able to host a second MSP because its own nodes are already clocks belonging to the timing domain of the first MSP. One option is that the CE SP configures its network nodes as transparent clocks (TC) because a TC can be used to update the correctionField in PTP messages belonging to multiple domains. SyncE has no equivalent capability, and unless the hardware used to build the CE network changes funda- mentally, this restriction is not likely to be lifted soon. There are some innovative suggestions as to how to facilitate a network in multiple timing domains, but doing SO is not a realistic option with any currently available technology. Note that MEF has marked the transport of G.8275.1 across a CE network with TC support as a use case "for further study" (see MEF 22.3: 13.4, "Performance of time synchronization architecture"). For MSP, the only option is to ask the CE SP to carry its PTP traffic transparently. This could in- volve using PTP over IP (PTPoIP) or some other technique such as encapsulating the PTP (L2 or L3) in a VPN, tunnel, or pseudowire. No matter which technique is used, the PTP will be transpor- ted without any underlying support from the network (and no SyncE). This introduces all sorts of issues with the network performance and accuracy of the timing signal. For this to work, the MSP must be able to specify and order a service (or circuit) that it can rely on to carry PTP accurately but without on-path hardware assistance. This means being able to order circuits from the CE SP that have very limited PDV and almost no asymmetry. Delivering and oper- ating such circuits under varying network traffic conditions is very difficult. The other problem is, how can the MSP monitor the timing and be assured that the phase is arriving accurately when it appears at the cell site? The MSP can use APTS to be able to correct for asym-