Hi Manav,
A high level point is that for the pure MPLS mapping (section 5.3) , I wonder if what is really needed is a PTP profile for MPLS -- similar to Annex D/E/F for IPv4/IPv6/Ethernet, respectively. For example the IP & Ethernet profiles include other information such as the port addressing for the unicast master table and acceptable master table. Without a full profile, although the intermediate notes may operate in TC, the server, client and boundary nodes may not operate successfully. Its not clear if this draft is intended to cover all clock types (OC, BC & TC) or only TC. There are many sections that talk only about TC without considering OC and BC behaviour or impact. Is BC intended to be covered as a Client-side OC + Server-side OC model, or is BC excluded from consideration in this draft? Perhaps this draft should be either cleaned-up to consider all clock types or should be restricted to only TC clock type with OC & BC out of scope. Some specific comments + The abstract could be clarified to indicate there are three mappings, not two (pure MPLS, UDP/IP over MPLS and Ethernet over MPLS). I think the third mapping may be under discussion, so perhaps this is premature. + A few places in the text the phrase "proper handling of these packets" or "properly handle PTP messages" or "perform proper processing" is used to mean transparent clock. I would propose to remove such language as from the ITU-T studies of timing performances of PTP one could argue the "proper" way is to implement a boundary clock. Where the intention is to aid the designer of a TC that is fine to describe the implementation recommendation, but not to suggest this is the way to acheive the best performance or even the desired way to deploy PTP over MPLS. + I would like to see a statement added in the document that the performance aspects (e.g. the phase or frequency alignment) are outside the scope of the document. + Section 6, 7, 8, 10 and 13 seems to focus only on the TC case between OC's and does not consider BC situation. + Section 12 text on checksums could be improved to indicate this only applies to TC and not to OC & BC. + Section 16 seems to address only TC clocks and not OC or BC clocks. + Section 16.3 implies that the only possible way to handle PTP is TC, excluding BC --- "don't have the capability to process 1588 packets (e.g. TC processing)" and " Non-1588-aware LSRs ignore the RSVP 1588_PTP_LSP object and just switch the MPLS packets carrying 1588 messages as data packets and don't perform any TC processing." Regards, ZARLINK Semiconductor Peter Meyer Timing & Synchronization Communication Products Group Office: +1-613-270-7203 | Fax: +1-613-592-1010 [email protected] | www.zarlink.com "Bhatia, Manav (Manav)" <manav.bhatia@alc To atel-lucent.com> "[email protected]" <[email protected]> Sent by: cc <tictoc-bounces@i etf.org> Subject [TICTOC] draft-ietf-tictoc-1588overmpls-00.t 26/01/2011 11:22 xt AM Hi, We've tried incorporating most of the comments that we received on the list. Please ping me if you think we have missed some. Would be great if the WG can go through this and provide feedback on the same. The draft is available here: http://www.ietf.org/internet-drafts/draft-ietf-tictoc-1588overmpls-00.txt Cheers, Manav > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of [email protected] > Sent: Wednesday, January 26, 2011 9.30 PM > To: [email protected] > Cc: [email protected] > Subject: [TICTOC] I-D Action:draft-ietf-tictoc-1588overmpls-00.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 PTP messages (1588) over > MPLS Networks > Author(s) : S. Davari, et al. > Filename : draft-ietf-tictoc-1588overmpls-00.txt > Pages : 35 > Date : 2011-01-26 > > This document defines the method for transporting PTP messages (PDUs) > over an MPLS network to enable a proper handling of these packets > (e.g. implementation of Transparent Clocks (TC)) in LSRs. > Cheers, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
