Hi Sasha, One comment below.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Alexander Vainshtein Sent: July 13, 2010 03:33 PM To: Yaakov Stein Cc: [email protected] Subject: Re: [TICTOC] FW: 1588 over MPLS draft Yaakov, Please see inline below. Regards, Sasha ________________________________________ From: [email protected] [[email protected]] On Behalf Of Yaakov Stein [[email protected]] Sent: Tuesday, July 13, 2010 10:11 PM To: Tony Li; Ron Cohen; Shahram Davari; [email protected] Cc: [email protected] Subject: Re: [TICTOC] FW: 1588 over MPLS draft 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. [[Sasha]] TC is the reason, BC, IMO, is not. MO: Actually, for a BC you also need a way to identify and terminate the PTP packets. It is actually no different than if one uses the pdelay mechanism of a peer-to-peer TC (ie., need to identify and terminate the PTP packets), as opposed to an end-to-end TC (ie., need only to identify the PTP packets). 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. [[Sasha]] QoS is IMO not an issue. It exists over IP as well as over MPLS. 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). [[Sasha]] Exactly!!! If you want every LSR on the way to be able to inspect and modify the packet, you need a RA label or, rather, its analog - let's call it the PTP Alert label, or PTPA for (not so) short. This would be a new reserved label (and yes, some are still left) with the following rules: - just as the RA label, it can be anywhere in the stack except at the bottom - An LSR that observes this label (because it was at the top of the stack or because it has popped all the labels above it) will do the following: * Check the payload of the MPLS packet for being a PTP packet in one of the existing encapsulations (my personal preference is PTP over UDP/IP, but it is not that relevant) * If the check succeeds and the LSR is a TC, update the correction field in this packet * Forward this packet as indicated by the label immediately below the PTPA. If this means sending a labeled packet, add PTPA at the top of the resulting label stack (again, same treatment as for the RA). The forwarding rule is applied regardless of the results of check for carrying PTP. The only differences with RA is that passing the PTPA-labeled packet to a software module is not required (and probably should be avoided). It would be also pretty easy to check if there any malicious LSRs on your LSP that do not recognize PTPA: just use ICMP-Ping in this LSP with and without added PTPA on top... if it does not work with PTPA but works without it, there is an LSR that treats PTPA as an unknown label and discards the packet... Does this make sense? My 2c, Sasha 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 couldnt 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 _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
