Hi Peter, Thanks for your great comments. Please see my responses inline.
Thanks Shahram From: [email protected] [mailto:[email protected]] Sent: Wednesday, March 21, 2012 10:10 AM To: Shahram Davari Cc: [email protected] Subject: Re: [TICTOC] Updated 1588 over MPLS draf-03 Hi Shahram et al, These are my comments on the draft. 1) In section 3, I would suggest this paragraph be removed. It is unclear where this problem arises as it seems the GMs are all traceable back to UTC. Many large operators have confirmed the use and distribution of only a single clock domain from core through access, in on-going discussions within ITU_T. Maybe you have some examples of asynchronous PTP clock domain deployments, and where this requirement arises? It would be interesting to know what other traceable time base may be used to distributed throughout the network, and how multiple GMs are themselves synchronized to a timebase other than UTC.. I think it would be easier to remove this paragraph than to start-up such a use case discussion. "There is also a requirement to transport PTP messages belonging to many different 1588 domains across an MPLS network,such as the case for whole sale (carrier?s carrier case)." SD> This issue was raised by others as well. Although this draft can support the mentioned functionality, but I think it is out of scope of this draft and I am going to remove this sentence. 2) In section 4, one example is provided using TCs in the LSRs. I would propse the addition of another example / use case using BCs in the LSRs. This traces back to some earlier comments (not fully vetted by MPLS routing experts) on the reflector that it seems single-hop PTP LSPs could be used between BCs when using a pure BC chain. This is one of the cases listed in section 19 "applicability statements" SD> In The BC at every hop case that you mention, the LSR is really acting as LER since it terminates hop-by-hop LSP. This is different from a real LSR doing BC, meaning that without terminating the LSP do the BC operation. So I am going to leave it as is. Please let me know whether you agree with my assessment. 3) In section 16.2, it covers on the transparent clock case. I would propose the following changes. a) "(e.g. transparent clock or boundary clock processing)" SD> Based on my answer to (2), I don't think we need to do this change since LSR is not really doing BC. b) "After 1588 processing the packet is forwarded as a normal MPLS packet to downstream node (in the case of transparent clock processing), whereas a boundary clock terminates the 1588 packets at each node and re-generates a new packet downstream". SD> Same as above. No change. 4) In section 16.3, it covers only the transparent clock case. "(e.g. perform transparent clock or boundary clock processing)" SD> Same as above. No change 5) In section 19, there is a missing line-return between sub-bullet #2 and #3 SD> Corrected. Thanks. 6) In section 19, its unclear why the OC and BC case would not apply to non-MPLS interfaces aswell. SD> The OC and BC obviously apply to non-MPLS interface, but that is out of the scope of this document which Tries to document the 1588 over MPLS functionality. Regards, Regards, Microsemi Corporation Peter Meyer Timing & Synchronization - CMPG Office:+1-613-270-7203 | Mobile: +1-613-240-9163 [email protected]<mailto:[email protected]> | www.zarlink.com<http://www.zarlink.com/> Shahram Davari <[email protected]> Sent by: <[email protected]> 12/03/2012 08:17 PM To "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "'[email protected]'" <[email protected]>, CCAMP <[email protected]> cc Subject [TICTOC] Updated 1588 over MPLS draf-03 Hi, Please find attached the latest 1588 over MPLS draft (03). Since cut-off date was yesterday, we will upload this after the Paris meeting. Review is required from TICTOC, MPLS, PWE3 and CCAMP WGs, since some aspects from each of these groups are used in this draft. We will present this draft in the relevant WGs in Paris. Regards, Shahram Davari[attachment "draft-ietf-tictoc-1588overmpls-03.txt" deleted by Peter Meyer/Zarlink] _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc ---------- This email is confidential and may contain information that is privileged and exempt from disclosure by law. If you have received it in error, please contact the sender immediately by return email and then delete it from your system; you should not copy it or disclose its contents to anyone. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. Anyone who communicates with us by email is taken to accept these risks.
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
