[Tsv-art] Tsvart last call review of draft-ietf-detnet-mpls-05

Michael Tüxen via Datatracker <noreply@ietf.org> Sun, 15 March 2020 22:14 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 997213A1D38; Sun, 15 Mar 2020 15:14:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Michael_T=C3=BCxen_via_Datatracker?= <noreply@ietf.org>
To: <tsv-art@ietf.org>
Cc: last-call@ietf.org, detnet@ietf.org, draft-ietf-detnet-mpls.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.121.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158431049935.18052.15833035673726505804@ietfa.amsl.com>
Reply-To: =?utf-8?q?Michael_T=C3=BCxen?= <tuexen@fh-muenster.de>
Date: Sun, 15 Mar 2020 15:14:59 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/FHZtlZARVMb3hMxmQAbDe3EfoNU>
Subject: [Tsv-art] Tsvart last call review of draft-ietf-detnet-mpls-05
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: Sun, 15 Mar 2020 22:15:00 -0000

Reviewer: Michael Tüxen
Review result: Ready with Issues

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.

The document is in general pretty generic, so I don't know if the following
was discussed on the mailing list and is described in other documents, but
I think it should be described here or at least pointers to the specification
describing it should be inserted.

The problems I see are related to the Sequence Number you introduce in
Figure 5. If, used it is a 16-bit or 28 bit number. From the example you
provide, it seems that it is used like a Serial Number as described in
RFC 1982. The receiver uses this number for the PEF and POF. If this is
correct, this puts a limitation regarding the number of outstanding
packets on the sender. I don't see this limit being mentioned and I don't
see how this limit is enforced, since there does not seem to be an
The document states that an implementation MAY limit the maximum
number of sequence numbers being tracked. What happens if the
receiver runs out of this limit? How does a receiver protect itself against
a sender playing games with the sequence number? Limiting the resources
is only a MAY, so how is this done in the general case?