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

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> wrote:

> Hi Ben,
> thank you for your thorough review and comments. Please find my answers
> in-line tagged GIM>>.
>
> Regards,
> Greg
>
> On Wed, Mar 1, 2017 at 3:16 PM, Ben Campbell <[e-mail]> wrote:
>
>> 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?\
>>
> 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.
>
>>
>> -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?
>>
> 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:
>> - Abstract: The last paragraph is a single, long sentence. Please
>> 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.
>
>
>> - 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..."
>>
> 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).
>
>
>
>>
>> -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".
>>
> GIM>> Agreed, Prepend with 'The'.
>
>> -- I have trouble matching some pronouns to their antecedents in the rest
>> of the paragraph.
>>
>>
>>
>