Re: [Detnet] WG Last Call: draft-ietf-detnet-bounded-latency-02

Greg Mirsky <> Fri, 12 February 2021 20:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 517793A0E68 for <>; Fri, 12 Feb 2021 12:58:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 tq4vDNfUDm1P for <>; Fri, 12 Feb 2021 12:58:20 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 40A523A0E59 for <>; Fri, 12 Feb 2021 12:58:20 -0800 (PST)
Received: by with SMTP id q14so651693ljp.4 for <>; Fri, 12 Feb 2021 12:58:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+b/sNA6q5oOnIBg0jpw5jdXMZi1X6rqYsxqQGlbpAKw=; b=sF1LWfbp7DUaDh+f5Ldu/9sNKyXKrz9WyPo7SZhiB6oYiRmxanMa1JRYnSdr2CLhpk 8ts6a3akTJibe7ZrQsZkdrsClSJF9eD3lEo6vGSKJ2Rv81J1Z7a9Thn07zf5AUbB2W2A mkEvCE8tKdW5qnK9cJ7KGVG3+bjLLZmpYQa/C15hO+WObFBwWh/SXnONLXYjIRtLpIAf e8xlhCJKN0nkk2CpSt+h5Fcmz/epiaA5gcDt1b9DRfOjbD63C1o90zzfyPHx9ebolIVe uye4P9V966cxptrv5cJRFx8odJfH9azx2Gkusp2QlNVct/4wPku/z1Qi/NKuU8E/7edm nElw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+b/sNA6q5oOnIBg0jpw5jdXMZi1X6rqYsxqQGlbpAKw=; b=F0DVjpF6DEh9L7pRzkXyyHgP+cv+gBwTDleIy6Ys10gIWvKxyhDg57EUADmzfYHvF7 qhiAdHzAEtrnkA1PM38GWd1YBkzI8tkVmut/JzHmaeR5K43fwk8ZnptzdCaFrrHNujnn 4TfmXpcNecMsUrQdec0CllkuKOH8Bk8QY7qs2RKSc9vXh1je/hZ9+HkszJzAVAOsyIGy NB6lIxqyC+FZb/BJKLJFdUBpabHjqVz75H3WOFXerA0DWRow8M7R2BkmqXUJOloYj67s jnMu3yY7Poq4XSpaEdNXCigWUxgCFIEZJ+QehjtRN6274uyxTL/SnqOL14vHKqbrxR1i kLsg==
X-Gm-Message-State: AOAM533MUcwfw1BPnrPRQRyhHNwxI2qOajO9v/jM0ZIsMDib+1F77lWS imKBhRZs1fLuommVhvilb4eCqWyy9nLHVpbi6eFUmGeEaY/goQ==
X-Google-Smtp-Source: ABdhPJw430jdT54aZ22yVyo64SzFUtzIOrP0W53ZpnzHjM2dTCV46P5bRBnrtMJhrZGaKM2wkFTImR8Attd8/IPEkQM=
X-Received: by 2002:a2e:9bd8:: with SMTP id w24mr2682477ljj.126.1613163498158; Fri, 12 Feb 2021 12:58:18 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Fri, 12 Feb 2021 12:58:08 -0800
Message-ID: <>
To: Lou Berger <>
Cc: DetNet WG <>
Content-Type: multipart/alternative; boundary="00000000000045bd8c05bb29e50a"
Archived-At: <>
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-bounded-latency-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Feb 2021 20:58:23 -0000

Dear All,
I've read the current version of the draft and support progressing it to
the publication as the Informational RFC.
I have several non-blocking comments and questions for the author's

   - In Abstract and Introduction "server" and "central server" referenced.
   Could it be used to identify an SDN controller or orchestrator? If that is
   the case or close, perhaps a more direct terminology can be used.
   - Perhaps s/un-provisioning/de-provisioning/?
   - It's been quite a long time since I've seen a network device being
   referenced as "bridge". If there's no difference modeling different types
   of networking devices in Section 3.2, perhaps "typically, bridges or
   routers" can be omitted.
   - And in the same sentence, a part of the reference model is described
   as "a wired link". Could that be some other media, e.g., wireless?
   - you may choose to use a single term from "DetNet unaware", "DetNet
   non-aware", and "non-DetNet"
   - the statement in the second paragraph's  first sentence appears very

   In general, when passing through a non-DetNet island, the island
   causes delay variation in excess of what would be caused by DetNet

I agree that under some conditions such a domain might cause higher delay
variation but I am not sure that is always the case.

   - Further in that paragraph, is stated that "... can still be calculated
   and met if and only if the following are true" though the second bullet
   appears as a conditional "An ingress conditioning function (Section 4.3)
   may be required ...". I am not sure it is clear when that second bullet is
   true - if the conditioning function is required or if it is not needed.


On Fri, Feb 5, 2021 at 5:30 AM Lou Berger <> wrote:

> All,
> This starts working group last call on draft-ietf-detnet-bounded-latency-02
> The working group last call ends on February 19th.
> Please send your comments to the working group mailing list.
> Please note, there was an IPR disclosure against this document
> submitted on January 14, 2021, see
> While this disclosure came very late in the document life cycle,
> it appears the filing was also relatively recent (2019-10-16) and
> after the pre adoption IP call:
> Positive comments, e.g., "I've reviewed this document
> and believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
> Thank you,
> Lou (DetNet Co-Chair & doc Shepherd)
> _______________________________________________
> detnet mailing list