Re: [Ntp] Antw: Re: Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts

Heiko Gerstung <heiko.gerstung@meinberg.de> Mon, 02 September 2019 08:00 UTC

Return-Path: <heiko.gerstung@meinberg.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 17EDE1200E9 for <ntp@ietfa.amsl.com>; Mon, 2 Sep 2019 01:00:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.29
X-Spam-Level:
X-Spam-Status: No, score=-4.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=meinberg.de
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 eUvAUF8tN4u7 for <ntp@ietfa.amsl.com>; Mon, 2 Sep 2019 01:00:46 -0700 (PDT)
Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0939712006F for <ntp@ietf.org>; Mon, 2 Sep 2019 01:00:46 -0700 (PDT)
Received: from srv-kerioconnect.py.meinberg.de (unknown [193.158.22.2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id 5722D71C0212; Mon, 2 Sep 2019 10:00:42 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.2 server1a.meinberg.de 5722D71C0212
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=meinberg.de; s=mail201101; t=1567411244; bh=camIli+1wACWYgjo97DXTk9zk6kBNbjonKJ5nEYOWLQ=; h=Date:Subject:Message-ID:References:In-Reply-To:Mime-version:From: To:Content-Type:Content-Transfer-Encoding; b=MNIKkTW3E3Ke54zKUIub9tTp7VagGXTlVrZQK/r96rAYqGpiPMGtKxed3GHtjMKP8 MFU5P22ffs7dUI9G+s8qR+kQkhvdC90kwtGGzwt4aZxbgK2/fpjIxjqK15BLPNwYHp O8cRnITCoHqjQQGYqVIdBkP+sWkXfTIw4NOr7e4Y=
X-Kerio-Anti-Spam: Build: [Engines: 2.15.9.1266, Stamp: 3], Multi: [Enabled, t: (0.000005,0.005662)], BW: [Enabled, t: (0.000006)], RTDA: [Enabled, t: (0.188551), Hit: No, Details: v2.7.53; Id: 15.1i61l6q.1djofr0jj.2im5i], total: 0(700)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/10.1c.0.190812
Date: Mon, 02 Sep 2019 10:00:41 +0200
Message-ID: <43FFB9C5-8F9D-491C-8FC6-9DD292009E2A@meinberg.de>
Thread-Topic: [Ntp] Antw: Re: Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
References: <1B4A56E7-16A6-4767-9268-BCF4BEB9A247@isoc.org> <BCA949D7-7D92-43A9-9766-573559A9FC70@meinberg.de> <5D66392D020000A100033273@gwsmtp.uni-regensburg.de> <8F6BAF5F-CC7B-47B9-90FD-BD20D6ABE845@meinberg.de> <20190828103752.GI24761@localhost> <3f4b55ca-02d9-a470-229b-40860866efbf@nwtime.org> <20190828111458.GJ24761@localhost> <e50112dd-f918-1135-74c8-a738ecb70b70@nwtime.org> <55867E75-9813-466B-8E57-0E157DE5AEB9@meinberg.de> <d308b5d4-3d6e-981b-3dfc-9d5938bad78d@rubidium.se> <5D6CB84E020000A100033405@gwsmtp.uni-regensburg.de>
In-Reply-To: <5D6CB84E020000A100033405@gwsmtp.uni-regensburg.de>
Mime-version: 1.0
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+MGQ3NGNiYTgyN2MxZTBhYw==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>, "ntp@ietf.org" <ntp@ietf.org>, "magnus@rubidium.se" <magnus@rubidium.se>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: clamav-milter 0.100.3 at server1a
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/HBUn1xPE55wcdePMGedoKnPHV-0>
Subject: Re: [Ntp] Antw: Re: Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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: Mon, 02 Sep 2019 08:00:48 -0000

Hi Ulrich,

good point. That is why NTP would use that "ID" instead of the IP address to identify itself. That means ntpd could find out timing loops even if they are caused by a routing loop.

Regards,
   Heiko


-- 
Heiko Gerstung 
Managing Director

MEINBERG® Funkuhren GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone:    +49 (0)5281 9309-404
Fax:        +49 (0)5281 9309-9404

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung

Email:
 heiko.gerstung@meinberg.de 
Web:
 Deutsch   https://www.meinberg.de
 English    https://www.meinbergglobal.com

Do not miss our Time Synchronization Blog:
 https://blog.meinbergglobal.com 

Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung
 
 

On 02.09.19, 08:37 "ntp im Auftrag von Ulrich Windl" <ntp-bounces@ietf.org im Auftrag von Ulrich.Windl@rz.uni-regensburg.de> wrote:

    >>> Magnus Danielson <magnus@rubidium.se> schrieb am 28.08.2019 um 13:30 in
    Nachricht <d308b5d4-3d6e-981b-3dfc-9d5938bad78d@rubidium.se>:
    > I agree. If someone knocks on the door with v5 packets, reply in v5
    > form, if someone knocks on the door with v4 packets, reply in v4 form.
    > As people migrate to v5, they can start using all the benefits from it.
    > 
    > For loop‑protection, keeping a list of nodes from the source is a very
    > easy base condition to avoid routing loops, since as an announcement
    
    But remember that a "note" is NOT "an IP address". With multi-homed hosts you
    can have interesting synchronization loops... ;-)
    
    > comes in, if none of the nodes in the list is oneself, you may use it,
    > where as if any of the nodes is oneself, a loop is for sure detected.
    > 
    > While the trace loop detection mechanism is sufficient in theory, it
    > does not completely solve all loop problems, as transient loops may
    > occur, but it at least avoids problems in the long term.
    > 
    > If I only had time to describe all the things I would do to enhance NTP,
    > it has a number of built‑in assumptions which is not useful or correct.
    > 
    > Cheers,
    > Magnus
    > 
    > On 2019‑08‑28 13:23, Heiko Gerstung wrote:
    >> Why not define a method in v5 that not only protects against degree 1 loops
    
    > but maybe also against degree 2,3 or n? 
    >>
    >> This is what I meant when trying to explain that we should not stick to the
    
    > existing packet format with its shortcomings.
    >>
    >> Regards,
    >>    Heiko
    >>
    > 
    > _______________________________________________
    > ntp mailing list
    > ntp@ietf.org 
    > https://www.ietf.org/mailman/listinfo/ntp 
    
    
    
    _______________________________________________
    ntp mailing list
    ntp@ietf.org
    https://www.ietf.org/mailman/listinfo/ntp