Hi all, I have been out of contact for a few days, and just found that quite a few of you have commented on this issue.
There seem to have been two issues raised. 1) Why do we need to define an MPLS (or MPLS-TP) encap ? As many have said TC (or BC) is one reason. I am not sure we are going to see TC handling in LSRs any time soon, but it is a reason. Perhaps a better reason for now is QoS. I really want to easily recognize a timing flow to give it EF service. Of course this can be done by giving it its own label and assigning the proper QoS to that label (which is Shahram suggests), but it may be easier to make timing flows universally recognizable (as router alerts are). 2) Why do we need a new encap. Why not just use the UDP/IP one and put it in MPLS, or the Ethernet one in a PW. Of course it is fine to carry 1588 inside UDP/IP or Ethernet inside MPLS. For that matter you can put the 1588 in Ethernet inside an Ethernet PW inside IP (using RFC 4023) inside MPLS, and many other encaps. The problem is the predictability of finding the fields inside. When you say 1588 in Ethernet encap, is that untagged ? 1 VLAN tag ? 2 tags ? MAC-in-MAC ? In UDP/IP is that without IP options ? The idea behind defining another transport layer (and, incidentally, there are already more defined in 1588) We COULD standardize one of these (e.g., never tagged), but what would we do in a hybrid scenario when it comes in from Ethernet with a tag ? Y(J)S -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tony Li Sent: Saturday, July 10, 2010 10:46 To: Ron Cohen Cc: [email protected] Subject: Re: [TICTOC] FW: 1588 over MPLS draft 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 _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
