Re: [ippm] Robert Wilton's Discuss on draft-ietf-ippm-ioam-direct-export-09: (with DISCUSS and COMMENT)

Tal Mizrahi <> Thu, 18 August 2022 12:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6576FC152704; Thu, 18 Aug 2022 05:59:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Status: No, score=-7.106 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_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 qYa2Q9HsD4_1; Thu, 18 Aug 2022 05:59:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 84D9EC1522C8; Thu, 18 Aug 2022 05:59:54 -0700 (PDT)
Received: by with SMTP id p125so1474596pfp.2; Thu, 18 Aug 2022 05:59:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=qDAgsGKi+o0q61IVE/aGfjBPf5jTcBZoMrhuxxtt8vo=; b=COlaZSA5aGN8eBbPFQw46GCnNjgpCH8ps3zHadY4QLMw6dcMM8QkOwGIEQX/Oak0xd UfyNx13lKf21nzx88NQIE0+Asyf+pEfQSEnIfBaNH7bgX2LmvEnVhXeCvnSzrnm7OoGg iARBFkmbT++x6FufCoCIadsHi8YUuKYC/PcQmQQCqjMbEf+cNdyD0u6csvF/kRZgftuH C+E1vlyAr4nXxylnTfcSVGKinAMkeYKTLLdtkxXgCiDQOwnHCjmqHno0ylcGObIdIS64 C3iOzQT5MJuEtarN/1z03N0pGfwhuqQNs68cYZjKEoLYfF4MNX8ULFhivDkqChNuf94H 1V3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=qDAgsGKi+o0q61IVE/aGfjBPf5jTcBZoMrhuxxtt8vo=; b=bT0OlFwCtjTcIptGha0MczFiB1w4fullg5otuojOKZCNu9Dfhgy3nw+CumQxcm3YZW jLN/HMDb/MqVIujQO7ajjLcChr5Bmq2etAX9kljHUkIr07OxBYM/BO03FqzL1fHzZXbD eLvlSkU7hD9jzP1WVVFNhyePchKYP8M5DRAKTO4w5Hgvnyhgv/CL3uV4xAzcmhCZi2sh D6kiS44l6vr8EEXKhyKNTG/2v3YL4qXxUxvIs4ivpPTkUZGRHscHPs7LO9iJOvc3I6bU KCn5CTQLYlnDXI9ABk9AI5nrx5E07w7n5g9T28UZvRagE2KaFQmxCzDstN4zb2x3DMAx F15w==
X-Gm-Message-State: ACgBeo0DBjAlT2eXlYSuYs4bPjX2h4MRLFIy9VaAvBgs+NTs4zzZaCNW +9a+rF7Zzf8y0T8AymNmtXRpeES48Arzu9z8sjI=
X-Google-Smtp-Source: AA6agR4aXA6Xqa3BAEMlCM1kcG5xAjhg9Sebu3eddUgwgrYBfszT7XL144/Nk0wCfA905BR/y0J1eTUkiyAOb0Q002I=
X-Received: by 2002:a65:4605:0:b0:41c:3d73:9385 with SMTP id v5-20020a654605000000b0041c3d739385mr2327847pgq.168.1660827593632; Thu, 18 Aug 2022 05:59:53 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Tal Mizrahi <>
Date: Thu, 18 Aug 2022 15:59:38 +0300
Message-ID: <>
To: Robert Wilton <>
Cc: The IESG <>,,,,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [ippm] Robert Wilton's Discuss on draft-ietf-ippm-ioam-direct-export-09: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Aug 2022 12:59:58 -0000

Dear Robert,

Many thanks for the comments.

We have uploaded an updated version that hopefully addresses the
DISCUSS comments.

Please see my responses below, marked [TM].

Please let us know if there are further comments.

On Thu, Jun 30, 2022 at 1:37 PM Robert Wilton via Datatracker
<> wrote:
> Robert Wilton has entered the following ballot position for
> draft-ietf-ippm-ioam-direct-export-09: Discuss
> 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 how to handle DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Hi,
> I had a couple of minor discuss comments to clarify a couple of points that
> seemed unclear:
> 1) Definition of Sequence Number:
>    Sequence Number An optional 32-bit sequence number starting from 0
>                    and increasing by 1 for each following monitored
>                    packet from the same flow at the encapsulating node.
>                    The Sequence Number, when combined with the Flow ID,
>                    provides a convenient approach to correlate the
>                    exported data from the same user packet.
> Please can you clarify.  Is this every packet in the flow (presumably not)?
> Does monitored packet means just those with the DEX option?  Could it include
> other packets

[TM] The text was updated - only packets with the DEX option are counted.

> 2. Optional field ordering.
>    Optional fields The optional fields, if present, reside after the
>                    Reserved field.  The order of the optional fields is
>                    according to the respective bits that are enabled in
>                    the Extension-Flags field.  Each optional field is 4
>                    octets long.
> Please can clarify that the order is from most significant bit to least
> significant bit of the option field.

[TM] Fixed.

> 3. Allocation is based on the "RFC
>    Required" procedure, as defined in [RFC8126].
> Given the number of extensions is so limited, is RFC required (e.g. allows ISE)
> really a strict enough allocation policy?

[TM] Agree. Changed to "IETF Review"

> Regards,
> Rob
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Here are my non-blocking comments:
> 1.
>    This draft has evolved from combining some of the concepts of PBT-I
>    from [] with immediate
>    exporting from [I-D.ietf-ippm-ioam-flags].
> I'm not sure that this paragraph is really helpful now, and could probably be
> deleted - you could use the datatracker to indicate the document history and
> which previous drafts this document replaces.
> 2.
>    N >> M
> I'm assuming that by ">>", this means much greater than?  It would be better
> use words here, or at least define what this means (e.g., as opposed to a
> bit-shift).
> 3.
>    An IOAM node
>    MAY maintain a counter or a set of counters that count the events in
>    which the IOAM node receives a packet with the DEX Option-Type and
>    does not collect and/or export data due to the rate limits.
> Given that this is a MAY, I wasn't sure that this really specifies anything, I
> guess that it is just offering a suggestion.
> 4.
>    Exported packets SHOULD NOT be exported over a path or a tunnel that
>    is subject to IOAM direct exporting.  Furthermore, IOAM encapsulating
>    nodes that can identify a packet as an IOAM exported packet MUST NOT
>    push a DEX Option-Type into such a packet.  This requirement is
>    intended to prevent nested exporting and/or exporting loops.
> It was unclear to me how that that SHOULD NOT can really be enforced, if the
> exported packets are allowed to leave the limited domain.  Perhaps the "SHOULD
> NOT" should be limited to the domain where IOAM is operating?
> 5.
>    transit or decapsulating IOAM node that receives an unknown IOAM-
>    Option-Type ignores it (as defined in [RFC9197]), and specifically
>    nodes that do not support the DEX Option-Type ignore it.  Note that
>    as per [RFC9197] a decapsulating node removes the IOAM encapsulation
>    and all its IOAM-Option-Types, and specifically in the case where one
>    of these options is a (possibly unknown) DEX Option-Type.  The
>    ability to skip over a (possibly unknown) DEX Option-Type in the
>    parsing or in the decapsulation procedure is dependent on the
>    specific encapsulation, which is outside the scope of this document.
>    For example, when IOAM is encapsulated in IPv6
> I found the sentence from "Note that ..." to be somewhat unclear.
> 6. Option-Type Format
> Would it be more helpful to explicitly specify what the length is.  I.e., X
> bytes + 4 * number of set bits in the Extension-Flags?
> 7. Extension-Flags
> More a question for my own knowledge:  I presume that the length calculation
> (i.e., checking for the count of set bits) can be performed efficiently?  I.e.,
> if calculating the length is important on any fast path.
> 8. subject to birthday problem conflicts, while centralized
> Would it be helpful to spell out what is meant by "birthday problem conflicts",
> or perhaps include an informative reference to the wiki page?
> Nits:
> N>100 => N > 100