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

Greg Mirsky <gregimirsky@gmail.com> Sun, 05 March 2017 00:46 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 9A4631295F2; Sat, 4 Mar 2017 16:46:47 -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 2Z9iIpOhap4j; Sat, 4 Mar 2017 16:46:45 -0800 (PST)
Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (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 98D221295F0; Sat, 4 Mar 2017 16:46:45 -0800 (PST)
Received: by mail-ot0-x233.google.com with SMTP id x37so49735375ota.2; Sat, 04 Mar 2017 16:46:45 -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=zxFwoFkhAwQVY6WfI2++c7DlJZFdVpiyBCeeGpcN4hU=; b=QbXkC0uSL7wCKFyVJ7dV80pBvu0aefOE7ZfScSLK4tBMlTKati9WXsefXT+QtAIL2d VMYKl5sm1rZZ2IL32BCO40+Ko72T9FGFdD7yEBqVsmMVPUCUcF6JMkvHFpjxeSY4eDnU tucCf26WC7ebrbK44p3JBG2R15RG51foo4b1iwbvE6Jj4w+AlR1pRe3HiFfGtcN/ZiIJ BISxFpnz4AephRvAytWvhC9RMcQUs/kTQA5Ak6TDZITVNZE7adXke839nVlUEk3AQWN9 oDXI0ucdT8It3AU8RIG9zsvbyTz98cuiEuXGyF5eveDh3EzNmGFl8ly1ddLVmX3LQDVD paxQ==
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=zxFwoFkhAwQVY6WfI2++c7DlJZFdVpiyBCeeGpcN4hU=; b=BQGWjkuvfpa5pjH53cxhVbO7WOoYjhFIxG+7TwRtJJrO0lUyBlkwFxEMOj1k21H/Ad M0w8Zejv/6kAFwhZ5T1fh8W0RAxxBuE+lUc2vGjVNdFJtJVZDanpmMnU17lpgM82xbmp OIVFaSLpFUI0bu1JwZVhWVp/5w4bZRsqXVgml7eSjJTbYoAz8IBI8mTYueef4IJr69tk qpgTTd8wtjt/zuUBGAfHkvBPLHlliF6+MbxWZNDbM9pmLONMfxOtEzxBd1M06aTSXEIr 6BVt4XsWprAI1fImNhWPsR5/VBXztt3tEJRgn5y7FfYFMoS0kUvuWiJzMzG9qJopVDKK +dHw==
X-Gm-Message-State: AMke39nuIhfwa+RLK6r6FjL7kGeoC6CqUHZ1cdbBXUTPuNyPuURzMH5bEaePCmRokJeH8BfUaLEspByHeIpZ+w==
X-Received: by 10.157.73.140 with SMTP id g12mr4583382otf.35.1488674804807; Sat, 04 Mar 2017 16:46:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.21.21 with HTTP; Sat, 4 Mar 2017 16:46:44 -0800 (PST)
In-Reply-To: <CA+RyBmXhbEmN7nQQaPmBCdu3mT4ZsK0=BUwUg4Rvpy4RkM3ToA@mail.gmail.com>
References: <148841019992.7040.2698428179443970594.idtracker@ietfa.amsl.com> <CA+RyBmXhbEmN7nQQaPmBCdu3mT4ZsK0=BUwUg4Rvpy4RkM3ToA@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sat, 4 Mar 2017 16:46:44 -0800
Message-ID: <CA+RyBmUQDrrZJMAMMd1KXhFCfm41J64FJ70ESBkkihDG-9QQOQ@mail.gmail.com>
To: Ben Campbell <ben@nostrum.com>
Content-Type: multipart/alternative; boundary=f40304379b20ed3ee20549f11c3a
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/Ez_oB31tT8PmINBUOb8JckbGOsM>
Cc: mpls-chairs@ietf.org, draft-ietf-mpls-residence-time@ietf.org, "mpls@ietf.org" <mpls@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [mpls] Ben Campbell's 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: Sun, 05 Mar 2017 00:46:47 -0000

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 <gregimirsky@gmail.com>; 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 <ben@nostrum.com>; 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.
>>
>>
>>
>