Ron, All true, but the cost is implementing Yet Another Encapsulation.
The bandwidth delta isn't big enough to be worth discussing. What's another 20 bytes? And the reason why OAM isn't in IP is wholly due to politics. If folks really wanted to do good engineering, they would have done BFD for reachability and IP based traceroute. Adding more complexity just so that we can each have our own little standards is NOT efficient engineering and a good use of any of our resources. Tony On Jul 9, 2010, at 11:43 PM, Ron Cohen wrote: > Tony, > > The idea is that this encapsulation is used in scenarios where the MPLS cloud > is PTP-aware. MPLS LSRs act as boundary (or transparent) clocks and ensure > that time delivery is will not be affected by queuing and forwarding delays. > > I think the question in these scenarios should be the other way round: why > should PTP messages sent between two PTP aware LSRs be encapsulated in > Ethernet and/or IP? Beyond bandwidth efficiency, addition of superfluous > layers adds complications and implementation assumptions. I think it is > similar to the reason why OAM messages between two LSRs are not encapsulated > in Ethernet/IP. > > Does this make sense? > > Best, > Ron > > > > > On Sat, Jul 10, 2010 at 8:53 AM, Tony Li <[email protected]> wrote: > > Thanks Ron. > > Please pardon my ignorance, but what's the benefit of this over doing an > EthernetPW? > > Tony > > > On Jul 9, 2010, at 10:27 PM, Ron Cohen wrote: > > > Hi Tony, > > > > PTP is designed to be extended over multiple transports. Some transports > > are included in IEEE1588-2008 Annex-s, while the idea was that others (such > > as MPLS) will be developed by the expert standardization bodies. > > > > I wrote a proposal a while ago for direct PTP over MPLS mapping. It is > > still available here http://tools.ietf.org/html/draft-ronc-ptp-mpls-00 . At > > least part of it still makes sense. > > > > Best, > > Ron > > > > On Fri, Jul 9, 2010 at 10:41 PM, Tony Li <[email protected]> wrote: > > > > And, how can the encapsulation be anything other than EthernetPW? > > > > Tony > > > > > > On Jul 9, 2010, at 12:38 PM, <[email protected]> wrote: > > > > > Hi Yaakov, > > > > > > when you say encapsulation what is the intention e.g. at the interface? > > > > > > Mike > > > ________________________________ > > > From: [email protected] [[email protected]] On Behalf Of > > > Yaakov Stein [[email protected]] > > > Sent: 09 July 2010 05:06 > > > To: [email protected]; [email protected]; > > > [email protected] > > > Subject: Re: [TICTOC] FW: 1588 over MPLS draft > > > > > > Sebastien > > > > > > Yes, developing an MPLS encapsulation for 1588 is high on TICTOC's list > > > of things to accomplish. > > > > > > Y(J)S > > > > > > From: [email protected] [mailto:[email protected]] On Behalf > > > Of [email protected] > > > Sent: Thursday, July 08, 2010 18:37 > > > To: [email protected]; [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 > > > > _______________________________________________ > > TICTOC mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/tictoc > > > > _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
