IETF Logo Mail Archive

[Ntp] Re: [EXT] Re: [EXT] Re: Re: [EXT] Re: Re: [EXT] [EXT] Focussing loop detection on loop detection only.

"Windl, Ulrich" <u.windl@ukr.de> Tue, 21 July 2026 06:52 UTC

Return-Path: <prvs=6550100d5=u.windl@ukr.de>
X-Original-To: ntp@mail2.ietf.org
Delivered-To: ntp@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 01D0311B0C55D for <ntp@mail2.ietf.org>; Mon, 20 Jul 2026 23:52:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784616744; bh=cwrKNEccdeYpn0y6jiVYioTs+6fhSdxcWfiHNxQJyoQ=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=n/FDlCO/j8FzAnKsVrGQptKRIH8o5wquSNDpwhKelU2ie00H3A3hzZxx0lujm95wY Ce8OSbW3c2X3zO+jJZqcyM59SDnk+w3pQOJH2wRwHNPHHA1tjPd3cPgr/39vV5q5FD szI3GHTzS7Sk14xhD5qV8Hk0Ha1Qzs1GD7rFYHbk=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=ukr.de
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQtNEbXdibFT for <ntp@mail2.ietf.org>; Mon, 20 Jul 2026 23:52:23 -0700 (PDT)
Received: from mail02.ukr.de (mail02.ukr.de [193.175.194.182]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 41A3411B0C450 for <ntp@ietf.org>; Mon, 20 Jul 2026 23:52:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ukr.de; i=@ukr.de; q=dns/txt; s=ukr; t=1784616740; x=1816152740; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cwrKNEccdeYpn0y6jiVYioTs+6fhSdxcWfiHNxQJyoQ=; b=II5UIWNSNrEGN0tXz42a1eFR1AKLQQ+AzPg3DaEN6GHYmiWQijVaWUXt Nkg4m17E7Zzhu16Og+Uhs6ulT6KTGzRTRIkABbUXmymvKFDnGjaXBkLjD dulSaIbyyaIaDpUQbGtAM/2+2NnSgGS/X3pFY3g1CcSCkSJ8rnuIspQBW VhhK6SHB1XVS38hKPqImxsicCBvEwkbNYLXMcY0BeExWoc5VY8vZp1vQC qhofOEepd1TjWMVsuzassdqZoC1ZdUjpLTlXrXmfA9xjnCginnGG3N026 kaBIAg8b+O+u0l+efV+4708zNU5ybUlZqsSAHFnLNq4DbWo8DDa1U3XPN g==;
X-CSE-ConnectionGUID: U2x0OT0iT8eO6XcnYzNnQg==
X-CSE-MsgGUID: lLLDeIQiTvG8fsNG/TquKw==
X-ThreatScanner-Verdict: Negative
X-IronPort-AV: E=McAfee;i="6800,10657,11852"; a="9432345"
X-IronPort-AV: E=Sophos;i="6.25,176,1779141600"; d="scan'208";a="9432345"
Received: from unknown (HELO ukr.de) ([172.24.2.106]) by dmz-infcsg02.ukr.dmz with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jul 2026 08:52:18 +0200
Received: from ukr-excmb07.ukr.local (172.24.2.107) by ukr-excmb06.ukr.local (172.24.2.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Tue, 21 Jul 2026 08:52:17 +0200
Received: from ukr-excmb07.ukr.local ([fe80::4dee:3e0b:b33f:60ac]) by ukr-excmb07.ukr.local ([fe80::4dee:3e0b:b33f:60ac%8]) with mapi id 15.02.2562.045; Tue, 21 Jul 2026 08:52:17 +0200
From: "Windl, Ulrich" <u.windl@ukr.de>
To: Miroslav Lichvar <mlichvar@redhat.com>, Hal Murray <halmurray@sonic.net>
Thread-Topic: [EXT] Re: [EXT] Re: [Ntp] Re: [EXT] Re: Re: [EXT] [EXT] Focussing loop detection on loop detection only.
Thread-Index: AQHdEEyk6/xNV0fDZ0upHtA5Evs8ArZrBJcAgAyUg5A=
Date: Tue, 21 Jul 2026 06:52:17 +0000
Message-ID: <ea01ee64aca947809b5145f8c5c9b93c@ukr.de>
References: <u.windl@ukr.de> <f8c4b23f6a664ba68b2a7abe359a8b50@ukr.de> <20260710091517.C324162003D@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <alSkqHLj2k-n-ffW@localhost>
In-Reply-To: <alSkqHLj2k-n-ffW@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]
x-tm-snts-smtp: 32AC63C36A0CC6C27F0CFBA206AB161B4E1D2A2513DA094E882955AA6580F5542000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Message-ID-Hash: CEFPGF574QPTM6BLJVQ4CJFMW4JCVJMX
X-Message-ID-Hash: CEFPGF574QPTM6BLJVQ4CJFMW4JCVJMX
X-MailFrom: prvs=6550100d5=u.windl@ukr.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ntp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: David Venhoek <david@venhoek.nl>, NTP WG <ntp@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Ntp] Re: [EXT] Re: [EXT] Re: Re: [EXT] Re: Re: [EXT] [EXT] Focussing loop detection on loop detection only.
List-Id: Network Time Protocol <ntp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/H_lkShayXFpEUz-VBd-2GbZxRfA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Owner: <mailto:ntp-owner@ietf.org>
List-Post: <mailto:ntp@ietf.org>
List-Subscribe: <mailto:ntp-join@ietf.org>
List-Unsubscribe: <mailto:ntp-leave@ietf.org>

Hi!

Thanks for explaining. I see. But still: Apart from the time until reaching stratum-16, is the mechanism actually needed?
I'm looking for a case that would suffer permanently (Or at least for a long time) from absence of loop detection.
AFAIR Dave Mills' worries were that some sub-cluster of servers may drift off, and other clients may trust that cluster. Specifically with peering being obsolete, I don't know such configuration. Anybody does?

Kind regards,
Ulrich Windl

> -----Original Message-----
> From: Miroslav Lichvar <mlichvar@redhat.com>
> Sent: Monday, July 13, 2026 10:41 AM
> To: Hal Murray <halmurray@sonic.net>
> Cc: Windl, Ulrich <u.windl@ukr.de>; David Venhoek <david@venhoek.nl>;
> NTP WG <ntp@ietf.org>
> Subject: [EXT] Re: [EXT] Re: [Ntp] Re: [EXT] Re: Re: [EXT] [EXT] Focussing loop
> detection on loop detection only.
> 
> Sicherheits-Hinweis: Diese E-Mail wurde von einer Person außerhalb des UKR
> gesendet. Seien Sie vorsichtig vor gefälschten Absendern, wenn Sie auf Links
> klicken, Anhänge öffnen oder weitere Aktionen ausführen, bevor Sie die
> Echtheit überprüft haben.
> 
> On Fri, Jul 10, 2026 at 02:15:17AM -0700, Hal Murray wrote:
> >
> > Windl, Ulrich said:
> > > I agree with the analysis, but how would loop prevention change the
> > > situation that both servers will end up at stratum 16?
> >
> > It gets there faster.  A never points to B because that would make a loop.
> >  So it jumps directly to stratum 16.  B gets to stratum 16 on its next
> > polling.
> 
> If loop prevention works, A will not select B if B is synchronizing to
> A, so A should stay at stratum 3 and B at stratum 4, and their clients
> can continue using them until their root dispersion/distance becomes
> unacceptable.
> 
> --
> Miroslav Lichvar

v2.46.0 | Report a Bug | By Email | System Status