Minutes for TICTOC meeting @ IETF-80 The meeting started at 17:30 CEST. Karen O'Donoghue and Yaakov Stein chaired the meeting. Dave Marlow took minutes, and Karen was jabber scribe. The agenda was bashed, and the blue sheets distributed. Eliot Lear provided an information brief on Maintaining the Time Zone Database which covered information in draft-lear-iana-timezone-database-01. This was provided to the TICTOC wg because time zones were of interest to many of the TICTOC participants. The Time Zone Database goes back to 1980's, and is based on contributions of hundreds of people. This contains perhaps the most comprehensive and complete Time Zone history. There are about 500 distinct entries in the Time Zone Database where local time is not a continuous function; for example, Daylight Savings time transitions are a step function. Eliot's primary issue is related to the future of the Time Zone Database. The person who is maintaining it is retiring in 2012 with no successor identified. Currently there are many problems with the future for the Time Zone Database including no license structure and no place to store the database, including the historic information. TICTOC participants were invited to comment on Eliot's ID which proposes to transfer hosting of this database to IANA. Stefano Ruffino provided an ITU-T SG15/Q13 update. He went over a number of updates including an updated structure of their documents. ITU-T efforts as they relate to TICTOC: (1) The TICTOC IEEE 1588 over MPLS effort does not impact the ITU-T frequency synchronization initiatives; (2) There is no specific efforts on-going in the Q13 on security, though the outcome of TICTOC in this area could be used and referenced by Q13 Recommendations; (3) Management work is in the scope of ITU-T activities (e.g. Q14). Packet timing management will also need to be addressed. A TICTOC 1588 MIB might be referenced by future ITU-T documents, coordination might be appropriate on this point. Yaakov asked whether discovery is of interest in the ITU or is every clock already manually configured? Discovery is not an ITU-T subject at this time. Yixian Xu provided a Security Requirements discussion based on draft-xu-tictoc-ipsec-security-for-synchronization-00. Of specific interest is whether timing packets need to be identified and understood by Intermediate Systems transferring across an IPsec tunnel. The assumption is that the IPsec tunnel is already in place. Two proposals were discussed, one allowed Intermediate Systems to identify time packets and the other did not. Discussion on this was moved to the mailing list. One needs to be able to recognize timing packets in order to use hardware assists. In discussing whether the time information was encrypted or not, someone said that RFC 3401 has a policy on tunnels where policy decides what goes through the tunnel and what does not. Karen had a short discussion on general security requirements. When the agenda was set for this meeting it was thought that an editor was available to start work in this area; however, an editor is still needed. This discussion was deferred until an editor is found. Karen mentioned that the interim requirements worked out at the Ireland IETF are not available, and that she was looking for notes from Paris interim meeting that covered this area. Someone said that security should go fast since IPsec is closing down. Tim Plunkett provided a brief on Network Time Mechanisms for Improving Computer Clock Accuracy based on draft-marlow-tictoc-computer-clock-accuracy-00. This effort is looking for new mechanisms beyond those identified in NTPv4 (RFC5905) that provide increased time synchronization accuracy for operating system clocks' time and frequency. The ID identifies three candidate mechanisms for experimentation. The use case targeted is a dense concentration of computing elements connected by a gigabit network where a satellite-based time source (i.e., GPS) is used for synchronizing primary time servers and secondary time servers and leaf computing elements are synchronized via the network. In this use case, some of the computing elements need to synchronize to each other to within a microsecond while other computing elements only need to be synchronized to each other to within a millisecond. Initial experiments have been started in the use of NTP Interleave. This is an option similar to the mechanism used in IEEE 1588 and is available in recent NTP distributions. Two other mechanisms were discussed as possibilities including an approach that merged the better capabilities of NTP and IEEE 1588. Stefano Ruffino asked why NTP broadcast mode was used in the initial experiments, and Tim mentioned that this was the option provided in the recent NTP distribution. Tim suggested the start of a standards track effort to develop time synchronization performance metrics that allows different experimental efforts be performed in a way that the results are comparable. Yaakov thought that performance metrics is really an ITU-T effort. Tim Frost said that existing ITU metrics are frequency based. His company has made contributions for time based metrics to ITU. Karen said that metrics related to those worked in the Benchmarking WG could be worked in the IETF. Tim Frost was asked to see whether his company could contribute the metrics to the TICTOC work. Vladimir Smotlacha said he performed experiments with NTP servers using OCXO oscillators showing much higher synchronization levels than those measured by Tim Plunkett in his initial experiments. Vladimir was asked to provide references to his papers, which he later passed through the list. Tim solicited comments and contributions on the mechanisms described and on additional mechanisms that should be considered. Tim Frost discussed the Precision Time Protocol Version 2 (PTPv2) Management Information Base, draft-vinay-tictoc-ptp-mib-00. This is a new draft covering all PTPv2 clocks (ordinary clocks, boundary clocks, and transparent clocks) and goes beyond the telecom profile allowing for multiple ports and multiple instances. Remaining issues to resolve include: (1) How should we handle different profiles, such as the G.8265.1 telecom profile; (2) How should we handle associated data; (3)Do we want to configure PTP clocks via MIBs, or simply collect management information? It was pointed out that SNMPv3 security capabilities can be used. Yaakov asked Tim if he would refresh his Requiremens doc, Tim answered that that he would if there is help and interest. Stefano Ruffino asked how to handle profiles, which Tim answered it would be via a family of MIBs. Ron Cohen asked the diference between the clock and domain, but this was taken to the list. Yaakov said that he wants a 1588 MIB which covers all cases. The Chairs requested review of this draft. There is interest in moving this to a Working Group draft. Shahram Davari discussed the Transporting PTP messages (1588) over MPLS Networks, draft-ietf-tictoc-1588overmpls-00. Shahram reviewed the contents of the draft, including IS-IS and OSPF signaling extensions for 1588 aware LSRs. Open issues with this draft are: (1) Support 1588 over P2MP LSP, which requires co-routed return PTP LSP. There are drafts proposed for LDP and RSVP-TE. (2) Encapsulation Types, Ethernet and UDP/IP Encapsulations are defined. The draft describes mechanisms which are a layer violation. Does the group need PTP PDU directly over MPLS? For the Ethernet encapsulation, Yaakov said to ask the IEEE. Stefano Ruffino raised a concern about modifying the payload. (3) FRR may not be usable since it is not bidirectional, some thought that this was not a concern, just the way it is. Recommend 1:1 or 1+1 protection or redundant master? (4) Is PHP support required? Some thought it would be easier to just say that PHP is not supported. If yes then BGP and Targeted LDP will need extensions. Yaakov Stein discussed Generic MPLS Time Correction Field, draft-stein-tictoc-mpls-00. Shahram pointed out that this is a competing draft to draft-ietf-tictoc-1588overmpls made by the Chair. Yaakov said that he did not want affect the current Working Group draft but to begin working with the MPLS WG to develop a more general solution. The idea is instead of a 1588-specific CF mechanism, to define a generic MPLS mechanism that can be applied to any MPLS packet. This would enable applying CF to any 1588 over MPLS encapsulation or applying CF to NTP or Time Protocol. There are two encapsulation possibilities: (1) Follow-up CF using GAL and (2) In-packet CF. This will require coordination with PWE who control the first nibble registry. The signaling for OSPF, IS-IS, or RSVP-TE can be carried out similarly to in draft-ietf-tictoc-1588overmpls. Ron Cohen, via jabber, said that a similar idea had been suggested in IEEE for an Ethernet time correction field. The planned MPLS Discussions was moved to the next TICTOC telecon since time had run out. Karen is planning to continue monthly discussions via telecon on Tuesdays, these will be announced on the list. WG milestones and charter are badly out of date and these need to be updated.