Re: [Ntp] Is one refid enough

Miroslav Lichvar <mlichvar@redhat.com> Thu, 05 September 2019 11:02 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 A0FB11200E5 for <ntp@ietfa.amsl.com>; Thu, 5 Sep 2019 04:02:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 5phtSwViKnpB for <ntp@ietfa.amsl.com>; Thu, 5 Sep 2019 04:02:30 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3C51200C1 for <ntp@ietf.org>; Thu, 5 Sep 2019 04:02:29 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 51C7D30EE131 for <ntp@ietf.org>; Thu, 5 Sep 2019 11:02:29 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C26AD19C6A for <ntp@ietf.org>; Thu, 5 Sep 2019 11:02:28 +0000 (UTC)
Date: Thu, 5 Sep 2019 13:02:27 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: ntp@ietf.org
Message-ID: <20190905110227.GM15024@localhost>
References: <CACsn0c=0VFPtYHkQnyjaukK3-TBS60J=cZ0LM1hVkuZg3yLG_Q@mail.gmail.com> <4279C9FF-DEF9-42D3-838A-E344307BFF88@meinberg.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4279C9FF-DEF9-42D3-838A-E344307BFF88@meinberg.de>
User-Agent: Mutt/1.12.0 (2019-05-25)
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Thu, 05 Sep 2019 11:02:29 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/OlWIqpOmsd0lP0s9V63M0ueBXJY>
Subject: Re: [Ntp] Is one refid enough
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: Thu, 05 Sep 2019 11:02:33 -0000

On Thu, Sep 05, 2019 at 12:52:00PM +0200, Heiko Gerstung wrote:
> I would expect that a loop in NTP is typically prevented by the stratum level mechanism, if you never accept an upstream server having the same or a higher stratum level than yours, you should not be able to create a loop anyway. I therefore would accept that the refID itself is not required to prevent sync loops, no matter of which degree.
> 
> if A Is stratum 1 and A->B->C->D then B would never choose D because it is stratum 4 and B itself is stratum 2. 

That's how it worked in NTPv3 and it limited the selection
significantly. In NTPv4 clients are allowed to synchronize to sources
having the same or higher stratum. It has some weight in the
source selection (it is included in the root distance), but it doesn't
prevent the selection.

-- 
Miroslav Lichvar