Re: [mpls] Spencer Dawkins' No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT)
Alexander Vainshtein <vainshtein.alex@gmail.com> Mon, 27 February 2017 20:53 UTC
Return-Path: <vainshtein.alex@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 744A6126D73; Mon, 27 Feb 2017 12:53:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 dGsMLfcwyctv; Mon, 27 Feb 2017 12:53:23 -0800 (PST)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 5C3B2129F03; Mon, 27 Feb 2017 12:53:23 -0800 (PST)
Received: by mail-io0-x229.google.com with SMTP id 90so36713896ios.1; Mon, 27 Feb 2017 12:53:23 -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=Bkj5cZewbS8Pk2W8YtMXspYWRunyBJslG7M2BQhcdxQ=; b=e6Bgq/vKwJK4dlip6DIVQlUzJF2juiErUKxFM+iXUwzgVzk73slgau30I5bhr0AQ8d sv5f7/WI+KD8zkJGX0tZ+FlhNzYd2XpJ556RYOb8xx64VCNoalPiG0upoTm/lswYxTc+ mBqhP4z1L2F7ujGqpCnE+xFXdJ5N8hwW962uQd5QJAVw5h3IUIJITIUaoiJim4aGLsSL UBmbknxoQjK5zMx6liqvPOAlicQRlL4L5W96Jrn+02NNMckiDkrlnildmtZrHnUMejD6 9uqjfaWY/CMU5+jKpMG6NKwrC0rYfVkRmhWzEWCFqjkiiheatjG2lOLfkpiAmxQG4XDj AcFg==
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=Bkj5cZewbS8Pk2W8YtMXspYWRunyBJslG7M2BQhcdxQ=; b=BshIYQ3AM+L8YqcFIIQn+s+iSjqBx1B+jVKgGsZHSGupdsv0ya9c/8g/L2w8+xaUeR hD30itufwEjWOJHbBajomEoBaB04pjMpLXpH8Hi2pWOM8IPfePoNKqborLPFfKqB2Fvq owNvDk1Za3KhOXrKooQzcBjL/HyL/+j484f3N6RP53U+MtiLb9Bsvbvvl4sbD0rbfM9T aC8axucQRnatjPKMdKniBt68U9/Ad43x8WI0ZoZnZ4WtyHTM7Br5Du9LfRShzmqC9DTG uz1zSWnjW1mEqytdn7Iu2x8ipTBvkgSZVTDtgqqPMk+vPbhkdvor+MS02LjguB7fb5fh RcUA==
X-Gm-Message-State: AMke39l5Z26ITTkaHYFyg91eQcTx7coEKmtxpbz5+D1+IJ64SfMNkTddhN0Q9CLBqc3yI2eKXzyYoKUBOZSePQ==
X-Received: by 10.107.147.134 with SMTP id v128mr15322262iod.75.1488228802659; Mon, 27 Feb 2017 12:53:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.79.24.199 with HTTP; Mon, 27 Feb 2017 12:53:22 -0800 (PST)
Received: by 10.79.24.199 with HTTP; Mon, 27 Feb 2017 12:53:22 -0800 (PST)
In-Reply-To: <CAA+i7SsxMH-BFyeEq-zPFPg=bQXMyiPZ9MUvAH7D1hEs3+rB4g@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> <48E1A67CB9CA044EADFEAB87D814BFF64A9FEEF5@eusaamb107.ericsson.se> <CAA+i7Ssyk4NHn-ssiv+kVZmXOxeRhnYhroQ_nXRFjjiHEh8N_A@mail.gmail.com> <CAA+i7SvsWOqEzYOR7SYWvHCPagM=tJqRUW2eGfeTsNEuD5c-LQ@mail.gmail.com> <CAA+i7StXpci6THE5oNu_nS6s0RaScdVF0i4qryFeq0ckab1DJQ@mail.gmail.com> <CAA+i7SsbDDqFsMesX6iObY4yxt-eCiQi3VTWuY9UBoPAqXj6PQ@mail.gmail.com> <CAA+i7SuMJzEr8rq5s6XKBWHcx8nU1tz+uWdrWoLeE-9+N1eoXw@mail.gmail.com> <CAA+i7SsxMH-BFyeEq-zPFPg=bQXMyiPZ9MUvAH7D1hEs3+rB4g@mail.gmail.com>
From: Alexander Vainshtein <vainshtein.alex@gmail.com>
Date: Mon, 27 Feb 2017 22:53:22 +0200
Message-ID: <CAA+i7Svfs6Ec+S7m4a+R_FunhyvVyubobC82XpVyhhtG8woEOA@mail.gmail.com>
To: spencerdawkins.ietf@gmail.com
Content-Type: multipart/alternative; boundary="94eb2c055d18208d0505498945f2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/Yz0ahKEJwiNe0Rg4ji9V2PItVWg>
Cc: iesg@ietf.org, mpls@ietf.org, mpls-chairs@ietf.org, draft-ietf-mpls-residence-time@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 20:53:25 -0000
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. 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, Sasha On Feb 27, 2017 21:41, "Eric Gray" <eric.gray@ericsson.com> wrote: Spencer, 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. J -- Eric *From:* Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] *Sent:* Monday, February 27, 2017 12:47 PM *To:* Greg Mirsky <gregimirsky@gmail.com> *Cc:* iesg@ietf.org; draft-ietf-mpls-residence-time@ietf.org; Loa Andersson <loa@pi.nu>; mpls-chairs@ietf.org; mpls@ietf.org *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" <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/statement/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?
- [mpls] Spencer Dawkins' No Objection on draft-iet… Spencer Dawkins
- Re: [mpls] Spencer Dawkins' No Objection on draft… Greg Mirsky
- Re: [mpls] Spencer Dawkins' No Objection on draft… Spencer Dawkins at IETF
- Re: [mpls] Spencer Dawkins' No Objection on draft… Greg Mirsky
- Re: [mpls] Spencer Dawkins' No Objection on draft… Spencer Dawkins at IETF
- Re: [mpls] Spencer Dawkins' No Objection on draft… Greg Mirsky
- Re: [mpls] Spencer Dawkins' No Objection on draft… Eric Gray
- Re: [mpls] Spencer Dawkins' No Objection on draft… Alexander Vainshtein
- Re: [mpls] Spencer Dawkins' No Objection on draft… Spencer Dawkins at IETF
- Re: [mpls] Spencer Dawkins' No Objection on draft… Greg Mirsky