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

Tom Herbert <tom@herbertland.com> Wed, 24 July 2019 23:07 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DB2A1120103 for <ippm@ietfa.amsl.com>; Wed, 24 Jul 2019 16:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7Np6y8UuvnYi for <ippm@ietfa.amsl.com>; Wed, 24 Jul 2019 16:07:32 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF60412006E for <ippm@ietf.org>; Wed, 24 Jul 2019 16:07:31 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id w20so48475928edd.2 for <ippm@ietf.org>; Wed, 24 Jul 2019 16:07:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=JSDFjXsnZRiaWovAzxYusFVR6eCat4M6yqszfcHXcVM=; b=kq3ooyiC61em2tKE+kM1aT0lqruV2bakhqCCgzus0MaresPRxY4Ui2aL9sCYUgi0TA QLtGPE0EDfCzb4ggwgmsQ16dqth1zLrF626KVFm1BIPVZmQOLAS32v0c2ad55oBdHRSG iGxTGkl45fwyDWYpZ9RdJ+qx+u0BTg/zhP8pUR/P5iW9qNy/eBvExI2Q2n/MPhxgbNoG ZaepKKA3Lvv0fuiad5LqDj552x/O0EiPLKTKlibMELXyQq16eyLjF8Nxkt/swPTE1AIA J/XUMDJVD//wcUDOOOo3ZIQh+tw9LPhcOcXO00UeBBvZCrnZwmEVVHMDjLpB4Z3K/IlG VXsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JSDFjXsnZRiaWovAzxYusFVR6eCat4M6yqszfcHXcVM=; b=cr2ScSEbuCEphZCREZ7WY9BmzvmKKl561bKHpeGvAIWfHoCoYsrUhLJ6hs8W0ZGVf2 5WD40G9J/szk161O0m5BJuTIcwn7Gyy5Hrlo+KfedPvS5et0utMGv/WOqTOOhOsauKWq n1Gm19CcvMhR5ei/GUojb4hsUoyoKIVYOUvftLU0B+M9prfQzFWMbymeKuKwrFzDMmj0 U7jXkPzk5xqdvje9nn2VQ8XfKfPxoDpd0X/jqUq87Q8VyTxsrsULU2lgjFbAYSMOlCug +EN524GWoNKEXwqp8vT/FVskFAx37BMkEZiGyCPFyMDP1c/xOwyDtLn3VkpNquGjCF0d 2d8g==
X-Gm-Message-State: APjAAAX3jLpGoI8EBIO39ZDkv58G47ARauymilRxWOLGUq2OCGzONUvp ibAj98ao0yLE3g6hgdKaokmIapS6TcUkzNbCMjZ3E+Us
X-Google-Smtp-Source: APXvYqxJ3ZyBKcW1BuyMEFiGH92O/cSn1ixxsgMllVrW3byXl+UgTZpP+SLgdJtpXJLlYxjtHbx+hWLY1hXjhfzcBJU=
X-Received: by 2002:a17:906:229b:: with SMTP id p27mr63013483eja.266.1564009649816; Wed, 24 Jul 2019 16:07:29 -0700 (PDT)
MIME-Version: 1.0
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 24 Jul 2019 16:07:18 -0700
Message-ID: <CALx6S34aMnTzFuoQnPScCu8mG2FT37o4Ok4DSP-5vYO9xEq=UA@mail.gmail.com>
To: IETF IPPM WG <ippm@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/ze2P_NWJlPDgO2hV1Q9T6BL0rz8>
Subject: [ippm] Comments on draft-ietf-ippm-ioam-data-06
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Wed, 24 Jul 2019 23:07:34 -0000


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

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.

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."


"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

"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.