[Tsv-art] Tsvart last call review of draft-ietf-detnet-flow-information-model-11

Olivier Bonaventure via Datatracker <noreply@ietf.org> Fri, 06 November 2020 20:56 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tsv-art@ietf.org
Delivered-To: tsv-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9583A0D20; Fri, 6 Nov 2020 12:56:26 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Olivier Bonaventure via Datatracker <noreply@ietf.org>
To: <tsv-art@ietf.org>
Cc: detnet@ietf.org, draft-ietf-detnet-flow-information-model.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160469618665.20223.2730384752002027021@ietfa.amsl.com>
Reply-To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Date: Fri, 06 Nov 2020 12:56:26 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/wP2r--YwwSVt_gmj4xD7w90NT8w>
Subject: [Tsv-art] Tsvart last call review of draft-ietf-detnet-flow-information-model-11
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Nov 2020 20:56:27 -0000

Reviewer: Olivier Bonaventure
Review result: Almost Ready

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

This review was requested in a very short period of time and I could not read
all the Detnet related materials. I focus on issues that could be relevant for
the transport area.

The introduction indicates that the Detnet architecture supports IP and MPLS
flows, but section 5.4.2 indicates that and IP flow can be specified using the
following attributes :

  a.  SourceIpAddress
   b.  DestinationIpAddress
   c.  IPv6FlowLabel
   d.  Dscp (attribute)
   e.  Protocol
   f.  SourcePort
   g.  DestinationPort
   h.  IPSecSpi

I would personally qualify the flows that include transport layer information
as layer-4 and not IP flows. Maybe a note in the introduction should be
mentioned. In the document, it is unclear to me whether some of these
attributes are optional or can be specified as wild cards. Maybe this is
described in another document.

The information model defines various attributes. Some of the definitions are
very precise and mention the measurement unit. For others, this is less clear.
For example, intervals are defined in units of nanoseconds, but payloadsize is
not defined as a number of bytes.

Some information elements appear unclear to an external observer like me:

5.9.4.  Maximum Loss of the DetNet Flow

   MaxLoss defines the maximum Packet Loss Ratio (PLR) requirement for
   the DetNet flow between the Ingress and Egress(es).

There is no measurement interval define for the packet loss ratio.

5.9.6.  Maximum Misordering Tolerance of the DetNet Flow

The definition is unclear and does not make it easy to measure this value

6.3.1.  Minimum Bandwidth of the DetNet Service

>From the definition, it is unclear to me whether the payload only is used to
compute the bandwidth or whether this includes the headers and if so which

I was surprised by the following paragraph

6.4.  Connectivity Type of the DetNet Service

   Two connectivity types are distinguished: point-to-point (p2p) and
   point-to-multipoint (p2mp).  Connectivity type p2mp is created by a
   transport layer function (e.g., p2mp LSP).  (Note: mp2mp connectivity
   is a superposition of p2mp connections.)

Does the note precludes the utilisation of multicast to support the detnet
service ? If so, I don't think that this restriction should be part of an
information model. It should be specified in an architecture document.

6.6.  Rank of the DetNet Service

   The DnServiceRank attribute provides the rank of a service instance
   relative to other services in the DetNet domain.  DnServiceRank
   (range: 0-255) is used by the network in case of network resource
   limitation scenarios.

>From this description I do not know whether a high value rank gets more
resource than a low value one. I would suggest to clarify this in the
definition of the rank.