Re: [mpls] Spencer Dawkins' No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT)

Eric Gray <> Mon, 27 February 2017 19:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04ECF12A2F9; Mon, 27 Feb 2017 11:41:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mdKNtFcnPcpP; Mon, 27 Feb 2017 11:41:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30B4A12A2FC; Mon, 27 Feb 2017 11:41:52 -0800 (PST)
X-AuditID: c6180641-0291898000000a06-47-58b43aaa332e
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id E7.01.02566.AAA34B85; Mon, 27 Feb 2017 15:41:46 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Mon, 27 Feb 2017 14:41:46 -0500
From: Eric Gray <>
To: Spencer Dawkins at IETF <>, Greg Mirsky <>
Thread-Topic: Spencer Dawkins' No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT)
Thread-Index: AQHSkRvaEblNygCx9UeSUWiBa5OqBqF9azOA//+1hFuAAB1nkA==
Date: Mon, 27 Feb 2017 19:41:45 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF64A9FEEF5eusaamb107erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyuXSPn+4qqy0RBgt/6FgcvnCK3eLbtKes FjP+TGS2+Dd3DrPFusun2CxuLV3JarFsyh5mB3aPnbPusnssWfKTyWPW9Da2AOYoLpuU1JzM stQifbsErowb114zFSzazljx+NtclgbGLZsYuxg5OSQETCSOPexn72Lk4hASWM8o8ebiKWYI ZzmjRPP8NjaQKjYBDYljd9aCdYgIJEl82fIfrIhZ4CWjxPKOT0wgCWGBRIkrD18xwRT93LIC ynaSmL3qNJjNIqAqMfvtHdYuRg4OXgFfiWdbeSCWfWeWOHL8P9gCToFAiRtPu8DqGQXEJL6f WgNmMwuIS9x6Mp8J4mwBiSV7zjND2KISLx//Y4WwlSQmLT3HClGfLzFj10uwel4BQYmTM5+w TGAUmYVk1CwkZbOQlM0COo9ZQFNi/S59iBJFiSndD9khbA2J1jlz2ZHFFzCyr2LkKC0uyMlN NzLcxAiMv2MSbI47GPf2eh5iFOBgVOLh3cC2JUKINbGsuDL3EKMEB7OSCG9vOlCINyWxsiq1 KD++qDQntfgQozQHi5I47/WQ++FCAumJJanZqakFqUUwWSYOTqkGxoU3vTgLWvKZ3kTYywYe P/9tTwzzn/Y7zVduOa7Ln7V4ucd9C4H56tW/0522W7xt7Kjv8JFUDfgRk/Xne0rUia/Xn23I Spy0vHlvqcL2Z98P2pb0aSmHqDz4L7h+SWI0Q2vDZ/YV3eLcZZu8Fi/U3aS+KfLs92VCD3KO 3hXbZnpf+rzw3Cuxa5RYijMSDbWYi4oTAWx4BeC7AgAA
Archived-At: <>
Cc: "" <>, "" <>, "" <>, "" <>
Subject: Re: [mpls] Spencer Dawkins' No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Feb 2017 19:41:54 -0000


                While the reference to NTP is forward looking (as Greg suggested) – there is no strong reason to suspect that additional work relative to this specification will _necessarily_ be required.

Transparent Clock (again as Greg mentioned) has not yet been defined for NTP.

                The essential element of transparent clock is that there needs to be a way to determine the amount of time a message spends at each hop (this is the variable component of delay for any given path) so that this delay can be corrected for.  The more hops for which you have this information, the more accurate the corrected time values will be.

                If you can determine the variable delay experienced by a time message, you can combine this information with the measurable fixed delay (associated mostly with light-speed delays) to provide a very precise corrected time value.

                Transparent Clock is quite elegant in that sense, as long as it can be done without layer-violations.  ☺


From: Spencer Dawkins at IETF []
Sent: Monday, February 27, 2017 12:47 PM
To: Greg Mirsky <>
Cc:;; Loa Andersson <>nu>;;
Subject: Re: Spencer Dawkins' No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT)

Hi, Greg,

On Feb 27, 2017 11:13, "Greg Mirsky" <<>> wrote:
Hi Spencer,
yes, only PTP has defined operation of the transparent clock and how to use the residence time to improve accuracy of distributed time.

(Remembering that this is a no-blocking comment)

I'd suggest removing the text reference to NTP in the Introduction, and mentioning that you're allocating the value for NTP in Section 7.2, but that NTP can't make use of this mechanism unless it adds support for transparent clock.

Does that make sense?



On Mon, Feb 27, 2017 at 9:06 AM, Spencer Dawkins at IETF <<>> wrote:
Hi, Greg,

On Feb 27, 2017 09:55, "Greg Mirsky" <<>> wrote:
Hi Spencer,
thank you for your thorough review and the question.
NTP yet doesn't use transparent clock paradigm but in section 3 G-ACh for Residence Time Measurement we've noted that NTP may be one type of TLV and have requested appropriate allocation by IANA in the new sub-registry MPLS RTM TLV Registry (section 7.2). Thus, if NTP will be enhanced to use transparent clock, the RTM over MPLS will be capable to support it.
We're open to your suggestions to make it clearer.

So, is it correct to say that PTP is the only time protocol that uses the transparent clock paradigm today?


Kind regards,

On Sun, Feb 26, 2017 at 1:54 PM, Spencer Dawkins <<>> wrote:
Spencer Dawkins has entered the following ballot position for
draft-ietf-mpls-residence-time-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I'm a bit confused on one point. There's one reference to NTP in the
Introduction, everything else is about PTP, but the specification never
actually says if this mechanism is intended to be usable for NTP as well.
Could that be clearer?