Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt

Ray Hunter <> Fri, 25 October 2013 17:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3FFB11E8359; Fri, 25 Oct 2013 10:38:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BNoxocoBg6cN; Fri, 25 Oct 2013 10:38:37 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f14:62e::2]) by (Postfix) with ESMTP id BD21E11E837F; Fri, 25 Oct 2013 10:38:28 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7EB5787007C; Fri, 25 Oct 2013 19:38:11 +0200 (CEST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PzFpEHYhKdgX; Fri, 25 Oct 2013 19:38:11 +0200 (CEST)
Received: from Rays-iMac-2.local (unknown []) (Authenticated sender: by (Postfix) with ESMTPA id 4C26387003F; Fri, 25 Oct 2013 19:38:11 +0200 (CEST)
Message-ID: <>
Date: Fri, 25 Oct 2013 19:38:09 +0200
From: Ray Hunter <>
User-Agent: Postbox 3.0.8 (Macintosh/20130427)
MIME-Version: 1.0
To: "Ackermann, Michael" <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: v6ops WG <>, 6man WG <>, "" <>
Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Oct 2013 17:38:38 -0000

> Ackermann, Michael <>
> 25 October 2013 01:44
> Ray
> Your Comment: 
> No. I think what I said was that the level of certainty in your measurements is dependent on the level of synchronisation of the 2 clock sources if you are calculating a delta of timestamp of clock 1 - timestamp clock 2.
> My Response:
> Then it sounds like we are in agreement.   Given the appropriate stratum level at both nodes, the desired level of time synchronization is achieved. 
No. We are not in agreement.

Stratum is an indication of how far down you are in the hierarchy from
any NTP Stratum 0 clock.

It says nothing about whether your stratum 0 and my stratum 0 are

We could both be running caesium clocks, and there could still be an
offset if I don't set my reference time of my caesium clock the same as
your reference time. When talking about microsecond or picosecond timing
that will almost certainly be significant.

You really need to know that the true provenance of the clock source is
identical in order to make PDM 1 calculations, not just the stratum.

Hence my comment to couple some sort of "clock ID" to the timestamp.
> Your Comment: 
> I think it might be instructive to go back and look at high school physics books on making measurements, precision, accuracy, and error estimations, especially when taking the difference of two measurements, or making other calculations on top of raw observations
> My Response:  Not sure exactly what this means but I can say that this sounds like theoretical doubt that time synchronization will not work properly in geographically dispersed environments?    I can tell you that it does in our experiences and that the surrounding protocols/implementations are crafted to account for such vicissitudes.  
> I will say that I have no field experience with DCF-77 sources, only GPS and Cesium.  
> Your Comment:
> Equally a stratum 0 clock can be free running if it loses it's radio signal.
> My Response: 
> This comment sort of confused me as well, but suffice to say, if any component is broken, results will be impaired.   Obviously this is not limited to the time synch subject.  
> Finally, your comment about "Middleboxes".    I hope it can be as simple to accommodate as you describe.   My concern is that if there are numerous middleboxes, the fields may get repetitively overlaid, or there will need to be so many separate fields, we could incur excessive complexity or overhead.    Given that we can accomplish this with a workable solution, I am certainly all for it.   
> The more information I can have to manage networks and solve problems, the better!
> Thanks again for your thoughts, inputs and questions!
> Mike