Subject: [mpls] Ben Campbell's No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 01 Mar 2017 15:16:39 -0800

Ben Campbell 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 have no objection, but do have some a few minor comments:

Substantive:

-2.1, 4th paragraph from end: Can you offer guidance on what might
constitute a reasonably bound wait time?\

-2.1, 2nd paragraph from end: "... MUST NOT do both": What's the scope of
that MUST NOT? Does it mean MUST NOT ever? NUST NOT in the same
message?

Editorial:
- Abstract: The last paragraph is a single, long sentence. Please
consider breaking it into simpler sentences.

- 2.1, paragraph 9: "This bit, once it is set by a two-
   step mode device, MUST stay set accordingly": Can that MUST be stated
in process terms? That is, <actors>  MUST NOT unset this bit..."

-2.1, paragraph 11:  "Without loss of generality should note
   that handling of Sync event messages..." : I don't follow the
sentence; are words missing and/or out of order?
-- "Following outlines handling of PTP Sync event message by the two-step
RTM node.": I think there's a missing "the" at the start. It's absence
completely changes the meaning of "following outlines"-- as written it
seem like the verb is "following", but I think you mean it to be
"outlines".
-- I have trouble matching some pronouns to their antecedents in the rest
of the paragraph.

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 2 Mar 2017 09:21:45 -0800

Hi Ben,
thank you for your thorough review and comments. Please find my answers
in-line tagged GIM>>.

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/
GIM>> Section 7.7.2 Message transmission intervals in IEEE.1588.2008
defines algorithm to calculate intervals  between PTP control messages that
will, in turn, define the range for "the reasonably bound time". But
specification of the precise values are deferred to the appropriate PTP
profiles.

> that MUST NOT? Does it mean MUST NOT ever? NUST NOT in the same
GIM>> This is in reference to the node behavior in context of the same LSP.
On the given LSP the RTM-capable node MUST NOT perform in one-step and
two-step mode.

> consider breaking it into simpler sentences.
NEW TEXT

   Residence time is the variable part of propagation delay of timing
   and synchronization messages.  Knowing what this delay is for each
   message allows for a more accurate determination of the delay to be
   taken into account in applying the value included in a Precision Time
   Protocol event message.

> in process terms? That is, <actors>  MUST NOT unset this bit..."
OLD TEXT

   PTP messages also include a bit that indicates whether or not a
   follow-up message will be coming.  This bit, once it is set by a two-
   step mode device, MUST stay set accordingly until the original and
   follow-up messages are combined by an end-point (such as a Boundary
   Clock).

NEW TEXT

   PTP messages also include a bit that indicates whether or not a
   follow-up message will be coming.  This bit MAY be set by a two-step
   mode PTP device.  The value MUST NOT be unset until the original and
   follow-up messages are combined by an end-point (such as a Boundary
   Clock).

> seem like the verb is "following", but I think you mean it to be
GIM>> Agreed, Prepend with 'The'.

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 4 Mar 2017 16:46:44 -0800

Hi Ben,
Stefano provided more detailed information to our discussion regarding
limiting wait for the follow-up:

Profiles can have very different packet rate (between 1 and 128 packet per
seconds). In G.8275.1 (telecom profile with full timing support) the packet
rate is 16 packets per seconds.

But for applications were timing support is not guaranteed, the packet rate
might be higher (e.g. 64 or 128 packet per seconds). 8275.2 is a better
reference for this case.

One problem is that existing profiles have not defined time out ; extract
from 8275.2:

*“PTSF-lossSync, lack of reception of PTP timing messages from a master
(loss of the packet timing signal): if the slave no longer receives the
timing messages sent by a master (i.e., Sync and subsequently Follow_up and
Delay_Resp messages), then a PTSF-lossSync associated to this master must
occur. A timeout period for reception of Sync messages or Delay_Resp
messages (these are analogous to "syncReceiptTimeout" and
"delayRespReceiptTimeout" in [ITU-T G.8265.1]) for these timing messages
must be implemented in the slave before triggering the PTSF-lossSync (the
range and default value of this timeout parameter are for further study).”*

As an example, a time out of 5 Sync messages in case of 64 packets per
seconds would mean 78 ms.

  I can add a sentence with reference to PTP profiles and G8275.2. Please
advise.

Regards,
Greg

On Thu, Mar 2, 2017 at 9:21 AM, Greg Mirsky <[email-masked]> wrote:

> GIM>> This is in reference to the node behavior in context of the same
> LSP. On the given LSP the RTM-capable node MUST NOT perform in one-step and
> two-step mode.
>
>>
>> Editorial:

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 7 Mar 2017 09:38:56 -0800

Hi Ben, et.al,
we've published the new version of the draft. It includes changes to
address your comments and many others. Hope I haven't missed any.

Regards,
Greg