[TICTOC] Minutes from the NTP WG session at IETF 100

dieter.sibold@ptb.de Wed, 22 November 2017 17:35 UTC

Return-Path: <dieter.sibold@ptb.de>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B051294A6; Wed, 22 Nov 2017 09:35:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNVzUMefmlIA; Wed, 22 Nov 2017 09:35:33 -0800 (PST)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BBD01200C5; Wed, 22 Nov 2017 09:35:33 -0800 (PST)
Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id vAMHYVfS026867-vAMHYVfU026867 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Nov 2017 18:34:31 +0100
Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 60C4E5AFB08; Wed, 22 Nov 2017 18:34:31 +0100 (CET)
To: ntp@ietf.org, tictoc@ietf.org
MIME-Version: 1.0
Message-ID: <OFD2349273.33E7890C-ONC12581E0.005F2035-C12581E0.00608A98@ptb.de>
From: dieter.sibold@ptb.de
Date: Wed, 22 Nov 2017 18:34:29 +0100
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha-256"; boundary="-------z32744_boundary_sign"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tictoc/W60lVhCBiQP5jYGukAxYcR5OagE>
Subject: [TICTOC] Minutes from the NTP WG session at IETF 100
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Nov 2017 17:35:39 -0000

The minutes from the NTP/TICTOC meeting at IETF 100 are available under:

https://datatracker.ietf.org/meeting/100/materials/minutes-100-ntp/

Dieter

================================
NTP/TICTOC Joint Meeting
November 13th, 2017, 13:30-15:30
================================
 
NTP WG Chairs: Karen O'Donoghue, Dieter Sibold
TICTOC WG Chairs: Karen O'Donoghue, Yaakov Stein (absent)
Note taker: Tal Mizrahi
Jabber: Kyle Rose
 
===========
NTP Session
===========
 
CHAIR SLIDES
------------
Presenter: Karen O'Donoghue 
Slides: 
https://datatracker.ietf.org/meeting/100/materials/slides-100-ntp-agenda-and-note-well/

 
Summary:
-   Karen presented the new note well.
-   Control Messages Protocol for Use with Network Time Protocol Version 4 
draft:
    -   There are open questions how operators are currently using mode 6
    -   Would anyone be willing to help out Brian with the mode 6 draft? 
    -   There are question about version numbering
    -   Question about the necessity to add additional commands to the 
mode 6 messages
    -   Robert Nagy: I volunteer.
-   BCP 
    -   is in the shepherding write-up stage
-   NTP extension field draft: 
    -   We will be putting together a consensus call about this issue 
after further discussion with the authors.
    -   Harlan: the authors got together a couple of times.
    -   Karen: the authors still need to agree. There seem to be two 
alternatives, and we want to be able to present the options to the working 
group.
 
 
MESSAGE AUTHENTICATION CODE FOR THE NETWORK TIME PROTOCOL
---------------------------------------------------------
No slides were presented.
 
Discussion:
-   Aanchal: will add the security considerations section in the next 
version of the draft.
-   Tal: another comment was regarding whether this MAC could be included 
in an extension field.
-   Aanchal: that was already discussed on the mailing list.
-   Tal: another issue was there should be a subsection about 
interoperability with previous implementations.
 
 
NETWORK TIME SECURITY (NTS)
---------------------------
Presenter: Dieter Sibold
https://datatracker.ietf.org/meeting/100/materials/slides-100-ntp-network-time-security-for-the-network-time-protocol/

 
Discussion:
- Kyle Rose: what is the plan for modes other than client/server?
- Dieter: In the last interim meeting we talked about moving the other 
modes to another draft in the future.
- Daniel Franke: I expect to write an experimental draft about these other 
modes.
- Karen: is there a time frame for moving forward?
- Dieter: not at this time. If we could have an interim meeting, we can 
talk about a plan in the interim.
- Karen: it could be great if we could have a hackathon effort around NTS 
in IETF 101 in London.
 
 
A YANG DATA MODEL FOR NTP
-------------------------
Presenter: Anil Kumar (remote)
https://datatracker.ietf.org/meeting/100/materials/slides-100-ntp-a-yang-data-model-for-ntp/

 
Discussion:
- Harlan: I am assuming there should be compatibility between the YANG 
model interface, the mode 6 interface, and the SNMP MIB interface. 
- Greg: why does this need to be compatible?
- Harlan: functionally equivalent, not necessarily compatible.
- Robert Nagy: I agree that it needs to be equivalent, but not compatible. 
When can we finally get this released? We don't want to continue to update 
this.
- Greg: we want to standardize the base, and then we will be able to add 
extensions in the future.
- Karen: What is your view on the compatibility with mode 6?
- Anil: we did not try to have compatibility with mode 6. We believe it is 
functionally equivalent to the MIB.
- Karen: Harlan, do you believe compatibility with mode 6 is really 
required? It seems that it is not a design objective.
- Harlan: we want to make it easier on the user by having the three 
mechanisms as similar as possible.
- Karen: it is not reasonable to require these three to be compatible, as 
mode 6 and the MIB go back a long time.
- Harlan: let?s try to reach functional equivalence.
- Anil: I will look into it with the other authors.
 
 
 
GUIDELINES FOR DEFINING PACKET TIMESTAMP FORMATS
------------------------------------------------
Presenter: Tal Mizrahi
https://datatracker.ietf.org/meeting/100/materials/slides-100-ntp-packet-timestamp-formats/

 
Discussion:
- Greg: I believe this work is valuable. I would like to suggest clear 
terminology that distinguishes resolution from accuracy. Also suggest to 
discuss how to migrate to a higher accuracy. Another aspect that should be 
discussed is how the control plane communicates the timestamp format. In 
future we might need more resolution as provided by the truncated PTP 
timestamps. We might add a foresight discussion how to migrate to higher 
resolution timestamps.
- Karen: what is the time frame for the next steps?
- Tal: we hope to complete the open issues by the next IETF meeting and be 
ready for WG last call.
 
 
NTP INTERLEAVED MODES
---------------------
Presenter: Aanchal Malhotra
https://datatracker.ietf.org/meeting/100/materials/slides-100-ntp-ntp-interleaved-modes/

 
Discussion:
- Greg: when you say ?improve the accuracy?, what do you mean?
- Aanchal: the accuracy of the timestamp captured by the client or server.
- Greg: when you timestamp in software, there may be nondeterministic 
error. The further you move from the demon, the less accurate it is.
- Rich Salz: the time stamping is already in the kernel space. The further 
you move from the demon, the more accurate.
- Tal: this is very similar to the PTP Follow_up messages. PTP uses 
Sequence ID to match the timestamp and the corresponding event message. Is 
there something similar in the proposed mechanism?
- Aanchal: yes. The receiver verifies the origin timestamp and the 
transmit timestamp.
- Tal: from a security perspective, it looks like if a MAC verification 
fails, you should also ignore the previous and next packet, as they are 
bound by the interleaved timestamps. Please consider this and add text 
about it to the draft.
- Harlan: there was a discussion about where you get the most accurate 
timestamp: closest to the interface, or further from the demon. Both are 
correct, depending on the specific system. There was quite a bit of work 
by Dave Mills about Interleave mode. Regarding the MAC: either the MAC 
works or not, and we drop if it does not work. Interleave mode is a 
wonderful thing.
- Kristof Teichel: this work is very important. Clarification question: 
does the server have to keep per-client states?
- Aanchal: yes.
- Robert: what you did is great. There are security issues that we need to 
think about. If we could avoid adding an additional field for that, it 
would be great.
- Greg: regarding PTP Follow_up messages: what is the frequency of the 
messages from the client to the server? By delaying the information to the 
next query, we increase the interval. If we had used something similar to 
Follow_up messages, the information would be used immediately.
- Karen: please summarize this proposal on the mailing list.
- Aanchal: delay is not an issue here.
- Harlan: interleave mode is most useful in symmetric mode, and less 
useful in client/server mode.
 
ON IMPLEMENTING TIME
--------------------
Presenter: Aanchal Malhotra
https://datatracker.ietf.org/meeting/100/materials/slides-100-ntp-on-implementing-time/

 
Discussion:
- Greg: a timestamp is not necessarily based on wall clock time. It can be 
relative, or can be based on any reference.
- Willem Toorop: a timestamp is a point in time expressed in wall time.
- Greg: it is important to agree on the dictionary.
- Harlan: it is unfair to describe some of these issues in the context of 
NTP.
- Kristof: this work is important. Where can the document be found?
- Aanchal: it is on the agenda.
- Kristof: please use the term monotonic more carefully ? need to define 
it.
- Greg: only NTP is used as a reference to this draft.
- Tal: it is important to clearly define the scope of the document, and 
the target audience. Another issue is that the intended status should 
probably be informational.
- Karen: the scope is very important.
- Ethan Grossman: one of the things that was not clear was what the draft 
was focusing on: implementation considerations, or security aspects.
- Karen: can we have an update to the draft before we start call for 
adoption?
- Aanchal: we would be happy if people could send their comments on the 
mailing list.
 
 
==============
TICTOC Session
==============
 
CHAIR SLIDES
------------
Presenter: Karen O'Donoghue 
Slides: 
https://datatracker.ietf.org/meeting/100/materials/slides-100-ntp-agenda-and-note-well/

 
A YANG DATA MODEL FOR IEEE 1588v2
---------------------------------
Presenter: Yuanlong Jiang
https://datatracker.ietf.org/meeting/100/materials/slides-100-tictoc-yang-data-model-for-ieee-1588v2/

 
Discussion:
- Karen: one remaining unresolved issue. Once we resolve that issue, there 
is probably no need for another WG last call.
- Yuanlong: we are looking into it, and I will update the mailing list 
once we resolve it.
- Suresh Krishnan: has this been reviewed by a YANG expert? Will need to 
be.
- Karen: there was no official YANG doctor review, but it was reviewed by 
YANG experts. We can do a formal YANG doctor review.
- Suresh: please do that when the document is ready.
- Yuanlong: we sent version 05 to the NETMOD working group. We received 
comments on the mailing list. We have not received any formal comments 
from a YANG doctor.
 


-------------------------------------
Dr. Dieter Sibold
Physikalisch-Technische Bundesanstalt
Q.42 - Zeitverteilung mittels IP
QM-Verantwortlicher der Stelle IT
Bundesallee 100 
D-38116 Braunschweig
Tel:    +49-531-592-84 20
E-Mail: dieter.sibold@ptb.de