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

Greg Mirsky <gregimirsky@gmail.com> Mon, 27 February 2017 17:58 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E474129995; Mon, 27 Feb 2017 09:58:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 PI6BQ67pYpnY; Mon, 27 Feb 2017 09:58:28 -0800 (PST)
Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1240129992; Mon, 27 Feb 2017 09:58:28 -0800 (PST)
Received: by mail-ot0-x231.google.com with SMTP id w44so56985482otw.2; Mon, 27 Feb 2017 09:58:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JTvpgK+NIv3AfK82UcLoeGodhRTl+YaXpqsvQdOhAnE=; b=s5P9fQuRDkuG+Xq3k34VsTcjEHjQGXcKZIRVqYGR0opPjC0rr1O7e6BIwSWOZ3A1gr fO3feAp+QPBwIceoNaf2bgS6PRIzoHM4LpB4fH8tQAU6RERU2sJRzjB36GT+ght3ZvXO eC6rrGbNSqy6/USqiYr6kx1ErXLihoDLiOVl8vEdjMbYiRQA7L0XN/4JXu81Yu5WZk2n GIv/xpOh/n9yK0xwO4ZIsVp2XhXb94bpAFTk4UKucDn3WaYv3s+dEwzMS6YarRunLjt/ TRMXY5+0ondHkYGUdxVNijNxLAPenwiUjtnGbmXGn+BEDCoh4TDO2IUSxZch4KUd3aZd ydTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JTvpgK+NIv3AfK82UcLoeGodhRTl+YaXpqsvQdOhAnE=; b=JkxqtKAcbijg3PvrkNXCTMx991ASSlA3JJc1T58EWqr5DifdCK8+vmF6aMEnbvO/cu p8JFlGQCtDUT7Zkh96Q4cE8zUFlSpZ3w286aMp9KuXtwtLKVnxv8kPLq6uV+fZQ7ObOG f4qlCrzgZhBhlRe5tW7lX+oVanU9yVTm/Gzp1GEyIgCAiuAVEN2GaciKlfBXAcliPm6j xnA0tGXX+meQBf4iv6HsYuQclMe7H1gjqGfnO5dw41NWBUIR+pOFRXroZtFSbEVuwd40 SU5f1ndAYnlIRX20DJzTtihCVAGhQjUWJYbdq9hHx+5pKf8LOKUhM6CLtv89+1oJeu1g bYjQ==
X-Gm-Message-State: AMke39mIWP2K1vAhXVjPqw83mvVhZPioeVzeeQh0HABKWWHal25ETaNo8EDylGOxUVaZHny49xE8VWYkFNmb6g==
X-Received: by 10.157.2.6 with SMTP id 6mr10951583otb.118.1488218308059; Mon, 27 Feb 2017 09:58:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.21.21 with HTTP; Mon, 27 Feb 2017 09:58:27 -0800 (PST)
In-Reply-To: <CAKKJt-e1aPM8j8nv+2cSwC1_8cehjbKaKwYWPdUmKJBNm5nTZA@mail.gmail.com>
References: <148814606376.2949.10868917655692470857.idtracker@ietfa.amsl.com> <CA+RyBmXFjsYEmhEPbcWr143GtM0DDDaAoaGrfCL8BNE+F7qTwg@mail.gmail.com> <CAKKJt-c4c8CM77AF1Z61pH6-c4RpsW=YjoiauWNSsCG7o592uA@mail.gmail.com> <CA+RyBmUT=xmYw11m5wsypvd2ibSCdgfQOjZM=YknTiYKrRv1Qw@mail.gmail.com> <CAKKJt-c+NMA+9=YP+f8U3a92dLm_ODGu26ZZDYrd8Z+zLfJhBQ@mail.gmail.com> <CAKKJt-cj3bYxiQck1UCzXwePZ1ka9f=w0334MrZeB+FOpQ69mQ@mail.gmail.com> <CAKKJt-e1aPM8j8nv+2cSwC1_8cehjbKaKwYWPdUmKJBNm5nTZA@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 27 Feb 2017 09:58:27 -0800
Message-ID: <CA+RyBmWvXgN46SLbtffHP1nmcHRYZmYDvr2a-EQFzZ40J1TyWA@mail.gmail.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c114f2699a9a8054986d3ba
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/yukBflSjmrxWO4XCcN8fYmUtRWc>
Cc: mpls-chairs@ietf.org, draft-ietf-mpls-residence-time@ietf.org, "mpls@ietf.org" <mpls@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Subject: Re: [mpls] Spencer Dawkins' No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Feb 2017 17:58:30 -0000

Hi Spencer,
thank you for your consideration.
I think that reference to NTP as one of protocols, and it is broadly used
protocol, to synchronize clocks in the Introduction may be justified. I
propose to add a note, as you've suggested, in section 3 that allocation of
the value for NTP payload is forward looking as use of the transparent
clock not yet been defined for NTP.

Regards,
Greg

On Mon, Feb 27, 2017 at 9:46 AM, Spencer Dawkins at IETF <
spencerdawkins.ietf@gmail.com>; wrote:

> Hi, Greg,
>
> On Feb 27, 2017 11:13, "Greg Mirsky" <gregimirsky@gmail.com>; 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?
>
> Spencer
>
> Regards,
> Greg
>
> On Mon, Feb 27, 2017 at 9:06 AM, Spencer Dawkins at IETF <
> spencerdawkins.ietf@gmail.com>; wrote:
>
>> Hi, Greg,
>>
>> On Feb 27, 2017 09:55, "Greg Mirsky" <gregimirsky@gmail.com>; 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?
>>
>> Spencer
>>
>> Kind regards,
>> Greg
>>
>> On Sun, Feb 26, 2017 at 1:54 PM, Spencer Dawkins <
>> spencerdawkins.ietf@gmail.com>; 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 https://www.ietf.org/iesg/stat
>>> ement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> 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?
>>>
>>>
>>>
>>
>>
>>
>
>
>