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

"Frank Brockners (fbrockne)" <fbrockne@cisco.com> Mon, 05 August 2019 07:07 UTC

Return-Path: <fbrockne@cisco.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 6C3D9120150 for <ippm@ietfa.amsl.com>; Mon, 5 Aug 2019 00:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=YwQ2cqYV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=g1dsY8mn
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 zUVMCjaRt1hA for <ippm@ietfa.amsl.com>; Mon, 5 Aug 2019 00:07:35 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886EF12014F for <ippm@ietf.org>; Mon, 5 Aug 2019 00:07:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13794; q=dns/txt; s=iport; t=1564988855; x=1566198455; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IAjgdh7skutVf+9OokzEpP4A4UtE5cekE2JHE8GWPhA=; b=YwQ2cqYVjjmu6GxBj6puwMm/q6CWIaDhDbe6RsigYrcleUZy9hX5/MMx ZOL8vvWUQzwkd8VhZb5XwoZtrfYboP7uXQ5eYRDFT4hOykFAuAA4LEYBq Ga4hHJps7vsxJdFy2VAcj1pwuuYmNUp9J7mCUj+JajNiU/ypq7c6vgmS0 Q=;
IronPort-PHdr: =?us-ascii?q?9a23=3ANL8Wrx9ExJQy1P9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcCPE0rwL/jnRyc7B89FElRi+iLzPA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAAD41Edd/5BdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVQMBAQEBCwGBRCknA21VIAQLKgqEFINHA4ssgluXWYEugSQ?= =?us-ascii?q?DVAkBAQEMAQEYCwoCAQGEPwIXgk4jNgcOAQMBAQQBAQIBBm2FHgyFSgEBAQE?= =?us-ascii?q?CAQEBEBERDAEBJQcLAQsEAgEIEQQBAQECAiYCAgIlCxUICAIEDgUIGoMBgWo?= =?us-ascii?q?DDg8BAgyfdQKBOIhgcYEygnoBAQWFBRiCEwMGgQwoAYRxhnEXgUA/gRFGgkw?= =?us-ascii?q?+gmEBAYFjgwkygiaMDzOCR5subQkCghuGXIQyQ4hogi+Veo57hiSQGAIEAgQ?= =?us-ascii?q?FAg4BAQWBVwMugVhwFTuCbIJCDBeBAwECB4JBhRSFP3KBKYtyAYEgAQE?=
X-IronPort-AV: E=Sophos;i="5.64,349,1559520000"; d="scan'208";a="611416064"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Aug 2019 07:07:34 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x7577Y9n003470 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Aug 2019 07:07:34 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 02:07:33 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 02:07:33 -0500
Received: from NAM05-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 5 Aug 2019 02:07:33 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bY7VjWPePhBJJnqdpkAsT1Rx1TygVPP3VEwDN+ZdRcliWxdXPyalG/XdwQ172brPfX8McAqs+RVgYl/7qFLoIkmhDeNiO6T4BbpxdVhLEJGcWjYDg0buEqCkdA84/zjOpM1FvIsGCQJkxL2ygnvF9ZlyrlzD7dRnBvsBknt5MytxV0dvbgORWFyWaJ7FUt6cfHADqtR1L2JOGAB7wYx22E0gkCLkHoGqnhMoOFss/mHsBqt6uklpYWX1rq9xr+D9G7yt/S2sWcB7PjozJqPdPunlYwvGBY/wnuxdvX+oWEbKV6N1jDdgF+jONmxx1I+hD6zYb3M4ikwHBY7Aee4y/Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IAjgdh7skutVf+9OokzEpP4A4UtE5cekE2JHE8GWPhA=; b=YfjbUE+hJALdy/AtDvhqJ9rGcYZ7xYOLUvDUV79wx0VSmjTatr7TEKCev8aFiJidT9+KpXxLIO6mfh8sJqxkCOuhRZn/vjdaqh9LH1GhZIvfyxf/oL/xP/LfMlgw02e7rwsSlAJATf1EnMmJJkAtz/rjunOavLevo+O7A5t9zVST9TXFghMjwPPxrWQT1fjBxyEG3/7BuD3Hf/9Y0801s0MrXne+xp4pCk7FFENydE81KBTxLveSNE8S0jxxPMdAgqXcg2jEEmvD7YwlF5xxgU0FLqfi7m/LQBV8muks4s0qp6QVUVY5x4orrbTrobLReFUpuLsbkQ+xpUAO8OfHMg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IAjgdh7skutVf+9OokzEpP4A4UtE5cekE2JHE8GWPhA=; b=g1dsY8mnyS6UcvLBd9Ap4+mWM6L/8xTD0kR9SXLupRVtYnQ11eX0ijXOKkBgPOUH9QIqfYMy0yHj673Fy2exUYlBqTLfX4i+KYr3luMkP4Eq2p6NG5EKc1+JxVAJm58kmzyGLeReJdJfQD8lWLQ5AknFfelSw+4DQMDiHBhTb88=
Received: from BYAPR11MB2584.namprd11.prod.outlook.com (52.135.227.17) by BYAPR11MB2934.namprd11.prod.outlook.com (20.177.228.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Mon, 5 Aug 2019 07:07:31 +0000
Received: from BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::d443:d196:b8f6:d858]) by BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::d443:d196:b8f6:d858%7]) with mapi id 15.20.2094.017; Mon, 5 Aug 2019 07:07:31 +0000
From: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
To: Tom Herbert <tom@herbertland.com>
CC: IETF IPPM WG <ippm@ietf.org>, Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Thread-Topic: [ippm] Comments on draft-ietf-ippm-ioam-data-06
Thread-Index: AQHVQnSkcM+hM0NzCkyT+m1G2sWgdqbjT4aAgALTBWCAA7/DAIACTR7w
Date: Mon, 5 Aug 2019 07:07:31 +0000
Message-ID: <BYAPR11MB2584275311BDA53408939E3CDADA0@BYAPR11MB2584.namprd11.prod.outlook.com>
References: <CALx6S34aMnTzFuoQnPScCu8mG2FT37o4Ok4DSP-5vYO9xEq=UA@mail.gmail.com> <CALx6S34ureyjwo1DYTKYGEecGy46NzAbuGcV+nrhw98+CLUK1w@mail.gmail.com> <BYAPR11MB2584A42E0A36AD939699E618DADE0@BYAPR11MB2584.namprd11.prod.outlook.com> <CALx6S35czgwSxppCpJwPnCXgYF_BnOhBcktq9wNrGarBEBbScw@mail.gmail.com>
In-Reply-To: <CALx6S35czgwSxppCpJwPnCXgYF_BnOhBcktq9wNrGarBEBbScw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=fbrockne@cisco.com;
x-originating-ip: [173.38.220.54]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3ba54e87-215b-4eec-571a-08d7197395ae
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2934;
x-ms-traffictypediagnostic: BYAPR11MB2934:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <BYAPR11MB2934F4C8544BE672DE6180D6DADA0@BYAPR11MB2934.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01208B1E18
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(39860400002)(376002)(346002)(396003)(366004)(136003)(51914003)(189003)(199004)(13464003)(3846002)(26005)(316002)(6116002)(5660300002)(186003)(9686003)(6306002)(53936002)(52536014)(64756008)(76116006)(66556008)(66946007)(66476007)(476003)(66446008)(229853002)(6916009)(486006)(33656002)(7736002)(74316002)(8676002)(81156014)(81166006)(305945005)(8936002)(55016002)(446003)(4326008)(25786009)(478600001)(966005)(14454004)(11346002)(7696005)(99286004)(256004)(6506007)(53546011)(14444005)(76176011)(102836004)(68736007)(6246003)(54906003)(6436002)(86362001)(71200400001)(71190400001)(2906002)(66066001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2934; H:BYAPR11MB2584.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 6vzaWCgrcXwm+UXQzqH4OHXR/+15xX5z6yMOKi/nW57XHgCLEGX42eeH1YAOzta8gPY59BrRQXKVjHHfCZyc9QzcOez8BbMiAc+GuAh2zxSa9ZSHHdWucu8DhBmYbi0isxPhGaYlNqeUtSYj/I7ylpki1hJSkbR04hT7Ag+0D2HmV8WnuwlyutHAfmLPPqN5H+joXO9ThTXnRBkGuOiN65bmoHppBd1eMnl/87EcrGlceBadyaGLIHbfW3KtstR64pGg5Y1pWcgVH4q8NQbrxFSPdI/oCbsFpobHIAB9T6EW5e/uhiBq+CIlkO1//RtXRnr8oTzc9V78eRb1s/3WcKArXuyeNkg3fB3x1UfY73SxrgU5mpbfA2NDC9OdDEFGaeNHjWvQ9Hk/sf58N6lbIbcDlKdIJdG9XjOmxgFIQEk=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3ba54e87-215b-4eec-571a-08d7197395ae
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2019 07:07:31.4431 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: fbrockne@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2934
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.22, xch-aln-012.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/ZNe1Hqf_jzkVWE1UCoSoWa1mDNM>
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: Mon, 05 Aug 2019 07:07:38 -0000

Hi Tom,

> -----Original Message-----
> From: Tom Herbert <tom@herbertland.com>
> Sent: Samstag, 3. August 2019 21:43
> To: Frank Brockners (fbrockne) <fbrockne@cisco.com>
> Cc: IETF IPPM WG <ippm@ietf.org>
> Subject: Re: [ippm] Comments on draft-ietf-ippm-ioam-data-06
> 
> 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).

... FB: Not sure I follow the "can of worms" statement. Choosing a length is just an optimization. 
It would allow you to pre-compute things - so that during operations, you'd just check validity instead of doing the actual calculations.

Thanks for the pointer to GUE. Ordering the bits so that parsing becomes easier makes sense. So you seem to suggest that we make "opaque state snapshot" bit 22 (assuming that we're reserve 23 for future extension and move checksum - as a fixed size field further up)?

> 
> > * 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?

...FB: This is why IOAM has namespaces. IOAM does not define any semantics of the fields carried - this means that the semantics can (and are also expected to) change from namespace to namespace.  


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

...FB: Sounds reasonable - but I'd like to hear other opinions as well - especially Tal's who wrote the initial patch for checksum complement.

Thanks, Frank

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