Well the first errors are that the NTP RFC numbers are wrong! They should be 5905 (NTP v4), 5906 (Autokey), 5907 (MIB), and 5908 (DHCP Options).
Danny On 9/1/2010 12:22 PM, Karen O'Donoghue wrote: > Folks, > > Below are the minutes for our July meeting. My apologies for the delay > in getting them out. If you have any comments, we have until 15 Sept to > submit changes. > > Thanks, > Karen > > #################### > Joint NTP/TICTOC Working Group Meeting > Tuesday, July 27, 2010, 1520 – 1700 > > The jabber log can be found at: > http://jabber.ietf.org/logs/tictoc/2010-07-27.txt > > The meeting was called to order by co-chairs Yaakov Stein and > Karen O'Donoghue. Sterling Knickerbocker took the minutes, and > Brian Haberman acted as jabber scribe. Blue sheets were > distributed, and the note well warning presented. > > The proposed agenda was: > 1. NTP issues > - Karen > 2. 1588 over MPLS > - Yaakov > - Shahram > - Ron Cohen > - Lizhong Jin (P2MP LSP with co-routed reverse path) > 3. Timing Security > - Stefano > - Rock > 4. Timing Management > - Tim Frost > 5. Other > - Stefano (ITU SG15 Q13 status update) > > NTP issues > ========== > Slides: > www.ietf.org/proceedings/78/slides/tictoc-10/tictoc-10.htm > > Karen O'Donoghue reviewed recent accomplishments in the NTP WG. > The four primary documents have been published as RFCs (RFC3505, > RFC3506, RFC3507, RFC3508). There is a new draft under > discussion on list (draft-chen-ntps-ra-opt-00.txt). There is > some concern about whether this option should be supported at > all. Further discussion is requested on the mailing list, and > guidance has been solicited from the 6man working group chairs. > > There has been some discussion regarding moving the core NTP RFC > further along the IETF standards track because of its level of > maturity. Further discussion will be held off until after the > Administrative Plenary due to the possible changes to that > process. Yaakov commented that discussions have taken place > about making exceptions for standards track documents and the > multiple implementation requirement. > > ITU SG15 Q13 status update > ========================== > Slides: > www.ietf.org/proceedings/78/slides/tictoc-4/tictoc-4.htm > > Stefano Ruffini presented an update on the activities of ITU-T > SG15 Q13 which has been in operation since 2004. Several > recommendations have been completed including G.8261, G.8262, > and G.8264. An IEEE 1588 Frequency profile is under development > and will be followed by a Time of Day profile. Additional > details are available in the slides. > > Danny Mayer asked why there were no IPv6 based profiles under > development in the ITU-T. Stefano indicated that it could be > could be a future work item. Peter Lothberg asked which version > of UTC is being specified. Stefano responded that it is the most > local UTC, and Peter commented that several companies may have > several UTC sources that may not match within the desired > performance window. > > 1588 over MPLS > ============== > > There were four presentations related to IEEE 1588 over MPLS. > > 1588 MPLS encapsulation > ----------------------- > Slides: > www.ietf.org/proceedings/78/slides/tictoc-0/tictoc-0.htm > > Yaakov Stein presented a summary of the 1588 MPLS encapsulations > options discussed at IETF77 and discussed what would need to be > done next. There was a fair amount of discussion related to the > basic requirements associated with this effort. One question > asked was why do you need special treatment for timing packets. > We need to more clearly articulate the requirements and see if > there are already tools in MPLS to address them. Putting > timestamps as close to the hardware as possible has already been > solved. If a Boundary Clock (BC) or Transparent Clock (TC) is > used, work will be required to handle the signaling. How is > packet routing/rerouting handled? Luca Martini commented that we > need to define the service of the network. A transparent clock > will only work on a known network. Define an MPLS label so the > network knows it is a timing packet and what to do with it. The > requirement for pursuing a special encapsulation is not clear, > and the specifications required for the encapsulation are not > developed. > > 1588 over MPLS > -------------- > Slides: > www.ietf.org/proceedings/78/slides/tictoc-5/tictoc-5.htm > > Yaakov Stein presented a set of slides for Shahram Davari who > was unable to attend. These slides propose an approach to IEEE > 1588 encapsulation. Luca Martini commented that this is fine > with respect to encapsulation but still needs some signaling > work. Something needs to be updated so the router can recognize > this as a timing packet. Another question was does the router > need to recognize it as a timing packet? Does 1588 support P2MP > LSPs? It appears the answer is yes for both Ethernet and IP. > Peter commented that you need to make sure you do not hard code > the solution. There was a comment that TCs are not needed; > however, Steffano commented that TCs are needed for very > accurate time sync. Mark Glasser commented that we should > reorder the options because some are harder/more work. This > appears to be an easier solution. > > (Direct) PTP over MPLS > ---------------------- > Slides: > www.ietf.org/proceedings/78/slides/tictoc-8/tictoc-8.htm > Draft: > draft-ronc-ptp-mps-00.txt (expired) > > Ron Cohen provided an overview of his expired draft on PTP over > MPLS providing a justification for PTP directly over MPLS. Peter > Lothberg asked how big is the MPLS cloud in km or miles? If you > make it large, say 500km of fiber, the delay variation will be > on the order of 200ns. Craig commented that it is assumed that > you can synchronize the boundaries of the MPLS cloud, but that > is the basis of the problem – how do we sync the clocks on the > edge of the cloud? Craig asked if we have looked at the effects > on time sync if the service being provided may not have the same > time reference in the LSR when supporting multiple clocks. > Further discussion was moved to the mailing list. > > P2MP LSP with co-routed reverse path > ------------------------------------ > Slides: > www.ietf.org/proceedings/78/slides/tictoc-1/tictoc-1.htm > > Lizhong Jin presented a set of slides on P2MP LSP with co-routed > reverse path. Yaakov commented that trying to force two slaves > to send their delay_req at different times to avoid congestion > at the Grandmaster sounds complicated. Further discussion was > moved to the mailing list. > > Timing Security > =============== > > There were two presentations on timing security. > > Stefano Ruffini: Packet Timing Security Aspects. > ------------------------------------------------ > Slides: > www.ietf.org/proceedings/78/slides/tictoc-2/tictoc-2.htm > > Stefano provided a discussion on some thoughts on basic > architecture and requirements with respect to timing and > security and possible ITU-T efforts. This is one area where the > ITU-T would like to be able to leverage work done in the IETF. > > Security Requirement for 1588v2 over IPSec > ------------------------------------------ > Slides: > www.ietf.org/proceedings/78/slides/tictoc-3/tictoc-3.htm > > Rock presented two proposed approaches in 3GPP and ITU for IEEE > 1588v2 protection using IPsec, entire protection and partial > protection. In the entire protection approach, all of the 1588v2 > packets are protected with IPsec. For partial protections, the > general messages are protected while the event messages are not. > There was concern expressed that encryption of timing packets > would impact the synchronization accuracy. Further discussion > has highlighted the difference between encrypting timing packets > to secure them versus having to compensate for transmission of > timing packets over a link that is encrypted. Further discussion > on the topic is required. It was also unclear whether this work > should be pursued in the TICTOC or IPSecME working groups. > > Timing Management > ================= > Drafts: > draft-frost-tictoc-management-00.txt > draft-frost-tictoc-ptp-slave-mib-00.txt > > Slides: > www.ietf.org/proceedings/78/slides/tictoc-6/tictoc-6.htm > www.ietf.org/proceedings/78/slides/tictoc-7/tictoc-7.htm > > Tim Frost presented two drafts on network management. Due to > time constraints, discussion was moved to the mailing list. The > chairs thanked Tim for the submission of drafts to initiate the > conversation. > > Karen wrapped up meeting with a reminder to attendees to ask > your questions on the mailing list as some may have been missed > during the meeting. The chairs also indicated that they plan to > hold a series of conference calls to progress to work before the > next meeting. The chairs thanked everyone for the contributions > and discussion. > > The meeting was adjourned at 17:05 pm. > > > > _______________________________________________ > TICTOC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tictoc > > _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
