[ippm] Opsdir last call review of draft-ietf-ippm-ioam-direct-export-08

Linda Dunbar via Datatracker <noreply@ietf.org> Tue, 14 June 2022 03:12 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 A8211C15AE30; Mon, 13 Jun 2022 20:12:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Linda Dunbar via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: draft-ietf-ippm-ioam-direct-export.all@ietf.org, ippm@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165517633368.30100.5384506751806885611@ietfa.amsl.com>
Reply-To: Linda Dunbar <linda.dunbar@futurewei.com>
Date: Mon, 13 Jun 2022 20:12:13 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/fMyv20aE1bHAM2w46LV9qX4N4lc>
Subject: [ippm] Opsdir last call review of draft-ietf-ippm-ioam-direct-export-08
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, 14 Jun 2022 03:12:13 -0000

Reviewer: Linda Dunbar
Review result: Has Nits

I have reviewed this document as part of the Ops area directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Ops area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

This document specifies an IOAM encoding (Direct Export Option) to trigger IOAM
data to be directly exported or locally aggregated without being pushed into
in-flight data packets.

I think the document is READY with some nits:
>From the operation point of view, can the "entity" that the IOAM is directed by
DEX Option send an explicit request to all the nodes for the IOAM to be
exported to them? instead of asking the DEX encapsulating node to encode the
DEX in some data packet? If not, why? If yes, can you add a comparison of those
two approaches?

Thank you very much
Linda Dunbar