Shahram: Thanks for your quick reply. Please see my new comments inline.
Rich -----Original Message----- From: Shahram Davari [mailto:[email protected]] Sent: Wednesday, October 24, 2012 10:39 AM To: Richard Tse; [email protected] Cc: [email protected] Subject: Re: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-03.txt Hi Richard, Thanks for your comments. Please see my responses inline. Regards, Shahram -----Original Message----- From: Richard Tse [mailto:[email protected]] Sent: Tuesday, October 23, 2012 8:27 PM To: [email protected] Cc: [email protected]; Richard Tse Subject: RE: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-03.txt 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. SD> the two statements you mentioned are not contradictory. Based on MPLS architecture the payload of PW is only known to the ingress and Egress LERs and not to intermediate LSRs. This draft proposed to signal whether the payload for a specific Timing LSP is IP or PW so that all LSRs in the path know the payload. The signaling also specifies what type of timing message is encapsulated (PTP, NTP, etc). So a parser can easily parse the Timing message. Parsing of Timing message is required since not all Timing messages require Time-stamping or TC correction. For example 1588 has event messages and non-event messages. 1588 standard requires different time-stamping behavior for different messages. [Richard Tse] I see. From the text in clause 3, my original interpretation was that different labels would be used for different message types. Thus, the LSRs and LERs would not have to look at anything except the label. I really liked this because it was so simple and had only the minor(?) cost of using a few more labels. But, I guess this would be corrupted by the OAM and Mgmt messages which also use the PTP LSPs and require different actions. 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. [SD] For 2-step the CPU can do the parsing and deep packet inspection is not required at line rate in HW. [Richard Tse] I was hoping to simplify the implementation so the LERs would not need a deep-packet processing element to handle transparent clocks. With 2-step clocks, the CPU needs to hold a lot of PTP context to wait and associate follow_up packets with sync packets. When doing deep-packet inspection and 2-step clock context handling, nominal PTP packet rates multiplied by the many PTP connections that may flow through a TC will require non-insignificant processing power. With 1-step clocking, this could all be done in H/W. 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. [SD] The method for transporting Ethernet over MPLS is via PW and that is covered in section 6.2. [Richard Tse] Thanks. I overlooked the fact that you removed all the IP and UDP layers from the PW encapsulation. ---------- 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
