[Gen-art] Genart last call review of draft-ietf-detnet-architecture-08

Joel Halpern <jmh@joelhalpern.com> Sat, 22 September 2018 00:59 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B56F2130EB2; Fri, 21 Sep 2018 17:59:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joel Halpern <jmh@joelhalpern.com>
To: <gen-art@ietf.org>
Cc: draft-ietf-detnet-architecture.all@ietf.org, detnet@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153757799868.20291.14005182713582795355@ietfa.amsl.com>
Date: Fri, 21 Sep 2018 17:59:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/5Nsli-3yVEVIsQIZjSE-H7wZrQI>
Subject: [Gen-art] Genart last call review of draft-ietf-detnet-architecture-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Sep 2018 00:59:59 -0000

Reviewer: Joel Halpern
Review result: Ready with Issues

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-detnet-architecture-08
Reviewer: Joel Halpern
Review Date: 2018-09-20
IETF LC End Date: 2018-10-03
IESG Telechat date: Not scheduled for a telechat

Summary: This document is ready for publication as a Proposed Standard

I presume that the status was selected so as to avoid the need for downrefs
when other Detnet documents normatively reference this one?

Major issues: N/A

Minor issues:
    Section 3.1 states that worst case delay for priority queueing is
    unbounded.  That does not match my understanding.  I know that DelayBound
    DSCP behavior tightly (although, I think, not as tightly  as Detnet) limits
    both the worst case delay and the delay variation.

    It seems very odd that section says that DetNet flows can not be
    throttled when earlier text says that DetNet flows do have a maximum
    bandwidth.  Buried in section 4.3.2 I find that what is meant by throttled
    is not "enforcing a rate limit", but rather "sending congestion
    notification to cause the source to slow down."  I think the wording about
    "can not be throttled" both in and 4.3.2 should be adjusted for
    clarity. also reads oddly in that it seems to recommend providing
    significant buffering, when the need for and use of such buffers is a major
    source of jitter.

    In section 4.1.2, I realized that the Detnet Transit node terminology had
    mildly confused me.  The text says "DetNet enabled nodes are interconnected
    via transit nodes (e.g., LSRs) which support DetNet, but are not DetNet
    service aware."  Reading this, and the definitions in section 2.1, it
    appears that a Detnet Transit node is a node that is providing transport
    behavior that detnet needs, but is not actually modified for detnet.

    Section 4.4.2 talks about per flow per node state.  It would be good to
    have a forward reference to section 4.9 about scaling to larger networks.

Nits/editorial comments:
     It would be good if there were some explanation for the 75% maximum number
     in section 3.3.1.  That there is some limit seems intuitive.  What value
     that limit has is not so obvious.

    Section 4.7.3 introduces an example using Ethernet Mulicast destiantions as
    part of labeling.  There is no earlier explanation of the use of an
    Ethernet MAC Multicast destination, and the text does not seem to require
    that the traffic be actually multicast.  Hence the reader is liable to be
    confused by the reference to multicast.  I rate this only a nit as it seems
    clear that this is an example whose details are presumably explained in
    another document.    Still, it would help to clarify the example.