Shahram: I have a few comments about this draft:
A) In clause 3, you say "...the payload can't be deterministically identified by LSRs because the payload type is a context of the PW label and the PW label, and the PW label and its context are only known to the Edge routers (PEs/LERs); LSRs don't know what is a PW's payload (Ethernet, ATM, FR, CES, etc)." However, a new contradictory text in clause 7 says: "It is the job of the LER/LSR to parse the timing message and find out the type of the Timing message and decide whether and how to Time-stamp it (e.g. , BC) or modify existing timestamp in it (e.g., TC)." I think the new text in clause 7 needs to be changed. I don't think we want LERs and LSRs to look inside timing packets to decide how to timestamp it. I think the timing LSPs should be unique and should contain all the information that the LER/LSR needs for its timestamping function. B). Following along the lines of my comment above regarding deep packet inspection, how is 2-step functionality handled in a transparent clock in the MPLS network? To update a follow_up packet, an LSR TC would need to look inside the packet to associate the sequenceID of the Follow_up message with that of the Sync message. Perhaps you should allow only one-step timestamping in all MPLS nodes. Follow_up packets that were generated outside the MPLS network can still pass through, but they will not be modified. This would simplify the timestamping function and negate the need for any deep-packet inspection. C). Clause 6.4 of the newly released draft of ITU-T G.8275.1, Precision time protocol telecom profile for phase/time synchronization, states that "The Ethernet mapping, as per IEEE 1588-2008 Annex F, is agreed as the default mapping for the profile." Sooner or later, you will need to add the PTP-over-Ethernet-over-MPLS encapsulation to section 6 of your standard to support this profile. Richard Tse Technical Advisor PMC-Sierra, Inc 8555 Baxter Place Burnaby, BC Canada V5A 4V7 Phone: +1-604-415-6015 Email: [email protected] www.pmc-sierra.com -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Monday, October 22, 2012 1:28 AM To: [email protected] Cc: [email protected] Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Timing over IP Connection and Transfer of Clock Working Group of the IETF. Title : Transporting Timing messages over MPLS Networks Author(s) : Shahram Davari Amit Oren Manav Bhatia Peter Roberts Laurent Montini Filename : draft-ietf-tictoc-1588overmpls-03.txt Pages : 36 Date : 2012-10-22 Abstract: This document defines the method for transporting Timing messages such as PTP and NTP over an MPLS network. The method allows for the easy identification of these PDUs at the port level to allow for port level processing of these PDUs in both LERs and LSRs. The basic idea is to transport Timing messages inside dedicated MPLS LSPs. These LSPs only carry timing messages and possibly Control and Management packets, but they do not carry customer traffic. Two methods for transporting Timing messages over MPLS are defined. The first method is to transport Timing messages directly over the dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for MPLS networks. The second method is to transport Timing messages inside a PW via Ethernet encapsulation, which is suitable for both MPLS and MPLS-TP networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588overmpls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tictoc-1588overmpls-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
