[Detnet] Opsdir last call review of draft-ietf-detnet-mpls-over-ip-preof-08

Carlos Pignataro via Datatracker <noreply@ietf.org> Sat, 23 December 2023 18:21 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 DDE37C14F5F0; Sat, 23 Dec 2023 10:21:28 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Carlos Pignataro via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: detnet@ietf.org, draft-ietf-detnet-mpls-over-ip-preof.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <170335568889.53995.7881932492353324497@ietfa.amsl.com>
Reply-To: Carlos Pignataro <cpignata@gmail.com>
Date: Sat, 23 Dec 2023 10:21:28 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/TiFfTQNne2RMHVOFLIu7-78KDgA>
Subject: [Detnet] Opsdir last call review of draft-ietf-detnet-mpls-over-ip-preof-08
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 23 Dec 2023 18:21:29 -0000

Reviewer: Carlos Pignataro
Review result: Has Issues

Hi!

Review of       draft-ietf-detnet-mpls-over-ip-preof
Type    Last Call Review
Team    Ops Directorate (opsdir)
Reviewer:       Carlos Pignataro

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This document is comprehensive and achieves exactly what it is set to in the
short and intentional Abstract.

>From an OpsDir perspective, I found a areas potentially lacking in coverage:

1. OAM -- there's a single short mention of OAM as a footnote of Section 5.
However, that lacks specificity and appropriate references.

I would suggest turning that note into a small sub-section that, at least,
provides Normative citation to the referenced "MPLS-based DetNet OAM
techniques".

2. "4.4.  Flow Aggregation", "In the first case, the different DetNet PWs [...]"

Is this case using Figure 3 encapsulation? if so, could this be mentioned or
referenced?

3. DetNet document roadmap. Is this document an update to RFC9025? Is the
sequencing the Normative piece? How these two relate and what's missing from
RFC9025 could be more clearly articulated. Basically, RFC 8964, RFC 9025, this
document. How they really relate?

4. The use in S5 of the IPv6 Flow Label could also use some processing
specificity.

5. From an Ops perspective, are there additional MPLS-based DetNet counters
that would help in data-plane troubleshooting and debugging?

6. Finally, please find a couple of nits for consideration:

   The DetNet MPLS data plane [RFC8964] specifies how sequencing
   information is encoded in the MPLS header.  However, the DetNet IP
   data plane described in [RFC8939] does not specify how sequencing
   information can be encoded in the IP header.  This documents provides
   sequencing information to DetNet IP nodes by re-using the DetNet MPLS
   over UDP/IP data plane [RFC9025] with the restriction of using zero
   F-labels.

"This documents" -> "This document"

   For the second option, an additional hierarchy is created thanks to
   an additional Service-ID and d-CW tuple added to the encapsulation.
   The Aggregate-ID is a special case of a Service-ID, whose properties
   are known only at the aggregation and de-aggregation end points.  It
   is a property of the Aggregate-ID that it is followed by a d-CW
   followed by an Service-ID/d-CW tuple.  Figure 4 shows the

"an Service-ID" -> "a Service-ID"

Thanks, and very best,

Carlos Pignataro.