IETF Logo Mail Archive

Re: [Ntp] [EXT] Re: I-D Action: draft-ietf-ntp-over-ptp-02.txt

"Windl, Ulrich" <u.windl@ukr.de> Wed, 24 January 2024 10:29 UTC

Return-Path: <u.windl@ukr.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22E9C151065; Wed, 24 Jan 2024 02:29:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBbIRGMBVYva; Wed, 24 Jan 2024 02:29:17 -0800 (PST)
Received: from mail01.ukr.de (mail01.ukr.de [193.175.194.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F4AC14F6BF; Wed, 24 Jan 2024 02:29:15 -0800 (PST)
X-CSE-ConnectionGUID: khBwiMYgTc6YK1aCBuLGJA==
X-CSE-MsgGUID: NOXw49mgSse8Wyd+iV0icA==
X-ThreatScanner-Verdict: Negative
X-IronPort-AV: E=McAfee;i="6600,9927,10962"; a="590131"
X-IronPort-AV: E=Sophos;i="6.05,216,1701126000"; d="scan'208";a="590131"
Received: from unknown (HELO ukr-excmb02.ukr.local) ([172.24.6.62]) by dmz-infcsg01.ukr.dmz with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jan 2024 11:29:12 +0100
Received: from ukr-excmb03.ukr.local (172.24.6.63) by ukr-excmb02.ukr.local (172.24.6.62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Wed, 24 Jan 2024 11:29:11 +0100
Received: from ukr-excmb03.ukr.local ([fe80::1cb4:6e0c:6da4:a8a0]) by ukr-excmb03.ukr.local ([fe80::1cb4:6e0c:6da4:a8a0%4]) with mapi id 15.01.2507.035; Wed, 24 Jan 2024 11:29:11 +0100
From: "Windl, Ulrich" <u.windl@ukr.de>
To: Miroslav Lichvar <mlichvar@redhat.com>
CC: "ntp@ietf.org" <ntp@ietf.org>, "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Thread-Topic: [EXT] Re: [Ntp] I-D Action: draft-ietf-ntp-over-ptp-02.txt
Thread-Index: AQHaTq8XzToLLVPSmkOkhMH1C6Tl6bDowkkg
Date: Wed, 24 Jan 2024 10:29:11 +0000
Message-ID: <1a5437e79aeb476fa24d1b38984aad0d@ukr.de>
References: <170559083139.51727.7055735529782201998@ietfa.amsl.com> <0b00f60b1df14fe49666b0be67813ff6@ukr.de> <ZbDkl8pOAuvTdS9b@localhost>
In-Reply-To: <ZbDkl8pOAuvTdS9b@localhost>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.24.3.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/TZhMkBEoO7kq95I9LQ1mhxoRSDA>
Subject: Re: [Ntp] [EXT] Re: I-D Action: draft-ietf-ntp-over-ptp-02.txt
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2024 10:29:18 -0000

Miroslav,

thanks for explaining; my second issue was whether the abstract should emphasize that "NTP _packets_" are encapsulated(?) in "PTP _packets_". That's what I meant with "transport". I think saying "protocol" instead is more confusing.

Kind regards,
Ulrich

-----Original Message-----
From: Miroslav Lichvar <mlichvar@redhat.com> 
Sent: Wednesday, January 24, 2024 11:21 AM
To: Windl, Ulrich <u.windl@ukr.de>
Cc: ntp@ietf.org; i-d-announce@ietf.org
Subject: [EXT] Re: [Ntp] I-D Action: draft-ietf-ntp-over-ptp-02.txt

On Fri, Jan 19, 2024 at 06:55:41AM +0000, Windl, Ulrich wrote:
> Hi!
> 
> " type is 0x8000 (ORGANIZATION_EXTENSION_DO_NOT_PROPAGATE)" for a prospective standard seems odd (I mean the "do not propagate"), but I admit that I'm unsure what DO_NOT_PROPAGATE actually means for PTP.

The propagation is in respect to data exchanged in PTP announce
messages and boundary clocks. A TLV which should be propagated has to
be saved by the client side of the boundary clock and then included
in its own announce messages transmitted as a server.

In our case with the NTP TLV it shouldn't matter if it's marked as
"propage" or "do not propage" as the TLV is included only in delay
request messages, not announce messages. "do not propagate" seems like
a safer choice in case of bugs.

I understand that having a standard which is not freely available in
normative references is problematic. I'm not sure how well these
things are expected to be explained in an IETF draft.

> I also think that "   This document specifies a transport for the Network Time Protocol
>    (NTP) client-server and symmetric modes using the Precision Time
>    Protocol (PTP)" is sub-optimal: "Isn't it more a "PTP transport for NTP" ? Or is "the PTP protocol" only the packet format?

I probably don't understand the language well enough to see the
difference between the two. Maybe someone else can explain it better.

-- 
Miroslav Lichvar

v2.23.0 | Report a Bug | By Email