[Detnet] Alvaro Retana's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)

Alvaro Retana <aretana.ietf@gmail.com> Wed, 20 February 2019 15:56 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: detnet@ietf.org
Delivered-To: detnet@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA8F127AC2; Wed, 20 Feb 2019 07:56:47 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana <aretana.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-detnet-architecture@ietf.org, Lou Berger <lberger@labn.net>, detnet-chairs@ietf.org, detnet@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155067820715.31361.3746519237969586434.idtracker@ietfa.amsl.com>
Date: Wed, 20 Feb 2019 07:56:47 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/wgX0NyHDYZDPrc-Wl64QbzVH02M>
Subject: [Detnet] Alvaro Retana's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Feb 2019 15:56:47 -0000

Alvaro Retana has entered the following ballot position for
draft-ietf-detnet-architecture-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I support Mirja's and Alissa's DISCUSSes...and have a related set of concerns
about the coexistence with non-DetNet traffic and privacy:

§3.3.1 talks about what I think is a hard to achieve balance between coexisting
with non-DetNet traffic and keeping that traffic from disrupting DetNet flows. 
Because of the constraints, the intent of prioritizing DetNet flows is clear
(and that is ok), but that may result in starvation of non-DetNet
traffic...even if the text does explicitly say that it "must be avoided".

I would like to see the potential case of starving non-DetNet traffic called
out somewhere.  I'm looking for something similar to the first paragraph in §5,
but focused on the non-DetNet traffic.

Related to the above is the fact that the identification of flows could be used
to specifically *not* include some of them as DetNet flows.  This is a
variation of the concern outlined in §6, but applied to non-DetNet flows, with
the potential starvation mentioned above.  Again, I would like to at least see
some discussion of this risk.

The use case and problem statement documents outline specific applications that
may not have non-DetNet traffic, and the Introduction supports that.  However,
the architecture described in this document may be used in more general
networks to provide guarantees to specific traffic...  IOW, even if the
intention is there, there is no guarantee that DetNet will only be used in the
expected use cases.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with and support Benjamin's DISCUSS -- also, I think that
draft-ietf-detnet-security should be a Normative reference.

I also agree that Informational may be a better status.

[nit] s/sub-layer at which A DetNet service/sub-layer at which a DetNet service
[nit] Expand SRLG.