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

[Greg Mirsky <[e-mail]>]

Hi Spencer,
I've uploaded the new version of the draft. It includes changes we've
discussed as well as to address comments from Alia, Mirja, Ben, and
Benjamin. I hope that I haven't missed anything.

Regards,
Greg

On Mon, Feb 27, 2017 at 1:36 PM, Spencer Dawkins at IETF <
[e-mail]> wrote:

> Keeping in mind that these are non-blocking comments (so, do the right
> thing) ...
>
>
> On Feb 27, 2017 14:53, "Alexander Vainshtein" <[e-mail]>
> wrote:
>
> 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 ;-)
>
> Thanks,
>
> Spencer
>
> 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" <[e-mail]> 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:[e-mail]]
> *Sent:* Monday, February 27, 2017 12:47 PM
> *To:* Greg Mirsky <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; Loa
> Andersson <[e-mail]>; [e-mail]; [e-mail]
> *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" <[e-mail]> 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 <
> [e-mail]> wrote:
>
> Hi, Greg,
>
>
>
> On Feb 27, 2017 09:55, "Greg Mirsky" <[e-mail]> 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 <
> [e-mail]> 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?
>
>
>
>
>
>
>
>
>
>
>
>