Hi, I believe this document is very important and valuable. I believe there are a few issues that need to be clarified and further explained, as detailed below.
Major Issues: ------------------ 1. Some more details about the deployment scenarios are necessary (especially in Section 4 and Section 18). For example, it is important to explain whether the LER can serve multiple customers. If the MPLS cloud (maintained by a service provider) provides timing services to multiple customers, this document must discuss the fact that LER BCs need to interact with multiple grandmasters, and consequently multiple time references. Similarly, if LSR TCs are syntonized to the master, it implies that they need to choose one master to syntonize to. 2. Figure 1 and Figure 2 describe point-to-point scenarios, but it is important to clarify also point-to-multipoint scenarios, when there are more than two LER BCs. For example, is it assumed that there is a full-mesh of timing LSPs between all LER BCs? 3. More specifically, I could not find a discussion in the document about how PTP multicast event messages are distributed over the timing LSP. Maybe it is implicitly assumed that event messages are sent as unicast? A discussion about this issue is essential. 4. In PTP the BMC algorithm is based on multicast Announce messages, which allow master election, and allow the slaves to discover the master. It is important to add some description about how Announce messages are distributed in the architecture proposed by this document. 5. The IEEE 1588 uses the term "port". Each PTP "port" has a state, which can be master, slave, or passive. The state is determined according to the BMC algorithm. The BMC algorithm determines whether a port is a slave or a master based on the announce messages received through this port. In the current draft, I assume a "port" is in fact defined by a specific timing LSP (corresponding to a specific peer BC/OC), and the set of Announce messages received through it. This implies that Announce messages must either be sent through the timing LSP, or somehow be traceable to a specific timing LSP. This must be well defined in the document to allow consistent implementations. 6. Section 19 currently suggests a few possible solutions. It is important that this document will define a single solution. 7. "Such peer delay measurement messages SHALL NOT use the Timing LSP that runs between two LERs." --> This statement is problematic. It appears you have to use the timing LSP for peer-delay messages, since you want the PDelay_Resp to use the same path as Sync messages, to guarantee that the packet is subject to the same path delay in both cases. 8. A P2P TCs sends PDelay_Req messages to its adjacent clock. However, since TCs do not distribute Announce messages, a TC does not necessarily know who its adjacent TCs are. This is why PDelay_Req is usually sent as multicast (e.g. in 802.1AS). in PTP over MPLS, I am guessing that the TC must maintain a list of all the "neighbors" it needs to send a PDelay_Req to, each "neighbor" corresponding to a timing label. The current document must explain how the TC sends a PDelay_Req (unicast / multicast? To whom?). 9. Security considerations: - If the MPLS network (provider network) serves multiple customers, it is important to analyze the cross-customer effects. For example: o If an LER BC is synchronized to a specific grandmaster, belonging to customer A, then customer A can attack other customers by manipulating its time. o Similarly for a TC that is syntonized to a specfici customer. - The document must discuss the fact that customer timing messages (as opposed to "regular" customer data) cannot be encrypted or authenticated on an end-to-end basis. o Alternatively, authentication/integrity verification mechanism can be used by a shared secret between the customer and provider nodes. 10. Section 18.1 must include more details about the issues listed above (Announce message distribution, PDelay_Req message transmission, etc.). Less major Issues: ----------------------- 11. Some terms in the document are used inconsistently, for example, the terms "time-stamping" and "timestamping" are used intermittently. 12. There is some inconsistency about capitalization, for example, the word "Timing" is sometimes capitalized and sometimes not. Since you are using the term "Timing messages" quite often, I would suggest to add it to the terminology section, and to be consistent about its capitalization, whereas if the word "timing" is used on its own lowercase letters would be more appropriate. 13. Section 1: "Annex F of [IEEE- 1588]" --> "Annex F of [IEEE]" 14. "...NTP messages for clock and time synchronization. The PTP..." --> "...NTP messages for clock and time synchronization. The NTP..." 15. It appears that some of the sections are only applicable to PTP (e.g., Section 4, Section 18, Section 19). That is reasonable, but it should be pointed out explicitly that these sections apply only to PTP. 16. Section 4: "Transparent clocks do not terminate the Timing messages but they do modify the contents of the Timing messages as they transit across the transparent clock" --> This is not true for P2P transparent clocks. 17.Section 7: "For example the following PTP messages (called Event messages) require time-stamping, while other Non-Event PTP messages do not need time-stamping. o Announce" --> Announce is not an event message, so it should be excluded from this list. 18.Section 7: "and PDELAY_RESP_FOLLOW_UP messages must..." --> "and PDELAY_RESP_FOLLOW_UP messages MUST..." 19.Section 12: "IIn order to manage Timing LSPs" --> "In order to monitor timing LSPs" (OAM protocols monitor connections, rather than manage them). 20.Section 15: It would be worth to mention that IPv6 zero checksum may be used, and quote draft-ietf-6man-udpzero. Tal.
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
