Subject: Re: [ntpwg] Antw: Re: Antw: Re: IPv6 REFIDs

From: Danny Mayer <[email-masked]>
Date: Tue, 02 Jun 2015 12:38:55 -0400

On 6/1/2015 2:11 AM, Ulrich Windl wrote:
>>>> Harlan Stenn <[email-masked]> schrieb am 29.05.2015 um 23:31 in Nachricht
> <[email-masked]>:
> [...]
>>>> sure looks wrong to me - will we detct a timing loop if one path is
>>>> thru the IPv4 address and the other is thru the IPv6 address?
>>>
>>> We don't detect the timing loop through the IP address, we detect a
>>> timing loop through the RefID which could be anything.
>>
>> Not today.  The refid is based on the IP address.  And the RFC currently
>> *does* use the IP as part of the spec for loop detection.  See below.
> 

That's not quite correct. The RFC talks about using the IP address to
create a RefID value but loop detection does not use the IP address,
just the RefID which could be anything. Note that the RefID can only be
used for loop detection if the Stratum is greater than 1, since Stratum
1 servers have RefID's of the Reference clock identifier. Then multiple
servers have the same RefID's.

The current RFC does not describe timing loops so how to do loop
detection is not a well defined condition. That needs to be added.

> That's probably a consequence when you mix the concept with the
implementation: When the daemon used an IP address as refid, ist
implementation could use the IP address instead of the refid. Of course
an implementation should not do that, and a specification not at all.

That's still wrong. If we need to know the IP address of the upstream
server then we should find another way to get it, we shouldn't confuse
it with the RefID.

> [...]
>> I see the following in A.5.5.3:
>>
>>         /*
>>          * A loop error occurs if the remote peer is synchronized to the
>>          * local peer or the remote peer is synchronized to the current
>>          * system peer.  Note this is the behavior for IPv4; for IPv6
>>          * the MD5 hash is used instead.
>>          */
> 
> Are we mixing specification with implemetation again?
> 

That's a consequence of how it's defined in the RFC (or vice versa).
It's not necessarily the right solution to timing loops assuming that we
have a good working definition of a timing loop.

Danny
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 02 Jun 2015 18:56:36 +0000

> servers have the same RefID's.

I'm pretty sure I don't agree with that statement.

> detection is not a well defined condition. That needs to be added.

Not in clear language, but with the code fragments it's clear that the
intent is that if A and B are exchanging time packets, A will not sync
with B if B is getting its time from A.

>> implementation could use the IP address instead of the refid. Of
>> course an implementation should not do that, and a specification not
>> at all.
> 
> It's not necessarily the right solution to timing loops assuming that
> we have a good working definition of a timing loop.

We took a working implementation that currently sees between 1 and 10
TRILLION operational hours PER YEAR and described that implementation in
an RFC that we've been tweaking for about 10 years' time now.

We have a useful number of people looking at both the RFC and the
reference implementation, looking for at least 2 things: 1) places where
they differ, and 2) places where the RFC says things it doesn't need to
say.  When these, or any other questions come up, we talk about them.

"In theory, theory and practice are the same.  In practice, they are
not."

Do you want an NTP RFC that works in theory or in practice?
-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Danny Mayer <[email-masked]>
Date: Tue, 02 Jun 2015 15:24:16 -0400

> Do you want an NTP RFC that works in theory or in practice?

Yes! :)

Danny

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 03 Jun 2015 08:15:33 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 02.06.2015 um 20:56 in Nachricht

[...]
> with B if B is getting its time from A.

I have two problems:
1) "B is getting its time from A" is not exactly defined: Is B getting time from A if A is among the candidates, or does A have to be "sys.peer".

2) When you are referring to code fragments to find out, it must be absolutely clear whether code fragemnts are there to illustrate, or to define. IMHO code fragments should only illustrate. If the specification is not clear enough, fix the specification, and do not add more sample code.

[...]
> Do you want an NTP RFC that works in theory or in practice?

Both. Can something that doesn't work in theory work in practice? Can't something that works in practice be described in ab abstract (not saying "theoretical") way?

Regards,
Ulrich