Re: [ippm] Éric Vyncke's No Objection on draft-ietf-ippm-ioam-data-12: (with COMMENT)

Tal Mizrahi <> Sun, 23 May 2021 07:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B5F33A31FC; Sun, 23 May 2021 00:47:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X1vjMG3Ol9sO; Sun, 23 May 2021 00:47:56 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E9A6C3A31FA; Sun, 23 May 2021 00:47:55 -0700 (PDT)
Received: by with SMTP id z85-20020a1c7e580000b029017a76f3afbaso6815800wmc.2; Sun, 23 May 2021 00:47:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=us6q1Kz1r17K5fmE7DT3no2bG576Z7sK9Jgi8xnxJp4=; b=eBjDbJ4+b+7tJT8nBF0MazROKsmS9Ftlatm7BpIEWsIoyiU0jC/yPKontuQKnWghMQ ystRF8bLx59uNJf+VRD8PvdZ9RICzKivBO+kMprIt6Pv+217rCUJ04dk/krSQeL6TjUt NHtJUUZiL1YP+GYiGe86P0SpyGb2kEWFqKxlbOH/uhMVEreykijG57LCCQOfrU5gWIdr ie13YqgYoUtghfAfKOtPQIx+5fMM7LorOlekZdJERj9Mo2UQ/+yaiOrQXOZcjsZK7fjr Ut6kqG2DZoWFLXGaeJK1KgoSH2zBa7A5pYPFq0C0WrVCrj/s1zy3W/PO6UtnAo190bVE 4P8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=us6q1Kz1r17K5fmE7DT3no2bG576Z7sK9Jgi8xnxJp4=; b=CRQw4BYooE0lrYSVqEB5yxSWvtACBikxKz9zFUZJzIB59fP2AmPtDiuXxkiANFFj1Y GxQqEQOOxZPpmMSnr+02UgXCdM5Z+xzXmXEKoTAEEDUk7HQhaaQc52qKAmEiJlx7U5ba ZOQ79B2Ck+9dzmYp62HNqjT2HYh/USTHhlZeDE9LxvGguGmmK3XgbXZYswXUVEpd8xii DbRcEkqs1rQNHhKwOE5rWwqi2qVIu4j5OX2SCjvv5PZVVz5b07vS5+XOTl6cNJPlvgGh jp6nydRETETJ6VKi+gQOKRAcgWAG3GCTfF4ooMQsA4I0Z2qu7alIE3uupVF77ek3wyzL Cy8w==
X-Gm-Message-State: AOAM533T/HRnHensSJeYBSR+tn4xxrVUyZv65Q6F2ATWkwMG68XAKpVd rbYVc+AVUdUES33I+RNyNAlRku2AMCfppnWW5/Q=
X-Google-Smtp-Source: ABdhPJwLKV83leJn/WdSocutdRoI7udQYmSXkX8sWEMZAptv41TZZEM6QWqeV6gUlUyl8GxMV1VmZ/tFBwyX4TU1ryI=
X-Received: by 2002:a7b:c923:: with SMTP id h3mr5203203wml.67.1621756072751; Sun, 23 May 2021 00:47:52 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Tal Mizrahi <>
Date: Sun, 23 May 2021 10:47:39 +0300
Message-ID: <>
To: Éric Vyncke <>
Cc: The IESG <>,, IPPM Chairs <>, IETF IPPM WG <>, Al Morton <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [ippm] Éric Vyncke's No Objection on draft-ietf-ippm-ioam-data-12: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 23 May 2021 07:47:59 -0000

Hi Éric,

Many thanks for the comments.
We are currently working on an updated version of the draft that will
accommodate the comments.

Please see our responses and proposed changes below.
Please let us know if there are further comments.


On Thu, Mar 25, 2021 at 10:34 AM Éric Vyncke via Datatracker
<> wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-ippm-ioam-data-12: No Objection
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thank you for the work put into this document and thank you for acknowledging
> my comments and advices (as they were minor, I am not recusing myself).
> Sometimes the text is difficult to read as paragraphs and sentences are long
> and somehow repetitive.
> Please find below  some non-blocking COMMENT points (but replies would be
> appreciated), and some nits. Like Alvaro, I was hesitating to ballot a DISCUSS
> on one point about section 4 (insertion/deletion of data on the flight).
> I hope that this helps to improve the document,
> Regards,
> -éric
> == COMMENTS ==
> -- Abstract --
> "a path between two points in the network" does this mean that this document
> cannot be used with a multicast destination address ?

Proposed text update:
traverses a path between two points in the network
traverses a path in the network

> -- Section 2 --
> Is the list about 'contributors' (as in the section title) or 'co-authors' (as
> in the text) ?

After a bit of discussion with the WG chairs, this was the text that
was recommended for this section.

> -- Section 3 --
> Please use the BCP14 boilerplate

Right. Will be fixed.

> Please note that Geneve is now RFC 8926.

Right. Will be fixed.

> -- Section 4 --
> Should the 'deployment domain' include a reference to RFC 8799 ?
> I was about to ballot a DISCUSS on this one: While the actual encapsulation is
> out of scope, the definition of "IOAM control points" alludes to nodes at the
> edge and in the core being able to add/remove data fields. This behavior will
> obviously have some impacts on the PMTU discovery and possibly on the handling
> of ICMP. Did the authors think of writing a generic section in this document on
> how this can be done in a correct way?

Right. This was also pointed out by other IESG members, and we plan to
clarify this text, including a reference to RFC 8799.

> What is "live user traffic" ? I guess that this is not about end-user real-time
> video ;-) but a better wording would be welcome.

s/live / /

> I am afraid that "ships in the night" does not apply here as all ships are
> usually on the same layer ;-) (planes do flight at different flight levels)
> But, this is not that important. No need to reply.
> -- Section 5.1 --
> Is it expected to have additional IOAM data types than the 4 in this document?
> Text should clarify this.

Right. We will add the following text to section 5.1:
Future IOAM-Option-Types can be allocated by IANA, as described in Section 8.1.

> -- Section 5.2 --
> "A transit node MUST NOT add new IOAM-Option-Types" seems to contradict the
> "IOAM control points" definition of section 4.

Section 4 says: "Devices which form an IOAM-Domain can add, update or
remove IOAM-Data-Fields."
Specifically, transit nodes can add data fields, but not option types.
This is clearly specified in Section 5.2, as well as the difference
between an encapsulating node and a transit node.

> -- Section 5.3 --
> If 0x0000 is already reserved, then I would suggest to make it part of the IANA
> range (i.e., making IANA range 0x0000 t 0x7FFF).

Right. This value is already defined in the IANA section as reserved.
The text just explicitly states what the meaning of value 0 is:
"0: default namespace (known to all IOAM nodes)"

> -- Section --
> Should there be a precise definition (or reference) of "time in nanoseconds the
> packet spent in the transit node"? E.g., between first bit received and last
> bit sent ?

We tried to avoid explicitly specifying this, in order to avoid
mandating a specific hardware/software architecture.
We plan to add a general note to Section 5.4 that discusses the fact
that some of the node data fields have implementation specific
It should be noted that the semantics of some of the node data fields
that are defined below, such as the queue depth and buffer occupancy,
are implementation specific. This approach is intended to allow IOAM
nodes with various different architectures.

> -- Section --
> Is there a reason why the queue depth is expressed in buffers and not in
> packets? (Both metrics have useful values imho)

Right, again this goes back to the note about implementation specific
semantics. We hope the note we are adding to Section 5.4 addresses

> -- Section 5.5 --
> In "Random: Unique identifier for the packet" how are collisions resolved? Do
> they matter at all ?

Good point, and we will add some text about this to the PoT draft. The
current draft only defines the fields. The detailed functionality is
specified in the PoT draft.

> How can a transit/decaps node can handle the PoT (and also the E2E of section
> 5.6) as the length is not specified in the header ?

The length of the PoT option is constant, and thus a node that detects
the presence of a PoT option knows its length.
For the E2E option, a node that parses the IOAM-E2E-Type field knows
the length of the option.

> == NITS ==
> Usually "e.g." is enclosed between commas.
> The sentence "The definition of how IOAM-Data-Fields are encapsulated into
> other protocols is outside the scope of this document." or a minor variation of
> it occurs multiple times in the document. Please consider avoiding those
> repetitions.