Re: Review of draft-ietf-mpls-residence-time-12

Greg Mirsky <gregimirsky@gmail.com> Wed, 18 January 2017 19:25 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A94312957A; Wed, 18 Jan 2017 11:25:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-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 xsn5bJVdLqyJ; Wed, 18 Jan 2017 11:25:08 -0800 (PST)
Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (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 11EF012955B; Wed, 18 Jan 2017 11:25:08 -0800 (PST)
Received: by mail-ot0-x22f.google.com with SMTP id 65so15954903otq.2; Wed, 18 Jan 2017 11:25:08 -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=hD6PxcLdVroH7IlCqbSsn1cDagXy3v7cANK+NF791ZE=; b=MRRabecI/aF1dasCCyaF9Hq0wi+SbVsEq3Ev0qBtvytKBqgqsVchphJImT3tBiXptU hIhpoj1z5UcPnL6Ug6D9TSHhYUEGxZC+kRSYhti2xDoSo3qh5aHQ79B8t4KYmxvWb6Rq ynyWvtTmG4svDYyVegGhRk/ZoZ762tSvzt9K04BqVwq8HZZRmJ3Zec98ckDCDpnNOGE3 IvL7i54y7o3PvifDm5IeiiQ4AJmJTSp00f0SBMU8Kk0U3lfhPadz8Y6pC+p9MW7Yl8+H aI5a7ZNJp7IOzWmeS5C7z4aSCG6Ia8djnGETbP+2M9nZ3dr0rZBzxVXKdAlJqd/cwvAO uP6Q==
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=hD6PxcLdVroH7IlCqbSsn1cDagXy3v7cANK+NF791ZE=; b=qB4WgaH02Awah8PYqZvq7zb/WXrXORajfCxRe3sfv01bz1N6US4Pc8aLJ9ojuo4Hrs v4Z7OFnfzQBB64Hp9GldQIzPTnVGVUP274BZhWNfGgrXb1xylyTrkRLE2Vg5lLKBYZDn vOB28qNxLXR+/ijgqLNfRZ4AZ0vGaVzZHtWv7gaDpn0fmfyD0Qo+ZCc1kHRsw7tbnBaI D3KUnPmhG3kH6wdUs66HuJi4ODqw0LdeY63MOK2WUC6G5Leq1F+V16cYlWQb+pjRwI6l n9W9BSCwau2WhLod9SeT1s4bs5pwCfej7wZ/vNjK/shda7+0M797435/SWosod0ec9XH ZzTA==
X-Gm-Message-State: AIkVDXJ2Zse4n4e9e9drN88v5nuUe/aUGzrsDCLPNgEetghR5ZVDj88dlaMfQpZewYqMpzXG4uIIFmRUkgJh+A==
X-Received: by 10.157.9.214 with SMTP id 22mr2318427otz.128.1484767507433; Wed, 18 Jan 2017 11:25:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.1.103 with HTTP; Wed, 18 Jan 2017 11:25:07 -0800 (PST)
In-Reply-To: <95d41b52-5c85-869f-2139-6713816e9637@nostrum.com>
References: <148414970343.8167.4538946698521330202.idtracker@ietfa.amsl.com> <CA+RyBmU9W5QP4EjbPezoCpdLHv1RJCrzJvxQmeTnAvjO_6vbJA@mail.gmail.com> <CA+RyBmVrvyiwDp2kV3VLiQtqOaL=MaVjZugGbvgWnp6y3dwP3Q@mail.gmail.com> <95d41b52-5c85-869f-2139-6713816e9637@nostrum.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 18 Jan 2017 11:25:07 -0800
Message-ID: <CA+RyBmWcvU70BZYRj8ZHUZrmkcwq1eHS38jFpyZOq3A_5eXZ9g@mail.gmail.com>
Subject: Re: Review of draft-ietf-mpls-residence-time-12
To: Robert Sparks <rjsparks@nostrum.com>
Content-Type: multipart/alternative; boundary=001a11c1591cdacfbe0546635f6b
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/vCmB2bf1hhvoFOWOtbMLSVoADQM>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, draft-ietf-mpls-residence-time.all@ietf.org, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jan 2017 19:25:10 -0000

Hi Robert,
thank you for the most expedient review and comments. I'll make changes in
Section 2 per your suggestion.

Regards,
Greg

On Wed, Jan 18, 2017 at 10:34 AM, Robert Sparks <rjsparks@nostrum.com>
wrote:

> The changes all look good.
>
> I still think you should say something in the document about what "the
> time of packet arrival" and "transmission" means, and call out the point
> you made about being careful to not introduce apparent jitter by not making
> those measurements consistently. (The definitions you point to in your
> earlier mail from G.8013 don't really help - they just say "time of packet
> arrival". Again, the first and last bit are likely to be several
> nanoseconds apart so I think it matters. Perhaps you're saying it doesn't
> matter as long as each node is consistent (there will be error in the
> residence time measurement, but it will be constant at each node, so the
> sum of errors will be constant, and the clocks will be ok?)
>
> Please look at the new first paragraph of section 2 - there's a mix of "as
> case" and "in case" that should be made consistent. I suspect it would be
> easiest to simply say "referred to as using a one-step clock" and "referred
> to as using a two-step clock" or similar.
>
> RjS
>
> On 1/18/17 12:03 PM, Greg Mirsky wrote:
>
> Hi Robert,
> Sasha Vainshtein came with elegant idea to address disconnection between
> discussion of one-step and two-step modes that you've pointed out. We've
> moved Section 7 as sub-section into Section 2 now. Attached are updated
> diff and the proposed new version -13.
>
> Regards,
> Greg
>
> On Wed, Jan 18, 2017 at 8:13 AM, Greg Mirsky <gregimirsky@gmail.com>
> wrote:
>
>> Hi Robert,
>> once again, thank you for your thorough review and the most detailed
>> comments. I've prepared updated version and would greatly appreciate if you
>> review the changes and let us know whether your comments been addressed.
>> Attached are diff and the new version.
>>
>> Regards,
>> Greg
>>
>> On Wed, Jan 11, 2017 at 7:48 AM, Robert Sparks <rjsparks@nostrum.com>
>> wrote:
>>
>>> Reviewer: Robert Sparks
>>> Review result: Ready with Nits
>>>
>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>> Review Team (Gen-ART) reviews all IETF documents being processed
>>> by the IESG for the IETF Chair.  Please treat these comments just
>>> like any other last call comments.
>>>
>>> For more information, please see the FAQ at
>>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>>
>>> Document: draft-ietf-mpls-residence-time-12
>>> Reviewer: Robert Sparks
>>> Review Date: 2017-01-10
>>> IETF LC End Date: 2017-01-17
>>> IESG Telechat date: 2017-02-02
>>>
>>> Summary: Ready (with nits) for publication as a Proposed Standard
>>>
>>> I have two primary comments. I expect both are rooted in the authors
>>> and working group knowing what the document means instead of seeing
>>> what
>>> it says or doesn't say:
>>>
>>> 1) The document is loose with its use of 'packet', and where TTLs
>>> appear when
>>> they are discussed. It might be helpful to rephrase the text that
>>> speaks
>>> of RTM packets in terms of RTM messages that are encoded as G-ACh
>>> messages and
>>> not refer to packets unless you mean the whole encapsulated packet
>>> with MPLS
>>> header, ACH, and G-ACh message.
>>>
>>> 2) Since this new mechanic speaks in terms of fractional nanoseconds,
>>> some
>>> discussion of what trigger-point you intend people to use for taking
>>> the
>>> precise time of a packet's arrival or departure seems warranted. (The
>>> first and
>>> last bit of the whole encapsulated packet above are going to appear at
>>> the
>>> physical layer many nanoseconds apart at OC192 speeds if I've done the
>>> math
>>> right). It may be obvious to the folks discussing this, but it's not
>>> obvious
>>> from the document.  If it's _not_ obvious and variation in technique
>>> is
>>> expected, then some discussion about issues that might arise from
>>> different
>>> implementation choices would be welcome.
>>>
>>> The rest of these are editorial nits:
>>>
>>> It would help to pull an overview description of the difference
>>> between
>>> one-step and two-step much earlier in the document. I suggest in the
>>> overview
>>> in section 2. Otherwise, the reader really has to jump forward and
>>> read section
>>> 7 before section 3's 5th bullet makes any sense.
>>>
>>> In section 3, "IANA will be asked" should be made active. Say "This
>>> document
>>> asks IANA to" and point to the IANA consideration section. Apply
>>> similar
>>> treatment to the other places where you talk about future IANA
>>> actions.
>>>
>>> There are several places where there are missing words (typically
>>> articles or
>>> prepositions). You're less likely to end up with misinterpretations
>>> during the
>>> RFC Editor phase if you provide them before the document gets that far
>>> in the
>>> process. The spots I found most disruptive were these (this is not
>>> intended to
>>> be exhaustive):
>>>
>>>   Section 3: "set 1 according" -> "set to 1 according"
>>>   Section 3: "the Table 19 [IEEE..." -> "Table 19 of [IEEE..."
>>>   Section 4.2: "Detailed discussion of ... modes in Section 7."
>>>                         -> "Detailed discussion of ... modes appears
>>> in Section 7."
>>>   Section 10: "most of" -> "most of all"
>>>
>>> In Setion 3.1 at "identity of the source port", please point into the
>>> document
>>> that defines this identity and its representation. I suspect this is a
>>> pointer
>>> into a specific section in IEEE.1588.2008].
>>>
>>>
>>>
>>>
>>
>
>