[Detnet] Benjamin Kaduk's No Objection on draft-ietf-detnet-mpls-over-tsn-06: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 18 February 2021 09:08 UTC

Return-Path: <noreply@ietf.org>
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 4F1C33A0E34; Thu, 18 Feb 2021 01:08:37 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-detnet-mpls-over-tsn@ietf.org, detnet-chairs@ietf.org, detnet@ietf.org, Lou Berger <lberger@labn.net>, lberger@labn.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.25.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <161363931724.28226.4690227321627053128@ietfa.amsl.com>
Date: Thu, 18 Feb 2021 01:08:37 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/886Eod6u2RlGImmbeGtTevxaYLQ>
Subject: [Detnet] Benjamin Kaduk's No Objection on draft-ietf-detnet-mpls-over-tsn-06: (with 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: Thu, 18 Feb 2021 09:08:37 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-detnet-mpls-over-tsn-06: No Objection

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-mpls-over-tsn/



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

Roman's comment is a good one.

Section 3

   and process d-CWs, S-Labels and F-labels as needed.  MPLS DetNet
   nodes and transit nodes include DetNet forwarding sub-layer
   functions, support for notably explicit routes, and resources
   allocation to eliminate (or reduce) congestion loss and jitter.

Akin to my remarks on draft-ietf-detnet-tsn-vpn-over-mpls, I'd suggest
"notably support for explicit routes, and resource allocation to
eliminate (or reduce) congestion loss and jitter".

Section 4.2

   A TSN-aware MPLS (DetNet) node implementation must support the
   Sequencing function and the Sequence encode/decode function as
   defined in Clause 7.4 and 7.6 of IEEE 802.1CB [IEEE8021CB] if FRER is
   used inside the TSN sub-network.
   [...]
   A TSN-aware MPLS (DetNet) node implementation must support the Stream
   splitting function and the Individual recovery function as defined in
   Clause 7.7 and 7.5 of IEEE 802.1CB [IEEE8021CB] when the node is a
   replication or elimination point for FRER.

(nit) I suggest phrasing these as "in order for FRIR to be used inside
the TSN sub-network" and "in order for that node to be a replication or
elimination point for FRER".  The current phrasing implies some
surprising causality, as if changing the network's configuration
spontaneously imposes a requirement on the node.

Section 4.4

   Implementations of this document shall use management and control
   information to map a DetNet flow to a TSN Stream.  N:1 mapping
   (aggregating DetNet flows in a single TSN Stream) shall be supported.

I note that in draft-ietf-detnet-tsn-vpn-over-mpls this was a normative
"SHALL be supported" (which was itself the strongest criterion I could
find for that document being standards-track).  Is there a simple
description for what's different between these documents?

Section 5

   requirements.  Note that, as the TSN sub-network is just a portion of
   the end2end DetNet path (i.e., single hop from MPLS perspective),

nit: please write out "end-to-end".

   In some case it may be challenging to determine some TSN Stream
   related information.  [...]

nit: "In some cases".