Re: [RTG-DIR] RtgDir review: draft-ietf-6lo-deadline-time-03

"Carles Gomez Montenegro" <> Fri, 05 April 2019 14:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4911F120250; Fri, 5 Apr 2019 07:35:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VaAfHNZFsqG4; Fri, 5 Apr 2019 07:35:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F15681200EF; Fri, 5 Apr 2019 07:35:14 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x35EZ8O8021010; Fri, 5 Apr 2019 16:35:08 +0200
Received: from ( []) by (Postfix) with ESMTP id 30E5C1D53C1; Fri, 5 Apr 2019 16:35:07 +0200 (CEST)
Received: from by with HTTP; Fri, 5 Apr 2019 16:35:08 +0200
Message-ID: <>
In-Reply-To: <>
References: <> <>
Date: Fri, 05 Apr 2019 16:35:08 +0200
From: Carles Gomez Montenegro <>
To: Dan Frost <>
Cc:,,, Charlie Perkins <>
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.2 at violet
X-Virus-Status: Clean
X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 ( []); Fri, 05 Apr 2019 16:35:08 +0200 (CEST)
Archived-At: <>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-6lo-deadline-time-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Apr 2019 14:35:18 -0000

Dear Dan,

Thanks for reviewing draft-ietf-6lo-deadline-time-03.

Authors of draft-ietf-6lo-deadline-time recently produced revision -04 of
the draft, based on a number of comments received, including yours:

Do you think -04 satisfies your previous concerns?


Shwetha and Carles (6lo co-chairs)

> Hello Dan,
> We could go with the formats shown in
> draft-ietf-ntp-packet-timestamps-05.txt, or a format derived from them
> by scaling down to fewer bits.  Do we need to support both NTP and PTP
> versions?  I think we should also continue to support ASN as a time unit.
> There has been discussion about whether or not the 'D' bit is needed,
> and so far the balance of the discussion seems to indicate that it is
> O.K. to keep it.  However, that could still change.
> Thanks much for your review!
> We will soon have a specific proposal for a new Deadline Time and
> Origination Time (DT and OT) format based on discussion about the above
> points.  It will somehow be derived from the formats shown in the NTP
> draft document.
> Regards,
> Charlie P.
> On 1/7/2019 6:24 AM, Dan Frost wrote:
>> Hello,
>> I have been selected as the Routing Directorate reviewer for this draft.
>> The Routing Directorate seeks to review all routing or routing-related
>> drafts as they pass through IETF last call and IESG review, and
>> sometimes on special request. The purpose of the review is to provide
>> assistance to the Routing ADs. For more information about the Routing
>> Directorate, please see
>> ​
>> Although these comments are primarily for the use of the Routing ADs, it
>> would be helpful if you could consider them along with any other IETF
>> Last Call comments that you receive, and strive to resolve them through
>> discussion or by updating the draft.
>> Document: draft-ietf-6lo-deadline-time-03
>> Reviewer: Dan Frost
>> Review Date: 2019-01-07
>> Intended Status: Standards Track
>> Summary:
>> I have some minor concerns about this document that I think should be
>> resolved before publication.
>> Comments:
>> This draft specifies a mechanism for including packet delivery deadline
>> times, in the form of an elective 6LoWPAN routing header, for use in
>> low-power and lossy networks with real-time requirements for end-to-end
>> delay. Routers can use packet deadline times to make informed scheduling
>> decisions or discard overdue packets. The timing metadata can also be
>> useful for performance monitoring and diagnostics.
>> The draft is, for the most part, clear, and the writing quality is good.
>> Major Issues:
>> No major issues found.
>> Minor Issues:
>> The main issue I see with the spec is the way timestamp formats are
>> specified with the TU (time units) field. The possible values for this
>> field include "seconds" and "microseconds". This is unusual,
>> particularly in combination with the EXP field, which leads to some time
>> values having multiple representations. And when representing absolute
>> timestamps, we'd usually use well-known formats like NTP or IEEE 1588.
>> The draft probably needs to rework the timestamp representation options
>> along these lines, including specifying a single default format for
>> interoperability (we did this in RFC 6374, for example). An important
>> consideration here is the typical capabilities of the kinds of devices
>> expected to implement this spec; many devices only have good support for
>> one standard timestamp format. Industrial devices, a specfiic target of
>> this spec, usually expect IEEE 1588.
>> Making the Origination Time non-optional and specifying the Deadline
>> Time as a delta could also be considered.
>> Is the D flag (must drop if deadline exceeded) really necessary? Should
>> the semantics not just be to drop the overdue packet if there's
>> congestion, and forward it otherwise?
>> Nits:
>> Section 4: s/Whenever the packets crosses into a network/Whenever a
>> packet crosses into a network/
>> Cheers,
>> -d