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

Spencer Dawkins at IETF <> Mon, 27 February 2017 21:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B051127735; Mon, 27 Feb 2017 13:36:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DIzLU6wx6b9d; Mon, 27 Feb 2017 13:36:13 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B6DD012A34C; Mon, 27 Feb 2017 13:36:13 -0800 (PST)
Received: by with SMTP id l138so21338611ywc.0; Mon, 27 Feb 2017 13:36:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=211598jjmLaz+afN7DGvn1aVkpxrHj+alZPwBwj0hLA=; b=aterao8qHnThz5anD/Cm38n3v0wrf8azjpgJsw3sJPMgu+wWVyi7MRF5xjr7OYYxI/ JZoOf2x7OuXijTdmHQGujDn3XDEByRegtKlnkq+Dby/QwD1J99FfbawUXW5DBKslJcCs mybFq52jfMwBcR4lLMiVi10qAe6/hJvRGdzuQGQRlNoXIiLD1P4KsGEZ6f51SpemrT4F bhSS4aNvAdPfML9YxxkvpI/UcosP/dmKQuGGmNo+VTIEMoDDa7234tQetuTB9KA3G/4f GRvVLJOvmaKPnji1gi6ov86nT+D+CFNKrJH8qtkK1zyhNpujWL5jqjmX7istAnI3/p+Y qjlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=211598jjmLaz+afN7DGvn1aVkpxrHj+alZPwBwj0hLA=; b=ojQoxngHRxkWbgfDW+BpPexInzagEU1OYjm7e+hBo21JVBPbqh+pE5OxSA4hzJbCgC pQ0Ky5ZVHI2G19r4r0Jefy9nAFfozG5edDEO1ixApP6j3LA9fCWTtsol01fQZk7iX2CP LU+/i8eTaVT4LLqtVAz2i+aJuP3dHZRJxriZIDXCUBlpc2Z5JePfPKldYUpL+IfL4l6T aCNRlbjRyjiCPuDWNUrdJYD2G0Eo+gOQ3d1u6rKhijLl4Dh6GnQ/zIj6PQ4zAgZj+9Xs Wv47McA7tFup7Fy367boIQQRk+OeOuzQuSlMtyJSIH59nyZQE8MOu+6wferEdmeL7j/r Z9Fg==
X-Gm-Message-State: AMke39nKzZYX4D2zTuvxd6TzzmtMODFY7Zcku3uJwERKa+w1ZCTGuSb+VeOpJ6Foq8uogEHinbNpwKxyEvOVZA==
X-Received: by with SMTP id x189mr12664796ywb.242.1488231372828; Mon, 27 Feb 2017 13:36:12 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 27 Feb 2017 13:36:12 -0800 (PST)
Received: by with HTTP; Mon, 27 Feb 2017 13:36:12 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Spencer Dawkins at IETF <>
Date: Mon, 27 Feb 2017 15:36:12 -0600
Message-ID: <>
To: Alexander Vainshtein <>
Content-Type: multipart/alternative; boundary=001a11491fca5274c0054989deac
Archived-At: <>
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 21:36:16 -0000

Keeping in mind that these are non-blocking comments (so, do the right
thing) ...

On Feb 27, 2017 14:53, "Alexander Vainshtein" <>

Spencer and all,
I concur with Eric.

The RTM mechanism defined in this spec does not depend on the protocol -
NPT, PTP or something else - that is carried over an LSP.

Right, and the Introduction starts out that way, but the Abstract calls out
PTP specifically, and a quick string search turns up 4 "NTP" strings and 70
"PTP" strings in the document (counting the table of contents but you get
the idea). That's probably what misled me.

But the good news is that I'm not likely to be your typical reader ;-)



However, PTP by design can use the information about accummulated on-path
delay (the Correction field in its PDUs has been defined for just this
purpose), while NTP, in its present form, cannot do that.

If/when the NTP spec is updated so that it can use measured on-path delay,
it would be able to benefit from RTM as well - as I see it, without any
substantial changes to this spec.

Hopefully this helps.

My 2c,

On Feb 27, 2017 21:41, "Eric Gray" <> wrote:


                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

                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.  J



*From:* Spencer Dawkins at IETF []
*Sent:* Monday, February 27, 2017 12:47 PM
*To:* Greg Mirsky <>
*Cc:*;; Loa Andersson
*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?