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

"Carles Gomez Montenegro" <carlesgo@entel.upc.edu> Fri, 05 April 2019 14:35 UTC

Return-Path: <carlesgo@entel.upc.edu>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4911F120250; Fri, 5 Apr 2019 07:35:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaAfHNZFsqG4; Fri, 5 Apr 2019 07:35:15 -0700 (PDT)
Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 F15681200EF; Fri, 5 Apr 2019 07:35:14 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x35EZ8O8021010; Fri, 5 Apr 2019 16:35:08 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 30E5C1D53C1; Fri, 5 Apr 2019 16:35:07 +0200 (CEST)
Received: from 131.111.5.141 by webmail.entel.upc.edu with HTTP; Fri, 5 Apr 2019 16:35:08 +0200
Message-ID: <227c462c8ece488e8aebbe2b9236e110.squirrel@webmail.entel.upc.edu>
In-Reply-To: <f4b5a213-51ba-670a-7eee-91e2dd2d357b@earthlink.net>
References: <1546871074.3699932.1627604240.346EB1B6@webmail.messagingengine.com> <f4b5a213-51ba-670a-7eee-91e2dd2d357b@earthlink.net>
Date: Fri, 05 Apr 2019 16:35:08 +0200
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: Dan Frost <frost@mm.st>
Cc: rtg-ads@ietf.org, draft-ietf-6lo-deadline-time.all@ietf.org, rtg-dir@ietf.org, Charlie Perkins <charles.perkins@earthlink.net>
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 (violet.upc.es [147.83.2.51]); Fri, 05 Apr 2019 16:35:08 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/osH-b8dqtoHTfHE_6zK3Dga8TxY>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-6lo-deadline-time-03
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=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:
https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/

Do you think -04 satisfies your previous concerns?

Thanks,

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
>> ​https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>>
>> 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
>>
>