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

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 5 Apr 2019 16:35:08 +0200

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
>>
>