[ippm] Intdir telechat review of draft-ietf-ippm-ioam-flags-09

Pascal Thubert via Datatracker <noreply@ietf.org> Tue, 28 June 2022 14:48 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ippm@ietf.org
Delivered-To: ippm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1506C15CF4C; Tue, 28 Jun 2022 07:48:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Pascal Thubert via Datatracker <noreply@ietf.org>
To: int-dir@ietf.org
Cc: draft-ietf-ippm-ioam-flags.all@ietf.org, ippm@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.5.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165642768985.47824.18006923379049872252@ietfa.amsl.com>
Reply-To: Pascal Thubert <pthubert@cisco.com>
Date: Tue, 28 Jun 2022 07:48:09 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/-X7btY1h4k8iCD-eFFhf3yJH_XI>
Subject: [ippm] Intdir telechat review of draft-ietf-ippm-ioam-flags-09
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jun 2022 14:48:09 -0000

Reviewer: Pascal Thubert
Review result: Ready with Nits

I am an assigned INT directorate reviewer for <draft-foo.txt>. These comments
were written primarily for the benefit of the Internet Area Directors. Document
editors and shepherd(s) should treat these comments just like they would treat
comments from any other IETF contributors and resolve them along with any other
Last Call comments that have been received. For more details on the INT
Directorate, see https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

1.  Introduction

   IOAM [RFC9197] is used for monitoring traffic in the network by
   incorporating IOAM data fields into in-flight data packets.

Should we read that the data is manipulated in-flight? Then it's not just
incorporated...

                       If an encapsulating node receives a looped
   back packet that was not originated from the current encapsulating
   node, the packet is dropped.
Should we read "originated from self"?

   or sets the loopack
typo

            The copy is also truncated, i.e., any payload that
   resides after the IOAM option(s) is removed before transmitting the
   looped back packet back towards the encapsulating node.

IUs there enough info to correlate with the copied packet in case the
encapsulator keeps stats, e.g. packet size? Could the loopbakc copy carry
packets stats (again like size or time)

   The looped back data rate SHOULD NOT exceed 1/N of the interface
   capacity on any of the IOAM node's interfaces.  Using N>100 is
   RECOMMENDED.  Depending on the IOAM node's architecture
This is not really the same N as before. Why is it the same value?
I see that it makes sense to throttle at the encapsulation, but here this
should not be done beyond a self protection maesure wihc should not be
triggering in normal conditions. Because loosing loop back copies may cause the
encapsulator to think there is a problem when there is none.

   It is not intended as a replacement for existing
   active OAM protocols, which may run in higher layers and make use of
   the Active flag.
Sorry could you reformulate? Higher levels could not use that flag, that would
be a layer violation.