IETF Logo Mail Archive

Re: [Ntp] Antw: Re: Antw: Re: Antw: [EXT] NTPv5 Loop Detection without Stratum

Miroslav Lichvar <mlichvar@redhat.com> Wed, 31 August 2022 07:30 UTC

Return-Path: <mlichvar@redhat.com>
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 1D5D1C1522C7 for <ntp@ietfa.amsl.com>; Wed, 31 Aug 2022 00:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.678
X-Spam-Level:
X-Spam-Status: No, score=-2.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
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 111CmdTxVd6y for <ntp@ietfa.amsl.com>; Wed, 31 Aug 2022 00:30:07 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98813C14F73E for <ntp@ietf.org>; Wed, 31 Aug 2022 00:30:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661931006; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=D8SJWO+L0grc/9bIOJc10U8W8c6ijj3juGDaH90d/CY=; b=aAQhFEAMus2SYUsnn9Wwp1eNS0JGi2zqakuRU1Dp1l1igDqcDk/iGJE+PlyBbg9prtPMnI RFIRHe51zi36gwETXg/FVpdzUi1oeuPzPv7mcwYAybUaW3Mro2rTb35JjCuPZuHfKiqCZX e3uyVJnewxKClnSRf78DSX1prPGQBOE=
Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-288-PtvaMYVIPoCupPLN4GL36w-1; Wed, 31 Aug 2022 03:30:03 -0400
X-MC-Unique: PtvaMYVIPoCupPLN4GL36w-1
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C78CB3C0D865; Wed, 31 Aug 2022 07:30:02 +0000 (UTC)
Received: from localhost (unknown [10.43.135.229]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 20A3A2026D4C; Wed, 31 Aug 2022 07:30:02 +0000 (UTC)
Date: Wed, 31 Aug 2022 09:30:00 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
Cc: david@venhoek.nl, "ntp@ietf.org" <ntp@ietf.org>, mayer@pdmconsulting.net
Message-ID: <Yw8N+IBYvUD0NRg8@localhost>
References: <DA1F1664-8A84-4197-844A-CA7E8DAA36B8@meinberg.de> <6305BCFE020000A10004CA27@gwsmtp.uni-regensburg.de> <69f413e8-793e-fc9d-849f-6c5971bd2e90@pdmconsulting.net> <630E0EFC020000A10004D2F0@gwsmtp.uni-regensburg.de> <CAPz_-SVPE-Fd1vFWnbu+GAPc=y2bkJMW4pyu98bBwDfcm+R2rg@mail.gmail.com> <630EFA10020000A10004D330@gwsmtp.uni-regensburg.de>
MIME-Version: 1.0
In-Reply-To: <630EFA10020000A10004D330@gwsmtp.uni-regensburg.de>
X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/lowtgnVNK39fI3PH2UDz0fF2JCo>
Subject: Re: [Ntp] Antw: Re: Antw: Re: Antw: [EXT] NTPv5 Loop Detection without Stratum
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, 31 Aug 2022 07:30:12 -0000

On Wed, Aug 31, 2022 at 08:05:04AM +0200, Ulrich Windl wrote:
> >>> David Venhoek <david@venhoek.nl> schrieb am 30.08.2022 um 16:13 in Nachricht
> > No, the loop avoidance algorithm only rejects a source if that source
> > depends on the node itself. So, when having 4 servers A B C and D, if
> > server A is a stratum 1 server, and servers B and C sync to server A,
> > server D can still use all of A,B and C to synchronize. However,
> 
> My point was a bit different: Assume a to D are stratum-1 servers fed by one GPS clock.
> If you configure E to get time from a to D, would E accept more than one of those servers as they are seemingly all fed from the same source, namely GPS? If I understood the rules corretcly, and if there is no exception for Reference-IDs that specify a clock, only one source should be used.

That is not a loop. GPS is not synchronized to an NTP server.

It might be useful to reduce weights of sources sharing the same
source, and the Bloom filter could help with that, but that is a
separate issue from detecting synchronization loops.

-- 
Miroslav Lichvar

v2.23.0 | Report a Bug | By Email