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

Tom Herbert <tom@herbertland.com> Sat, 03 August 2019 19:42 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58CD120137 for <ippm@ietfa.amsl.com>; Sat, 3 Aug 2019 12:42:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyezA-eKdEAU for <ippm@ietfa.amsl.com>; Sat, 3 Aug 2019 12:42:54 -0700 (PDT)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 8DC34120058 for <ippm@ietf.org>; Sat, 3 Aug 2019 12:42:53 -0700 (PDT)
Received: by mail-ed1-x535.google.com with SMTP id i11so11751957edq.0 for <ippm@ietf.org>; Sat, 03 Aug 2019 12:42:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=h8w1/7Y94mOYdaDJx3K8lWlsSXZMvGTJ3BAmdncXBtQ=; b=2DD/jfAbYJtpCeRG6NUJEMbeti6zKXBnVQfZ+bBKbArm72QgfHUD01gozKKzvpTWsF rIs2l4/Qfr+HjAPljitstobz4hekOQGM/ydr7fFVnIBo8OHoJ557bdq78MuzgYYm7TNQ a59DwTjX8mB3puS1uXeOlNnfT+0i7pWM1QzlosnLMBJJ7Mf6k4L1NKIsAI7cNBLROVRQ dI2Suo7/JffGCFYaBfEeffs5aau8CB4OIV+xNw6kBh+b5ziX43k+Q39YPdk3htCPQJl0 mnMLMOzBLVFuYCH2/OKuhbGzqvAbxmJalqisuxYTZCxKdGpkuBmxLHmEH/9VVyMaeVNX F+tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=h8w1/7Y94mOYdaDJx3K8lWlsSXZMvGTJ3BAmdncXBtQ=; b=AHRFsHxGynTM4QKH4Ny0T5FnyVEOiTgEHU6gyyaByxeTH9XuB2IgTQOGcs2wF1oymw 8WWfiFPCrdKw6uBEQw//hrQ0LWqz+nqk6ZnANFsKC+LRqoWmacwitJomoOssmlkg6+VG tY3oEPxTlWBhqgwrdg/pJYVe3g5ePkL3omg06Yg7tD+UNryJqnEbtDVy4fwEkWWYABf+ MHfofXLh0Sc91NN0SIRhYqpJn4YowBNFvyOre9BeOa21MByTAgLh0C7PYv7DKU+zYX4B zy4fMHsch9514SwH92OfmNFYqRZdZWqYfd+QxLlqx29gqpj/M4EjRs4psIoO6kzpybDb 1ZLw==
X-Gm-Message-State: APjAAAVW6zyZh1OWLIpo2Aepwvd99arq+Ful9HsDxSyBM1xzGlGQm6sy 9+1mN5MESxkoUPJKvM3wBfw/MHJV70nS9nFy688=
X-Google-Smtp-Source: APXvYqyQSSm79vEhFjSQniy2FK6SnpmznODAcdGQhzvemHHB2rTMTroc1XwjSFFORkaOBU5fvnbGSzk9TvFI0aiWVz8=
X-Received: by 2002:aa7:d30d:: with SMTP id p13mr127504001edq.292.1564861371951; Sat, 03 Aug 2019 12:42:51 -0700 (PDT)
MIME-Version: 1.0
References: <CALx6S34aMnTzFuoQnPScCu8mG2FT37o4Ok4DSP-5vYO9xEq=UA@mail.gmail.com> <CALx6S34ureyjwo1DYTKYGEecGy46NzAbuGcV+nrhw98+CLUK1w@mail.gmail.com> <BYAPR11MB2584A42E0A36AD939699E618DADE0@BYAPR11MB2584.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB2584A42E0A36AD939699E618DADE0@BYAPR11MB2584.namprd11.prod.outlook.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sat, 3 Aug 2019 12:42:40 -0700
Message-ID: <CALx6S35czgwSxppCpJwPnCXgYF_BnOhBcktq9wNrGarBEBbScw@mail.gmail.com>
To: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
Cc: IETF IPPM WG <ippm@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/Po1xkWzdgEwxfsh6yMXbfNKMXqc>
Subject: Re: [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: Sat, 03 Aug 2019 19:42:57 -0000

On Thu, Aug 1, 2019 at 3:59 AM Frank Brockners (fbrockne)
<fbrockne@cisco.com> wrote:
>
> Hi Tom,
>
> Thanks for your comments. Couple of thoughts:
>
> * Bit 7 / Opaque State Snapshot:
>
> Per the discussion in the WG meeting in Montreal: The field could indeed lead to variable length data being inserted into the packet. That said, the envisioned use would be that for a specific deployment or IOAM domain, the "length" would be a fixed value so that a parser could be preconfigured in a proper way. Those could even be specified as part of an IOAM profile (draft-mizrahi-ippm-ioam-profile-00).
> For the next revision of the draft, we should add a deployment consideration for "Opaque State Snapshot" to reflect this discussion.
>
Hi Frank,

Preconfiguring a fixed length across a domain seems like a can of
worms to me. Maybe some domain has reason to use different lengths
simultaneously, or what happens the day that some domain changes
length? My comment wasn't in opposition of variable length opaque
data, it is a question of where the data should be placed in the
packet. I juat think it should follow any defined flag-fields (you
might want to look at how GUE handles private data which immediate
follows the flag-fields).

> * Bit 23 / Checksum complement:
>
> The idea for the checksum complement was indeed what you mention: Avoid the need to update the packet's UDP checksum by an intermediate entity, which isn't be able to update the UDP checksum itself. One can argue whether these nodes would exist - per what you say, but from what I remember, this option was added to be on the safe side. The field was added way back (https://github.com/inband-oam/ietf/pull/41). I'm hoping that Tal could shed some further light it.

Yes, I believe that it could be useful in the UDP case. My concern is
the placement of the field so that it skips over bits yet to be
defined. This makes backwards compatibility difficult when new fields
are defined that deployed devices won't understand and know their
lengths to find the offset of checksum complement field.

>
> * Short / wide format of fields:
>
> You note that "Having separate fields for different sizes of the same information awkward and inefficient." - thought these fields don't necessarily need to carry the same content. Both fields (short and wide) could indeed be present in the same packet and can complement each other. Given that the term "interface" isn't further defined, what an IOAM domain is going to associate with interface is flexible, e.g. "interface_short" could be an identifier for the physical interface, whereas "interface_wide" could be an identifier for a logical sub-interface of that physical interface.

Okay, but I wonder how that will work for interoperability. i.e. is
there a problem if different implementations apply different semantics
to fields?

> Per your suggestion - given that we use 2 bits, we could consider making things more flexible by using all of the four potential values of the 2-bit number (like your 16/32/64 example). The question is: Is this needed? I'd appreciate additional opinions.
>
> * 24 bits Trace type
>
> Per your suggestion, reserving a bit to allow for future scalability makes sense - and bit 23 would be an obvious choice; which would in turn mean that we'd need to assign a different bit for checksum complement. If everyone else is fine with this change, we can include this change in -07.

One other minor suggestion for the checksum field is to define it as
32 bits instead of just 16 since the field size is 32 bits regardless.
This might save some folding operations when writing it. For instance,
if a 32 bit field is set with initial value of zero, we would just
need to set the checksum field to the not of the value being set
(assuming checksum field is also initialized zero, otherwise it's a
one's complement add)-- no need to fold to sixteen bits. Of course, if
an implementation really wants to fold the result to sixteen bits it
can and still results in the same effect.

Tom
>
> Thanks again, Frank
>
>
>
> > -----Original Message-----
> > From: ippm <ippm-bounces@ietf.org> On Behalf Of Tom Herbert
> > Sent: Dienstag, 30. Juli 2019 17:20
> > To: IETF IPPM WG <ippm@ietf.org>
> > Subject: Re: [ippm] Comments on draft-ietf-ippm-ioam-data-06
> >
> > On Wed, Jul 24, 2019 at 4:07 PM Tom Herbert <tom@herbertland.com> 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.
> >
> > Tom
> >
> > > 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
> >
> > _______________________________________________
> > ippm mailing list
> > ippm@ietf.org
> > https://www.ietf.org/mailman/listinfo/ippm