Minutes for TICTOC meeting @ IETF-79 The meeting started at 09:10. Yaakov took minutes. Al Morton was jabber scribe. Karen bashed the agenda. Discussion order was slightly altered, with the security presentation moved to before the MPLS discussion. Jean-Loup and Stefano prepared an update ITU SG15 Q13 progress, but could not make it to this meeting. Greg presented their slides. Work on the telecom profile for frequency has concluded and now the focus has shifted to performance metrics. Al asked if this work was being liaised to SG12 Q17, as they have developed definitions for PDV. Greg said that SG12 would be consulted, and that the intent was to build on accepted definitions. Yaakov added that for timing more fine-grained PDV information is required. Greg continued stating that the time/phase profile had been on hold until the frequency profile was complete, but had started at the last meeting. This problem is harder since for frequency it is always possible to improve performance by using a better crystal and a longer filter. Here too the most challenging application of interest is mobile backhauling. The first phase of this work will be hop-by-hop and not end-to-end time distribution. There are contributions proposing that the focus be on the boundary clock rather than transparent clock approach, in order to avoid the layer violation. ITU is considering security, management, and interoperability aspects as it has observed that TICTOC is not moving quickly on these issues. The industry is moving fast here and the ITU has thus accelerated its pace. Yaakov asked whether they are taking boundary clock settling time into consideration of the trade-offs between BC and TC, and Greg answered in the affirmative. Karen raised the issue of coordination between the ITU and IETF. The problem is that ITU internal documents are not readily available to IETF participants. Al explained how this problem has been solved in the past by using an FTP “drop box” where documents could be placed without the delays incurred by the formal liaison process. We should ask Jean-Loup to set this up. Greg commented that this is not the only problem in making the coordination work well. A more pronounced problem is the different mode of work, with IETF working continually on the working list but only meeting for 2 hours per meeting, and the ITU working in spurts for a week or two at a time. Greg continued with presentations on management and more specifically on a proposed MIB framework for the 1588 telecom profile. These slides had been prepared for the previous IETF meeting, but due to the amount of contributions could not be adequately discussed then. This is work done mostly by Tim Frost, who could not make this meeting. Tim did most of the work on this, and there was significant input from Cisco. The purpose of these documents is to generate discussion, rather than to present a definitive solution. What are we trying to achieve by timing management ? The main issue is that we need to know as early as possible that a node is losing lock well before it causes a cellular base-station to go down. Right now PTP does not have a defined performance MIB, and every manufacturer builds its own proprietary MIB. Yaakov commented that the situation with NTP is not all that different in that the MIB only covers basic configuration parameters, with specific tools used for more advanced parameter adjustment, and performance data recovered by the algorithm being exchanged in the packet. Greg agreed, and added that with NTP the details change over time, and that the advantage of having a standard MIB would be to freeze the format, albeit at the expense of less visibility. Greg mentioned the autodiscovery issue. This is not of interest to the ITU, since they discuss well planned networks that do not change much over time, with well defined backups. This is an area mainly of interest to the IETF community. Yaakov stated that the draft was specific to the telecom profile, and that this was too narrow a focus for the IETF. Karen asked if it would be possible to have a single MIB applicable to both NTP and PTP. Greg answered that in principle there is a lot in common (such as basic definitions of time, number of bits required for time intervals, clock stability, steps-removed from PRC, etc.), but that such an undertaking would be much broader, take much more planning and time to develop, and would be much harder to get right. Performance metrics have been proposed that work well for the problem of frequency delivery over jittered networks, and IPPM-style metrics may be useful. Karen asked if the authors had looked at the MIB developed for the power profile. Greg answered that they had not specifically, but are aware of the 1588v1 MIB, the 802.1as work, and the power work. Al commented that the IPPM framework did not come for free. Greg said that what customers want is to how a definition of how to test timing equipment properly. He had once discovered an implementation limitation when a customer tested his equipment with a much longer absolute delay than they had considered. The next presentation was Rock who presented a proposal for 1588 in an IPsec environment. The idea was to add a field to the ESP header that identifies the packet as being a timing packet, even when the timing payload is encrypted. This same field could also be used by ipsecme for other purposes. When a packet with this identifier arrives at the end-point it can be readily identified as being a timing packet and timestamped, and intermediate boxes may prioritorize queuing based on it as well. Yaakov asked whether this was not a security hole in itself, as it identified “in the open” packets as being timing packets, and Rock agreed but didn’t think this to be a major problem. Karen asked if he had discussed this with ipsecme. Rock said that he was discussing, and that this suggestion was in line with RFC 5840 (WESP) that enables traffic visibility for intermediate devices by employing this type of header. Yaakov said that this mechanism is interesting as it might solve one of the problems with using IPsec for timing flows, namely the additional jitter added by the decryption (since the timestamping occurs before the decryption). Yaakov presented the state of work on the MPLS encapsulation. At the last meeting the chairs proposed holding conference calls, each call dedicated to a single subject. After the meeting the chairs proposed holding these calls monthly, every 2nd or 3rd Tues of the month at 8 AM Pacific time (a time that was reasonable for US and European attendees). Two such calls were held, both on the subject of timing over MPLS. There are at present three IDs on this subject (draft-stein-tictoc-mpls-00, draft-davari-tictoc-1588overmpls-00, draft-jin-jounay-mpls-mldp-hsmp-01). Although encapsulations had been raised, we are still discussing requirements. Karen added that any mechanism we propose must be relevant for both NTP and 1588. The first question discussed was whether the problem was frequency or time (uncalibrated or calibrated) distribution. The resolution was to work on time distribution, the feeling being that frequency is handled well enough today. The second question discussed was whether we are talking about a network service (provided by the network operator) or an over-the-top service (handled by the customer or higher-layer service provider). The resolution was to initially focus on network service, since this problem is easier to solve. Unfortunately, this is not the way timing is presently provided, but it was felt that if this problem was properly solved, it could potentially change how users operate. The third question was whether an MPLS encapsulation is really needed at all. Some participants claimed that timing may be better (and in many cases already) solved at layers lower than MPLS (Ethernet, OTN, SDH). The hole in that argument is that access to lower layers may not always available, and indeed the MPLS end-to-end path may be supported by concatenation of several disparate transport technologies. No resolution has been reached on this question, and Yaakov proposed asking service providers. Karen commented that she did not remember the debate as being so negative, and she did not feel that there was much opposition to our solving the problem, which many believe to be an important one. Puneet from Broadcom said that they had numerous requests from service providers (including here in China) that wanted a standardized method for carrying 1588 over MPLS. Ralph (as AD) suggested that carry on the discussion on the mailing list, especially since so many stakeholders were not present at the meeting. Karen wrapped up the session with a statement that we will continue holding monthly conference calls, which will be announced on the list. The meeting closed at 10:45.