Re: [ippm] Comments on draft-ietf-ippm-ioam-data-06

Tom Herbert <> Tue, 30 July 2019 15:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE99912019F for <>; Tue, 30 Jul 2019 08:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 0TVp52zrjNCa for <>; Tue, 30 Jul 2019 08:19:59 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C11241201AF for <>; Tue, 30 Jul 2019 08:19:58 -0700 (PDT)
Received: by with SMTP id k8so62896200eds.7 for <>; Tue, 30 Jul 2019 08:19:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=kKnKEH34fX/cr2f7ULU1iAVvkWpEgDyBBqZDPxTldgY=; b=KXuEyYwgeAAxelySjXsK9yFJ1/bMEjGNV5KfsLMg/oYapAmbN9tXH/i0chcyjWXfmW 81yBwvm3JA2QnTGnBI3cUaFhWP0QiQ3MzTP6vkpmNquBplZ+vPxEleyqnSud9srpk730 HCFNR8TVt1XT23xqU/947Oa92D99zIAwR2TUaatwJ4xR5tdRltMxQvnre8pqJxcrP2wQ xtN86bYDwGwddPT/vfzt93I73oroWh2PYkneh44W0TRnoV90kTyErYmdzycwmMf4zKaq U2XlJDuKfWtGycffOJsBohIcH/q2aH3++saif4Q5+dxgkBziPGqHsv68536ElhCQ5Gzd T6kw==
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; bh=kKnKEH34fX/cr2f7ULU1iAVvkWpEgDyBBqZDPxTldgY=; b=NxYKbgqFSum6yr+XchIjrRR6UDIEK2XHUPjQWvkLMg7LESqEee9WHS+rwXByBSD0Xq UvYoCR333dzmt2efckwCctosRZ5x/wFhZ50BtYNsV/+1C4MkfHZuHEjUxCdvhx32Xkaq iyjHhjHzaZtIp2llkXXrP2qE2NQya20aTLrIflHv6lKHICbX5NvwmFu3BsaJO390RGq0 pcIWNJuzi+cgV201ooWq58yRNQcAM5uVY0Q0Yf6rWlbXjKl6H7+DA8hYIiGaVFvtrg22 yNyk5dYnLcYIXd0myE+34lcFR2Sd0QOvpxHnBnj9i0jI2e2/q6E0EItkEBN0xw0kp2Of Kxxw==
X-Gm-Message-State: APjAAAWG20zvrPwECGlliJTiD8g3agaqF/ejUmjFVMTW6GsvgidmZBg8 W+VtjBkGMSIyKDhfuu0EwcXwkMULZrUkYeclGAf/Iuik93A=
X-Google-Smtp-Source: APXvYqwvbrk4y/Gogj8XBO1IFOrg0wwQjrXT10lH9Lsht2CCGqUaghsilHpB0nfgdhAZSCGQwFMiaV95Rmp4hZpDDTs=
X-Received: by 2002:a17:906:fcb8:: with SMTP id qw24mr90661849ejb.239.1564499996706; Tue, 30 Jul 2019 08:19:56 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Tue, 30 Jul 2019 08:19:45 -0700
Message-ID: <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [ippm] Comments on draft-ietf-ippm-ioam-data-06
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: Tue, 30 Jul 2019 15:20:01 -0000

On Wed, Jul 24, 2019 at 4:07 PM Tom Herbert <> wrote:
> Hello,
> These are some comments on the draft that are motivated while working
> on the IOAM hackathon project.
> From the draft:
> "Bit 7    When set indicates presence of variable length Opaque State
> Snapshot field."
> It seems like this would put a variable data field in the middle of
> fixed length fields of the bit vector. Also, it seems like the length
> could vary in each node. Both of these are harsh on a parser.
> If variable data is needed, I suggest that it should immediately
> follow the last flag field. The reserved field byte in the trace
> header might be used to hold the length of the variable data.
> From the draft:
> "Bit 23 When set indicates presence of the Checksum Complement node data."
> I don't understand why this is needed. As I understand it, this is to
> offset a change in the UDP payload so that the UDP checksum remains
> correct. Since the node processing this already had to parse into UDP,
> why not just adjust the UDP checksum itself (like NAT does for
> instance)?
> Skipping bits when allocating in the bit vector is also problematic.
> In order to determine the offset of the Nth flag field, a node needs
> to know the lengths of the 0..N-1 fields, but the lengths of N+1 field
> and on are relevant. This is important for backwards compatibility as
> new flags are defined. For instance, when bit 12 is defined, a legacy
> implementation that needs to set the checksum complement at bit 23
> would be unable to determine the offset of the checksum complement.
RFC7820 describes the need for checksum complement to be after the
field being set. I do believe that skipping bits in the vector is
problematic as described above. This also might preclude extending the
bit vector as proposed below.


> Side note, per RFC7605:
> "It is important to recognize that any interpretation of port numbers
> -- except at the endpoints -- may be incorrect"
> This might be a nuisance if just reading UDP payload that is
> misinterpreted, but modifying misinterpreted UDP data, which could
> happen if IOAM data being set is encapsulated in UDP, would be
> systematic data corruption. Very bad!
> From the draft:
> "Bit 1    When set indicates presence of ingress_if_id and
> egress_if_id (short format) in the node data."
> and
> "Bit 9    When set indicates presence of ingress_if_id and
> egress_if_id in wide format in the node data."
> Having separate fields for different sizes of the same information
> awkward and inefficient. Consider that both bit 1 and bit 9 might be
> simultaneously set and two different values could be reported. In GUE
> we allow flags to be group to allow different sizes for a field and
> that might be useful here. For example, for ingress and egress ID a
> two bit flag could be defined where 00 indicates field not present, 01
> indicates 16 bit IDs, 10 indicates 32 bit IDs, 11 indicates 64 bit
> IDs.
> "IOAM-Trace-Type:  A 24-bit identifier which specifies which data
> types are used in this node data list."
> With more than half already allocated it seems like the bits could be
> exhausted relatively quickly especially if IOAM is a rousing success
> and people apply their wildest imagination as to what data to collect.
> I suggest to reserve the last bit of the vector. This bit will
> indicate a field is present that itself contains another set of flags.
> And in turn the expansion field's last bit can indicate another
> expansion field and so on.
> Tom