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)."


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"

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)"
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".


4) In section 16.3, it covers only the transparent clock case.

"(e.g. perform transparent clock or boundary clock processing)"

5) In section 19, there is a missing line-return between sub-bullet #2 and 
#3

6) In section 19, its unclear why the OC and BC case would not apply to 
non-MPLS interfaces aswell.


Regards,

Regards,
Microsemi Corporation
Peter Meyer
Timing & Synchronization - CMPG
Office:+1-613-270-7203 |  Mobile: +1-613-240-9163 
[email protected] |  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

_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc

Reply via email to