Just to clarify:  by simpler  I meant Boundary clock is not required.

From: [email protected] [mailto:[email protected]] On Behalf Of 
Shahram Davari
Sent: Thursday, July 08, 2010 11:06 AM
To: [email protected]; [email protected]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Hi Sebastian,

Thanks for reading the draft. I will try to give you're my own understanding of 
the issue.

We know that if we want better accuracy and control and less complex algorithms 
in the Slave, it is best that most hops between 1588 Master and Slave perform 
Transparent Clocking (TC). As you mentioned one method is to use direct IP 
routing. However there are cases that this doesn't work. For example MPLS-TP 
networks don't support IP routing. Also when 1588 Master and Slave are in two 
different Ethernet networks separated by an MPLS network, it is simpler to just 
tunnel 1588 packets via Ethernet PW.

I hope this helps.

Thanks
Shahram

From: [email protected] 
[mailto:[email protected]]
Sent: Thursday, July 08, 2010 8:37 AM
To: Shahram Davari; [email protected]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Hi,

After reading this interesting draft, I would have some questions for 
clarification (sorry, I will not attend to the Maastricht meeting).

My first general question is related to the objective of TICTOC regarding this 
topic: is it planned that TICTOC would develop a specific mechanism for 
transporting PTP over MPLS as the one proposed in this document? If so, is it 
oriented to telecoms applications, or to other types of applications?

My second question would be to better understand why there is a need for 
transporting PTP over MPLS. It is still unclear to me. FYI, similar discussions 
happened in June in ITU-T Q13/15 during the last Geneva meeting.

My understanding of the context of this draft is that the network between a PTP 
master and a PTP slave experiences full timing support for PTP, such as TC in 
every node (or possibly BC, that is also slightly evoked in the document?). In 
this context, it can be questioned if the PTP timing delivery is really done 
"end-to-end", since every node has to process the PTP messages. Therefore, is 
it really appropriate in this case to put the PTP messages into a tunneling 
transport, such as MPLS?

It looks more logical to me in this situation to transport the PTP timing flows 
outside MPLS (e.g. simply over UDP/IP) on a hop-by-hop basis (e.g. each node 
delivers its timing to the next one).
But maybe I misunderstood or missed something...

Any thoughts?

Thanks.

BR,

Sébastien
________________________________
De : [email protected] [mailto:[email protected]] De la part de 
Shahram Davari
Envoyé : mercredi 7 juillet 2010 21:36
À : [email protected]
Objet : [TICTOC] FW: 1588 over MPLS draft


From: Shahram Davari
Sent: Wednesday, July 07, 2010 12:12 PM
To: '[email protected]'; '[email protected]'; '[email protected]'; '[email protected]'
Subject: 1588 over MPLS draft

Hi All,

Please find attached our first draft of 1588 over MPLS. Since we have some 
technical issues converting the Word format to Txt we couldn't  upload the 
draft before the cut-off date. However we will present the draft in the next 
IETF meeting and will upload the draft after the meeting.

Note that the main WG is TicToc but may require consultation with MPLS and PWE3 
WGs.

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

Reply via email to