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

Greg Mirsky <> Wed, 11 January 2017 18:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F2E9129762; Wed, 11 Jan 2017 10:36:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X3QC6Y8wD7IN; Wed, 11 Jan 2017 10:36:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E07F01296FD; Wed, 11 Jan 2017 10:36:19 -0800 (PST)
Received: by with SMTP id u143so188710078oif.3; Wed, 11 Jan 2017 10:36:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w02/wGbScQA5sIFVXeJylIu41woQV1ZiJKh9f06yy0Q=; b=HDlr8w6WqZcVJod6G7refRMER/613+sm1GsGGEE/8ggse1R5y5SUGtqx7Sd3XnqdVA r1xqC5rOiaKOub2cerh5jhAOD3F2i0NvF6Neu43Qk579cOLD+MItKumBVJr93P66essQ DwNNOetSt3XBXXrdZ0otjMsuLLXwqDtQbfUfRcp8TMJPffoPuR+xcf0NhHGKi76nri4f 7+RBAvbms3WbFbGXM6D952Ej2qpvzZsYACX9GxqW+/nTxug8xI8vlTsKHRRhAIE842pa 3k1FVH46IKdGrjMarnKXYVTY3uCvJFv+QaZfddUZQ2LNCiYY9N6QGhAcyoErJqj1/g73 EOGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w02/wGbScQA5sIFVXeJylIu41woQV1ZiJKh9f06yy0Q=; b=qJ6Nrtl5xQ6Hk+k9ZP7i1JQ9hreMn+YXGmgZkwg3t1PXP6AKbo7AVpISCMnHN0rdtQ UQKP9T9bne5yuAb2ku7rhaeJ4u14vEywWPJ1vAFAwZMZyLpSOGi3SDKtMZkgZwKoWt77 QUeKIKOP3qzCFk45+XG6KbBzNtgr5G57F3nwx8wxzWhqba3dI+PiuWeovzTYEM3xmA9C 4TkKxGIlATxYkTPLV83RQF6DHU0/OHUu+zz5psZfzPRQTABJE3yXy2/dB8yeCbMuF5JN QaIBPKCbFe2mkk5qnT9LfzpWXrW0TZTrduQRRk0URPb3ZLk0FvxNWiO1iEiZbHC0Eio6 a8vg==
X-Gm-Message-State: AIkVDXI0nycnUezdmW+zZ0+r06KMj37gk8ZNubLPpWpkHRopXsmOvDK2wirIyfaK87EJdvWlqr1CFCX+2R6ECg==
X-Received: by with SMTP id b133mr4629310oia.75.1484159779161; Wed, 11 Jan 2017 10:36:19 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 11 Jan 2017 10:36:18 -0800 (PST)
In-Reply-To: <>
References: <>
From: Greg Mirsky <>
Date: Wed, 11 Jan 2017 10:36:18 -0800
Message-ID: <>
Subject: Re: Review of draft-ietf-mpls-residence-time-12
To: Robert Sparks <>
Content-Type: multipart/alternative; boundary="001a113d448c6d4df90545d5e091"
Archived-At: <>
Cc: "" <>, "" <>,, "" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Jan 2017 18:36:25 -0000

Hi Robert,
thank you for your the most detailed review and helpful comments. I'll
prepare -13 version based on your suggestions.
Please find my responses, notes in-lined and tagged GIM>>


On Wed, Jan 11, 2017 at 7:48 AM, Robert Sparks <> 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
> <>.
> 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.
GIM>> Will use "message" as you've suggested. Indeed, interchangeable use
of packet and message does confuse.

> 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.
GIM>> G.8013, formerly Y.1731, does not require or define when a time stamp
must be taken. The document only indicates during which process time been
taken, e.g.:
TxTimeStampf: Timestamp at the transmission time of ETH-DM frame
 RxTimeStampf: Timestamp at the time of receiving frame with ETH-DM request
What is important for quality of measurement is for an implementation to be
reading and writing in timestamp at the same stage of processing the RTM
packet and avoiding queuing/de-queuing in order to avoid impact of jitter
caused by queuing/de-queuing.

> 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.
GIM>> Will try.

> 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.
GIM>> Will make changes accordingly.

> 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"
GIM>> Thank you, will make the changes.

> 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].
GIM>>  Will add the reference.